大変だーー！！またスコープが膨らんで収拾がつかないよ！
やれやれ、スコープクリープに悩んでいるのか。何がどう膨らんでしまったんだい？
クライアントが追加の機能を求めてきて、次々と新しい要求が出てきちゃって〜。
それで、追加の機能は正式に受け入れることになったのか？
えぇっ！？受け入れるかどうかも考えてなかったよ〜！
Hey guys, isn’t it just Agile to accommodate all changes?
そうそう、オウギワシ君もそう言ってますよ〜！
フム……事前に合意されていないスコープの追加は、”スコープクリープ”を招く。
プロジェクトを危険にさらす要因なんだ。
そんなの聞いてないよ〜！
まずは、今の状況をチーム全員で理解することが必要だ。
そして、それぞれの追加がプロジェクト全体にどう影響を与えるかを見極めよう。
Isn’t that going to slow us down, though?
確かに〜、それでスピードが落ちちゃうのは困りますよ。
……。プロジェクトでは「知らなかった」じゃ済まないんだ。
……。考えが浅かったかな。
まず状況を整理しよう。変更管理プロセスの見直しが必要だ。
出たーー！
| 変更管理プロセス | 説明 |
|---|---|
| 要求の記録 | 追加機能や変更したい点を正式に記録します。 |
| 影響の評価 | 変更がプロジェクトの時間、コスト、品質にどう影響するか調べます。 |
| 承認または拒否 | プロジェクトにとってプラスになるかどうかを基に、変更を承認または拒否します。 |
| コミュニケーション | 変更が承認されたら、ステークホルダー全員に情報を共有します。 |
スコープを管理するためのプロセスを詰める必要がある。
You mean we should formalize everything?
でも、クライアントが嫌がらないですか〜？
フム……丁寧に説明して、プロジェクト全体の影響を理解してもらうんだ。
なるほどー。でも上手くいきますかね？
Maybe we just need a good pitch, right?
……。要は、共有と合意形成が鍵だ。この流れをスムーズにするために会話のテンポを工夫することが必要なんだ。
う〜〜ん、やっぱり実践あるのみかなぁ〜。
まずは内部で変更管理の重要性を確認するところから始めよう。
では、今後はルールをきちんと意識して進めます！
Let’s get things done right this time.
さて、これで大丈夫だと思ったら、クライアント側でまた何か新しい要求が出てきたらどうする？
えぇっ！？それ聞いてないよ〜！
Here we go again?
フム……プロジェクトの成功は全員の協力にかかっている。次回も言葉を大切にして乗り越えようじゃないか。
わかった。次はもっと慎重に対応する！
スコープクリープを管理する方法
プロジェクト管理におけるスコープクリープは、プロジェクトの範囲が無計画に拡大する現象を指します。以下にスコープクリープを防ぐための基本的なステップをご紹介します。
- プロジェクト要求を明確に定義: 初期段階でプロジェクトの要求を詳細に文書化し、全ての関係者に確認を取ります。
- 変更管理プロセスの実施: すべての変更要求を公式に記録し、影響を評価した上で承認を得ます。
- 継続的なコミュニケーション: プロジェクト全体にわたりステークホルダーとの定期的なコミュニケーションを行い、要求が把握されているか確認します。
- 制約と合意の確認: プロジェクト契約および合意事項を常に確認し、過度な膨張を防ぎます。
- 定期的なレビューと評価: プロジェクトの進捗を定期的に評価し、スコープに影響が出ないか確認します。
これらのプロセスを通じて、プロジェクトの範囲を効果的に管理し、スコープクリープがもたらすリスクを最小限に抑えましょう。
コメント