・行き当たりばったりに手を付けるんじゃないよと
・ユーザが求めるものは何なのか（要求事項の収集）、そのためには何をすればいいのかをしっかり考える
・何をしなければいけないのか（＝スコープ）が決まるから、コストと納期の見積もりができる
・何をしなければいけないのか（＝スコープ）が決まるから、品質基準やテスト項目が決まる
・何をしなければいけないのか（＝スコープ）が明らかになっているから、リソース（人材割当）の計画ができる
・すべての計画はスコープから始まる
・ユーザの要求とスコープが乖離していると、どれだけ完璧なものを作っても、全く意味のないものを作っていることになる
・始めに定めたスコープは、もちろんプロジェクトの過程で変わることがある
・ただし不用意に変えるものではない、とPMBOKは明言する（→スコープ・クリープ）
・前述のように、コストやスケジュールやリソースの計画は、全てこのスコープを基準に練られている
・スコープを不用意に変化させることは、上記の計画を破綻させることになるからである
・スコープの見直しは十分な精査の上で行われるべきであるし、それによる影響度も考慮したうえで実行せねばならない
＜全体的な流れ＞
・要求事項を棚卸しする（要求事項の収集）
・今回のプロジェクトで何をやる/やらないを決める（スコープの定義）
・やると決めた要求事項の実現のために、やらなければいけないことをブレークダウンする（WBS＝スコープベースラインの作成）
・スコープベースライン＝WBS＋
＜計画プロセス＞
① スコープマネジメントの計画
・どうやって行くかのルールを決める
② 要求事項の収集
・ PMBOKにおける最重要プロセスの１つでは？めちゃくちゃ奥が深い
・ 特定済のステークホルダーのニーズを引き出し、要求事項を収集する
・ 有用な技法
・インタビュー＝関係者に直接聞く
・フォーカスグループ＝関係者を一堂に集め、聞き取り調査をする
・ファシリテーション＝フォーカスグループに近い
・ブレーンストーミング＝いわゆるブレスト
・ノミナルグループ＝ブレスト＋投票による優先順位付け
・マインドマップ＝ツリーやマップにしていく
・親和図＝バラバラに出したものをまとめていく
・多基準意思決定分析＝ディシジョンマトリックスを使う
・デルファイ法＝質問に回答させる→その意見に対する意見を集める→再度回答させるを繰り返すことで収束させる
・ アウトプットは、要求事項文書と、要求事項トレーサビリティマトリックス
③ スコープの定義
・収集したすべての要求事項のすべてがプロジェクトの対象になるわけではない
・やる/やらないを決め、文書化する
・アウトプットはスコープ記述書
・スコープ記述書には、作成する成果物、成果物の受け入れ基準、プロジェクトからの除外事項などを記載する
④ WBSの作成
・ やると決めたことを実現するために必要なことを要素分解し、階層構造に落としていく（WBS）
・分解した要素にはＩＤを振る（WBSコード）
・100%ルール＝WBSは過不足がないようにする。漏れなく、かつ、余分な作業が入らないように作る。
・ローリングウェーブ計画法＝段階的詳細化。将来作るものは現時点で分解できないことがある。
後に作るものの分解は上位レベルにとどめ、明確になったら徐々に分解していくこと。
・WBS辞書＝各要素の内容をより詳細に記述した補助文書
・ワークパッケージ＝最下位階層のWBS要素のこと。これらに対して後でアクティビティを定義していく。
・アウトプットは、スコープベースライン＝スコープ記述書＋WBS＋WBS辞書
＜監視コントロールプロセス＞
⑤ スコープの妥当性確認
・顧客が、成果物が受け入れ基準を満たしているかどうかを確認するプロセス
・検収のこと
・これをパスすると、成果物が公式に顧客に受け入れられる
・顧客に見せる前に、我々が内部的に品質を満たしているかどうか検査をすることは「品質のコントロール」であり、別のプロセスである
・順番は、品質のコントロール→スコープの妥当性確認となる
・無事受け入れられたら、プロジェクトの終結プロセスへと繋がっていく
・アウトプットは、受入済成果物or変更要求のどちらかになる
⑥ スコープのコントロール
・ ベースラインと実態の差異を監視し、問題があれば変更要求する