事業を加速させるために向き合う、食べチョクの開発戦略 #食べチョクチーム
みなさんこんにちは。株式会社ビビッドガーデンのCTOに就任しました、西尾です。
私は2018年3月に、2人目の社員としてビビッドガーデンに入社しました。
はじめは初期フェーズのエンジニアとして、少人数のチームで自分自身がひたすら手を動かし開発を行っていました。しかしそれだけでは、ビジネスの成長速度に開発が追いつかなくなりました。
事業のフェーズごとに、最速で最大の成果を出していくためにどうすればよいか。そのために技術と組織の両面で向き合っていく必要があることを学びました。
今回はこれまで食べチョクと私自身が向き合ってきた技術と組織課題、そしてこれからの開発戦略について書いてみます。
事業を成長させるために、これまで乗り越えてきたこと
私が入社した当初、ビビッドガーデンにはフルタイムのエンジニアが一人もいませんでした。この頃はチームも小さく、プロダクトも立ち上げたばかりだったので作る機能が明確でした。少ないメンバーで時間、資金という制限もあるなか、いかに早く開発できるかが重要なフェーズでした。
下図は食べチョク本体のGitHubのコントリビューショングラフです。この頃はチームでパフォーマンスを出していくというよりは、個々の力に頼る形でサービス開発を行っていました。
転機が訪れたのは2020年の3月頃。巣ごもり需要により、食べチョクへのアクセスが急増し、それにともない問題も続々と発生しました。一例は以下の通りです。
1ヶ月分の注文が1日で入るほど注文が急増し、カスタマーサクセスがパンクした。そのため、急いで足りない機能改善が必要になった。
テレビに取り上げられる機会も増え、突発的なアクセスにも耐えられるシステムに急遽作りかえる必要がでてきた。
大量の注文をさばけるシステムになっていなかったため生産者さんに負担がかかってしまった。注文と配送まわりの改善をいそいで行う必要がでてきた。
やりたいこと、やらなければならないことがいままで以上に増え、エンジニア数名の開発体制だと、ビジネスの成長にプロダクト開発が追いついていけない状態になりました。事業のスピードを上げるために、開発体制の強化が必要でした。
そこからは採用にも力をいれ、毎月のように新しいエンジニアが増え、今は40人規模まで仲間が増えました。
組織が大きくなるにつれ、別の問題もでてきました。メンバーが増えても開発がスケールしづらくなったのです。その頃発生していた課題は何か。一例をあげてみます。
施策がチームではなく個人に張り付く状態であった。最優先最速で作りたい機能がリリースできるかはその領域に詳しい個人に依存し、チームとしてサポートできるようにはなっていなかった。個人のパフォーマンスが事業スピードに影響するだけでなく、大きなプレッシャーが1人のエンジニアにのしかかる状態だった
開発チームは1つしか存在しなかった。スクラムイベントはメンバー増加とともにのび、朝会で話を聞いても隣の人が何をやっているかはよくわからない。レトロスペクティブも時間はかかるが、メンバーが多く時間も限られるため深い議論はできずチーム運営の改善が進まなかった
誰かが施策や設計を考え、それをエンジニアが単純にデリバリーするだけでは、考える人がボトルネックになりスピードが上がらない。チームごとにミッションを定め、チームで施策の検討と仮説検証をまわし、結果(アウトプット)ではなく成果(アウトカム)をみながら開発を進められるように作り替える必要があった
エンジニアが単に集まり、無策のまま気合でプロダクトを作っていくのは限界があります。少人数のときの開発スタイルもあらためていく必要がありました。
メンバーが増えてもスケールする開発組織とは何か。マネージャー陣と議論しながら課題解決にむけて動き、少しずつではありますがメンバーが増えてもまわりだす体制が作れていきました。
事業として成果を出すために、次は技術負債に向き合う
ここ1、2年、事業を加速させるためのボトルネックは、スケールする開発組織が作れていないことでした。そこが少しずつ解消しつつある今、次に取り組むのは技術課題の解消です。
食べチョクは今まで、機能開発が9割、残り1割ほどが技術改善という割合で開発を続けていました。40人規模でひたすら機能を追加しつづけた結果、どうなったのか。下図は食べチョク本体のコードサイズです。
食べチョク本体はモノリシックなアプリケーションです。Ruby on RailsとReactで作られており、その内部は複雑な密結合となっています。開発が進むにつれて、コードベースがどんどん大きくなってきています。嫌な予感がします。
大きく複雑なコードベースで開発をするとどうなるのか。直近1年以内に発生した問題を振り返ってみます。
会員登録のロジックを変えてデプロイをしたら、注文ができなくなった。本番リリース後にアラートがあがり、急いで切り戻しを行った。会員登録と注文は別の機能だと思ったので、手動テストはしていなかった。シナリオレベルの自動テストは足りず、リリース前にCIで気がつくことはできなかった
管理画面のサイドバーを直したら、いつのまにか注文画面と連絡機能が壊れていた。まさかそんなところが壊れるとは思わなかった。フロントエンドの自動テストはほとんどないので、リリースしても気がつかずに顧客に指摘されて問題が発覚した
一部コンポーネントのCSSを書き換えたら、全く関係ない画面のデザインが壊れて操作できない状態だった。見た目の不具合だったためアラートでも気がつかず、本番リリースしてからしばらくして問題が発覚した
システムは複雑に絡み合っており、手を入れると予想外のところが壊れがちです。
プロダクトを隅々まで把握していれば開発はできますが、認知負荷が高すぎます。多くのメンバーはここ1、2年以内にジョインしたばかりで、全体像を把握できている方は少ないです。これではなかなか開発速度があがりません。
食べチョクでは、本番で発生してしまった不具合を振り返るポストモーテムの活動を1年以上つづけています。この会では、毎回おなじみの声があがります。
「RSpec/Jestがもう少しあればよかった」「E2Eテストがあれば気がつけていた」「Visual Regression Testが運用にのっていれば気がつけたかも知れない」。
たしかに自動テストが足りないという問題もありますが、それだけでなく影響範囲の把握しづらい大きなプロダクトで認知負荷が高いこと、スピード優先で開発してきた見通しの悪い複雑なコードのツケがまわってきていると思っています。
開発者はいま、おそるおそるプロダクトに手を入れています。事業を成長させるためには、新しい機能追加と改善をすばやいサイクルで作っていく必要があります。しかし、手を入れた際の影響範囲が読めないので関連するコードを端から端まで読み、手動で動作確認を繰り返しながらなんとか開発を進めています。
この開発のしづらさが、ビジネスのスピードを加速させる上で今ボトルネックになっています。課題解消のために、次のような取り組みが必要だと考えています。
チームごとにデリバリーしやすいようなアーキテクチャに変えていく
テストカバレッジを向上させ、壊れたことにリリース前に気がつけるようにする
見通しの悪いコードをなおしつつ、デッドコードを削減する
最新のライブラリへのアップデートと、古いライブラリからの移行をする
今回はウェブアプリケーションの課題をあげましたが、モバイルアプリ、デザイン、インフラの観点でも技術的に解決しなければならない課題は、まだまだたくさんあります。
技術的な改善を、チームが自信をもって行う体制と仕組み作りも行わなければなりません。
新規開発が最優先、技術改善は一部のエンジニアが開発の片手間に120%の力を発揮して作業に取り組むのでは改善はすすみませんし、メンバーは疲弊してしまいます。
組織・チームとして技術課題に向き合い、取り組めるよう整備をする必要があります。
このような状態を改善するべく、食べチョクではプロダクトロードマップとは別に技術ロードマップも定め、改善に取り組めるよう体制をととのえはじめています。いままでは機能開発が9割、残り1割が技術改善でしたが、今後は技術改善の割合は4割程度までは引き上げる予定です。
事業を加速させるために、今なにが必要か
食べチョクの開発チームは、これから技術負債の解消にも向き合います。ただ、負債の解消が目的になってはいけないと思っています。
技術改善を始めると、ひたすらコードベースを綺麗にしよう、なんなら全部リニューアルして0ベースで構築しよう、ついでに新しい技術的なチャレンジもしようという気持ちがわいてしまいがちだと思っています。
事業のことを気にせず、時間の制限もなくて、予算の心配もしなくてよいのなら、私もその選択を取ると思います。しかし、スタートアップとして、ビジネスとして取り組んでいる以上、私たちが一番大事にしないといけないことは常に事業のスピードを加速させることです。コードを綺麗にすること、新しい技術を使うことはあくまで手段だと捉えています。
事業としてできるだけはやく、大きな成果を出すためにはどうすれば良いか。
ビビッドガーデンでは、結果（アウトプット）ではなく、成果（アウトカム）を重視した事業運営・プロダクト開発を心がけています。今月はあたらしい機能をN件リリースした（アウトプット）ではなく、KPIをN％改善した（アウトカム）を重視します。
これは技術改善も同じです。
今どこに手を入れれば事業が加速するのか、どこに投資すべきか、改善後のアウトカムは何なのか。事業成長のためにデリバリーの速度を上げることが目的なら、プロダクトのデプロイ頻度は上がり、変更のリードタイムが下がっていきます。見通しの良いコードに書き換え開発しやすくなれば、デプロイ後の本番障害率が下がっていきます。
ビビッドガーデンではFour Key Metricsを指標として使い始めていて、技術負債の改善によりこの数字を向上させていく予定です。
ビビッドガーデンはこれからも新しい施策にチャレンジしつつ、技術改善の比率も上げていきます。プロダクトを成長させるために何に取り組むのか、事業・組織・技術そして経営の面で向き合う必要があります。今どこに注力すべきかを見定め、取り組みを推進しつつチームで成果を出す、それが今の私には求められています。
経営陣やチームメンバーとともに良いプロダクトが作れるよう、そして組織の成果を最大化できるよう、これから尽力いたします。
この記事が気に入ったらサポートをしてみませんか？