開発組織の生産性指標が求められる様々な理由

三宅：株式会社ニーリーでCTOを務めている三宅と申します。現在は、PdMやデザイナーを含めた組織全体とプロダクトの統括を担当しています。

本日は、開発生産性の定量評価を求める理由を整理した上で、私たちがたどり着いたやり方をご紹介します。そして、実際に取り組んだ結果とそこから学んだこと、失敗談からの落とし穴を紹介したあと、今後についてもお話しします。

本日お話しするやり方については、私たちが試行錯誤の末に見つけたものであり、賛否両論あるかと思います。しかし、皆さんが抱える課題感も似ているのではないかと思いますので、このセッションをきっかけに意見交換やディスカッションを通じて、より良いやり方を追求できればうれしいです。

それでは、開発生産性の定量評価を求める理由から説明します。開発組織の生産性の定量指標は、様々な理由で欲しくなるシーンがあると思います。



開発組織のパフォーマンスの良し悪しを確認したり、目標設定をしたりする時だけでなく、人事評価や経営陣に説明するときなど、理由は多岐にわたります。

これらの理由を突き詰めていくと、結局のところは「より事業貢献できる開発組織にしていきたい」というニーズに繋がります。しかし、開発組織の活動や貢献を事業貢献と連動させるのは難しい。そのため、様々な場面で分かりやすい物差しとして、開発組織の生産性の定量指標が欲しくなるのではないかと考えています。

そこから考えると、開発組織の生産性は、コミット数やPull Request数、稼働時間といった指標ではなく、導入社数などのKPI・KGIのようなアウトカム、あるいは業績数値であるインパクトなど、より事業成果に近い指標で計測するのが理想なのではないでしょうか。

とはいえ、開発組織の成果貢献を事業成果で計測・評価するのは難しいですよね。例えば、営業から「このクライアントは重要です。獲得するために〇〇のような機能を開発してほしい」という依頼があって開発したものの、競合に負けてしまって事業成果に繋がらなかったとします。契約ができなかったとなると事業成果はありませんが、開発組織の成果はゼロではありません。

事業成果に繋がるものを開発・リリースできたとしても、効果が分かるまでには数ヶ月かかる場合もあります。そうすると、その期間の評価や振り返りをどうするのかという問題が出てきます。3ヶ月後、半年後に事業成果がでてきたとしても、すでに開発チームが変わってしまっている可能性もあります。

他にも、私たちの事業ではtoBとtoCの両方にサービスを提供しているため、それぞれに異なるアウトカム指標があります。特に初期の頃は開発チームメンバーが少ないため、クォーター内で両方のKPIに貢献するような開発を行うことがあります。そのような場合、一方の指標は達成できたけれど、もう一方は達成できなかったという状況が生まれることがあります。そうなった時に評価を50:50で分けるのは難しく、仮に測れたとしても、比較して評価するのは難しいでしょう。

また、セキュリティ対策や過去の不具合修正のように、重要であるため開発すべきであるものの、事業成果として計測するのが非常に困難なものもあります。これらを考慮すると、事業の構造や状況によって難易度が変わるとはいえ、基本的にはどのようなケースでも開発の貢献を事業成果で計測・評価することは難しいと考えています。



そのため、Four Keysのような有名な開発指標を計測した次のステップとして、「アウトカムやインパクトを使いたいけれど難しい」という状況において、ちょうどいい指標がないかということを探求してきました。

ニーリーが実践する「物量×事業KPI×MBO」の評価戦略

三宅：ここからは、探求の結果として辿り着いた私たちなりのやり方をご紹介します。



前提として、対象は個人ではなく、グロースチーム（ストリームアラインドチーム）を対象にしています。工程については、Discovery、Planning、 Develop、Deliveryという価値提供全体の流れがある中で、本日はDevelopフェーズに絞ってお話しします。

実際にたどり着いたやり方のポイントは3つあります。まず1つ目は「アウトプット（物量）の生産性指標として、開発生産量とリードタイムを使う」こと。2つ目は「アウトカム（付加価値）の生産性指標として、事業KPIを使う」です。最後は、この2つの異なる生産性の指標をバランスよく目標管理・評価するために「MBO（目標管理制度）を使う」ということです。

