「エンタープライズSaaS」の開発フローで工夫している3つのポイント
このBlogは「アジャイル開発 Advent Calendar 2019の11日目」の記事になります。
安野と申します。今回は、MNTSQ社（モンテスキュー、と読みます）における開発プロセスの紹介をしたいと思います。MNTSQでは、機械学習/自然言語処理と、弁護士の高度なドメイン知識を組み合わせ、リーガルワークの現場にいるプロフェッショナル向けにプロダクトを提供しています。現場の弁護士先生がガンガン使うSaaS型プロダクトを、数名のチームで回しているのは世の中的にもなかなか珍しいのではないかなと個人的には思っています。
MNTSQは、「エンタープライズ向け（あるいはプロフェッショナル向け）」かつ「クラウド/オンプレ併用」という特徴を持っています。この制約下でうまくワークする開発フローを作るのは諸々試行錯誤がありましたので、この機会に紹介できればと思います。
おそらくエンタープライズにクラウドサービスが浸透していくマクロなトレンドを見ても、MNTSQのような制約を持つサービスの数は今後も増えていくのではないかと思っており、弊社が先にぶち当たった課題をシェアさせていただくことにも一定の意味があるのではないかと考えております。
当然、まだまだ試行錯誤をしている途中のものであり、組織のサイズやプロダクトの成熟度、開発を取り巻く技術環境に応じて、最適なやり方というのは常に変化していくものだと思っております。逆にこういうことをやると良いよ！というフィードバックもいただけると大変嬉しいです。
エンタープライズ向けサービスでは、高速に毎日デプロイするのは難しい
MNTSQでは、feature branchごとに1日xx回デプロイを回すということをせずに、2週間に1回デプロイを回すサイクルを組んでいます。これにはいくつか理由があります。
・オンプレ、クラウドの双方を対象にする場合、こちらでデプロイタイミングを完全に制御することが難しい
・お客さまの事情で「事前にデプロイ日程を決めて欲しい」と要望いただくことも多い
・よって、契約締結時にデプロイサイクルを基本的に決めておく運用としている
・複数環境が並存しており、デプロイオペレーション自体に工数が必要になってしまう（完全自動は難しい）ため、日々デプロイをし続けるということが工数的にも難しい
・クラウド環境だけ随時やるという手もありますが、動作環境ごとにバージョンが異なってしまうことは意図せぬ障害の確率をあげるものでもあるため
・エンタープライズシステムでは、障害発生に対してよりセンシティブであり、リリース前にしっかりとしたQAプロセスをはさんでおく必要がある
全てが自動テストされていれば良いものの、フロントエンドのテストなどは自動テストをする工数が見合わないことも多く、自動テストで全てを済ませることが難しい現状があります
・stgに出してみて、該当の機能が動いていればOK、というチェックだと、他の箇所に影響が出ていないかどうかのテストが甘くなってしまうため、リリース前のQA期間に主要機能は手動テストを通す必要がある
・お客さまのビジネスの中核部を担うことを考えると、エンタープライズサービスは求められる耐障害性が上がります
2週間に一度デプロイのタイミングを決め、そのタイミングから逆算してリズムを設計
前述のような課題から、MNTSQでは2週間に一度のデプロイを行い（サービス開始時点で握り）、そのタイミングから逆算して開発チームのリズム作りをしています。必要な定期イベントは全てカレンダーに入れる形で進めています。具体的にはこんな感じです。
10日前：前回のデプロイサイクルのKPT実施/ヒヤリハットのレビュー
9日前：次回デプロイまでにいれたいPRの意識合わせ
4日前：次回デプロイまでにいれたいPRの残作業確認
3日前：コードフリーズ、ステージング環境反映
2日前：QAの実施 (テストベンダーQA&社内ロープレ会)
1日前：QAで上がった問題に対するhotfix対応
当日：デプロイ
ポイントとしては3つかなと思います。
1) コードフリーズを実施し10日のうち20％をbugfixに当てられるようにする
2) 「ロープレ会」「オフショア」の二系統のQAを実施して、なるべく事前にバグを潰せるようにする
3) ヒヤリハットレビューをサイクル毎に実施
コードフリーズを実施し、10日のうち最大20％はbugfixに当てられるようにする
今回のデプロイサイクルでいれられるのはこの時間までにmergeしたPRまで！という時期を明確に区切っています。コードフリーズと呼んでおり、このタイミング以降に開発されたものは、基本的にデプロイはしないようにしています。
コードをフリーズすることで、QAおよびhotfixをすることができ、直前にいれた変更がバグを引き起こす、ということを防止することが可能になります。タイミングとしては3日前にコードフリーズを行うようにしていて、もしmerge時点で発見できなかった不具合が発見されても、最大で2日間は対応する余地ができます。
また、弊社ではgit-flowを採用しているのですが、stg検証用ブランチと本流のブランチを分けることによって、「feature branchのPRを本流ブランチにmergeすること」自体はいつでも可能とするようにしています。
「ロープレ会」「オフショア」の二系統のQAを実施して、なるべく事前にバグを潰せるようにする
コードフリーズ後に二つの方法でQAをするようにしています。一つはオフショアのテストベンダーに依頼しているフルチェックです。今回の変更が影響して、基本的な機能に悪影響を及ぼしていないことを確認するため、毎週主要機能を手動で動作させて正常に動作することを確認してもらうようにしています。
オフショア開発をすることにはいろんな知見が必要になるので、スモールチームだとあまり活用されるイメージはないかもしれませんが、テストだけ切り出すというのはかなりROIが高いやり方なのではないかと個人的には思っています。
もう一つのQAは社内で行うロールプレイング会、通称ロープレ会です。これは社内で新しくなったstg環境を実際に20分程度触ってみて、そこで使い心地が良いかどうか、バグがないかどうかということを洗い出して共有する作業になります。
このロープレ会はなるべく多くのメンバーが参加するようにしているのですが、バグチェックができる以外にも、メンバーの機能への理解が深まる他、実際に使ってみることで改善アイデアの議論ができる等、一石三鳥くらいの効果がある会だなと感じています。
ヒヤリハットレビュー会をデプロイ直後に実施
デプロイした記憶が新しいうちに、ヒヤリハットのレビュー会を実施しています。これはその前の週で障害、もしくは障害につながりそうだった事象をお互いに共有し、原因や対策の議論をする場です。「こういう感じでバグが入りそうになって危なかったよー」という話をエンジニアチームで共有知としていくことで、チームとしての学びを作っていこうという会になります。また、ヒヤリハットを記録していくことで、定量的な分析もできるようになり、ハマりポイントが客観的にわかってくるようになります。障害が起きた後だけではなく、障害につながりそうだったものもカジュアルに吐き出せる場を作ることがポイントなのではないかなと考えています。
＝＝＝
開発現場はそれぞれのプロダクトが抱えるさまざまな制約条件によって最適な開発サイクルがあると思います。おそらくMNTSQ社の開発フローにも改善の余地は多々あるかと思います。スタートアップにとって開発スピードは命だと思うので、Enterprise向けであっても可能な限り開発スピード、イテレーションを回せるように開発サイクルを設計するというのはとても重要なことかと思っています。
We are hiring!
最後に若干宣伝ぽくなりますが、MNTSQ社では開発のプロジェクトマネージャ、ソフトウェアエンジニア、SREをそれぞれ若干名ずつ募集しております。業界に大きなインパクトを与えられるプロダクト作りに携わりたい方はぜひともこちらのページから連絡いただくか、安野にDMください！