しっかし、今回のエントリは誤植多いですな？他人のPC使ったかIME入れなおしたばかりか？とかなんとか云いながらなんとか読み終えたのは実務にチャレンジ中なのかモダンプロジェクトマネジメントについて素朴な感想を長々書き連ねた渡辺氏のこれのこと。
そういえばこんなん以前にもあったなぁと跳箱の過去ログをひっくり返したら去年の夏に（いまだ大きなお友達な）近藤氏がMPMを無駄に再発明した際に入れたこのツッコミで書いたんだった...。
Microsoft Projectも2007になって、ついにというか、やっとというかアンドゥが99回までできるようになった（めでてぇなぁ）記念に突っ込んでみるか。
渡辺氏は経営計画と開発計画のギャップ調整などとこじゃれたいい方していますが、なんのこっちゃない要求管理の段階からマネジメントできてない典型的なダメプロジェクトの話を延々しているだけです。てゆうか、渡辺氏が挙げたような机上の空論上塗り方式で塗り固められた"計画"なるものに計画と名乗ってほしくないです。（冗談抜き）
体系立てて勉強するにはPMIに入って（東京支部だけの会員にはなれないので日本人でもPMI本体にも入る必要がある）
を教科書に順序良くお勉強していくのが王道とは思いますが、そこまで手間かけられん、という向きは、
Vol.004は"要求→仕様"を「見える化」する!特集なので内容的にもちょうどよいだろうと。P28で中嶋氏が制約条件についてコラムを書かれておりますが、ここ、キモです。TOC=制約理論（The Goalで有名なやつ）を下敷きにして狭い紙幅でよくまとまっているので一読されたい。きっちり勉強されたい向きは、
など読むとよいでしょう。ネットで勉強したい方にはTOCの広場がお奨めです。
渡辺氏の事例なら基本であり基礎となるファンクションポイントをきっちり詰めて（跳箱はこれを素振り百万本と呼ぶ）徹底的に分解、リスト化（これが鬼ほど大事）してEVMすれば十分マネジメントできるはずです。ちなみに跳箱はUMLで文書化マンセーです。
で、コストモデルに落としこむための明細作りができたら次は日本情報システム・ユーザー協会のソフトウェアメトリックス調査報告などを参考に適正工数を把握して、自分たちの生産性と比較して明細リストにコストを貼り付けていく。
この部分もそうだし、システム規模（HWとかの）設計廻りもそうなんだけど、工数や規模等の変数を確定させるためのデータ集め（データの粒度、精度、計測条件ほか）と加工がへたくそなプロジェクトは運用に入ってから問題になるケース多いです。
要するによくわからんところ、あいまいなところが残らないように網羅的に徹底して突き詰めていけば、あとでしまったちゃんにならないで済むってだけの話です。
とても簡単。
ただし、やり抜ければ、ね。修行もしないで口先だけで世の中を渡っていこうとするタイプにはできないかもしれない。
ちなみに跳箱はなにか作り始める前に開発チームに対して、それはどんなものなのか、どんな背景があるのか、技術や規格の成立過程はどうなっていたのか、等々を網羅的に調べ上げて、各要素とその連携によってどのような効果が得られてそれは以前と比べてどうなるのかを記述したWhite Paperの作成をさせるようにしています。きちんと明示的に説明を記述できないところがあったら要するに理解し切れてない（こなしきれていない）ってことだし、コードとちがって普通のおっさんでも読めるし。
どうでもいいけど、渡辺氏は
NILSの担当パネルでもディスカッションテーマとして採り上げられないか調整
しているんだそうだがNILSなるイベントは人月の神話をネタに盛り上がれるような素人ばかりが参加しているイベントなのかね？てゆうか、渡辺氏自身、語れるほど経験もってなさげなところがなんですな。群盲象を撫でるのも一興か...。
小林氏のようなカネの亡者の関わるイベントに絡む話をするならプロジェクトリスクの定量把握に基づく金融商品化の可能性とかそういうもっと眉唾物で生臭い話のほうがいいんじゃないの？
そういえばこんなん以前にもあったなぁと跳箱の過去ログをひっくり返したら去年の夏に（いまだ大きなお友達な）近藤氏がMPMを無駄に再発明した際に入れたこのツッコミで書いたんだった...。
Microsoft Projectも2007になって、ついにというか、やっとというかアンドゥが99回までできるようになった（めでてぇなぁ）記念に突っ込んでみるか。
渡辺氏は経営計画と開発計画のギャップ調整などとこじゃれたいい方していますが、なんのこっちゃない要求管理の段階からマネジメントできてない典型的なダメプロジェクトの話を延々しているだけです。てゆうか、渡辺氏が挙げたような机上の空論上塗り方式で塗り固められた"計画"なるものに計画と名乗ってほしくないです。（冗談抜き）
体系立てて勉強するにはPMIに入って（東京支部だけの会員にはなれないので日本人でもPMI本体にも入る必要がある）
 | プロジェクトマネジメント知識体系ガイド第3版 A Guide To The Project Management Body Of KnowledgeProject Management Instこのアイテムの詳細を見る |
