プロダクトを開発するという活動の中で活動結果のメトリクスを分析することでより良い結果が出せることがあります。
例えば
- 予定通りに開発が進まない時に原因を探る
- 次に何を開発していくのが良いのかを決定する
といった場合に色々な数値を分析することで探索の精度を向上させたり、より良い計画が立てられたりします。
しかし複雑な開発活動の中ではたくさんの数値を計測することができ、
計測する数値やその使い方によっては意味を為さなかったり逆に害をもたらしたりもします。
私個人の開発経験と書籍を読んだりカンファレンスに参加したりして得た学びから
開発活動におけるメトリクスの種類・性質をまとめてみます。
重要なこと
- 数値を見る前にプロダクトやチームの状況・課題がある程度認識できていること
- 数値の定義を明確にすること
似たような名前で意味が異なる指標もある。認識合わせは大事。 - なんのためにその数値を計測するのか目的意識を持つこと
（簡単に取れるものはとりあえず取っておいても良いとは思います） - 数値を見た上で開発活動での出来事と合わせて分析すること
- 複数の指標を組み合わせて見ること
- 数値が絶対だと思わないこと
ソフトウェアエンジニアリングの世界で「生産性の高さ」だと主張できる汎用性の高い指標は存在しません
開発生産性について議論する前に知っておきたいこと @hirokidaichi さんの記事から引用
開発活動の段階による分類
開発活動の構造
プロダクト開発者はプロダクトという成果物を通じて顧客に価値を提供します。
開発者の活動そのものは顧客に価値を提供しません。
BtoBサービス提供企業の開発活動のイメージ
開発者の活動の多寡が必ずしもユーザーに提供する価値の多寡に直結しないという事実を認識することは非常に重要なことです。
例えば100個の機能を作っても利用ユーザーが0であればその活動が生み出した価値は0です。
Effortの段階の指標
具体例
- コードを書いた行数
- PR作成数
- PRに対するコメント数
- PRの変更行数
など
特徴
- 計測が簡単
- 開発活動の変更に対する反応が早い
- 開発者体験に影響する
- 改善点にたどり着きやすい
- 数値が改善してもOutcomeやImpactにつながるかどうかは分からない
どうやって使っていくべきか
- 開発者活動の健康状態を測る指標
⇒PRの作成数が大幅に減少していたので詳しく話を聞くと、開発業務以外の差し込みが多数発生しており、開発活動が予定通り行えていないことが分かった - 開発者の基礎行動を徹底させるためのツール
⇒1日1PRを作成することを目標とすることで毎日アウトプットを出し、PRのサイズを小さくすることを習慣づけた
開発生産性向上を通じた組織文化づくりへのアプローチ』 #開発生産性con_findyの登壇内容より引用
Outputの段階の指標
具体例
- 作った機能の数
- 直した不具合の数
- ファンクションポイント量
- ベロシティー
など
特徴
- 計測が簡単
- 開発活動の変更に対する反応が早い
- 方向性がずれてしまうとアウトカムに結びつかない
どうやって使っていくべきか
@ryuzee さんのベロシティDeep Diveより引用
- どれぐらいの量の開発を計画するかの材料に使う
⇒スクラムチームが今までのベロシティを見ながら次のスプリントで取り組む内容を決める - 将来の見通しを立てるために使う
⇒スクラムチームが今までのベロシティとリリースまでに必要なストーリーポイントを見ながらおおまかなリリース時期を考える - 推移を見て問題点を見つける
⇒ベロシティの上下が激しい時に以下のようなことを疑って分析する- 未完成のものを次のスプリントで完成させることが常態化していないか？
- 特定の種類のプロダクトバックログアイテムの見積の精度が低くないか？
- 開発者のなかにスキルのボトルネックがないか？
- 割り込みや掛け持ちで作業に使える時間が不安定になっていないか？
Outcomeの段階の指標
具体例と使い方
まずどういったプロダクトでどういう状況かという前提が必要。
例えばYouTubeのような広告によって収益を得る動画共有サービスの場合を考える。
収益に影響する要素として以下のような要素があるとする。
- 新規ユーザー数
- ユーザーの動画閲覧頻度
- ユーザーの１回当たりの動画閲覧時間
この時新しく動画終了時に関連性の高い動画の自動再生を行う機能を追加したことで
ユーザーの１回あたりの動画閲覧時間が伸びた場合、アウトカムが発生したと言える。
次の例として動画共有サービスの中の動画の投稿をサポートする機能を考える。
投稿される動画の数が増えることで新規ユーザーが増加し、ユーザーの動画閲覧時間も伸びたことが計測できている。
また多くの動画投稿者は動画につけるBGMを選ぶことに苦労している。
こういった状況で投稿する動画のBGMを無料で利用できる機能をつけることで動画投稿数が増加した場合、アウトカムが発生したと言える。
ただし動画の投稿数が増えた場合、動画を管理するコストは増加する。
そのため動画投稿数とユーザーの動画閲覧時間の関係性が以前と変わってしまっていないかということも、合わせて計測し続ける必要がある。
特徴
- 開発活動の成果そのもの
- 計測する指標は提供する価値に合わせて設計する必要がある
- 開発活動の変更に対する反応が遅い（少なくともデリバリーが必須）
- 計測が難しい場合もある
- OutcomeがImpactにつながる構造が破壊されていないことを検証し続ける必要がある
期待付加価値
Outcomeが実際に出たかどうかはリリースされて利用されるまで検証ができない。
そのため事前にどの程度の価値がある機能なのかという期待値で評価を行い、どの程度の期待付加価値をリリースできたのかを計測する方法もある。
例
- 前述のように事前に計測していた数値の関係性から収益の増加を予測するもの
- RICEスコア
- 加重スコアリング
など
Impactの段階の指標
具体例
- 売上の増加
- 利益の増加
- コストの削減
など
特徴
- ビジネスの成果そのもの
- 誰の成果かわかりづらい
突然上がった売上は開発活動の成果か？営業活動の成果か？ - 単体だと開発活動の方向性が示されない
- 開発活動に対する反応が遅い
- 開発者へのリターンに近い
お給料アップ⇒おいしいごはん
どうやって使っていくべきか
- 期待付加価値と合わせて目標にする
⇒動画の投稿時に無料で利用できるBGMを選択できる機能を開発する。
これにより動画投稿数が増加し新規ユーザーと１ユーザー辺りの動画視聴時間が増加する。
それによって動画視聴広告収益がXXXX万円増加する見込みである。
品質の観点
これまで記載したものは開発活動の出力に関するもの。
それだけで計測していると品質の悪化に気づけない場合がある。
品質が悪化すると様々な問題が発生する。
質とスピード : 製品品質の品質特性と品質副特性 @t_wada さん
例えば
修正性が低下していくと次第に実装の難易度が上がり、手戻りや不具合が増加し、開発速度が低下する。
試験性が低く自動テストを実施できない状態だと、デリバリーの速度低下やリスク増加が起きる。
機密性に問題があるとセキュリティインシデントの発生リスクが増加する。
計測可能な品質はEffortの段階の指標などと合わせて計測した方が良い。
テストが必要なものはテストを実施した方が良い。
リードタイムの観点
機能追加、不具合修正といった施策を実施するまでにかかった時間。
- どれだけ早くアイデアをユーザーに使ってもらって検証できるか
- どれだけ早く変更失敗をリカバリーできるか
に影響し、最終的にはOutcomeやImpactにも影響する。
サイクルタイム
開発に着手してから稼働するまでの時間。
開発の速度、レビューの速度、テストの速度（自動化の度合い）、デリバリーの速度（自動化の度合い）が影響する。
複数のタスクがあるとき
複数のタスクがあり、着手が後回しになったタスクは前のタスクの開発時間がリードタイムに加算される。
意思決定に時間がかかるとき
意思決定が遅くなったタスクはその分の時間がリードタイムに加算される。
複数指標の組み合わせの考え方
- SPACEフレームワーク
https://r-kaga.com/blog/about-space-of-developer-productivity - HEARTフレームワーク
https://www.ghs.tokyo/posts/HEART-Framework
参考
書籍
カンファレンス
記事、まとめ等