レッスン2：スコープを固める

このレッスンで学ぶこと

成果物ベースでスコープを記述する発想を身につける
受け入れ基準を書き、「完了」の基準を関係者と共有できるようにする
MoSCoWで優先度を4段階に分類できる
スコープクリープが起きる仕組みと、その防ぎ方を理解する
変更要求と変更管理プロセスの基本を把握する
プロジェクト計画書に書く7つの項目を理解する

レッスン1では、プロジェクトを制約の三角形（スコープ・QCD）で捉える発想と、本コースの守備範囲を確認しました。今回から、実際に手を動かしてプロジェクトを組み立てていきます。最初の一歩は、「何を作るか、どこまでの範囲をやるか」を固める作業、つまりスコープを固めることです。

スコープが曖昧なまま走り出すとどうなるか

具体的な場面で考えてみましょう。あるメーカーで、新商品の発売プロジェクトが立ち上がりました。プロジェクトリーダーは「発売日までに、しっかり準備を整えます」とだけ関係者に伝え、詳細なすり合わせをしないまま各部門に作業を割り振りました。

2か月後、進捗確認の会議で問題が表面化します。製造部門は「発売日に工場出荷分の在庫を確保する」ことだけを目標にしていました。一方、営業部門は「発売日にはすでに主要な取引先の店頭に商品が並んでいる」ことを前提に、取引先への案内を進めていました。工場出荷から店頭陳列までには、通常2〜3週間の物流のリードタイムがかかります。つまり、製造部門と営業部門が思い描いていた「発売日」の意味が、最初からズレていたのです。

このズレに気づいたのは、発売予定日のわずか1か月前でした。慌てて製造スケジュールを前倒ししようとしましたが、原材料の調達が間に合わず、結局、発売日を2週間延期する事態になりました。

この失敗の根本原因は、製造部門の作業能力でも、営業部門の交渉力でもありません。「発売日までに、しっかり準備を整える」という姿勢ベースの合言葉だけで走り出し、「発売日とは具体的に何が完了している状態か」という成果物ベースの合意を、プロジェクトの最初にしていなかったことにあります。本レッスンで扱う技術は、この種のズレを、プロジェクトの初期段階で防ぐためのものです。

なぜスコープを最初に固めるのか

プロジェクトが混乱する最大の原因は、実はスケジュールの見積もりミスよりも、「スコープが曖昧なまま走り出すこと」にあります。「新商品を発売する」「オフィスを移転する」「社内イベントを開催する」——このような一言のゴールだけでは、関係者それぞれが思い浮かべる中身がバラバラになりがちです。ある人は「発売日にプレスリリースを出すこと」までを想像し、別の人は「発売後3か月の販促活動」まで含めて想像しているかもしれません。この認識のズレを放置したまま作業を始めると、後になって「そんなことまでやるとは思っていなかった」という食い違いが表面化し、手戻りや対立の原因になります。

スコープを固めるとは、この認識のズレを、プロジェクトの最初の段階で言葉と図表にして関係者どうしですり合わせる作業です。制約の三角形の中心に置いたスコープを、最初に固めることが、残りのQCD（品質・コスト・納期）を検討する土台になります。

成果物ベースでスコープを記述する

スコープを記述するとき、最も避けたいのが「頑張る」「しっかりやる」「万全を期す」といった、行動の姿勢を表す言葉だけで済ませてしまうことです。こうした言葉は、達成できたかどうかを誰も判定できません。

本コースが推奨するのは、「成果物ベース」でスコープを記述する方法です。成果物とは、プロジェクトの過程や終わりに完成する、目に見える具体的な生産物を指します。「頑張って新商品を発売する」ではなく、「発売日までに、商品本体・パッケージ・プレスリリース・販促用のPOP・ECサイトの商品ページの5点を完成させる」というように、完成した状態で存在するはずのものを列挙します。

社内イベントの運営を例に、成果物ベースの記述を比べてみましょう。

記述の仕方	例
姿勢ベース（避けたい書き方）	「参加者に満足してもらえるよう、しっかり準備する」
成果物ベース（推奨する書き方）	「会場の確保、案内状の発送、当日の進行台本、受付名簿、アンケート用紙の5点を、開催日の1週間前までに完成させる」