それぞれ説明していきます。開発生産量はリリースした開発案件の総量だと定義しています。ここで狙いたいのは、いわゆる期待付加価値です。結論として、期待付加価値はリリースした開発案件の総量で近似することにしています。

使用されないものは負債になってしまうため、何でもリリースすれば良いわけではないことは認識しています。ただ、私たちの現在の事業状況では、リリースすれば事業にプラスになるアジェンダがまだ多い状況です。また、作ったものが事業に貢献しているかについては、後ほどお話しする事業KPIで考慮します。セキュリティ対応や過去の不具合・障害対応のように、計測が難しいものも加味したいと考えているため、開発生産量はリリースした開発案件の総量だと定義しています。



実際にどのようにしているのかというと、開発規模で開発生産量を見積もっています。開発案件の規模を「大玉・中玉・小玉」に分けて、その中でさらに細分化し合計9つのマス目に分類して、ポイント制のようなイメージで生産量を見積もっています。タスク単位ではなく、開発案件単位でのストーリーポイントに近いイメージです。

これをPRD作成後（開発着手前）に見積もるようにしています。私たちの開発スタイルでは、エンジニアがPRDを書くのが当たり前の文化になっており、要求要件を整理する際に開発対象のあたりもつけています。そのため、エンジニアが開発対象のあたりをつけて規模を見積もり、それを開発生産量として使用しています。

リリース単位で見積もるようにしており、プロダクトバックログアイテムごとに計測しています。最初はPRDとバックログがほぼ1対1ですが、フロー効率向上を目的として段階的にリリースすることがあるため、段階リリース時はプロダクトバックログを分解し、あくまでリリースの単位で見ています。後でご紹介するリードタイムも同じく、このバックログ単位で見ています。

生産量だけでなくリードタイムもセットで見るようにしています。リードタイムは、設計～リリースまでの期間だと定義して計測しています。生産量だけでなくリードタイムもセットで見ている理由は、フロー効率を意識したいからです。工程ごとのリードタイムは、Findy Team+のようなツールで計測可能であり、私たちも見るようにしていますが、生産性を測る指標としては、設計～リリースまでの大きな単位で見ることにしています。

どうやって計測するのかというと、開発プロセスの中で自動記録しています。開発着手やリリースといったステータス管理をプロダクトバックログで行い、それに連動させて自動的に記録することで計測しています。

生産性向上のための計測で生産性を下げてしまっては意味がないため、特別なことをするのではなく、既存プロセスに組み込み自動で取得するコンセプトで運用しています。

続いて、2つ目の事業KPIについてご紹介します。事業KPIはアウトカムの生産性として採用しており、セールス、カスタマーサクセス、マーケティングといったビジネス組織と同じ目標を使用すると定義しています。

例えば、コンバージョンレートのような開発組織固有の指標ではなく、担当するグロースチームがミッションとして持つ事業戦略に紐づくKPI、つまりビジネス側のKPIと同じものを使って測ります。事業戦略に紐づくKPIが結果的にビジネス側のKPIと同じになるため、ビジネス側のKPIを使って測る、というのが事業KPIです。



3つ目に、それらをセットで見るために使っているMBOについてお話しします。MBOが何なのかというと、使い方によって違いはありますが、皆さんがよく使われるOKRと比較して2つの大きな差があると考えています。1つ目は目標のストレッチ度合い、2つ目は評価に連動させるかどうかです。



MBOを使ったバランスの取り方についてもご紹介します。目標の作り方のポイントは大きく2つあります。1つ目は「どの範囲をターゲットとする目標なのか」というところにあります。冒頭でお話しした通り、チームをメインの対象としているため、チームに関連する目標が約70%のウェイトを占める形で目標を設定します。一方で、個人の努力や成果も考慮したいため、個人の目標も一部入れるようにしています。

2つ目は「何を目的とする目標なのか」です。ここに、事業KPIと開発生産量、リードタイムを組み込んでいます。状況によりますが、大きな開発プロジェクトが始まる半期であれば、量ではなくプロジェクトの成功が事業貢献を示すものとなるため、必ずしも事業KPIと生産量を組み入れるわけではありません。その時の事業状況に応じて変えていきますが、必ず事業の成果を測る直接指標を入れます。しかし、それだけだとウェイトが事業に寄りすぎ、開発組織からすると、アンコントローラブルとなり、納得感が得られないため、プロダクトの活動自体の指標も合わせて入れる工夫をしています。

