前に、プロジェクト計画書に書くことっていうのでＰＭＢＯＫの内容を書いた。
そこで、「実際にかく場合の問題とかは、べつに書きます」って書いた。
今日はその話。
実際に書く場合の問題は、以下のとおり
・プロジェクト計画書って、実際に書こうとしたとき、人によって書く内容が違う。
・プロジェクト計画書を書こうとしたとき、ＰＭＢＯＫのいったとおりにかけない点
→その時点では、決まっていないことがある
はじめの、「人によって書く内容が違う」例としては、日経システム構築 ２００５年２月号「のとはら先生の実践！プロジェクトマネジメント指南」の１４３ページがあげられる。
ここでは、（解答として）以下の項目を、プロジェクトマネジメント計画書として、書くこととしている。
１.プロジェクト目的
２.プロジェクト範囲
３.プロジェクト制約事項
４.プロジェクト全体作業フロー
５.プロジェクト成果物リスト
６.プロジェクト標準
７.アプローチ
８.プロジェクトスケジュール
９.プロジェクト必要資源
１０.プロジェクト体制
１１.プロジェクト予算
１２.プロジェクトリスク評価
１３.品質目標
１４.プロジェクトチーム目標
PMBOKの場合は以下のとおり（ここを参照）
あ・プロジェクト憲章
い・プロジェクトマネジメントの方法や戦略
う・スコープ記述書
え・ＷＢＳ（コントロールレベルまで）
お・（ＷＢＳに対する）コスト見積もり、スケジュール、責任分担
か・技術スコープ、スケジュールのベースライン、コストのベースライン
き・主要マイルストーンと目標期日
く・主要スタッフ、予想コスト、作業工数
け・リスクマネジメント計画書
こ・固有のマネジメント計画書
さ・未決課題と未解決事項
し・詳細資料
書く内容や順番、使っている言葉も違う。実際、書く内容も異なるところがある。
では、実際に両方を比較しながら、「ＰＭＢＯＫのいったとおりにかけ」るかどうか、みてみよう。
（あ）プロジェクト憲章（意味は、ここを参照）は、見せられない場合や、プロジェクト計画書作成時には、決まっていないことが多い。
だから、これは、のとはら先生のとおり、（１）プロジェクト目的と、（５）プロジェクト成果物リストで逃げたほうがいい。そこを突っ込んでくくる人はまずいないだろう。。
（い）は、のとはら先生の（７）に相当
（う）スコープ記述書と（え）ＷＢＳはこの時点でかけるなら、書いたほうがいい。かけない場合、のとはら先生の（２）、（４）のように、全体フローを「ぼやっと」書いて逃げる手もある。
（３）の制約は、入れておいたほうがいい（ＰＩＭＢＯＫで何で入ってないのかわかんないけど、（か）か（け）に入れるつもりかな？）
（６）は、のとはら先生、強調してたけど、ＰＭＢＯＫに明示されていない（（こ）が近いのかな？）。
現場的には、プロジェクト計画書を書く時点で、会社として、どういうドキュメントを書くか、決まっている場合は、その（決まっている）資料の書き方を添付（あるいはどこどこ参照と）明示しておけばＯＫな話。
でも、多くのケースで、ドキュメント標準やプロジェクト標準は、この時点では、かけない（もっと後で、走りながら決まる。それがいいことか、悪いことかは別として）なので、（６）は、「書ければ」の話。
のとはら先生の（８）から（１１）は、ＰＩＭＢＯＫの（か）から（く）みたいな感じでＯＫだと思う
リスク評価はどちらにも入っている。これは必要だと思う
品質管理とプロジェクトチーム目標はあるに越したことはないが、実際にはこの時点でかけないことが多い。これが書けないから、プロジェクト計画書がかけないとするくらいなら、この部分を書かないで、発行したほうがいいと思う。
ＰＭＢＯＫの（こ）から（し）も同様で、あるに越したことはないが、それが書けるのを待つくらいなら、適当な線で切って、プロジェクト計画書を発行したほうがいい。
この部分、かけなければ、なくても計画書として成立してしまうものだと思う。
ということで、現実的に書ける部分、書いておきたい部分をあげると、
(A)目的（当たり障りのない範囲）と、成果物（作成標準がある場合、それも明記）、
(B)作業範囲範囲と、その順番（わかる範囲で）、
(C)スケジュール、費用、体制、予算（わかる範囲で）、
(D)リスクと制約（どこが読みきれていないのか？）
(Z)戦略、アプローチ、品質目標などあれば、かいてもＯＫ
これだけそろっていれば、計画書としては、ＯＫじゃーないの、実際、ここしか見ないでしょ。みんな(^^;)
現実的には、あとは、会社の規約や、その道の権威の言うことに、フォーマットを合わせることになる（のとはら先生の流派なら、のとはら先生方式に、ＰＭＢＯＫでやるって会社が決めたなら、その流派で）。
つまり、「プロジェクト計画書に書かなくてはいけないこと」は、上の(A)(B)(C)(D)、それ以外は、省いても問題ない（流派によっては省く）ので、あとは上司に逆らわない程度に、でっち上げて書くというのが現状だとおもう。
少なくとも、「こう書かないとプロジェクト計画書は成立しない！」と主張しているのは、上司とか、現場から離れている人で、現場的には、(A)(B)(C)(D)が決まっていれば、あとは、どーでもいいことだと思うよ！
そこで、「実際にかく場合の問題とかは、べつに書きます」って書いた。
今日はその話。
実際に書く場合の問題は、以下のとおり
・プロジェクト計画書って、実際に書こうとしたとき、人によって書く内容が違う。
・プロジェクト計画書を書こうとしたとき、ＰＭＢＯＫのいったとおりにかけない点
→その時点では、決まっていないことがある
はじめの、「人によって書く内容が違う」例としては、日経システム構築 ２００５年２月号「のとはら先生の実践！プロジェクトマネジメント指南」の１４３ページがあげられる。
ここでは、（解答として）以下の項目を、プロジェクトマネジメント計画書として、書くこととしている。
１.プロジェクト目的
２.プロジェクト範囲
３.プロジェクト制約事項
４.プロジェクト全体作業フロー
５.プロジェクト成果物リスト
６.プロジェクト標準
７.アプローチ
８.プロジェクトスケジュール
９.プロジェクト必要資源
１０.プロジェクト体制
１１.プロジェクト予算
１２.プロジェクトリスク評価
１３.品質目標
１４.プロジェクトチーム目標
PMBOKの場合は以下のとおり（ここを参照）
あ・プロジェクト憲章
い・プロジェクトマネジメントの方法や戦略
う・スコープ記述書
え・ＷＢＳ（コントロールレベルまで）
お・（ＷＢＳに対する）コスト見積もり、スケジュール、責任分担
か・技術スコープ、スケジュールのベースライン、コストのベースライン
き・主要マイルストーンと目標期日
く・主要スタッフ、予想コスト、作業工数
け・リスクマネジメント計画書
こ・固有のマネジメント計画書
さ・未決課題と未解決事項
し・詳細資料
書く内容や順番、使っている言葉も違う。実際、書く内容も異なるところがある。
では、実際に両方を比較しながら、「ＰＭＢＯＫのいったとおりにかけ」るかどうか、みてみよう。
（あ）プロジェクト憲章（意味は、ここを参照）は、見せられない場合や、プロジェクト計画書作成時には、決まっていないことが多い。
だから、これは、のとはら先生のとおり、（１）プロジェクト目的と、（５）プロジェクト成果物リストで逃げたほうがいい。そこを突っ込んでくくる人はまずいないだろう。。
（い）は、のとはら先生の（７）に相当
（う）スコープ記述書と（え）ＷＢＳはこの時点でかけるなら、書いたほうがいい。かけない場合、のとはら先生の（２）、（４）のように、全体フローを「ぼやっと」書いて逃げる手もある。
（３）の制約は、入れておいたほうがいい（ＰＩＭＢＯＫで何で入ってないのかわかんないけど、（か）か（け）に入れるつもりかな？）
（６）は、のとはら先生、強調してたけど、ＰＭＢＯＫに明示されていない（（こ）が近いのかな？）。
現場的には、プロジェクト計画書を書く時点で、会社として、どういうドキュメントを書くか、決まっている場合は、その（決まっている）資料の書き方を添付（あるいはどこどこ参照と）明示しておけばＯＫな話。
でも、多くのケースで、ドキュメント標準やプロジェクト標準は、この時点では、かけない（もっと後で、走りながら決まる。それがいいことか、悪いことかは別として）なので、（６）は、「書ければ」の話。
のとはら先生の（８）から（１１）は、ＰＩＭＢＯＫの（か）から（く）みたいな感じでＯＫだと思う
リスク評価はどちらにも入っている。これは必要だと思う
品質管理とプロジェクトチーム目標はあるに越したことはないが、実際にはこの時点でかけないことが多い。これが書けないから、プロジェクト計画書がかけないとするくらいなら、この部分を書かないで、発行したほうがいいと思う。
ＰＭＢＯＫの（こ）から（し）も同様で、あるに越したことはないが、それが書けるのを待つくらいなら、適当な線で切って、プロジェクト計画書を発行したほうがいい。
この部分、かけなければ、なくても計画書として成立してしまうものだと思う。
ということで、現実的に書ける部分、書いておきたい部分をあげると、
(A)目的（当たり障りのない範囲）と、成果物（作成標準がある場合、それも明記）、
(B)作業範囲範囲と、その順番（わかる範囲で）、
(C)スケジュール、費用、体制、予算（わかる範囲で）、
(D)リスクと制約（どこが読みきれていないのか？）
(Z)戦略、アプローチ、品質目標などあれば、かいてもＯＫ
これだけそろっていれば、計画書としては、ＯＫじゃーないの、実際、ここしか見ないでしょ。みんな(^^;)
現実的には、あとは、会社の規約や、その道の権威の言うことに、フォーマットを合わせることになる（のとはら先生の流派なら、のとはら先生方式に、ＰＭＢＯＫでやるって会社が決めたなら、その流派で）。
つまり、「プロジェクト計画書に書かなくてはいけないこと」は、上の(A)(B)(C)(D)、それ以外は、省いても問題ない（流派によっては省く）ので、あとは上司に逆らわない程度に、でっち上げて書くというのが現状だとおもう。
少なくとも、「こう書かないとプロジェクト計画書は成立しない！」と主張しているのは、上司とか、現場から離れている人で、現場的には、(A)(B)(C)(D)が決まっていれば、あとは、どーでもいいことだと思うよ！
アクセス
トータル
ランキング