成果物ベースで書くと、「何をもって完了とするか」が関係者の間で一致します。また、後述するWBS（作業分解構成図）を作るときにも、成果物をそのまま出発点として使えるため、レッスン3への橋渡しにもなります。

💡 ポイント スコープを記述するときの合言葉は「動詞ではなく名詞で終える」です。「準備する」「対応する」ではなく、「案内状」「進行台本」「受付名簿」のように、完成した状態の名詞で終わる書き方を意識してください。

受け入れ基準——「完了」の基準を言葉にする

成果物を列挙しただけでは、まだ足りません。「案内状」という成果物1つを取っても、A4サイズ1枚の簡素なものを想像する人もいれば、デザイン会社に発注した凝ったものを想像する人もいます。ここで必要になるのが「受け入れ基準」です。

受け入れ基準とは、ある成果物が「完成した」「合格した」と判断するための、具体的で検証可能な条件を指します。受け入れ基準を書くときのコツは、「誰が読んでも同じ判断ができる」ように、数値や具体的な状態で表現することです。

悪い例：「見栄えのよい案内状を作る」
良い例：「案内状はA4サイズ1枚、開催日・会場・持ち物・締め切りの4項目を明記し、部門長の確認を経て、開催日の3週間前までに配布する」

良い例では、サイズ・記載項目・承認プロセス・配布時期という、検証可能な条件がそろっています。これなら、誰が確認しても「基準を満たしているか」を同じように判定できます。

受け入れ基準を書く際の観点を、次の4つにまとめておきます。

形式：サイズ、フォーマット、提出方法など
内容：盛り込むべき項目、含めてはいけない項目
承認プロセス：誰の確認・承認を経るか
期限：いつまでに完成させるか

📝 補足 受け入れ基準は、成果物1つひとつに細かく書きすぎると、かえって作成の手間が膨らみます。プロジェクトの規模に応じて、重要な成果物（関係者間で認識がズレやすいもの、外部に公開されるもの）に絞って丁寧に書き、軽微な成果物は簡潔に済ませる、というメリハリが実務的です。

MoSCoW——優先度を4段階に分類する

スコープに含める項目が固まってきたら、次はその中の優先度をつけます。プロジェクトの現場でよく使われるのが「MoSCoW（モスクワ）」という優先度分類です。MoSCoWは、次の4つの英単語の頭文字を並べた語呂合わせです。

Must have（必須）：これがなければプロジェクトの目的が成立しない項目
Should have（重要）：あったほうが望ましいが、なくても目的は成立する項目
Could have（あれば良い）：余力があれば取り組みたい項目
Won't have（今回は対象外）：今回のプロジェクトでは意図的に扱わないと決めた項目

社内イベントの運営を例にすると、次のような分類になります。

分類	例
Must have	会場の確保、参加者への案内、当日の進行
Should have	参加者アンケートの実施、記念写真の撮影
Could have	参加賞の用意、SNSでの告知
Won't have	会場での生配信、外部メディアへの取材依頼

MoSCoWの効果は、「Must have」を明確にすることで、後から時間や予算が足りなくなったときに、真っ先に削るべき項目（Could haveから優先的に削る）と、絶対に死守すべき項目（Must have）を、あらかじめ関係者間で合意しておける点にあります。プロジェクトが佳境に入ってから優先度をめぐって対立するよりも、余裕のある初期段階で合意しておくほうが、はるかに冷静な判断ができます。

⚠️ 注意 経験の浅いチームほど、「Must have」に項目を詰め込みすぎる傾向があります。すべてが必須になってしまうと、優先度をつけた意味がなくなります。目安として、Must haveは全項目の半分以下に収めるよう意識してください。

新商品の発売プロジェクトでも、同じ枠組みを当てはめてみましょう。

分類	例
Must have	商品本体の製造、法令上必要な表示・許認可、主要取引先への納品
Should have	パッケージデザインの刷新、プレスリリースの配信
Could have	インフルエンサーへのサンプル提供、記念キャンペーンの実施
Won't have	海外市場向けの展開、姉妹商品の同時発売

