デプロイしたくなるアーキテクチャで、チームをときめかせる　justInCase小笠原氏がチームにかけた魔法

アーキテクチャでチームに魔法をかける！

小笠原寛明氏（以下、小笠原）：今日は私たちが、こんまりさん（近藤麻理恵氏）みたいに、アーキテクチャでチームに魔法をかけた話をします。

まずjustInCaseという会社についてなんですけど、我々は保険会社です。

私たちのミッションは保険を使って社会をActiveにすることです。

誰でも必要な保険にいつでも入れるように、「保険API」というサービスを提供しています。

例えば、みなさんの管轄しているWebサービスに保険の加入のような機能を入れたいときに、たった数行コードを追加するだけで、このように保険の加入が実装できます。

ただ、私たちのバックエンドには深刻な問題がありました。ぜんぜんときめかないんです。どういうことか？

去年の夏に私がジョインした段階で、まず保険契約に関するコードは3つのリポジトリに分散していて、それらが相互に参照しあっているせいで、テストはデプロイしないと動かせない。

しかもCIのフローが整備されていなかったせいで、マスターのバージョンが本当にリソースとして反映されているのか、ぜんぜんわからない。

こんな調子だったので、キャッチアップにものすごく時間がかかり、結果、去年の秋にリリースする予定だった保険商品第2号は、リリースが無期限の延期となってしまっています。

思わずテストを書きたくなるようなアーキテクチャとは

小笠原：そこで私たちは、アーキテクチャを片づけることにしました。これが片づけたあとのアーキテクチャです。

私たちが片づけたポイントは2つ。「テストを書きたくなるアーキテクチャ」、それから「デプロイがしたくなるアーキテクチャ」です。

このアーキテクチャを書くためのアドバイスは、みなさんが知っているあの人からもらいました。誰でしょう？　正解は……ジェフ・ベゾスです。

ベゾスさんは2002年にこんなことを言ったことがあります。

「すべてのサービスはインターフェースを通して公開してください。さもないと、クビです」。

私たちはクビにされたくなかったので、まずこれまでの通信を見直しました。APIを経由していても、環境によって名前がぜんぜん違ったり、もしくは、APIを経由しないでコンテナを直接起動していたりしていました。

これを私たちはAWS Cloud Mapを使って片づけました。

どの環境でも、ローカルと同じようにHTTPで通信でき、しかも依存するとき、参照するときの名前も変わりません。

それから、認証も見直しました。テストのたびにログイン・ログアウトをしていたのでは、ぜんぜんテストを書きたくならないと思うんです。

私たちはAmazon API Gatewayのカスタムオーソライザーを使って、これを解決しました。Amazon ECSやAWS Lambdaを問わず、すべての外部からの通信はAmazon API Gatewayのカスタムオーソライザーでトークンを検証してから行っています。

だから、例えば私たちのAmazon ECSのソースコードには、アクセストークンを検証するような仕組みは一切入っていません。結果、ローカルでも認証なしですぐにテストができます。

新しくジョインしたメンバーが、すぐにパフォーマンスを発揮できる環境に

小笠原：こうやって片づけたことによって、チームにも変化がありました。

まず、アプリケーションエンジニアを、年始からこの6月で新たに6名採用しました。しかもプルリクのマージまでの日数も、3日短縮できました。

それからデプロイも片づけました。これまでAWS CloudFormationで管理はしていたものの、どんな状態がデプロイされているのかまったくわからなかった。スタック間の依存性を大幅に見直したことによって、AWS CloudFormationをまるごとCIに乗せることができました。

よかったこととしては、タグをPushするだけで、AWS CloudFormationの使い方がわかっていないエンジニアでも、テスト環境にリソースをまるごとデプロイできるようになりました。これはデプロイしたくなりますよね。

実際、効果がありました。

例えば直近3ヶ月のCircle CIを見てみたところ、デプロイ回数が平均1日10回でした。

こうした片づけをしたことによって、私たちのチームに魔法がかかりました。

おさらいです。メンバーが半年で3倍になり、プルリクのマージ期間が3日短縮、デプロイの回数が1日10回以上。

これにより、1ヶ月あたりの機能開発の速度が12.5倍になりました。

私たちは本番環境に月91本のリリースをしています。しかも、既存のメンバーががんばったわけではなくて、新しくジョインしたメンバーがパフォーマンスを出してくれました。

振り返ります。私たちはアーキテクチャを片づけました。

そのおかげでメンバーがテストを書きたくなり、デプロイをしたくなりました。

結果として、チームをときめかせることができました！

（会場拍手）

以上、このアーキテクチャを作るにあたって、チームのみなさまとAWSの協力していただいていたみなさま、オーディエンスのみなさま、ありがとうございました。

アーキテクチャを作り変える絶好のタイミングだった

司会者：小笠原さん、ありがとうございました。

（会場拍手）

では1分間のQ&Aにいきたいと思います。審査員のみなさん、なにかご質問がある方いらっしゃいますでしょうか？

大竹雅登氏（以下、大竹）：ありがとうございます。エンジニアだったら、そうやって時間を投資して環境を整備することに合理性を見いだせると思うんですけど、これまでできていなかったということは、それに有意性を見出していない環境があったんじゃないかなと思います。ご自身はそれを推進していくために、どんな工夫をしたのかをお聞きしたいです。

小笠原：私はかなりいい時期にジョインしたと思っています。商品第1号のリリースはこれまで別の人間がやっていたんですけど、MVPを早く作らなければいけなかったということで、インフラや人に強く依存したコードになっていたのは仕方のないことかなと思っています。

私はチームがスケールしていくタイミングで入ったので、こうやってアーキテクチャを作り変えていくのは、ある意味で当然の流れだったのかなと理解をしています。

大竹：わかりました。ありがとうございます。

司会者：ありがとうございます。では、みなさま。小笠原さんにもう一度大きな拍手をお願いいたします。小笠原さん、ありがとうございました。

（会場拍手）