第6章：プロジェクトタイムマネジメント(その1)

最近サボり気味なので、この連載待ってる人がいたらごめんなさい。
ここでは、プロジェクトタイムマネジメントをまとめます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

keywords

• スケジューリングのツール
  
• マイルストーンチャート
  
• フローチャート
  
• バー(ガント)チャート
  
• ネットワーク図
  
• スケジュール作成
  
• ネットワーク図
  
• アクティビティ・オン・ノード(AON) または プレシデンス・ダイアグラム法(PDM)
  
• アクティビティ・オン・アロー(AOA) または アローダイアグラム法(ADM)
  
• ガート(GERT)
  
• 依存関係
  

スケジューリングのツール(p.75-77)
　以下の通り、さまざまなツールがあるが、長短それぞれの特徴がある(もちろん試験に出る)

• マイルストーンチャート(p.78)
  
• フローチャート
  
• バーチャート/ガントチャート(p.78)
  
• ネットワーク図(p.77)
  

　試験の「出方」は、「○○の目的では上記リストのどれが適切か?」とか、「次の中で誤っているものを選べ… で、それぞれの適用例が並んでいる」という形式…例えば、

• それぞれのタスクの依存関係を明らかにするために
  
• 上司に主要成果物を報告するために
  
• 進捗度合いを追っかけるために、あるいはチーム内での報告のために
  

　…という具合に。それぞれの図の特徴そのまんまなので、解答は以下の説明を読む前に自分してみるといいかも。大切なことは、「このチャートを使う理由を明確にしておくこと」これはリアルでも一緒ですな。

マイルストーンチャート(p.69,p.78)
　マイルストーン(milestone)とは一里塚、あるいは歴史的重大事件のこと。ある大切なタスクが一区切りついたことを示す、しるし。例えば、プロトタイプβ版の完成予定日とか、承認された基本設計書の発行日付といった、モノの形をとることが多い。日付と主要成果物の一覧表ですな。

　重要なのは、「マイルストーンは期間を持たない」ということ。一区切りなので「期間」という概念はありません。プロジェクトの進捗管理を大局的掴み取るには、マイルストーンがきちんと達成できているかをチェックすればよい。プロジェクトを大局的にチェックしたい人→あなたの上司や、顧客のなかでもエライ人ですな。

フローチャート(p.98)
　それぞれの要素の依存関係、順序性、条件分岐を明らかにする図。UMLだとアクティビティ図もその一種だね。言葉よりもp.100の図8-3を見ればすぐ分かる。これは、特性要因図(p.98)と共に、品質計画プロセスで、品質問題がどこに発生するかを予測するために使われる。

バー(ガント)チャート(p.78)
　計画プロセスでは使えないツール。しかし、コントロールプロセスでの進捗報告には絶大なる力を発揮するツール。ありがちな出題としては、「次のうち誤りを指摘せよ」という設問で「ガントチャートを用いてスケジュール作成を行った」というやつ(誤り)。

　ガントチャートでは、依存関係のあるタスク間を、矢印や線でつなぐことがあるが(私はそうしている)、しなくても誤りではないことに注意。また、これは、タスクの進捗度合いを表すものであって、プロジェクトで行うタスクをまとめ上げるのはWBSやネットワーク図には及ばない。これもエライ人向け(マネジメント層)の報告で使われる。

　当然のことながら、ガントチャートを描くためには、

• どのタスクがあるのか(タスクが洗い出されている)
  
• それぞれのタスクの依存関係はあるか(依存関係と順序性が洗い出されている)
  
• スタートとエンドは、それぞれ何月何日か?
  

…が分かっていなければならない。従って、ガントチャートは、WBSとネットワーク図の作成が終わった後になって、ようやく描くことができる。ここも誤り指摘の問題に出る。

ネットワーク図(p.70)
　PERT,CPM,PDM… いっぱい出てくる。要はタスクの順序性を明らかにし、所要時間の見積もりをしたいだけなのにアフォほどでてきますな。リアルではUMLの状態遷移図みたいなネットワーク図を使ってるけれど、それで充分。こんなにツールは要らない。まさに試験のためのネタですな。ココの一長一短は後述するとして、全体としてのポイントとしては、

• 計画プロセスで作られ→使われる(6.2アクティビティ順序設定のアウトプット、6.4スケジュール作成のインプット)
  
• 計画プロセスでのクラッシングやファストトラッキングにおいて使われる
  

スケジュール作成(p.64)
　やるべきことは決まっていて、以下のステップが基本形

• どんな作業があるか洗い出し→WBS
  
• どの順番にこなす必要があるかを見極め→ネットワーク図
  
• どれぐらいの期間がかかるか見積もる
  

　だが、もっと具体的には、以下のインプットを要する(p.74)

• ネットワーク図
  
• アクティビティ所用期間見積もり：6.3アクティビティ所用期間見積もりプロセスのアウトプット、それぞれのアクティビティでどれぐらい時間がかかるか?
  
• 資源に対する要求事項：p.86どんな資源がどれぐらい必要となるか?
  
• 資源プール記述書：どんな資源が、いつ、どんな形で利用できるか?
  
• カレンダー：「○○日かかる」ことは分かっていても、それを実行する期間が年をまたがったら、スケジュールの差異がでてくる。あるいは土日を考慮して期間を見積もらなきゃいけない。根性で土日を含めた期間見積もりをする奴がいるけれど、まるっきり分かっていないか、過去の[たまたま]うまくいった実績を引きずっているだけ
  
