Home / 別館 Home / 仕事 / プロジェクトの進め方メモ

プロジェクトの進め方 メモ

●目次
  1. 立ち上げプロセス
  2. 計画プロセス
    1. 成果物と目標の明確化フェイズ
    2. タスクの定義フェイズ
    3. リソースの割り当てフェイズ
    4. 作業時間の見積フェイズ
    5. タスクの順序設定フェイズ
    6. プロジェクト計画の最適化フェイズ
    7. リソース負荷の調整フェイズ
    8. コスト見積フェイズ
    9. リスク特定と対応策策定フェイズ
    10. 基準計画フェイズ
  3. 遂行プロセス
    1. 実績情報の収集フェイズ
    2. 現状分析と変更管理フェイズ
  4. 終結プロセス
　参考文献リスト

　立ち上げプロセス

　プロジェクト遂行によってどのようなビジネスプランが実現されるのか、そのことによってどのような成果が期待されるのかを分析・評価する。
　プロジェクトが遂行に値すると判断できたら、正式に発足を認めた文書を発行する。

【Top】

　計画プロセス

　成果物と目標の明確化フェイズ

このフェイズでやるべきこと

　プロジェクトが作り出す成果物やサービスの機能、特徴を明確にする。
　プロジェクトの定量的な達成目標を明らかにする

【手順】
  1. スコープ記述書を作成する
  2. スコープ・マネジメント計画書を作成する
  3. Project : ファイルのプロパティにプロジェクト名、プロジェクトマネージャ名を入力する
  4. Project : サマリータスクを表示する
  5. Project : プロジェクトの開始日・終了日を設定する
  6. Project : プロジェクト・カレンダを設定する
  7. Project : プロジェクト・カレンダをスケジュール領域に表示する
【このフェイズで作成されるドキュメント類】 【このフェイズにおける MS Project での作業】

　スコープ記述書

【目的】
　プロジェクトの成果物と目標を明確にする。
　プロジェクトの成果物の内容や定量的な達成目標について、メンバ内で共通の認識を持つ。

【記載事項】
プロジェクトの目的
　プロジェクトの発足の理由を記述する。
プロジェクトの成果物
　プロジェクトの計画を行うために充分な詳細度で、プロジェクトの成果物（ないしサービス）の特徴を記述する。その際、プロジェクトの目的との関係や成果物によって解決される問題も記述する。
プロジェクトの中間成果物
　プロジェクトの成果物を完成させるために必要となる中間成果物をリストアップする。プロジェクトによって作成されるものであっても、中間成果物になり得ないものが特定できる場合は、それも明記する。
プロジェクトの定量的な達成目標
　プロジェクトが成功したかどうか判断するために、「コスト」「スケジュール」「品質」について、定量的な基準を具体的に示す。
制約条件
　プロジェクト遂行における制約条件をリストアップする。その際、制約条件の優先順位も明確にする。
　ex) 納期を最優先し、そのためには追加コストが認められる等。
仮定条件
　プロジェクトを遂行する上で、現実に起こると予想される条件をリストアップする。
　ex)機能追加の要望が発生する可能性がある等。

　スコープ・マネジメント計画書

【目的】
　スコープ記述書の内容が遵守できるよう、どのように管理するかを明確にする。
　プロジェクトの進行に伴い発生したスコープの変化に対して、どのような手順で変更するのかも明確にする。

【記載事項】
プロジェクト組織
　プロジェクトに関わる全てのメンバの関係を明確にするため、相関関係を階層構造等で記述する。
ステークホルダー間の命令系統、報告関係についても記述する。
スコープの安定度
　スコープ記述書に記載した事項が、どの程度の頻度で変更される可能性があるか、変更が発生した場合のコスト面への影響、スケジュールへの影響を記述する。
スコープ変更の識別方法
　スコープの変更について、「誰が」「どのような手続きで」識別するのかを記述する。また、変更が必要だと認識された場合、「誰が」「どのように変更内容について検討し」「変更による影響を分析し」「変更を決定するのか」を記述する。
スコープ変更の手順
　スコープの変更が決定された場合、「誰が」「どのような手順で」変更内容をプロジェクトに反映させるかを記述する。

　MS Project での作業

