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

リアルのマネジメントでテンパッてるので、「プロマネ」の文字列を見るのもイヤ状態。ホントはこんなときこそ貪欲に学ばないといけないのにね …テヘ

ここでは、プロジェクトタイムマネジメントをまとめます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

keywords

• クリティカルパス計算問題のポイント
  
• 期間短縮
  
• 再見積もり
  
• クラッシング
  
• ファストトラッキング
  
• 資源平準化
  
• スケジュールマネジメント計画書
  

クリティカルパス計算問題のポイント

　所用期間を全部のパスについて計算する。リアルと異なり、試験ではそんなにたくさんのパスは出てこない。一番長いのがクリティカルパス。これを問う設問は「このプロジェクトを終わらせる最短の期間を求めよ」なのがイヤラシイ

　クリティカルパスは一本とは限らない

　クリティカルパスがダミーパスを通る場合もある。ダミーパスはタスク依存関係を示すための「時間ゼロ」のパスのこと

　前提条件の変化によって、クリティカルパスが変わることがある。その次の設問は、変わったあとのクリティカルパスで答えるのか、そうでないのかに注意。たとえば、問3の設問でクリティカルパスが変わったとする。

• 問4で「問3の条件で…」と書き出しているか?
  
• あるいは問3を読み直して「タスク○○が追加されたと仮定すると…」と書いてあるだけか?
  

私はよくここ↑で間違える…

＿|￣|○

　マイナスのフロート(スラック)もある。確かに俗語で「自由時間」という意味がある。しかし、フロート(float)とは金融用語で「信用買いや小切手振り出しの商取引と、実際の資金引き出しの間の期間」のこと。取引によってはマイナスもありうるでしょ、イロイロと…

　前提条件の変更でネットワーク図が変更されたら、プロジェクト終結日も自動的に変更されるか?　ぶっちゃけありえない。タスクの追加、見積もりの変更がされたら、先ずクラッシングやファストトラッキングで再調整を行う。その後にネットワーク図を変更するべし。

期間短縮(p.75)

