3.4 開発の投資対効果を測るのは難しい
また、開発生産性を上げる取り組みは現状の進行しているタイムライン（プロジェクト）とは別の追加リソースで行うことが多く、何をするにも技術投資額（予算）が必要です。予算をつけるにはよく費用対効果を求められますが、ソフトウェア開発の成果（投資対効果）を定量化するのは非常に難しいという問題も、複雑性を加速させているでしょう。
生産性は、アクティビティの入力とその出力を観察することで判断できます。そうなるとソフトウェア開発の出力（成果）を正しく測定する必要がありますが、技術投資額とそれに対するリターンは、P/L（損益計算書）の人件費と関連指標を確認すれば多少できるかもしれません。しかしながら、機能単位やプロジェクト単位の判断は難しいです。基本は、かけた工数（とバグなどの品質）を変数としてその投資額の妥当性を評価するのがメインだと考えています。ここは次回の記事で詳細に説明します。
また、ソフトウェア開発では時間軸として半年後、1年後、数年後を見据えて「今やっておくべきこと」が多く存在します。システムのリファクタリングやリプレイスはこれに関連し、例えばスピード感を持って0→1を作ったときに内部品質を犠牲にしているケースはよくあります。その借りはどこかで返済しないといけないので追加予算が必要になります。さらに、時間が経てば立つほど解決までの時間は悪化していくので、返却額は増えていきます。
ソフトウェアの内部品質が高いものと低いものを比較すると、機能追加の損益分岐点からわずか1カ月で逆転していきます（マーティン・ファウラー氏の記事から引用）。
つまり、初期はスピード重視で品質を犠牲にすることで開発は早くなるが、1カ月後には内部品質（テストなど）を初期から整備していたほうが早くなるということです。
一方、プロモーションやキャンペーン、効果に直結するエンハンス開発はリリースした直後に数値（例えば売上）として跳ね返ってくるほか、KPIがLTVでも期間で予算のリクープの計算がしやすい側面があります。
こうした投資において、長いスパンで効果が出るものと、短いスパンで出るものがある時間軸のズレが、技術投資への判断を揺るがす難しい点の1つです。直近の売上を重視するほか、予算未達に着地しそうな場合は、どうしても技術投資ではなく目先の利益を取る開発を重視しがちです。
とはいえ、ソフトウェア開発についてまったく説明責任を果たさないわけにはいきません。ソフトウェア開発のブラックボックスが組織全体に伝わらず開発組織は信頼を獲得できません。なぜ複雑に見えるのかを考えていくと「見えやすく測りやすいもの」と「見えにくく測りにくいもの」の境目がはっきりしているところにあると考えています。
3.5 遅れた事実はわかりやすいが、"なぜ遅れたか”は測りにくい
プロジェクトの遅れに着目すると、遅れた事実は測りやすいが、なぜ遅れたかは非常に測りにくいものです。例えば、下図の緑線にある通り、15人月で見積もったプロジェクトがあったとします。初動は順調にスタートすることが多いのですが、だんだんプロジェクトが進むごとに設計の漏れが発覚し、実装しながら新しい設計を始め作った機能との整合性が取れなくなるなど、カオスになっていきます。次第にスコープクリープ（仕様変更や追加仕様）が発生し、どんどん終了予定日がズレてきます。こうしたことはよくあり、その度に自身の見積もり力（設計力）の甘さを痛感します。
問題なのはそのときに「なぜ遅れたのか」「なぜ毎回遅れるのか」を説明できるかです。これには事業/経営者目線と開発組織目線の両方の観点から考えていきます。
3.5.1 事業/経営目線
事業/経営レイヤーが、年間もしくはクォーター単位で事業戦略や予算管理をする上で、戦術としての機能開発にどのぐらい工数がかかるかは当然ですが開発組織と会話します。事業/経営レイヤー側からすると、エンジニアの見積もりを信じて事業の計画を作ります（作るしかないとも言えます）。
しかし、毎回プロジェクトは遅れます。ただ、なぜ遅れるのかはわからない。そのため事業計画にズレが生じます。多少ならバッファの範囲内だが、大きなプロジェクトが計画されていた場合は大きくずれることがしばしばあります。
そうなると、何を考えるかというと リカバリーのための人件費（エンジニア、PM） の投入を考えます。そこが操作可能変数だからです。これは正しい側面もありますが、開発組織の観察がうまくできていないと逆効果にもなります。
3.5.2 開発組織目線
一方、開発組織側に目線を移すと見積もりによる計画は、そもそも大なり小なり外れるかもしれないという認識があります。ペインとしては、遅れた事実はわかりやすいが、 “なぜ遅れたか” は伝わりにくいという点です。これは数値の可視化難易度が影響しています。測りやすいものは見えやすく、測りにくいものは見えにくくて伝わりにくいです。
細かい単位でWBSで進捗を管理し、issueのestimateを観察していれば、日々ズレはどこかで発生します。プロジェクトの進捗やIssue単位での見積もりといった測りやすい部分は「遅れた」と、その事実は誰の目にも見えやすい形で報告可能になります。そこでの対策は、プロセスの順番入れ替えやスコープを落とす、残業でカバーといった対策になりがちです。
ただし、実際の根本原因は前述した通り、システムの内部品質の問題だったり、技術負債の返却・リファクタリングができない環境、SRE領域の共通プラットフォームやエコシステムがないことでの各チームの認知負荷が高いことだったりします。これらの解決はとても時間がかかるがゆえに、なかなか対応できない中で常に複数の施策やプロジェクトが進み、その都度根本原因の対策が行われないまま小手先の対策だけが行われ、遅れが発生して信頼を落とすという現象が起きます。
さらにリカバリープランとして大量に人員を投入された場合、気をつけないと「人月の神話」で表されるブルックスの法則に陥ります。ブルックスの法則は「炎上しているプロジェクトに人員が投入されても、さらに炎上するだけである」という法則で、これは既存のメンバーはただでさえ炎上しているプロジェクトの中で数多くの仕事があるので、新しいメンバーのオンボーディングが満足にできないため、新しいメンバーが生産性を発揮するまでに時間が長くなることが原因の1つです。
開発組織としては、その人件費予算を本来であれば既存チームとは別にチームを立てて内部品質の改善を進めたいが、ビジネスサイドからすると「あと3カ月後にリリースが迫っているから納期に間に合わせてほしい！」という要望になるので、炎上しているプロジェクトのタスクに着手する人員追加に当てられます。
結果としてなかなか手が出せないという状態が続き、時間が経つにつれてさらに負債の返却する利子（工数と難易度）が上がっていくというカラクリです。現場のモチベーションも低下するので、バーンアウトも気をつけるべき部分でしょう。
つまり、お互いが同じ目的でプロジェクトを成功させたいと思っているにもかかわらず、課題と解決策があっていない状態であるゆえに、組織に溝ができるのは大変悲しいことです。なので、開発組織の生産性を上げて組織を強くしていかなければいけません。
第2回、第3回（今回）の記事で、開発組織目線で考える開発生産性のペインを中心に述べてきました。次回は、見積もりの精度問題やソフトウェア開発の複雑性がある中で、開発組織はどのように生産性を考えていけば良いのかを予測し、工数ベースでの開発手法について紹介します。