• 制約条件(納入日、提出日、マイルストーン)
  
• 前提条件
  
• リードとラグ：リードは準備期間(leadtime)、ラグは遅延時間(timelag)のこと。リードの例→システム開発のための環境の準備として、インストール/セットアップに必要な期間。ラグの例→コンクリを打ってから養生させるのに必要な期間
  
• リスクマネジメント計画書
  
• アクティビティ属性：誰がその作業を行うのか? どこでその作業を行うのか? …で特に考慮が必要なもの。例えばある金属の合成が必要な作業として、それが無重力化でないとできないのであれば、その作業場所は限定されることになる
  

上記のインプットを元に、以下のことをすることがスケジュール作成という。

• 使えるリソース(人的資源含む)について、上司と相談。自分でマネジメントできるのであれば不要だが、人レベルの場合、そうもいかないこともあるし
  
• カレンダーレベルに落とし込んだスケジュール表を、チームメンバーに見せてみる。より実感のわく形で、できる/できないを検証できるから
  
• ステークホルダーとミーティングを行い、スケジューリングについて公式な同意を得る
  
• クラッシングやファストトラッキング、再見積もりにより、所用期間の短縮をはかる
  
• リスク対応計画書に基づき、プロジェクト計画書を再チェックする(←よく忘れる。リアルでも試験でも)
  
• モンテカルロ法を用いて所用期間をシミュレートする
  
• 資源平準化を行う。要は足りない資源をクリティカルパス上のタスクに割り当てること
  

ネットワーク図(p.69)
　ネットワーク図はどの順番でタスクが流れていくかを明らかにする。ネットワーク図により開始から終了まで、どのタスクがどのように流れていくかが明確化される。そして、個々のタスクの所要時間の見積もりが成されれば、開始から終了までどれぐらいの時間がかかるかが明らかになる。さらに、カレンダー日付をあてはめることにより、開始から終了までどれぐらいの期間になるのかが分かる。
　ネットワーク図を完成させるためには、WBSを完成し、アクティビティリストが必要。

アクティビティ・オン・ノード(AON) または プレシデンス・ダイアグラム法(PDM)(p.69)

　　AON:Activity-on-Node
　　PDM:Precedence Diagramming Method

　p.69図6-2を見ると、開始から終了までの間にA～Fの「箱」がある。この箱がタスクだ。つまり、それぞれのタスクをやる順番に並べて線でつないだものがAONでありPDMということ。「箱」をノード(Node)と呼んでいるから、アクティビティ・オン・ノードという名前。またはin order of precedence(順次に)という意味から、タスクを順番に並べたグラフ、即ち、プレシデンス・ダイアグラムという名前。ダミーは使わない。「ダミーって何?」という方は次の項目(アクティビティ・オン・アロー)の説明へどうぞ(p.70図6-3)。

　それぞれのタスクの依存関係は以下の通り。覚えろ

• 終了→開始(FS)：タスクは終了してなければならない、次のタスクが開始する前までには
  
• 終了→終了(FF)：タスクは終了してなければならない、次のタスクを終了する前までには
  
• 開始→開始(SS)：タスクは開始してなければならない、次のタスクを開始する前までには
  
• 開始→終了(SF)：タスクは開始してなければならない、次のタスクを終了する前までには
  

(S：Start、F：Finish)

アクティビティ・オン・アロー(AOA) または アローダイアグラム法(ADM)(p.70)
　　AOA:Activity on Arrow
　　ADM:Arrow Diagramming Method
　　AOL:Activity on Line　←他の呼び方

　ノード上にタスクがあるAONやPDMと異なり、矢印(arrow)の上にタスクがある。p.70図6-3を見ると、○(ノード)の間を結ぶ矢印の上にA-Fのアクティビティがある。破線はダミーアクティビティのこと。

○─A→○─B→○　という構造上、Aが終わってから(二つ目のノードにたどり着いてから)初めてBを開始することができる。即ち、この図は終了→開始(FS)の関係だけで構成される。

　p.70図6-3を使って、ダミーアクティビティの説明をする。この図そのものがプログラミングの工程と仮定しよう。B を設計・製造、C を単体(モジュール)試験とする。そしてDは試験環境の構築とする。製造したものを試験するのだから、B→C は明確な依存関係がある。製造・試験フローと、環境構築フローは、それぞれ別個にで流れているが、試験(C)を始めるには構築(D)が終わっている必要がある。つまり、環境を作って→初めて試験が始められる(FSの関係)。フローをまたがってこの関係を示すために、ダミー(破線)アクティビティが引かれる。ダミーアクティビティは所要時間ゼロ。依存関係を示すだけのものであると理解しておく。

ガート(GERT)(p.70)
　上に挙げた AON や AOA と違うところが唯一試験にでるポイント。つまり、「ループ(繰り返し)」と「条件分岐」が書けるというところ。

依存関係(p.68)
　結びつきの強さをうたったものだが、強い・弱いでええんちゃうと思っている。試験に出るので仕方なし、覚えておこうか。

• 強制依存関係：物理的依存関係、ハードロジック。設計もせずに製造に入ることができない、とか。
  
• 任意依存関係：選好ロジック、優先ロジック、ソフトロジック。できれば望ましい依存関係。
  
• 外部依存関係：順序性がプロジェクトの外部のアクティビティに依存している。Linuxで開発しましょうということは決まったが、肝心の Redhat-Linux が入手できてないなら、環境は作れないよね、という関係。
  

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PMP試験対策の目次に戻る
--