基礎知識

開発生産性の測り方。4つの指標と、測定の限界

開発の生産性は測りにくく、誤った指標を使うと行動が歪みます。この記事では、何を測り、何を測らないべきかを整理します。

なぜ測るのか

生産性を測る目的を、最初に確認しておきます。

個人の評価に使うためではありません。この目的で導入すると、数字を作る行動が生まれ、実態が見えなくなります。

目的は、改善すべき箇所を見つけることです。どこで時間がかかっているか、何が滞っているか。

もう一つは、投資の判断材料です。改善に時間を使うべきかを、経営に説明するための根拠になります。

測ること自体が目的化しないよう、何のために測るかを先に決める必要があります。

使ってはいけない指標

測りやすいという理由で選ばれがちな、有害な指標を挙げます。

コードの行数。多く書くほど評価されるなら、冗長なコードが増えます。少ない行数で解決するほうが優れています。

コミットの回数。意味のない分割が生まれます。

作業時間。長く働くほど評価されるなら、効率化の動機が失われます。

完了したタスクの数。簡単な作業を選ぶ動機が生まれます。

指標は行動を変えます。測ったものが増えるのではなく、測られたものに合わせて行動が変わる。この性質を常に意識する必要があります。

広く使われている4つの指標

開発組織の状態を測る指標として、次の4つが知られています。

• 変更をリリースする頻度／どれだけ頻繁に本番へ反映できているか
• 変更にかかる時間／コードを書いてから本番に届くまでの期間
• 変更で問題が起きる割合／リリースのうち、不具合を招いた比率
• 復旧までの時間／問題が起きてから回復するまで

前の2つは速さ、後の2つは安定性を表します。

この4つが優れているのは、個人ではなく組織全体の流れを見ている点です。特定の人を評価する指標にはなりません。

また、速さと安定性を同時に見るため、片方を犠牲にした改善が数字に現れます。

あわせて見るもの

4つの指標だけでは見えない部分を補う観点を挙げます。

作ったものが使われたか。速く作っても、使われなければ価値はありません。最終的にはここが問われます。

手戻りの量。要件の認識違いによる作り直しは、上流の問題を示します。

待ち時間。レビュー待ち、承認待ち、環境の準備待ち。実作業ではなく待機が多い場合、改善の余地は組織側にあります。

開発者の実感。働きやすさ、道具の使いやすさ。数値化しにくいが、離職に直結します。

測り始めるには

実務的な導入手順を整理します。

第一に、現状を1つだけ測る。いきなり全部を測ろうとせず、リリースの頻度など取りやすいものから。

第二に、推移を見る。他社との比較より、自組織の変化のほうが有用です。

第三に、原因を掘る。数字が悪い理由を、現場に聞く。数字は問いの出発点であって、答えではありません。

第四に、改善を1つ試す。待ち時間の削減、自動化、レビューの仕組み。

第五に、効果を確認する。ここまでを一巡させて初めて、測る意味が出ます。

測定の限界

最後に、この取り組みの限界について書いておきます。

開発の生産性は、完全には測れません。同じ機能でも難易度が違い、価値も違います。

数字が良くても、事業が伸びるとは限りません。速く作ることと、正しいものを作ることは別です。

したがって、指標は判断の補助に留めるべきです。数字だけで結論を出すと、実態を見誤ります。

それでも測る価値はあります。感覚で議論していた状態から、共通の材料で話せる状態に変わるためです。この変化自体に意味があります。

チームによる違い

指標を比較する際の注意点を整理します。

扱う対象で条件が違います。新規開発と既存の保守では、変更の頻度も難易度も異なります。

規制の有無も影響します。金融や医療では、検証と承認の工程が法令で定められている場合があります。

したがって、チーム間の比較には意味がないことが多くなります。

見るべきは、同じチームの推移です。3か月前と比べてどうか。

順位付けに使うと、数字を作る行動が生まれます。比較ではなく改善のために使う、という位置づけを明確にする必要があります。

どこが詰まっているかを見る

指標から改善につなげる方法を整理します。

工程ごとに時間を分解する。実装、レビュー、テスト、承認、リリース。どこで滞留しているかが見えます。

待ち時間が長い場合、原因は組織側にあります。レビューする人が足りない、承認者が多い、環境の準備に時間がかかる。

テストに時間がかかる場合、自動化の余地があります。

リリースが怖い場合、切り戻しの仕組みが不十分です。安全に戻せるなら、頻度は上げられます。

改善の対象は、多くの場合コードではなく工程だという点が、この測定の示唆です。