こんにちは。プラットフォーム開発部 EMのchikaです。

最近、開発チームの生産性について話題になったので、今回は生産性について調べたこと、考えていることなどを書こうと思います。

生産性の定義

「生産性を上げよう！」とはよく聞かれる話ですが、この生産性とは何を指しているのでしょうか。開発チームの生産性の話の前に、ものすごく抽象的な言葉である生産性とは何かを確認しておきます。

生産性とは、原材料や設備、人などを投入（input）することで生産する製品・サービスなどの生産物（output）の相対的な割合で、以下のような式で表されます。

生産性 ＝ 産出（output）/ 投入（input）

そして、inputとoutputの要素によって生産性にはいくつかの種類があるのですが、大きく物的生産性と付加価値生産性の2つに分類できます。

物的生産性：生産した物量（重さ、個数など）で測る
付加価値生産性：生産によって生み出した金額（粗利）などの価値で測る

物的生産性は、同じ製品を、作れば作っただけ売れることを前提にいかに少ない労働力・資材でたくさん生産できるかに着目した指標ですが、Webサービスなどのプロダクト開発においては同じ商品を繰り返し作ることはあまりないので、基本的には付加価値生産性で測ることになります。

また上記の分類に加えて、inputを人や時間などの労働力とした生産性のことを労働生産性と呼ぶので、私たちのようなITサービス業が上げたい生産性とは、すなわち付加価値労働生産性であるといえます。

開発チームの生産性 ≒ プロダクトの生産性…？

以上の定義を踏まえ、プロダクト開発では粗利のほかに売上、顧客数、ユーザー数、DAUなどを付加価値と捉え、これらを労働効率よく向上させることが生産性（付加価値労働生産性）の向上と言うことができます。

一方で、開発チームで生産性を上げよう！といったときには、いかに少ない人数で多くのタスクをこなせるか、どれだけ短期間で、たくさんデプロイできるかなどの指標がよく挙げられます。

でも、タスクをたくさん消化しようが、何度デプロイしようが、売上やユーザー数などの付加価値が上がるかどうかは別の話です。

開発チームの生産性としてプロダクトの付加価値となる指標の向上を期待されても、達成できるかは運次第と言わざるを得ません。

逆にプロダクトの付加価値への貢献性を感じにくくなってしまい、タスク数やデプロイ数を指標にしてて良いのか？などと考えたりしてなんだかモヤモヤしてきます。

生産性のレベルについて

ここで参考になるのが、Podcast #EM.FMで語られていた、エンジニアの生産性というトピックです。字幕付きのYoutube版もあるので、参考までに以下に貼っておきます。

www.youtube.com

こちらによると、エンジニアの生産性（開発チームの生産性）を語るときには3つのレベルに分けて議論する必要があるということです。

生産性の3つのレベル

各レベルの定義と、私なりの理解で例となる指標を記載してみました。

Lv1：タスク量の生産性

単位時間にどれくらいの作業、どれくらいのクオリティでできているか、どのくらいの待ち時間でできているか
物的労働生産性ともいえる
基本的にエンジニアが整備して見るもの
例）デプロイ頻度・変更リードタイムなどのDevOps指標、ベロシティ、スプリントの消化チケット数・残タスク数（粒度のばらつきが少ない前提）、他

Lv2：価値の量の生産性

単位時間で実現した作業・機能がどれくらいの価値を実現できたか
- 価値：PdMがいくつかの判断軸をもとに予め評価した価値
PdM（PO）を中心に見るもの（あるいはPOを含めたスクラムチームで見る）
例）プロダクトロードマップに基づいた優先順に並べたプロダクトバックログのリリース数、スコア化した価値の実現量、企画～リリースまでのリードタイム

Lv3：成果のレベルの生産性

実現した価値（Lv2における価値）でどれだけの成果を生み出したか
先に述べた付加価値の生産性
営業や経営陣も含めた事業レベルで見るべきもの
例）売上・利益やDAUなど、KPIやNorth Star Metric（NSM）の変化量

各レベル間の関係

各レベル間の関係性については「下位の生産性は上位のレベルの生産性を上げるための土台」であると理解すれば良いかと思います。

