自分は世界を動かさないかも知れないけど
プロジェクトマネジメントに関する話題を検索していたら、以下の方のブログに引っかかりました。
プロジェクト・マネジメント、サプライチェーン、時間管理術といった多くの話題についてしっかりとした見解をお持ちで、内容が素晴らしいなと感銘しています。
タイム・コンサルタントの日誌から
そんな方が執筆された書籍で「世界を動かすプロジェクトマネジメントの教科書 ~グローバルなチャレンジを成功させるOSの作り方」というのがありまして、ぜひ読んでみようと思って購入しました。
若手社員が先生の手ほどきを受けてプロジェクトマネジメントを学んでいくというビジネス小説になります。レクチャー形式のおかげで流れが分かりやすく、今日からでも実践してみようと思わせてくれる内容です。
PMBOKを読んである程度実践してみようと思っていましたが、すべてを実践するには重すぎるわけです。そりゃぁ航空産業やオリンピックプロジェクトといった規模のプロジェクトマネジメントをも想定した知識体系ですから盛り沢山です。中・小規模の請負プロジェクトでは仰々しいので、テーラリングは必要なわけです。ただ全般的に理解はしないと下手なテーラリングによって意味が無い状態にもしたくないし、っていうところで悩んでいるときに、丁度よい内容でした。
決して世界を動かすプロジェクトではなく、単なる請負プロジェクトであっても、書籍の内容であれば実践できるんじゃないかと。
WBSは計画を立てるだけでなく、プロジェクト全体で一貫して扱うもの
という認識はあるのですが、見積もり時に作成してあとは放ったらかしにしていますよね。はい。
この書籍のほとんどはWBSに関する内容です。WBSでスケジュールと予算を立案し、それを使ってスケジュールと費用を監視し、コストと進捗をコントロールしていきます。WBSが全ての核となります。
全体の流れ
- 漏れなくアクティビティを抽出するために、「アクティビティマトリクス」を作成する
- クリティカルパス法で工期を計算するために、「プレシーデンスダイアグラム」を作成する
- 「積み上げ法」で全体のコストを見積もる
- WBSを「アップデーティング」して進捗を捉える
- 「コミットメント＋潜在的追加費用」でコストの着地点を予測する
- 「EVMS]でコストと進捗を同時にコントロールする
プロジェクト全体の流れのなかでのマネジメントの役割は上のような感じですが、とくに注目は「アクティビティマトリクス」ですね。要件モレやスコープの誤りといったことがあるとプロジェクトが破綻していってしまいますが、「アクティビティマトリクス」を作成すると、アクティビティがモレなく抽出できます。
「アクティビティマトリクス」を使い、成果物とプロセスの二軸でアクティビティを抽出する
WBSに挙げるアクティビティの抽出の見方として、成果物を洗いだしたF-WBS(Functional-WBS)とプロセスを洗い出したP-WBS(Product WBS)に分かれています。前者は「入出庫機能モジュール」「保管機能モジュール」「棚卸機能モジュール」「マスタ管理モジュール」といったサブシステム別にブレークダウンし、入出庫機能モジュールは、さらに「入庫」「出庫」「返品」といったサブモジュールにブレークダウンしていきます。後者は「要求分析」「設計」「実装」「テスト」「移行作業」というプロセスでブレークダウンし、「設計」はさらに「基本設計」「詳細設計」「実装設計」に分けていったりします。
わたしはF派、わたしはP派などという論争もあるようですが、本書籍では成果物とプロセスの二軸でアクティビティを抽出する「アクティビティマトリクス」を作成しましょうとしています。
すごーく簡単に書いてみました。
- プロジェクトが最終成果物に至るまでの「プロセスの構造図」をつくる
- プロジェクトの「成果物の構造図」をつくる
- 両者のマトリクスをつくる
さらに以下のように続く作業がありますが、ここでの記載は端折ります。
- マトリクスのマス目をグループ化して、適切なワークパッケージを形成する。
- マネジメントの分担を意識して、ワークパッケージに整理番号をふり、WBSに構造化する。
- 各ワークパッケージのインプット・アウトプット・必要なリソースをアクティビティリストに記述する（WBS辞書）
実際にはプロセスも成果物ももっとたくさんあるので、割と壮大なマトリクスになってしまいそうではあります。目的はプロジェクトの進捗と成果物を追いたいわけで、見積もり可能なところで留めなければならないですね。あまりにも詳細化するとだんだんチェックリスト化していき目的とかけ離れていきかねないわけで。
「プレシーデンスダイアグラム」を使い、実行可能なスケジュールを立てる
アクティビティリストを元に、スケジュールを組んでいくわけですが、先行・後続作業もあるし、並行で出来る作業もあります。大抵の開発案件はアクティビティが数十個や数百個になるわけで、何かしら図示しないとやってられません。書籍では「プレシーデンスダイアグラム」を用いたネットワーク図を紹介しています。
- 先行・後続と並行作業を意識してアクティビティを並べていきます。
- アクティビティ名の後ろにはアクティビティリストで設定した工数を括弧書きで明記します。
- 左から順に足し算で最早開始日と最早完了日を設定していきます。
- 右から順に逆算で最遅開始日と最遅完了日を設定していきます。
・・・なんか適当なアクティビティのお陰で、参考にならない程度な気もしますが、まぁいいでしょう。
フォワードとバックワードで日程を入れると、余裕日数が無いアクティビティが出てきます。これがクリティカルパスとなり、全体の納期になりますし、遅れると日程の遅れに直結してしまいます。ただ、実際にはアクティビティは大量にあるわけですので、このダイアグラムを手書きで起こすのは気が狂ってしまいます。やはりツールの手助けが必要です。なにかツールがあればご紹介くださいませ。