リーンスタートアップ著者ERIC RIESの新刊「THE STARTUP WAY」の翻訳概要まとめ #startupway #leanstartup

THE STARTUP WAY

THE STARTUP WAYはLEAN STARTUP著者のERIC RIESの最新刊になります。ERIC RIESがLEAN STARTUPの考え方を大企業に適用させる場合の考えかたについて記載されています。前作のLEAN STARTUPを読まれて実践されている方をベースに読んでみたまとめを書いてみます。英語は苦手オブ苦手なので、誤訳というか誤理解もあるかもしれませんが、全体の雰囲気が伝わればよいかなくらいの期待値でおねがいします。大企業でリーンスタートアップを実践している人には伝わるとは思うので。 なお、フランクにではありますが、エリックからは本中の図の引用の許可は頂いております。

Yes please do

— Eric Ries (@ericries) 2017年11月26日

概要

大企業も従来のマネジメント方法だけでは不確実性に対峙する際に立ち行かなくなります。そのために、大企業もリーンスタートアップの考え方を適用すると良いと本書では提案しています。その事例として本書全体を通してベースはエリック・リースがGEの改善を行ったエピソードを元に説明されています。具体的な事例については本書を読んでもらいたいので、ここでは省略します。全体を通してのメッセージとしては、「アカウンタビリティ」をベースにした起業家機能を事業部門毎に、機能組織(HR、Finance、Engineering、etc)毎にもつべきであるとしています。そして、その起業家機能は、社内スタートアップとそれに投資する社内VC的な位置づけのGrowth Boardで構成されます。事業部門における、社内スタートアップとはまさにそのドメインでの新規事業等が該当します。また、機能組織でいうと、例えば人事機能でいうと、人事評価ルールの刷新等が該当したりします。これもスタートアップとして扱い、新しい評価制度をMVP的に一部の従業員に適用し、仮説検証を繰り返していくことになります。 そして、Growth Boardと社内スタートアップは一般的なVCとスタートアップとの関係性と同じであり、資金の用途についての細かい説明責任は発生しません。結果で示すのみ。そして、計量資金調達（Metered Funding）に基づいて、ステージゲート的に資金調達を随時していくことになります。その進度はROIによる進捗がゼロの期間の間においては、リーンスタートアップでの革新会計をベースに見ることになります。売上が立ち、スケールしていくと従来のROIベースの会計に切り替わります。また、その間に、既存事業は従来のマネジメント手法で運営されており、従来の一般的なマネジメントスタイルと、上記のような起業家的マネジメントスタイルの二本柱で企業運営する考え方になります。

https://twitter.com/ericries/status/934106870284943365

昔ながらな企業と近代的な企業の違い

エリックは、リーンスタートアップの考え方を大企業に取り込むべきと解く前に、近代的な会社としてどうあるべきかを説いています。（相当直訳なので雰囲気つたわれば・・・）

• 昔ながらな企業は、規律的な管理と統制を通じて着実に成長しており、四半期報告書などの短期間で大きなプレッシャーを受ける可能性がある。近代的企業は、継続的なイノベーションを通じた持続的な影響に基づいており、長期的な成果に重点を置いている。
• 昔ながらな企業は、特殊な機能のサイロの専門家で構成されている。その間に、各ハンドオーバーに関連付けられた特定のマイルストーンを使用して機能から機能にプロジェクトを送信するステージゲートまたはウォーターフォールプロセスで作業が行われる。近代的企業は、反復性の高い科学的プロセスを通じて顧客にサービスを提供するために協力し合うクロスファンクショナルチームで構成される。
• 昔ながらな企業は、巨大なプログラムを運営する傾向がある。近代的企業は迅速な実験を行う。
• 昔ながらな企業は、法律、IT、財務などの内部機能を使用して、詳細な手順に準拠してリスクを軽減する。 近代的企業は内部機能を使用して従業員が顧客にサービスを提供するという目標を達成し、ビジネス成果を生み出す責任を分担する。
• 昔ながらな企業は、ROI、伝統的な会計および市場シェアに基づいて非常に不確実なプロジェクトでさえ優先順位付けする。成功を測るために、プロジェクトチームは可能な限りよく見えるように設計された数字（「バニティメトリクス」）を追跡して共有するが、必ずしも真実を明らかにするわけではない。近代的企業は、将来の影響の可能性と規模を最大限にしようとする。プロジェクトチームは、革新会計を使用して主要指標を報告し測定する。
• 昔ながらな企業は、マネージャーとその部下から構成される。近代的企業は、リーダーとその能力を発揮する起業家で構成されている。
• 昔ながらな企業は、年々似た資格資金調達(entitlement funding)システムを使い、自分たちが「正しい」ことを確認するために、高価で開発が遅い大きなプロジェクトを追求する傾向がある。近代的企業は、スマートな実験のポートフォリオを追求し、成功したことが証明されたときに計量資金調達(metered funding)システムを使用して追加投資をする。これには失敗コストも含まれている。
• 昔ながらな企業では効率性は全員が常に忙しいという意味で、効率的に間違ったことを構築することによって簡単に「失敗を達成する」ことを意味する。現代企業は、効率性とは必要な手段で顧客対して正しいことを理解させることを意味する。
• 昔ながらな企業は、「失敗は選択肢ではない」と考えており、"失敗を受け入れる"とリップサービスをするかもしれないが、報酬、昇進、評価システムは根本的に異なるメッセージを送る。近代的企業は、生産的な失敗に報い、方向のスマートな変化につながり、有用な情報を提供する。
• 昔ながらな企業は、参入障壁によって競争から保護されている。近代的企業は、継続的な技術革新を通じて競合他社を粉塵にさらす。

この相違点のリストを見てると、多くのパラドックスに気付く。全体的に短期的な成果（四半期報告書など）に焦点を当てた昔ながらな企業でさえ、ほとんどの第一歩は非常に遅く、リスク回避的であり、All or Nothingで投資します。近代企業の経営陣は、どの戦略が長期的なビジョンを支えるかを知るためには、長期的な哲学と極めて短期的で迅速な実験が必要です。

MISSING FUNCTION

で、そのために企業に見逃している機能があるよと。 小規模な組織では、創業者がやっていたことだけど、組織が大きくなるとどこかにうもれてしまうことで、つまりは、不確実性に対処しながら推進していく機能。

起業家機能

エリックはCEOと会うとき、しばしば以下のように尋ねるらしい。

「あなたの組織の誰が今、以下の2つのことを担当していますか？」

• 企業の新しい部門になる可能性のある高成長のイニシアチブを監視する。
• 起業家的、実験的、反復的な考え方を、日常業務を通じて組織全体に浸透させる。

これらの責任は、組織図にはほとんど表示されません。既存のマネージャー（エンジニアリング、マーケティング、ITなど）の中で最優先事項ではなく、さらに悪いことには誰かの責任である。だから、これらの熱の入らない状況から脱して、起業家精神を近代的企業の核となる規律と見なす時が来ている。それは組織の「スタートアップDNA」の監督者であり、継続的に次世代のイノベーションに投資するために起業家の考え方や技術を組織全体に浸透させる独特の役割を担っている。

例えばで言うと、多くの従業員や多くの職種のマネージャーは、財務のような基本的な予算編成や財務モデリングなどのツールや手順について訓練を受けていてみんな当たり前のように理解してるけど、これと同様に、起業家精神や起業家機能もスキルなのでそうあるべきです。そして、起業家機能は独自のキャリアパスを持つ専用機能として、また組織全体に起業家的手法を普及させる広範な基礎知識の源泉としても機能するようになります。

そこで、エリックは起業家機能に求める2つの責任について言及しています。

• 起業家機能の第1の責任は、同社の社内スタートアップを監督すること。
• 起業家機能の第2の責任は、成功の問題を管理すること。ほとんどの新興企業が失敗するという事実を認めていますが、ほとんどの組織にとって最も難しいのは成功したときに何をすべきかを知ることです。確立された組織内でスタートアップすることは、既存の事業を穏やかに脅かすだけです。しかし、本当の成功を収めている社内スタートアップはもっと危険です。成功した実験では、どのように組織内の家を見つけるのでしょうか？既存の部門に吸収されるか、まったく新しい部門になるか？それはどうやって決まるのか？それは誰の決定で？あらゆる部門には、革新と成長のために新しいアイデアをテストし、洗練し、拡張する方法が必要です。

アイデアが実証され、適応され、スケールする

上記の図は1つの部門内で、時間の経過と共に1つの社内スタートアップ（や新規事業）のパスです。それは、シードステージの実験の一環として始まり、時間と共に成長していきます。複数のスタートアップがある場合、多くの仲間達がトラクションの欠如のために死ぬ中、生き残ったチームはそれを続けていきます。そして、そのスタートアップにおける実験の業務比率が、実行に関するアクティビティによって支配されるまでシフトします。そうすれば、（あとはやるだけなので）親部門がそれを管理する全責任を引き継ぐことができます。起業家マネジメントは一般的なマネジメントとは異なるため、まぜると事故ります。これらの異なる形態の管理は、互いに隔離され、別々に運営されます。新しい製品による小さなスタートアップは、実験実行の連続体の左端で、既存の製品を使用して着実に四半期ごとに成長を遂げている成熟した部門は、この流れでの右端の終わりです。 そして、この状況で発生する事象として、その組織にわずか10人の顧客を持つスタートアップがある場合、新しい顧客を獲得するために投資するのか、既存の事業の顧客にサービス提供するために投資するのかを考えなければならなくなります。法務なり財務なりの一般的に言われている良いプラクティスは既存の顧客（事業）にうまく役立つために出来ているので、企業はあまり過激なことをしないようになっています。そのため機会を逃してしまいます。（イノベーターのジレンマ）

