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

| 固定リンク
コメント
読み応えのある内容でした。各章ごとにエッセンスが散りばめれてていました。書かれていることは分かるが、あとはいかに強い意志を持って実行するか。それが、優秀なPMに成れるかどうかの境目のような気がします。
問題に当たった時になんらかのヒントと勇気を与えてくれる本ですね。
投稿: タイガーのフォトリー日記 | 2005.02.02 22:43
ishi3 さん、コメントありがとうございます
非常に参考になる一方で、「頼り」にしちゃいけないな、とも思いました。これは著者の経験に裏打ちされたノウハウ集なのですが、あくまでも「ヒント」ですね。巷にあるマニュアル本のごとく扱うと酷い目に遭うんじゃないかと。
投稿: Dain | 2005.02.04 00:14
金融機関系大規模システムの移行には単なるハード切り替えからアプリのフルスクラッチまで(非常に幸運な事に(ーー;))何度か経験しています。
フルスクラッチは失敗しますね、十中八九...S後も2年は安定しません。眠れない日々は丸々1年続きますし、オリンピックイヤーは恐怖ですな。
ただ、悪い事ばかりでは無いですよ。一番良いのははヒトが育つ事。SIerもユーザーのシステム部門もBPも何もかも一度にスキルアップします。自分の周りにツワモノが一気に増えるので、その後の仕事はしばらく安泰です。
もちろんスキルアップするのはそういう素地を持ってたヒトだけですし、壊れるヒトも沢山出ます。そう言えば死人も出ましたね...。
さらに言えば、誰も使ってない不要部分が消えて無くなってくれる事は私的には一番嬉しい部分です。もちろん大事な部分も沢山消えて無くなってくれるわけですが...。
投稿: 鉛のZEP | 2005.02.04 23:26
鉛のZEP さん、コメントありがとうございます。
確かに、修羅場(デスマーチとは言いませんよ)をくぐることで技術的にも人間的にも一皮剥けますね。よりチャレンジングになる人もいれば、逃げ上手になる人もいます。ただ、壊れる人にはなりたくないですね…
これからは「いかに壊れないような負荷で人を育てるか(自分も育つか)」が課題になりそうです。この本の行間に埋まっている「人員の大量投入→修羅場→生き残りでプロジェクトを回す」やり方はもう勘弁なので。
投稿: Dain | 2005.02.06 10:49