プロジェクトマネジメントの実践的な知恵が沢山詰まった本 プロマネ失敗学

◎　プロマネ失敗学 あなたを成功に導く14事例の教訓


著者は、永らくNTTで活躍された拜原正人さん。


日経ITプロフェッショナルという雑誌への
「プロマネ失敗学」という2年間の連載記事を書籍化したもの。


著者は危機支援と呼んでいるが、
システム開発/導入などで暗礁に乗り上げそうなプロジェクトへの
自身でのサポートした14プロジェクトを事例にした説明が主体なので、
PMの教科書的な解説ではなく、
実践的な問題点の指摘、解決方法、
もっと早い時期での改善方法などが述べられている。


PM,PMを目指している人などには、
非常に素晴らしい手引書になると思う。


IT業界で言われている経験則のような話は、
開発者側だけでなく、依頼者側にも役立つのでは？


例えば、２−４−３という要求事項の大きさの変化。
始めは2程度の大きさだったお客の要求が、
段々大きくなり、倍の４になる。
でも開発者側は対応できないので、調整するが、
それでも３の1.5倍になってしまう。


２−６−２は、ITだけの話しではなく、
通常プロジェクトに参加するメンバーの
2割は非常に優秀で、
6割は普通で、
残りの2割が出来が悪い。
問題プロジェクトは、できの悪い2割のメンバーに注力すれば
改善できる。


20-80は普通のパレートの法則。
2割の品質の悪いプログラムが
8割の問題を引き起こす。
だから、品質の悪い2割を見つけ出して、
適切な対処をすれば、無駄な努力は大幅に軽減される。


事例、その後の解説でも出てくるが、
危機対策の始めに必要なことは
・全体俯瞰図の作成
・全体スケジュール表の作成
・ユーザ要求の切り分け/対応時期の確認
・適切なマネジメント体制の確立
など。


各事例での最終的なプロジェクトの解決案は”ステージング”。
著者はレベル１、レベル２と説明しているが、
これはステージングと言われて、
プロジェクト全体が失敗するよりは、
最低限機能で早めにサービス提供を実施し、
その後に追加機能として2回目のサービス提供をする。


これはユーザ要求を詳細に聞き取ると、
実際には遅い提供でも業務上問題ない、または少々の作業で対応できるなどがある。
これを後回しにさせてもらう対策だ。



5部にも書かれているが、
プロジェクト・マネージメントが教科書的になっていたり、
数字上のつじつまだけを追っかけていたりするで問題が発生する場合が多い。
スケジュール管理を全く実施していない事例があるが、
これは最近ではまれで、殆どのプロジェクトでは、スケジュール管理はしている。
しかし問題は、要件定義、設計、開発、テスト、導入と書かれているだけで
その中身を検証していない場合が多いことだろう。


システム開発・導入の標準化は進んでいるが、
教科書的、官僚的な対応だけで、
実際の中身が伴っていないことが問題。


プロジェクトは、その意味からして、
それぞれのプロジェクトは独特なはずなので、
標準化された開発・導入の規則だけに従っているだけでは
問題が起きるはずだ。


PMとかシステム開発系の人、またマネジメント系の仕事の人々には
お勧めの本です。



ただ、誰かのブログで、
何となく自慢ぽく読める部分があって、嫌だとの意見があった。
確かに、”筆者の経験では”とか”筆者ら危機支援チームは”という
主語が多く、少々鼻に付く。
日本語は、主語がなくても意味が通じるので、
この主語を読み飛ばすと、非常に読み易い。


少々書き直せば、非常に読み易く、売れる本だと思った。


また、プロジェクト・サポート開始時に
誰に、どのように、何を聞くのか、調べるのか、
どのように分析するのか、
などをまとめようと思ったが、
明確に書かれてなく、
ここに書き出せない。


この部分が分析、説明されていると、
素晴らしい知恵の本になると思う。


この辺を確認するために、
もう一回読み直さないと。



昔勤めて会社で、著者の拜原正人さんへ売り込みをしたことがあった。
NTTの部長にしては、本質論を問うてくるタイプで、気になる人でした。
時折、どうしているのかなと思っていて、
先日、どうしているのかと思って、検索したところ、
この本を発見したのが、
この本を読む切っ掛けでした。


