その大きな芋は私のものです。ありがとう。

Published on

開発生産性についてのお勉強

Authors

開発生産性についての勉強をしようと思った理由

最近、新しいチームに異動となった。そのチームでの私の役目のうちの一つに『チームの開発生産性を上げる』というものがあり、 『開発生産性』を上げるためには『開発生産性』そのものについて知らねばならぬ、と思ったので勉強することにした。

o3 とかに聞いていい感じにまとめようかとも思ったけど、以前の記事 でも書いたように AI はあくまで補助的に利用しようという心持ちで（今は）いるので、今まで通り素直に本を読んで勉強することにした。

読んだ本

開発生産性とは？

開発生産性とは、一般的によく言われる労働生産性の考え方とは少し異なる。
労働生産性は「付加価値額 ÷ 従業員数」という式で表されるが、これだとエンジニア組織としての生産性は適切に測れない。

ソフトウェア企業の労働生産性は「投資フェーズ」では低くて、「回収フェーズ」では高くなるという逆転現象が起こるという特性があり、
この特性があるために、労働生産性の考え方をそのまま開発生産性に当てはめることはできない。

開発生産性におけるインプットとアウトプット

開発生産性を考えるとき、インプットとアウトプットには様々な要素が含まれる。

インプットとしては

  • 開発に費やされた時間
  • 開発に投入された人的リソース
  • 開発に使用された予算
  • 開発に必要なインフラやツールのコスト
  • 開発チームの教育育成に投資された時間と予算

アウトプットとしては

  • リリースされた機能や修正の数
  • 開発されたコードの行数
  • 解決されたバグやイシューの数
  • 提供された価値（ユーザー満足度、売り上げへの貢献など）
  • 開発されたドキュメントの量と質

こんな感じで、一言にインプットとアウトプットといっても様々な種類が存在する。
組織や開発チームの特性やプロジェクトの性質によっても、何をインプットとして、何をアウトプットとするかの定義が異なる場合がある。

インプットとアウトプットの定義を明確にできると、自分たちのチームにおいて何を開発生産性と呼ぶのかを明確にできる。

開発生産性のレベル

開発生産性は、以下の 3 つのレベルで考えることができる。

  1. レベル 1: 仕事量の生産性

    • 特定の作業量をどれだけ効率的にこなせたか
    • 純粋に作業量の観点から生産性を評価する

  2. レベル 2: 期待付加価値の生産性

    • 仕事量に加えて、各施策がプロダクト自体にどれだけの価値をもたらすかを考慮
    • ただし、実際の価値を評価するのは時間がかかるので、「期待される価値がどの程度リリースできたか」に焦点を当てる

  3. レベル 3: 実現付加価値の生産性

    • 売上や KPI など、実際のサービスに対する具体的な貢献を評価
    • 開発チームだけでなくカスタマーサクセスやセールス、マーケティングなど、組織全体で評価に取り組んでいく必要がある

レベル 1 は開発チームだけでコントロールできるので取り組みやすく、成果につながりやすい特徴がある。一方、レベル 3 はチームを横断するので実現が困難になる。

開発生産性を測るための指標

開発生産性を測定するための主要な指標として、以下のようなものがある。

Four Keys（DORA メトリクス）

Four Keys は、以下の 4 つの指標を計測する。

  1. デプロイ頻度

    • 開発したプログラムが本番環境にリリースされる頻度
    • 開発チームの効率性と、変更を迅速に提供する能力を測定
    • ただし、デプロイ頻度だけを見るのではなく、一回のデプロイでの変更量、デプロイ成功率なども併せて評価する必要がある

  2. 変更のリードタイム

    • 開発したプログラムが本番環境にリリースされるまでの時間
    • 開発チームのアジリティを測定
    • 正確な測定のために、測定の開始点と終了点を明確にし、一貫した方法で測定を行うことが重要

  3. 変更失敗率

    • 本番環境へのリリース後に、障害などが発生する割合
    • 開発チームのリリースプロセスの質を測定
    • 失敗の定義を明確にしておく必要がある。例えば、切り戻しが必要な障害なのか、運用で回避できる障害なのか、パフォーマンスのダウンも含むのかなど。平均修復時間との調整も視野に入れる必要がある

  4. 平均修復時間

    • システム障害が発生してから、サービスが復旧するまでの平均時間
    • 開発チームの問題解決能力とシステムの回復力を測定
    • 変更失敗率と同様に、障害の定義と測定の開始点・終了点の定義を明確にする必要がある。また、「復旧」をいつの時点でみなすのかも重要。切り戻し等により障害が一時的に収まったタイミングか、完全に元の状態に戻った時点かという判断が必要

その他の重要な指標

Four Keys では全ての指標は測定しきれないため、下記のメトリクスも補助的に使うと良い。

プルリクエストの作成数

純粋に、プルリクエストを特定期間内にいくつ出すことができたか。
ただし、プルリクエストの作成数を指標とする場合、別チームや他人同士での比較を行うのではなく、チームや個人の過去との比較を行うことが重要。

自動テストのコードカバレッジ

コードカバレッジ測定ツールやライブラリを用いて、自動テストがどの程度ソースコードを網羅しているかを測定する。

コードカバレッジには以下の 4 段階がある。

  • C0: ステートメントカバレッジ - 各ステートメントが少なくとも一度は実行されたか
  • C1: ブランチカバレッジ - 各分岐が少なくとも一度は実行されたか
  • C2: パスカバレッジ - 各実行パスが少なくとも一度は実行されたか
  • MCC: Modified Condition / Decision Coverage - 各条件の全ての組み合わせが少なくとも一度は実行されたか

ただし、単純にカバレッジ 100%を目指すのではなく、「バグを事前に検知して、守れるテストになっているか」を重視することが重要。

マージ時間

プルリクエストがオープンされてからマージされるまでの時間を測定する。
マージ時間が短いほど、プルリクエストの総数が減って認知負荷が低くなり、マージ時のコンフリクトの発生確率も低くなる。

バリューストリーム指標

開発プロセス全体を通して、顧客に提供する価値の流れを評価するための指標。開発プロセス全体の効率性と有効性を測定して、改善点を特定するために役立つ。
これを測定するためには、バリューストリームマップ（VSM）を作成し、バリューストリームにおける各プロセスのリードタイム、プロセス時間、手戻り率を記録する。
また、サイクルタイム（アイデアの着想、要望の提出から実際に顧客に価値が届くまでの時間）も重要な指標となる。

SPACE フレームワーク

Nicole Forsgren 博士らが提唱した、開発者体験を評価するための指標。
「Satisfaction and well-being（満足度と幸福度）」「Performance（パフォーマンス）」「Activity（活動）」「Communication and collaboration（コミュニケーションとコラボレーション）」「Efficiency and flow（効率とフロー）」の頭文字をとったもの。

各要素の詳細は以下の通り。

  • Satisfaction and well-being
    • 開発者のモチベーションとパフォーマンスに直結する、満足度と幸福度を測定
    • 定量的な数値だけでなく心理的安全性の向上や業務量の調整、柔軟な働き方の提供などの定性的な部分も重視する必要がある
  • Performance
    • 前述の Four Keys と密接にかかわる
  • Activity
    • 開発者個人の日々の活動を可視化して、チームの働き方や課題を把握できる
  • Communication and collaboration
    • チームの一体感とパフォーマンスを高める指標
    • 情報共有を気軽にしあえるような環境や状況を作りながら、相互にコミュニケーションを自発的に行える状態を目指す
  • Efficiency and flow
    • 開発者がスムーズに作業を進められる環境かどうかを評価
    • この指標を改善するには、自動化の促進、ワークフローの最適化、集中阻害要因の排除などが重要
Discuss on Twitter • View on GitHub