Mirai Translate TECH BLOG

株式会社みらい翻訳のテックブログ

開発チームにおける生産性とは

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

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

生産性の定義

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

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

生産性 = 産出(output)/ 投入(input)

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

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

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

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

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

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

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

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

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

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

生産性のレベルについて

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


www.youtube.com


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 KeysLeanとDevOpsの科学 などで説明されている、ソフトウェアデリバリのパフォーマンスを測定する4つの指標のうちの2つです。

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

変更リードタイム

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

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

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

デプロイ頻度

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

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

広木 大地/ エンジニアリング組織論への招待 on Twitter: "最近、エンジニアリング組織の健全さの指標に、 d/d/d というのを用いてる。 deploys / a day / a developer の略で 1日あたりのデプロイ回数を開発者数で割ったもの。 だいたい、0.1 以上なら健全と言える これが悪化しているとき、最上流含めたエンジニアリングパイプラインのどこかに問題がある" / Twitter

以上のことから、デプロイ頻度と変更リードタイムは、開発チームでコントロール可能な指標として最も効果的だと考えられます。

私達もまだ計測できていないので、いずれこれらを参考にチームパフォーマンスを測れる状態にしたいと考えています。

まだ生産性とか言えるレベルじゃないんですが…

とは言ったものの、今すぐ計測しよう!とできないチーム事情を抱えたところは私達以外のもあるのではないでしょうか。

例えば、スクラムチームにおいてスクラムの経験があるメンバーが少なかったり、CI/CDなど技術的な環境整備をしないとデプロイ頻度やリードタイムの改善が明らかに難しい*1といった状況です。

そのような状態で無理に生産性指標を計測しようとしても、おそらく意味のある数値は取れないと思います。

この場合、初めから無理に増減を見れる指標を計測しようとせず、例えば最初は

  • KPTの)Keepを○個以上出す
  • 改善項目を最低1つ決める
  • レビューで必ず成果物を出す
    • ゆくゆくはデプロイ実施まで持っていく

こういった小さな目標を設定して達成率を見ていったりして、しばらくして安定してスプリントを回せるようになったら

  • 繰越タスク量を小さくする
    • スプリントの見積り精度を高める
    • タスク量はタスク数や見積時間
  • タスクの平均の見積時間・実績時間を小さくする
    • 慣れないとタスクサイズが大きいことが多い
    • 実績時間の計測はそこそこハードルがある印象
  • ふりかえりで決めた改善項目を実行できた累計数を記録する
    • 改善の積み重ねを可視化できると成長を実感できる
  • スキルマップ・機能マップを作り2人以上できる項目を増やす
    • 1人しか出来ないことを減らしていく(属人化を避ける)

こんな形でなんらか計測できる指標で見ていくことで、少しずつチームが成長してパフォーマンスを上げられればよいのかなと考えています。

もちろん、もともと計測したかったデプロイ頻度やリードタイムを計測するにはこれだけでなく技術的な環境整備も必須になるので、そちらには別途(そのチームなのか、別の専門チームなのかは組織によって異なると思いますが)アプローチしていく必要があります。

ここで述べた指標設定の課題は私達自身が直面していることなので、ここに挙げた項目がチームにとって適切かどうかの答えや実績はまだないのですが、この状況をくぐり抜けた方が偶然この記事を見かけて何か思うことがあればご意見いただきたいところですし、似たような状況の方にも何かの参考になればと思います。

チームに合った指標を考える参考資料

以下資料では、開発チームの生産性指標をどのように設定して事業貢献度を測るかについて、チームの成熟度(タックマンモデルのステージ)によって異なる設定をするというモデル事例を紹介されていて、まさにこの記事のテーマに沿った内容として参考になったので紹介しておきます。

www.slideshare.net

まとめ

今回は、ここ最近で話題になりつつもうまく言語化出来ていなかった生産性について書いてみました。

  • 開発チームの(エンジニアの)生産性は、レベルを分けて整理して考える必要がある
  • 開発チームでコントロールできる範囲の生産性指標を立てる
  • 計測可能な生産性指標を最初から立てるのが難しければ、小さな目標を立ててチームを成長させていく

DevOps指標の話は実際の取組みやツールでの可視化など具体的なものをちらほら見かけますが、それよりも広い範囲を指すと思われる生産性については、#EM.FM のトピックが出てくるまではあまり具体的な情報を目にしなかったように思います。

他社での取り組み、特に私達のような「これからやっていこう」というチームの取り組みなど、もっと知りたくなりました。

We're hiring!

みらい翻訳では、私たちと一緒に開発チームの生産性を向上していっていただけるエンジニアを募集しています! ご興味のある方は、ぜひ下記リンクよりご応募・お問い合わせをお待ちしております。

miraitranslate.com

*1:デプロイとリリースの分離が実現できていない、リリース作業に手作業が必要になっていて重いなど