起業家機能を取り込んだ組織イメージ

で、上記のもろもろを企業の組織図に反映すると以下のような図になります。前述の通り、起業家機能は、エンジニアリングやマーケティングなどの企業内機能と同等の位置づけになります。そのため、Missing Functionと扱っている所以です。

THE MISSING ORGANIZATIONAL CAPABILITIES

このような起業家機能ををサポートするためには、一連の新しい課題を解決しなければなりません。

1.適切な責任制約を持つ実験のためのスペースをどのように作るか。

自律的なチームに限定責任を与え実験する「自由の島」または「サンドボックス」を作ります。 Lean Startupでは、これらの限定責任実験を最小限の実行可能な製品（MVP）と呼びます。ここではMVPがどーのこーのは省きます。今は、チームに強力なアカウンタビリティ基準を与えながら実験を作成するという自由度を持たせるというリーダーシップの課題に焦点を当てたいと思います。最高の起業家は制約の中で働く能力を持っています。リソースが不足している早期段階の企業では、制約が自然に発生します。何かをやるためには、非常に多くの人やたくさんのお金、または特定の月数が必要です。より大きな企業では、これらの制約をより意識的に作成する必要があります。あなたの典型的なプロダクトマネージメントのミーティングを考えてみましょう。

 「聞いて、私たちはビジネスに6週間余裕を残すだけの現金しか持っていません。私たちができることが大好きなものがたくさんあることは分かっていますが、それ以前にこれらの事柄のうちの少なくとも1つを動作させなければ、私たちは死ぬ運命に入っています。」

 それはストレスに満ちていると聞こえますが、それは最も生産性の高い作業方法です。スコープや状況の変化に対して常に対抗する力がある唯一の環境の1つです。（制約によりチームは結果的にWIP制限を1にしている状況。そしてそれを作り上げるリーダーシップ。）

2.投資収益率（ROI）を事前に知らなくて、どのようにプロジェクトに資金を投入するか。

画期的なプロジェクトは、ほとんどの場合、最初はおもちゃや悪い考えのように見えます。しかし、本当に悪いものもあります。虚栄心プロジェクトにお金を浪費することなく、証拠、実験、ビジョンに基づいて投資を行うことを学ぶことは、非常に困難でありながら深遠な重要なスキルです。

3.自律的に活動しているチームのための適切なマイルストーンを作成するにはどうすればよいか。

成功とそれへのマイルストーンをどのように定義しますか？正確な予測がないと、従来の管理ツールの多くは機能しなくなりました。スタートアップ投資家はこの呪いに長年苦労しています。理想的には、投資家は各ファイナンス・ラウンドから何を得るのかを事前に知りたいと思っています。たとえば、従来のベンチャーキャピタルでバックアップされた「シリーズA」投資の後、スタートアップは新製品の発売、100万の顧客、および1,000万ドルの経常収入を得ることを知りたいと考えています。しかし、実際には、これはほとんど起こりません。たぶんスタートアップは本当にその製品を立ち上げるだろうが、最初のバージョンに夢中になると思った顧客は興味がなかった。おそらく、総収入は予測よりもかなり低いですが、顧客あたりの収入は予想よりもはるかに高いみたいな状況も発生したりします。このあいまいな状況では、私たちは何をしますか？ 一般的に言えば、企業内のファイナンスの専門家は、アカウンタビリティ目標を数パーセントポイントも失っているチームから資金を引き出すように訓練されています。スタートアップの投資家であることは、しばしば、説明責任の目標を桁違いに欠いているチームを倍増させる必要があります。これには、正確な予測ができない状況でも機能する新しい種類のマイルストーンを作成する必要があります。

4.スキルとして起業家精神をより良くするために、専門的な開発とコーチングをどのように提供するか。

多くのリーダーにとって、これは明確に異なるリーダーシップスタイルの人々を指導することを必要とします。あなたは若いスティーブ・ジョブズをコーチしようと想像できますか？しかし、「次のスティーブ・ジョブズ」に対する投資は必要であるものの、現実にはジョブズ氏のような人格を持つ人は解雇される傾向があります。企業環境でうまくやる方法を見つけた人は、履歴書に繰り返し失敗した経歴を書き込んではダメだと知っています。しかし、起業家として成功を収めた人たちは、失敗が最高の教師であったということをほぼ普遍的に言っています。そして私たちのほとんどは、私たちを指導して起業家の才能を育てるのを助けてくれたメンターや投資家を幸運にも持っていました。シリコンバレーはキャリアとして起業家精神を追求する人々のための広範なネットワークを持っています。この種の従業員を保持したい組織は、企業にも内部的にこれらのサポートを複製する必要があります。

5.私たちはどのようにして社内外にネットワーキングとマッチメイキングを提供するのか、また、社内外の人々は「私は企業起業家だ」という新しいアイデンティティをどのように理解するのか。

ほとんどの企業において、社内スタートアップへの人事的サポート、エンジニア、マーケター、デザイナー等のプロフェッショナルサポート等のサポートがありません。THE STARTUP WAYのアンバサダーとして、起業家機能が繁栄すると期待したら、これらのサポートを創り出す必要があります。

6.適切な人材を適切なチームに配置するにはどうすればよいか。

「誰もスタートアップで働くようにアサインされません。」と、ある企業の起業家は私を嫌って言った。

マネージャーはアサインをする際に、自分の昇進に最も効果のあるアサインを行う癖があり、またメンバ側も自分のキャリアを汚すようなアサインは割けるために様々なツールを使ってアピールしてみたりと、政治的活動や駆け引きなどクッソどうでもよいムダがはびこりがちです。未知の、リスクの高い、不確実なプロジェクトには、人材を惹きつけるための合理的な方法が必要です。

7.我々はどのように新しいインセンティブと昇進システムを作りだすか。

大事なのは、単純にスキルがないのか、わかった上で迂回ルートをとっている人材なのかを見分ける仕組み。また、「fauxtrepreneurs」のフェイクにはまらないための見抜く仕組みが必要。

fauxtrepreneurs : A person who comes up with myriad business ideas but never actually sees one out.

アカウンタビリティ

起業家マネジメントは、21世紀の不確実性のために特別に設計されたリーダーシップ・フレームワークです。 これは伝統的なマネジメントの代わりではありません。 マネジメントポートフォリオにおいて、一般的なマネジメントと同じくらいの厳格さを起業家マネジメントにも与えるように設計された規律です。従来のマネジメントスタイルで管理できないのは、予測不能であるということだけではありません。 これは従来の管理設定で慣れ親しんできたものとは異なるツールと異なる保護手段を必要となります。 THE STARTUP WAYのパワーは、2つの異なる作業方法の強みを兼ね備えているという事実にあります。 Lean Startupでは、この簡単な図（inspired by a famous diagram in The Toyota Way）を使って作業する「スタートアップの方法」を明確にする最初の試みを含めました。

THE STARTUP WAYの基礎はACCOUNTABILITYをベースに、PROCESS、CULTURE、PEOPLEで構成されています。 ACCOUNTABILITYは、従業員の行動を促し、そして、注意をフォーカスさせるための報酬やインセンティブを含む責任の仕組みです。組織において人々は何によって昇進して、何によって祝われ、何によって解雇されるのか。アカウンタビリティシステムは、企業が達成したいと望む長期的および短期的な目標に沿って整えなければなりません。 PROCESSは、プロジェクトの計画、管理、チームの調整、コラボレーションなど、従業員が日常的に仕事を遂行するために使用するツールや戦術に関係しています。アカウンタビリティシステムが結果的に選択肢を制限するため、プロセスは説明責任から外れます。適切なインセンティブが与えられたほとんどのチームは、新しいツールや戦術の回りに自己組織化することができます。アカウンタビリティによる説明責任をチームが持つからこそ、そこに権利・権限が発生し、プロセスは自由になります。 時間の経過とともに、これらの習慣や働き方はCULTUREになります。文化は組織がどのように動くかを望んでいるものではなく、過去に実際どのようにしたかに基いている組織の筋肉の記憶です。従業員に「Be more innovative!」とか「Think outside the box!”」とか奨励するポスターをはるだけで文化を変えることはできません。Facebookで有名な「Move fast and break things!」さえも意味ない。あらゆる文化は、特定の種類の人々、すなわち究極の企業資源を引き付けています。 有害だったり昔ながらの文化は革新的な才能を離脱させます。最終的に、組織の成功は文化が引き付けることができる人の総量に依存します。新しい文化を育むためには、個々のチームが自己組織化する必要があります。新しい文化は、新しいやりかたが成功するのを目撃した経験から生まれるものです。これらのチームは、慎重に育成されれば企業全体の新しい文化の種となり得ます。実際、多くの成功した変革の中で、チェンジ・エージェントになった将来のリーダーは、初期のパイロットプロジェクトで働く普通の従業員として始まりました。

単一の組織内であっても、起業家の原則と一般的な管理原則は共通の基盤、特に長期的な考え方の重要性と共通の価値観を共有しているため、実行の厳格性と規律が必要です。それらを共存させるために、その差分をわかりやすくした図が以下。

