Googleプロジェクト管理：スコープクリープ

はじめに

わたしが Google プロジェクト管理:プロフェッショナル認定証で得られた素晴らしい体験を、要点をまとめ小さく分割して、わかりやすく簡潔に紹介していきます。

興味があれば、ぜひ "Google プロジェクト管理:プロフェッショナル認定証" を受講してみてください。

プロジェクトのスコープ

前回、プロジェクトのスコープについて紹介しました。

プロジェクトマネージャーは、チームが軌道に乗れるように、プロジェクトの境界線をしっかりと設定し、維持することが仕事です。

• インスコープ :プロジェクトに含まれ、プロジェクト全体の目標に貢献するタスク
• アウトオブスコープ :含まれていないタスク

スコープクリープとは

プロジェクトのライフサイクルが進むにつれて、予期せぬ問題に遭遇したり、プロジェクトの成功に影響を与えるような新しい詳細やアイデアがもたらされたりすることがあります。

プロジェクト開始後のどの時点でも、プロジェクトのスコープに影響を与える変更、拡大、制御不能な要因を "スコープクリープ" と呼びます。

スコープクリープはよくある問題で、コントロールするのは必ずしも容易ではありません。私たちは、すべてのプロジェクトでこの問題に取り組んでいます。どのようなプロジェクトでも、どのような業界でも起こりうることです。

また、スコープクリープの発生源は、外部と内部の2つに大別されます。

外部スコープクリープ

スコープクリープの外部発生源は、認識しやすいものです。 例えば、一人の主要な顧客とプロジェクトを進めている場合、その顧客から変更を要求されるかもしれませんし、周囲のビジネス環境が変化するかもしれませんし、使用している基礎技術が変わるかもしれません。

外部スコープクリープの主な原因として、要件が具体的でなく、プロジェクトのプロセス、成果物、マイルストーンに合意していない場合、プロジェクト開始後にスコープクリープが発生することはほぼ間違いないでしょう。

役立つヒント:

• ステークホルダーがプロジェクトに対して可視性を持っていることを確認します。何が作られ、どのようなリソースが必要で、どれくらいのコストがかかり、どれくらいの時間がかかるのか、詳細を知っておいてほしいのです。
• 要件を明確にし、最初の計画に対して建設的な批評を求めましょう。このような情報は、契約締結前に得ることが重要です。
• プロジェクトの範囲が明確になったら、範囲外の要求にどう対処するか、計画を立てる。誰が正式な変更要求を出せるか、また、それらの要求をどのように評価し、受け入れ、実行するかについて合意する。
• 最後に、これらの合意事項を必ず文書化する。こうすることで、あなた、ステークホルダー、または顧客が、将来的に意見の相違を生じたときに、いつでも参照できる文書を持つことができます。

内部スコープクリープ

内部で発生するスコープクリープは、発見が難しく、制御も困難です。この種のクリープは、プロジェクトチームのメンバーがプロセスや製品の変更・改良を提案したり、それを主張したりすることで発生します。

例えば、

• 開発チームが、コストが高くなるにもかかわらず、製品をより良くするという理由で決定を正当化してしまう。
• チームリーダーが、プロセスの変更がプロジェクトの別の部分を担当している他のチームメンバーに与える影響を理解せずに、あるプロセスがより効率的であると決定してしまう。

役立つヒント:

プロジェクトスコープ外の変更は、損益を悪化させ、スケジュールを脅かし、リスクを増大させるということを、チームに明確に伝える必要があるのです。プロジェクトスコープに小さな影響はない。チームメンバーが予定外のタスクを引き受けた場合、そのタスクに費やされた時間以上のものが失われるのです。

プロジェクトの限界を維持するのは、プロジェクトマネージャーとしてのあなたの責任です。プロジェクトのスコープを常に監視しておきます。たとえ些細な変更であっても、プロジェクトの成功に大きなリスクをもたらす可能性があります。

スコープクリープを制御するためのベストプラクティス

• プロジェクトの要件を定義する: ステークホルダーや顧客とコミュニケーションをとり、彼らがプロジェクトに何を求めているかを正確に把握し、開始段階でそれらの要件を文書化します。
• プロジェクトのスケジュールを明確にする: 時間やタスクの管理は、プロジェクトの範囲を守るために不可欠です。スケジュールは、プロジェクトのすべての要件と、それを達成するために必要なタスクの概要を示す必要があります。
• 何がスコープ外かを判断する: ステークホルダー、顧客、プロジェクトチームは、提案された変更がスコープ外であることを理解するようにします。プロジェクトへの潜在的な影響について明確な合意をとり、合意を文書化する。
• 代替案を提供する: 顧客やステークホルダーに代替策を提案する。また、提案された変更がどのように新たなリスクを生む可能性があるかを検討させることもできます。必要であれば、費用対効果分析を行う。
• 変更管理プロセスを設定する: プロジェクトの期間中、いくつかの変更は避けられません。プロジェクト計画に追加する前に、各変更をどのように定義し、レビューし、承認（または却下）するか、そのプロセスを決定する。プロジェクトチームがこのプロセスを理解していることを確認します。
• ノーと言う方法を学ぶ: 時には、提案された変更にノーと言わなければならないこともあります。主要なステークホルダーや顧客にNOと言うのは気が引けるものですが、プロジェクトの範囲と全体的な品質を守るためには必要なことです。追加作業を依頼された場合は、最初のプロジェクト要件で定義した予算、スケジュール、リソースにどのような支障が出るかを説明します。
• 範囲外の作業に対する費用を徴収する: 範囲外の作業が必要な場合、発生したすべてのコストを文書化する。これには、スコープの拡大により間接的に影響を受けた作業の費用も含まれます。また、その費用が何に対するものかを必ず明記してください。

スコープクリープ発生の例

例えば、あなたは、開発チームとスマートフォン用のモバイルキーボードアプリの言語アイコンのデザインを更新するプロジェクトに携わったとします。

その際、検索アイコンと音声入力アイコンのデザインも刷新する必要があることに気づきました。これらは非常に小さな機能であり、技術的には対象外ですが、チームは最小限の労力で大きな価値を提供できると考えました。そこで、アップデートに踏み切ったのです。

しかし、関係者のレビューで、英語のキーボードはあるが、他の言語のキーボードがないことが指摘され、キーボードを追加設計することが提案された。この時点で、プロジェクトのスコープは、ごく単純なアイコンの更新から、複数のキーボードレイアウトを展開する複雑なものへと拡大する危険性が出てきました。

キーボードを追加すると、

• チームのタイムラインに影響を与え、プロジェクトが長引くことになります。
• また、人員を増やすか、既存のメンバーが残業をする必要があるため、人材確保にも影響が出ます。
• さらに、作業時間の延長やキーボードの翻訳などのコストを想定していなかったため、予算が増加することになります。

これは、スコープクリープの一例に過ぎません。スコープクリープは、「アイコンをもう一つか二つデザインすればいいじゃん！」というような微妙なものから、「他の言語のキーボードのデザインもやってよ！」というような分かりやすいものまで、さまざまです。