ビジネス貢献するためのエンジニアリングの話をデブサミでしてきた #devsumi
Nintendo switchの初期不良を引き当てたので、ゼルダをやるために開けておいた予定がなにもすることなくなってしまったのでブログを書いた。私のswitchは今頃京都にあるでしょう。
Developers Summit 2017 でコンテンツ委員しつつ登壇もしてきた
もともとは、デブサミオーガナイザの鍋島さんからコンテンツ委員としてお声がけ頂き、今回はコンテンツ委員という立場でデブサミに関わっていました。 そのため、コンテンツ委員が登壇とか自作自演感甚だしいので自分が登壇するつもりはまったくなかったのですが、GuildWorks -ギルドワークス-の市谷さんから越境をテーマに株式会社ヴァル研究所の新井さんと自分の3人でやりませんかとお誘いを受け、以下で登壇することに。
「新規事業が対峙する現実からエンジニアリングを俯瞰する」
www.slideshare.net
新規事業が対峙する現実というものを、
- ビジネスモデル
- ビジネスフェーズ
- ビジネス仮説検証プロセス
- 予算計画のリズム
として、そこからエンジニアリングを俯瞰して見てみるという構成になっております。 基本的に以前書いたブログ プロダクト開発を内製化やアジャイル化する際のどこからはじめるかの勘所の話 #postudy - @i2key のBlog、新規事業のグロース期を支えるエンジニアリングについて - @i2key のBlogの焼き直しに近いイメージになります。簡単にスライドの補足を以下に書いていきます。
リーンスタートアップとスクラムの全体像
新規事業における顧客開発プロセスやリーンスタートアップの仮説検証サイクル(BMLループ)、またスクラム開発をひとつにまとめるとこのようになります。一旦、ビジネスがどういうフェーズで進んでいて、そのために自分たちのエンジニアリングはどう関わるのかというポイントで全体感を頭に入れておくと見通しが良くなると思います。結局はプロダクトバックログ（PBL）に入ってくるものの源流はビジネスフェーズにおける仮説検証内容になるので、そこからエンジニアリングが見えるようになるとエンジニア側から提案が出来るようになったりします。例えば、GitFlowでやっていたが、GithubFlowに変えたい。だからエンジニア工数を一部そっちの改善に割きたい。とビジネス側に提案したとしても意味不明すぎて議論にならないと思いますが、現在、Releaseブランチの運用において、複数の機能追加が合流してからリリースする流れになっており、他の機能追加の実装速度に引っ張られて他の機能もリリース出来ない状況になっている。学びに対するリードタイムが増えているため、個別に出来上がったタイミングでリリースできるようにしていき、学びに対するリードタイムを最小化したい。と提案してみるとか。そこら辺については、リソース効率とフロー効率の話で簡単に言及いたします。
ビジネスモデルからエンジニアリングを俯瞰する
いろいろなビジネスモデルがあるなかで、それらのパターンを網羅して理解するにこしたことないのですが、エンジニアとして一番簡単な方法としては、どこで売上が発生しているかを見極めることだと考えています。
- エンジニアの書いたコード上で売上がたつパターン
- エンジニアの書いたコード上以外で売上がたつパターン
エンジニアの書いたコード上で売上がたつパターン
ここでは成果課金広告モデルを例としてあげています。例えば旅行予約サイトで、ユーザーが宿の予約をとると、クライアントの宿主様から予約に応じて広告費が支払われるようなモデルです。これを画面遷移レベルで見てみると、サービスのトップ画面に流入したユーザが、検索条件入力→検索結果の一覧画面→詳細画面へと進んでいき、最後に予約ボタンを押すような流れになるかと思います。更にコードレベルで見てみると、最終的には、if(isBooked)条件内の処理が実行されることで予約が成立し、そこで売上が発生することになります。要するにif(isBooked)ロジック内に流れてくるユーザ数を最大化すること＝画面のUI改善つまりはコード改善そのものがファネル通過率の向上、CVRの向上＝売上の向上につながる構造になっています。
整理すると、エンジニアによるプロダクト改善が売上目標に直接寄与するため、エンジニアがこのサービスの成長のエンジンになりやすいです。そして、エンジニアのビジネス貢献が可視化しやすいということは、数値目標を持ったプロダクトチームがじゃんじゃん改善サイクルを回すと売上に貢献できるという良いサイクルがつくりやすいです。言い換えると、アジャイルとか超導入しやすい座組（結果が売上で出る）になります。また、サービスの開発を外注依存のような組織が内製化をはじめる場合は、こういうビジネスモデルのものから着手していくと成果が出やすい部分になります。 キラキラして見えるようなエンジニア文化がある会社のビジネスモデルを見てみると、こういうモデルのパターンが多いように感じます。エンジニアが競争力直結なのでそりゃエンジニアの待遇がよくなるはず。逆に営業が競争力直結なビジネスなのであれば、営業が最も働きやすい構造になるかと思います。
エンジニアの書いたコード上以外で売上がたつパターン
ここでは純広告モデルを例としてあげています。例えば、広告枠をアプリとして提供しているけれどもあくまで枠（及び期間）の固定金額でユーザーのコンバージョンの有無に関係なくクライアントにお支払いただくようなものになります。例としてあえて、前述と同じマッチングモデルで説明しているため若干苦しい部分はありますがご了承ください。このモデルの場合、画面遷移的に、サービストップ画面に流入したユーザが最終的に詳細画面に到達し、予約のようなコンバージョン行動を取ったとしても売上は発生しません。クライアントからは出広料として既に固定額でお金をお支い頂いているからです。そのため、コードレベルでみても、if(isBooked)条件内の処理が実行されたとしても売上は発生しません。ここが「エンジニアの書いたコード以外で売上がたつ」と表現している理由になります。つまりは、UI改善等のプロダクト改善をエンジニアリングで行っても売上には数値として効果が直結はしない構造になっています。
とは言え、エンジニアリングが何も貢献していないのかというと、そうではありません。営業が売る場合の顧客単価あげる（クロスセルやアップセル）ための商品開発を行い貢献することが出来ます。しかしながら、ここらへんの貢献についてエンジニアがビジネス貢献をうまく説明出来ない、もしくはビジネス側が理解してくれないと、関係性が歪んでいきエンジニアはQCD目標のみに極端にフォーカスされていく場合があります。
エンジニアのビジネス貢献が可視化しにくいとどうなるかというと、トラブルだけが目立つようになります。そして、できて当たり前（減点主義）のパラダイムになっていき、エンジニアはコスト削減や生産性向上のようなビジネス指標から程遠い目標設定になります。結果的に、QCDSの制約の雁字搦めになるので、エンジニア側は壁を作りディフェンシブになりだします。本来、俊敏に仮説検証回したい目的に反して、組織がスローダウンしていくことになります。放置していると、社内なのに受発注の関係性になってしまいます。
そうならないために、ビジネス側・エンジニア側が共通の目標を持ち、それぞれの貢献が可視化できるようにする必要あがあります。そこでポイントなのはその目標に対して、それぞれが結果に影響を与えられるレベルで管理することです。エンジニアリングで直接影響を与えられるビジネス指標は何かをビジネス側と一緒に検討し合意形成していくことになるかと思います。いわゆるKPIツリーやOKR等がそこらへんに当たるかと思います。
ビジネスフェーズからエンジニアリングを俯瞰する
ここでは、ビジネスフェーズからエンジニアリングを俯瞰します。フェーズと言っているのは顧客開発プロセスでいうところの、顧客発見→顧客実証→顧客開拓→組織構築、ランニングリーンでいうところの、ProblemSolutionFit→ProductMarketFir→Scalingをさしています。
顧客発見フェーズ（Problem Solution Fit目指す）
深い課題を抱えた顧客はいるか、その課題の解決策は妥当か、その結果、独自の価値提供が出来るかというポイントで検証していくことになります。本当のところは細かいプロセスがありますが、すごくざっくり言うと、ビジネス指標としての例としては、継続率を見たりします。継続しているということは、このサービスは顧客の課題を解決し続けているから顧客はこのサービスを使い続けるということが出来るからです。ここでターゲットになるユーザーは基本的にアーリーアダプターなので、ある程度のことは許容してくれるので、当たり前品質や性能品質にはこだわらず、魅力的な品質のみに特化したMVP実装をしていくことになります。MVPも検証したい仮説に応じて必要最低限のスコープが変わっていくことがポイントです。ここでの必要最低限は、「課題解決可能かどうかを検証するための必要最低限」になります。
顧客実証フェーズ（Product Market Fit目指す）
このフェーズでは、プロダクトがマーケットにフィットするかを検証することになります。言い換えると、顧客は本当に買ってくれるのか、コスト構造に無理が無いかを見ていくことになります。具体的には、顧客獲得コスト（CAC: customer acquisition cost）＜顧客生涯価値（LTV: Life time value）が成立すること。この際のエンジニアリングとして求められる品質レベルは、最低限の売れる状態。MVPの定義の必要最低限が今度は「売れる」にかかります。そのため、最低限の性能品質、と当たり前品質が必要になります。
顧客開拓（Scaling）
顧客開拓フェーズでは、今までアーリーアダプター対象だった製品を一般のユーザまで広げていくことになります。そのため、今までより広いユーザセグメントに売れることが要求されます。競合よりこの製品を選んでもらう必要があるので、アップセルやクロスセルに向けた性能品質や当たり前品質が求められていきます。
また、このフェーズになると既にユーザが多くついていることになりますが、そのような状況下において製品をつかって仮説検証を継続することになるため、インフラ要件としては、既存ユーザに影響を与えずに仮説検証が出来るような仕組みが必要になってきます。具体的に言い換えると、既存ユーザと新規ユーザを分けて検証するためのコホート分析の仕組みや、セグメントに応じて機能を出し分けるようなA/BテストやFeatureFlagの運用等です。そして、それらを支えるビルド、デプロイ、モニタリングのエコシステムになるかと思います。
いわゆるDevOps系のプラクティスですね。
ビジネスフェーズにおけるエンジニア像
前述の各フェーズを乗り越えていくのに際して、上記のようなエンジニア像が見えてきます。顧客発見フェーズにおいては、エンジニアといえどもソリューション片手にユーザインタビューに行くこともあります。エンジニアという枠に縛られずにマルチロールで動けるような人材がパフォーマンスを発揮しやすいと思います。顧客実証フェーズにおいては、ビジネス目標を達成するために、自ら手段を考え、その結果必要であればサーバのアルゴリズムを弄るし、フロントへの改善が必要であればiOSでもAndroidでも弄るようなフルスタックな人材が必要になるかと思います。なんせ、領域特化した専門家だけを集めるような余裕はまだないので。余談ですが、ここらへんはなぜフルスタックが良いのかについて別途スライド上の別のページでも取り上げていますが、待ちのムダや引き継ぎによるムダが省けて結果的にフロー効率がよくなる（顧客からのフィードバックを得るまでのリードタイムが少なくなる）という効果もあったりします。
話をもどしますと、つぎの顧客開拓フェーズにおいては、広げていくカスタマーセグメントに応じて必要な性能要件や品質要件が上がっていきます。仮にtoC商品をtoB商品へのアップセル目的で上げていく場合、それ相応のセキュリティ要件が出てきたりもします。そのような場合には、やはり専門性を持ったエンジニアが必要になってきます。各分野のプロフェッショナルがそれぞれの目標を達成すべく貢献していくような構造になります。その中でも、特定領域の神のようなエンジニアも競争優位としても必要になると思います。
リソース効率とフロー効率について
エンジニア目線だけでいると、どうしても稼働率をベースに考えてしまいます。しかしながら対峙している新規事業においては、如何に早く顧客から学びを得るかがポイントになってきます。そうなってきたときに、「効率が良い」という言葉の意味を考えないといけません。
- 稼働率という意味で効率が良い（リソース効率）
- 顧客から学びを得るまでのリードタイムにおいて効率が良い（フロー効率）
- まとめて同時に複数のことはせずに一つの機能の実装のみをチームで行っている。場合によっては、仕事がなくて遊びが発生してしまう人もたまにいる。稼働率そいう側面だと効率が悪いが、リリースをして学びを得るという側面だとリードタイムは短く効率が良い。
顧客から早く学びを得るにはまずはリソース効率ではなくフロー効率を重視したほうが学びのない期間を作らずに済みます。
リソース効率からフロー効率に変える方法のひとつとして「マルチタスクをやめる」ことがあげられます。それを図解したものが以下になります。
これは極端な例ですが、A機能、B機能、C機能のすべての機能追加タスクがそれぞれ15人日かかる場合。同時進行するとすべてのリリースまでのリードタイムは3週間になります。逆に一つずつ終わらせていくと、A機能は1週間、B機能は2週間、C機能のみが3週間というリードタイムになります。AとCが仮に相関が強かった場合は、Aの結果を踏まえてCの開発をやめることも検討できます。このように、同時にやることで様々なムダが生まれていたりします。現実はこんなシンプルではないですが、「一個流し」を意識することでいろいろなムダが除けるので、リリース計画においてもビジネス視点を持つことは重要だったりします。
他にはペアプロとかもリソース効率ではなくフロー効率を上げに行くプラクティスだと認識しています。モブプログラミングなんて完全にフロー効率に振り切っている。重要なのは、二人で別々の機能の仕掛中在庫を作るのではなく二人で1つの在庫を早く出荷することに重きをおいていること。また、副次効果として、知識の流通が同時に行われるため、1機能について2人の仕様理解者が同時に生まれる。つまりは引き継ぎによるムダが減るという様々な効果があったりもします。
さいごに
基本的にスライドを見てもらえれば内容はわかるとは思いますが、補足部分をブログに記載させていただきました。 また、今回は貴重な機会を頂き、市谷さん、新井さん、鍋島さんありがとうございました。 登壇を誘って頂いた市谷さんがFouderをしているDevLoveというコミュニティは自分にとって大きな転換ポイントの一つで、かつて参加したHangarFlightというイベントの余りにもの厨二感に良い意味で感化され、絶対この場に発表者として帰ってくると誓い、その後のDevLove現場甲子園（東日本大会）と名を変えたイベントに登壇。そこでの内容を評価していただき現場甲子園の日本シリーズに登壇。そして、その内容をコピペしてデブサミ2015公募に応募。公募なぜか通る。偶然にベストスピーカー賞いただく。夏サミの登壇依頼いただく。スピーカーつながりとかでいろいろな人と知り合いになる。困ったときに助けてとお願いすると、色々教えてもらえるようになる。アウトプットするといろんな人がインプットくれるようになる。そんな中、デブサミ2017のコンテンツ委員の打診いただく。面白そうだからのっかる。こんな講演ききたいなあという思いの説明用にポエムをブログに書いてみる。そういう話してみませんかと今回の登壇の話へとつながる。登壇するために、適当なこと言えないので、いろいろな1次ソース文献を読み漁る。更に理解が深まる。という流れの最初の一歩目はDevLoveというコミュニティとの出会いにあったと思っています。自分はPapanda氏に越境をenergizeされたひとりです。まことに….感謝ッ…！！！
