メモ

JPMFの設立発起人であるにもかかわらず、引退後は各種行事に出席したこともなかったが例会でコラボレイティブ・プロジェクト・サービス社(http://www.collaboproject.com/)の「構造化プロジェクトマネジメント」の講演があるというので興味を持って出かけた。プログラミング手法に「ストラクチャード・プログラミング」というのがあるので、これからパクッたネーミングかなと思ったらその通りで、この手法を提唱しているのはダブリンのETP（http://www.etpint.com/）のCEOのFergus O'Connel氏だそうである。マイクロソフト社の第2の開発拠点はダブリンにあり、アイルランドはITインダストリーが集積しているところだそうである。そのような背景からのネーミングらしい。そのうち「オブジェクト・オリエンテッド・プロジェクト・マネジメント」なるものを提唱する人がでてくるやもしれぬと思った。

構造化ウンヌンにこだわらなければPMBOKに比べて簡明で頭に入りやすい。

そのメッセージはプロジェクトマネジメントなど常識を持っている人ならだれでもできる。チョッと構造化してやればいいのだ。といって7つの常識的原則なるものを教えてくれる。いわく：
1.Keep it simple
2.Know what
3.Sequence of event
4.Things don't get down if people don't do them
5.Think what rarely turn out
6.Things either are or they ar'nt
7.Look from others
そして10段階のステップとポイントを教える。
1.Visualize the goal
2.Make a list of jobs
3.There must be one leader
4.Assign people to jobs
5.Margin for error/manage expectations
6.Use an appropriate leadership style
7.Know what's going on
8.Tell people what's going on
9.Repeat steps 1. to 8. until 10.
10.The prize

第5段階のポイントが印象的だった。計画を立てるとき、発注者の予算とか納期などのプロジェクトの制約条件を一応無視した計画を作り、それから制約条件との隔たりをどう埋めるか検討しなければならない。もし埋める手段がなければそのプロジェクトはmission impossibleである。プロジェクトマネジャーにアサインされそうな人は職を賭しても引き受けてはいけない。

それでも上司がおしつけてきたらどうすべきかとの質問がでた。上司が物事を理解できない場合しばしばそのようなことは生じるが、もしあなたに確信があるなら、たとえ別の人にその仕事がまわったとしても、引き受けるてはいけない。引き受けた人と上司が共同責任者となるだけである。もしこのような風潮が企業内に蔓延したら速やかにその企業とおさらばすべきでしょう。

桂離宮を作った造園家が引き受ける条件として出した、3項目、「金を出しても口を出すな」、「期限を切るな」、「金に糸目をつけるな」を発注者がのんではじめて桂離宮は完成したという逸話と一脈通ずる。