00:02
はい、7月6日木曜日ですね。僕は朝9時33分になりました。今日も東京の方は、なんか荒いらしい。雨がガンガン降るらしく。まあ関西の方でもすごく雨がバンバン降ってるらしくてね。
まあ九州とかで、あの洪水だったりとかっていうので、ニュース見てると自然災害が強いなっていうところで、皆さんも気をつけていただければなと思います。はい、おはようございます。ひめみのけいすことくわはるです。
では本日も朝から始めていきたいなと思ってます。本日はですけども、タイトーになります。How to plan as an engineering executiveというので、まあリーダーシップというより、どちらかというと経営目線ですね。
でのエンジニアリングのいろんなもののプランニングの解説の記事を読んでいましたが、昨日で読み切れなかったので、今日はその続きからちょっと読んでいこうと思っています。
まあ1個1個のセクションは単体で読み切れるようなものになってるっぽいので、まあ皆さんの方でも続きだったり、前の昨日読んだところも気になった方は読んでみていただければなと思っています。
で、昨日読んだのがファイナンシャルプランですね。お金的な見積もりのところを読んでて、途中で時間切れになったような記憶があるので、今日はその続きですね。
財務計画におけるエンジニアリングの役割についての推論という話ですね。このところから今日はちょっと入っていきたいなと思っております。本日の参加者は日賀新さんとリソースフルナテマさん。
はい、おはようございます。ご参加いただきありがとうございます。今からダラダラって読んでいこうと思っております。じゃあ早速やっていきましょう。
はい、リーザニングアバウトエンジニアリングゼロオールエインファイナンシャルプラン。財務計画におけるエンジニアリングの役割と推論。
エグゼクティブチームの視点からエンジニアリング担当役員の視点に切り替えると、問題は少しシンプルになります。
エンジニアリングが収益について直接責任を負うことはほとんどありません。間接的にはその収益についてプロダクトだったりセールスのいずれかの責任を負うことがほとんどでありますけど、
ですので財務計画に対するあなたの主な貢献はエンジニアリングの経費管理のみです。
私はエンジニアリングの経費をビジネスラインと3つの特定のバケツの両方によってセグメント化するということを推奨しています。
1つ目がエンジニアリング部分の人件費です。2つ目が生産オペレーションコスト、ほとんどのクラウドコスト、もしくは生産に関するベンダーコストですね。
3つ目が開発コストになります。CICDとか低損実行とか開発環境などに関連するベンダーやホスティングのコストなどなど。
これらの3つのコストをセグメント化することを推奨します。これらのセグメントの中で収益が費用よりも早く加速している、事業の質がすでに向上しているというような事業ラインには
対象件の時間を費やし、その他の事業ラインには多くの時間を費やすべきです。
収益よりも費用の方が加速しているビジネスラインについては、いつどのようにその設定を逆転させるかについて、あなたと経営人全員が明確な仮説を文章化しておく必要というのがあります。
例えば新規事業がそのような局面でしばらく時間を費やすことは想定内であるなど、常に問題があるわけではないが、経営人全体が各事業について同じ命令に従って更新することは不可欠ですよ。
03:02
では続きまして、Why should financial planning be an annual process? なぜ財務計画は毎年行うべきなのか?
会社の財務計画というのはあらゆる機能にとって基礎となるような制約条件になります。
しかし私は計画は固定されたものであるかのように運営した方が経営人としては、またエンジニアリング部門としてより効果的であるというふうに主張したいと。
その理由は3つあります。1つ目は財務計画を頻繁に調整しすぎると、目標が移動し続けるため実行状況を評価することが不可能になります。
2つ目に、財務計画を大幅に調整するということは、多くの機能にわたって多大な時間を必要とする計画集中型の活動になります。
そのため計画を変更するということは、大量の解約を生み、しばしば他の計画構成要素の手直しも必要となります。
3つ目、全ての優れた制約と同様に計画を耐久性のあるものにすれば、チームはその中で効果的に実行することに集中します。
もしそれを柔軟なものにすれば、チームは代わりに制約を動かすこと、例えば人員増を要求することなどに集中するでしょう。前者は後者よりもはるかにのぞましい。
ということで、確かにやらなければならないんですけど、安定した財務計画で効果的な会社を経営する方がはるかに簡単ではありますよということですね。
なので、財務計画を毎年行うべきかというところでいくと、毎年、年単位でもちろん行う方がいいんでしょうけど、年の中で頻繁に調整するのは結構やばいんじゃないのっていう話。
やばいというか、いろんなものが大変だよっていう話ですね。計画そのものをリプランニングするということは、全ての作業をストップします。そういう話だと思います。
では続いて、アトリビューティングコストビジネスユニットですね。コストを事業部門に帰属させましょうという話です。
初期の事業には単一事業があり、物事は単純であります。すべてのエンジニアリングコストというのは、その単一事業の運営に直接結びついています。
企業が成長するにつれて、最終的には複数の事業に拡大することになる。その可能性もありますけど、そこでは少し厄介なことが起きます。
最も単純な帰属でさえ掘り下げていくと、実は厄介になります。例えば、フィグマのような会社は主力製品は一つになりますけど、
事業を2つの事業部門に区分していると考えられます。エンタープライズとそれ以外ですよ、例えばね。
中核となる製品はどちらの場合も同じですけど、エンタープライズの多くの機能はエンタープライズ以外の購入者には価値がありません。
この場合、エンタープライズにフォーカスしたプロダクトエンジニアをエンタープライズのビジネスユニットに帰属させるのは簡単ですけど、
コアプロダクトを構築するプロダクトエンジニアっていうのをどのように帰属させるべきかっていうのはあまり明確ではありません。
収益に応じて帰属させるか、全てのコストを非エンタープライズ部門に帰属させ、エンタープライズ部門のマージンを人為的によく見せるのか、他の方法をとるかなどなど、いろいろ考えることがあります。
いやーこれ確かに、なるほどですね。僕ちょっと事業会社にいたことがないんで、言われてみればそりゃそうだろうって感じですね。
06:03
これら全ての質問に対する答えというのは常に場合によるになります。ケースバイケースですね。
私の経験では、このトピックに関する精度っていうのは正直言って比較的低いと。
財務部門が納得できるような弁護可能な方法を見つけることに集中し、あまり頻繁に論争を蒸し返さないようにしましょうと。
ここはあんま触れない方がいいってことですね。なるほどでした。
とはいえ難しいですね。コアプロダクトとエンタープライズっていうのをざっくり分けてしまうと、エンジニアはどこに帰属させるとか、アサインするか結構大変ですね。
なるほどでした。
では続いて、Why can financial planning be so contentious?
ファイナンシャルプランニングってのはなぜ争いになるのかっていう話ですね。ちょっと短いですけど。
うまく運営されている経営チームでは、財務計画は本来争いの種にはなりません。
しかし経営人が経営人共通の成功ではなく、自分の職務に集中している場合、経費の半分というのはゼロサムゲームとなります。
業績不振の根拠として、予算不足を指摘する経営人の傾向もあいまって、経営人との関係が壊れるか、支出がコントロールできなくなるのか、どちらかになりがちです。
各CEOが自分の部署とか自分の担当分野の方に今集中して、経費の配分っていうところを喧嘩しちゃうとそうなる。ここ難しいですね。
とはいえそれぞれのミッションを与えられているとは思いますのでね。
で、財務計画プロセスというのが論争的であるのであれば、CEOとこの話題について少し推し問答をすることをお勧めしますと。
それはあなたが直接解決できる問題ではなく、経営人がパートナーとの関係に苦しんでいるか、特定の経営幹部が苦しんでいる兆候があるという可能性が高いですよと。
なるほどね。そういうのは全部明らかにしたりとかしっかり問題と向き合いましょうというところで、CEOと推し問答。
推し問答になるかどうかはそのケースはケースというところですね。はいわかりました。
では続きまして、should engineering headcount growth limit company headcount growth?
はい、エンジニアリング部門の従業員の伸びというのは企業の従業員数の伸びを抑制すべきでしょうかと。
難しいね。エンジニアリング部門の従業員数の伸びを、企業の従業員数の伸びを抑制するための理由とするかですよね。
いやーこれ難しい話ですね。一般的に私はほとんどの企業っていうのは、エンジニアリング部門の成長率に応じて、
全体的な従業員数の増加を抑制すべきだと考えている。そうなんですね。
そうすることで、たとえそれが苦しいことであっても、効率的な会社を運営するという説明責任を果たすことはできます。
また他の組織がエンジニアリングよりも急速に規模を拡大し、エンジニアリングが会社の最優先課題に取り組むための待機幅を狭めてしまうという難しいシナリオも避けることができます。
もちろん細部には常に例外があります。例えばUberはエンジニアリングに過度な要求をさせることなく、各都市のチームに権限を与える柔軟なツールを使って、各都市のオペレーションチームを迅速にスケールさせました。
Uberはもしエンジニアリングの人員でオペレーションの成長を抑制していたら、超成長期の混乱期に市場シェアを大きく失っていたかもしれません。
09:04
ビジネス要件だったりエンジニアリングじゃない部門の人を増やすと、結果エンジニアリングに対する要求とか変更がすごい増えるんですよね。それに対応しきれないというところで、あんまり加速することができない気がするんで、結果そういう事業をやっている会社とかITビジネスをやっている会社はエンジニアリングの方に需要因数ですね、数を増やす方に打った方がいいんじゃないかというところですね。
この人がそういう主張でしたと。まあでも本当にこれも難しいところですね。会社のフェーズであったりとか、今のプロダクトの伸び率だったりとか、あとお金回りですよね。本当にまさに財政、財務計画とかと要相談とありますけど、できるんだったら確かにエンジニアリングを増やす方がいいかもしれないですね。
結果、エンジニアリングって一人で何かできることはできないし、一人に託すとその人辞めた瞬間、一生にめでたく死亡フラグが立つので、できればエンジニアの方が数多い方がまあいいかもしれないですね。続いていきましょう。
インフォーミングオンカイズネーショナルストラクチャーですね。組織構造への情報提供という話です。増員を要請するときは、いつでもその人数を組み入れるための組織設計を文書化しておくべきであります。これを行う最も簡単な方法というのは、大まかな組織計算を行うことで大事です。
分かりやすく3つ例と書かれていますが、総人員を8人ずつのチームに分けます。各チームにマネージャーとミッションを配置します。
8人というのは、Amazonの2ピザチームのルールです。2枚のピザでお腹がいっぱいになる、ある程度お腹が満たされる人数が適切なチームの人数でいそうという、なかなか面白い例です。それが確か7人か8人だった気がします。
この人は8人ずつのチームに分けます。そのチームにマネージャーとミッションを配置します。2つ目に、そのチームは4から6人のクラスターに分けます。各クラスターには経験豊富なマネージャーと重点分野、例えば消費者向け製品だったり、企業向け製品だったり、インフラストラクチャーなどを配置します。
これが2つ目ですね。3つ目は、直属の部下となる5から7人のグループになるまで、再期的にグループ分けを続けます。エンジニアが40人までの会社であれば、グループの階層は1つで済みますけど、エンジニアが200人までの会社になると、複数の階層がどうしたって必要になってきます。そりゃそうだよね。
少し表面的な話になりますが、資金計画の段階でこのようなことを詳しく考えるのは正直お勧めできません。実際の組織設計の最終段階では個人の強みであったりとか経験を考慮しなければならないが、資金計画のプロセスではその程度の具体性は正直役に立ちません。
なるほどね。これはもう本当に具体まで入ったお話なので、資金計画というまだまだ走り出しの時にはそこまで考慮しても結果意味なくなっちゃうということですね。分かりました。まあでも組織構造の話はいつでもこれは見直しを図ったほうがいいですね。これは別に大きくなろうが小さくなろうがあんま変わらないので。
一つずつチームですね。会社の最小単位は個人ではなくてチームになってくるので、チームを最小単位とした時に何人までにするかと。その後会社の中のエンジニアリングチームメンバーの数全体から何階層にするかというところですね。
12:08
で、かつその階層にもしっかりミッションとか役割とかを決めた上で分けるっていうのが多分良さそうですね。企業のフェーズによって一つ一つの見直しを図るという感じですね。はいでは続いていきましょう。アライニングハイアリングプラン&リクルーティングバンドウィズですね。採用計画と採用枠の調整ですね。さっき人数の話したからまあやっぱり採用の話になりますよね。
ファイナンシャルプランニングの最後のトピックというのは、エグゼクティブチームとその次のレイヤーのリーダーというのが埋まりそうもないヘッドカウントについて議論に時間を費やすというのはよくあることです。私は過去の採用枠と現在の採用計画を比較することは非常に有益だと考えております。
過去の数字から計画した採用人数を確保できそうにないのであれば、その議論に時間を費やすことはもちろんないでしょう。これは特に超成長企業でよくあることで、経営陣が研究開発に過度なこだわりを持たず、ほとんどの人員要請を許可することがあります。
実際にはこのようなシナリオでは、R&D内のチームはヘッドカウントの承認を通じて、ではなくリクルーターの待機幅を確保する、例えばチームの採用パイプラインの特定のリクルーターを割り当てることによって、ヘッドカウントを獲得することになります。
このような状況に陥った場合、私がお勧めするのは、強力な採用パートナーになることでリクルーターと連携することです。大丈夫か?そういう状況になったら結構カオスになる気がするので、そこはしっかり見た方がいいなと思ったりしました。でもそういう状況がもしあるのであれば考えた方がいいなというところです。
これこそはまさに事業会社あるあるだという感じですね。私はR&Dの専門部隊とか持っていないので、こういう状況というのがあまり分からないですけど、本当にありそうですねというところで続きまして、この辺は例えば任天堂さんみたいな、ゲーム部門で唯一社内に研究部門を持っているという部署を持っている会社さんとかは、もしかしたらそういう悩みを持っているかもしれないですね。
では続いてちょっと大きいセクションに入ります。今のが財務計画におけるホギホギみたいなところだったので。次はDetermine Your Functional Portfolio Allocationですね。機能別ポートフォリオ配分の決定ですと。
エンジニアリング戦略の3つのコアコンポーネントの1つというものが、現在の優先事項に対してエンジニアリングリソースをどのように配分するかということです。この機能ポートフォリオ配分というのは、ベンダー、受け合い業者、およびフルタイムの人員にまたがるエンジニアリング予算全体に適用されます。この配分はプランニングにも直接影響します。
機能配分で答えるべき基本的な質問というのは、今後1年間毎月どれだけのエンジニアリング能力をステークホルダーの要求に集中させるか、あるいは社内の優先事項に投資するかということになります。これは単なるパーセンテージの羅列に過ぎません。
15:00
例えば、6月のエンジニアリング時間の63%は部門横断プロジェクトに集中し、7月は75%、8月は60%としてみましょう。しかし、これらの数字を決定することは正直難しく、会社のロードマップに大きな影響を与えます。
次の図はこの質問に対する一つの答えの可能性を示したもので、インフラへの固定投資、ディベロッパーエクスペアレーンスへの投資の拡大、プロダクトエンジニアリングの一時的な一向きのシフトというのを示しています。
このグラフが棒グラフで貼られているのですが、コートでは難しいので、ざっくりと説明します。横軸にマンスズ、毎月の月、縦軸にアロケーショントゥエンジニアリングプロジェクト、エンジニアリングの配分を縦軸にしています。
インフラコストが結構大きくて、ディベロッパーエクスペアレーンス、開発体験のところがあまり裂かれていない。あとはプロダクトエンジニアリングの開発コストにかかるので、スタートの方はインフラとか開発体験とか初期設計みたいなところにしっかりリソースが裂かれていって、進めば進むほどちょっとずつプロダクトエンジニアリングが増えていく。
やっぱりピークになるとプロダクトエンジニアリングがガッとコストがかかる。ここまでくるとインフラコストはほぼ手を動かしてはなくて、単純にお金だけ払ってるような感じかもしれないですけどね。
最後もやっぱりプロダクトエンジニアリングがちょっとかかる。これは多分テストしたりとか、リソース修正したりとか、リリース直前みたいなところかなっていうのがなんとなく見ている様子を起こされますけど、この記事も後ほどシェアしますので、皆さんも改めて見ていただいて、このグラフを見てどう思うかというところですね。
本文戻りまして、単純なパーセンテージであるにも関わらず、正しいパーセンテージの配分を決定するのは必然的に少し難しくなります。
私がお勧めする方法というのは、いくつかあるんですけど、1年に1回程度、エンジニアリングへの投資とその影響、そしてまだ行っていない潜在的な投資をすべて見直しましょう。
開発者の生産性調査、明確なブレインストーミングなど幅広い情報源から潜在的な影響のリストを策定します。
作業が完了し、新しいアイデアが提案されたら、このリストをリアルタイムで更新します。
この辺は結構皆さんやってそうですけどね。
リストが更新されたら、機能的な優先順位への定常状態の目標配分を修正します。
具体的には、機能的優先事項に占領するプラットフォームエンジニアリングチームとインフラストワークチャーエンジニアリングチームへの投資です。
定常的な割当の範囲内で全ての機能的優先課題を解決することを目指しますが、
特に影響度の高いプロジェクトやコンテキストに依存するプロジェクトについては、
プロダクトエンジニアリングなど一般的に機能横断的な作業を行うチームが一時的に支援すべきかどうか積極的に議論をしてください。
あなた自身を含めリーダーシップの時間を明らかにインパクトが大きくない大規模なアロケーションのスポットの修正に投資しましょう。
これらは組織について最もよく知ることができ、また最も有意義な調整を行うことができる場所になります。
18:00
このプロセスにどれだけのエネルギーを投資すべきか悩んでいるのであれば、
完璧である必要とはもちろんなく、有用である必要であるということを覚えておいてほしいです。
クロスファンクショナルなパートナーが満足し、エンジニアが満足すれば、非常に軽いもので済ますこともできます。
ここは明確なこういう方法みたいなのがなくて、この人は経験値でこういうやり方でどうですかっていうのを今一連のフローを教えていただきましたけど、
なかなかこの辺はですね、職人芸じゃないですけど、経験値高い人にサポートいただくのかでもいいかもしれないですね。
もしスタートアップとかその辺経験値ない人はもう外部にレビュアーだったりとか、
そういうですねエグゼクティブだけのコーチングだったり監修的なプロジェクトをやっている、またそういう人たちは支援するサイトがありますので、
そういうところに登録して、他の会社でエグゼクティブとかをやられている方にサポートいただくというのがいいかもしれないですね。
もちろんお金がかかりますけどね。はい、というところでした。では続いて、時間もちょっと迫ってきたのであと1、2個ぐらいですかね。
読んで終わりたいと思います。では続いていきましょう。
なぜ機能別ポートフォリオ配分が必要なのかという話です。
会社の予算設定とロードマップ作成が共同で行われるのであれば、なぜ機能別ポートフォリオ配分の設定もエグゼクティブチーム全体で行われないのかというのを問う価値があります。
行ってない時点でやばいと思ったりはしてますけど。
シンプルな答えは、機能計画は担当役員やチームが行うのがベストだからです。
機能別アロケーションは機能固有の専門知識に深く依存しているため、より大きな機能横断的なグループで行うとより悪い結果につながると。
はいはいはい、ごめんなさい、わかりました。
あとこれあれですね、会社の規模感によってそれは確かにそうかもしれない。
エグゼクティブチーム全体が固有のチームに対してやいのやいのやることは多分リソースかなり配分間違っているので。
とはいえそれが何か新規事業だったり会社の次の未来を担うような一大プロジェクトとかいうんだったら話は別だと思いますけど。
ただ広げすぎると基本的には悪い結果につながる可能性が高いということですね。
なので横断的なグループでやるよりはもう本当に個別の担当役員とかでやりつつそこだけで閉じることができないときに改めてエグゼクティブチームというところに問題を持っていくというようなプロがいいかもしれないですね。
だからといって機能別リーダーが単独で割り当てを行うべきだと言っているわけではもちろんない。
私はエンジニアリング戦略の策定で述べたようにエンジニアリングチームのリーダーシップチームとかエンジニアリングの他のシニアメンバーと連携しておかないその提案を同業幹部と検証することを強くお勧めします。
しかし同業他社の幹部を深く巻き込んでも彼らやあなたのためになるとは正直思えません。
モノレポについてスタッフエンジニアの視点よりもCFOの意見を優先させようとしているのであれば何かが大きく間違っています。
モノレポは開発環境における重要トピックであるのでこれを本当にやるんだったら結構大きい変化だと思います。
それに対してCFOに意見を優先させるのは確かにおかしいと思います。
時間をかけて機能的優先事項への配分をすり抜かし、それを機能横断的優先事項に変換することによってこの問題の根本に対処しましょう。
21:04
コンプライアンス、セキュリティ、信頼性というものは本来会社の基本的な仕事であるべきで、目に見えないエンジニアリングの機能は仕事ではありません。
エンジニアリングの仕事を機能的な割り当てから外すことは非エンジニアリングの幹部を率いる予定をするよりもはるかに効果的です。
エンジニアは本来エンジニアリングだけをしたいという方も結構いらっしゃると思うので、まあ難しいっちゃ難しいんですけどね。
本来のエンジニアリングの機能的な仕事ではないというのは理解しつつ、どう割り当てるかということですね。
また割り当てから何を外すかというのは結構大事ですね。
それを非エンジニアリングの幹部を率いるよりは全然いいと思います。
エンジニアリングがわかってないそういう幹部級の方っていうのは経営目線とか違う目線、外からの目線でお話はしてくださるんですけど、なんだかんだバッティングする気がするのでね。
少なくとも理解がある方であるんだったらもう少し話は別かなと思いました。
時間的にじゃあ次でラストにします。
Keep the allocation fairly steadyですね。配分をかなり安定させましょうという話です。
エグゼクティブにとって最も一般的なアロケーションの課題っていうのは、アロケーションを頻繁に調整しすぎることになりますと。
なるほど。理論的に理想的な配分を追求し続けるよりも、継続的で狭い範囲での変更を好むべきであります。
配分を変更することは進歩のように感じられますが、変更のたびにかなりの混乱が生じるため、頻繁に並行することは大きなペナルティもあります。
そのため現在の配分が最小最適でない場合でも、資源配分の現状位置に強いバイアスをかけるということをお勧めしておきます。
割当てを頻繁に変更しない理由、もう一つの理由ですね。
もう一つの理由は、チームが割当てを奪い合うことに過度に集中し、仲間とのゼロサム競争になってしまう可能性があるからです。
これは文化的に好ましくないことであり、チーム間の競争なしに、無限のリターンが期待できる創造的な問題解決という、より価値ある機会から目を逸らしてしまうのでということでした。
アロケーションをそんなに頻繁にやるのは、計画が破綻しているので、あんまりよろしくないし、そこをやるとなすと、やっぱりペナルティというかペインを伴う形ですよね。
本当にやる価値があるかというのは、しっかり考えたり、一般の人の意見を聞きつつやるときはガツンとやりましょうという感じだと思いますね。
はい、というところで、ちょっと長くなりましたけど、今日の朝方は以上にしていきたいと思います。
明日もこの記事を続けていきたいと思いますが、恐らく明日も読み切れないので、明後日まで続きたいと思います。
本日の参加者は増えてた。
赤神さんとケンジさんと日賀シンというものか日賀シャインというものかちょっとわからないですけど。
リソースフルなテマさんとミニさんと見えてないですけどスーさんですね。
ご参加いただきありがとうございました。
木曜日ですね。あと1日、金曜日までですけども、今日も1日頑張っていけたらなと思います。
それでは終了したいと思います。お疲れ様でした。