先ほどの失敗例に照らすと、「発売日に主要取引先の店頭に商品が並んでいること」がMust haveであるという認識を、製造部門と営業部門があらかじめ共有できていれば、物流のリードタイムを逆算して製造スケジュールを組むことができたはずです。MoSCoWは、優先度をつけるだけでなく、部門をまたいだ認識のズレをあぶり出す道具としても機能します。

スコープクリープ——気づかないうちに範囲が広がる現象

スコープを固めても、プロジェクトが進むにつれて、少しずつ範囲が広がってしまうことがあります。この現象を「スコープクリープ」と呼びます。クリープとは、じわじわとにじみ出るように広がることを意味する言葉で、1つひとつは小さな追加であっても、積み重なるとプロジェクト全体の負荷を大きく押し上げます。

スコープクリープが起きる典型的なパターンを見てみましょう。

善意の積み重ね：「ついでにこれもやっておこう」という担当者の善意が、気づかないうちに作業量を増やす
声の大きい要望への対応：一部の関係者からの強い要望に、その都度個別に応じてしまう
境界の曖昧さ：スコープの記述が姿勢ベースのままで、どこまでが範囲内か誰も明確に判断できない
変更を記録しない習慣：口頭でのやり取りだけで小さな変更を積み重ね、誰も全体像を把握できなくなる

先ほどの社内イベントの例で考えてみましょう。「参加賞の用意」というCould haveの項目に、「せっかくだから豪華にしよう」「もう1種類追加しよう」と、担当者の善意で少しずつ手が加わっていく——これがスコープクリープの典型です。1つひとつの追加は数千円、数時間の話でも、10個積み重なれば、当初の予算と工数を大きく超えてしまいます。

🔰 初学者の方へ スコープクリープは、悪意によって起きることはほとんどありません。むしろ、「もっと良くしたい」という前向きな気持ちから生まれることが多いのが厄介な点です。だからこそ、次に説明する「変更管理プロセス」という仕組みで、善意の追加であっても一度立ち止まって記録する習慣が必要になります。

変更要求と変更管理プロセス

スコープクリープを防ぐ最も有効な手段は、「変更をなくすこと」ではなく、「変更を記録し、影響を確認してから反映すること」です。この一連の流れを「変更管理プロセス」と呼び、個々の変更の申し出を「変更要求」と呼びます。

変更管理プロセスの基本的な流れは、次の4つのステップです。

起票：変更を思いついた人が、その内容と理由を簡潔に書き残す
影響評価：その変更を受け入れた場合、スケジュール・予算・ほかの成果物にどのような影響が出るかを確認する
承認判断：影響評価をもとに、変更を受け入れるか、見送るか、次回以降に持ち越すかを決める
反映：承認された変更を、スコープの記述やWBSに反映し、関係者に共有する

このプロセスの本質は、変更を止めることではなく、「思いつきレベルの変更」と「影響を確認したうえでの変更」を区別することにあります。次のような簡易的な変更要求の記録表があれば、規模の小さいプロジェクトでも十分に運用できます。

起票日	変更内容	起票者	影響（スケジュール／予算）	判断
6月3日	参加賞をもう1種類追加	総務担当	予算+2万円、作業+2時間	承認（予算内で吸収可能）
6月10日	会場を大ホールに変更	企画担当	予算+15万円、会場調整に1週間	見送り（予算超過のため）

このように記録しておけば、「なぜ予算が当初計画より増えたのか」を後から説明する場面でも、根拠を示すことができます。

📖 もっと詳しく 大規模なプロジェクトでは、変更要求の承認を専門の会議体で判断する仕組みが整備されることもあります。小規模なプロジェクトであれば、プロジェクトの責任者が変更管理表を確認しながら都度判断する運用で十分機能します。プロジェクトの規模に応じて、必要な重さの仕組みを選ぶという発想が重要です。

変更管理プロセスを運用するうえで、もう1つ意識したいのが「誰が承認するか」をあらかじめ決めておくことです。承認者が明確でないと、変更要求が起票されても、判断が宙に浮いたまま放置されがちです。小規模なプロジェクトであれば、プロジェクトの責任者1人が承認者となる運用で十分です。予算やスケジュールへの影響が大きい変更については、あらかじめ「予算3万円を超える変更は、上長の確認を得てから承認する」のように、金額や影響度に応じた承認ラインを決めておくと、判断のたびに迷わずに済みます。

