🏃‍♂️

中長期プロジェクトのためのスクラム開発ガイド

に公開
スクラム
プロジェクト管理
見積もり
アジャイル開発
進捗管理
idea

中長期プロジェクトのためのスクラム開発ガイド

よく聞く悩み：計画と柔軟性のジレンマ

中長期プロジェクトでスクラム開発を導入する際、こんな悩みを抱えていませんか？

「ウォーターフォールは変更に弱いけど、純粋なスクラムだと長期的な見通しが立てにくい...」

これは多くの開発チームが直面する根本的なジレンマです：

  • ステークホルダーは計画を知りたい：「いつ完成するのか」「予算内で収まるのか」
  • チームは柔軟に動きたい：仕様変更や新しい要求に臨機応変に対応したい

この相反する要求を同時に満たすには、どうすればよいのでしょうか？

解決方法：ハイブリッドアプローチ

答えは、計画性と柔軟性を両立させるハイブリッドなアプローチにあります。

具体的には：

  1. フェーズ1：全体設計 - しっかりとした計画を立てる
  2. フェーズ2：スクラム開発 - 柔軟な実装を行う
  3. 2段階見積もり - 2つのフェーズを連携させる仕組み

この手法により、ステークホルダーが安心できる予測可能性と、開発チームが必要とする柔軟性の両方を実現できます。

なぜ従来のアプローチでは限界があるのか

このジレンマの背景を理解するために、従来のアプローチの課題を整理してみましょう。

ウォーターフォールの限界

ウォーターフォール開発では、半年から1年以上の長期プロジェクトにおいて以下の問題が発生します：

  • 要件変更への対応が困難 - 途中での仕様変更により設計からやり直しになる
  • フィードバックの遅延 - システム完成まで実際の使用感が分からない
  • 進捗の不透明性 - 「設計90%完了」の実態が把握できない
  • モチベーション維持困難 - 成果が見えにくく士気が低下する

特に要件変更への対応困難さは深刻で、プロジェクト開始から数ヶ月後に「やはりこの機能が必要」となった場合、すでに作成済みの設計書や開発済みの機能に大幅な修正が必要となり、コストと期間の大幅な増加を招きます。

純粋なスクラム導入の課題

一方で、スクラムを単純に導入するだけでは、中長期プロジェクト特有の問題に対処できません：

全体像が見えないことによる不安: 2週間のスプリントを繰り返すだけでは、プロジェクト全体の完成時期やコストが見通せません。ステークホルダーは「いつ完成するのか」「予算内で収まるのか」といった根本的な質問に対する答えが得られず、不安を抱えることになります。

予算承認と計画立案の困難さ: 企業のプロジェクトでは、事前の予算取りやマイルストーンの設定が必要不可欠です。しかし、従来のスクラムでは「やってみないと分からない」という性質上、これらの要求に応えることが困難です。

スコープ管理の問題: 新しい要望が出たときに、それがプロジェクト全体に与える影響を正確に判断できません。結果として、スコープが際限なく拡大するか、逆に重要な機能が削られてしまうリスクがあります。

解決策：2フェーズ + 2段階見積もりのハイブリッドアプローチ

全体像：2つのフェーズで進める

この手法のキモは、計画性を重視するフェーズと柔軟性を重視するフェーズを分けて実行することです。

フェーズ1：全体設計では、ステークホルダー全員を巻き込んで要求をしっかり固めます。ワイヤーフレームを作成し、機能一覧と大まかな優先順位を決定。そして技術リーダーが概算見積もりを行い、全体のスケジュール感と予算感について合意を得ます。

フェーズ2：スクラム開発では、全体設計をもとにPBI（プロダクトバックログアイテム）を詳細化し、2週間のスプリントを繰り返して実装を進めます。各スプリントでは、いつものスクラムサイクル（リファインメント、プランニング、実装、レビュー、デプロイ）を回していきます。

【フェーズ1：全体設計】
要求整理（ステークホルダー全員で実施）
  ↓
ワイヤーフレーム作成
  ↓
機能一覧と優先度決定
  ↓
概算見積もり（技術リーダーが実施）
  ↓
スケジュール作成・予算承認

【フェーズ2：スクラム開発】
PBI詳細化 → リファインメント → スプリントプランニング
    ↓                                    ↓
  API仕様/        2週間スプリント      実装
  DB設計             ×N回            ↓
                                  レビュー → デプロイ

このアプローチにより、プロジェクトの予測可能性を確保しながら、実装段階では柔軟な対応が可能になります。

鍵となる仕組み：2段階見積もり

2つの異なる目的の見積もりを連携させることで、計画性と柔軟性を両立させます。

第1段階：概算見積もり（全体像把握のため）

実施者: 技術リーダー
実施時期: プロジェクト開始時
目的: プロジェクト全体の工数とスケジュールを把握

特徴的なポイント：

  • ざっくりした5段階評価: SS(1)、S(2)、M(3)、L(5)、LL(8)ポイント
  • 機能単位で見積もり: 画面やAPI単位で分解してポイント割り当て
  • 意図的にバッファを確保: チーム実力25ポイント/スプリント → 計画上は20ポイントで設定

なぜバッファが重要か？
後の仕様変更や予期しない問題に対応するための柔軟性を確保するためです。これがないと「2週間区切りのウォーターフォール」になってしまい、スクラムの利点を活かせません。

