SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

誤解だらけの開発生産性 〜DMM.comで見てきた誤解〜

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

石垣 雅人(合同会社DMM.com)[著]

開発生産性が上がる恩恵はレイヤーごとに異なる

 開発生産性という言葉は便利な言葉が故に組織内で異なる意味で使われることがたびたびあります。そのため「開発生産性が上がった」というときに受ける恩恵も変わってきます。

 まず開発チームが見ているのはスループットです。これは1人月あたりにどれだけ生産量を出せるかという内部の速さと安定性です。DORA(DevOps Research and Assessment)のFour Keysは、このレイヤーの状態を対で捉える指標です(DORA metrics guide)。

開発生産性の意味はレイヤーごとに価値が変わる
開発生産性の意味はレイヤーごとに価値が変わる

 しかし、一段上のマネージャーやプロジェクトマネージャー(PM)が見ているのは、人月と工期です。計画した機能がきちんとスケジュールどおりにユーザーに届いたか。投資工数が予想どおりだったか、見積もりと実績がどれだけずれたかというものです。さらに上のレイヤーの事業側では、人月は金額に読み替わります。同じ単価でも、届く施策の回数と質が変わり、届かなければ追加の投資が必要となります。経営と経理が見ているのは、損益計算書の販管費と、貸借対照表のソフトウェア資産や減価償却です。現場がスループットを上げたと言うとき、経営が聞いているのは販管費と資産に効いたのかという問いです。

 開発生産性を上げたい意味や恩恵も、レイヤーによって異なります。エンジニアが見ているのはテストやレビューの速さ、手を動かせる時間、負債を減らせるかどうかという観点です。PMや開発マネージャーが見ているのは、プロセスのリードタイムと、予測どおりに仮説を回せるか、人員の見通しが立つかどうかという観点です。事業側や経営側が見ているのは早く安く、届く範囲が足りているかどうかという観点です。内製にこだわらず外に出す判断も、このレイヤーには入ります。

 事業側にとっての速さは、プルリクエストが何時間でマージされたかではありません。仮説が一定の確率で価値になるなら、四半期に何回その仮説を出せるか、1施策のリードタイムがどれだけ縮むかが価値になります。回転が落ちると、取りにいけた利益を取り逃がします。開発のスループットをいきなり損益に飛ばさず、工数、金額、財務の順に、一段ずつ入力と出力として渡します。

 ある改修でリードタイムが3日から2日になっても、事業側の問いは別です。その1日で、欲しい時期に欲しい範囲は届いたのか。同じ人数で、施策の回数は増えたのか。届いた変更は、使われない資産として償却の負担だけを増やしていないか。件数の改善は、この三つのどれかに翻訳されて初めて、上のレイヤーの評価の材料になります。

 各レイヤーの入力と出力は、次のように一段ずつつながります(石垣雅人「『開発生産性』はエンジニア"だけ"のモノではなくなった?」、CodeZine)。

各レイヤーの入力と出力
レイヤー 入力(input) 処理(model) 出力(output)
開発組織 人 ソフトウェア開発 1人月あたりの生産性(スループット)
PM、EM 1人月あたりの生産性(スループット) 価値提供速度の未来予測 工数・スケジュール(工数の手戻りコスト削減など)
BM、PdM 工数・スケジュール 工数×単価を人的予算の基本として、戦略・戦術の遂行計画 P/L(一般管理費)
経理 開発したプロダクト ソフトウェア資産計上か費用かの振り分け 税負担・減価償却費(P/L)

 レイヤーをまたぐこの価値の変換は、開発の改善が事業の言葉に届く経路として整理できます(石垣雅人「『開発生産性を上げる改善』って儲かるの?」、開発生産性カンファレンス2024)。経路を共有しないまま現場の件数だけを開発生産性が上がったという評価で置くと、上のレイヤーの問いへ渡す材料が、その外側に残ります。計画を信じて立てられるかも、資産に効いたかも、実装者の完了件数には最初から載っていません。

 だからFour Keysが改善しても、事業側に良くなった実感が生まれないとき、圧力はもう一度エンジニアの速度に戻ります。この戻りは、測るレイヤー選びの間違いに見えがちです。開発の指標は良くなったのに、事業側の実感が動かない。見ている数字のレイヤーがずれていた、と読めてしまうからです。ただ、指標を上の言葉に差し替えても、責任の主語が実装者のままなら圧力は止まりません。実際に起きているのは、責任の置き場所を一番下に固定したまま、上の問いを下の単位で埋めようとすることです。

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

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

Amazon  SEshop  その他

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

著:石垣 雅人
発売日:2026年07月21日(火)
定価:3,168円(本体2,880円+税10%)

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

次のページ
誰が遅いかをやめて、どのレイヤーの約束がずれたかを見る

この記事は参考になりましたか?

誤解だらけの開発生産性 〜DMM.comで見てきた誤解〜連載記事一覧

もっと読む

この記事の著者

石垣 雅人(合同会社DMM.com)(イシガキ マサト)

 DMM .comにエンジニア職で新卒入社し、翌年からプロジェクトマネージャーを務める。 いくつかのプロダクトマネージャーを経て2020年、DMM.comの入り口である総合トップなどを管轄する総合トップ開発部の立ち上げを行い、部長を従事。 現在はプラットフォーム事業本部 第1開発部 部長 / VPo...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー