12
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

自分たちだけの「開発生産性方程式」の作り方

Posted at

はじめに

株式会社うるるの技術戦略部の古賀と申します!
昨年に引き続き開発生産性について、アドカレを書くことにしました!

(け、決して書く時間もネタもなくて業務でやってることをそのまま書いてるわけでは...)

「開発生産性を上げよう」とFour Keysを計測してみたものの、ふと我に返る瞬間がありませんか?

「デプロイ回数は増えた。でも、本当に生産性は上がったのか?」と。

あるいは、SPACEのような立派なフレームワークを導入しようとして、「正直、運用コストが高すぎて無理」と挫折したり。

既存の型に無理やり自分たちを当てはめる必要はありません。もっとシンプルで、手触りのある指標でいいはずです。

本記事では、教科書通りの指標を追うのではなく、**「自分たちのチームの痛みに合わせた、もう少し手前の指標」**を自分で作る方法(方程式)について考えます。


1. 提案:Four Keysを補完する「手前の指標」の例

例えば、Four Keys(結果)が出るもっと手前で、現場の実感を数値化する指標です。ここでは2つの例を紹介しますが、あくまで「例」です。

① Pt消化速度(価値のスピードメーター)

「忙しいけど、結局どれくらい進んだの?」

$$
\text{Pt消化速度} = \frac{\text{完了ストーリーポイント}}{\text{着手から完了までの時間}}
$$

  • 何が見えるか: 四六時中働いていても、ここが低ければ「ビルドトラップ(作ったけど価値がない)」や「手戻り地獄」に陥っている可能性があります。
  • ポイント: 分子はAIに「客観的なPt」を推定させると、計測コストが下がります。

② 予測誤差率(負債のセンサー)

「予定通りにいかないのは、何かがおかしい」

$$
\text{予測誤差率} = \frac{|\text{当初の見積もり} - \text{実際にかかった時間}|}{\text{当初の見積もり}}
$$

  • 何が見えるか: この数値が高い=「コードが複雑すぎる」か「仕様が曖昧すぎる」証拠です。
  • 活用法: リードタイムが悪化する(Four Keysに現れる)2週間前に、チームの異常を検知するアラートとして使えます。

2. 実証:同じ「High Performer」でも中身は違う

Four Keys上はどちらも優秀な2つのチームがあるとします。

指標 チームA (健全) チームB (疲弊)
Four Keys 優秀 優秀
Pt消化速度 3.2 pt/h 1.0 pt/h
予測誤差率 7% 50%

チームBの現場:
見積もりが半分外れる(誤差50%)ため、遅れを取り戻そうと「小さな修正」を大量にデプロイしています。Four Keysの数字は綺麗ですが、現場は火の車です。

このように、既存指標だけでは見えない「現場の本当の姿」を、独自の方程式で炙り出すことが重要です。


3. レシピ集:あなたのチームに合う方程式はどれ?

上記の指標も、あなたのチームには合わないかもしれません。
よくある課題別に、3つの「方程式のレシピ」を用意しました。これらをヒントに、自分たち用の計算式を作ってください。

【レシピ1】「待ち時間」が長すぎてイライラするチームへ

課題: コードを書く時間より、レビュー待ちや仕様確認の待ち時間が長い。
処方箋: フロー効率係数

$$
\text{フロー効率} = \frac{\text{実作業時間(コーディング+テスト)}}{\text{トータルリードタイム(着手〜完了)}}
$$

  • 狙い: 「人を増やそう」ではなく「承認フローを減らそう」という議論をするため。

【レシピ2】「バグ対応」で新機能が作れないチームへ

課題: デプロイ頻度は高いが、その半分はバグ修正。
処方箋: 品質調整済みベロシティ

$$
\text{有効ベロシティ} = \text{完了Pt} \times (1 - \text{手戻り率})
$$

  • 狙い: 「今週は50ptやりました!(でも半分手戻りです)」というぬか喜びを防ぐため。

【レシピ3】「作った機能」が使われないチームへ

課題: 機能はリリースしているが、ビジネス貢献している実感が薄い。
処方箋: 機能定着コスト指数

$$
\text{機能定着コスト} = \frac{\text{開発工数(人日)}}{\text{リリース後の週間アクティブユーザー数}}
$$

  • 狙い: 「作る速さ」ではなく「作る意味(打率)」を問うため。

4. 自分たちの方程式を作る3ステップ

  1. 「何が一番ムカつくか(痛み)」を言語化する
    • 「レビューが遅い」「仕様がコロコロ変わる」……その愚痴がスタート地点です。
  2. 分母と分子を決める
    • 分子(得たいもの):完了Pt、ユーザー数、売上
    • 分母(コスト・制約):時間、チケット数、デプロイ回数
  3. 割り算して、名前をつける
    • 名前をつけることで、それがチーム共通の「敵」または「目標」になります。

さいごに

コーディングという開発の楽しい部分はAIにごっそり奪われたので、
このAI時代に自分たちの価値とは何か、一緒にもがき、苦しんでいきましょう!!!笑

12
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?