
2025.02.06
ポンコツ期、孤独期、成果独り占め期を経て… サイボウズのプロマネが振り返る、マネージャーの成長の「4フェーズ」
Startup Architecture Of The Year 2019 #2-7 株式会社ジャストインケース(全1記事)
提供:アマゾン ウェブ サービス ジャパン株式会社
リンクをコピー
記事をブックマーク
小笠原寛明氏(以下、小笠原):今日は私たちが、こんまりさん(近藤麻理恵氏)みたいに、アーキテクチャでチームに魔法をかけた話をします。
まず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を早く作らなければいけなかったということで、インフラや人に強く依存したコードになっていたのは仕方のないことかなと思っています。
私はチームがスケールしていくタイミングで入ったので、こうやってアーキテクチャを作り変えていくのは、ある意味で当然の流れだったのかなと理解をしています。
大竹:わかりました。ありがとうございます。
司会者:ありがとうございます。では、みなさま。小笠原さんにもう一度大きな拍手をお願いいたします。小笠原さん、ありがとうございました。
(会場拍手)
アマゾン ウェブ サービス ジャパン株式会社
関連タグ:
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.03
「昔は富豪的プログラミングなんてできなかった」 21歳で「2ちゃんねる」を生んだひろゆき氏が語る開発の裏側
2025.02.03
手帳に書くだけで心が整うメンタルケアのコツ イライラ、モヤモヤ、落ち込んだ時の手帳の使い方
2025.02.04
日本企業にありがちな「生産性の低さ」の原因 メーカーの「ちょっとした改善」で勝負が決まる仕組みの落とし穴
PR | 2025.02.07
プロジェクトマネージャーは「無理ゲーを攻略するプレイヤー」 仕事を任せられない管理職のためのマネジメントの秘訣
2025.02.05
「納得しないと動けない部下」を変える3つのステップとは マネージャーの悩みを解消する会話のテクニック
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.01.30
2月の立春までにやっておきたい手帳術 「スケジュール管理」を超えた、理想や夢を現実にする手帳の使い方
2025.02.06
落合陽一氏や松尾豊氏の研究は社会に届いているか? ひろゆき氏が語るアカデミアの課題と展望
2025.02.05
エンジニアとして成功するための秘訣とは? ひろゆき氏が語る、自由な働き方を叶えるアプリ開発とキャリア戦略