プロダクト開発を内製化やアジャイル化する際のどこからはじめるかの勘所の話 #postudy

本ポストは特に私が所属する組織の見解ではなく、私が今までの経験&自分がチームを作るときにチームの目標を考えたり、組織内にアジャイルを導入したり、組織内での開発チームの位置づけをどうするかなどなどを考えるときに意識していることですのであしからず。

内製化や、アジャイル化のビジネス上の効果を得やすい部分をビジネスモデルから考える

昨日、プロダクトオーナー祭り2016で「DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ」というセッションでパネルディスカッションに登壇させていただきました。 postudy.doorkeeper.jp そこで内製化や、アジャイル化はどの部分からやるのがよいかみたいな話の流れかなにかで、「System of Engagementでなおかつ成果課金のようなエンジニアの書いたコード上で売上が立つモデルだとエンジニアリングが直接売上に寄与しやすいためビジネス価値を生みやすく座組が作りやすいです。仮にはじめての内製化やアジャイル化みたいなことをするのであれば、そういうところから始めるとよいです。」みたいな話を軽くしたのですが、あまりにも軽くしすぎたので補足をブログにしてきます。

System of Engagement(SoE) と System of Record(SoR)

ここらへんの議論については、最近、Ito Naoya さんがSoEとSoRの話をしてくださっていて、共通認識として広まってきてる感があります。掻い摘むと、顧客とのエンゲージメントを高めるためのシステム(SoE)と、記録のためのシステム、いわゆる基幹系システム(SoR)にわかれ、それぞれに応じて、適切なマネジメントスタイル、組織、方法論、技術選定、開発プロセスを取るべきであるという話になります。SoEかSoRかというわけではなく、それぞれの要素のグラデーションでバランスよく考えましょうという話ですね。

https://speakerdeck.com/naoya/system-of-record-to-system-of-engagement#5

その上で、SoEは仮説検証型、アジャイル型寄り。

しかしながら、もう一歩踏み込んで、更にビジネスモデルという切り口で見てみると、更に霧がはれていきます。

エンジニアの書いたコード上で売上が発生するようなビジネスモデル

例えば、SoEの中にトランザクション(従量課金モデル)の要素がある場合は、その部分から仮説検証型、アジャイル開発型としてトライすると良いと思います。 簡単に言い換えると、プロダクト上でユーザーが課金するもしくは、プロダクト上のユーザの行動によってクライアントからお金が支払われるようなモデルです。もっと、極端に言い換えると、エンジニアの書いたコード上でユーザーのコンバージョンが発生してお金が儲かるモデルです。この場合は、エンジニアが成長のエンジンになりやすいケースです。だってエンジニアのコード(UI、パフォーマンス、アルゴリズム等)が良ければ良いほどコンバージョンを生み、売上があがっていくので。 つまり、そのようなビジネスモデルのケースでは、数値責任をもったチームが仮説検証サイクルを意識してアジャイルに回すほうが売上貢献しやすいです。言い換えると、エンジニアのコードの改善が売上に直結寄与しやすい。これがビジネス価値をエンジニアが作り出していると言いやすく、説明責任を果たしやすいです。

この領域は、たとえば、ソシャゲとか、デーティングとか、ECとか、toC課金のモデルの多くであり、ネット系とかウェブ系と言われている部分の多くです。また、toBとかでいうと成果課金広告とか、アドテクとか、SaaSとかがそれになりますね。SaaSの場合は、チャーンレートが重要になってきます。または裏返しで継続率ですね。それが毎月の売上に直結します。

500StartupsのDaveが提唱しているAARRRモデルがありますがこれが一番イメージしやすいです。

f:id:i2key:20161127232130p:plain

これは勝手に私が書き換えたものですが、Churn(水漏れ)も追加しています。広告等でユーザーを獲得してきて、一定量がアクティベーションせずに離脱して、残りが継続利用してくれて、でもまた徐々に下に漏れていって、継続利用してくれるとどんどん売上が立っていってみたいな流れです。つまり、ここの水漏れをエンジニアリングで防ぐことでも、売上に直結させられます。本質的な継続率は、顧客の課題を解決し続けている必要があるのでそもそものサービスの価値の議論にはなるかと思いますが。まあ、つまりは、改善サイクル(リリースまでのリードタイム)が高速化するとビジネス価値を生みやすいということです。かつて言われていたグロースハッカーがまさに活躍する領域です。

ここからは妄想ですが、そのため、成果課金・従量課金・月額課金モデル等をベースとするエンジニアの書いたコードの上で売上が立つウェブ系なスタートアップ界隈やソシャゲ界隈などなどはアジャイルを採用することが多く、あわせてエンジニアの労働環境も良くしやすく、オフィスもエンジニア最適化されたり、エンジニアは好きなディスプレイ、マシン、キーボード、椅子で自由に働いている。そして給料も良いのでは。エンジニア達こそが競争力の源泉になるので。という構造になっている(なりやすい)かと思います。妄想ですが。

エンジニアの書いたコード上で売上が立たないビジネスモデル

