3回読んだ。でかいプロジェクトのPMにとってはガイドラインとして最適(ただしメインフレーム更改・統合の超大型ITプロジェクトに限る)。言っていることはいちいち納得できるが、いかんせん古いので、香ばしいスメルも楽しめる一冊。
経験不足のPMがプロジェクトを任された時、何をどうしていいか途方に暮れる。あるいは何するかは分かっていても、力点が分からないため、やっぱり途方に暮れる。「とりあえず」引き受けて火傷したPMはたくさんいる。巨大プロジェクトだと発注側の命運すら左右する。まさに死活問題。
そんな新米PMに朗報なのがこの本。「決断する25の瞬間」と銘打っているが、ポイントは25以上ぎっしりと詰まっている。プロジェクトのどのタイミングで何をするべきなのか、というプロジェクトマネジメントの肝(きも)が分かる。
さらにリアルなのがウレシイ。PMBOKの無味乾燥な「知識体系」ではない。現場でのギリギリの決断や、「買うか作るか見捨てるか」といった生々しい選択方法が、著者の経験を元に惜しげもなく開陳されている。
ただし、この本の事例は古い…っつーか特殊ナリ。銀行の統廃合でじゃんじゃんバリバリPMしてる人なら、読むまでもない「常識」ばかり。その「常識」が普通のプロジェクトに通用するかどうかには疑問符をつけておく。
さらに、構造化設計マンセーなところ、クラスタリングすることで「性能を買う」といった発想が一切ないところ、「PMを取り替えればよい」といった、そもそも誰のための本なのかを忘れた発言は芳しいスメルを放っている。
「超大型プロジェクトをマネジメントするためには高度なスキルを要する」←この一文はあっちこっちで強調されている。「高度な」スキルを有する団塊世代からすると、イマドキのPMは頼りない←というホンネが透けて見える…が、「高度な」スキルとは何なのかといった能書きは無い。分かる、わかるよ、だって説明できないんだよもん。ぶっちゃけ正体をバラすと、
・超大型プロジェクトの見積もりスキル
・超大型プロジェクトのマスタプラン策定スキル
・超大型プロジェクトのリスクマネジメントスキル
…などなど
だから、皆がよ~く知っているスキルと同じなんだよね。「超大型」という形容詞が付くだけで。ン年前のマジックワード「オブジェクト指向」と同じ香りがする。
一方、「超大型」プロジェクトは、そうでないプロジェクトと全く違うことも確かナリ。金が莫大だとか、期間がかかるというよりも、端的に言うと、人柱が必要なプロジェクト。人月ではなく一本二本で数える」。一発勝負、失敗は許されない。うまくいってもいかなくてもニュースになるプロジェクト。PMはたいてい、「親分肌だが、根はマジメで小心者」が指名される。そのため、ストレスに文字通り潰されてしまう人もいる。そのへんのシャレにならない話は日コンでは書けないだろうが、直接お話を伺ったら面白いだろうなぁ…
その極意は、やっぱり実践で斬ったり貼ったりすることで身につけるしかない。激しく同感した部分を引用するが、痛い目に遭ったことが無い人ならスルーしてしまうだろう。例えば次の一文。
大きな既存システムがある場合、画面
・帳票を見ても既存機能の継承はできない。ましてユーザーから見えない機能は把握できず、理解の遠く及ばない状態が発生してしまう。大規模プロジェクトの既存機能継承は既存システムからの継承が大半であり、この作業を怠ると、プロジェクトは最初からやり直しになる危険性がある。ユーザーからの要求のみで新システムの仕様を確定させた場合は、既存機能の大半は継承されていないと認識すべきである
(下線は私)
ええ、ええ、もちろん知ってたよ。でも今は身にしみて理解してマス、痛いほど。やっぱ本を読むだけではあきまへんな
'`,、 ( ´∀`) '`,、
--
実践プロジェクトマネジメント――危機を乗り越える25の決断(岡村正司)
L
最近のコメント