新しい組織の形

起業家マネジメントのツールは、革新を必要とするプロジェクトや不確実性のコンテキストで動作するプロジェクトのために組織全体で使用されているとしても、起業家精神も組織内に専用の家が必要です。 アントレプレナーシップは、専門スキルと独自のベストプラクティスを必要としていることを認識すると、エンジニアリング、マーケティング、セールス、IT、人事、財務などの機能にも組織図に独自の家を与えることができます。要は、起業家機能を事業ドメインだけではなく、機能組織にも注入することで新しい変革を起こしやすくするのだーとおっしゃってる模様。

ただ、この構造に変えるには並大抵の努力じゃいかないとエリックもいっていて、でもそれ以上のメリットがあるといっている。そのメリットって何かを次に列挙します。

変革の成果

1.リーダーシップの機会が増えます。

今日の階層構造の課題の1つは、実際にはP＆Lの責任を持つ真のゼネラルマネージャーの仕事がほんのわずかであることです。リーダーシップポジションを小さくする企業では、ポジションは小規模であるため正確なリーダーシップの役割を果たすことはしばしばありません。ほとんどの組織では、小規模は重要ではないと見なされます。社内のスタートアップは、小さくても、充実した責任を負っています。彼、彼女に大組織のP＆L責任を与えるほどリスクが高いように見せても、社内スタートアップでは、本当のリーダーであることを証明する機会があります。要は、小さいスタートアップながらもP/L責任を負った上で業務が遂行できるため、これは説明責任と実行権限が同居する座組のため、本当のリーダーシップを学べる良い機会であるということ。

2.退職を促す代わりに、革新的な人材を社内に維持するのに役立ちます

才能のある人々がスタートアップをはじめるために会社を離れる場合、これは経済全体にとっては平均しても良いことです。しかし、元の会社にとっては、それは損失です。人事部門の失敗です。ファウンダーが会社たちあげのために辞めていくのを防がねばならない。

3.無駄な時間とエネルギーを削減します。

あなたが毎日している仕事が誰かのために価値を創造していることをどのように知っていますか？たいていの人がその質問に答えることができません。 リーン生産理論は、輸送、在庫、動き、待機、過処理、過剰生産、および欠陥の7種類のムダを識別します。 最近、リーンコミュニティは、伝統的なムダのカテゴリーを超えて考えています。 誰もが望んでいないものを効率的にやっていくことは、もう一つの根本的なムダであると認識する必要があります。 この問題は、あらゆる規模の企業、スタートアップ、既存の組織を悩ませています。間違った製品を構築するために時間とエネルギーを注ぎます。THE STARTUP WAYは、最初に構築すべき正しいモノを見つけ出すための管理努力に焦点を当てています。

4.プロジェクトを殺すより良い方法です。

プロジェクトをキャンセルすると、政治的に大きな影響を及ぼすことがよくあります。その結果、企業はほとんどの場合十分な頻度でそれをやっていません。プロジェクトが政治的な勢いを集め始めると、ステージゲートプロセスがそれを止めることは難しくなります。ミドルマネージャーは強制的に執行者のように行動します。プロジェクトを終わらせる必要がある場合、通常はかなり苦しいです。

ほとんどの企業は、プロジェクトの管理に「緑色、黄色、赤色」の評価システムを使用しています。一般的に言えば、評価を行うための基準が10つある場合、各チームは常に7つの緑、2つの黄色、1つの赤を表示しているようです。それは魔法と似ています。彼らはいつも同じです！

なぜかというと・・・・すべてのマネージャーは、あなたがあまりにも多くの緑を表示する場合、信じられないと思うことを知っています。一方、問題が多すぎるとプロジェクトがキャンセルされる可能性があります。管理者は、ゲートを通過するために必要なものに対してステータス更新を完全に較正しています。プロジェクトの実際の進行状況との関連がほとんどない、この物語の構築に費やされた舞台裏での時間とエネルギーの量は膨大です。

一方、スタートアップは常に失敗します。原因は常に同じです。彼らは収益を上げる前にお金がなくなり、それ以上の収入を得ることはできません。ファウンダーの中には、さらなる投資をしなかった投資家について不平を言う人もいますが、一般的な文化は、企業の失敗はファウンダーとその決定に起因すると認めています。それが私たちが自分のキャリアを終わらせるということではありません。彼らが追加の資金を調達できない場合、それは彼らがつくりだした結果が次の段階に進むのに十分なものではなかったからです。ただそれだけ。

5.スピードと俊敏性で異種の問題を解決する能力。

発生したときに、大規模な製品リコールや他の目に見える危機のような、組織全体を解決するために組織全体を改革する必要があるという問題があります。しかし、何らかの理由（現実的または政治的）にかかわらず、CEOの個人的な注意を呼び起こさない緊急の問題はどうですか？ある機能や部門が急性の痛みを感じるものとそうでないものとの連携が必要な問題はどうですか？そして、労働者を悩ませているイライラした日々の「普通の」問題はどうですか？今日の管理システムは、このような状況に注意と資源を投入するために奮闘しています。

実験を実行し、結果を測定し、もし結果がこの解決策として有益であれば、それをスケールアップするような、より起業家的なアプローチでより良い答えが得られます。膨大な数の実験が失敗するという事実を利用するので、管理上の帯域幅を取る必要はありません。組織が新しいアイデアを二重にするかどうかについて戦略的な会話をする必要があるときには、実際の顧客データと完全な合理的な議論ができます。

6. で、その結果。

不確実性に対処し、企業がより多くの新製品を構築できるよう支援することにより、THE STARTUP WAYはマネージャに市場へのより適応力と機敏性を与えることができます。

変革への3フェーズからなるロードマップ

前述のもろもろの変革を進めていくには以下の3ステップを踏むとエリックは言っています。

• フェーズ1は、実験、適応を通して基礎を築くことです。
• フェーズ2は、迅速なスケーリングと展開のためのものです。
• フェーズ3は、企業の深いシステム（財務、人事、etc等）を扱うことに取り組む力を得ることになります。

フェーズ1: CRITICAL MASS

フェーズ1はクリティカルマスに到達するまで、以下の典型的なリーンスタートアップに基づいたやりかたで進めていきます。 - この特定の組織で新しい方法がどのように機能するかを示す包括的なケース、ストーリー、および結果のセットを作成するために、限られた数のプロジェクトから始め、そこから構築します。 - 最初から機能的な多様性を組み込むために、パイロットプロジェクトを実施するための専用のクロス・ファンクショナル・チームを作成する。 - エグゼクティブが提示されたプロジェクトについて迅速かつ明確な意思決定を可能にするGrowth Boardシステムを作成する。 - 初期チームに、不安定な地形でコースをプロットするのに役立つリーンスタートアップ型の実験を設計する方法を教える。 - 適切なスタートアップスタイルのメトリックを使用して、それらの実験の結果を測定する。 - 新たな作業方法が確立された方法と矛盾するようになったときに生じる問題を解決するのに役立つ組織の指導者ネットワークを構築する。すぐに前進し、後の段階まで組織構造への深い変更を遅らせるために、最初は例外で作業します。 - 新しい概念を企業固有の言語とツールに翻訳する。

フェーズ2 : SCALING UP

このフェーズは、フェーズ1の取り組みによって特定された、組織にとって適切な方法の迅速なスケーリングと展開に関するものです。 GEでは、これらのアイデアが1つの機能ドメインで機能していることから、個々のプロジェクトを通じてどのドメインにも適用できることを証明することになりました。 フェーズ1の場合と同様に、フェーズ2についても「適切な」方法はありません。 しかし、この次の変化の段階で働いている組織に共通する重要なパターンとタスクがあります。

• フェーズ1のチームやプロジェクトが直面する課題を確認し、特定する。
• 新しい方法で作業するための普及したシステムを開発し、展開する。
• 新しい方法を強化するために幹部レベルの支持者・擁護者を特定し、適切に活用する。
• 内部機能を変換プロセスに持ち込む。
• 内部コーチングプログラムを作成する。
• 成長基盤を確立し、資源配分のための計量資金（Metered Funding）を使い始める。

計量資金調達（Metered Funding）

従来の年次予算計画でやっていく予算編成をここではエリックは資格資金調達（entitlement funding）と言ってる。で、この座組だと、毎年開催される会議での資金調達のために、自身の希望するプロジェクトを「デッキ」に入れることは非常に難しいです。でも、一度デッキに入ってからは、ほとんどのマネージャーが「蛇口」と呼んでいるように資金調達の流れが周期的に変化します。相当やばい失敗がない限り、プロジェクトは四半期ごとに、さらには年々継続することが期待されます。ある年度に資金提供されるほとんどのプロジェクトは、翌年に同じレベルではないかもだけど資金提供され、そしてほとんどキャンセルされることはないです。 また、チームが資金援助を受ける資格があると感じると、スタートアップに必要なエネルギーとフォーカスを生成することはほとんど不可能です。スタートアップの死亡率は、過度の資金を投じられたケースでは異常に高いです。

資格資金調達のもう一つの問題は、政治を管理するための費用です。平均的なプロジェクトチームリーダーが自分の予算に関連する会議の数は、驚異的なものになります。そのように働くことに慣れている企業では、文化の変革は長期的なプロジェクトです。それには一連の連動する改革が必要。しかし、予算プロセスは基本的なものなので、資格資金調達への鍵となる解消策は、計量資金調達（Metered Funding）というものです。これは計量された資金調達との取引です。金銭を使う絶対的な自由と、より多くの資格を取り除く方法についての非常に厳格な基準と、検証された学習のみで建てられたものです。 VCからシード資金を調達して100万ドルを調達した場合、翌月に進捗報告しろと電話を受けることは決してありません。この自由は、スタートアップを可能にする重要な部分です。

