スコープを明確に決めましたョ！その手順、間違ってますよ！
お疲れ様です、ゆーろー@常駐しないPMOです。
わたしがプロコンサルとして参加しているiPM naviのコラムをご紹介します。
writing by プロコンサル えのき
*このコラムはiPM naviでも配信しています
ITプロジェクトは、多くのメンバーが関わって一つのシステムを作り上げていきます。
その過程において、メンバーは作業を円滑に行うためにPMを含めたステークホルダーに質問や相談をするものです。
しかし、プログラム製造工程で『業務仕様』の質問が多発するITプロジェクトは、危機状態であると認識してください。
こんにちは、プロコンサルのえのきです。
iPMでは、PM初心者のスキルアップやDX時代に適応したいPMのリスキリングのサポートとして、iPM TRAININGを運営しています。
このコースの一つとして、『プロジェクト計画書の作り方』を講座として提供しています。
その中でも重要な部分な『スコープを明確にする手順』を、今回のコラムでWHAT・WHY・HOWの順番で解説します。
えのきのキャリア
2003年に大手コンサルファームにジョイン。
数年間のオープン系システムのインフラエンジニアを経験したのち、プロジェクトマネジメント関連業務へキャリアチェンジ。
以降中小から大規模までさまざまなプロジェクトにおいてPM/PMO業務に従事。
製造業、メディア、金融、官公庁など、業界を問わず経験しており、クライアントの様々な文化に柔軟に対応している。
近年ではシステム関連の知識を生かし業務コンサルテイング領域でも活動中。
WHAT：スコープの明確化とは
プロジェクトチームは、限られた時間の中でプロジェクトの目的を達成しなくてはなりません。
そのため、顧客の要求から『成果物』と『作業の実行範囲』を決める必要があります。
これがスコープを明確にするということです。
WHY：なぜプロジェクトのスコープを明確にするのか
PMは、プロジェクトの目的が明確になっても目的を達成させるために、プロジェクトの範囲に対して何をしなければならないのかを決めなくてはなりません。
これが決まっていないプロジェクトは、目的が達成できない延々と続くプロジェクトや炎上プロジェクトになります。
PMは、プロジェクトの目的をしっかりと理解したうえで、スコープを明確にしてください。
HOW：スコープの明確化を考える
こちらはプロジェクト計画書に記載する『スコープ』の事例です。
あなたは、以降のACTをしっかりと押さえてください。
【ACT1：顧客の要求事項の明確化】
ここでは、『対象業務』、『対象システム』を考えていきます。
その際、必要となるINPUT情報は、顧客から提供される作業範囲記述書になります。 PMは、顧客のビジネスニーズ、システムニーズを見つけ出して、対象業務とシステムと範囲を明確にしていきます。
また、プロジェクトによっては作業範囲記述書が準備されていない場合や曖昧な場合があります。
このような時は、PMが中心となって以下のことを行う必要があります。
・システム化範囲が曖昧な場合は調査する
・顧客の要求が将来的に有効なビジネスになり得るかを決定する
・顧客要求の優先度を決定する
🗒 メモ
顧客要求の優先度を決定する手順は、こちらのコラムが参考になります↓
作業範囲記述書は、プロジェクト開始前の企画工程において、顧客が準備するプロジェクトの作業範囲を定義した文書でです。
具体的には、顧客が以下を定義し文書としてまとめている。
プロジェクトの目標、成果物の取り決め、スケジュール、作業内容、役割分担、権限、投資効果...etc
この資料は、本来は顧客が準備するものですが、準備されていない、準備されているが漏れが多い、このような場合が多いものです。
そのため、プロジェクト計画の段階で開発チーム（上流工程が得意んアメンバー）で、顧客を巻き込み精査してください。
【ACT2：プロジェクト除外事項の明確化】
ここでは、『プロジェクトの対象外』を考えていきます。
その際、必要となるINPUT情報は、顧客から提供される作業範囲記述書になります。
PMは、プロジェクトにおいて顧客との要求齟齬（ビジネス要求、システム要求等）を防ぐために対象外となる作業を明確にしてください。
その時、PMは顧客の曖昧な要求を特定して、プロジェクトの範囲とするのかを決めてください。
【ACT3：プロジェクト成果物の決定】
ここでは、『プロジェクトの成果物』を考えていきます。
その際、必要となるINPUT情報は、作業範囲記述書、組織体の環境要因、組織のプロセス資源になります。
組織体の環境要因は、プロジェクトへ制約を与えるものを指すします。
顧客（または、あなたの所属する会社）のメンバーが不足しているので、外部の要員に頼らざる得ない状況など、顧客（または、あなたの所属する会社）では解決できない問題。
また、顧客（または、あなたの所属する会社）の方針などもプロジェクトを縛る要因となります。
顧客（または、あなたの所属する会社）の方針を無視してプロジェクトを行うことは出来ないが、ネガティブなものだけでなく逆に顧客（または、あなたの所属する会社）としてプロジェクトを支える仕組みもある。
PMは、このように利用できるもの、利用できないものを合わせて考える必要があります、
組織のプロセス資源は、顧客（または、あなたの所属する会社）が持っているナレッジやノウハウを指します。
例えば、過去のプロジェクトの資産・品質指標・社内の業務ルール等となります。
PMは、プロジェクトで決めたシステム範囲を対象に成果物を明確にしてください。
成果物はドキュメントといった書類もあれば、システムを動かすためのプログラムソース等が対象となります。
これらを成果物の一覧表として開発工程ごとに明確に整理してください。
【ACT4：WBSの作成】
ここでは、『プロジェクトの成果物』を整理します。
そのため、作業範囲記述書とWBSを使っていきます。
特に、このACTでは、どのような作業を行うのかWBSで作業を分解してください。
WBSはワークパッケージを洗い出し、作業順序を決めていきます。
また、WBSを作成することで抜け漏れしていた成果物も見つけ出すことができます。
抜け漏れしていた成果物は、成果物一覧に盛り込んでください。
🗒 メモ
WBSを作成するヒントはこちらのコラムを読んでください↓
プロジェクトのスコープを明確にするということは、対象業務、対象システム、成果物をきちんと整理し定義することは一般的なことです。
あなたも、プロジェクトで『これってやるの？』、『XXXX機能は実装しないから、やらないでしょ..』といった曖昧な場面を経験したことがあると思います。
実は、これはプロジェクト計画の段階で、顧客と『プロジェクト対象外』を明確にしなかったことによって、起こる事故なんです。
『プロジェクト対象外』もスコープの明確化の範囲であることを忘れないでください。
★★★ 45秒で分かるiPM navi ★★
無料メンバーの登録（こちら）
iPM naviの活用方法（こちら）
★★★ ぜひ、お立ち寄りください ★★
最後まで読んでいただき有難う御座いました。
お忙しい中、読んで頂き有難うございます。サポートは、今後のPM育成を充実させる活動と他のクリエイターへ還元していきたい考えています🙇♂️