ソフトウェアチームの経済学：なぜ大半のエンジニアリング組織は財務的に「目隠し」されているのか
(viktorcessan.com)- 大半のエンジニアリング組織は、チーム単位のコストと価値創出を数値で把握できないまま運営されており、これは財務的な非効率につながっている
- 8人規模のチームの年間コストは約 €104万（月 €8.7万、日 €4,000） であり、機能開発や改善の遅延など、あらゆる意思決定が明確な金銭的影響を持つ
- 内部プラットフォームチームと顧客向けプロダクトチームのいずれも、損益分岐点と3〜5倍の価値創出基準を計算できるが、実際にこれを追跡している組織はまれ
- 過去20年間の低金利・成長重視の文化が財務規律を弱め、大規模な組織と複雑なコードベースを資産ではなく負債へと変えてしまった
- LLMの登場によってこうした構造的非効率が露わになり、チームごとのコスト・価値・収益性を定量的に測定する組織が長期的な競争優位を確保するようになる
ソフトウェアチームの経済学：なぜ大半のエンジニアリング組織は財務的に「目隠し」されているのか
- ソフトウェア開発のコスト構造とチーム単位の経済的妥当性を数値で分析すると、多くの組織がこのデータを認識しないまま運営されていることがわかる
- 8人規模のチームでは年間約 €104万（月 €8.7万） が必要で、これは1日あたり約 €4,000 のコストに相当する
- 内部プラットフォームチームも顧客向けプロダクトチームも、損益分岐点(break-even) を超えるために必要な価値創出量を計算できるが、実際にこれを追跡している組織はほとんどない
- 過去20年間の低金利環境と成長重視の文化が財務規律を弱め、大規模なエンジニアリング組織や複雑なコードベースを「資産」だと錯覚させてきた
- LLM(大規模言語モデル) の登場によってこうした構造的非効率が露わになり、各チームのコストと価値創出を明確に測定する組織が競争優位を確保するようになる
実際のチームコスト構造
- 西欧を基準にすると、ソフトウェアエンジニア1人あたりの年間総コストは €120,000〜€150,000、平均で €130,000 程度
- 給与、社会保障費、年金、機材、管理費、オフィススペースなどを含む
- 8人チームの年間総コストは €1,040,000、月 €86,667、日 €4,000
- 大半のエンジニアや管理職でさえこの数値を知らず、優先順位決定の過程にコスト意識が反映されていない
- 機能開発、改善の遅延、プラットフォーム再構築など、あらゆる意思決定には明確な金銭的コストが伴う
- 例：3週間かけてユーザーの2%向け機能を開発するのは、約 €60,000 の意思決定に当たる
内部プラットフォームチームの損益分岐点計算
- 8人規模のプラットフォームチームが100人のエンジニアを支援していると仮定する
- 月間コストは €87,000 で、これを相殺するには同等の価値創出が必要
- エンジニア1人あたりの月間コストは €10,800（時間あたり €65）
- 100人基準で月 1,340時間削減（1人あたり週3時間） できれば損益分岐点に達する
- 単純な時間削減だけでなく、障害の減少などによって直接的に売上を守る効果もありうる
- しかし大半のチームは、こうした数値を測定も意思決定への反映もしていない
- 現実的な財務健全性の基準は、3〜5倍の価値創出（月 €26万〜€43万）
- システムの維持・更新コストや失敗率（50〜70%）を考慮する必要がある
- 単なる「損益分岐点」ではなく、持続可能な収益性の確保が必要
顧客向けプロダクトチームにも同じ論理が当てはまる
- 顧客向けの8人チームも月 €87,000 のコスト構造を持つ
- 1ユーザーあたりの月間売上が €50 なら、損益分岐点は 1,740人分の価値、 3〜5倍基準では 5,000〜8,700人分の価値 が必要
- 解約率(churn) の改善が最も直接的なレバー
- 例：5万人のうち月2%が解約（1,000人、€50,000 の損失）→ 原因を取り除けば損益分岐点の大部分を埋められる
- アクティベーション率(activation) の改善も重要
- 月間新規1万人のうち30%しかアクティブ化しない → 5ポイント改善すれば500人が追加転換し、€25,000 の追加売上
- コンバージョン率(conversion) の上昇も同様の効果を持つ
- 2万人のトライアルで 4%→4.5% に転換すると、100人の追加課金化で €5,000 の追加売上
- 複数の指標の小さな改善が積み重なって大きな財務効果を生むことがあるが、 大半のチームはこうした指標と財務結果のつながりを測定していない
なぜ財務的な測定をしないのか
- 多くのチームは velocity、チケット数、機能数、NPS、CSAT など、活動・感情指標ばかりを追跡している
- これらは財務指標の代替物ではなく、まったく別のカテゴリである
- 活動指標が改善しても、財務成果は悪化しうる
- 機能数の増加 → 間違った機能かもしれない
- エンゲージメント上昇 → 実際の売上に貢献するユーザーが減っている可能性もある
- こうした指標が選ばれるのは、測定・報告・成果の演出が容易だから
- 財務指標は不都合な真実を明らかにすることがある
- 大半の組織は、透明な財務測定の文化を意図的に築いていない
過去20年間の背景
- 2002〜2011年：金利は低かったが、投資家のリスク回避によって財務規律は保たれていた
- 2011〜2022年：ゼロ金利・リスク選好の回復・SaaS成長ロジックが結びついた
- 11年間、企業は人員急増、低効率、誤った優先順位にもかかわらず、成長率によって許容された
- この時期に形成されたリーダー世代は、財務成果を求められない環境で育った
- そのため、2022年以降に資本コストが上昇しても、行動が自動的に調整されない
「資産」と誤認されたエンジニアリング組織の負債
- 大規模なコードベースやエンジニアリング組織は、伝統的に資産(asset) と見なされてきた
- 蓄積されたビジネスロジック、技術基盤、組織能力など
- 実際には、保守負担・調整コスト・意思決定の遅延が積み重なる負債(liability) の構造である
- 複雑性の増大によって生産性が低下し、コストが上がり、収益は停滞する
- 過去には低金利環境がこの負債を覆い隠していた
-
LLMが明らかにした現実
- 開発者 Nathan Cavaglione はLLMエージェントを使って、14日でSlackの中核機能の95%を複製した
- Slackには数千人のエンジニアが10年以上をかけて開発し、数十億ユーロ規模の投資が行われてきた
- Nathanは組織の複雑性・既存アーキテクチャ・調整コストなしに、類似製品を短期間で完成させた
- これは、大規模組織の規模・複雑性・蓄積コードが競争優位であるという前提が、もはや有効ではないことを示している
- LLMコードの保守性には課題があるものの、 エージェント-エージェント環境では人手による保守よりコスト・速度の面で優位に立つ
今後先行する組織の条件
- 競争力の核心は技術ではなく分析能力
- 各チームのコスト・価値・収益性の閾値を明確に把握する組織が構造的に優位に立つ
- こうした組織は次のことが可能になる
- Build vs Buy の判断を、実際の経済性に基づいて行う
- 収益性の限界を下回るチームを特定する
- 遅延による価値損失を定量化して優先順位を調整する
- 大半の組織には現在、測定インフラ・データフロー・習慣が欠けている
- 構築の過程は不快でも不可欠
- チームが財務的な結びつきのない仕事に四半期全体を費やしていたことが判明するかもしれない
- 過去には低金利と成長重視の論理がこれを許容していたが、 AIで開発コストが急落し、投資家が財務成果を求める環境では持続不可能
- チーム単位の経済性を明確に問い、測定する習慣を持つ組織が、 時間が経つほど複利的な競争優位を積み上げていく
1件のコメント
Hacker Newsのコメント
この記事の要点は、プログラミングそのものが難しいのではなく、何をプログラミングすべきかを見極めることこそが本当に難しい部分だということ
実際には、まず間違ったものを作っては置き換える過程を何度も繰り返しながら、問題空間を探っていくことが大半だ
プログラミングはしばしば最終成果物ではなく、問題定義を明確にするための手段に近い
単にフレームワークを組み合わせるだけなら簡単かもしれないが、複雑なシステムを扱う環境では、プログラミングそれ自体が本当に難しい仕事だ
単純な要求が巨大なシステムへ膨らんでいくのをよく見てきた。ただし、Googleのようにインフラへ賢く投資すれば競争優位を得ることもできる
ただし、こうしたアプローチはしばしば非生産的に見えたり、「間違ったことを言う人」だと誤解されたりしやすい
多くの開発者は自分のプロジェクトが特別だと錯覚しているが、実際にはすでに実証済みの設計をコピーするだけで十分な場合が多い
記事にあるように、コードが素早く生成されると管理が難しくなるという懸念はもっともだが、人間が保守しないのであれば重要性は下がる、という主張だ
だが私は、その論理を**「アジャイルコーチLLM」**にも適用できると思う。LLMはすでに大半の洞察をはるかに低コストで提供できる
結局、人間はプールサイドで休めるようになるのかもしれない
「汚いコードベースでもエージェントを何体も投入すれば解決する」という主張には同意できない
実際には、見た目は完璧でも内部はフォーム製の建物のように構造的に間違っているコードが多い
こうしたコードは時間がたつと拡張不可能になり、やがてレンガのように固まってしまう
私もAIが作ったプロジェクト2件が完全に失敗した経験がある
エージェントをさらに投入しても進展はなく、できあがった成果物の大半は間違った方向を向いていた
「ソフトウェア開発は資本集約的な活動だ」という主張には同意するが、業界ごとに文脈は異なる
電力会社や製造業者は、ITよりも物理インフラの維持費のほうがはるかに大きい
ただ、SaaS契約があまりに増えたことで、LLM開発者を雇うほうが経済的かを検討する企業は増えている
記事を興味深く読んでいたが、Slackクローンの例で信頼を失った
実際のSlackの規模、安定性、機能性をまったく理解していない主張だ
企業向け製品では、こうした細かな機能が何百も必須になる。単純なコピーは競争ではない
数字とグラフだけを大量に投げつける記事は、議論に勝ちたい人の文章に見える
Rory Sutherlandの言うように、「Finance People」は確実性と予測可能性に執着する
だが世界はそんなに単純ではない
記事の細部よりも、コストに対する価値を考えないエンジニアリング文化には共感する
会議やインシデント対応の場で、費用対効果を考えずに過剰な対応を取ることが多い
技術的負債も同様で、コストが分からなければ責任ある選択はできない
「プラットフォームチームは時間短縮によって価値を証明すべきだ」という単純計算は間違っている
プラットフォームチームは単に時間を節約するのではなく、ビジネスリスクを減らし中核的な品質を保証する役割を担っている
これは単なる経済論理ではなく、組織に不可欠なインフラの問題だ
結局重要なのは、チームがプロダクトを心から大切にしているかということだ
短期的なキャリアよりもプロダクトそのものを重視するチームだけが、指標や管理手法を超えて本当の成果を出す
ただし、そもそも愛着を持てない構造のプロジェクトもあり、生産性の限界が明確な場合もある