　基本的な設定

　ファイルのプロパティに「プロジェクト名」「プロジェクトマネージャ名」を入力する。

　サマリータスクの表示

【操作】
　ツール　→　オプション　→　表示　→　アウトラインオプション　→　プロジェクトのサマリータスク[ON]

　プロジェクトの開始日（終了日）の設定

【操作】
　プロジェクト　→プ　ロジェクト情報　→　スケジュールの基点　→　プロジェクトの開始日（もしくは終了日）

　プロジェクトカレンダの設定

【操作】
　（1）ツール　→　稼働時間の変更　→　新規作成
　（2）プロジェクト　→　プロジェクト情報　→　カレンダ

　タイムスケール領域への表示

【操作】
　書式　→　タイムスケール　→　非稼働時間　→　カレンダ名

【Tips】
　作成したカレンダを他のプロジェクトファイルでも使用できるよう、「グローバル・テンプレート・ファイル」にコピーしておく。
【操作】
　ツール　→　内容構成の変更　→　カレンダ　→コピー
※　ただし、カレンダオプションの指定まではコピーできない。
【Top】

　タスクの定義フェイズ

　このフェイズでやるべきこと

　プロジェクトの成果物を完成させるために必要な中間成果物を階層構造で洗い出す。さらにその中間成果物を完成させるために必要な作業（タスク）を階層構造で洗い出す。
　この階層構造（WBS:Work Breakdown Structure）の最下位は、一番小さな成果物を作り出すために必要な実際の作業になる。

【手順】
  1. 階層構造を記述する
  2. ワークパッケージをリストアップする
  3. WBSを検証する
  4. 作業を定義する
  5. MS Project : WBS を表示する
  6. MS Project : 定期的なタスクを設定する
  7. MS Project : タスクに特有なカレンダを設定する
  8. MS Project : タスクの成果物を記述する
  9. MS Project : タスクの責任者を記述する
  10. MS Project : その他の情報を記述する
  11. MS Project : タスクのリソース特徴を設定する
【このフェイズにおける MS Project での作業】

　階層構造

　階層構造については、下記を基準として考える。

基幹要素（レベル1）
　プロジェクトの中間成果物を設定するのが通常。
中間要素（レベル2以降）
　基幹要素を成果物ベースでブレイクダウンする。
ワークパッケージ要素（最下層）
　ブレイクダウンした最小の成果物を送出するための実際の作業。1人で作業した場合に90時間以下で完了できるレベルまでブレイクダウンする。実際に行う作業を記述することになるため、「●●を××する」と表現する。

　WBSの検証

　作成した WBS が、スコープ記述書に記述された成果物を完成できるような構成要素になっているかどうかを検証するため、以下の点についてチェックを行う。

　作業定義

　ワークパッケージに対して作業定義を行う。
　各ワークパッケージの成果物、作業手順について、割り当てられているリソースの認識をあわせる。

【内容】
タスクの成果物
　タスクによって作成される成果物を記述する。成果物が特定できないタスクは、無駄な作業の可能性があるので、本当に必要かどうかを検討する必要がある。
タスク遂行責任者
　タスクを行う責任者。この責任者がタスクの進捗状況について報告を行い、タスクのメンバに対して指示を行う。
タスクの作業内容、作業手順
　タスクの成果物を作成するための作業内容・手順を、タスクを行うメンバが理解できるように詳細に記述する。
タスク完了の判断基準
　タスクがどのような状態になった場合に完了したと判断するかの基準を記述する。
タスクの前提条件
　タスクを行う前提となる条件、制約、仮定等があれば、それを記述する。

　MS Project での作業

　WBS の表示

【操作】
　列の挿入　→　フィールド名　→　アウトライン番号

　定期的なタスクの設定

【操作】
　挿入　→　定期タスク　→　定期タスク情報

　タスクに特有なカレンダの設定

【操作】
　ツール　→　稼働時間の変更　→　新しいカレンダーを設定
　タスク情報　→　詳細　→　リソースカレンダを無視してスケジュールを作成[ON]

　タスクの成果物の記述

【操作】
　新しくテキストフィールドを作成し、そこに入力する。

　タスクの責任者の記述

【操作】
　新しくテキストフィールドを作成し、そこに入力する。