を教科書に順序良くお勉強していくのが王道とは思いますが、そこまで手間かけられん、という向きは、
 | PM magazine vol.004翔泳社このアイテムの詳細を見る |
Vol.004は"要求→仕様"を「見える化」する!特集なので内容的にもちょうどよいだろうと。P28で中嶋氏が制約条件についてコラムを書かれておりますが、ここ、キモです。TOC=制約理論（The Goalで有名なやつ）を下敷きにして狭い紙幅でよくまとまっているので一読されたい。きっちり勉強されたい向きは、
 | 時間に遅れないプロジェクトマネジメント―制約理論の応用共立出版このアイテムの詳細を見る |
など読むとよいでしょう。ネットで勉強したい方にはTOCの広場がお奨めです。
渡辺氏の事例なら基本であり基礎となるファンクションポイントをきっちり詰めて（跳箱はこれを素振り百万本と呼ぶ）徹底的に分解、リスト化（これが鬼ほど大事）してEVMすれば十分マネジメントできるはずです。ちなみに跳箱はUMLで文書化マンセーです。
で、コストモデルに落としこむための明細作りができたら次は日本情報システム・ユーザー協会のソフトウェアメトリックス調査報告などを参考に適正工数を把握して、自分たちの生産性と比較して明細リストにコストを貼り付けていく。
この部分もそうだし、システム規模（HWとかの）設計廻りもそうなんだけど、工数や規模等の変数を確定させるためのデータ集め（データの粒度、精度、計測条件ほか）と加工がへたくそなプロジェクトは運用に入ってから問題になるケース多いです。
要するによくわからんところ、あいまいなところが残らないように網羅的に徹底して突き詰めていけば、あとでしまったちゃんにならないで済むってだけの話です。
とても簡単。
ただし、やり抜ければ、ね。修行もしないで口先だけで世の中を渡っていこうとするタイプにはできないかもしれない。
ちなみに跳箱はなにか作り始める前に開発チームに対して、それはどんなものなのか、どんな背景があるのか、技術や規格の成立過程はどうなっていたのか、等々を網羅的に調べ上げて、各要素とその連携によってどのような効果が得られてそれは以前と比べてどうなるのかを記述したWhite Paperの作成をさせるようにしています。きちんと明示的に説明を記述できないところがあったら要するに理解し切れてない（こなしきれていない）ってことだし、コードとちがって普通のおっさんでも読めるし。
どうでもいいけど、渡辺氏は
NILSの担当パネルでもディスカッションテーマとして採り上げられないか調整
しているんだそうだがNILSなるイベントは人月の神話をネタに盛り上がれるような素人ばかりが参加しているイベントなのかね？てゆうか、渡辺氏自身、語れるほど経験もってなさげなところがなんですな。群盲象を撫でるのも一興か...。
小林氏のようなカネの亡者の関わるイベントに絡む話をするならプロジェクトリスクの定量把握に基づく金融商品化の可能性とかそういうもっと眉唾物で生臭い話のほうがいいんじゃないの？