計量資金調達に移行するメリット。

• Scarcity mindset （節約的な意味あいかな）
• Changes the calculus of who’s to blame if a project fails
• Allows managing a set of projects as an explicit portfolio, along with portfolio metrics
• Greatly reduced political burden on teams （チームの政治的負担を大幅に軽減）
• Greatly enhanced focus on “what do I have to provably learn in order to unlock more funding?” （さらなる資金調達のために何を学ばなければならないのか？にフォーカスする）
• More conducive to cross-functional collaboration (because everyone is paid out of a common budget)
• Reduces middle manager interference (because no resources are borrowed from the parent company)

計量資金調達は、文化を変えるだけでは十分ではだめで、これは既存のシステムが非常に復元力があるためです。実際の文化の変化を起こすために、計量資金とGrowth Board（後述）などの他の変更を組み合わせが必要になります。

Growth Board

Growth Boardには、次の3つの責任があります。

1.社内スタートアップのコーポレートアカウンタビリティの単一点であること。

いくつかのGrowth Boardは、1つのチームにしか対応できません。ほかにも長寿命のGrowth Boardもあり一度に多くのチームにサービスを提供したりもします。スタートアップのアクセラレータと同じように、意図的にチームのコホートをボードに持ち込むことさえあります。 その形態にかかわらず、すべてのGrowth Boardは、自ら監督する社内起業家のためのピボットまたは継続の意思決定の立場を目指すべきである。最良のボードは、ファウンダーが進歩について深く考えるように促し、検証された学習を達成したのか、単に希望のある考えを達成したのかを疑うことができます。これはステージゲート（ "go / kill"）のレビューとは異なります。

2.会社の他のスタートアップに関する情報のための単一の情報センターとしての役割を果たす。

（略）

3.スタートアップチームに計量資金を提供する。

最も進んだGrowth Boardのために、計量資金調達は組織の文化変化を推進する究極のツールです。Growth Boardによって資金が提供されるだけでなく、コーチされる社内スタートアップは、真にリーンなメンタリティを持っています。計量資金調達が機能するためには、Growrh Boardの資金調達の決定は単純でなければなりません。社内スタートアップは、マイクロマネジメントなしで、Growth Boardのお金を望みどおりに使うことができます。しかし、給与、設備、施設など、使用するものの全額を負担しなければなりません。 私は内部のスタートアップが外部のベンダーに行くのを見ました。彼らが自分のお金を使っている限り、これは問題ありません。しかし、Growth Boardの哲学のルールは、次のようなものでなければなりません。お金はあなたのものですが、有効な学習を示さなければ、さらに資金を得ることはできません。これが高度な技術である理由です。ほとんどのチームは、強制されるまでこのルールを信じません。しかし、また、ほとんどの役員は失敗したビジネスにさらに金をつぎ込むことを防げません。そして、大部分の従業員は、彼らのプロジェクトに高い技術を投入するために上司に説得力を高めました。しかし、革新会計の全体のポイントは、これらの決定を厳格な方法で行うことです。成長志向のプロセスのチームと役員は、そうするために学び成長する必要があります。

フェーズ3 : DEEP SYSTEMS

フェーズ3では社内での改善の座組がDEEP SYSTEMに及ぶことにふれています。ここでいうDEEP SYSTEMは、法務、経理、人事等のゲートキーパー機能にあたる部分を指しています。THE STARTUP WAYの目標は、顧客サービスの考え方を取り入れることです。 ゲートキーパーの目的は文字通りディフェンスであるため、レビュー、官僚制、厳格なルールを通じて他の機能の作業を遅らせます。 ここをTHE STARTUP WAY化できると、チームは作業を加速できます。 何を変える必要があるのかは場合によって異なります。 本書内には、法務部門の例（PivotalでのOSS利用方針に関する法務チェックの改善について）やファイナンスの例、人事の例等がのっていますが、ここでは人事のスタートアップ化についてサマリだけ載せます。

GEのとあるチームがFastWorkが進み、自らセットベース開発を開始したとのこと。そして、セットベースにすることで、顧客に価値提供するリードタイムが5年からMVP投入18ヶ月まで削減。これを上位層までレポートしたかというと、「していない」といいます。 セットベース開発を行うと、複数案をパラレルで走らすから一時的にコスト増加し、さらに、場合によってはリワークが一部増えることになる。 彼らの人事評価システムでは、リワークをKPIとしており、リワーク量が多いと評価が下がり、キャリアに悪影響を及ぼすらしく成果としていうことはできないようです。まさに評価システムがボトルネックになっている状況です。これを解決するために人事の中にもスタートアップチームが立ち上がりました。その中で人事評価のMVPの仮説検証をコホートをきり繰り返し実験を実施し、改善を推進していったようです。つまりは、これが各機能組織においてもスタートアップチームが隠れているという所以で、このような活動も、機能組織にGrowth Boardを設置し、スタートアップとしてのメカニズムにのせて推進することになります。

起業家精神の統一理論

今まで、組織の事業軸、機能軸それぞれで起業家機能についてふれてきました。これらのアイデアのすべてを一緒に話す壮大な方法があります。今日、ほとんどの組織（規模にかかわらず）は、以下の活動をいくらか行っています。

• 全く新しい製品を作り、新たな成長源を追求する。
• ITシステムやHRポリシーなどの新しい「内部製品」を構築する。
• 企業開発：他の企業や新興企業の買収、スピンアウト、コーポレートベンチャー、技術ライセンス/技術移転
• 新しい作業方法を導入するための企業チーム（FastWorksなど）の構築など、企業のリストラや変革を行う。

これらの4つの活動は多くの人々が理解するよりも共通しています。実際、それらは共通点が非常に多く、一元管理され、単一の包括的機能の助けを借りて管理されるべきです。これらは起業家精神の "欠けている機能"の柱です。現代の企業は真にその前身との差別化を始めます。重要なことは、組織が次のことを行うことです。

• 1.起業家精神機能の責任を誰かに任せます（あまりにも多くの組織には誰もいません）。
• 2.これらの人々に、単に扇動者として（単に多くの「チーフ・イノベーション・オフィサー」が存在するように）指定するのではなく、実際の運営責任を与える。
• 3.起業家の才能のためのキャリアパスと専門的なパフォーマンス開発プロセスを構築する（影響を受ける機能や部門に関係なく、柱を越えて共通の標準を作成する）。
• 4.柱を横切る起業家の相互訓練を促進する。 （これは、創業者としての実績のあるVCが非常に高い評価を受けている理由ですが、創業者としての実績を持っていないにもかかわらず成功したVCには注意する必要があります。重要なのは、履歴書ではなく、考え方です。）
• 5.組織全体の起業家精神を育むための訓練、指導、サポート、指導、ベストプラクティスを提供する。
• 6.組織において、非起業家を教育する責任があります。必ずしも変化の原動力ではありませんが、より起業家的な働き方を採用する必要があります。
• 7.他の機能（特にゲートキーパーの機能）が会社のポリシーを設定しているときに、起業家精神を議論のテーブルに置く。これは特にファイナンス、法律、人事、およびITにとって非常に重要です。

これらのコミットメントは、企業の機能として、起業家精神の最も包括的な構造を形成します。以下に、起業家精神の統一理論のすべての要素を示す組織図が掲載されています。

感想

ざっと読んで大事だと思ったポイントを上記にまとめましたが、基本的にアカウンタビリティがベースになっている考え自体は非常にスタートアップ的であり、シンプルだと思いました。結局、責任と権限が同じ場所にあれば、健全な自由であるため、自己責任でなんでもできます。また、既存事業とのカニバリによるイノベーターのジレンマを回避するために、全体的にはステージゲート方式で新規事業を運営する出島があり、この構造も弊社のRECRUIT VENTURESにそっくりだなと感じました。そこそこの規模の企業でやるには自然とこの構造になるのでしょうか。

About | Recruit Ventures (Recruit)

THE STARTUPWAY と バイモーダル戦略について

視点を変えるとこのTHE STARTUP WAYは従来の一般的なマネジメントと、起業家的マネジメントを2本の柱としています。この構造が実はエンジニアである私からみると、完全にバイモーダル戦略のそれと一致しており、本質的には同じ構造でスッキリしました。

前述の図。 以下がバイモーダル戦略。

新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi

THE STARTUP WAY と クロスファンクショナル/スモールチームについて

次に、マイクロサービスは組織論だという組織論サイドの考えでいくと、マイクロサービスを縦切り横切り議論でいうと、事業ドメイン切りをした場合、仮にそこを売上があがる単位に分割するとまさに同じ座組がつくれます。チームはクロスファンクショナルであり、そこには売上に関するアカウンタビリティがのるため、その分、技術的な、ビジネス的な、権限が発生します。

さいごのさいご。

本質的には、責任と権限が同じ場所に来るようにおいて健全な自由度をもたせ現場を動きやすくする。そして、それが出来るための起業家機能を設置する。Growth boardがVC的に動く。というスタートアップエコシステムを社内に作ろうとしているのはわかりました。ロジックとしては非常に全うであり、ツッコミどころはありません。ただ、ただ、さいごにひとつだけ。なぜ、GEの株価はリーンスタートアップしたのに今年にはいってからむちゃくちゃさがっておるのだろうか。