本質を追及するタイプの方で、信頼も置けるし、
実践の知恵も多くお持ちだと思います。



追記：2012/6/16 気になる部分のメモ


11ページ

プロジェクトのドミナント・アイテムは、①プロジェクト規模、②プロジェクト開発期間、③ステークホルダーの特性、④契約形態、⑤開発やシステム、運用、権限の分散度合い、⑥技術の複合度合い------という6つに大きく分類できる。

14ページ

危機プロジェクトの再建を請け負う場合、筆者らは次の作業を行う。
まず、危機プロジェクトの現状を把握する。現状把握では、特にドミナント・アイテムの把握に重点を置いて、ドミナント・アイテムの危機への関与度を分析する。
次に、ユーザー企業およびITベンダーと話し合いながら、緊急復旧のためのレベル１サービスの条件を設定するとともに、危機要因を特定する。
最後に、短期復旧のための危機要因の修復を含めたクライシスマネジメントを実施。」さらに定常復旧のためのプロジェクト再整備を支援する。

17ページ

プロジェクト・マネジャーにとって重要なキーワードである「俯瞰」について紹介する。
プロジェクト・マネジャーは、プロジェクトに対する全体像とプロジェクトの死命を制するような問題（ドミナント・アイテム）を的確に把握し、対処する必要がある。いわゆる「木を見て森を見ず」の過ちを犯さないために、プロジェクト内部（渦の中、主観、一人称）とプロジェクト外部（渦の外、客観、他人称）を行き来できなければならない。

62ページ

プロジェクト危機支援の成否の8割は、危機支援当初に危機感を喚起できるか、あるいは共有できるかで決まるのである。

65ページ

必要な作業をブレークダウン
最後に、このプロジェクトへ危機介入した時点で、ヒアリング結果に基づいて筆者ら支援チームが作成した危機診断チェック項目表を紹介しておこう（次ページの表3）
この表は、危機脱出に必要な作業をブレークダウンして表したものである。「システム品質向上」、「性能改善」、「残存仕様検討課題」、「科学技術計算・販売在庫管理連携テスト」、「移行計画」などの大項目に始まり、中項目、小項目、作業項目へと、必要な作業をブレークダウンしている。作業項目には、作業項目名、作業実施担当者名、作業終了期日、求められる作業結果なども具体的に記述した。

67ページ

当初計画にこだわらない

テスト期間の短さは、プロジェクトにとって致命的となる。あらゆる要素を考慮した上で、十分な長さのテスト工程を確保しておくべきである。

72ページ

Y氏の状況説明はあいまいだったが、プロジェクトの危機の発端は、おおむねこんなものである。

77ページ

プロジェクト・マネジャーは、進捗の遅れに気付いたら、開発チームの現場に一歩踏み込んで現実を把握し、何らかの手を打つべきだ。スケジュールの遵守のみを重要視する「官僚的なマネジメント」では、プロジェクトは失敗する可能性が高い。

78ページ

危機プロジェクトに介入するとき、医者が患者の容態を診察するのと同じように、プロジェクトを診断する。これは、今見えている「症状」の裏に隠された「病因」（ドミナント・アイテム）を特定し顕在化させることが目的である。
ここで重要なのは、「症状」と「病因」の違いをきちんとにんしきすることだ。

79ページ

システム的視野に立って「病因」を特定するために、キーパーソンの協力を得ながら、システムの全貌を見通す地図、すなわち「俯瞰図」を描く。

３つの俯瞰図を作成する
・・・・・・・・・・必ず次の3つの俯瞰図を作成している。
１つは、システム構成俯瞰図・・・・・・・・・・・・
2つ目は、開発線票俯瞰図・・・・・・・・・・
3つ目は、要員移動俯瞰図・・・・・・・・

83ページ

システム開発プロジェクトで考慮すべき品質は、プログラムの品質（製品品質）だけではない。システム品質やプロジェクトの品質にも目を配るべきだ。（次ページ図4）

84ページの図４”企業ITシステム開発における品質の分類”
から項目だけ
・プロジェクト品質
・・システム品質
・・人間系品質
・・ステークホルダーの満足度
・システム品質には
・・製品品質
・・方式品質
・・環境品質
・・作業品質