このように複数の目標とウェイトを調整し、約5～6個の目標を設定します。図の例では、全社の事業KPIとしてARRを10%、チームの事業KPIとして導入社数を20%、チームのプロダクトとしての成果として生産量とリードタイムを40%（クォーターごとの調整で20%ずつ）、個人の目標を30%というイメージです。

チームの部分は共通ですが、最終的にはすべて個人ごとにカスタマイズして設定しています。これは大変な作業ではあるのですが、ニーリーには「人に向き合うことを大事にする」というカルチャーがあるため、開発組織だけでなく全社でこのようなMBOを運用しています。

MBOでの目標管理や評価の具体的な方法は、弊社のCHROが書いたnote「ニーリーの能力開発と人事ポリシー/人事制度を公開します」をご参照ください。

1点だけ重要なこととして、MBOの目標達成度合いを加味するのは賞与に限定しており、グレードや給与には利用していないということはご認識おきください。

実践から得られた2つの「学び」と「落とし穴」

三宅：実際にやってみた結果と得られた学びについてご紹介します。



これは実際に測定した結果です。縦軸に開発生産量またはリードタイムの総量、横軸を月にして、傾向を見るために2ヶ月の移動平均をプロットしています。これだけでは分かりにくいかもしれませんが、私たちとしては傾向を示しているのではないかと感じています。



こちらは、あるチームのデータです。わかりやすくするために、リードタイムではなく割り算したスループットをプロットしています。

まず、生産量が大きく落ちています。これは、メンバーが減ったことにより純粋に生産量が減ったためです。通常はメンバーが減ってもスループットは変わらないはずですが、この例ではシニアメンバーが減ったことでリーダーにレビュー負荷が集中し、そこがボトルネックとなってスループットも一気に落ちてしまいました。

その後、要因が解消され、生産量は回復傾向にあります。ただ、新しく入ったメンバーのオンボーディングはリーダーが行うため、負荷の集中はすぐに解消されず、スループットの回復には時差が出ています。

このように、計測したデータを振り返ると、組織で起きている実態を意外と正確に表していると感じました。

やってみての学びと失敗談、落とし穴もご紹介します。



1つ目は「期待はパフォーマンスを引き出す」です。こちらは先ほどと別のチームのデータであり、体制に変化はありませんでした。そのため、一定量のデリバリーになるかと思いきや、生産量が大きく上昇しました。このタイミングで何が起きたかというと、事業戦略上非常に重要な開発プロジェクトが立ち上がりました。

そこで、このプロジェクトを早く進めることがどれだけ重要なのかをオフラインのキックオフミーティングや定例でしっかりと伝えるなど、丁寧なメッセージングを実施しました。その結果、生産量の向上に繋がったと考えています。期待をしっかりと伝えることは、パフォーマンスに直結すると実感しました。



2つ目は「事業KPIが強い組織をつくる」です。事業KPIを入れる目的は、無闇に作れば良いという話ではなく、生産量の牽制が当初の目的でした。しかし、実際にやってみるとそれだけでなく、ビジネス側と一体となってKPI達成を目指す強い一体感が生まれたと感じています。

具体的な行動変化として印象的だったのは、ある重要なクライアントとの連携機能開発プロジェクトでの出来事です。これは納期ありきのプロジェクトで、開発工数が未定のまま、特定のタイミングまでにリリースしてサービスが使えるようになっている必要がありました。

私は前職でプロジェクトマネジメントをよくやっていたため、納期ありきのプロジェクトは炎上しがちだと知っていました。そのため、こういったケースでは「スケジュールなんてコミットできないし、まずは要件をしっかり決めよう」と話すようにしています。しかし、事業計画的に非常に大きなインパクトを与える重要な案件だったため、このプロジェクトはどうにかして達成する必要がありました。

この時に私から何か働きかけをせずとも、開発チームのメンバー全員が不平不満を言うことなく、納期までに問題なく機能開発できる方法や進め方を考えてくれました。時にはハードワークもありましたが、無事に納期を達成し、計画通りの数字を計上できました。