リーンUXの著者は、ブログで「リーンスタートアップは不確実性に対処してるかもしれないが、実際にそれを評価するマーケット（やCFO）は確実性が大好きwww」と言ってるけど、ホントかいなｗｗｗｗ

さいごのさいごのさいご。

実はこれは、Recruit Engineers Advent Calendar 2017 - Adventar の3日目の記事でした。 さいごにバイモーダルとかマイクロサービスとかくっつけて、ギリギリエンジニアのアドベントカレンダー風に着地させましたが、弊社のエンジニアの中にはエンジニアリングの嗜みとして、ビジネス側もこうやってチョットだけ理解しようとしている人もいるんだよという多様性もアピールできれば。ではでは。

宣伝

というわけで、リーンスタートアップに関するイベントを馬田さんと角さんとやることになりました。もう人数がアレですが、よろしくお願いいたします！

leanstartup.connpass.com

フロー効率性とリソース効率性について XP祭り2017で発表してきた #xpjug

先日、開催された XP祭り2017 にて発表してきました。スライドは以下になります。

フロー効率性とリソース効率性について #xpjug from Itsuki Kuroda

www.slideshare.net

また、上記発表のベースは以前のポストである「 フロー効率性とリソース効率性について（QCDのトレードオフなんて本当は無かったんだ） - @i2key のBlog 」がベースとなっております。また、Slideshareに上げたスライドが画像が若干ガビガビになってて見にくいので補足がてら要点だけ記載します。（と思ったら、元のポストより完成度高まってしまった。ので今後、誰かに説明するときはこっちをオリジナルにしよう。。。。）

フロー効率性とリソース効率性についてかんたんな説明

リソース効率性について

リソース効率を高めるということは稼働率を100%にあげていくことであり、リソースに空きがあればタスクを与え全員が何かしらの手持ちのある状態を作るということになります。ただし、価値を発揮するまでのリードタイムが長くなります。 上記の図は例えばA、B、Cという3つの機能追加開発(それぞれ工数15人日)があった場合、それらを同時に開発するパターンを示しています。複数のことを同時にやるとリリースまでまとめて同時に行われるため、3週間後にまとめてリリースされることになります。ABC機能がユーザに届くまで・その機能を使った検証を開始するまでのリードタイムは3週間かかります。これに対して後述するフロー効率性を重視した開発だと前倒しになります。ただし、この状況は皆に仕事が割り振られて手持ち無沙汰な人がいないため、リソースあたりの稼働率は高くなります。以下の図がリソース効率を高めるときのイメージです。 フォーカスしているのはリソースそのもので、そのリソースの稼働を100%になるまで、流れてくるタスクに対して割り当てています。一般的にマルチタスクと言われている働き方です。

フロー効率性について

フロー効率を高めるということは稼働率をある程度犠牲にした上で、全員で1つのことに取り掛かり1つ1つをリリースしていくことになります。これにより個々の価値発揮までのリードタイムはリソース効率重視に比べ短くなります。しかしながら、手持ち無沙汰な人が発生したりするので稼働率は下がります。 前述の図と同様にA、B、Cという3つの機能追加開発(それぞれ工数15人日)があった場合、それらを1つ1つ順番に開発するパターンを示しています。一つ一つを順番に倒していくためAは大体1週間くらい、Bは大体2週間くらい、Cは大体3週間くらいでリリースされます。仮にA機能がC機能の前提だった場合、Aの検証結果がダメな場合は、Cは開発をやめて別のことをやるとか、まとめてやる場合よりも短サイクルでフィードバックループを回すことが可能になります。 ここでフォーカスしているのはリソースではなく流れてくるタスクそのものです。そのタスク自体が享受するリソース時間を最大化するように割り当てられています。1つの対象が得られるリソース時間を最大化する手法としては以下が有名です。

• ペアプログラミング
• モブプログラミング
• 障害発生時の動き
• ○○対策会議

上記は、価値を発揮するまで（問題を取り除くまで）のリードタイムを短くするために行われています。このときにリソースの稼働率を気にしていないはずです。

フロー効率性とリソース効率性のビジネス影響について

では、実際にビジネス上、それぞれのスタイルがどのように影響するのかという点で見ていきます。ただし、様々なケースがありどっちが正義というわけでもないので今回は改善サイクルを回してコンバージョンレート（以下CVR）を上げていくという開発を例にします。

ビジネス価値とリソース効率性重視の開発スタイル

ABCの機能がそれぞれCVR向上を目的とした場合、リソース効率重視でまとめて開発するとこの場合、6〜7週間後にリリースされます。そして、説明のため超ざっくりですがABCそれぞれが仮に1ptのCVR向上の効果があるとした場合、それらの効果は同時にきます。ビジネスモデルにもよりますがそれがKPI数値に寄与するのかはたまた売上に直結するのかはありますが作ったものの成果が出るのがそのタイミングです。

ビジネス価値とフロー効率性重視の開発スタイル

それに対して、ABCをフロー効率性重視で1つずつ作っていった場合、Aがリリースされるのが大体2週間後で、成果が出始めるのも2週間後からになります。そしてそこからBの開発がはじまりますが、Aの効果は引き続き続いているので根雪構造として効果が蓄積していきます。そして4〜5週間後に差し掛かったときにBがリリースされます。A同様にそこかでBの効果も出始めるので、A+Bの効果が積み上がります。同様にCも（略）。ここでポイントなのはビジネス上の成果は根雪構造をとるので早めに市場投下したほうが何らかのフィードバックを得やすくなります。

それぞれのビジネス上での影響

まとめると、上図のような感じになります。改善サイクルを回りてCVRをあげるような文脈における開発では、まとめてやること（リソース効率）を選択するということは、学んでいない期間、稼いでいない期間を最大化するという選択を取ったということを意味します。また分析基盤がしっかりしていて、機能毎のコホートが取れていれば問題ないですが、何も準備無しでやった場合は効果も同時に濁ることになり、何が寄与したのかすら不明になります。学びがないので振り返れないです。 それに対して、1つずつやること（フロー効率）を選択したということは学んでいない期間、稼いでいない期間を最小化する選択をしたことになります。しかしながら、稼働率は若干悪化するため、トータルでいうとABCを作り切るコストは高くなるかもしれません。しかしながら、ABCそれぞれがダメだった場合のリスクも下げられているので行って来いかと思います。

個人として、組織として、マルチタスクをとるか、シングルタスクをとるかという選択

○○効率性が正義、○○効率性は悪とかを言いたいわけではなく、これは場合によるとは思います。が、個人的には制約がない限りフローに倒したほうがリソース効率上の問題も浮き彫りになるためフロー改善を意識的にやるとよいと思います。そのためにバリューストリームマップとか考え方のフレームワークはあります。しかしながら、サービス開発において様々な制約が存在します。現実は簡単ではないです。そんな中でエンジニアリングを駆使して制約をコントロール対象にすることが求められていますし、DevOpsやアジャイルにおけるエンジニアリングプラクティスは制約をコントロール下においてフローを加速させる目的が含まれているように思えます。

例えば、リリース日が固定で沢山の実装すべき機能がある場合、そのリリース日を制約としてすべてをまとめて作っていくやりかたを選ぶ(リソース効率)か、Feature Toggleを用いて1つ1つ段階的にDark Launchしていき、リリース日にトグルオープンにする(フロー効率)か、エンジニアリングで制約をコントロールできたりします。

契約、環境、組織、プロセス、スキル様々な制約がある中で制約をコントロール対象ではなく前提とした瞬間にリソース効率の引力が襲ってきます。ただし、開発の特性上、制約を前提とおかねばならない場合もあるのは当然で、制約をコントロール出来る上限こそがその開発組織の文化的、組織的、技術的練度なのかと思います。

まとめ

この手の話というのは、ToCでもCCPMでもリーンでもTPSでもどこでも同じような話がされています。なんら新しい概念でもなんでもありません。その割には現実世界では何に当てはまるのかというように実業務に紐付けては理解されていないように感じます。そこで、サービス開発が対峙している状況にテーラリングすることで少しでもこの概念が現場（特に判断を行うロール：マネージャなど）にインストールできればと思います。あくまで真理に対して初心者でもわかりやすく特定の方向から光を当てているだけであり、全方位をケアするような目的ではありませんので、今回光を当てていない影の部分に対して、やれ、ToCではこうだとか、TPSだとあーだとか、いやいやリーンだとこうだけど？みたいなツッコミはご配慮いただけると幸いです（笑）

フロー効率性とリソース効率性について（QCDのトレードオフなんて本当は無かったんだ）

最新版

本ポストをXP祭り2017で発表したので、補足を含め要点のみを抽出してリライトしております。

i2key.hateblo.jp

---

本ポストはプロダクト開発における特定の文脈によるものなのですべてがそうだとは言っていませんのであしからず。バイモーダル戦略でいうところのSoE領域*1であり、学びによる改善サイクルをガンガン回していくようなモデル・フェーズを対象としております。TPSやLEANを現場で実践してる方々には今更なお話かと思いますが、DevOpsやアジャイル、リーンスタートアップを実践していく上で何周かしてまた原点の理解すると深みがますというかようやく、「ちょっとだけリーンわかる」ようになったので自分用のメモになります。

