1.3 開発生産性が経営層に伝わらない理由は、"言語"が違うから
最近、よく聞く話題として 「開発生産性に投資する意味が経営層に伝わらない」 という悩みをよく聞きます。開発チームとしては開発生産性をあげるために、リファクタリングやシステムリプレイス、開発生産性を測るためにモニタリング基盤を導入したいが予算が下りないといった会話です。
いわゆる、スコープクリープ（追加要望）問題と言われるものですが、その理由はシンプルに同じプロダクトと早く・良いものをデリバリーしたいという目的でも 会話のプロトコルが違うためと考えています。
年間で決めた戦略から予算を決め、達成するために必要な戦術（施策）があります。経営層やPdMやPMといったビジネスのことも考えているメンバーは、Aという施策は予算500万程度、B施策は2,000万の予算でリリースしたい思いがあるはずです。
一方、開発チームはプロジェクトが進む中で、初めのほうはスケジュールを守れていたとしても、初動のスピードを重視するあまり内部品質に問題がでてきます。現代のソフトウェアにおいて、システムの内部品質の現状維持は衰退を意味している ので常にメンテナンスという名のリファクタリングが欠かせません。
これを無視し続けても、数カ月後には開発生産性が落ちてくることは明白なため、途中で追加工数を交渉しますが、システムの内部的な構造の見えづらさから中々納得させることができません。なぜならエンジニアではないメンバーにとっては 目に見えていないものなのは理解ができないから です。エンジニアではないメンバーから明確に見えるものは、追加コストによって予算が減っていくことだけです（ただ、リファクタリングをしたからと言って、内部品質が改善され、生産性が継続的に維持できているのは、チームのスキルによるところもあるので難しいです）。
お互い「良いものを早くユーザーに届けるために開発を早くしたい」と言っていることは同じでも、達成するために必要な要素を 片方は予算を考えており、もう片方はシステムの品質 を考えています。開発において、遅れた事実は明白ですが、“なぜ遅れたか”は数値化しにくいのです。生産性が悪化する要因をきちんと言語化するほか、説明責任は自分たちが果たしたり、期待以上のスピードで機能をリリースしたりして信頼を得ることが開発組織には必要です。
1.3.1 "開発生産性"という言葉は、レイヤーごとに意味が違う
これらの問題を解決するための第一歩として、開発生産性が 組織レイヤーでそれぞれ異なる意味を持つことを理解しなければいけません。開発組織には開発組織の考え方があり、経営層、事業責任者（BM）、PdM、PM、EM、経理部門にもそれぞれの考え方と異なる影響度があります。開発生産性を良くする意味とアプローチ、その抽象度も異なるのです。
例えば、以下の体制図があったとします。2つの事業があります。1つ目の事業は年商100億円でその分所属人数も多く100人います。体制としてもマネジメントコストによる組織の細分化が進んでおり、BM（事業責任者）→ PdM（プロダクトマネージャー）→ EM / PM / Director → Engineer / Designerという体制です。一方の事業は、年商1億円で所属としても10人のため、PdM配下にEngineer / Designerといったクリエイター組織が紐づいている状態です。
それぞれのレイヤーにおいて、開発生産性の向上から受ける恩恵と考える責務は以下です。
- 開発組織にとっての開発生産性は、具体的な開発作業のスループット（1人月あたりの生産性） を通じて、開発生産性を直接的に測定し、改善します。具体的には継続的なデリバリー速度（短期的ではなく）を目的としたプロセスの改善（トランクベース開発など）、技術投資（リファクタリングなど）になります。
- PM/EMで言えば、開発組織が生み出す生産性（1人月あたりの生産性）を工数として扱いながら価値を提供する速度の効率と効果を評価します。プロダクト管理やチームマネジメントを行い、プロダクトを前に進めることに集中します。
- PdMや事業責任者（BM）であれば、1人月あたりの工数単価から開発コストを金額として算出し、P/L（損益計算書）をもとに戦略と戦術に向き合います。
- 経営層については、これらすべてを包含しながらも経理部門と協力しながら、損益計算書（P/L）や貸借対照表（B/S）などの財務諸表を通じて、開発生産性の財務的な影響を評価します。これには、一般管理費やB/Sでいうソフトウェア資産、減価償却などが含まれます。
この多様性を理解することは重要であり、異なるレイヤー間で良いソフトウェアが企業価値を高めるためには、これらを適切に接続する必要があります。そのためには、異なるレイヤー間のオーバーラップする部分、つまり接続箇所の設計が重要になります。異なる視点や専門知識を持つ各レイヤー間での協力を促進することで、全体としての開発生産性を向上させることができます。
1.3.2 "開発生産性"の意味を変換して、入力と出力で渡してあげる
オーバーラップする部分を可視化開発生産性の概念で変換して、組織内の異なるレイヤー間での入力と出力として伝達するアプローチを考えていきます。
下図は、そのマッピングの一例です。全員がプロダクト、ユーザーに向き合っていることを前提に、開発生産性に対してはどこに向き合っているかを考えました。
| レイヤー | 入力（input） |
処理（model） （向き合い） |
出力（output） |
| 開発組織 | 人 | ソフトウェア開発 | 1人月あたりの生産性（スループット） |
| PM / EM | 1人月あたりの生産性（スループット） | 価値提供速度の未来予測 |
工数・スケジュール （工数の手戻りコスト削減など） |
| BM / PdM | 工数・スケジュール |
工数 × 単価を人的予算の基本として 戦略・戦術の遂行計画 |
P/L（一般管理費） |
| 経理 | 開発したプロダクト | ソフトウェア資産計上か費用かの振り分け | 税負担・減価償却費（P/L） |
