【目次】
1. スコープクリープとは？
1、スコープクリープとは？
プロジェクトでは、一般に予期せぬ出来事が発生し、常にスコープ（システムやプロジェクトの範囲）が変わってしまいます。スコープの変更は、プロジェクトの様々な面に影響するため、適切にマネジメントする必要があります。しかし現場では「このぐらいの変更ならたいしたことはないだろう」と、報告・承認を経ずにスコープを変更することがあります。
これが繰り返されると、ベースラインと現実のスコープが乖離（かいり）して、プロジェクトマネージャーが現状を把握できなくなり、適切なマネジメントが行えなくなる恐れがあり、これがスコープクリープ （Scope creep） の原因となります。
従来のプロジェクトマネジメントの手法では、プロジェクトへの変更要求を、すべてプロジェクトマネージャーに集約させます。スケジュールやコスト、リソースなどへの影響を検討し、プロジェクトオーナーなどプロジェクトの責任者や、その責任範囲を超えた場合には、さらに上級管理者の承認を経てから、変更を実施しなければなりません。いわゆる正式な変更管理を経ることが必要であり、その影響評価、変更手続きや承認のための作業と時間を要します。従来のプロジェクトマネジメントでは、変更に対してそのプロセスを重んじるのです。
2、スコープクリープを防ぐために
スクラムとは、複雑で変化の激しい問題に対応するためのフレームワークでSBOK［1］の「6.4. スクラムにおける変更」で説明しているように「柔軟性と安定性のバランスをうまくとること」で変更に対処します。それが、スコープクリープを防ぐことにつながります。
【スクラムの柔軟性】
スクラムの柔軟性は、反復的な製品開発、タイムボックス、クロスファンクションチーム[2]、顧客価値ベースの優先順位付け、および継続的インテグレーション（統合・統一）によって、実現されます。
【安定性】
あらゆるスプリントで、そのスコープをロックダウンすることにより、チームは作業と労力を効率的に最適化および管理できます。その他のメリットとしては、チームがスプリントの作業を開始した後に、変更を管理する必要がないことです。これは、従来のプロジェクトマネジメントと比較して、スクラムのフレームワークの大きなメリットです。従来のプロジェクトマネジメントとスクラムプロジェクトの相違は次のようです。
・従来のプロジェクトマネジメント
従来のプロジェクトマネジメントでは、プロジェクトのライフサイクル中にいつでも変更を要求および承認できます。これは、プロジェクトチームメンバーに混乱を招き、不連続性によるチームのモチベーションを低下させ、集中力の欠如（けつじょ）と「何も成し遂げていない」という感覚をチームに引き起こします。
・スクラムプロジェクト
スクラムプロジェクトでは、スプリントが開始されると変更はできません。これにより、すべてのスプリントで、チームはタスクを完了し、成果物を完成するのです。ビジネス側は、各スプリントの終了時に、出荷可能な成果物から具体的なメリットを認識することができるのです。さらに、プロダクトオーナーとステークホルダー[3]は、一旦スプリントが開始されると、それは1週間から6週間続くので、その間には変更が許可されないということを認識しています。ですから、エピックの開発、プロダクトバックログの作成、およびプロダクトバックログのグルーミングといった適切なプロセスのなかで、要件を定義し、優先順位を付けておくのです。
3、「顧客価値ベースの優先順位付け」に関するテクニック
スクラムの原則の一つ「顧客価値ベースの優先順位付け」に関するテクニックをご紹介します。詳細は、SBOKの「4.5.2. 価値の計画」を参照ください。
3.1＜顧客価値ベースの優先順位付け＞
顧客価値ベースの優先順位付け （Customer Value-based Prioritization） は、顧客に最も重要な役割を置き、最初に最も高い価値を持つユーザーストーリーの実装に努めます。このような高価値のユーザーストーリーが特定され、プロダクトバックログの先頭に、それらを移動します。
チームは、さまざまな優先順位付けスキームを使用して、価値の高いフィーチャーを決定することができます。
a. シンプルなスキーム
シンプルなスキームでは、項目に優先度”1″、”2″、”3″、または”高”、”中”、”低”などのラベルを付けます。これは単純で分かりやすいアプローチですが、優先度”1″または”高”とラベル付けする傾向が多いため、問題が発生する可能性があります。
b. MoSCoWの優先順位付け
MoSCoWの優先順位付けスキームは「Must have」、「Should have」、「Could have」、「Won’t have」というフレーズの最初の文字から名付けられました。この優先順位付け方法は、一般的にシンプルなスキームよりも効果的です。このラベルは、優先順位が高い順に並んでいます。「Must have」フィーチャーは、もしそれがなければ製品そのものに価値がありません。「Won’t have」フィーチャーは、もしそれがあったらありがたいのですが、製品に含まれる必要がないものです。
c. モノポリーマネー
この手法は、顧客にプロジェクト予算の金額と等しい「モノポリーマネー （Monopoly Money）」または「偽金」を与え、検討中のユーザーストーリーのなかで配布するよう依頼するものです。このようにして、顧客は各ユーザーストーリーに対してどのくらい支払う意思があるかに基づいて、優先順位を付けます。
d. 100ポイント法
100ポイント法 （100-Point Method） はディーン・レフィングウェル （Dean Leffingwell） とドン・ウィドリグ （Don Widrig, 2003）によって開発されました。これは、100ポイントを顧客に与えて、それを使って最も重要だと感じるフィーチャーに投票します。
e. 狩野モデル
狩野モデル （Kano analysis） は、狩野紀昭（1984）によって開発されました。顧客の嗜好に基づいてフィーチャーや要件を次の4つのカテゴリーに分類するものです。
- エキサイター （Exciters） / ディライター（Delighters） ：顧客にとって新しいもの、もしくは高い価値があるフィーチャー
- サティスファイアー （Satisfiers） ：顧客に価値を提供するフィーチャー
- ディスサティスファイアー （Dissatisfiers） ：それが存在しない場合には、顧客が製品を気に入らない可能性が高...
