速さの前に、目的・指標・約束を揃える
では、何から手をつけるべきでしょうか。答えは、いきなり速くすることではありません。
開発生産性の本質はPR数やデプロイ頻度そのものではなく、開発組織がいつまでに何ができるかと語った約束がどれだけ信頼できるか、という点にあります。いつまでに、どのクオリティのものが届くか、という期待のズレが大きいほど悪い意味での管理をしたくなり、現場は速くしろと言われ続けます。事業責任者やプロダクトマネージャーは市場の変化に合わせて、欲しいタイミングで欲しいものが出るかという計画の信頼性を見ています。エンジニア側の内部指標が改善しても、事業側の信頼に結びついていなければ良くなった実感は生まれません。遅れること自体より、なぜ遅れたのか、次はどう変わるのかを説明できないことが不信につながります。
立場によって、開発生産性の意味はずれます。経営は売上やコスト、利益への貢献を、PMはユーザー価値や機能の完成度、スケジュール遵守、競合優位性を、エンジニアは開発スピードとあわせてコード品質、技術的負債、持続可能性を重視します。このずれを放置したままスピードだけを上げても、誰のための改善かが定まりません。
速さを動かす前に、次の三つの認識を関係者で揃えてください。
- 何のために開発生産性を向上させるのか
- どの指標で測定するのか
- その数値を誰の、何のために使うのか
そのうえで、スコープ、リリース日、品質のどれを動かすかを決めます。今回のリリースに含める機能を切り出す、顧客と営業と品質を確保できる現実的な日程を再議論する、大枠で進めるのをやめ、要件定義を一段落つけてから実装に入る、この日程ならこの範囲の実装とこの品質を担保できると関係者で明示する。人を足す以外の選択肢を、合意のうえで並べることが第一歩です。
合意した内容は、議事メモやプロジェクト計画など、後から参照できる場所に残してください。なぜこの日程、この範囲、この品質にしたのか、どの前提が崩れたらどう動くのかを共有しておくと、遅れが起きたときに会話が変わります。遅れた事実だけを話すのではなく、なぜ遅れたのか、次はどう変えるのかを、同じ情報を見ながら議論できるようになります。
現場で明日からできることは、スピードの議論に入る前に、上の三つの問いをメモに書き、上司やPMと15分でもよいので認識をすり合わせることです。指標の改善案を出す前に、何のための数字かを揃えるだけでとにかく早くという会話の温度は下がりやすくなります。
おわりに
速く出せば生産性は上がる、というのは誤解です。スピードを上げる前に何を約束し、どう信頼を積むかを揃える必要があります。速さの議論を止めるための話ではなく、速さを支える土台を先に整えるための話です。
冒頭の決済基盤の改修も、計画の信頼性を伝えたい意図が「とにかく早く」として届き、スピードが正義化した先では忙しいのに遅れと品質への不安だけが残る。その構造が、いま解体した誤解の行き先でしたが、結果として目的・指標・約束を関係者で揃え直し、計画の信頼性を「とにかく早く」と読み違えないようにしたことで、設計に必要な時間を確保したうえで計画どおりに価値を届けられる組織になりました。誤解を解けば、スピードと品質は両立しうるということです。
次回はその信頼を支える数値をどう扱うか、第2回「数値の誤解 〜開発生産性は定量化できるのか〜」で扱います。
参考文献
- NIST. The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002.
- Martin Fowler. Is High Quality Software Worth the Cost?
- Ward Cunningham. The WyCash Portfolio Management System, OOPSLA '92. 比喩の解説
- Forsgren, N. et al. The SPACE of Developer Productivity. ACM Queue, 2021.
- フレデリック・ブルックス. The Mythical Man-Month: Essays on Software Engineering (1975/1995). Addison-Wesley.