それに対してSoEの中でも、逆に、エンジニアのコード上で売上が発生しないモデル。 例えば、営業が商品(製品、純広告、etc)を売ってその商談で売上が立つようなモデルとかだと、ある意味、成長のエンジンはエンジニアではなく営業力になる(スケーラブルかどうかの議論はおいとく)ケースが多いです。

ここでエンジニアが価値を出すポイントは、商品開発(パッケージソフト商品、純広告商品等)になるパターンが多いと思います。(営業支援ツール等のSoRなバックオフィス系は一旦省きます)

エンジニアリングは魅力的な売れる商品を作ることと、営業の顧客単価をどうあげるかに寄与するパターンになります。そしてエンジニアの開発した新たな商品によって顧客単価があがるのであれば、それは素晴らしい成果になります。例えば、顧客単価を上げるために、オプションプランで追加課金するような機能を追加するとか、SMB向け商品等でアップセルを狙うためにエンタープライズの大口顧客に売るために、エンタープライズ特化の機能を追加するとかになります。しかしながら、このモデルでは、定量的なエンジニアのビジネス貢献度が前述の従量課金モデル等に比べ見えにくくなってしまうため、アジャイル化する前にまずはエンジニアのビジネス貢献を定性的にでも見える化する必要があります。絶対やるべきです。 そのための一つのやり方としてAlignmentMapというものがあります。こちらもちょうどプロダクトオーナー祭りにて言及されている方がいました。 martinfowler.com

前述のトランザクション課金モデルだとKPIツリーを分解していけば、最終的にCVR改善等のプロダクトチームのエンジニアタスクに落ちやすいので、定量的にビジネス貢献度を出しやすいのですが、非トランザクション課金モデル、非SaaSモデルでも定性的にビジネス貢献を可視化することはこれで出来ます。これをやることで開発タスクがそれぞれどんなビジネス貢献に寄与するのかをエンジニア自身が把握することもできるし、ビジネス側も意味なさげに見える技術的負債の解消や性能改善等のエンジニアリングとビジネスの関係が見えるので色々やりやすくなります。AlignmentMapとか名前ついてますが、一般的な組織では当たり前のようにこういう構造化はしているとは思います。運用の仕方についてはリンク先を読めばわかるかと思いますので省略します。定期的にビジネスサイド、エンジニアサイド両方での振り返りを行い、一つのマップにマージして議論するのがポイントです。

f:id:i2key:20161127232159p:plain

AlignmentMap

SoEの各フェーズにおいて求められるエンジニアロールについて

また、前述のようなビジネスモデルでの切り口とは別の切り口で、内製化チームを作る場合、時間軸で見てみることも大事で、SoEのビジネスフェーズによって求められるエンジニアロールも変わってくるという話もしたので簡単にまとめておきます。ビジネスドメインによって差異はあるとは思いますので、あくまで考え方の一例として理解してください。

基本的には下記の図がすべてなのですが、説明しますと、初期ステージであればあるほど、なんでもやるよねという話です。MVPを作って実際のユーザーにインタビューしにいくかもしれませんし、営業にエンジニアも同行するかもしれません。そしてグロース期に入って、ビジネスコミットの強いフルスタックエンジニアは、グロースハッカーとして水漏れの補修をしながらKPIに寄与するエンジニアリングをしたりする。チーム自体がクロスファンクショナルであれば、別にフルスタックである必要はないと思いますが、フルスタックエンジニアであるほうが、リードタイムは少なくフロー効率は高いと思います。そして、P/M Fitを達成し、マーケにより流入を増やしたり、カスタマーセグメントを幅出ししたり、アップセル狙ったり、でトラフィックが増えてくるあたりで深刻な性能問題になやんだりします。ここらへんでは、今までの技術的負債をどうにかできるプロフェッショナル型のエンジニアが活躍してくると思います。

f:id:i2key:20161128160513p:plain

結果的に、午前のやっとむさんの発表に繋がったらしい。

まとめ

皆が置かれている文脈も違うため、すべてを包含してこうだとは言い切ることはできないのですが、伝えたかったこととしては、仮に内製化をはじめるとか、アジャイル化していくとか考えるときにどこから始めるとビジネス上の価値創出がしやすいか、成功確度が高いかをこういうふうに考えることも出来るよ、ということでした。 そして、その構造を理解した上で開発体制を組んだり、プロセスをきめたりすれば、よりエンジニアがビジネス貢献しやすい座組を整えやすくなるよという話でした。

そのため、自分がよくやるのは、例えば広告系なビジネスの場合であれば、営業資料があれば真っ先にそれを見せてもらったりします。そこで純広告を売っているのか、成果課金広告モデルなのかわかります。また、その比率も見ます。それでエンジニア組織のありかたを想像するキッカケになったりします。

別に今回記述した論理展開がすべての開発現場に当てはまるわけではないので、現場毎に自分たちのビジネスモデルと向き合い考える必要はありますが、こういう切り口でエンジニアのビジネス貢献というテーマで開発組織のあるべき姿を考えてみるのもよいのではないでしょうか。 こう考えることで、内製化すべきポイントはどこであるか、まずアジャイル化すべきポイントはどこであるか、エンジニアの評価制度にビジネス貢献度を入れるべきかどうかとか、色々考える際のとっかかりになると思います。