共通の価値観としての「リードタイム」

SoEライクな開発をしていると、仮説を立案し、そのための仮説を実証するための機能を実装し、リリースして計測、そして学びを得て仮説を補正する（別の案を試す）というサイクルをくるくる回すことになるかと思います。このようなときに開発チームとして目指すところは学びの回数を最大化することなのは自明かと思います。そしてそのサイクル短くする、すなわちサイクル効率性を高めることが必要になります。サイクル効率には仮説の質等も影響も与えますが、今回はエンジニアが直接結果をコントロールしやすいサイクルタイム、言い換えるならば、学びまでのリードタイムを軸に考えていきます。またスコープは学ぶまでのリードタイムであるため、Build部分のみにフォーカスするのではなく、Build-Measure-Learnの1回転をスコープとします。 例えば、コードレビューで手戻りが頻発すればリードタイムが伸びますし、受け入れテストで受け入れられなければやりなおしになるのでリードタイムが伸びます。様々な活動は結果的にリードタイムに跳ね返ります。

すごくラフですが以下のような開発プロセスのバリューストリームマッピングを例にします。LTはリードタイムを表しています。リードタイムとはプロセスが作業を受け付けてから、下流のプロセスに渡すまでの時間になります。PTはプロセスタイムで、作業者がひとつの作業項目を完了するのにかかる時間です。そして実際に価値が作り込まれているのがこのプロセスタイムになります。実際のところは[PT = Value Add Time(VAT) + ムダ ]であり、 本当に価値を作っている時間はその一部になります。赤い部分が上記のBuild-Measure-LeanサイクルのBuild部分に相当します。エンジニアが直接結果をコントロールしやすい部分です。

フロー効率性とリソース効率性の話

あえて極端な例。A機能、B機能、C機能の実装それぞれ15人日かかる場合。

• リソース効率性パラダイム（図の上側レーン） 複数のことを同時にやるとプロダクトが届くまでのリードタイムが長くなる。ただし、みんなに仕事が割り振られるためリソースの稼働率は高くなる。
• フロー効率性パラダイム（図の下側レーン） 逆に、同時にやることを一つにすると、プロダクトが届くまでのリードタイムは短くなる。ただし、全員が同じことをやる場合、どうしても一時的に、手持ちがなくなる人が出て来るためリソースの稼働率は下がる。図ではCも3Weekのリードタイムで出してるが実際は、4週目とかにズレこむ感覚。でも、ABCのリードタイムのトータルでは上側レーンよりは圧倒的に少ない。

これはどちらが正解というわけではないです。この2つはQCDのようによくあるトレードオフの関係にあります。大規模開発のように大量のものを一括でドン！とリリースするような文脈だと、上記のリソース効率のパラダイムになります。そんな中でフロー効率性を高めるようなペアプログラミングを実施したいと提案しても、(リソース)効率落ちるだろと言われ却下されることは多いのではないでしょうか。逆にフロー効率性を高めて、学びまでのリードタイムを最小化しようとしているときに、偉い人が出てきて「リリース物は全部承認印が必要だ、だが、時間はあまりないので一括で見るからまとめて持ってきなさい」とかいわれると現場はフロー効率性を高めようとしているのにリソース効率性のノイズが入り、現場からはヘイトが高まるのではないでしょうか。

ポイントとしては、タスクやデータ、物事の流れに着目し、それがうまく流れているかをカイゼンしていくことが大事です。

そして、一般的には、フロー効率性の目線で現場の課題を可視化していき、フロー効率性を高めると結果的にリソース効率性における課題も表出化され改善されることが多いです。ベースはフロー効率性を高める目線で活動しつつ、制約が現れたときにそれをコントロールの対象とするか、前提とおくかは重要(制約理論)です。ここらへんはThis is Lean*2とかに詳しくは書いてあります。

QCDのトレードオフなんて本当は無かったんだ

SoEライクな開発の座組において、QCDとScopeは「学びまでのリードタイム」という軸で見ると以下の意味を持つ。結論から言うとリードタイムという観点だとQCD全部大事。品質は悪いと基本的に手戻りを生むので速度に跳ね返る。手戻ってる時間は学びをうまない時間。品質を下げるという判断は学びの速度低下を許容するとこと。

• Quality：低下するとリードタイムを悪化させる（＝品質下げるという選択肢がそもそも無い：固定）
  • プロセス品質下げると手順ミス等により手戻りが発生しデリバリへのリードタイムが長くなる
  • 内部品質さげるとバグの発生、コードレビューの指摘、技術的負債による実装の複雑さなどにより手戻りや速度低下を招き、デリバリへのリードタイムが長くなる
  • 外部品質さげるとUXバグをうみ、本来検証したいことが検証できず学びまでのリードタイムが長くなる。障害発生により、それの対応に終われリソースが枯渇し本来やるべきことの足かせになり、リードタイムが長くなる
  • 利用時の品質さげると、カスタマーサポートが頻発しその対応に組織のパワーが持って行かれリードタイムが長くなる
• Cost：大抵人件費でありチーム体制は頻繁に増減はない（固定）
  • コストはエンジニアリングの場合、大抵、人件費に跳ね返るが体制は基本的には固定であり頻繁に上下するものでないので固定になるケースが多い。
  • 学びまでのリードタイムの人件費と見るのであれば、少ないにこしたことはない。結果的にコストはリードタイムそのもの。
• Delivery：出来るだけ短縮したい（伸ばさない、短縮すべき対象）
  • リードタイムそのもの
• Scope：一度にやる量を決めることでリードタイムが結果的に変わってくる
  • 大きくする（大きなバッチ）と、リソース効率性のバイアスがかかるため、一括でリリースは出来るが、デリバリまでのリードタイムは増える（前述の図の上側レーン）
  • 小さくする（1個流し）と、フロー効率性のバイアスがかかるため、小出しにはなるがデリバリまでのリードタイムは小さくなる（前述の図の下側レーン）

QCDは調整ネジではなく、リソース効率性とフロー効率性が調整のネジ

この文脈においてQCDは基本的に変数ではなく、ほぼ定数として扱うことになる。全部大事。そして、デリバリは早ければはやいほどいい。そこで調整ネジというか変数になってくるのがScopeで、一度に開発する(同時にリリースされる)対象の量とサイズがそれにあたる。それにより、リードタイムが上下する。 調整ネジとは言え、学びへのリードタイムを短くしたいので、フロー効率性を高める選択をしたほうがよいのが本音。

チームが一度に行うタスク量が多い/サイズが大きい場合

一度に開発する量が多い/サイズが大きいと、並行作業が発生する。チームメンバは担当する機能が割り当てられ、それぞれ別々の機能の開発をする。つまり、この時点で、チームは前述の以下の図の上側レーンを選択したことになる。例えば、プロダクトオーナーから起案された機能要望がとてつもなく大きいとかがこれにあたる。エンジニアは本能的に下記図で上側レーンのようにリードタイムが増えることを感じ、「もっと分割できないですか？」「必要最小限にできないですか？」ときいたりするが、「これ全部必要です。」といわれることが経験上あるはず。しかしながら、これに対して「エンジニアチームの生産性が悪い」「なかなかリリースされない」みたいな意見がでたりもする。この状況を作り上げている「１つ」の要因はバッチサイズの大きさである。しかし、これはチームがそうなることを選んだのである。POやプロダクトマネージャーはチームに大きな塊を渡した時点で、渡した側も何が起きるか、どういう選択をしたのかを把握しておく必要がある。

This is Leanの P21にはリソース効率性に振り切っている状況を以下のような図で説明されている。1つのリソースにフォーカスして、そのリソースが与えられる稼働を100% になるように複数のフローユニット（タスク）に分割する。

部分的にリソース効率性が求められる場合はある

• どうしても一括でまとめて処理しないとならない場合
  • 手動でしかテスト出来ない部分、データセット上、まとめて確認したほうが早いような場合
  • 承認印が必要でなおかつ承認者が特定のタイミングでしか捕まらない。承認者のリソースに空きがうまれたタイミングで一括で処理してもらう必要がある場合。
    • 【余談】大抵ここがボトルネックになってくるため、制約理論を活用することになる。
    • 【余談】最終的には改善していくとこの承認行為自体が不要になる場合もある（権限委譲等により）
      • 権限委譲については、いろいろなやり方がある。エンジニアリングにより、安全に失敗できるインフラを構築できればその枠内では権限委譲できる等。
        • 例えば、自由にアイデアをリリースしたい場合、Feature Toggleを用いて、社内のメンバのみに公開する設定で実装。ドックフーディングをして、問題なければユーザの10%に公開。そこで問題なければ全体公開等。これはエンジニアリング＆インフラにより権限委譲を可能にするパターン。
        • もしくは、マイクロサービスアーキテクチャにて売上をあげている単位でマイクロサービス化（アーキテクチャレイヤ分割というよりは、ドメイン分割）。これにより売上責任を持ったクロスファンクショナルチームは、売上をあげる責任を持つと同時にプロセス権限が委譲される。

チームが一度に行うタスク量が少ない/サイズが小さい場合

一度に開発する量が少なく、サイズが小さい場合、チームは1つのことにフォーカスできる。例えば1つの機能を全員で実装する。すると複数の機能を全員で実装していた場合よりも、とある1つの機能は学びまでのリードタイムが短くなる。下記図の通りである。また、チームへ渡される要件のスコープが小さければ小さいほど、チームの見積もりの確度は高まる。更に、チームは自分たちの本来の適正な生産性で作業を実施できるようになる。

