17:292019年振り返りTweet広告を非表示にする2018-12-302018年振り返り2018年みなさま大変お世話になりました。2018年は、マネジメントする組織のメンバ数が20人から100人へと拡大したことがあり、はじめてずくしの1年でした。そのため、基本的にはインプットの年で、社外登壇やアウトプット活動はほとんどしておりません。そんなのする暇がなかった・・・・。ゲームはかなりしました。ゲームの話と、数少ないアウトプットをまとめておきます。協調学習過程としてのスクラム。欲しいものを、どうやって知るか。川口さんから恐怖のパネルセッションのオファーを頂き、前回のPO祭りの当日丸投げ対策として事前に仕込んだ資料になります。Kurodaconfengine.comDevLove関西”効率が良い”を考えてみる〜フロー効率性とリソース効率性のお話〜大阪いきたいなー、なんか話すので。さんが以下のイベントを企画してくださり、大阪にたこ焼きたべにいきました。「ここだけアジャイル」という特集に掲載いただきました。「テスト特集」に掲載いただきました。ブログ今年はブログをまさかの2本しか書いていないのですが、両方とも普段からメンバーと1on1で話しているようなことで、それをそのままブログにするとはてブ数がそこそこつくのが意外でした。「再発防止策はチェックリストによる目視確認」から考えるアウトカムフォーカスシステム障害の対応から個別の対策ではなくどう組織知として還元していくかを考えたときに、この手のものは汎化して教訓化すると一気にスケーラブルになるので、そういうふうに捉えて振り返りをしています。同時に、それをパターンとして自分の引き出しとしています。i2key.hateblo.jp組織に流れるフォースを間接的にコントロールする仕事フォースという単語からはてなブックマークのコメントにスターウォーズ感がすごく出てるのですが、イメージでいうとパターンランゲージの文脈におけるフォースを意図していました。日本語に置き換えると、コンテキスト上に流れるニーズや力なのですが汎化させると傾向と言うとすんなり入るかもしれません。2018と2019のコンテンツ委員をやりました(2019は継続中)。Daylightでした。基本的にはホラーゲームのカテゴリで、殺人鬼(1人)とサバイバー(4人)で鬼ごっこして、脱出するゲームになります。鬼ごっこ&缶蹴り&けいどろ(どろけい)の悪魔合体のようなルールなので、幼少期にみながやったリアルな遊びをオンラインでやっているイメージです。つまらないわけがない。これを、会社で部活化し、みんなでやっております。ブログを書いてくれているのでそっちもどうぞ。Daylightやってる予定です。ボクササイズ会社のひとたちとb-monsterというボクササイズに通い出しました。2018年2月から開始して、未だに続いています。45分間ノンストップでのボクササイズは脳内がスッキリするし、汗びっしょりだし、結構いろいろな考え事できるし自分のルーチーンになりました。2018年8月27日クロアチア行ったクロアチアの様子です。2018去年に引き続きAgile2018に参加しました。新しい発見というよりは、自分の中での経験を抽象化して定着をはかるための場としてとても有用でした。いうことで、エンジニアリングマネージャー的なことを書いてみます。1on1とか採用とか評価制度とかではなく、組織力学のような話を。フォースを感じる自分は普段からエンジニア組織をマネジメントする際に「構造によって発生する力学」をすごく意識しています。いま、大体100人弱の社員エンジニア組織をマネジメントしているなかで、役割上、判断する仕事がかなりの割合をしめます。その判断でどんな力学が発生して最終的に現場で何が起こるかまで可能な限り想像力を張り巡らさないとならないです。この想像力において、どれだけ解像度を高くできるかこそが現場感だと思います。経験がないと何がおこるか想像すら出来ないと思うので。ビジネスにおける意思決定で発生したフォースは徐々に伝搬し、最終的にエンジニアの現場に流れ込んできます。このフォースがどのように伝搬してくるかを見る能力がとても大事であり、これが無いと、本来、事業を加速させようとした意思決定も現場に伝わるころには、まったく逆のフォースを発生させてしまい、スピード感を失ったディフェンシブなものにすり替わってしまったりします。具体的な例で話したほうがイメージ付きやすいと思うので以下に想像ベースで書いてみます。スタートアップや社内新規事業のアーリーステージにおいて、さらなる成長の加速を願い、過度な売上目標をチームに持たせようとした場合なにが起こるのか。サービス初期のプロダクトの価値が実証されていない状態(バケツに穴が空いた状態)においては、例えば売り方(売上)ではなく売り物(プロダクト)の力のみで結果をコントロールできる数値(継続率や成長率)を目標にすべきなのですが、ここで強い売上目標を組織に持たせると、チームは売上の単価やグロスをあげるために、売り物(プロダクト)ではなく売り方側をチューニングしアップセルやクロスセルをどうしてもしたくなります。そのほうが短期的に数字を作りやすいから。くどいですが、本来であればこのフェーズは売り方ではなく売り物をチューニングし、顧客の課題を確実に解決できるプロダクト(バケツの穴を塞いだ状態)に仕上げたほうが全体的には手戻りが減り事業成長の点で効率が良いです。売り方(水の流し方)のチューニングはそのあとの話。売上を目標に持ってしまっているので、そうもいかず。仮にtoC向けサービス(薄利多売)であった場合は、急速にtoB(顧客単価高)へと販売戦略を変えたりすることもあります。ここで現場で発生することは、プロダクトのフェーズ(バケツに穴あいているtoC向けサービス)と、ビジネスの強いられているフェーズ(アップセルクロスセルによる売上最大化)にミスマッチを起こします。どんなに送客しても、toCプロダクトをtoBに売ったところでチャーンレートが高い状態(バケツに穴あいたまま)なので顧客は継続せず漏れていきます。それを防ぐために焦って、toBむけエンタープライズな仕様や機能がどんどん追加されていきます。ベースがtoCであったシンプルなサービスはあとから十徳ナイフのように機能がもりもりにされていき、コードベースは肥大化していき、開発のフットワークはどんどん悪くなっていきます。悲しいことにこの肥大化したコードベースの6割は使われない機能だったりします。P/L上もシステム投資における資産が積み上がり残存簿価まみれになり、減価償却費が根雪構造的に積み上がり自分たちのできることが徐々に制限されていきます。この最初の力学を発生させたポイントは、「アーリーステージの組織にフェーズに見合わない売上目標を課したこと」になります。そのため、最初の組織の目標設定のタイミングで、どのような力学が発生するかを解像度高く想像を巡らせる必要がありますし、わかる限りその段階で正すことが求められます。エンジニアリングマネージャーの嗅覚が必要とされる部分だと思います。同様なものに、例えば次の例もあります。サービスの能力以上の資金調達(社内|社外)するというケースです。基本的には前述と同じ構造ではありますが、調達額(投資家からしたら投資額)に対して、どうしても期待が高くなります。すると、期待値に見合うように目標を高く設定するバイアスが発生します。「こんなに投資してそのリターン?」となってしまうので。チームはそのゴールに向けた数値の積み上げが始まります。そこから逆算した無理なエクセル上の計画が立てられ、プロダクトはそれにそった計画駆動型の開発モデルになっていきます。開発「側」は計画通り作り上げることが目標になり、柔軟な変更を弾き返すようになります。プランニング「側」と開発「側」の壁が強くなっていきます。しても、プランニング「側」は目標に向けた計画を遂行したいがために、仕様を押し込みたくなるし、開発「側」はそれをディフェンスしたくなる。開発「側」は「仕様が決まってないので作れません」となる。開発「側」は計画を守るために、バッファを計画上にたくさん盛り込みだす。やれることをバッファ分だけ自ら減らしていく構造を作り上げる。基本的にバッファは使い切ってリリースを迎えることになる。結果的に自分たちのできる総量を、自ら低下させ成長をスローダウンさせていくことになる。仮にスタートアップだったら、最終的にダウンラウンドを招くことにもなります。これも、最初の力学を発生させたポイントは「サービスの能力以上の資金調達」するという決定によって発生する組織力学です。起点は、ちょっと背伸びしたかっただけなのかもしれないのですが、巡り巡ってこんなはずじゃなかったという結果につながるかもしれません。若干上記の例が、ビジネスビジネスしてたので、もう少し開発現場よりの例も上げてみます。開発現場の生産性をあげるために、チームのベロシティだけでなく個人のベロシティも日々モニタリングするようにしようという提案があった場合。エンジニアは自身のベロシティが自身の業績評価につながると思ってしまうかもしれない。なると、多めに見積もったほうが生産性は高く見えるようになる。見積もりよりも時間が掛かりそうな場合に、低品質でもおわりにしてしまえという考えが出てくることもある。相互のメンバ間の助け合いもおきなくなっていく。人のこと助けても自分のベロシティあがりませんし。これらは極端な例だとは思いますが、正しく合意形成や目的の共有がなされていない状態でこの決定を下すと、現場には少なからず間違った力学が発生してしまうことがあります。エンジニアリングマネージャーとしてフォースを間接的にコントロールする最初から上記にあげているような構造のパターンを知っていたわけではないので、実際にはシステム思考をベースに複数の類似した経験から因果のパターンを抽出して自分の引き出しとしています。(無意識的にやっていて、同じような事象に遭遇したときにひらめく感じ。なんでも構造として捉えるのがもともと好きなので、その思考方法が癖になっていて、iPadで日々お絵かきをしています。自分は別にパターン・ランゲージの熟練者でもなんでもないので、なんとなくやってます。エンジニアリングマネージャーとしては、ビジネス上の判断が力学としてエンジニアリングの現場にどのような形で伝搬するのか、逆に伝搬させないようにするのかを見極め、ビジネス上もっともアウトカムへのスループットを最大化させるように対策を講じる必要があると思います。基本的に構造によって発生する力学なので、その流れるフォース自体はコントロールしにくいですが、力学を発生・加速・減衰させる構造側はコントロール可能なので、構造をコントロールしてマネジメントしていくことになると思います。ビジネスモデル、目標の構造(KGI-KPIs)、予算の構造(ポートフォリオ)、それに紐付いて作られる組織構造、それに紐づくシステムアーキテクチャ、開発プロセスなどです。経営層が経営指標をEBITDAにするとメッセージングしたときに、開発の現場では何がおこるかとか考えてみると面白いかもしれません。自分が大切にしているのがこの力学を逆手にハックして利用していくことです。その力学を逆にうまく使って自分のやりたいこと、都合のよいことをフォースの流れに混ぜ込んでのせてしまう。すると施策が一気に進んだりします。デメリットがない場合、コトを前進させるのにはフォースの流れを利用してしまえと思っています。こんなことを考えながら日々、エンジニア組織をマネージメントしています。開発の現場において、大きなシステム障害が発生したような場合に原因究明から今後の再発防止策を検討することがよくあるかと思います。そこでよくある議論として、とあるエンジニア「エクセルでチェックリスト作って今回の確認観点を追加します!今後はリリース前確認でかならず目視でチェックリスト確認を実施します」ベテランエンジニア「んなことやってたら、チェックリストが永遠に増えていくからやること増えるだけだろ。チェックの自動化をしなさい。これ実際に再発防止の効果が出るまでのリードタイムというポイントで見ると一般的にスジが悪いとされているチェックリスト的なやつですが、とあるエンジニアの案ほうが今すぐ対策を講じることができるので良かったりするなあと最近思うようになってきました。暫定的な再発防止対処としてですが。目的は、「同じことが今後も発生しないこと」「それを事前に食い止めること」、であり、「自動化して確認が楽になること」ではないのですが、どうしても技術的な正しさやエンジニアとしての美学が目的ベースの判断を歪めることがあります。再発防止に求める効果効能と時間軸による変化さくっとチェックを自動化できるような場合は最初から自動化すればよいのですが、例えば、それが難しいような場合、エンジニアの美学としてのコードで解決することに時間を溶かすよりも、まずは原始的であろうが実利を即得られる方法を選択するほうが良いです。その対策を実装している間にまた類似システム障害が発生したら意味が本末転倒なので。実利の即効性(フロー効率的)まずは即効性が重要なので、一番早いやりかたを選択したほうがよいと思います。今すぐできることが重要なので。それがエクセルチェックリストならそれでもいいですし。本来の目的を達成してから、あとはそれを今後N回繰り返していくときの効率面の問題に対処していくのが良いと思います。(Lintに定義追加する程度とかの問題ならSTEP2からでいいです。ありがちなのがテストを自動化すればいい!という対策で、これ事態は別に悪くなくむしろ自分もそうしたいのですが、開発の文脈を無視したこの手の解決策をうつと問題がおきます。本来すぐ防止策を打ちたいだけなのに、いざテストコード書こうとすると、おやおや、クラスが大きいな・・・、メソッドも細かく切られていないしテストコード自体が複雑になるなあ。これなら、まずはリファクタリングしないとなあ、、、さあ、どこからなおしていくかな。みたいなことが起こりがち。リードタイムが長くなる一方。それは後述のSTEP2でやりたい。目的を今すぐ果たしたい。フロー効率性重視でやりたい。フロー効率性やリソース効率性の考え方はこちらを参照ください。今後の作業量の効率性(リソース効率的)一旦、イケてない方法にしろ再発防止という目的を達成したのであれば、次にN回繰り返すときのことや、人力作業による手戻り発生等の物理的な無駄を排除していくことになります。やりかたはコードによる自動化とかがメジャーだとは思います。そもそも仕組みを組み直して、そもそも問題が発生しない構造にしてしまうとか。いえ、それなりのリードタイムを要する行為かと思います。カネで解決するためにアウトソースで実施することもあるかもしれません。こちらはリソースの効率性の文脈が強いと思います。カイゼンは最終的には実利を得つつもやることが減っている状態だと思っているので、ここまできてカイゼンはDONEではあります。この場合は、恒久対応までDONEすることをマネジメントすることは言わずもがな必須です。運用がゴミまみれになり負債化するので。今回の件はイメージにすると以下です。実利をリードタイム最短で取りに行き、その後、スケールしやすいように作業の効率化をしていくイメージです。普段の何気ない意思決定に介在するアウトカムフォーカスポイントは目的を意識した上で、STEP1とSTEP2双方を意図的に実施することです。何度もいいますが、STEP1を絶対非効率なやりかたでやれと言っているわけではなく、即効性のある方法をとるとよいという意味なので、手動目視チェックリストで絶対やれという意図ではないです。この何気ない意思決定および行動の積み重ねが開発組織の文化につながっていくと思います。チェックリスト文化だけも良くないですし、文脈を無視した自動化文化も良くないと思います。最短のリードタイムで実利をとり、そのあと効率化していけると良いのではないでしょうか。本件の障害対応においては、まあ、普通に暫定対応と恒久対応なだけの話なのですが、このパターンって結構あるなあと感じたのでブログにしました。類似ケース例えば、開発における案件のリリースまでのリードタイムを改善のために計測しようとしたときに、目的でいうと「リードタイムの可視化」なので、メンバ全員に聞いて回って模造紙にまとめるでも即効性があればなんでもいいのですが、自分も含めてですがどうしてもタスク管理ツールのAPIリファレンスを覗きだし、自動でチケットの日付とステータスの推移を抽出できないかとか悩みだすんですんですよね。運用がうまくされていなくてチケット管理ツールから自動抽出できないとなると、うーん・・・・、となってまた別の技術的解決方法を探しに行ってしまう。本来の目的からどんどんそれていきなかなか可視化されないという事態に陥る。全員で集まって人力で計測した時間を模造紙に書き出すだけで一旦は解決するのに。別のケースでいうとリーンスタートアップなどででてくるMVPとかもそれに近いかもしれないですね。さいごにサービス開発の現場では結構この手のことが多い気がしていて、また、本件の例のベテランエンジニアのようにHOWの指摘をしたくなるのもわかるのですが、そこは本質を意識しアウトカムにフォーカスし、得たい実利とHOWとリードタイムを天秤にかけながら判断をすべきだと思います。どんなにHOWが秀逸でも実利に繋がっていないとやっていないことと変わりないので。プラクティスの使い方がどうこうとかそういう話ではなく、本質的にはこういうことこそがアジャイルをしようとせずに、結果的にアジャイルであることなのではないかなと思ったりします。(高い技術力で高速に打ち手が打てる状態が最高ではありますが自分はそんな才能はないので。Scrum今年の振り返りがてら、オフィシャルな社外発表ベースの今年のアウトプットの雑なまとめ。大体0.5回/月の社外登壇らしい。Kurodawww.slideshare.netスライドが潰れて見にくい画像を補足。(これが正解とかではなく目的や文脈にあわせてこういう構造でいつも考えている感じ。i2key.hateblo.jp番外編i2key.hateblo.jpまとめみなさま今年もお世話になりました。来年もよろしくおねがいします。パネルディスカッションに機会がありまして出演させていただきます。RIESの最新刊になります。STARTUPの考え方を大企業に適用させる場合の考えかたについて記載されています。STARTUPを読まれて実践されている方をベースに読んでみたまとめを書いてみます。英語は苦手オブ苦手なので、誤訳というか誤理解もあるかもしれませんが、全体の雰囲気が伝わればよいかなくらいの期待値でおねがいします。大企業でリーンスタートアップを実践している人には伝わるとは思うので。フランクにではありますが、エリックからは本中の図の引用の許可は頂いております。大企業も従来のマネジメント方法だけでは不確実性に対峙する際に立ち行かなくなります。そのために、大企業もリーンスタートアップの考え方を適用すると良いと本書では提案しています。その事例として本書全体を通してベースはエリック・リースがGEの改善を行ったエピソードを元に説明されています。具体的な事例については本書を読んでもらいたいので、ここでは省略します。全体を通してのメッセージとしては、「アカウンタビリティ」をベースにした起業家機能を事業部門毎に、機能組織(HR、Finance、Engineering、etc)毎にもつべきであるとしています。Boardで構成されます。事業部門における、社内スタートアップとはまさにそのドメインでの新規事業等が該当します。機能組織でいうと、例えば人事機能でいうと、人事評価ルールの刷新等が該当したりします。これもスタートアップとして扱い、新しい評価制度をMVP的に一部の従業員に適用し、仮説検証を繰り返していくことになります。Boardと社内スタートアップは一般的なVCとスタートアップとの関係性と同じであり、資金の用途についての細かい説明責任は発生しません。Funding)に基づいて、ステージゲート的に資金調達を随時していくことになります。その進度はROIによる進捗がゼロの期間の間においては、リーンスタートアップでの革新会計をベースに見ることになります。売上が立ち、スケールしていくと従来のROIベースの会計に切り替わります。その間に、既存事業は従来のマネジメント手法で運営されており、従来の一般的なマネジメントスタイルと、上記のような起業家的マネジメントスタイルの二本柱で企業運営する考え方になります。https://twitter.com/ericries/status/934106870284943365昔ながらな企業と近代的な企業の違いエリックは、リーンスタートアップの考え方を大企業に取り込むべきと解く前に、近代的な会社としてどうあるべきかを説いています。(相当直訳なので雰囲気つたわれば・・・)昔ながらな企業は、規律的な管理と統制を通じて着実に成長しており、四半期報告書などの短期間で大きなプレッシャーを受ける可能性がある。近代的企業は、継続的なイノベーションを通じた持続的な影響に基づいており、長期的な成果に重点を置いている。昔ながらな企業は、特殊な機能のサイロの専門家で構成されている。その間に、各ハンドオーバーに関連付けられた特定のマイルストーンを使用して機能から機能にプロジェクトを送信するステージゲートまたはウォーターフォールプロセスで作業が行われる。近代的企業は、反復性の高い科学的プロセスを通じて顧客にサービスを提供するために協力し合うクロスファンクショナルチームで構成される。昔ながらな企業は、巨大なプログラムを運営する傾向がある。近代的企業は迅速な実験を行う。昔ながらな企業は、法律、IT、財務などの内部機能を使用して、詳細な手順に準拠してリスクを軽減する。近代的企業は内部機能を使用して従業員が顧客にサービスを提供するという目標を達成し、ビジネス成果を生み出す責任を分担する。昔ながらな企業は、ROI、伝統的な会計および市場シェアに基づいて非常に不確実なプロジェクトでさえ優先順位付けする。成功を測るために、プロジェクトチームは可能な限りよく見えるように設計された数字(「バニティメトリクス」)を追跡して共有するが、必ずしも真実を明らかにするわけではない。近代的企業は、将来の影響の可能性と規模を最大限にしようとする。プロジェクトチームは、革新会計を使用して主要指標を報告し測定する。昔ながらな企業は、マネージャーとその部下から構成される。近代的企業は、リーダーとその能力を発揮する起業家で構成されている。funding)システムを使い、自分たちが「正しい」ことを確認するために、高価で開発が遅い大きなプロジェクトを追求する傾向がある。funding)システムを使用して追加投資をする。これには失敗コストも含まれている。昔ながらな企業では効率性は全員が常に忙しいという意味で、効率的に間違ったことを構築することによって簡単に「失敗を達成する」ことを意味する。現代企業は、効率性とは必要な手段で顧客対して正しいことを理解させることを意味する。システムは根本的に異なるメッセージを送る。近代的企業は、生産的な失敗に報い、方向のスマートな変化につながり、有用な情報を提供する。昔ながらな企業は、参入障壁によって競争から保護されている。近代的企業は、継続的な技術革新を通じて競合他社を粉塵にさらす。この相違点のリストを見てると、多くのパラドックスに気付く。Nothingで投資します。近代企業の経営陣は、どの戦略が長期的なビジョンを支えるかを知るためには、長期的な哲学と極めて短期的で迅速な実験が必要です。FUNCTIONで、そのために企業に見逃している機能があるよと。エリックはCEOと会うとき、しばしば以下のように尋ねるらしい。考え方を、日常業務を通じて組織全体に浸透させる。これらの責任は、組織図にはほとんど表示されません。既存のマネージャー(エンジニアリング、マーケティング、ITなど)の中で最優先事項ではなく、さらに悪いことには誰かの責任である。これらの熱の入らない状況から脱して、起業家精神を近代的企業の核となる規律と見なす時が来ている。それは組織の「スタートアップDNA」の監督者であり、継続的に次世代のイノベーションに投資するために起業家の考え方や技術を組織全体に浸透させる独特の役割を担っている。言うと、多くの従業員や多くの職種のマネージャーは、財務のような基本的な予算編成や財務モデリングなどのツールや手順について訓練を受けていてみんな当たり前のように理解してるけど、これと同様に、起業家精神や起業家機能もスキルなのでそうあるべきです。起業家機能は独自のキャリアパスを持つ専用機能として、また組織全体に起業家的手法を普及させる広範な基礎知識の源泉としても機能するようになります。そこで、エリックは起業家機能に求める2つの責任について言及しています。起業家機能の第1の責任は、同社の社内スタートアップを監督すること。起業家機能の第2の責任は、成功の問題を管理すること。ほとんどの新興企業が失敗するという事実を認めていますが、ほとんどの組織にとって最も難しいのは成功したときに何をすべきかを知ることです。確立された組織内でスタートアップすることは、既存の事業を穏やかに脅かすだけです。本当の成功を収めている社内スタートアップはもっと危険です。成功した実験では、どのように組織内の家を見つけるのでしょうか?既存の部門に吸収されるか、まったく新しい部門になるか?それはどうやって決まるのか?それは誰の決定で?あらゆる部門には、革新と成長のために新しいアイデアをテストし、洗練し、拡張する方法が必要です。アイデアが実証され、適応され、スケールする上記の図は1つの部門内で、時間の経過と共に1つの社内スタートアップ(や新規事業)のパスです。それは、シードステージの実験の一環として始まり、時間と共に成長していきます。複数のスタートアップがある場合、多くの仲間達がトラクションの欠如のために死ぬ中、生き残ったチームはそれを続けていきます。そのスタートアップにおける実験の業務比率が、実行に関するアクティビティによって支配されるまでシフトします。すれば、(あとはやるだけなので)親部門がそれを管理する全責任を引き継ぐことができます。起業家マネジメントは一般的なマネジメントとは異なるため、まぜると事故ります。これらの異なる形態の管理は、互いに隔離され、別々に運営されます。新しい製品による小さなスタートアップは、実験実行の連続体の左端で、既存の製品を使用して着実に四半期ごとに成長を遂げている成熟した部門は、この流れでの右端の終わりです。この状況で発生する事象として、その組織にわずか10人の顧客を持つスタートアップがある場合、新しい顧客を獲得するために投資するのか、既存の事業の顧客にサービス提供するために投資するのかを考えなければならなくなります。法務なり財務なりの一般的に言われている良いプラクティスは既存の顧客(事業)にうまく役立つために出来ているので、企業はあまり過激なことをしないようになっています。そのため機会を逃してしまいます。(イノベーターのジレンマ)起業家機能を取り込んだ組織イメージで、上記のもろもろを企業の組織図に反映すると以下のような図になります。前述の通り、起業家機能は、エンジニアリングやマーケティングなどの企業内機能と同等の位置づけになります。Functionと扱っている所以です。CAPABILITIESこのような起業家機能ををサポートするためには、一連の新しい課題を解決しなければなりません。1.適切な責任制約を持つ実験のためのスペースをどのように作るか。自律的なチームに限定責任を与え実験する「自由の島」または「サンドボックス」を作ります。Startupでは、これらの限定責任実験を最小限の実行可能な製品(MVP)と呼びます。ここではMVPがどーのこーのは省きます。今は、チームに強力なアカウンタビリティ基準を与えながら実験を作成するという自由度を持たせるというリーダーシップの課題に焦点を当てたいと思います。最高の起業家は制約の中で働く能力を持っています。リソースが不足している早期段階の企業では、制約が自然に発生します。何かをやるためには、非常に多くの人やたくさんのお金、または特定の月数が必要です。大きな企業では、これらの制約をより意識的に作成する必要があります。あなたの典型的なプロダクトマネージメントのミーティングを考えてみましょう。「聞いて、私たちはビジネスに6週間余裕を残すだけの現金しか持っていません。私たちができることが大好きなものがたくさんあることは分かっていますが、それ以前にこれらの事柄のうちの少なくとも1つを動作させなければ、私たちは死ぬ運命に入っています。」それはストレスに満ちていると聞こえますが、それは最も生産性の高い作業方法です。スコープや状況の変化に対して常に対抗する力がある唯一の環境の1つです。(制約によりチームは結果的にWIP制限を1にしている状況。それを作り上げるリーダーシップ。)2.投資収益率(ROI)を事前に知らなくて、どのようにプロジェクトに資金を投入するか。画期的なプロジェクトは、ほとんどの場合、最初はおもちゃや悪い考えのように見えます。本当に悪いものもあります。虚栄心プロジェクトにお金を浪費することなく、証拠、実験、ビジョンに基づいて投資を行うことを学ぶことは、非常に困難でありながら深遠な重要なスキルです。3.自律的に活動しているチームのための適切なマイルストーンを作成するにはどうすればよいか。成功とそれへのマイルストーンをどのように定義しますか?正確な予測がないと、従来の管理ツールの多くは機能しなくなりました。スタートアップ投資家はこの呪いに長年苦労しています。理想的には、投資家は各ファイナンス・ラウンドから何を得るのかを事前に知りたいと思っています。従来のベンチャーキャピタルでバックアップされた「シリーズA」投資の後、スタートアップは新製品の発売、100万の顧客、および1,000万ドルの経常収入を得ることを知りたいと考えています。実際には、これはほとんど起こりません。スタートアップは本当にその製品を立ち上げるだろうが、最初のバージョンに夢中になると思った顧客は興味がなかった。総収入は予測よりもかなり低いですが、顧客あたりの収入は予想よりもはるかに高いみたいな状況も発生したりします。一般的に言えば、企業内のファイナンスの専門家は、アカウンタビリティ目標を数パーセントポイントも失っているチームから資金を引き出すように訓練されています。スタートアップの投資家であることは、しばしば、説明責任の目標を桁違いに欠いているチームを倍増させる必要があります。これには、正確な予測ができない状況でも機能する新しい種類のマイルストーンを作成する必要があります。4.スキルとして起業家精神をより良くするために、専門的な開発とコーチングをどのように提供するか。多くのリーダーにとって、これは明確に異なるリーダーシップスタイルの人々を指導することを必要とします。あなたは若いスティーブ・ジョブズをコーチしようと想像できますか?しかし、「次のスティーブ・ジョブズ」に対する投資は必要であるものの、現実にはジョブズ氏のような人格を持つ人は解雇される傾向があります。企業環境でうまくやる方法を見つけた人は、履歴書に繰り返し失敗した経歴を書き込んではダメだと知っています。起業家として成功を収めた人たちは、失敗が最高の教師であったということをほぼ普遍的に言っています。私たちのほとんどは、私たちを指導して起業家の才能を育てるのを助けてくれたメンターや投資家を幸運にも持っていました。シリコンバレーはキャリアとして起業家精神を追求する人々のための広範なネットワークを持っています。この種の従業員を保持したい組織は、企業にも内部的にこれらのサポートを複製する必要があります。5.私たちはどのようにして社内外にネットワーキングとマッチメイキングを提供するのか、また、社内外の人々は「私は企業起業家だ」という新しいアイデンティティをどのように理解するのか。ほとんどの企業において、社内スタートアップへの人事的サポート、エンジニア、マーケター、デザイナー等のプロフェッショナルサポート等のサポートがありません。WAYのアンバサダーとして、起業家機能が繁栄すると期待したら、これらのサポートを創り出す必要があります。6.適切な人材を適切なチームに配置するにはどうすればよいか。「誰もスタートアップで働くようにアサインされません。」と、ある企業の起業家は私を嫌って言った。マネージャーはアサインをする際に、自分の昇進に最も効果のあるアサインを行う癖があり、またメンバ側も自分のキャリアを汚すようなアサインは割けるために様々なツールを使ってアピールしてみたりと、政治的活動や駆け引きなどクッソどうでもよいムダがはびこりがちです。未知の、リスクの高い、不確実なプロジェクトには、人材を惹きつけるための合理的な方法が必要です。7.我々はどのように新しいインセンティブと昇進システムを作りだすか。大事なのは、単純にスキルがないのか、わかった上で迂回ルートをとっている人材なのかを見分ける仕組み。「fauxtrepreneurs」のフェイクにはまらないための見抜く仕組みが必要。out.アカウンタビリティ起業家マネジメントは、21世紀の不確実性のために特別に設計されたリーダーシップ・フレームワークです。これは伝統的なマネジメントの代わりではありません。マネジメントポートフォリオにおいて、一般的なマネジメントと同じくらいの厳格さを起業家マネジメントにも与えるように設計された規律です。従来のマネジメントスタイルで管理できないのは、予測不能であるということだけではありません。これは従来の管理設定で慣れ親しんできたものとは異なるツールと異なる保護手段を必要となります。WAYのパワーは、2つの異なる作業方法の強みを兼ね備えているという事実にあります。Way)を使って作業する「スタートアップの方法」を明確にする最初の試みを含めました。WAYの基礎はACCOUNTABILITYをベースに、PROCESS、CULTURE、PEOPLEで構成されています。ACCOUNTABILITYは、従業員の行動を促し、そして、注意をフォーカスさせるための報酬やインセンティブを含む責任の仕組みです。組織において人々は何によって昇進して、何によって祝われ、何によって解雇されるのか。アカウンタビリティシステムは、企業が達成したいと望む長期的および短期的な目標に沿って整えなければなりません。PROCESSは、プロジェクトの計画、管理、チームの調整、コラボレーションなど、従業員が日常的に仕事を遂行するために使用するツールや戦術に関係しています。アカウンタビリティシステムが結果的に選択肢を制限するため、プロセスは説明責任から外れます。適切なインセンティブが与えられたほとんどのチームは、新しいツールや戦術の回りに自己組織化することができます。アカウンタビリティによる説明責任をチームが持つからこそ、そこに権利・権限が発生し、プロセスは自由になります。時間の経過とともに、これらの習慣や働き方はCULTUREになります。文化は組織がどのように動くかを望んでいるものではなく、過去に実際どのようにしたかに基いている組織の筋肉の記憶です。box!”」とか奨励するポスターをはるだけで文化を変えることはできません。things!」さえも意味ない。あらゆる文化は、特定の種類の人々、すなわち究極の企業資源を引き付けています。有害だったり昔ながらの文化は革新的な才能を離脱させます。最終的に、組織の成功は文化が引き付けることができる人の総量に依存します。新しい文化を育むためには、個々のチームが自己組織化する必要があります。新しい文化は、新しいやりかたが成功するのを目撃した経験から生まれるものです。これらのチームは、慎重に育成されれば企業全体の新しい文化の種となり得ます。実際、多くの成功した変革の中で、チェンジ・エージェントになった将来のリーダーは、初期のパイロットプロジェクトで働く普通の従業員として始まりました。単一の組織内であっても、起業家の原則と一般的な管理原則は共通の基盤、特に長期的な考え方の重要性と共通の価値観を共有しているため、実行の厳格性と規律が必要です。それらを共存させるために、その差分をわかりやすくした図が以下。起業家マネジメントのツールは、革新を必要とするプロジェクトや不確実性のコンテキストで動作するプロジェクトのために組織全体で使用されているとしても、起業家精神も組織内に専用の家が必要です。アントレプレナーシップは、専門スキルと独自のベストプラクティスを必要としていることを認識すると、エンジニアリング、マーケティング、セールス、IT、人事、財務などの機能にも組織図に独自の家を与えることができます。要は、起業家機能を事業ドメインだけではなく、機能組織にも注入することで新しい変革を起こしやすくするのだーとおっしゃってる模様。この構造に変えるには並大抵の努力じゃいかないとエリックもいっていて、でもそれ以上のメリットがあるといっている。そのメリットって何かを次に列挙します。変革の成果1.リーダーシップの機会が増えます。今日の階層構造の課題の1つは、実際にはP&Lの責任を持つ真のゼネラルマネージャーの仕事がほんのわずかであることです。リーダーシップポジションを小さくする企業では、ポジションは小規模であるため正確なリーダーシップの役割を果たすことはしばしばありません。ほとんどの組織では、小規模は重要ではないと見なされます。社内のスタートアップは、小さくても、充実した責任を負っています。彼、彼女に大組織のP&L責任を与えるほどリスクが高いように見せても、社内スタートアップでは、本当のリーダーであることを証明する機会があります。要は、小さいスタートアップながらもP/L責任を負った上で業務が遂行できるため、これは説明責任と実行権限が同居する座組のため、本当のリーダーシップを学べる良い機会であるということ。2.退職を促す代わりに、革新的な人材を社内に維持するのに役立ちます才能のある人々がスタートアップをはじめるために会社を離れる場合、これは経済全体にとっては平均しても良いことです。元の会社にとっては、それは損失です。ファウンダーが会社たちあげのために辞めていくのを防がねばならない。3.無駄な時間とエネルギーを削減します。あなたが毎日している仕事が誰かのために価値を創造していることをどのように知っていますか?たいていの人がその質問に答えることができません。欠陥の7種類のムダを識別します。最近、リーンコミュニティは、伝統的なムダのカテゴリーを超えて考えています。誰もが望んでいないものを効率的にやっていくことは、もう一つの根本的なムダであると認識する必要があります。この問題は、あらゆる規模の企業、スタートアップ、既存の組織を悩ませています。間違った製品を構築するために時間とエネルギーを注ぎます。WAYは、最初に構築すべき正しいモノを見つけ出すための管理努力に焦点を当てています。4.プロジェクトを殺すより良い方法です。プロジェクトをキャンセルすると、政治的に大きな影響を及ぼすことがよくあります。その結果、企業はほとんどの場合十分な頻度でそれをやっていません。プロジェクトが政治的な勢いを集め始めると、ステージゲートプロセスがそれを止めることは難しくなります。ミドルマネージャーは強制的に執行者のように行動します。プロジェクトを終わらせる必要がある場合、通常はかなり苦しいです。評価システムを使用しています。一般的に言えば、評価を行うための基準が10つある場合、各チームは常に7つの緑、2つの黄色、1つの赤を表示しているようです。それは魔法と似ています。彼らはいつも同じです!なぜかというと・・・・すべてのマネージャーは、あなたがあまりにも多くの緑を表示する場合、信じられないと思うことを知っています。問題が多すぎるとプロジェクトがキャンセルされる可能性があります。管理者は、ゲートを通過するために必要なものに対してステータス更新を完全に較正しています。プロジェクトの実際の進行状況との関連がほとんどない、この物語の構築に費やされた舞台裏での時間とエネルギーの量は膨大です。スタートアップは常に失敗します。彼らは収益を上げる前にお金がなくなり、それ以上の収入を得ることはできません。ファウンダーの中には、さらなる投資をしなかった投資家について不平を言う人もいますが、一般的な文化は、企業の失敗はファウンダーとその決定に起因すると認めています。それが私たちが自分のキャリアを終わらせるということではありません。彼らが追加の資金を調達できない場合、それは彼らがつくりだした結果が次の段階に進むのに十分なものではなかったからです。5.スピードと俊敏性で異種の問題を解決する能力。発生したときに、大規模な製品リコールや他の目に見える危機のような、組織全体を解決するために組織全体を改革する必要があるという問題があります。何らかの理由(現実的または政治的)にかかわらず、CEOの個人的な注意を呼び起こさない緊急の問題はどうですか?ある機能や部門が急性の痛みを感じるものとそうでないものとの連携が必要な問題はどうですか?そして、労働者を悩ませているイライラした日々の「普通の」問題はどうですか?今日の管理システムは、このような状況に注意と資源を投入するために奮闘しています。実験を実行し、結果を測定し、もし結果がこの解決策として有益であれば、それをスケールアップするような、より起業家的なアプローチでより良い答えが得られます。膨大な数の実験が失敗するという事実を利用するので、管理上の帯域幅を取る必要はありません。組織が新しいアイデアを二重にするかどうかについて戦略的な会話をする必要があるときには、実際の顧客データと完全な合理的な議論ができます。WAYはマネージャに市場へのより適応力と機敏性を与えることができます。変革への3フェーズからなるロードマップ前述のもろもろの変革を進めていくには以下の3ステップを踏むとエリックは言っています。フェーズ1は、実験、適応を通して基礎を築くことです。フェーズ2は、迅速なスケーリングと展開のためのものです。フェーズ3は、企業の深いシステム(財務、人事、etc等)を扱うことに取り組む力を得ることになります。MASSフェーズ1はクリティカルマスに到達するまで、以下の典型的なリーンスタートアップに基づいたやりかたで進めていきます。この特定の組織で新しい方法がどのように機能するかを示す包括的なケース、ストーリー、および結果のセットを作成するために、限られた数のプロジェクトから始め、そこから構築します。最初から機能的な多様性を組み込むために、パイロットプロジェクトを実施するための専用のクロス・ファンクショナル・チームを作成する。Boardシステムを作成する。初期チームに、不安定な地形でコースをプロットするのに役立つリーンスタートアップ型の実験を設計する方法を教える。適切なスタートアップスタイルのメトリックを使用して、それらの実験の結果を測定する。新たな作業方法が確立された方法と矛盾するようになったときに生じる問題を解決するのに役立つ組織の指導者ネットワークを構築する。前進し、後の段階まで組織構造への深い変更を遅らせるために、最初は例外で作業します。新しい概念を企業固有の言語とツールに翻訳する。UPこのフェーズは、フェーズ1の取り組みによって特定された、組織にとって適切な方法の迅速なスケーリングと展開に関するものです。GEでは、これらのアイデアが1つの機能ドメインで機能していることから、個々のプロジェクトを通じてどのドメインにも適用できることを証明することになりました。フェーズ1の場合と同様に、フェーズ2についても「適切な」方法はありません。この次の変化の段階で働いている組織に共通する重要なパターンとタスクがあります。フェーズ1のチームやプロジェクトが直面する課題を確認し、特定する。新しい方法で作業するための普及したシステムを開発し、展開する。新しい方法を強化するために幹部レベルの支持者・擁護者を特定し、適切に活用する。内部機能を変換プロセスに持ち込む。内部コーチングプログラムを作成する。Funding)を使い始める。funding)と言ってる。この座組だと、毎年開催される会議での資金調達のために、自身の希望するプロジェクトを「デッキ」に入れることは非常に難しいです。一度デッキに入ってからは、ほとんどのマネージャーが「蛇口」と呼んでいるように資金調達の流れが周期的に変化します。やばい失敗がない限り、プロジェクトは四半期ごとに、さらには年々継続することが期待されます。ある年度に資金提供されるほとんどのプロジェクトは、翌年に同じレベルではないかもだけど資金提供され、そしてほとんどキャンセルされることはないです。チームが資金援助を受ける資格があると感じると、スタートアップに必要なエネルギーとフォーカスを生成することはほとんど不可能です。スタートアップの死亡率は、過度の資金を投じられたケースでは異常に高いです。資格資金調達のもう一つの問題は、政治を管理するための費用です。平均的なプロジェクトチームリーダーが自分の予算に関連する会議の数は、驚異的なものになります。そのように働くことに慣れている企業では、文化の変革は長期的なプロジェクトです。それには一連の連動する改革が必要。Funding)というものです。これは計量された資金調達との取引です。金銭を使う絶対的な自由と、より多くの資格を取り除く方法についての非常に厳格な基準と、検証された学習のみで建てられたものです。VCからシード資金を調達して100万ドルを調達した場合、翌月に進捗報告しろと電話を受けることは決してありません。この自由は、スタートアップを可能にする重要な部分です。計量資金調達に移行するメリット。company)計量資金調達は、文化を変えるだけでは十分ではだめで、これは既存のシステムが非常に復元力があるためです。Board(後述)などの他の変更を組み合わせが必要になります。Boardには、次の3つの責任があります。1.社内スタートアップのコーポレートアカウンタビリティの単一点であること。Boardは、1つのチームにしか対応できません。Boardもあり一度に多くのチームにサービスを提供したりもします。スタートアップのアクセラレータと同じように、意図的にチームのコホートをボードに持ち込むことさえあります。Boardは、自ら監督する社内起業家のためのピボットまたは継続の意思決定の立場を目指すべきである。最良のボードは、ファウンダーが進歩について深く考えるように促し、検証された学習を達成したのか、単に希望のある考えを達成したのかを疑うことができます。kill")のレビューとは異なります。2.会社の他のスタートアップに関する情報のための単一の情報センターとしての役割を果たす。(略)3.スタートアップチームに計量資金を提供する。Boardのために、計量資金調達は組織の文化変化を推進する究極のツールです。Boardによって資金が提供されるだけでなく、コーチされる社内スタートアップは、真にリーンなメンタリティを持っています。Boardの資金調達の決定は単純でなければなりません。Boardのお金を望みどおりに使うことができます。使用するものの全額を負担しなければなりません。私は内部のスタートアップが外部のベンダーに行くのを見ました。彼らが自分のお金を使っている限り、これは問題ありません。Boardの哲学のルールは、次のようなものでなければなりません。お金はあなたのものですが、有効な学習を示さなければ、さらに資金を得ることはできません。これが高度な技術である理由です。ほとんどのチームは、強制されるまでこのルールを信じません。ほとんどの役員は失敗したビジネスにさらに金をつぎ込むことを防げません。大部分の従業員は、彼らのプロジェクトに高い技術を投入するために上司に説得力を高めました。革新会計の全体のポイントは、これらの決定を厳格な方法で行うことです。成長志向のプロセスのチームと役員は、そうするために学び成長する必要があります。SYSTEMに及ぶことにふれています。ゲートキーパー機能にあたる部分を指しています。WAYの目標は、顧客サービスの考え方を取り入れることです。ゲートキーパーの目的は文字通りディフェンスであるため、レビュー、官僚制、厳格なルールを通じて他の機能の作業を遅らせます。WAY化できると、チームは作業を加速できます。何を変える必要があるのかは場合によって異なります。本書内には、法務部門の例(PivotalでのOSS利用方針に関する法務チェックの改善について)やファイナンスの例、人事の例等がのっていますが、ここでは人事のスタートアップ化についてサマリだけ載せます。GEのとあるチームがFastWorkが進み、自らセットベース開発を開始したとのこと。セットベースにすることで、顧客に価値提供するリードタイムが5年からMVP投入18ヶ月まで削減。これを上位層までレポートしたかというと、「していない」といいます。セットベース開発を行うと、複数案をパラレルで走らすから一時的にコスト増加し、さらに、場合によってはリワークが一部増えることになる。彼らの人事評価システムでは、リワークをKPIとしており、リワーク量が多いと評価が下がり、キャリアに悪影響を及ぼすらしく成果としていうことはできないようです。評価システムがボトルネックになっている状況です。これを解決するために人事の中にもスタートアップチームが立ち上がりました。その中で人事評価のMVPの仮説検証をコホートをきり繰り返し実験を実施し、改善を推進していったようです。Boardを設置し、スタートアップとしてのメカニズムにのせて推進することになります。今まで、組織の事業軸、機能軸それぞれで起業家機能についてふれてきました。これらのアイデアのすべてを一緒に話す壮大な方法があります。今日、ほとんどの組織(規模にかかわらず)は、以下の活動をいくらか行っています。新しい製品を作り、新たな成長源を追求する。ITシステムやHRポリシーなどの新しい「内部製品」を構築する。新しい作業方法を導入するための企業チーム(FastWorksなど)の構築など、企業のリストラや変革を行う。これらの4つの活動は多くの人々が理解するよりも共通しています。実際、それらは共通点が非常に多く、一元管理され、単一の包括的機能の助けを借りて管理されるべきです。"欠けている機能"の柱です。現代の企業は真にその前身との差別化を始めます。重要なことは、組織が次のことを行うことです。1.起業家精神機能の責任を誰かに任せます(あまりにも多くの組織には誰もいません)。2.これらの人々に、単に扇動者として(単に多くの「チーフ・イノベーション・オフィサー」が存在するように)指定するのではなく、実際の運営責任を与える。3.起業家の才能のためのキャリアパスと専門的なパフォーマンス開発プロセスを構築する(影響を受ける機能や部門に関係なく、柱を越えて共通の標準を作成する)。4.柱を横切る起業家の相互訓練を促進する。(これは、創業者としての実績のあるVCが非常に高い評価を受けている理由ですが、創業者としての実績を持っていないにもかかわらず成功したVCには注意する必要があります。重要なのは、履歴書ではなく、考え方です。)5.組織全体の起業家精神を育むための訓練、指導、サポート、指導、ベストプラクティスを提供する。6.組織において、非起業家を教育する責任があります。変化の原動力ではありませんが、より起業家的な働き方を採用する必要があります。7.他の機能(特にゲートキーパーの機能)が会社のポリシーを設定しているときに、起業家精神を議論のテーブルに置く。これは特にファイナンス、法律、人事、およびITにとって非常に重要です。これらのコミットメントは、企業の機能として、起業家精神の最も包括的な構造を形成します。以下に、起業家精神の統一理論のすべての要素を示す組織図が掲載されています。感想ざっと読んで大事だと思ったポイントを上記にまとめましたが、基本的にアカウンタビリティがベースになっている考え自体は非常にスタートアップ的であり、シンプルだと思いました。結局、責任と権限が同じ場所にあれば、健全な自由であるため、自己責任でなんでもできます。VENTURESにそっくりだなと感じました。規模の企業でやるには自然とこの構造になるのでしょうか。WAYは従来の一般的なマネジメントと、起業家的マネジメントを2本の柱としています。この構造が実はエンジニアである私からみると、完全にバイモーダル戦略のそれと一致しており、本質的には同じ構造でスッキリしました。以下がバイモーダル戦略。クロスファンクショナル/スモールチームについて次に、マイクロサービスは組織論だという組織論サイドの考えでいくと、マイクロサービスを縦切り横切り議論でいうと、事業ドメイン切りをした場合、仮にそこを売上があがる単位に分割するとまさに同じ座組がつくれます。チームはクロスファンクショナルであり、そこには売上に関するアカウンタビリティがのるため、その分、技術的な、ビジネス的な、権限が発生します。本質的には、責任と権限が同じ場所に来るようにおいて健全な自由度をもたせ現場を動きやすくする。それが出来るための起業家機能を設置する。boardがVC的に動く。いうスタートアップエコシステムを社内に作ろうとしているのはわかりました。ロジックとしては非常に全うであり、ツッコミどころはありません。GEの株価はリーンスタートアップしたのに今年にはいってからむちゃくちゃさがっておるのだろうか。リーンUXの著者は、ブログで「リーンスタートアップは不確実性に対処してるかもしれないが、実際にそれを評価するマーケット(やCFO)は確実性が大好きwww」と言ってるけど、ホントかいなwwwwさいごのさいごのさいご。さいごにバイモーダルとかマイクロサービスとかくっつけて、ギリギリエンジニアのアドベントカレンダー風に着地させましたが、弊社のエンジニアの中にはエンジニアリングの嗜みとして、ビジネス側もこうやってチョットだけ理解しようとしている人もいるんだよという多様性もアピールできれば。宣伝というわけで、リーンスタートアップに関するイベントを馬田さんと角さんとやることになりました。スライドは以下になります。」がベースとなっております。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の効果が積み上がります。ここでポイントなのはビジネス上の成果は根雪構造をとるので早めに市場投下したほうが何らかのフィードバックを得やすくなります。それぞれのビジネス上での影響まとめると、上図のような感じになります。改善サイクルを回りてCVRをあげるような文脈における開発では、まとめてやること(リソース効率)を選択するということは、学んでいない期間、稼いでいない期間を最大化するという選択を取ったということを意味します。分析基盤がしっかりしていて、機能毎のコホートが取れていれば問題ないですが、何も準備無しでやった場合は効果も同時に濁ることになり、何が寄与したのかすら不明になります。学びがないので振り返れないです。それに対して、1つずつやること(フロー効率)を選択したということは学んでいない期間、稼いでいない期間を最小化する選択をしたことになります。稼働率は若干悪化するため、トータルでいうとABCを作り切るコストは高くなるかもしれません。ABCそれぞれがダメだった場合のリスクも下げられているので行って来いかと思います。○○効率性が正義、○○効率性は悪とかを言いたいわけではなく、これは場合によるとは思います。個人的には制約がない限りフローに倒したほうがリソース効率上の問題も浮き彫りになるためフロー改善を意識的にやるとよいと思います。そのためにバリューストリームマップとか考え方のフレームワークはあります。サービス開発において様々な制約が存在します。現実は簡単ではないです。そんな中でエンジニアリングを駆使して制約をコントロール対象にすることが求められていますし、DevOpsやアジャイルにおけるエンジニアリングプラクティスは制約をコントロール下においてフローを加速させる目的が含まれているように思えます。プロセス、スキル様々な制約がある中で制約をコントロール対象ではなく前提とした瞬間にリソース効率の引力が襲ってきます。まとめこの手の話というのは、ToCでもCCPMでもリーンでもTPSでもどこでも同じような話がされています。なんら新しい概念でもなんでもありません。その割には現実世界では何に当てはまるのかというように実業務に紐付けては理解されていないように感じます。そこで、サービス開発が対峙している状況にテーラリングすることで少しでもこの概念が現場(特に判断を行うロール:マネージャなど)にインストールできればと思います。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。