はじめに
あるプロダクトの開発チームの生産性を計測したいと思いました。
昔は、開発したソースコードの行数で生産性を計測していたと思います。ただ、ソースコードの行数では、正しく生産性は計測できないと言われています（例えばこちらの記事など）。
では生産性は、どうやって算出するのが良いのか、具体的な方法(そのまま真似できる方法)を探したのですが、見つからなくて困っていました。
ということで、生産性を計測する方法を考案して計測してみた結果、そこそこ良い効果があったので、その方法を紹介します。
成果とは何か
[生産性] ＝ [成果] / [かかった工数]
で算出する前提とします。ということで、まず成果とは何かを考えます。
たくさんソースコードを書いても、たくさん関数を作っても、たくさんデプロイしても、それが顧客の価値につながらなければ意味がないように思います。
だからファンクションポイント法や d/d/d(Deploys per Day per Developers) での計測は、生産性のための成果を測るにはちょっと不向きな気がします。
(ちなみにベロシティは、こちらの記事などで生産性の計測に使わない方がいいと言われています)
ということで、成果というのは、直接作ったモノ(プログラム)ではなくて、それを作った結果、__「顧客に対してどれだけ価値があったか」__という方向性で考えるのが良いと思います。
「顧客に対してどれだけ価値があったか」について、ここからは具体的な例を挙げて考えます。
分かりやすい例として、__自社で開発しているプロダクトに機能追加や改善を行う開発チーム__を例とします(私のチームが、まさにそういう開発チームです)。
自社プロダクトの開発チームにとって、「顧客に価値のあること」は、「売上に貢献すること」だと仮定します。
しかし、売上の値をそのまま計測しても、あまり良い感じに開発チームの生産性は計測できないと思います。売上は、営業チームやサポートチームの頑張りなど、様々な要因によって大きく変動することが多いからです。
ということで、「売上に貢献すること」を、もう少しブレイクダウンしてみます。
開発チームが行った機能追加が、売上にどういう影響があるのかを考えてみます。
仮にこのプロダクトの売上が、「新規契約」と「既存ユーザーの契約延長」によって決まると仮定します。
その場合、特定のユーザーにとって非常に価値の高い機能追加をしたことによって、「新規契約」または「契約延長」してくれるユーザーが現れたら、それは売上に貢献したことになると思います。
つまり、開発チームは、__「ユーザーにとって価値のある機能追加を行うこと」__が、売上に貢献すると言えると思います。
まとめると以下になります。
[自社プロダクトの開発チームの成果]
＝ [売上に貢献すること]
＝ [ユーザーにとって価値のある機能追加を行うこと]
ユーザーにとっての価値を評価する方法
プロダクトがWebサービスであれば、一部のユーザーに対して、追加した機能を公開して、それによってユーザーの行動がどう変わるのかを計測すれば、ユーザーにどれだけの価値がある機能なのか評価できそうに思います。
ここでは、そういうことができない前提の例を考えます。
(私の開発チームでは、そういうことができないので)
機能ごとにユーザーの行動がどれだけ変わるかが計測できないとなると、もはや定量的に評価するのが難しいので、割り切って定性的な評価方法にします。
具体的には、機能ごとに「ユーザーにとっての価値」を定性評価した値を「機能価値ポイント」として設定します。
定性評価を1人だけで行うとデータの偏りが強くなるので、開発チーム・営業・サポートの3者の平均値で算出します。
前提として、営業・サポートは、ユーザーの声を日々聞いているため、ユーザーにとっての価値が肌感覚で分かる前提とします。開発チームも、ユーザーの要望を随時聞いており、ユーザーにとっての価値がだいたい分かる前提とします。
下図のような感じに、機能A～Cに対して、開発・営業・サポートがそれぞれフィボナッチ数で値を決めて、その平均値をその機能の「機能価値ポイント」とします。
まとめると以下になります。
[自社プロダクトの開発チームの成果]
＝ [売上に貢献すること]
＝ [ユーザーにとって価値のある機能追加を行うこと]
＝ [リリースした機能の機能価値ポイントの合計]
機能価値ポイントによる生産性の計測結果
私の開発チームで、実際に1年前と現在で、機能価値ポイントで生産性を計測してみました。
ここでは、開発工数1人月(160H)当たりで、どれだけの機能価値ポイントがリリースできたかを計測しています。
(開発工数とは、仕様書の作成～テスト実施まで全ての工程の合算値です)
私のチームでは、この1年間で生産性を向上させるための様々な施策(以下の記事参照)を行ったので、1年前と比較して生産性は倍増という結果になりました。
1年以上かけて生産性倍増＋成長し続けるチームになった施策を全部公開
参考情報として、[コード行数] / [開発工数] で計測した生産性も、1年前と比較して同じように2倍くらいになりました。
感覚的にも、1年前と比較すると生産性はかなり上がったと思うので、機能価値ポイントによる計測結果は、当たらずとも遠からずな値になっていると思います。
生産性を計測した効果
機能価値ポイントでの生産性を高めるためには、「少ない開発工数で価値の高い機能を優先して開発すること」や「開発工数を少なくするための仕様の調整」が重要になります。
従って、この生産性を高めようと意識することで、開発チームは「決められた仕様通りに作る」だけでなくて、「如何に少ない工数で大きな成果を出すか」を考えて、仕事に取り組む姿勢が強くなると思います(開発する機能を選ぶこともプロダクトオーナーだけに任せるのでなく、開発チームが積極的に関与した方が良いと思います)。
実際に、そういうことを考えて仕事に取り組んだ結果、__「生産性が上がった」という結果を得ると達成感__も得られます。
まとめ
本稿で紹介した機能価値ポイントによる生産性の計測は、定性評価なので、正しい値ではないかもしれません。
でも、正しい値かどうかはそこまで重要ではなくて、__「如何に少ない工数で大きな成果を出すか」を考えて頑張った結果、それが「生産性」という指標に現れて、達成感を得られることに価値がある__と思います。
開発・営業・サポートの代表者3人で10機能の機能価値ポイントを決めるのに1時間もかからないので、その1時間で達成感が得られる指標を計測できるならば、こういう生産性の計測方法も有りじゃないかと思います。
こういうユニークな様々な施策を 8/27 に Developers Summit 2020 KANSAI にて発表予定です。
事前登録で無料視聴できますので、よろしければご視聴ください。
Twitterでも開発に役立つ情報を発信しています → @kojimadev