Lv3指標であるKPIやNSMを上げるには、「KPIやNSMが向上するかは分からないけど、試したいと思っている施策を速く、たくさん試せるようになる」というLv2の生産性向上が必要ですし、Lv2の生産性を上げるには足回りとなるベロシティやデプロイ頻度、変更リードタイムといったLv1の生産性を上げる必要があります。

モヤモヤの正体

こうして整理した上で振り返ると、先ほどのモヤっとする話はタスク量（Lv1）と成果（Lv3）という遠いレベルのものを生産性という言葉で同列に話してしまっていて、両者の間にあるはずのLv2の生産性指標や、各レベルのスコープが語られていないからということが分かります。

全てがごった煮の状態なので、最終目標である成果（Lv3）だけが強調されて見えるのかもしれません。

どうやって指標設定していけばよいのか

生産性という言葉自体はだいぶ整理できたとして、開発チームの生産性指標としては何をどうやって設定していけば良いのでしょうか。

チームでコントロール可能な範囲を扱う

先の生産性レベルの整理で重要な点は、それぞれのレベルを扱える組織単位・チームが異なるということです。

POを含めたスクラムチームであればLv2の生産性までスコープになると思いますが、エンジニア中心の開発チームであれば、基本的にLv1の生産性までしかコントロールできません。

逆に言えば、開発チームはLv1の生産性を向上させることに集中すればよいと考えています。（それだけでもやることがたくさんあって大変です）。

私達の開発チームはPOと一緒にスクラムチームを形成しているので、本音を言えば「POと合意したプロダクトバックログアイテム（PBI）の消化数」とか、そのリリースまでのリードタイムなどのLv2の生産性指標も含めて追っていきたいのが理想です。

ただ、現状はまだエンジニアもPOもアジャイル開発に慣れているメンバーが多いわけではなくPBIの粒度が大きくなりがちだったり、そもそも開発のバッチサイズが大きいなどといったことから、上記のようなLv2指標を計測できるようになるには少し時間がかかると考えています。

特にエンジニアメンバーからすればLv2指標だけ計測されても自分たちで向上できる範囲に限りがあるので、まずはLv1の生産性指標をちゃんと計測できるようにしたいところです。

計測したいLv1の生産性指標

Lv1の生産性指標としては先ほどデプロイ頻度や変更リードタイムなどのDevOps指標を挙げましたが、これらは Four Keys や LeanとDevOpsの科学などで説明されている、ソフトウェアデリバリのパフォーマンスを測定する4つの指標のうちの2つです。

この2つの指標については LeanとDevOpsの科学によると、「測定が比較的容易で、変動も比較的小さい」指標であるとされています。

変更リードタイム

変更リードタイムは、「変更のcommitから本番環境稼働までの所要時間」と定義されていますが、これは（企画〜要件定義はもちろん）設計工程を含んでおらず、その理由については「所要時間の計測をいつ始めるべきかが明確ではない上に、変動が非常に大きい」と説明されています。

これは開発案件の規模や実装着手前の（エンジニア以外のステークホルダが介在する）工程による変動が大きいということだと思いますが、別の言い方をすれば開発チームでコントロール出来ない要素が入ってきてしまうということです。

逆にそれ以降、実装・テスト・ビルド・デプロイについては計測が容易で変動が少ないので開発チームでコントロール可能ということができます。

デプロイ頻度

デプロイ頻度も、本番環境へのデプロイタイミングがコントロール可能でさえあれば変動が少なく計測可能な指標です。

広木大地さんが仰っていた d/d/dも、計算要素の中心はデプロイ頻度によるため、ソフトウェアデリバリのパフォーマンス計測の重要な要素であることが伺えます。

最近、エンジニアリング組織の健全さの指標に、
d/d/d というのを用いてる。

deploys / a day / a developer の略で
1日あたりのデプロイ回数を開発者数で割ったもの。

だいたい、0.1 以上なら健全と言える

これが悪化しているとき、最上流含めたエンジニアリングパイプラインのどこかに問題がある
— 広木大地/ エンジニアリング組織論への招待 (@hiroki_daichi) 2019年2月26日