開発生産性の数値を目標にしない｜『誤解だらけの開発生産性』の書評

開発の生産性を上げたい。そう思って手に取ったのが『誤解だらけの開発生産性』でした。

読んでいちばん残ったのは、開発生産性の数値を目標にすると、よくないことが起きるという話です。それ以来、なるべく数値を目標にしないようにしています。

結論から言うと、チームの目標を決めたり、メンバーを評価したりする立場の人に読んでほしい1冊です。一方で、具体的な解決策を求めて読むと、物足りなさが残るかもしれません。

誤解だらけの開発生産性はどんな本か

書誌情報と目次は、紀伊國屋書店のページに載っている出版社内容情報によるものです。出版社の紹介によると、架空の開発現場を舞台にしたストーリーパートと、解説パートが交互に進む作りです。エンジニア、上司、デザイナー、開発マネージャー、PM、QA、サポートと、立場ごとに「開発生産性」という言葉の受け止め方が違うことを描いています。

章は7つで、すべての章題に「重圧」が出てきます。

目次を見る限り、第3章と第4章が「測る」「指標」を正面から扱う章です。第7章で、生産性を上げるだけのエンジニアから抜け出す話に進みます。

読んだきっかけ｜生産性を上げたかった

刺さったところ｜数値を目標にするとよくない

上げ方を探して読んだのに、いちばん刺さったのは「開発生産性の数値を目標にするとよくない」という話でした。

数値を測ること自体が悪いわけではありません。問題は、その数値が目標になったときです。数値を上げること自体が目的になると、本来上げたかったもの（価値を届ける速さや質）とずれていきます。

これは開発生産性に限った話ではなく、一般に「グッドハートの法則」と呼ばれる現象です。開発の指標を研究しているDORAも、指標の解説ページで指標を目標にするとチームが数値を操作しようとしやすくなる、と注意しています。「年末までに毎日複数回デプロイする」のような一律の数値目標は避けるべき、という書き方です。

数値が目標になると、何が起きるか

説明用の例です。「1人あたりのプルリクエスト数」を目標にしたとします。

PRを小さく分けること自体は、レビューしやすくなるので悪いことではありません。ただ、「数を増やすため」に分け始めると、数値と実態がずれていきます。

読んでから変えたこと｜なるべく数値を目標にしない

読んでから変えたのは、なるべく数値を目標に持たないことです。

DORAの解説ページでは、ほかにも、1つの指標だけで判断しない、性質の違うチーム同士を比べない、チーム間の競争に使わない、といった注意点が挙げられています。数値を目標にしないなら、数値は「チームが自分たちの変化を知るための道具」として使う、ということです。

開発生産性の指標と、目標にしたときのゆがみ

「数値を目標にしない」と言っても、どんな数値があるのかを知らないと話が進みません。開発生産性の指標としてよく使われるのが、DORAの5つの指標です（この本の内容ではなく、DORAの公式の解説によるものです）。

指標の名前と意味はDORAの指標の解説ページによるものです。右の列は、目標にしたときに起こりがちなことを、説明用に私が考えた例です。

DORAは、速さと安定の指標を組み合わせて見るように勧めています。どちらか1つだけを追うと、速さのために品質を落としたり、安定のために出すのを怖がったりするからです。研究では、速さと安定はトレードオフではなく、うまくいっているチームは両方とも良い、とも説明されています。

1つの数値を目標にするとゆがむ。だから複数の数値を、目標ではなく状態を知るために並べて見る。この本で刺さった話と、DORAの注意点は同じ方向を向いています。

物足りなかったところ｜解決策は少なめ

物足りなかったのは、解決策があまり書かれていなかったことです。生産性を上げたくて読んだ身としては、「では、どうすればいいのか」の部分をもっと知りたかったです。

出版社の紹介では、手法やチェックシート、章ごとのまとめが用意されているとあります。ただ、タイトルや出版社の紹介を見ても、重心は「何が誤解なのか」「立場によって開発生産性の意味がどう違うのか」を知るほうにある本です。すぐ使える改善の手順を求める人は、そのつもりで読むと期待とのずれが少ないと思います。

今のレベル別の読み方

ストーリー形式の本ですが、立場によって先に読む章を決めると、得るものがはっきりします。

向いている人・向いていない人

• 向いている人：チームの目標を決めたり、メンバーを評価したりする立場の人。開発生産性の数値を目標に置こうとしている人
• 向いていない人：開発生産性を上げる具体的な手順を、すぐに知りたい人

出版社は「上司から開発生産性を求められて、困っているエンジニア」を対象読者に挙げています。私は逆に、求める側の人にこそ読んでほしいと感じました。

あわせて読みたい

• システム開発と「具体と抽象」の書評：数値（具体）と目的（抽象）を行き来する考え方
• アジャイルのスプリントとは：チームで改善を回す進め方

読んだ本はほかにも、トムの本棚に並べています。

よくある質問

Q. ストーリー形式とは、どんな作りですか？

出版社の紹介によると、現場の場面を描くストーリーパートと、その場面を説明する解説パートが用意されています。章ごとに学んだことを確かめる「まとめ」もあります。

Q. エンジニアでなくても読めますか？

読めます。登場するのはエンジニアだけでなく、上司、デザイナー、PM、QA、サポートなどです。開発チームと一緒に働く立場の人にも向いています。

Q. 電子版はありますか？

あります。紀伊國屋書店のページでも、電子版ありと案内されています。