コンテンツにスキップ
Vecta Contents

ストーリーポイント発注の考察

このドキュメントは、従来の「時間単価での発注」と、新しく試みている「ストーリーポイント単位での発注」を比較し、その実験結果や考察を共有することを目的としています。

管理者の役割として、常に「成果が報酬に見合っているか」を評価する必要があり、この点はどちらの発注スタイルでも共通していますが、ストーリーポイント単位の発注では、以下のような特徴が見えてきています。

  • 具体的な作業タスクと報酬が紐づくため、根拠を伴った評価が可能
  • 成果と報酬の妥当性が明確になり、メンバー間の単価不公平感が少ない
  • 単価交渉の合意形成は発注開始時の1回でよくなり、その都度、なんとなくの交渉を受ける必要がない

この点を中心に整理し、従来スタイルとの違いから得られた学びを共有していきたいと思います。

ストーリーポイントについて

ストーリーポイントとは、スクラム開発において、開発チームが作業の複雑さや工数を見積もるために使う相対的な単位です。

ストーリーポイントは時間ではなく、「相対的な複雑さ」を表します。例えば、あるタスクを1ポイントとした場合、2ポイントのタスクはその2倍複雑で、3ポイントのタスクは3倍複雑ということになります。

なぜ時間ではなくポイントなのか

時間での見積もりは人によって大きく異なりますが、相対的な複雑さの比較は人によるばらつきがなく、比較的安定しています。見積もりと実績をチーム全体で議論することが重要で、より正確な見積もりにつながります。

複雑なタスク、難易度高いタスクをより多くアウトプットできるエンジニアはより多くのSPを稼ぐことができ、技術力アップのモチベーションにつながります。

一般的なポイント体系

最もよく使われるのは「フィボナッチ数列**（1, 2, 3, 5, 8, 13, 21…）」です。数字が大きくなるほど間隔が広がるのは、複雑なタスクほど見積もりの不確実性が高くなることを反映しています。細かすぎる議論を避ける（もし 1, 2, 3, 4, 5, 6, 7… のような連続した数字を使うと、「このタスクは5か6か」で議論が長引きがち）

見積もりプロセス

タスクを取り組む前に担当するエンジニアが見積もり、イテレーションミーティングでメンバー全員で議論することで調整します。

「プランニングポーカー」を使う方法も良いです。チームメンバーが同時にポイントカードを出し、大きく異なる見積もりがあった場合は議論を行い、最終的にチーム全体で合意形成を図ります。

ベロシティの算出

チームが1イテレーション（通常1〜4週間、脳活ラボでは4週間を採用しています）で完了できるストーリーポイントの合計を「ベロシティ」と呼び、これを使って将来のイテレーション計画や納期予測を行います。

ストーリーポイントの目安

イテレーションを重ねながら、チームで合意した指標を構築していきます。

e.g.）

ポイント作業内容の目安
11-2テストケース程度の機能追加 / 軽微なバグ修正
23-4テストケース程度の機能追加
3単純なCRUD画面
5複雑なCRUD画面 / 環境構築 / その他同等の作業
8複雑なUIを伴う画面 / 難易度の高い技術調査

イテレーションミーティングの運用

  1. 事前準備
  • 各メンバーが前イテレーションの実績を記入
  • 見積もりに対する実績の比較を準備
  • 次イテレーションで取り組むイシューとその見積もりを入力
  1. ミーティングでの活動
  • 前イテレーションの振り返り（見積もり vs 実績）
  • 次イテレーションのイシューと見積もりの妥当性を全員で議論
  • チームのベロシティと次イテレーションのストーリーポイント総量を比較
  • ベロシティに対して計画が適切に収まっているか、リスクがないかをチェック
  • 必要に応じてストーリーポイントの見積もりや対象イシューを調整
  1. 継続的な改善
  • 4週間ごとのイテレーション開始時に実施
  • ストーリーポイント指標を実績に基づいてブラッシュアップ
  • チーム全体で納得できる指標を継続的に改善

レビュー工数の考慮

メンバーによっては、他のメンバーのプルリクエストをレビューする工数が必要な場合があります。

  • レビュー専用のストーリーポイント設定
    • 簡単なレビュー（小さな修正）: 1ポイント
    • 中程度のレビュー（新機能の追加）: 2-3ポイント
    • 複雑なレビュー（アーキテクチャ変更）: 5-8ポイント
  • レビュー作業が主なタスクになるメンバーは、別途個別に見積もって対応。より詳細にレビューし、メンバーとコミュニケーションしたくなる設計にしておくことが重要。
  • ローテーション制の導入し、レビュー負荷を特定の人に集中させず、チーム全体でローテーションすることで、知識の偏りや負荷を平準化する方法も良い。

注意事項

ストーリーポイントの変更は必ずイテレーションミーティング内で行う。 個人での変更を禁止する理由は、チーム全体の状況把握ができなくなるためです。

課題

  • イシュー登録時に自動で見積もりを設定するActionの検討
  • 目安の自動更新
  • 未確定要素の多いタスク
  • 緊急タスク（イテレーションにバッファが必要）
  • スキルが低いメンバーのモチベーションの維持が課題。ペアプロを推奨してスキルアップを促進するフォローが必要。

発注までの流れ

まとめ

契約形態の使い分け

  • SES契約が適している業務
    • 環境構築
    • 技術調査
    • イシュー自体の登録（上流設計）
  • SP契約が適している業務
    • 定義済みイシューの実装作業
    • メンバーレベルでの開発作業

課題認識

  • イシュー登録がなければ、作業がなく収益も発生しないリスクがある
  • SPでの運用はイシューありきのため、イシューを作成できるエンジニアに負荷が集中する
  • イシュー登録はテックリードレベルの人材に依存している
    • 事例: イシュー登録できないベトナムチームはSESからSPへ移行
    • AIの普及もあって、結果、離脱

もともこもない話

  • AIがゲームチェンジャーとなった現状を踏まえた設計が必要
  • AIプロンプトの設計・最適化に高いインセンティブ