新規事業のグロース期を支えるエンジニアリングについて
このブログは Recruit Engineers Advent Calendar 2016 - Adventar の12/7の記事になります。
はじめに
現在、新規事業開発部門にて、いくつかのチームの開発リーダーをしていまして、その中でチームの目標を決める中でグロースフェーズにおける開発チームの直近のやるべきことを洗い出したので、アドベントカレンダーのネタにさせていただきます。
前提として、本ポストで対象になる新規事業は下記の投稿における分類で言うと「エンジニアの書いたコード上で売上が立たないビジネスモデル」になります。そのため、エンジニアリングでKPIを向上させ売上に寄与するような一般的なグロースハッカー的な動き方についてはスコープ外です。詳しくは下記リンクをご一読ください。 i2key.hateblo.jp
現在のビジネスステージ
上記はAsh Maurya氏のRUNNING LEANとSteve Blank氏のSTARTUP MANUALにおけるビジネスフェーズを図にしたものになります。はじめは、MVPを作ってはぶっ壊し、捨てて、またMVPを作ってはぶっ壊しの繰り返しでProblem Solution Fit(PSF)前は過ごすかと思います。可能な限り作らないで検証できたほうがよいのでエンジニアもインタビューに行ったりもします。そして、PSF後あたりから、Product Market Fit(PMF)させるためのもう少し真面目（）な製品づくりが始まります。本ブログでのスコープ（赤い帯の部分）はPSF後、PMF目前もしくはその後のScaleフェーズにおける仮説検証を支えるエンジニアリングについて言及させていただきます。どうしてもPSF前のアーリーステージは作っては壊すの繰り返しなので、カウボーイスタイルになってしまっても仕方がない部分はあると思い。
上図は狩野モデルという品質モデルになります。狩野モデルでは魅力的品質、性能品質、当たり前品質に分けてそれぞれの品質特性を説明しています。PSF前のアーリーステージでは、顧客が存在すること、その顧客が深い課題を抱えていること、そして、それを解決することで得られる価値（ユニークバリュー・プロポジション（UVP））が実証できればよいので、基本的にアーリーアダプターを狙って検証しにいきます。アーリーアダプターは、当たり前品質は別になくても気にしないセグメント（脳内で補完してくれる）なので、UVPの実証にフォーカスします。
しかしながら、次のフェーズのPMFを狙うには、そもそも商品が売れなくてはならないため、当たり前品質も必要になってきます。魅力的品質のみに特化したMVPだけで売れるなんて幻想です。サービスがうじゃうじゃ出ている昨今において、シンプルなMVPだけで済むなんてそんな簡単な話ではありません。MVPが何に対する「必要最小限」なのかは検証対象によって変わることを理解するのが大事です。仮に、「本当に売れるか」を検証したい場合は、競合の機能も当たり前品質になってしまっているのであれば、必要になります。PMFでLTV(Life time value) > CAC(Customer Acquisition Cost)の検証をするために、価格設定の検証をするのであれば、まずは買ってもらわないといけないので同様に当たり前品質が必要になります。各フェーズ毎に検証したいことに応じた機能設計が必要です。 そして、ここらへんからチームメンバの人数も増えるし、ユーザー数もある程度増えてきており、今までのように簡単に機能追加やリリースができなくなってきます。しかしながら、仮説検証はまだまだ続くので、その速度をスローダウンさせることなく、むしろ高速化させていかねばなりません。
グロース期を支えるエンジニアリングの目指すべき状態
前述の状況をまとめると、このフェーズでは、当たり前品質を確保しつつ、ユーザーが既にいる状態で売り物で仮説検証をしていくことになります。そのため、エンジニアリングとしては、既存のユーザーベースを壊すことなく安全に仮説検証が出来るしくみを作ることが重要です。そしてトライするスピードをスローダウンさせることなく更なる仮説検証の高速化を目指すことになります。（仮説検証フェーズにおいて、どれだけ効率よく学べるかが最重要であるためです。）そこで、単純化するための仮説検証の速度と質という2つの軸に分けて考えます。
- 仮説検証の速度を最大化
- 手っ取り早いのが、デプロイ回数/日をチームの目標におき、それを高速で回せる状態に持っていく。しかしながら2週間に一回リリースなのであれば、10営業日に1回なのでデプロイ回数は0.1/日である。
- 仮説検証の質を最大化
- ニーズに合致していないものを高速で排出しても、高速うんこ製造機になるので、仮説の質を上げるためにエンジニアができる取り組みも行う。
- 既存のユーザーベースを壊すことなく安全に仮説検証の実験を行うための仕組みづくり。
仮説検証の速度を最大化
すごくラフですが以下のような開発プロセスのバリューストリームマッピングを例にします。LTはリードタイムを表しています。リードタイムとはプロセスが作業を受け付けてから、下流のプロセスに渡すまでの時間になります。PTはプロセスタイムで、作業者がひとつの作業項目を完了するのにかかる時間です。そして実際に価値が作り込まれているのがこのプロセスタイムになります。実際のところは[PT = Value Add Time(VAT) + ムダ ]であり、 本当に価値を作っている時間はその一部になります。そのため、前述のデプロイ回数/日を増やすのであれば、この図の赤い部分をまずは改善することになります。
デプロイ回数/日を目標におくと何がおきるか
- デプロイまでの赤い部分のリードタイムやプロセスタイムを減らしたくなる。VAT=0のプロセスは価値がないので消し去りたくなる。
- 最初はエンジニアリングでムダの部分を所々自動化する
- しかし技術でどうこうだけではすまなくなる
- プロセス改善することになる
- 複数の要件を同時に実装していくと、タスク切り替えのムダが発生することがわかり、バッチサイズ（このフローに流す作業のサイズ）を小さくすべきことに気づく
- インフラ担当とかアプリ担当とかの作業の引き継ぎにもムダがあることがわかる
- チーム間等の意思決定がボトルネックになる
- チーム内で担当を決めるのをやめて、なんでもやるほうが待ち時間によるムダがなくなり、はやいと感じ始める。
- 結果的にチーム外でも同じことがいえ、組織改善まで波及する
- そのために、付随してアーキテクチャの見直しまで発生する
- それに合わせて責任と権利の所在が変わる
- 継続的デリバリーの組織的な母体が出来上がる
以下はちょっと古いですが、以下が丁度Facebookがデイリーリリースに切り替わったころの周辺の各種プラクティスのマッピングになります。こういうものも参考にしてもよいと思います。結果的に、最近のDevOpsプラクティスとかぶるとは思いますが。
Facebook's Trunk Based Development (take 2) から引用
そして、以下が自分が担当しているチームでのやるべきことをリストアップしたものになります。これを元に、最上位のレイヤー（デプロイ回数）をチームの目標としています。箇条書きで醜くて申し訳ありませんが、そのままコピペしておきます。
仮説検証の速度の最大化（チーム目標：デプロイ回数/日）
- プロセスタイムの削減
- リードタイム削減
- 組織改善
- クロスファンクショナルチーム
- 部門間の引き継ぎのムダを省く
- 部門間の待ちのムダを省く
- フルスタックエンジニア
- チーム内の個人間の引き継ぎのムダを省く
- クロスファンクショナルチーム
- プロセス改善
- 大きなバッチサイズから小さなバッチサイズへ
- タスクを管理するのではなくペースを管理する
- カンバン、スクラム
- タスク切り替えのムダを省く
- リリースカレンダー
- WIP制限
- スコープボックスではなくタイムボックス
- プル型のタスク管理
- カンバン、スクラム
- タスクを管理するのではなくペースを管理する
- 自動化
- 直接顧客価値を作らない作業(Value add time = 0)の最小化
- 継続的インテグレーション
- テストコード維持（悪化させない）
- インフラコードを維持（悪化させない）
- デプロイ自動化
- 分析・集計自動化
- 各種マーケ施策の自動化
- マーケ担当者がエンジニアに依頼して、エンジニアが作業をするようなケース。同様の依頼が複数回発生したら運用を自動化する。
- 特定のセグメントに対して通知やメール送信をしたい。
- 特定のセグメントに対してキャンペーンコードを発行したい。
- 引き継ぎによるムダ/待ちによるムダの排除
- 営業担当者からの依頼のケースも同様
- マーケ担当者がエンジニアに依頼して、エンジニアが作業をするようなケース。同様の依頼が複数回発生したら運用を自動化する。
- 直接顧客価値を作らない作業(Value add time = 0)の最小化
- 大きなバッチサイズから小さなバッチサイズへ
- 組織改善
- 安定運用
- 未然防止
- セキュリティ
- システムモニタリング
- 自動復旧
- 事後対応
- トラブル対応フロー
- 障害レベルの切り分けロジック
- etc
- トラブル対応フロー
- 未然防止
仮説検証の質を最大化
前述のバリューストリームマップを同様に用いて説明します。仮説検証の質という観点で最も大事なのは、このプロセスのフローに投入する玉の質、つまりは仮説の質が良いことです。ニーズに合致していないものを高速で作れたとしてもゴミを生むだけで、しかもそれだけではなく、コードベースは肥大化していき機能が使われないどころか自分たちの生産性までも下げることになってしまいます。これはまさに余分な機能のムダになります。それを防ぐためにもエビデンスに基づく仮説構築の支援をエンジニアリングにて実施する必要があります。基本的には、各種分析基盤の実装です。また、各仮説検証の結果をパラレルで走っている検証の結果が混ざって濁らないような効果測定も必要です。
また、既存のユーザーベースを壊すことなく安全に仮説検証の実験を行うための仕組みづくりも必要です。具体的にはユーザーを任意のクエリや属性にてセグメントする仕組み、また、そのセグメントに対してリリース機能の出し分けをする仕組みが必要です。そしてそのセグメント毎に公開した機能単位で分析ができることが必要です。ここらへんの仕組みは最近ではSaaSを使えば大抵オールインワインで備わっています。これらの仕組みがある状況であれば、仮にリリース後に問題が起きた場合も、機能単位で切り戻しも可能になるため、欠陥によるムダ への対策にもなります。
以下に仮説検証の速度の最大化と同様に質に関するやるべきことの箇条書きをコピペしておきます。
仮説検証の質の最大化
- LEARNの質
- MEASUREの質
- 計測の基盤があること
- ダッシュボード
- ビジネス&システム
- BMLループの時間（学ぶまでのリードタイム）
- プロダクトバックログに起票されてから、検証されるまで
- BMLループの時間（学ぶまでのリードタイム）
- システム
- 各種システムパフォーマンス
- CPU/NETWORK/RESPONSE/etc
- ビルド時間
- 自動テスト時間
- デプロイ時間
- 各種システムパフォーマンス
- ビジネス
- ファネル分析
- 離脱率（or Churn Rate）
- P/S FITにおけるズレの側面
- ファネルに流すユーザの質に左右される
- エンジニアリングで改善可能な部分
- P/S FITにおけるズレの側面
- 離脱率（or Churn Rate）
- コホート分析
- カスタマーセグメント毎の各種数値
- 流入経路別の各種数値
- ノイズを排除し純粋にプロダクトの力を計測する
- 営業/マーケ獲得セグメント別の結果等
- ノイズを排除し純粋にプロダクトの力を計測する
- 流入経路別の各種数値
- リリースバージョン毎の各種数値
- 実装機能毎の各種数値
- カスタマーセグメント毎の各種数値
- Gross Revenue
- LTV/CACグラフ
- ユーザーセグメント毎のLTVとCACの関係性
- Churn rate
- その他各種KPI
- ファネル分析
- ビジネス&システム
- ダッシュボード
- 安全な検証環境
- 既存のユーザへの影響を最小化
- ユーザーをセグメントする機能
- ウェブコンソール上でSQLないしUIにて、特定の条件に関するユーザセグメントを作ることができる
- ユーザーをセグメントする機能
- Feature Flag
- ユーザーセグメントに対して機能の出し分けを可能にする
- Private Beta Test
- Dark Launch
- ユーザーセグメントに対して機能の出し分けを可能にする
- A/Bテスト基盤
- カナリヤテスト
- ブルーグリーンデプロイメント
- 既存のユーザへの影響を最小化
- 計測の基盤があること
- BUILDの質
まとめ
本ポストでは、便宜上バリューストリームマップの例で解説をしていましたが、本来は各チーム毎にバリューストリームマップを作成し、ボトルネックになっている部分を探し、解消することが大事です。例えば、ボトルネックじゃない部分をいくら解消しようが実は全体的には効果がないこともあります。そしてボトルネック解消には時には技術以外での解決策も必要であったりします。個人的には、TPSや制約理論を学ぶのが最も効果があると思います。そして、それらを意識しながら、下記を実現していくことになると思います。
- 当たり前品質を確保しつつ、ユーザーが既にいる状態で売り物で仮説検証をしていくため、エンジニアリングとしては、既存のユーザーベースを壊すことなく安全に仮説検証が出来るしくみを作ること
- トライするスピードをスローダウンさせることなく更なる仮説検証の高速化を目指すこと
以上です。