　ものすごくありがちなのは「時間が足りないという事態」。いつもいつもいつもいつも時間が足りない。なんでだろ? これはPMPでも同じこと考えていてだいたい10問ぐらい出題される。みんな分かってるじゃん(w

　チョト注意したいこと。PMPでは「時間が足りないという事態」を招いた原因については、問わない。リアルだと、それこそ私が指摘せずとも皆様ご存知だろうが、PMPでは「そんなこと指摘しても仕方がない。それよりもなんとかする方法を実行しなさい」というスタンス。あるいは「予め過去の教訓を収集しておき、そうした事態にならないように事前に察知して先行的に(proactive)手を打ちなさい」という考え方。前向きだねぇ～。私はそれに「逃がすな！追え！そして奴らを高く吊るせ！」を付け加えておきたい。いえナニ、リアルでちょっとあったんでorz

　方法は3つ。再見積もりとクラッシングとファストトラッキング。コイツを使うシチュエーションは次の二つ。

• 計画プロセスで上司などから「プロジェクト期間が長すぎる。短くせい！」と指示があったとき
  
• 実行プロセスで(*)によりプロジェクトに変更が入り、期日に間に合わなくなりそうなとき
  

(*には好きな言葉を入れて遊んでね。書ききれないから)

　リアルとの違いがまざまざと出ているポイント。

問：(*)によりタスクBの期間が1週間延びる。どうする?
問：(*)によりコストで赤字が出そうだ。どうする?

　この選択肢に「チームメンバーに残業させる」「頑張ってなんとかする」「個々の能力を最大限に…」ぜんぶ間違い。プロマネに対し、誰かを残業させることや、頑張りを強いたりすることは求められていない。巷ではいまだに精神論でなんとかなると信じてるヴァカどもがいっぱいいる。セーシンも大事だよ、蔑ろにはしないよ、でもね、ダメなものはダメなのよ、分かる? 坊や… と言いたくなる厨房がまだいるよー　(シグマ計画のせいだと固く信じて、も少しガマンする)

　やべ、脱線しすぎ。PMBOKの基本スタンスは

• (予め)起こりうる変化を予想し、手を打っておく
  
• (もし起きたら)「ツールと技法」を用いて変化に対応する
  
• (それでもダメなら)代替案を検討し、提示する
  

　これだけ。個々のテクはタイムマネジメントとリスクマネジメントで出てくるが、この中に「メンバーに残業をさせる」がないことを指摘しておく(しつこく)。

タイムマネジメントの3つの技法を順番に説明する。

再見積もり
　よく使われる言葉だし、内容はあらためていう必要もないかもしれないけれど、その目的に注目してほしい。目的→リスク(特にリスクリスト第一位のリスク)を減らすため。「再見積もり」とは、予算であれ時間であれ、減らされた資源により増大したリスク(たぶん一位に急上昇しているだろう)を減らすために、減らされた結果を反映した見積もりをすること。

クラッシング
　目的はスコープを維持するため。つまり「求められる機能／仕様／サービス内容／製品」を欠けることなくお届けするために実施するテクニック。やることは以下の二つ。

• クリティカルパス上にないタスクから、コストやスケジュールを移動する。どこい移動するかって? クリティカルパス上のキモとなっているタスクに移動する
  
• プロジェクトの外側から、コストやスケジュールを補充する。どこに補充するかって? クリティカルパス上のキモとなっているタスクに補充する
  

　読めばすぐにピンとくるけれど、これは「人月の神話」、狼男を倒す銀の弾丸。コストやスケジュールは人の形をして補充されるため、まかりまちがうと火に油となることをお忘れなく。PMBOKもそのへん分かっていて、クラッシングはコスト増となる可能性アリと言っている(コスト増だけで済めばよいが…)。

ファストトラッキング
　目的は納期に間に合わせるため。やることは平行してタスクを実施するってことやね。本来であれば順番に実施することを先行してやっちゃうのだから、手戻りが発生することも考慮に入れる必要あり。
　PMBOKだと「設計が完了するまえにコーディング開始」とあるが、構造化設計なら機能単位、OO設計ならユースケース単位にコーディング開始も可能だから、よくある話。ここではテストと出荷作業を平行してやることを例として挙げよう。

　1.設計変更発生！
　2.ちゃっちゃと修正
　3.ちゃっちゃとテスト
　4.ちゃっちゃと出荷(デプロイとかtarとか)

　んで、3.と4.を平行してやることがファストトラッキング。起こりうるリスクは、3.でバグやデグレードを見つけた場合、4.はやり直しになる、ということ。4.にシワ寄せがくると、出荷ミスが起きうる(人の目には動かないシステムに見える結果を招く)。もう一度くり返す。ファストトラッキングは納期に間に合わせるために取る手段。間に合ったけど動かないコンピュータって、欲しいかの?

　例を挙げる。前出の練習問題2でいうと、

• タスクBのリソースをタスクGに振り向けることをクラッシング
  
• このプロジェクト以外からのリソースをタスクHに注ぐことをクラッシングという
  
• タスクHとタスクCを並行して行うことをファストトラッキングという
  
• タスクAとタスクFを並行して行うことをファストトラッキングという
  

振り向けられているタスクは全てクリティカルパス上のタスクであることに注意

　リタ本で「クラッシングの方がファストトラッキングよりもコスト高」と述べられている。激しく同意だが一部訂正→「クラッシングの方がファストトラッキングよりもはるかにコスト高」と。古典「人月の神話」を持ち出さなくても周知の事実。ヨソからリソースを持ってくるというクラッシングそのものがもつリスクはPMBOKでは一切述べられていないのが残念。

　むしろリアルではファストトラッキングが主流だろうなぁ …スコープだけはあやふやなくせに、納期と予算はキッチリ決定されていて変更不可なのがフツーだからな(w

資源平準化(p.76)
　資源を割り当てるときの考え方。資源はいつでも潤沢に調達できるわけではない。資源はまずクリティカルパス上に割り当てていく。ひと月あたりの割り当ては安定したレベルにする。安定した(sutable)レベルって? 無意味に多すぎないということ。

　これは、人月を置き換えると分かりよいかもしれない。プロジェクト期間が3ヶ月で資源が300人月必要であれば、ひと月100人突っ込めばよい　←正気か!? を問い掛けられるのであれば、「資源平準化」の考え方をリアルで知っているといえる。おかしいのは期間が3ヶ月なところ。いちどきに100人がフルパワーで周るワケがない。300人月も必要とするプロジェクトであれば、その期間を長くとって、資源を均(なら)す(慣らす)べきだろう。

　ではどれぐらい均されて(慣らされて)いればよいか? プロジェクトマネジメントソフトウェアは自動的に吐き出してくれるが、それが妥当かどうかを判断するには、やっぱり経験が必要。こればかりは M$-Project の結果を見る莫れ。

　資源平準化の経験則とは「少ない資源をまずクリティカルパス上にあるアクティビティに割り当てる」ということ。資源ベース技法とも呼ばれる。

スケジュールマネジメント計画書(p.78)
　スケジュールの変更を反映したスケジュールマネジメント計画書は、プロジェクト計画書(p.44)の一部である。p.44の「プロジェクト計画書策定のアウトプット」に戻る。

• 6.4スケジュール作成のアウトプット「スケジュールマネジメント計画書」は、6.5スケジュールコントロールのインプットとなっている
• 6.5スケジュールコントロール(コントロールプロセス)では、実績測定を行う。計画と実績の差を測るために、ベースラインが決まっていなければならないし、もちろん「どうやって実績を測るのか?」も分かっていなければならない。コントロールプロセスになって初めて決めていないか?
• スケジュール変更管理の方法は決まっているか? つまりスケジュールを変更しなければならないハメになったとき、どうすればよいか予め分かっているか? そんな事態になってやっとステークホルダー間の調整する …ということをやっていないか?

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