人事評価の開発をしているプロダクトエンジニアのnomusonです。以前、最短距離で価値検証するために、開発生産性に向き合おうとしている話という記事で、変更のリードタイムや開発生産性フレームワークSPACEといった開発生産性の指標を計測して改善していこうとしていることを紹介しました。
今回はその続きとしての取り組みをお伝えします。
スクラムフェス大阪2024で発表しました！
本題に入る前にご報告です！ 開発生産性の指標を計測して継続的改善を行ったこと、またSPACEの計測指標を定めていくアプローチについて、スクラムフェス大阪2024で発表しました！
開発サイクルタイムを計測することでプロセス改善の成果を数値で実感できたこと、定量目標を掲げる際に定性目標もいっしょに掲げることで目的を見失わないようにしたことなど発表しました。 詳細は、発表スライドをご覧ください。
私は今回スクラムフェスで初めて発表しました。発表するにあたって、プロポーザルの提出から資料作成を通して取り組みの整理ができ、進む方向の確認や調整をする良い機会になりました。
なお、同イベントでアジャイルコーチングユニットの荒川さんも基本機能のLeSSチームを分割した話を発表しました。こちらも見てください！
アジャイルコーチングユニットについて気になった人は、アジャイルコーチングユニットを立ち上げ（て）ました を読んでみてください。
やっぱり価値と向き合いたい
開発生産性と向き合って開発プロセスの精度を高めていく研鑽・改善はやっていきますが、やはり開発した機能がユーザーの求めるものになっているか、製品価値が向上したのかどうかも確認していきたいです。
ソフトウェアエンジニアリングの価値と向き合う際、XP・テスト駆動開発で有名な Kent Beck が Measuring developer productivity? A response to McKinsey の記事で紹介したメンタルモデルをベースに考えることができます。
開発生産性に関連する指標は、このモデルのいずれかに分類できます。各ノードに該当する指標の例を示します。
- Effort
- コーディングなど実際のアクティビティ
- Output
- 機能のデリバリー数
- ドキュメントの作成数
- Outcome
- 実際の成果
- 顧客課題の解決
- Impact
- 売上
- Churn Rate
Effort、Output には先行指標が多く該当し、Outcome、Impact には遅行指標が多く該当します。先行指標と遅行指標の特徴をまとめてみます。
| 先行指標 | 遅行指標 |
|---|---|
| 計測しやすい | 計測しにくい |
| 早く結果を得られる | 結果が得られるのが遅い |
| ノイズが多い | ノイズが少ない |
| 数値をハックしやすい | 数値をハックしにくい |
先行指標だけ測って数値が良くなるように取り組むと、早く作れるかもしれませんがムダな機能を量産するリスクがあります。一方、遅行指標だけ測って数値を追いかけていっても、結果は良く見えるかもしれませんが、プロセスがないがしろになるリスクがあります。つまるところ、全体的に計測して正しいものを正しくつくれているかを検査していく必要があります。Effort、Output、Impactには取り扱いやすい指標が該当していますが、Outcomeはもっとも取り扱いが悩ましいです。
Evidence Based Management で考えてみる
私たちのプロダクトのOutcomeを評価するために、どんな指標をどのように計測していくのかといったことを考える枠組みとして、Evidence Based Management（以下、EBM）というフレームワークがあります。
EBMの定義について、エビデンスベースドマネジメントガイドから引用します。
エビデンスベースドマネジメント（EBM）とは、意図的な実験とフィードバックを用いることで、人々、チーム、組織がゴールを達成するために、よりよい情報に基づいた判断ができることを支援するフレームワークである。
経験主義にもとづいたフレームワークであり、スクラムに取り組んでいる私たちにとっても馴染みやすそうなため、EBM を通して Outcomeも取り扱えるように取り組んでいきます。
EBMでは、4つの重要価値領域を定義しています。
それぞれの重要価値領域において測るべき指標を考えて、ゴールを設定し、実験・フィードバックを繰り返していきます。 「現在の価値(CV)」の重要価値指標の1つである「顧客使用指標」を例に挙げてみます。人事評価では、評価データの開始数などユーザーの利用状況を集計しています。これから開発していく機能郡のOutcomeとして「評価データの開始率を10%上昇する」とゴールを立てて、開発プロセスやつくる機能の実験を繰り返しながら取り組んでいきます。 OutcomeだけでなくFour KeysやSPACEの指標もこの重要価値領域で分類することができます。手持ちの計測指標も活用しながら、EBMやっていきです！
さいごに
ソフトウェア開発は非常に複雑なため、開発生産性を完璧に定義して捉えることは不可能です。Kent Beckもそう言っています。 開発生産性が何か？ということではなく、顧客が本当に欲しいものを素早く提供できているかどうか検査して、適応をしていきたいものです。
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