This is Leanの P21には以下のような図で説明されている。1つのフローユニット（機能）にフォーカスして、その1つのフローユニットが受けられるリソース時間を最大化する。

フロー効率性を向上させるプラクティスや事例

• カンバン（トヨタ生産方式）
  • 一個流し（トヨタ生産方式）
    • WIP制限にて流す量を減らす（最適化する）
    • WIP制限1にすることが目的ではない（最適な値にする）
    • WIP制限を小さくすることのメリット・デメリット
      • メリット
        • フロー効率性に特化した改善が行いやすい。ボトルネックが可視化しやすい。
      • デメリット
        • WIPを1に制限すると生産ライン上のどこかでトラブルが起きた場合、後続ラインが全面停止する。デメリットではあるが、必ず異常事態を検知でき、後続に不良品が流れないと考えるとメリットでもある。
• ペアプログラミング
  • 二人で1つのことをするため、二人で別々のことをするよりも流れるものの数が半分＆品質が上がる（副次効果で引き継ぎが不要になり、結果的に誰でもどんな作業もプル出来るようになる。こちらもフロー効率性に寄与する。）
• モブプログラミング
  • ペアプロのフロー効率性の極値振り型
  • 「あなたが売っているのは、キー入力だろうか？それとも完成した機能だろうか？」 by カンバン仕事術*3 P112
• Github-Flow & Feature Flagのコラボ
  • FeatureFlagを仕込んだプルリクのMasterマージで本番環境への自動デプロイ
  • 断片でのプッシュが可能になり、プルリクが小さくなる
  • 流れるもののサイズを小さくする効果（フロー効率性）
  • 対してGit-FlowはReleaseブランチが若干一括処理でありリソース効率性がある。
• 継続的ビルド＆テスト＆インテグレーション
  • フィードバックループの短サイクル化
  • 早く間違いに気づく
  • 手戻りの最小化
• マルチタスクをやめる
  • カンバンのWIP制限の話と同義
• バリューストリームマップ
  • バリューストリームマップにて、プロセスタイムとリードタイムを可視化。ムダを特定しフローを改善。
• クロスファンクショナルチーム
  • 他組織とのやりとりは基本的にバッチ処理になりがちであり、引き継ぎのムダが発生する。それの排除。
• フルスタックエンジニア
  • クロスファンクショナルチームの人バージョン。1人で全部できれば待ちのムダが省ける。フルスタックはある文脈では（笑）とされるが非常にフロー効率性が高い。
• etc

まとめ

仮説検証型でプロダクト開発を行う場合、学びまでのリードタイムを如何に短くするかが重要であるのはもう自明ではあり、目指す方向は「一個流し」(フロー効率性：高)である。しかしながら「目指す」のであり「目的」ではないのがポイント。フロー効率性の極値である「一個流し」を目指すことで様々なムダが浮き彫りになり、それを解消していくと、結果的にリソース効率性も高まるのである。

• フロー効率性（流す量を減らす）をあげると、ライン上にタスクまちの人が増えて、何もしない人がうまれる。（リソース効率性悪化）
• リソース効率性（流す量を増やす）をあげると、ライン上に人まちのタスクが増えて、リードタイムが増える。（フロー効率性悪化）

エンジニアリングに読み替えると、チームに渡される玉の量とサイズの大きさと、それを全員で一個を倒しに行くのか、ばらばらにそれぞれのタスクをこなすのか。一般的にプロダクト開発においてプロジェクトマネジメント上QCDが調整ネジに扱われるが、SoEな文脈においてはフロー効率性とリソース効率性（ チームに渡される玉の量とサイズの大きさ ）を調整ネジにすべき。従来の鉄板(だと誤解されていた)だった品質すてて速度あげようは 品質は劣化すれば手戻りが発生するだけで、結局はリードタイムの増加に跳ね返る のでやめましょう。

結果的に、カンバンやスクラムがWIP制限だのプル型だのいっている理由やスコープで調整軸にするというあたりまえの話に結局戻ってしまったが、一周回って？基本を理解できたのでよかった。

*1:以下でバイモーダル戦略やSoE/SoRについて触れています i2key.hateblo.jp

*2: Amazon CAPTCHA

*3: カンバン仕事術 http://amzn.to/2rfmwHUamzn.to

Modern Agile 入門 #modernagile

完全に出遅れ感ありますが、モダンアジャイルが気になってきたのでちょこっと自分の中で理解のために整理をしてみました。モダンアジャイル自体にプラクティス厨やめろというメッセージが含まれているかとは思いますが、とは言え、本家 Modern Agile - Industrial Logic でもある程度はプラクティス風な記載はされているので同様にやるべきこと、やるとよいことをプロットして思考を整理しました。箇条書きで見にくいかとは思いますが、あくまで自分用なので。今後追記編集していくかもです。テキトーに自分用メモとして書いただけなので間違ってたら指摘ください。また、入門というタイトルは自分が入門しただけなので、入門者のために書いてるわけではないのであしからずw 各プラクティスや方法論は理解してる前提で箇条書きしてます。

Modern Agileの位置づけの理解

ここにプロットされている諸々の方法論については、アジャイルもDevOpsもリーンスタートアップも特定のスコープのスループットを最適化する話であり、以下の記述からもわかるようにModern Agileのスコープが従来の方法論のスコープを包含しにいった印象。ただ、ビジネス側への染み出しからいうと、人々を最高に輝かせる(Make People Awesome)というメッセージをどこまで視座高く理解しスコープを広げるかで、上記図中でのカバー領域はもっと左へ染み出していくかとは思います。

• 人々を最高に輝かせる / Make People Awesome
• 安全を必須条件にする / Make Safety a Prerequisite
• 継続的に価値を届ける / Deliver Value Continuously
• 高速に実験・学習する / Experiment & Learn Rapidly

となると、今までやってきたことの悪魔合体をしたくなる。というわけで、脳内整理メモ。基本的には過去に書いたポエム DevOpsはエンタープライズからスタートアップへの横恋慕 #devops #プロダクトマネージャー #leanstartup - @i2key のBlog の広義なDevOpsに近似しているけど。

人々を最高に輝かせる / Make People Awesome

プロセス

• デザイン思考
• 顧客開発プロセス
• ユーザーストーリーマッピング

システム

人（スキル/スタンス）

• 人々を幸せにするものを作る
  • カスタマーの理解
  • クライアントの理解
  • ビジネスの理解
    • ビジネスモデル
    • ビジネスフェーズ
    • ビジネス戦略/戦術
• 開発者を幸せにする（Developer Experience）
  • 適切な技術的チャレンジ
    • 最新の技術ではなく、最適な技術の選択
  • HRT文化
    • コードを憎んで人を憎まず
• 顧客開発の理解

安全を必須条件にする / Make Safety a Prerequisite

プロセス

• 早期失敗のハンドリングするプロセス
  • コードレビュー
    • 小さなプルリク
      • 関連（CD & Feature Flag）
  • ペアプログラミング
• 品質マネージメントプロセス
  • 確立したテスト戦略・計画
  • バグトリアージ
  • バグマネージメント
• インシデントマネジメント
  • 障害時運用フロー
  • セキュリティ運用フロー
• 失敗を非難しない振り返り

システム

• 安全に失敗できる環境の構築
  • SplitTest(ABtesting)
  • CanaryTest
  • FeatureToggle
• 事前に不具合を検出する仕組み
  • 自動テスト＆CI
  • 自動テストの品質管理
    • Mutation Testing
  • Chaos Monkey
• 馬鹿でかい本番リリースの恐怖からの脱却
  • Feature Flag
  • Dark Launch
• 不安を取り除く
  • リファクタリング
  • TDD

人（スキル/スタンス）

• 一人前のエンジニアリングスキル
  • 若手エンジニアの育成
    • コード品質担保
    • 機能要件、非機能要件の実現
    • 開発プロセスの理解

継続的に価値を届ける / Deliver Value Continuously

プロセス

• 組織構造
  • スモールチーム
  • クロスファンクショナルチーム
    • マイクロサービス
• 継続的にデリバリー出来るためのプロセス
  • タスクマネージメント
    • 理想：一個流し
    • 現実：スクラム
    • 現実：カンバン
  • リリースマネージメント
    • リリースカレンダー
    • リリーストレイン
• リードタイムの削減
  • VSMによるムダの可視化
  • プロセスタイム、ValueAddTimeの可視化、定義

システム

• アーキテクチャ分離
  • コンウェイ
• DevOpsプラクティス
  • Infrastructure as code
  • 自動テストの徹底
    • C0/C1カバレッジ
    • テストカバレッジ
      • UnitTesing
      • IntegrationTesting
      • HumanTask
  • 静的解析の徹底
    • 複雑度、凝集度、コード解析
  • CI/CD環境の構築
    • 継続的インテグレーション
    • 継続的デプロイ
    • ビジネスチームへリリースボタンの提供
      • いつでもリリース可能
  • モニタリング
• Feature Probe

人（スキル/スタンス）

• TPS/LEAN/TOCの理解
• フロー効率性の理解
• DevOpsの理解

高速に実験・学習する / Experiment & Learn Rapidly

プロセス

• 仮説検証型プロセスの装着
  • バックログ
    • 仮説
    • 仮説を実証するために必要な条件
    • そのために必要なデータ
    • データの収拾方法
    • そのためのMVP
    • そのためのコストと時間

