スコープクリープとは？
プロジェクトでは、一般に、予期せぬ出来事が発生し、常にスコープが変わってしまいます。スコープの変更は、プロジェクトの様々な面に影響するため、適切にマネジメントする必要があります。しかし、プロジェクトの現場では、「このぐらいの変更ならたいしたことないだろう」と、報告・承認を経ずにスコープを変更することがあります。これが繰り返されると、ベースラインと現実のスコープが乖離して、プロジェクトマネージャーが現状を把握できなくなり、適切なマネジメントができなくなる怖れがあります。これがスコープクリープ (Scope creep) です。
従来のプロジェクトマネージメントの手法では、プロジェクトへの変更要求を、すべてプロジェクトマネージャーに集約させます。スケジュールやコスト、リソースなどへの影響を検討し、プロジェクトオーナーなどプロジェクトの責任者や、その責任範囲を超えた場合には、さらに上級管理者の承認を経てから、変更を実施しなければなりません。いわゆる正式な変更管理を経ることが必要であり、その影響評価、変更手続きや承認のための作業や時間を要します。従来のプロジェクトマネジメントでは、変更に対してプロセスを重んじるのです。
スコープクリープを防ぐためには
スクラムのフレームワークでは、SBOKの「6.4. スクラムにおける変更」でご説明しているように、「柔軟性と安定性のバランスをうまくとること」で変更に対処します。それが、スコープクリープを防ぐことにつながります。
柔軟性：スクラムの柔軟性は、反復的な製品開発、タイムボックス、クロスファンクションチーム、顧客価値ベースの優先順位付け、および継続的インテグレーションによって、実現されます。
安定性：「あらゆるスプリントで、そのスコープをロックダウンすることにより、チームは作業と労力を効率的に最適化および管理できます。その他のメリットとしては、チームがスプリントの作業を開始した後に、変更を管理する必要がないことです。これは、従来のプロジェクトマネジメントと比較して、スクラムのフレームワークの大きなメリットです。」
- 従来のプロジェクトマネジメント：「従来のプロジェクトマネジメントでは、プロジェクトのライフサイクル中にいつでも変更を要求および承認できます。これは、プロジェクトチームメンバーに混乱を招き、不連続性によるチームのモチベーションを低下させ、集中力の欠如と「何も成し遂げていない」という感覚をチームに引き起こします。」
- スクラムプロジェクト：「スクラムプロジェクトでは、スプリントが開始されると変更はできません。これにより、すべてのスプリントで、チームはタスクを完了し、成果物を完成するのです。ビジネス側は、各スプリントの終了時に、出荷可能な成果物から具体的なメリットを認識することができるのです。さらに、プロダクトオーナーとステークホルダーは、一旦スプリントが開始されると、それは1週間から6週間続くので、その間には変更が許可されないということを認識しています。ですから、エピックの開発、プロダクトバックログの作成、およびプロダクトバックログのグルーミングといった適切なプロセスのなかで、要件を定義し、優先順位を付けておくのです。」
「顧客価値ベースの優先順位付け」に関するテクニック
スクラムの原則のひとつ、「顧客価値ベースの優先順位付け」に関するテクニックをご紹介します。SBOKの「4.5.2. 価値の計画」を参照ください。
＜顧客価値ベースの優先順位付け＞
顧客価値ベースの優先順位付け (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) ：それが存在しない場合には、顧客が製品を気に入らない可能性が高いが、存在したとしても満足度に影響を与えないフィーチャー
- 無関心 (Indifferent)：顧客に影響を全く与えることないフィーチャー。取り除くことが必要。
図 4-4 は、狩野モデルを示したものです。
興味深いことに、フィーチャーは通常、時間の経過とともに分類リストを下のほうに移動します。顧客が期待していたフィーチャー (例えば、携帯電話のカメラ) であっても、エキサイター / ディライターからサティスファイアーへ、そして最終的には、無関心へと移っていくのです。
以上、実際のプロジェクトマネジメントで参考にしていただければ幸いです。