　その他のタスク情報の記述

【操作】
　タスクの成果物・責任者以外の作業内容、作業手順については、メモに入力する。

【Tips】
　ファイルを添付する場合、ファイルの内容の更新を反映する必要がある時は、リンクにする。
　タスクのリソース特徴を設定する
　例えば会議等、何人リソースをつぎ込んでも時間を短縮できない（と言うか、人が増えるほど会議時間は延びる傾向にありますけど(^^;）タスク等、タスクの性質基づいてリソースの特徴を設定する。
単位数固定
　期間、作業時間を変更してもリソース数を一定に保つように再計算する。
  • リソース数を変更すると、期間が再計算される。
  • 作業時間を変更すると、期間が再計算される。
  • 期間を変更すると、作業時間が再計算される。
作業時間固定
　期間、リソース数を変更しても作業時間を一定に保つように再計算する。
  • リソース数を変更すると、期間が再計算される。
  • 作業時間を変更すると、期間が再計算される。
  • 期間を変更すると、リソース数が再計算される。
期間固定
　リソース数、作業時間を変更してもタスク期間を一定に保つように再計算する。
  • リソース数を変更すると、作業時間が再計算される。
  • 作業時間を変更すると、リソース数が再計算される。
  • 期間を変更すると、作業時間が再計算される。
【Tips】
　問題の会議については、「期間固定」を選択し、「残存作業時間を優先するスケジュール方法」のチェックを外す。
【Top】

　リソースの割り当てフェイズ

　このフェイズでやるべきこと

　プロジェクトメンバが決定したら、命令系統、報告関係を示した組織図を作成する。
　メンバ内の情報流通のフローについて決定する。
　リソースにタスクを割り当て、メンバがいつからいつまで、どのような作業内容を行い、どの程度の負荷でプロジェクトに参加するかを明確にする。
　各ワークパッケージの担当者と責任分担を明確にし、状況報告等、タスクの状況報告を責任者に統合させるためにメンバ内の情報流通のフローについて決定する。

【手順】
  1. コミュニケーション・マネジメント計画書を作成する
  2. MS Project : プロジェクトメンバの情報を入力する
  3. MS Project : リソースカレンダを設定する
  4. MS Project : タスクにリソースを割り当てる
【このフェイズで作成されるドキュメント類】 【このフェイズにおける MS Project での作業】

　コミュニケーション・マネジメント計画書

【目的】
　プロジェクトを進める上で確実な情報伝達及び実績情報の収集を円滑にするためにメンバ内の情報フローを明確にする。
　情報配布のフロー、ドキュメンテーションの作成方法、進捗報告方法などを明確にする。

【記載事項】
報告に関する事項
　どのような情報を、誰が、いつ報告するのかを記述する。
文書に関する事項
　どのような文書を、誰が、いつ作成するのかを記述する。
保管に関する事項
　報告された情報や文書を、誰が、どのように保管するのかを記述する。
配布に関する事項
　作成された情報や文書を、誰に、どのような方法で配布するのかを記述する。
アクセスに関する事項
　保管されている文書を、誰が、どのような権限でアクセスできるのかを記述する。
コミュニケーション・マネジメント計画書の更新に関する事項
　コミュニケーション・マネジメント計画書の更新・改訂をどのようにして行うのかを記述する。

　配員計画書

　ワークパッケージにリソースを割り当て、メンバがいつからいつまで、どのような作業内容を行い、どの程度の負荷でプロジェクトに参加するかを記述する。

　MS Project での作業

　プロジェクトメンバの情報入力

　プロジェクトメンバの名前、単価、休日を設定する。

【Tips】
　部署・スキルをリソースのアウトラインコードに設定しておくと便利。
　タスクへのリソース割り当て

　実際の作業となる WBS の最下位レベル（ワークパッケージ）に当たるタスクにリソースを割り当てる。
　ただし、例外として、定期タスクだけは、サマリータスクにリソースを割り当てる。

【Top】

　作業時間の見積フェイズ

　このフェイズでやるべきこと

　各タスクを完了するのに必要な期間を見積もる。

【手順】
  1. 各タスクを完了するのに必要期間を見積もる
  2. MS Project : タスクの期間の入力
【このフェイズにおける MS Project での作業】

　作業時間の見積

　作業時間を見積もる際に参考値として以下の情報を利用して推測する。
  1. 過去のプロジェクト情報
  2. 市販の時間見積データベース
  3. プロジェクトメンバーの経験値
【冨倉メモ】
　ちょっとこれでは、科学的な手法とは言えないですね(^^;
　ちなみに、僕自身はこんな感じで見積もっています。
自分がやるとして簡単にできそうだと思うもの
　並行して他の作業を行うことも考慮して3日を設定
自分がやるとして、ちょっと難しそうだと思うもの<
　並行して他の作業を行うことも考慮して5日を設定
自分には絶対にできそうにないと思うもの
　神様なら10日でやってくれるかも(^^;

　MS Project での作業

　タスク期間の入力

【操作】
　表示　→　ツールバー　→　PERT 分析

【Tips】
　PERT 加重値の各重みの合計は「6」にする。
【Top】

　タスクの順序設定フェイズ

　このフェイズでやるべきこと

　タスクの相互関係を明確にし、タスクの作業順序を決定する。
　プロジェクトが進行する中で、目標が達成されているか確認するためにマイルストーンを設定する。

【手順】
  1. タスクの作業順序を決定する
  2. マイルストーンを設定する
  3. MS Project : タスク間のリンクを張る
【このフェイズで作成されるドキュメント類】 【このフェイズにおける MS Project での作業】

　プロジェクト・ネットワーク図

　タスクの階層構造ではなく、時間軸での順序に並び替える。相互関係については、以下を考慮する。
強制ロジック
　タスクの順序が選択の余地なく絶対的かどうかを検討する。
ex) タスク A の成果物を元にして タスク B を行う。
外部所与ロジック
　外部で発生する事象とのタスクの関係を検討する。
任意ロジック
　上記以外。

　マイルストーン

　遂行中のプロジェクトが目標を達成できるものになっているかどうかを検証するためのタスクを設定する。このタスクのことをマイルストーンと言う。
　マイルストーンは、ある成果物を送出する段階が終了し、次の成果物を送出する段階に進むことを意味する。
　プロジェクトが始まり、進捗管理を行うときには、マイルストーンのタスクで、できあがった成果物が次の段階に進める程度に完成しているかどうかをチェックする必要がある。

　品質マネジメント計画書

　プロジェクトの成果物（中間成果物も含む）の品質をどのように管理するかの方法を記述する。

　MS Project での作業

　リンク設定
　原則としてワークパッケージ同士にリンクを設定する。
　タスクの依存関係には下記のものがある。
終了・開始
　先行タスクが終了すると後続タスクが開始される。通常はこの設定。
終了・終了
　先行タスクが終了すると後続タスクも終了する。
開始・開始
　先行タスクが開始すると後続タスクも開始される。
【Top】

　プロジェクト計画の最適化フェイズ

　このフェイズでやるべきこと

　クリティカルパス上にあるタスクにリソースの追加投入などを行ってプロジェクトを期限までに終了できるよう調整するとともに、現実的なスケジュールになるよう、リソースの調整、期間の調整を行い、プロジェクトのスケジュール計画を完成させる。

【手順】
  1. クリティカルパスを確認する
  2. 期間の調整を行う
  3. MS Project : クリティカルパスを表示する
【このフェイズにおける MS Project での作業】

　クリティカルパス

　タスク間にリンクを張った結果、プロジェクトの開始から終了まで一貫したタスク群がある場合、それがクリティカルパスになっている可能性がある。
　クリティカルパス上にあるタスクを担当するリソースに、自分の作業の遅れがプロジェクト全体に影響するタスクであるとの共通認識を持たせる必要がある。

　期間の調整

　クラッシング（期間の短縮）

　クリティカルパス上にあるタスクに新たなリソースを追加したり、スキルの高いリソースと置き換えたり、残業時間、休日出勤を設定する等して期間を短縮する。
　ただし、全体としてみれば、即コスト増大につながることが多く、期間の短縮が必ずしも適切な代替案といえない。

ファストトラッキング（作業の前倒し）

　クリティカルパス上でのタスク間の依存関係にリードタイムを設定したり、依存関係を「開始・開始」「終了・終了」など後続タスクを前倒しにして行うようにする。
　期間の長いタスクを複数のタスクに分解し、並行して行えないか検討する。
　作業を前倒しにした場合、作業のやり直しが発生するなど、リスクが大きくなる。

　MS Project での作業

　クリティカルパスの表示

【操作】
　書式　→　ガントチャートウィザード　→　クリティカルパス[ON]

【Top】

　リソース負荷の調整フェイズ

　このフェイズでやるべきこと

　プロジェクトが現実的に実行できるよう各リソースの割り当て状況を調べ、過剰なスケジュールにならないよう調整する。

【手順】
  1. MS Project : リソースの割り当て超過を調べる
  2. MS Project : タスクの延期、リソースの追加投入等を行い、リソースの負荷を調整する
【このフェイズにおける MS Project での作業】
【Top】

　コスト見積フェイズ

　このフェイズでやるべきこと

　リソースコスト、固定コストを勘案して見積もったプロジェクトの総コストが、プロジェクトの予算以内に納まっているか分析し、コストの調整を行う。

【手順】
  1. MS Project : 固定コストを入力する
  2. MS Project : タスクの合計コストを確認する
  3. コスト・マネジメント計画書を作成する
【このフェイズで作成されるドキュメント類】 【このフェイズにおける MS Project での作業】

　コスト・マネジメント計画書

　コストの変更に対応する手順を記述する。

　MS Project での作業

　固定コスト入力

【操作】
　表示　→　テーブル　→　コスト　→　固定コスト

　タスクの合計コスト

【操作】
　ガンチャート　→　表示　→　テーブル　→　コスト

　コスト・マネジメント計画書の添付

【操作】
　プロジェクトのサマリータスクのメモにコストマネジメント計画書を添付する。

【Top】

　リスク特定と対応策の策定フェイズ

　このフェイズでやるべきこと

　プロジェクトの不確実な部分について、予防策や対応策を策定する。

【手順】
  1. リスクを特定する
  2. 各リスクの発生確率と影響を分析し、対応すべきリスクと無視するリスクを識別する
  3. 予防策と発生時対策を策定する
  4. リスク・マネジメント計画書を作成する
  5. MS Project : リスク管理用テーブルを作成する
【このフェイズで作成されるドキュメント類】 【このフェイズにおける MS Project での作業】

　リスク特定

　スコープ記述書の仮定条件は、重大なリスクになる。
　それ以外のリスクを洗い出すために、各ワークパッケージについて想定されるリスクを洗い出す。

　発生確率と影響分析

　以下の項目について記述する。
発生確率
　リスクが発生する確率について、0〜100％で記述する。
影響
　リスクが発生した場合の影響について、1（ほとんどなし）〜5で記述する。
リスクバリュー
　発生確率×影響
　これを元に以下の基準に従って判断する。
確率50％以上　かつ　影響2以下　：　適宜判断
　リスク毎にどのような対応をするか決定しておく。
確率50％以上　かつ　影響3以上　：　予防対策及び発生時対策
　リスクが発生しないためにどのような予防策を行うか決定する。その上で、発生時の対策も決定しておく。
確率50％以下　かつ　影響2以下　：　無視
　リスクに対する対応は行わない。
確率50％以下　かつ　影響3以上　：　発生時対策
　発生時の対策を決定しておく。

　予防策と発生時対策の策定

　予防対策

　リスク原因となる事象をリストアップし、リスクの発生を予防するための対策を策定する。予防策はプロジェクトのタスクとして、スケジュール上に追加する。

　発生時対策

　リスク発生時にどのような対応をするのかを策定し、リスクが発生したと判断するトリガーポイントを決定する。

　リスク・マネジメント計画書

【目的】
　どのようなリスクがあり、それを回避するためにどのような予防を行うか、発生した場合の対応方法について明確にする。
　リスク管理の責任者が、リスク発生を認識する方法も明確にする。

【記載事項】
リスク管理の責任者
　各リスクに対する発生判断及び対応の責任者を決定する。
発生確率及び影響
　発生確率及び影響に基づくリスクバリューを記載する。
予防策及び発生時対策
　予防策及び発生時対策の実施管理方法を記載する。

　MS Project での作業

　リスク管理用テーブル作成
【操作】
  1. フィールドのユーザ設定
  2. リスク事象（テキストフィールド）、発生確率（数値フィールド）、影響（数値フィールド）、リスクバリュー（数値フィールド）
  3. リスクバリュー　→　属性のオプション　→　式　フィールド名　→　番号・ユーザ番号の設定　→　発生確率×影響
  4. フィールドのユーザ設定　→　タスクとグループサマリー行の計算　→　式を使う
  5. 表示　→　テーブル　→　その他のテーブル　→　新規作成
  6. テーブルの定義　→　テーブル名　→　メニューに表示する
  7. フィールド名　→　テーブルに表示するフィールドを選択
【Tips】
　作成したテーブルを他のプロジェクトファイルでも選択できるようにする。
　ツール　→　構成内容の変更　→　テーブル・フィールド　→　コピー
【Top】

　基準計画フェイズ

　このフェイズでやるべきこと

　プロジェクトをスケジュール面やコスト面、リソース面等から調整して最適化し、ステークホルダー間での合意が取れたら、基準計画として保存する。

【手順】
  1. スケジュール・マネジメント計画書を作成する
  2. 調達マネジメント計画書を作成する
  3. プロジェクト計画書を作成する
  4. MS Project : 基準計画を保存する
【このフェイズで作成されるドキュメント類】 【このフェイズにおける MS Project での作業】

　スケジュール・マネジメント計画書

　スケジュールに関する変更手順、進捗会議の方法、スケジュールの維持・管理方法について決定する。

【記載事項】
スケジュール変更の依頼、影響分析、承認方法
　スケジュールを変更する場合、「誰が」「変更に伴う影響を分析し」「その結果、変更を決定するか」を記述する。
進捗会議関係
　進捗会議の日程とそのメンバ、報告内容及び検討範囲を記述する。
スケジュールの管理方法
　スケジュールの進捗状況について管理を行う方法を記述する。

　調達マネジメント計画書

　外注、資材、追加人員等、リソースの調達の決定方法及び調達方法について記述する。

　プロジェクト計画書

　上記に加えて、スコープ記述書、スコープ・マネジメント計画書、コスト・マネジメント計画書等のプロジェクト・マネジメントに必要な文書とともに、首尾一貫したプロジェクト計画の書類としてまとめる。

【Top】

　遂行プロセス

　実績情報の収集フェイズ

　このフェイズでやるべきこと

　実績情報を収集し、プロジェクトの進捗状況を把握する。
　そのためには、コミュニケーション・マネジメント計画書で、必要な情報を収集できるよう、報告内容の統一、報告フローを明確にしておく必要がある。

【手順】
  1. MS Project : イナズマ線を設定する
【このフェイズにおける MS Project での作業】

　MS Project での作業

　イナズマ線の設定
【操作】
　プロジェクト　→　プロジェクトの状況報告日
【Tips】
　現在の日付にしておくと、今日実行すべきタスクがどれかわかりやすい。
【Top】

　現状分析と変更管理フェイズ

　差異分析

　プロジェクトの当初のスケジュール、コストと現状を比較してその差異を分析する。

　アーンドバリュー分析

　コストとスケジュールの両面からプロジェクトの進捗や効率を評価し、完了時のコストやスケジュールを予測分析する。
　基準コスト（BAC）を評価基準にし、実行予算（BCWS）、達成額（BCWP）、実績コスト（ACWP）を見て、数値的に分析する

【Top】

　終結プロセス

　教訓のまとめ

　プロジェクトが終了したら、次のプロジェクトに活かすために、プロジェクトに関する全てのデータを収集し、まとめて保存する。また、プロジェクトで得た教訓を明確にして文書化する。

【Top】

　最終会議

　最終会議では関わったメンバとの間でプロジェクトに関する知識を共有するために、以下の事項を話し合う。

スコープについて スケジュールについて 予算について 進捗管理について チームとして 依頼者、取引先、他部門との関係について その他

参考文献

Home / 別館 Home / 仕事 / プロジェクトの進め方メモ
とみくら　まさや（vzx01036@nifty.ne.jp） $ Date: 2003/12/29 $