エンジニア組織の年次計画とミッションツリー
CTO となり一年が経ちました、あっという間ですね。以前とは違うマネジメントの考え方が形になってきたので、筆を取ります。
- 財務視点でのエンジニア組織年次計画の作り方
- ミッションツリーとロールの関係
1. 財務視点でのエンジニア組織年次計画の作り方
バーンレートを正しく意識する
「自分たちが扱う事業モデルは、サービスで主要な売上を得ていますか？プロダクトで主要な売上を得ていますか？」
- SaaS のような月額課金モデルは、プロダクト売上構成比率: 高、サービス（導入時のコンサルティング等）売上構成比率: 低の関係性になりやすい
- 仲介業のような契約手数料モデルは、プロダクト売上構成比率: 低、サービス売上構成比率: 高の関係性になりやすい
- 主要な売上を担う領域に、主要な予算が割り当てられる
要は事業モデルよって、プロダクト開発（≒エンジニアリング）を営業キャッシュフロー（以下CF）扱いと見るか、投資 CF 扱いと見るかの基本方針を変えています。
基本方針を前提に、戦略を加味した意思決定を行うためにもう一つ観点を入れます。
- 創業期 / 発展期 / 成熟期 / 衰退期 等の事業成長フェーズによって CF が - になる意思決定もする
- 基本は CF が + になるように計画・管理したい
CF の扱いと戦略的意思決定を持って予算計画化。
エンジニア組織人数規模を、バーンレートの適切性観点で説明可能であるように心がけています。
粗利対人件費率を用いたエンジニア組織計画
「自分たちが扱う事業において、粗利対開発人件費率の指針を持っていますか？」
エンジニア組織としての予算計画は、ほぼほぼ人件費の計画と言っても差し支えないのではないでしょうか？
人件費に対する基準作りは、経営を行う際の共通言語として役に立ちます。
準備 1: 業界水準
自社事業における具体基準を作る際には、IR 等の公開情報から必ず同一業界他社をリサーチします。
業界水準を把握して目安とすることは、現実味のない基準値を生まないための予防ですね。
準備 2: 総人件費のセクション別構成比率の優先度を捉える
営業 CF と見るか？投資 CF と見るか？を定めることを最初に言葉にしました。
これを使って事業におけるセクション（営業部門・開発部門等）別構成比率の優先度を考えます。
営業 CF 扱いならば 開発人件費増 = 売上増 の単純な構図になりやすく、セクション（営業部門・開発部門等）別構成比で 50%~ 等に設定。投資 CF 扱いならば 開発人件費増 ≠ 売上増 の構図にもなりえるため、セクション別構成比で10%以下等に抑制。
※ 50%や10%といった数字は説明のための一例です
というようなイメージで捉えます。
エンジニア組織が社内で一番大きくて良いか？いやはや営業組織のほうが大きい方が良いか？大枠の検算に利用します。
準備 3: 最小構成人数の年次設計
- エンジニア組織が向き合うプロダクトやシステム群をチーム単位に分解、ヘッドカウントをプロットする枠を整理
- 専門性毎にアサイン・主幹プロダクトにリソース冗長性・一人チームでOK等、プロダクト開発に必要な最小構成を設計
- システム改善・マネジメントリソース等、エンジニア組織運営に必要な最小構成を設計
- 事業戦略・サービス戦略・システム戦略等、新規プロダクト開発や SLO 維持向上に必要な最小構成を設計
アウトプット（サンプル）
- 準備 3 の最小構成での人数規模 x 平均人件費の総額の粗利比率を算出
- 準備 1 の業界水準から逸脱しすぎていないこと
- 準備 2 のセクション別構成比観点で投資不足 or 投資過多な数字となっていないこと
3 点を念頭におきながら、粗利対開発人件費率の妥当な基準範囲を設定。
これは CF が + になるように計画・管理するための素案扱い。
フェーズや状況によって意志をもって基準を上げる判断等をする（いわゆる成長投資をエンジニア組織に設定すること）。
アウトプットの利用用途
アウトプットをどのように計画に使うかというと、エンジニア組織人数の年次ギャップ = 採用計画 として扱える。
報酬設計見直し時の論拠として、平均年収上昇させても粗利対開発人件費率の基準に収まっているのだから、経営観点で実行判断可能だよね？という起案や交渉が行える。
短期計画の達成に開発力がスポットで必要、粗利対開発人件費率の基準に収まる前提ならば業務委託採用枠を増やす判断に利用する。
etc...
色々な使い道があります。
開発量が増えていることの説明
「人数に比例して開発総量が増えていますか？」
人が増えているのに、プロダクト開発のスピードはなかなか上がらないのはなぜか？この問いを投げかけられた時の説明、これも共通言語を作っておきたいですね。
開発生産性の概念における代理指標群を用いて、開発量を説明可能な状態にします。
生産性指標で何が読み解けるのか？抽象的な部分を例示してから、年次計画に盛り込みます。
生産性指標のモニタリングによる考察の一例
- ハイパフォーマー 2 人（黄 + 水色）で構成されたチーム A は、個のパフォーマンスの高さ + レビューサイクルの早さによってハイアウトプット状態を長期実現
- 長期運営プロダクト、新規プロダクト、専門性別（Android / iOS / Backend / Frontend 等）、システム資産の特性によってパフォーマンスに有意差あり
※ presented by エンジニアリング組織のパフォーマンスを最大化 Findy Team+
自組織の開発アクティビティを考察することで、生産性に対するハイパフォーマー影響度の示唆や、システム資産の複雑度の違いによる影響度の示唆が得られる。
なぜシステム戦略を立ち上げ、システム資産の複雑度を解消するのか？それは、開発アクティビティの変化を通して生産性が向上し、最終的なアウトプット量の増加へと接続させたいからに他ならない。
生産性指標を用いると、このような説明ができると捉えています。
年次計画への盛り込み
- 開発アクティビティの代理指標から
一人当たり実装数（日）、総実装数（年）を盛り込む - 人数規模増・開発総量維持 → 生産性低下 = 開発人件費 ROI が悪化
- 人数規模維持・開発総量増 → 生産性向上 = 開発人件費 ROI が改善
生産量の代理指標を年次計画へ盛り込むことで、人数に比例した開発総量の変化を認識できるようになる。
最低限ここからモニタリングを始めておくと、システム戦略案件の ROI を開発アクティビティの改善率によって、成果判定や振り返りに繋げられるのも嬉しいですね。
※ Findy Team+ は DevOps 指標 / サイクルタイム / 個人アクティビティと他にも多くのモニタリングに有用です
2. ミッションツリーとロールの関係
年次計画が出来上がった次は、どのようにマネジメントを行うか？ですね。
ミッションツリーとしての分解や、各種ロールに託したいことの連続性や関係性を一枚絵にして概念整理を行います。
これらを前提に、個々人に何を期待かけるか？や、明確な目標管理がある組織においては目標設定に繋げるのが良いのではないかと考えています。
ビジネス要件を前提とした SLO
最小構成人数の設計の説明や、ミッションツリー内に SLO を記載しました。
財務視点のパートでは語りませんでしたが、エンジニア組織のマネジメントにおいて品質に対する考え方をなくすことはできません。
大枠としての考え方を方針として持ち、エンジニアメンバーと共に管理していきたいですね。
「ビジネス要件を前提とした 」というのは、これまた事業モデルを軸に基準値を決めようという流れです。
事業特性を考慮する一例
医療
生死の倫理観が求められる場合、システムが止まっている事が許容されにくい。
だから、システム稼働率が 99.999% 等、一定水準を保つ目標設定と予算を設定する。
ソーシャルゲーム
イベント時にどれだけアクセスを捌き切るかが売上に強く関連する。
だから、システムパフォーマンスとしてレイテンシー 100msec 以内等、一定水準を保つ目標設定と予算を設定する。
不動産（自分の扱う領域での考えも）
オフライン接客等のサービスによる売上が主流、必ずしも高頻度アクセスを捌くことが求められるわけではない。
しかし、高額商材な部類であるため一つの機会損失の影響度は大きい。
よって過剰投資こそしないが、安定稼働の担保・規模拡大や年数経過による性能劣化を抑制できるだけの予算を設定する。
事業モデルをキチンと読み解くと、そこには求められるシステム品質の輪郭があって、SLO の具体基準値への示唆がある。
SLO を維持向上することに対して、専任や予算をつける必要性が認識されてヘッドカウントを変える、だから人件費として財務指標が変わる。
うん、財務側にも繋がりましたね。
おわりに
また一年後には違った思考をしているしれませんが、今回はこの辺で。
次の一年は 、DevOps 指標・プロダクト生産量をブレイクダウンしてマネジメントに落とし込めるように精進します。
ではまた！