活用目的：

  • 全体工数の算出
  • 予算取りの根拠資料
  • リリース計画の作成
  • 進捗管理の基準値

第2段階：詳細見積もり（スプリント実行のため）

実施者: 開発チーム全員
実施時期: 各スプリントの前週（リファインメント時）
目的: スプリント計画の妥当性確認

手法: スクラム標準の1、2、3、5、8ストーリーポイント
重要: 時間ではなく、作業の相対的な大きさ・複雑さを示す

主な目的: 今回のスプリントで消化予定のPBI合計ポイントを、チームのベロシティ（過去の実績）と比較して、無理のないスプリント計画かを検証

副次的用途: 各PBIの相対的な大きさを把握し、その比率を使って概算見積もりポイントに換算することで、全体進捗を算出

2つの見積もりをどう連携させるか？

課題: 詳細見積もりのポイントを単純に足しても、途中でPBIが分割されたり追加されたりしたら、全体の進捗率がずれてしまう

解決策: 比率を使った換算という工夫で解決

具体例で理解する連携の仕組み

例えば、概算見積もりで50ポイントだった「ユーザー管理機能」があったとします。

これを詳細化した結果：

  • PBI-A（ユーザー登録）: 5ポイント
  • PBI-B（ユーザー情報編集）: 3ポイント
  • PBI-C（ユーザー削除）: 2ポイント
  • 合計: 10ポイント

この時、PBI-A（5ポイント）が完了したら：

1. PBI-Aの比率を計算
   比率 = 5ポイント ÷ 10ポイント = 0.5 (50%)

2. 概算ポイントに換算
   消化ポイント = 0.5 × 50ポイント = 25ポイント

つまり、元の概算ポイントに対する比率で完了した価値を測ります。

これなら、PBIが途中で細分化されたり増えたりしても、元の計画に対する進捗度をちゃんと追跡できるわけです。地味ですが、この仕組みにより長期的な見通しが立ちます。

進捗の可視化：バーンアップチャート

完了した作業量をこの換算後の概算ポイントベースでどんどん積み上げていくグラフです。それを最初に設定したバッファ込みの計画線と比較します。

重要なポイント: 予定線が控えめな消費ポイント数（バッファを含む）で設定されていること

  • 実績線が計画線を上回る → 進捗順調かつバッファが機能している証拠
  • 実績線が計画線を下回る → 早めにアラートを出せる

ステークホルダーにも「当初の見積もりに対して、今大体X%完了です」と、すごくクリアに報告できます。

以下のようなグラフになります：

500pt                         ━━━━━━━━ 最終目標
                         ┌────
400pt                ┌────┘    予定線（バッファ込み）
                 ┌────┘■■■
300pt        ┌────┘■■■      実績線
         ┌────┘■■■
200pt ┌────┘■■■  ← 予定線より上なら順調
   ┌────┘■■■      （バッファが機能している）
100pt ■■■
      Sprint1  Sprint2  Sprint3  Sprint4...

この手法の効果：

  • 正確な進捗率の維持: PBIが分割や追加されても、正確な進捗率を維持
  • 一目で分かる進捗状況: 予定と実績の乖離がグラフで一目瞭然
  • ステークホルダーへの明確な報告: 数値で明確に説明可能

うまく進めるための3つの重要ポイント

このハイブリッドアプローチをうまく進めるために、特に重要なポイントを3つに絞ってお伝えします。

1. 初期の全体設計でバッファ込みの概算見積もりをしっかりやる

中長期プロジェクトでは、最初の全体設計と概算見積もりが必須です。

バッファ確保により柔軟性を担保：実力の80%程度でスプリント計画を立てることで、仕様変更や予期しない問題に対応できる余裕を作り出します。

実装順序の最適化：依存関係を考慮した深さ優先探索的なアプローチにより、リスクの高い部分を早期に実装し、問題を早期発見できます。

2. PBIの変化に強い比率換算とバーンアップチャートで進捗を可視化・共有

比率を使った進捗管理：PBIが増減しても正確な進捗率を維持できる仕組みを構築します。

バーンアップチャートによる常時監視：プロジェクトの健康状態を常に把握し、ステークホルダーへの定期的な報告では数値に基づいた客観的な情報を提供します。

早期発見・早期対応：問題が発生した場合でも、早期発見・早期対応が可能な体制を整えます。

3. 2段階見積もりと進捗管理をうまく連携させる

詳細見積もりとベロシティの比較検証：各スプリントの計画が妥当であることを確認します。

長期的予測可能性と短期的アジャイル開発の両立：概算見積もりによる長期計画と、詳細見積もりによる柔軟な実装を比率でつなぎ、両方の良いところを活用します。

まとめ：計画性と柔軟性の両立

本記事でご紹介したハイブリッドアプローチは、スクラムの柔軟性と計画的な開発を両立させる実践的な手法です。

今回のアプローチのポイントは、以下の3つのステップを適切に組み合わせることにあります：

  1. 最初に全体像を描く（概算見積もりによる予測可能性の確保）
  2. 詳細は都度計画する（スプリント単位での柔軟な対応）
  3. 常に進捗を可視化する（バーンアップチャートによる透明性の提供）

この組み合わせにより、ステークホルダーが安心できる予測可能性と、開発チームが必要とする自律性の両方を実現できます。

GitHubで編集を提案

Discussion