スコープと変更管理のよくある失敗パターン

最後に、スコープと変更管理でつまずきやすいパターンを、3つ整理しておきます。

口約束だけで進める：会議での「じゃあそれでいきましょう」という一言だけで変更を進め、記録に残さない。後になって「言った・言わない」の水掛け論になる
善意の担当者に判断を委ねすぎる：現場の担当者が「これくらいならいいだろう」と、変更管理プロセスを通さずに独自の判断で作業を追加してしまう
変更管理表を更新しない：変更管理表を作ったものの、日々の忙しさの中で更新が止まり、実態と乖離した「使われない書類」になる

これらのパターンに共通するのは、仕組み自体は正しくても、日々の運用の中で形骸化してしまう点です。変更管理表は、複雑な様式である必要はありません。むしろ、担当者が数分で記入できるシンプルな表にしておくことが、継続的に運用するための鍵になります。

プロジェクト計画書に書く7つの項目

ここまで扱った、スコープ・受け入れ基準・優先度といった内容を、実際にどう文書にまとめればよいのでしょうか。本コースでは、この文書を「プロジェクト計画書」と呼びます。プロジェクト計画書は、プロジェクトの立ち上げ段階で作成し、関係者の間で内容を確認し合うための文書です。

プロジェクト計画書に盛り込むべき項目を、次の7つに整理します。

背景と目的：なぜこのプロジェクトを行うのか、達成したいゴールは何か
スコープ（成果物と除外事項）：本レッスンで扱った成果物ベースの記述と、Won't haveとして明示的に除外した項目
マイルストーンと期限：プロジェクト全体の主要な区切りと、最終的な期限
体制：誰がどの成果物を担当するかの一覧（レッスン3のWBSと連動させる）
予算の枠：使える予算の上限と、大まかな内訳
品質基準・受け入れ基準：主要な成果物について、レッスン2で扱った受け入れ基準
主要な制約条件・前提：使える人員や設備の制約、外部要因への依存など、計画の前提となる事項

7項目それぞれに厚みを持たせる必要はありません。小規模なプロジェクトであれば、1〜2ページの簡潔な文書で十分です。重要なのは、これらの項目が「関係者の頭の中にしかない状態」から、「文書として共有できる状態」に変換されていることです。

プロジェクト計画書は、完成させてから配布して終わりではありません。作成の過程そのものに価値があります。7項目を1人で埋めようとすると、どうしても書き手の視点に偏ります。関係者を集めて一緒に埋めていく、あるいは書き手がドラフトを作ってから関係者にレビューしてもらう、といった進め方を取ると、プロジェクトの初期段階で認識のズレを洗い出す機会にもなります。レッスン1で触れた「後から関係者が『そんなことまでやるとは思っていなかった』と言い出す」事態は、この段階でのすり合わせを丁寧に行うことで、多くが未然に防げます。

💡 ポイント プロジェクト計画書は、一度作って終わりの文書ではありません。レッスン2で扱った変更管理プロセスを通じて、承認された変更があれば、その都度この計画書を更新します。プロジェクトの現在地を映す「生きた文書」として扱ってください。

まとめ

このレッスンでは、以下のことを学びました。

スコープは「姿勢ベース」ではなく「成果物ベース」で記述し、完成した状態を名詞で列挙する
受け入れ基準は、形式・内容・承認プロセス・期限の4つの観点で、検証可能な条件として書く
MoSCoWは、Must have・Should have・Could have・Won't haveの4段階で優先度を分類する枠組みである
スコープクリープは善意の積み重ねから起きやすく、変更を記録する仕組みが対策になる
変更管理プロセスは、起票・影響評価・承認判断・反映の4ステップで運用する
プロジェクト計画書には、背景と目的・スコープ・マイルストーンと期限・体制・予算の枠・品質基準・主要な制約条件・前提の7項目を盛り込む

次のレッスンでは、固めたスコープを実際の作業に分解する技術、WBS（作業分解構成図）を扱います。「新商品を発売する」という大きな成果物を、実際に手を動かせる単位の作業まで分解していく手順を学びます。

確認クイズ

このレッスンの理解度をチェックしましょう。