組織に流れるフォースを間接的にコントロールする仕事
Recruit Engineers Advent Calendar 2018 - Adventar ということで、エンジニアリングマネージャー的なことを書いてみます。1on1とか採用とか評価制度とかではなく、組織力学のような話を。
フォースを感じる
自分は普段からエンジニア組織をマネジメントする際に「構造によって発生する力学」をすごく意識しています。いま、大体100人弱の社員エンジニア組織をマネジメントしているなかで、役割上、判断する仕事がかなりの割合をしめます。その判断でどんな力学が発生して最終的に現場で何が起こるかまで可能な限り想像力を張り巡らさないとならないです。そして、この想像力において、どれだけ解像度を高くできるかこそが現場感だと思います。経験がないと何がおこるか想像すら出来ないと思うので。
ビジネスにおける意思決定で発生したフォースは徐々に伝搬し、最終的にエンジニアの現場に流れ込んできます。このフォースがどのように伝搬してくるかを見る能力がとても大事であり、これが無いと、本来、事業を加速させようとした意思決定も現場に伝わるころには、まったく逆のフォースを発生させてしまい、スピード感を失ったディフェンシブなものにすり替わってしまったりします。
具体的な例で話したほうがイメージ付きやすいと思うので以下に想像ベースで書いてみます。
スタートアップや社内新規事業のアーリーステージにおいて過度な売上目標をチームに持たせようとした場合
例えば、スタートアップや社内新規事業のアーリーステージにおいて、さらなる成長の加速を願い、過度な売上目標をチームに持たせようとした場合なにが起こるのか。
サービス初期のプロダクトの価値が実証されていない状態（バケツに穴が空いた状態）においては、例えば売り方（売上）ではなく売り物（プロダクト）の力のみで結果をコントロールできる数値（継続率や成長率)を目標にすべきなのですが、ここで強い売上目標を組織に持たせると、チームは売上の単価やグロスをあげるために、売り物(プロダクト)ではなく売り方側をチューニングしアップセルやクロスセルをどうしてもしたくなります。そのほうが短期的に数字を作りやすいから。くどいですが、本来であればこのフェーズは売り方ではなく売り物をチューニングし、顧客の課題を確実に解決できるプロダクト(バケツの穴を塞いだ状態)に仕上げたほうが全体的には手戻りが減り事業成長の点で効率が良いです。売り方(水の流し方)のチューニングはそのあとの話。
しかしながら、売上を目標に持ってしまっているので、そうもいかず。仮にtoC向けサービス(薄利多売)であった場合は、急速にtoB(顧客単価高)へと販売戦略を変えたりすることもあります。ここで現場で発生することは、プロダクトのフェーズ（バケツに穴あいているtoC向けサービス）と、ビジネスの強いられているフェーズ（アップセルクロスセルによる売上最大化）にミスマッチを起こします。どんなに送客しても、toCプロダクトをtoBに売ったところでチャーンレートが高い状態(バケツに穴あいたまま)なので顧客は継続せず漏れていきます。また、それを防ぐために焦って、toBむけエンタープライズな仕様や機能がどんどん追加されていきます。ベースがtoCであったシンプルなサービスはあとから十徳ナイフのように機能がもりもりにされていき、コードベースは肥大化していき、開発のフットワークはどんどん悪くなっていきます。そして悲しいことにこの肥大化したコードベースの6割は使われない機能だったりします。P/L上もシステム投資における資産が積み上がり残存簿価まみれになり、減価償却費が根雪構造的に積み上がり自分たちのできることが徐々に制限されていきます。この最初の力学を発生させたポイントは、「アーリーステージの組織にフェーズに見合わない売上目標を課したこと」になります。
そのため、最初の組織の目標設定のタイミングで、どのような力学が発生するかを解像度高く想像を巡らせる必要がありますし、わかる限りその段階で正すことが求められます。まさにエンジニアリングマネージャーの嗅覚が必要とされる部分だと思います。
サービスの能力以上の資金調達する場合
同様なものに、例えば次の例もあります。 サービスの能力以上の資金調達(社内|社外)するというケースです。基本的には前述と同じ構造ではありますが、調達額（投資家からしたら投資額）に対して、どうしても期待が高くなります。すると、期待値に見合うように目標を高く設定するバイアスが発生します。「こんなに投資してそのリターン？」となってしまうので。そして、チームはそのゴールに向けた数値の積み上げが始まります。そこから逆算した無理なエクセル上の計画が立てられ、プロダクトはそれにそった計画駆動型の開発モデルになっていきます。
開発「側」は計画通り作り上げることが目標になり、柔軟な変更を弾き返すようになります。プランニング「側」と開発「側」の壁が強くなっていきます。どうしても、プランニング「側」は目標に向けた計画を遂行したいがために、仕様を押し込みたくなるし、開発「側」はそれをディフェンスしたくなる。ギスギスしだす。開発「側」は「仕様が決まってないので作れません」となる。更に開発「側」は計画を守るために、バッファを計画上にたくさん盛り込みだす。つまりは、やれることをバッファ分だけ自ら減らしていく構造を作り上げる。そして、基本的にバッファは使い切ってリリースを迎えることになる。結果的に自分たちのできる総量を、自ら低下させ成長をスローダウンさせていくことになる。仮にスタートアップだったら、最終的にダウンラウンドを招くことにもなります。 これも、最初の力学を発生させたポイントは「サービスの能力以上の資金調達」するという決定によって発生する組織力学です。起点は、ちょっと背伸びしたかっただけなのかもしれないのですが、巡り巡ってこんなはずじゃなかったという結果につながるかもしれません。
スクラム開発において個人のベロシティをモニタリングする場合
若干上記の例が、ビジネスビジネスしてたので、もう少し開発現場よりの例も上げてみます。 より開発現場の生産性をあげるために、チームのベロシティだけでなく個人のベロシティも日々モニタリングするようにしようという提案があった場合。 例えば、エンジニアは自身のベロシティが自身の業績評価につながると思ってしまうかもしれない。そうなると、多めに見積もったほうが生産性は高く見えるようになる。もしくは、見積もりよりも時間が掛かりそうな場合に、低品質でもおわりにしてしまえという考えが出てくることもある。さらに、相互のメンバ間の助け合いもおきなくなっていく。人のこと助けても自分のベロシティあがりませんし。と。流石にこれらは極端な例だとは思いますが、正しく合意形成や目的の共有がなされていない状態でこの決定を下すと、現場には少なからず間違った力学が発生してしまうことがあります。
エンジニアリングマネージャーとしてフォースを間接的にコントロールする
最初から上記にあげているような構造のパターンを知っていたわけではないので、実際にはシステム思考をベースに複数の類似した経験から因果のパターンを抽出して自分の引き出しとしています。（無意識的にやっていて、同じような事象に遭遇したときにひらめく感じ。） なんでも構造として捉えるのがもともと好きなので、その思考方法が癖になっていて、iPadで日々お絵かきをしています。ただ、自分は別にパターン・ランゲージの熟練者でもなんでもないので、なんとなくやってます。
エンジニアリングマネージャーとしては、ビジネス上の判断が力学としてエンジニアリングの現場にどのような形で伝搬するのか、逆に伝搬させないようにするのかを見極め、ビジネス上もっともアウトカムへのスループットを最大化させるように対策を講じる必要があると思います。 基本的に構造によって発生する力学なので、その流れるフォース自体はコントロールしにくいですが、力学を発生・加速・減衰させる構造側はコントロール可能なので、構造をコントロールしてマネジメントしていくことになると思います。例えば、ビジネスモデル、目標の構造（KGI-KPIs）、予算の構造（ポートフォリオ）、それに紐付いて作られる組織構造、それに紐づくシステムアーキテクチャ、開発プロセスなどです。 例えば、経営層が経営指標をEBITDAにするとメッセージングしたときに、開発の現場では何がおこるかとか考えてみると面白いかもしれません。
また、自分が大切にしているのがこの力学を逆手にハックして利用していくことです。その力学を逆にうまく使って自分のやりたいこと、都合のよいことをフォースの流れに混ぜ込んでのせてしまう。そうすると施策が一気に進んだりします。デメリットがない場合、コトを前進させるのにはフォースの流れを利用してしまえと思っています。
こんなことを考えながら日々、エンジニア組織をマネージメントしています。
「再発防止策はチェックリストによる目視確認」から考えるアウトカムフォーカス
「再発防止策はチェックリストによる目視確認」
開発の現場において、大きなシステム障害が発生したような場合に原因究明から今後の再発防止策を検討することがよくあるかと思います。
そこでよくある議論として、
とあるエンジニア「エクセルでチェックリスト作って今回の確認観点を追加します！今後はリリース前確認でかならず目視でチェックリスト確認を実施します」
ベテランエンジニア「んなことやってたら、チェックリストが永遠に増えていくからやること増えるだけだろ。もっと工夫なさい。チェックの自動化をしなさい。」
みたいな光景です。
ただ、これ実際に再発防止の効果が出るまでのリードタイムというポイントで見ると一般的にスジが悪いとされているチェックリスト的なやつですが、とあるエンジニアの案ほうが今すぐ対策を講じることができるので良かったりするなあと最近思うようになってきました。あくまで暫定的な再発防止対処としてですが。 目的は、「同じことが今後も発生しないこと」「それを事前に食い止めること」、であり、「自動化して確認が楽になること」ではないのですが、どうしても技術的な正しさやエンジニアとしての美学が目的ベースの判断を歪めることがあります。
再発防止に求める効果効能と時間軸による変化
さくっとチェックを自動化できるような場合は最初から自動化すればよいのですが、例えば、それが難しいような場合、エンジニアの美学としてのコードで解決することに時間を溶かすよりも、まずは原始的であろうが実利を即得られる方法を選択するほうが良いです。その対策を実装している間にまた類似システム障害が発生したら意味が本末転倒なので。
STEP1 まずは実利の即効性（フロー効率的）
まずは即効性が重要なので、一番早いやりかたを選択したほうがよいと思います。今すぐできることが重要なので。それがエクセルチェックリストならそれでもいいですし。そして、本来の目的を達成してから、あとはそれを今後N回繰り返していくときの効率面の問題に対処していくのが良いと思います。（Lintに定義追加する程度とかの問題ならSTEP2からでいいです。） よくありがちなのがテストを自動化すればいい！という対策で、これ事態は別に悪くなくむしろ自分もそうしたいのですが、開発の文脈を無視したこの手の解決策をうつと問題がおきます。本来すぐ防止策を打ちたいだけなのに、いざテストコード書こうとすると、おやおや、クラスが大きいな・・・、メソッドも細かく切られていないしテストコード自体が複雑になるなあ。。。これなら、まずはリファクタリングしないとなあ、、、さあ、どこからなおしていくかな。みたいなことが起こりがち。リードタイムが長くなる一方。それは後述のSTEP2でやりたい。まずは目的を今すぐ果たしたい。フロー効率性重視でやりたい。
※ フロー効率性やリソース効率性の考え方はこちらを参照ください。 i2key.hateblo.jp
STEP2 今後の作業量の効率性（リソース効率的）
一旦、イケてない方法にしろ再発防止という目的を達成したのであれば、次にN回繰り返すときのことや、人力作業による手戻り発生等の物理的な無駄を排除していくことになります。やりかたはコードによる自動化とかがメジャーだとは思います。もしくは、そもそも仕組みを組み直して、そもそも問題が発生しない構造にしてしまうとか。とはいえ、それなりのリードタイムを要する行為かと思います。もしくは、カネで解決するためにアウトソースで実施することもあるかもしれません。こちらはリソースの効率性の文脈が強いと思います。カイゼンは最終的には実利を得つつもやることが減っている状態だと思っているので、ここまできてカイゼンはDONEではあります。また、この場合は、恒久対応までDONEすることをマネジメントすることは言わずもがな必須です。運用がゴミまみれになり負債化するので。
今回の件はイメージにすると以下です。
まずは実利をリードタイム最短で取りに行き、その後、スケールしやすいように作業の効率化をしていくイメージです。
普段の何気ない意思決定に介在するアウトカムフォーカス
ポイントは目的を意識した上で、STEP1とSTEP2双方を意図的に実施することです。何度もいいますが、STEP1を絶対非効率なやりかたでやれと言っているわけではなく、即効性のある方法をとるとよいという意味なので、手動目視チェックリストで絶対やれという意図ではないです。そして、この何気ない意思決定および行動の積み重ねが開発組織の文化につながっていくと思います。チェックリスト文化だけも良くないですし、文脈を無視した自動化文化も良くないと思います。まずは最短のリードタイムで実利をとり、そのあと効率化していけると良いのではないでしょうか。本件の障害対応においては、まあ、普通に暫定対応と恒久対応なだけの話なのですが、このパターンって結構あるなあと感じたのでブログにしました。例えば次の類似ケース。
類似ケース
例えば、開発における案件のリリースまでのリードタイムを改善のために計測しようとしたときに、目的でいうと「リードタイムの可視化」なので、メンバ全員に聞いて回って模造紙にまとめるでも即効性があればなんでもいいのですが、自分も含めてですがどうしてもタスク管理ツールのAPIリファレンスを覗きだし、自動でチケットの日付とステータスの推移を抽出できないかとか悩みだすんですんですよね。で、運用がうまくされていなくてチケット管理ツールから自動抽出できないとなると、うーん・・・・、となってまた別の技術的解決方法を探しに行ってしまう。で、本来の目的からどんどんそれていきなかなか可視化されないという事態に陥る。全員で集まって人力で計測した時間を模造紙に書き出すだけで一旦は解決するのに。 また、別のケースでいうとリーンスタートアップなどででてくるMVPとかもそれに近いかもしれないですね。
さいごに
サービス開発の現場では結構この手のことが多い気がしていて、また、本件の例のベテランエンジニアのようにHOWの指摘をしたくなるのもわかるのですが、そこは本質を意識しアウトカムにフォーカスし、得たい実利とHOWとリードタイムを天秤にかけながら判断をすべきだと思います。どんなにHOWが秀逸でも実利に繋がっていないとやっていないことと変わりないので。つまり、プラクティスの使い方がどうこうとかそういう話ではなく、本質的にはこういうことこそがアジャイルをしようとせずに、結果的にアジャイルであることなのではないかなと思ったりします。（高い技術力で高速に打ち手が打てる状態が最高ではありますが自分はそんな才能はないので。）
2017年のアウトプットまとめ
今年の振り返りがてら、オフィシャルな社外発表ベースの今年のアウトプットの雑なまとめ。大体0.5回/月の社外登壇らしい。
2017/02/16
www.slideshare.net i2key.hateblo.jp
2017/03/18
www.slideshare.net
2017/06/18
DevLOVE200 Bridge 上記デブサミの以下の焼き直し
www.slideshare.net
2017/09/16
www.slideshare.net i2key.hateblo.jp i2key.hateblo.jp
2017/11/01
www.slideshare.net
2017/12/14
Lean Startup Update! 2018 〜3年間のリーンスタートアップのアップデート会〜
www.slideshare.net
スライドが潰れて見にくい画像を補足。(これが正解とかではなく目的や文脈にあわせてこういう構造でいつも考えている感じ。)
THE STARTUP WAY翻訳 i2key.hateblo.jp
番外編
まとめ
みなさま今年もお世話になりました。来年もよろしくおねがいします。 告知としまして、来年は年始早々、Regional Scrum Gathering Tokyo 2018 のパネルディスカッションに機会がありまして出演させていただきます。
リーンスタートアップ著者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日目の記事でした。 さいごにバイモーダルとかマイクロサービスとかくっつけて、ギリギリエンジニアのアドベントカレンダー風に着地させましたが、弊社のエンジニアの中にはエンジニアリングの嗜みとして、ビジネス側もこうやってチョットだけ理解しようとしている人もいるんだよという多様性もアピールできれば。ではでは。
宣伝
というわけで、リーンスタートアップに関するイベントを馬田さんと角さんとやることになりました。もう人数がアレですが、よろしくお願いいたします！
フロー効率性とリソース効率性について XP祭り2017で発表してきた #xpjug
先日、開催された XP祭り2017 にて発表してきました。スライドは以下になります。
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で発表したので、補足を含め要点のみを抽出してリライトしております。
本ポストはプロダクト開発における特定の文脈によるものなのですべてがそうだとは言っていませんのであしからず。バイモーダル戦略でいうところの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% になるように複数のフローユニット（タスク）に分割する。
部分的にリソース効率性が求められる場合はある
- どうしても一括でまとめて処理しないとならない場合
チームが一度に行うタスク量が少ない/サイズが小さい場合
一度に開発する量が少なく、サイズが小さい場合、チームは1つのことにフォーカスできる。例えば1つの機能を全員で実装する。すると複数の機能を全員で実装していた場合よりも、とある1つの機能は学びまでのリードタイムが短くなる。下記図の通りである。また、チームへ渡される要件のスコープが小さければ小さいほど、チームの見積もりの確度は高まる。更に、チームは自分たちの本来の適正な生産性で作業を実施できるようになる。
This is Leanの P21には以下のような図で説明されている。1つのフローユニット（機能）にフォーカスして、その1つのフローユニットが受けられるリソース時間を最大化する。
フロー効率性を向上させるプラクティスや事例
- カンバン（トヨタ生産方式）
- ペアプログラミング
- 二人で1つのことをするため、二人で別々のことをするよりも流れるものの数が半分＆品質が上がる（副次効果で引き継ぎが不要になり、結果的に誰でもどんな作業もプル出来るようになる。こちらもフロー効率性に寄与する。）
- モブプログラミング
- Github-Flow & Feature Flagのコラボ
- FeatureFlagを仕込んだプルリクのMasterマージで本番環境への自動デプロイ
- 断片でのプッシュが可能になり、プルリクが小さくなる
- 流れるもののサイズを小さくする効果（フロー効率性）
- 対してGit-FlowはReleaseブランチが若干一括処理でありリソース効率性がある。
- 継続的ビルド＆テスト＆インテグレーション
- フィードバックループの短サイクル化
- 早く間違いに気づく
- 手戻りの最小化
- マルチタスクをやめる
- カンバンのWIP制限の話と同義
- バリューストリームマップ
- バリューストリームマップにて、プロセスタイムとリードタイムを可視化。ムダを特定しフローを改善。
- クロスファンクショナルチーム
- 他組織とのやりとりは基本的にバッチ処理になりがちであり、引き継ぎのムダが発生する。それの排除。
- フルスタックエンジニア
- クロスファンクショナルチームの人バージョン。1人で全部できれば待ちのムダが省ける。フルスタックはある文脈では（笑）とされるが非常にフロー効率性が高い。
- etc
まとめ
仮説検証型でプロダクト開発を行う場合、学びまでのリードタイムを如何に短くするかが重要であるのはもう自明ではあり、目指す方向は「一個流し」(フロー効率性：高)である。しかしながら「目指す」のであり「目的」ではないのがポイント。フロー効率性の極値である「一個流し」を目指すことで様々なムダが浮き彫りになり、それを解消していくと、結果的にリソース効率性も高まるのである。
- フロー効率性（流す量を減らす）をあげると、ライン上にタスクまちの人が増えて、何もしない人がうまれる。（リソース効率性悪化）
- リソース効率性（流す量を増やす）をあげると、ライン上に人まちのタスクが増えて、リードタイムが増える。（フロー効率性悪化）
エンジニアリングに読み替えると、チームに渡される玉の量とサイズの大きさと、それを全員で一個を倒しに行くのか、ばらばらにそれぞれのタスクをこなすのか。一般的にプロダクト開発においてプロジェクトマネジメント上QCDが調整ネジに扱われるが、SoEな文脈においてはフロー効率性とリソース効率性（ チームに渡される玉の量とサイズの大きさ ）を調整ネジにすべき。従来の鉄板(だと誤解されていた)だった品質すてて速度あげようは 品質は劣化すれば手戻りが発生するだけで、結局はリードタイムの増加に跳ね返る のでやめましょう。
結果的に、カンバンやスクラムがWIP制限だのプル型だのいっている理由やスコープで調整軸にするというあたりまえの話に結局戻ってしまったが、一周回って？基本を理解できたのでよかった。
*1:以下でバイモーダル戦略やSoE/SoRについて触れています i2key.hateblo.jp
*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
- 自動テストの徹底
- 静的解析の徹底
- 複雑度、凝集度、コード解析
- 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設計スキル（仮説を検証するための必要最低限の実装）