エンジニアであるため、もちろん開発が中心なのですが、スタートアップとしては事業を伸ばす必要があります。開発チームの目標に事業KPIを据えることで、自分たちの領域を超えて価値提供や事業成果達成に向けて取り組む動きが増加しましたし、このやり方はプロダクト組織を強くすると実感しています。



続いて、落とし穴もご紹介します。1つ目は「手段が目的化しやすい」です。生産量を大玉・小玉のように見積もる話をしましたが、最初は異なるやり方をしていました。開発対象の機能に対して、難易度や変更度合いなどのパラメーターを設定することで、ファンクションポイントのようなイメージでシステマチックに見積もろうとしていたのです。

この背景としては、他チームと比較できる数字にするとともに、ハック対策をしたいという思いがありました。しかし、計測のための作業が増えてしまいました。精度を上げようとして、やることが芋づる式に増えていき、完全に手段が目的化してしまったため、やめました。



2つ目は「細かい指標は部分最適を誘発する」です。設計～リリースまでの大きな単位でリードタイムを見るとお話ししたのですが、様々な待ち時間が発生します。そこで、待ち時間を短くすることを目標に加えようとしたことがあります。しかし、待ち時間を短くしようとした結果、歪さが生まれて手順が不自然に変わり、むしろ遅くなりそうだとわかり、早々にやめました。

指標を目的に置いた瞬間に、頭ではハックせずに全体を早くするためにやっているとわかっていても、部分最適によって歪さが生まれてしまうのです。細かい指標を目標にする、もしくは本来の目的から遠いところにあるものを設定してしまうと、目的からずれてしまうのだと学びました。

大切なのは「生産性の追求」ではなく「事業成長の実現」

三宅：最後にまとめと今後についてお話しします。

実際にやってみて、“ちょうど良い”定量評価を見つけるのは難しいと痛感しました。以前は、計測に手間をかけずハックもせず、手段を目的化せず事業貢献を目指せば、アウトプット的なものを目標に置いても良いと思っていました。

しかし、実際にやってみると、手段が目的化しがちで、本来の目的から離れてしまいました。Kent Beck氏のキーノートを聞いている間も共感するばかりでしたし、私たちは「グッドハートの法則」を甘く見ていたのだと思いました。事業貢献できる開発組織を目指す以上、インパクトやアウトカムからは逃れられないと考えています。

ただ、事業成果で評価することは難しいと言いつつ、ニーズとしては存在しますよね。ではどうすれば良いのかというと、個人的には物量の生産性を計測すること自体はムダではないと考えています。少なくとも、健康診断や振り返りのツールとして有用ですし、何もないよりはあった方が良いと思います。関係者に説明しやすいですし、振り返れば、必ず意味のある気づきや学びが得られるはずです。

また、本日お話しした対応はそこまで手間をかけていないつもりです。使い方が重要だと考えており、多面的に捉えて、副作用に注意して運用するのが良いのではないかと思います。具体的には「単一の指標だけで判断しない」「定量指標を結果だけでデジタルに利用しない」「データに精度を求めるのではなく、粗いデータであることを受け入れ、そこから考察していく」といった使い方が良いのではないでしょうか。

ニーリーでは、開発生産量とリードタイム、事業KPI、そしてMBOを使って進めていこうと考えています。ただし、開発生産量やリードタイムといったアウトプットの生産量については、定量評価だけでなく定性評価とセットで注意して活用する、というやり方でやっていこうと私たちは考えています。

この取り組みを通して、開発生産性の追求は、事業成長への貢献という観点からすると、少し遠いように感じました。生産性の計測や評価は重要ですし、私たちも引き続き行っていきますが、最も重要なのは事業成長貢献のための開発だと考えています。

生産性を追求するのではなく、事業成長を実現するために、現在の開発組織に明確な課題があるかを確認し、もし課題があれば解決するために必要な範囲で生産性などを計測するのが良いと思います。そうすることで、目標設定によって歪さが生まれる問題を回避でき、課題解決に繋がり、成果も得られるのではないでしょうか。

本セッションが、皆さんの開発組織がより事業貢献できる強い組織になるための学びとなれば幸いです。本日はご清聴ありがとうございました！

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です