PMBOKとCCPMのおいしい関係(仮)

急遽 12/19(土)に発表を行うことになった/したので資料作り
http://www.atmarkit.co.jp/event/calendar/detail.php?event_id=50465

今回は .NET ラボで、マネジメント関係のお話をします。PMBOK の中で、スコープマネージメントを選びます。

ネタとしては、現在手書き段階

＜001＞

実は、このステップは現在 silverlight で作成することを構想中で、その設計図です。

プレゼン資料の作成も兼ねて書き下していきます。

■WBS項目の作成/編集

最初は、PMBOK的にトップダウンで始めます。これはスコープを決めるために作業領域を決めるためです。実は、この中にゴール（完成品）から決める、後順の方式もあります。CCPMで使うWBSを作るときには、この「後順」がいいので、実際はトップダウン、ボトムアップとは別に、完成品から部分工程へ下ろす、という作業になります。

ここで都合したWBSを眺めて、欠損部分がないか確認します。
当然、「検証」が必要なわけですが、この時点では正しい検証は無理です。経験上、トップダウンのWBS作成は、欠損が多く、甘い見積もりになりやすいものです（見積もりが倍増するのは、このあたりが理由）。

ただし、ここでWBSの正確性を上げるのは妥当ではありません。なぜならば、所詮、人間の考えることだから、悲観的に見れば見積もりが多くなり過ぎるし、楽観的に考えれば見積もりは少なくなりすぎる。そして、妥当性の基準もこの段階ではありません。

なので、どうせ無理であるならば、正確性を追求するよりも、経験と雰囲気/勘からWBSを作成します。

■PERT図へ落とし込み

WBSで各作業工程を決めたら、作業順序を決めます。
情報処理試験的には、PERT図は、日数を決めることを求められるのですが、ここではざっくりとした日数だけを決めます。なぜならば、WBSと同等に、妥当性を検証する手段がないからです。

なので、各作業工程にざっくりとした日数を割り当てます。既に決まっている日数（治験の試験期間など）を書いてもいいのですが、現作業では使いません。

それよりも、前後の作業工程が重要になります。つまり

・その工程の前提条件は何か？
・その工程では何を作るのか？次の工程は何か？

を重視して、前後の繋がりを検証します。
このようにして、はじめて、並列作業ができるところ、数珠繋がりにしかさぎょうができないところ、が決まってきます。

このとき、前後の工程で足りない WBS が出てきます。
つまり、WBS 項目の抽出作業の検証がここでできます。

■工程表に直す

さて、WBS（作業単体）、PERT図（工程の関連/リレーション）ができたので、時間軸を付けくわえます。ここでは、一般的なガントチャートを使います。

よく、ガントチャートのツールを前にして、各工程（WBSなど）や関連性を入力するツールがありますが、あれは間違いです。いや、間違いというか、いきなりガントチャートを書くのは無理です。
工程表/ガントチャートを作る前に、先の WBS と PERT図が出来てないければ、ガントチャートで時間軸を付けられません。

時間軸を加えるこということで、先の並列/直列な作業が割り振れます。
工程の日数はボトムアップ的にファンクションポイント法なので、設定してもよいのですが、「プロジェクトを期日内に完遂する」という目的が多いIT業界の場合には、どちらかといえば、完了日から逆算したほうが便利な場合があります。

ここで、

・実際に作業にかかる日数（ファンクションポイント法など）
・作業に掛けられる日数（工程表にて）

の２つの日数がでます。マイルストーンなどがあれば、この工程表に入れます。
そして、この２つの日数をすり合わせます。

近寄らないようであれば、どちらがが間違っています。

■工程表を修正する

これは手書きのノートにはないのですが、工程を作成したときのバッファの考慮します。いわゆる「保険」です。
安全性を考えた（未知のWBSや、見積もりミスなどを含める）場合に、このバッファを使いますが、CCPM（クリティカルチェーン プロジェクトマネージメント）では、プロジェクトバッファという手法を使います。

プロジェクトバッファの手法を使うときに注意しないといけないは、

・クリティカルチェーンを随時観察する。
・作業実績が随時観察できること。
・工程表が柔軟に変化できること。

が必須になります。
ここで、大抵のガントーチャート型のプロジェクト管理ツールは、工程表の引き直しが非常に手間です。ここの部分、アプリケーションの貧弱さにプロジェクト管理が引っ張られてしまうという「道具のまずさ」に関わってきます。道具に縛られるという感覚ですね。

なので、人間の頭にある感覚をツールに映し込めるという、道具が別途必要になります。

■進捗をマネジメントする

工程表に従い、進捗を管理します。このときに、各工程に遅れ/進みが入った場合は、迅速に工程表を修正します。あるいは、工程表を修正する手間が膨大であるならば、「クリティカルチェーンが変わらない限り工程表を修正しません」。

この２つは一見矛盾するように見えますが、実は、進捗管理のコストを考慮したものです。
つまり、管理コスト/マネジメントコストを考えたとき（金額に直した時に）、

・管理コストが非常に安く（プロジェクト費用の1割以下など）場合には、工程表を変えて、現実から未来像を再構成します。
・管理コストが非常に高い（プロジェクト費用の1割以上など）場合には、実績の監視を重視して、工程表とのずれを無視します。

現状では、「管理コストが高い」のが常です。これは、おそらく、ホワイトカラーの生産性の悪さに関わる問題なので、ここでは議論しませんが、ガントチャートを細々と弄っているのが進捗管理だと思っているのであれば、それは間違いです。そういう場合には、未来構成をするための予定工程表と、現実を把握するための進捗管理を別に行うのがよいのです。

で、本来は「管理コストを非常に安くする」のが、プロジェクト管理の理にかなっているので（と、ドラッカーも言っているよ）、このあたりのマネジメントを現状のIT業界は考え直す必要があるでしょう。

～～

ってな話を、.NETラボの勉強会でお話ししようと思います。興味がある方は土曜日にお会いしましょう。

申し込みは http://dn-lab.net/tabid/115/Default.aspx  から。
# 今回は人数が少なそうなので、飛び込みも歓迎です。

そんな訳で、プレゼン資料はこれから作るんだよ～。