評価の誤解　〜エンジニアだけが生産性を求められる構造〜

連載第4回では、人を足してもAIを足しても、納期の天井を決めているのは判断と合意の側だと書きました。その判断を担った人に、次に返ってくるのが評価です。変更のリードタイムは短くなり、障害も減っています。それでも会議の場では、開発は早くなっているがいまいち実感として全体が速くなっていないという問題が出てきます。これは評価する人の視野が開発フェーズだけに寄っていたり、開発生産性の意味が役割や役職によって変わっていたりすることが原因です。最終回となる第5回では、開発生産性がエンジニアだけの責任になる構造を解体します。

　前回の連載はこちらから。

聞かれるのは、誰の作業が遅かったのか

　チームはプルリクエスト（PR）のリードタイムを縮め、リリース後の障害も減らしています。レビューの待ち時間も、前の四半期より短くなっています。それでも、企画が立ってからユーザーに届くまでのリードタイムで見ると、遅いのは実装の前であることが多い。企画の合意が揺れ、要件定義が固まるまでに数週間分の時間が溶け、開発に渡った時点で四半期の残り時間はすでに短い。開発フェーズだけをどれだけ頑張っても、全体としてユーザーに届く時期はほとんど動きません。

　報告の場で開発側の数字を出すと、返ってくる問いは別の場所にあります。生産性は何パーセント上がったのか。隣のチームのリリース回数と比べてどうなのか。説明を求められるのは、開発リーダー個人です。企画や要件定義で止まっていた時間は、その問いの主語には入りません。

　品質に使った時間は、その表には出てきません。技術的負債の返済にスプリントの一部を割くと、機能のリリース数は一時的に減ります。レビューで差し戻し、曖昧な仕様を事業側に戻す作業に追われた週も、完了件数が伸びません。評価のシートが完了件数と工期だけだと、その週は生産性が落ちた週として記録に残ります。確認を厚くしてバグを止めた人より、確認を薄くして件数を稼いだ人のほうが開発生産性は高く見えます。

　遅れの会話も同じところに着地します。なぜ遅れたのか、次に何を変えるのかではなく、誰の作業が遅かったのかが先に聞かれます。計画を動かし、優先順位を途中で変えた側は、その問いの主語には入りません。実装した人が、未達の原因として記録に残ります。

　会議のあと、リーダーは個人の完了件数を週次で集計し始めます。件数が落ちた週は、返済を止めて小さな変更を積みます。レビューのコメントは短くなり、曖昧な仕様も実装側で吸収するようになります。数字は戻ります。戻ったあとに増えるのは差し戻しと、リリース後の問い合わせです。評価を守る行動が、前の四半期で減らした障害を別の形で戻します。

　事業側が知りたいのは、次の企画をこの時期に置いてよいかです。完了件数の増減からは、その問いに答えられません。答えられないぶん、問いは開発リーダーの速度に戻ります。

　内部の数字は良くなっているのに、評価だけが苦しいままです。足りないのは説明の上手さだけではありません。測っているレイヤーと、責任を置いている人がずれています。開発が速くなった恩恵も、レイヤーによって異なります。実装の待ち時間が減ったことは開発チームには見えますが、企画の時期が動いていない事業側には、同じ改善として届きません。

　開発生産性の誤解について、体系的に解説した書籍が発売中です！

 

Amazon　 SEshop　 その他

 

誤解だらけの開発生産性 ストーリーでわかる重圧とペインの乗り越え方

 

著：石垣 雅人
発売日：2026年07月21日（火）
定価：3,168円（本体2,880円＋税10%）

本書はストーリー形式でエンジニア、上司、デザイナー、開発マネージャー、PM、QA、サポートなどがかかえる開発生産性に紐づくペインと解消方法を解説した書籍です。立場によって異なる開発生産性の意味を紹介しそれにまつわるペインを解消できる工夫を盛りこんでいます。開発生産性に悩む開発リーダー必携の1冊です。