ベロシティは提供価値の量？作業量？見積もりテックトーク

mofmofでは毎週金曜日の昼に開発手法やトレンドの技術、案件の困りごとなどについて雑談をするテックトークの時間を設けています！

今回のテーマは「ユーザーストーリーのポイント付けについて」。
mofmofでは通常、ユーザーストーリーをベースとしたタスク管理を行っています。顧客に価値を提供するユーザーストーリー以外にも、調査・バグ・リファクタリングなど ユーザー価値が直接見えにくいタスク が存在します。
今回は、それらをベロシティの計測対象とするか否かについて議論しました。

話したこと

（読み飛ばしても大丈夫です）

ストーリーのポイント付けに悩んだ
調査ストーリーのポイント付けに悩んだ
使用しているタスク管理ツールでは、技術調査やリファクタリングには見積りポイントをつけることができない
今はどんな運用をしているの？↓
調査の扱いについて
以前の結論: 実装工数の20%を超えるなら別ストーリーに / 軽い調査ならポイントなし
調査が想定より長引くとベロシティに響き、その後のスケジューリングに影響が出る
そもそもベロシティの用途って？↓
ベロシティをなんの指標にするか
価値提供の速度の指標か、作業量の指標か
顧客が求めるもの、納期の存在などがポイントになりそう
そういえばバグもポイント付けられないよね？↓
バグのポイント付けについて
現在開発中の機能のバグなら現在のタスクに内包、既存機能のバグなら別途ストーリー化しポイントをつけたい
仕様考慮漏れなのか、開発のミスなのかによっても変わりそう
で話を戻して…、どう考えるのが良い？↓
顧客のスタンスと開発スタイルの相性
アジャイルへの理解や、納期の有無によって、アジャイル寄りかウォーターフォール寄りかが変わってきそう
これによってベロシティを価値ベースで活用するか作業量ベースで活用するかが判断できる

という内容でした。

以下、o3くんがいい感じにまとめてくれた表を掲載します！

背景と論点整理

論点	主な意見	代表的な発言
調査ストーリーにポイントを付けるか	案件による。調査が実装の20%以上ならポイント付与もアリ。	「結局これ結構時間取ってるしポイント付けたいってことがある」
リファクタリングやパフォーマンス改善は？	“価値”ではなく“作業量”として測りたいニーズが強い。	「リファクタリングはChoreにしちゃうとベロシティが下がる…」
バグにポイントを付けるか	新規機能由来バグなら機能内に吸収。保守案件ならバグ単体に付与。	「既存バグを直すだけならポイント付けたくなる」
ベロシティを何に使うか	①機能開発の計画精度 ②顧客への進捗説明用途で変わる。	「次の目標設定に使いたい」

価値ベース vs. 作業量ベース ― ふたつのベロシティ

	価値ベース	作業量ベース
目的	ユーザー／ビジネス価値の提供速度を測る	工数消化ペースを測り、納期・稼働を説明
含めるタスク	“ユーザーストーリー”のみ（調査・バグは原則 0pt）	調査・バグ・リファクタリングにもポイントをつける
向いている案件	開発した価値がビジネスの成果に直結する開発自社サービス、長期プロダクト、顧客がアジャイルを理解している、など	作ることが目的となっている案件受託開発、納期固定、顧客が開発リソースを求めている場合、など
メリット	提供価値にフォーカスできる	顧客と“いつ終わる？”を会話しやすい
デメリット	調査・バグが多いスプリントは数値のブレが大きい	スクラムを採用するか？から考えるべきかも

どうしたらいい？

結論: 案件ごとに話し合って決めましょう

契約前の打ち合わせやキックオフなどで、開発スタイルに関する意識・関わり方についての認識をそろえておくと良さそうです。

観点は以下の通り。

顧客は“価値”と“作業量”のどちらを重視しているか？
納期プレッシャーが高いか？（リリース日を動かすことができない）
顧客とアジャイルプラクティスを事前に合意できているか？
（調査・保守タスクの割合は高いか？）

上記を明らかにするために、インセプションデッキの作成時や契約時に話したいこと

ベロシティを示す対象（機能量か作業量か）
ポイント付与方針（chore・バグ）

まとめ ― 必要なのは運用の納得感

調査やバグにポイントを付けても、付けなくてもよい
大事なのはチームと顧客が“なぜそうするか”を共有し、ベロシティの数字を正しく扱えること。

案件の性質・顧客の期待次第で柔軟に切り替える
受託案件でスケジュール説明が重いなら作業量ベース、自社サービス的に価値の提供速度を測りたいなら価値ベースが適している。

インセプションデッキ／キックオフで合意形成をする
結局は顧客との対話。

もふもふ技術部

IT技術系mofmofメディア