システム

• （「安全を必須条件にする」がシステム面を担保）
• 実験結果を計測する環境の構築
  • 実験が正しく行われるための調整
    • ファネル分析
  • 機能追加単位での検証結果モニタリング(マーケ施策の影響受けない)
    • コホート分析
• ダッシュボード
  • 継続率|ChurnRate
  • 機能単位利用率
  • CVR
  • CAC|LTV
  • Leadtime to Learn
  • Leadtime to Launch
  • Leadtime to fix bug
  • etc

人（スキル/スタンス）

• LEANSTARTUPの理解
• プロダクトマネージメントの理解
• PDCAを回すスキル
• MVP設計スキル（仮説を検証するための必要最低限の実装）

ビジネス貢献するためのエンジニアリングの話をデブサミでしてきた #devsumi

Nintendo switchの初期不良を引き当てたので、ゼルダをやるために開けておいた予定がなにもすることなくなってしまったのでブログを書いた。私のswitchは今頃京都にあるでしょう。

Developers Summit 2017 でコンテンツ委員しつつ登壇もしてきた

もともとは、デブサミオーガナイザの鍋島さんからコンテンツ委員としてお声がけ頂き、今回はコンテンツ委員という立場でデブサミに関わっていました。 そのため、コンテンツ委員が登壇とか自作自演感甚だしいので自分が登壇するつもりはまったくなかったのですが、GuildWorks -ギルドワークス-の市谷さんから越境をテーマに株式会社ヴァル研究所の新井さんと自分の3人でやりませんかとお誘いを受け、以下で登壇することに。

「新規事業が対峙する現実からエンジニアリングを俯瞰する」

新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi from Itsuki Kuroda

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されたひとりです。まことに….感謝ッ…！！！

新規事業のグロース期を支えるエンジニアリングについて

このブログは 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) から引用

そして、以下が自分が担当しているチームでのやるべきことをリストアップしたものになります。これを元に、最上位のレイヤー（デプロイ回数）をチームの目標としています。箇条書きで醜くて申し訳ありませんが、そのままコピペしておきます。

仮説検証の速度の最大化（チーム目標：デプロイ回数/日）

• プロセスタイムの削減
  • 個人の開発スキル向上（若手とかはここらへんも目標にするとよい）
    • スキルマップ
    • ペアタスクによる学習
  • プロセスタイム増加の要素を増やさない
    • 技術的負債つくりこまない
      • 静的解析によるゲートウェイ
        • Sonar/Rubocop/Coverage
      • コードベースを小さくシンプルに保つ
        • 機能を増やさない
          • 機能毎のMAUやDAU等も見て判断できるようにする
        • コードレビュー
          • コードレビュー負荷軽減
            • 小さなプルリク
      • 無理なリリース計画を置かない
        • 納期優先型チケットの場合は、次スプリントで必ずリファクタリング実施
• リードタイム削減
  • 組織改善
    • クロスファンクショナルチーム
      • 部門間の引き継ぎのムダを省く
      • 部門間の待ちのムダを省く
    • フルスタックエンジニア
      • チーム内の個人間の引き継ぎのムダを省く
  • プロセス改善
    • 大きなバッチサイズから小さなバッチサイズへ
      • タスクを管理するのではなくペースを管理する
        • カンバン、スクラム
          • タスク切り替えのムダを省く
        • リリースカレンダー
        • WIP制限
        • スコープボックスではなくタイムボックス
        • プル型のタスク管理
    • 自動化
      • 直接顧客価値を作らない作業(Value add time = 0)の最小化
        • 継続的インテグレーション
        • テストコード維持（悪化させない）
        • インフラコードを維持（悪化させない）
        • デプロイ自動化
        • 分析・集計自動化
      • 各種マーケ施策の自動化
        • マーケ担当者がエンジニアに依頼して、エンジニアが作業をするようなケース。同様の依頼が複数回発生したら運用を自動化する。
          • 特定のセグメントに対して通知やメール送信をしたい。
          • 特定のセグメントに対してキャンペーンコードを発行したい。
            • 引き継ぎによるムダ/待ちによるムダの排除
        • 営業担当者からの依頼のケースも同様
• 安定運用
  • 未然防止
    • セキュリティ
    • システムモニタリング
    • 自動復旧
  • 事後対応
    • トラブル対応フロー
      • 障害レベルの切り分けロジック
    • etc

仮説検証の質を最大化

前述のバリューストリームマップを同様に用いて説明します。仮説検証の質という観点で最も大事なのは、このプロセスのフローに投入する玉の質、つまりは仮説の質が良いことです。ニーズに合致していないものを高速で作れたとしてもゴミを生むだけで、しかもそれだけではなく、コードベースは肥大化していき機能が使われないどころか自分たちの生産性までも下げることになってしまいます。これはまさに余分な機能のムダになります。それを防ぐためにもエビデンスに基づく仮説構築の支援をエンジニアリングにて実施する必要があります。基本的には、各種分析基盤の実装です。また、各仮説検証の結果をパラレルで走っている検証の結果が混ざって濁らないような効果測定も必要です。

また、既存のユーザーベースを壊すことなく安全に仮説検証の実験を行うための仕組みづくりも必要です。具体的にはユーザーを任意のクエリや属性にてセグメントする仕組み、また、そのセグメントに対してリリース機能の出し分けをする仕組みが必要です。そしてそのセグメント毎に公開した機能単位で分析ができることが必要です。ここらへんの仕組みは最近ではSaaSを使えば大抵オールインワインで備わっています。これらの仕組みがある状況であれば、仮にリリース後に問題が起きた場合も、機能単位で切り戻しも可能になるため、欠陥によるムダ への対策にもなります。

以下に仮説検証の速度の最大化と同様に質に関するやるべきことの箇条書きをコピペしておきます。

仮説検証の質の最大化

• LEARNの質
  • 仮説の質
    • エビデンス
    • 学びの質をあげる仕組み
      • チケットのフォーマットの改善（MVPキャンバス化）
  • ユーザーフィードバック
    • 各種分析
    • カスタマーサポート記録のデータベース化
• MEASUREの質
  • 計測の基盤があること
    • ダッシュボード
      • ビジネス&システム
        • BMLループの時間（学ぶまでのリードタイム）
          • プロダクトバックログに起票されてから、検証されるまで
      • システム
        • 各種システムパフォーマンス
          • CPU/NETWORK/RESPONSE/etc
        • ビルド時間
        • 自動テスト時間
        • デプロイ時間
      • ビジネス
        • ファネル分析
          • 離脱率（or Churn Rate）
            • P/S FITにおけるズレの側面
              • ファネルに流すユーザの質に左右される
            • エンジニアリングで改善可能な部分
        • コホート分析
          • カスタマーセグメント毎の各種数値
            • 流入経路別の各種数値
              • ノイズを排除し純粋にプロダクトの力を計測する
                • 営業/マーケ獲得セグメント別の結果等
          • リリースバージョン毎の各種数値
          • 実装機能毎の各種数値
        • Gross Revenue
        • LTV/CACグラフ
          • ユーザーセグメント毎のLTVとCACの関係性
        • Churn rate
        • その他各種KPI
  • 安全な検証環境
    • 既存のユーザへの影響を最小化
      • ユーザーをセグメントする機能
        • ウェブコンソール上でSQLないしUIにて、特定の条件に関するユーザセグメントを作ることができる
    • Feature Flag
      • ユーザーセグメントに対して機能の出し分けを可能にする
        • Private Beta Test
        • Dark Launch
    • A/Bテスト基盤
    • カナリヤテスト
    • ブルーグリーンデプロイメント
• BUILDの質
  • 各Featureの設計・実装・テストにおけるQCD
    • ペアプロ
    • ペアタスク
    • コードレビュー
    • 自動テスト
      • ユニットテスト
        • カバレッジ目標
      • Featureテスト
        • カバレッジ目標
      • E2Eテスト

まとめ

本ポストでは、便宜上バリューストリームマップの例で解説をしていましたが、本来は各チーム毎にバリューストリームマップを作成し、ボトルネックになっている部分を探し、解消することが大事です。例えば、ボトルネックじゃない部分をいくら解消しようが実は全体的には効果がないこともあります。そしてボトルネック解消には時には技術以外での解決策も必要であったりします。個人的には、TPSや制約理論を学ぶのが最も効果があると思います。そして、それらを意識しながら、下記を実現していくことになると思います。

• 当たり前品質を確保しつつ、ユーザーが既にいる状態で売り物で仮説検証をしていくため、エンジニアリングとしては、既存のユーザーベースを壊すことなく安全に仮説検証が出来るしくみを作ること
• トライするスピードをスローダウンさせることなく更なる仮説検証の高速化を目指すこと

以上です。

プロダクト開発を内製化やアジャイル化する際のどこからはじめるかの勘所の話 #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モデルがありますがこれが一番イメージしやすいです。

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

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

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

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

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

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

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

AlignmentMap

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

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

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

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

最初はマルチロールエンジニア、グロース期にはフルスタック、その後はプロフェッショナルというのは、午前に紹介した開拓者、入植者、都市計画者と移っていく話につながってるみたい。そうすれば組織内でまわせるという話 https://t.co/ifb0pq6QE6 #postudy

— YASUI Tsutomu (@yattom) 2016年11月26日

まとめ

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

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

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