現場で起こる開発生産性の重圧
「うちの開発、もう少し早くならないか」
DMMのある開発現場の例を出せば、こうした一日と重なります。
周りからは開発生産性の改善を求められますが、一方で開発生産性が何を指すのか、何をどう測るのかは、関係者のあいだで共有されていません。エンジニアが見ているのはプルリクエスト（PR）数やデプロイ頻度、経営が求めているのは計画の信頼性や予測可能性です。何が問題かも、何を指標にするかもずれたまま、現場にはとにかく早くという圧力だけが降ってきます。
例えば、長年動いている決済プラットフォーム基盤に対して比較的影響範囲が大きい改修を入れる際には、複雑で重要なシステムがゆえに本来設計に時間をかけるべきにも関わらず、全社的な優先度が高い（投資対効果が高い）といった理由でスピードが正義になります。正確に言えば、速く出すことが正義だと開発チームが思いこんでいる部分もあるでしょう。レポートラインレイヤー（圧をかけているとされる側）からすれば、後述する計画の信頼性や開発組織への期待値を伝えているだけなのに、それが現場には「とにかく早く」という圧として届いてしまう、というずれもあります。
また、PMとしても毎週の定例で何かしらの進捗を報告し、有意義な動きを示さなければなりません。仕様が固まらないまま実装が始まり、変更のたびに設計とコードが揺れ直します。画面やAPIの見え方だけ先に整え、データ構造や例外処理はあと回しになることも珍しくありません。関係者への確認待ちや差し戻しが積み上がる一方で、QA（品質保証）の検証時間は削られ、リリース日だけは動かせない、という状態が続きます。開発チームの残業は月40〜60時間に積み上がり、新機能の改修に3日かかっていた作業が1週間に伸びる、といった変化が出てきます。スケジュールが逼迫すると、人手を足して間に合わせるという話が上がることもあります。現場は忙しい。それでも遅れは埋まらず、品質への不安だけが増えていく。報告・連絡・相談も遅れていくという悪循環が生まれます。これは個人の能力不足というより、スピードだけを追いかけた結果として起きる構造です。
開発生産性の誤解について、体系的に解説した書籍が出ます！
誤解の解剖
とはいえ、速く出し続けていれば生産性は上がっているのでは、と感じる方もいるはずです。短期の体感としては、その通りです。ところがその前提自体が、品質や設計を伴わなければ足元から崩れていきます。現場でよく見る五つの連鎖があります。
1. 設計の軽視と手戻り
要件定義の段階で直すコストを1とすると、実装後の手戻りは肌感で5〜10倍に膨らむという話は現場でもよく聞きます。大枠だけ決めてダミーデータで画面を先に作るパターンでは、仕様変更のたびにデータベース設計やロジックがやり直しになり、積み上げた実装の多くが使われずに消えていきます。米国標準技術研究所（NIST）の The Economic Impacts of Inadequate Infrastructure for Software Testing（2002）でも、欠陥を設計段階で直すコストを基準1としたとき、実装段階では約5倍、リリース後では最大約30倍に達する、と報告されています。現場の手戻りの重さは、こうした段階差の話でもあります。
2. 品質の省略
品質保証の時間を削ってリリース日を守ると、障害はリリース後に一気に噴き出します。リリース後30分で20件を超える問い合わせが入るといった事態は、削った検証時間の請求書として返ってきます。修正と再リリースに追われ、本来の開発は止まります。Martin FowlerのIs High Quality Software Worth the Cost?では、内部品質について、短期的な速さと長期的な変更コストはトレードオフではなく、低品質のコードが数週間も経たないうちにチームの速度を鈍らせると論じています。テスト時間を削る選択は、障害対応という形でその利息が返ってきます。
3. 技術的負債の蓄積
言わずもがな技術負債にも影響を与えます。多くの開発チームでは急いだ実装はコードを複雑にし、新機能追加に3日かかっていた作業が1週間に伸び、一箇所を直すと別の場所が壊れるという状態に陥りやすくなります。単体テストを疎かにした変更は、影響範囲の予測を難しくします。スピードを優先した結果、かえって手が動かなくなるというジレンマがここで立ち上がります。技術的負債という比喩はWard CunninghamがOOPSLA '92で提示したもので、不完全な設計のまま出荷すると返済義務と利息に相当する手間が積み上がると説明されています（Martin Fowler, Technical Debt）。
4. 無駄な資産の蓄積
速く出すこと自体は、価値が届いたことを意味しません。AIネイティブな開発プロセスの普及で、実装の入口は以前より速くなっています。出力が増えるほど、仮説の検証を待たずに作り込んでしまい、誰も使わない機能や売上に結びつかないコードが積み上がりやすくなります。PR数やリリース回数は伸びても、利用データや顧客の反応が付かないまま、チームが保守し続ける対象だけが増えていきます。会社の帳簿上でもソフトウェア資産は膨らみ、償却の仕組みを通じて税務上の扱いにも影響し得ます。速さだけを追うと届いた価値ではなく、捨てられない在庫が増える構図になります。
5. チームの疲弊
長時間労働は判断力とモチベーションを削り、残業で工数を埋めるほど持続可能なペースから遠ざかります。疲弊が品質を落とし、品質問題が次の残業を呼ぶというループが静かに回り始めます。スピード偏重とセットで現れるのが、人を足せば早くなるという判断です。遅れているプロジェクトに人員を追加するとかえって遅くなるという指摘は、フレデリック・ブルックスの『人月の神話』にあります。オンボーディングと調整コストが非線形に膨らみ、設計や仕様の理解のように並列化しにくい仕事もあります。逼迫時ほど人を足せば何とかなると決めがちですが、手戻りと負荷だけが先に増え、残業と調整負荷をさらに強めます。人月の誤解については、連載第4回で改めて扱います。
この五つは単発では終わりません。設計を省き、テストを削り、負債が増え、無駄な資産が積み上がり、チームが疲れる。そこでまたスピードが求められ、負のスパイラルが回り始めます。
短期的に速く見えても、中長期では開発速度そのものが落ちます。作業が速くなったという体感はすぐに現れますが、顧客価値や売上・利益はあとからしか測れません。コード行数やリリース頻度、ストーリーポイントだけでは、本当に価値が届いたかまでは語れません。スピード偏重は、品質とスピードの二択という問いの立て方自体を歪めます。何を、いつまでに、どの品質で届けるかを先に合意するほうが、のちの手戻りを減らします。
フォースグレンらのThe SPACE of Developer Productivity（ACM Queue, 2021）でも、満足度、パフォーマンス、活動量、コミュニケーション、効率の多次元で捉えるべきだとされ、活動量だけを増やすと長時間労働や悪いシステムへの力技でかえって悪化しうると警告されています。
