第４４回目「実践プロジェクトマネジメント」（岡村正司著）（その２：全５回）
サブタイトルが「危機を乗り越える２５の決断」とある様に、著者がプロジェクト経験でえた次の世代に伝えたいノウハウを２５の瞬間に整理されたものです。プロジェクトを推進するにあたっての問題点と確認すべき事項、判断基準が記載されています。PMには是非一読することを勧めます。
今回も学ぶべきことが多いので、フォトリーディングからは少しずれてしまいますが、５回に分けて進めていきます。
なお、記載事項は各章で著者が表でまとめている事項について記載するともに、考察していきたいと思います（具体的な対策については、本書を参照してください。ためになること、気付かせてくれることがどの章にもあると言えます）。
この本に興味があれば→
スゴ本さんのブログでも参考になります。→スゴ本
以前も紹介しましたが、好川氏のブログでも紹介されています。→ビジネス書の杜
１回目：１．支援契約と請負契約の判断、２．開発規模見積りの判断、３．マスタースケジュールの判断、４．ソフトウェア・エンジニアリング選択のリスク判断、５．開発環境構築の判断、
２回目：６．要件定義遅延時の判断、７．プロジェクトメンバーの入れ替え、８．外部設計の品質リスクへの対応、９．コスト・オーバーラン発生の兆候,１０．PMSを利用したマネジメントが破綻した時
３回目：１１．大量取引処理の設計と課題への対応、１２．EVMが破綻した時、１３．拡張性設計とコスト・マネジメントの対立、１４．プログラムの品質悪化の兆候、１５．データベース設計の難しさと対応策、
４回目：１６．本番稼動機器および基盤システム決定の時、１７．SLAが守れない兆候が出た時、１８．予定通りのサービスインを決定する時、１９．追加開発受け入れ時の判断、２０．サービスイン遅延判断
５回目：２１．納品処理のトラブル判断、２２．プロジェクトを終了させる判断、２３．プロジェクト中断を言い渡された時、２４．対応するリスク、放置するリスク、２５．プロジェクトを成功に導くための判断、考察
６．要件定義遅延時の判断
- 要件定義が遅れたらまず業務仕様を固めよ
- 要件定義局面における遅延発生時のPMの判断
- ①既存システムの業務仕様把握が不十分→業務把握の仕様からやり直す
- ②新システム設計方針の作成が不十分→狙いと設計方針を作成
- ③新システム論理モデル作成のスキルが不十分→スキルのある要員確保、品質マネジメント強化
- ④新システム課題解決のマネジメント不足、要件定義局面の投入ワークロード不足、PJ規模に適応できるマネジメント能力不足→規模に合致したプロ計の作成、PMの確保
- 先を急がす、落ち着いた対応で、要件定義局面をキッチリ終了させる（後になるほど、前段のミスは膨らむ）
７．プロジェクトメンバーの入れ替え
- ときには苦渋の決断を下す メンバーの入れ替え
- チームメンバーの入れ替えはチーム・ビルディングの再実施に通じる
- メンバーの入れ替えにおけるPMの判断
- ①PJ局面開始時の新体制構築→PJ推進要件にPJ体制が合致するかどうか
- ②クラッシング対策用の組織を構築→クラッシング対策が可能かどうか
- ③PJ内の新組織発足→新組織が目標を達成できるかどうか
- ④メンバーの能力に合致した異動→メンバーの育成につながるかどうか
- ⑤PJ規模の変化に対応した組織構築→PMはその規模のPJ遂行が可能かどうか
- ⑥PJに貢献できない要員の異動→PJ内で新規役割が定義できるかどうか
- ⑦新戦力としてメンバー投入→交替要員としてPJに参加できるかどうか
８．外部設計の品質リスクへの対応
- 機能や性能を再確認 品質低下のリスクに備える
- 外部設計局面で発生しやすい品質面のリスクに対する判断
- ①業務仕様が当初の目的に合致していない→ユーザとの折衝
- ②新システムの業務機能が充足されていない→業務機能を充足
- ③新システムの使い勝手がよくない→ユーザとの折衝
- ④キャパシティ・プランの見積もりと業務対応→業務仕様に関わる個所は対応
- ⑤プロジェクト・プランの変更発生→開発規模・期間などを明確に判断
９．コスト・オーバーラン発生の兆候
- コスト超過を見極める能力は一人前のマネジャの条件
- コストオーバーラン発生時に必要なPMの判断
- ①プロジェクト・プランで過小見積もり：（兆候）設計方針が具体化していない、機能継承不足の指摘、要求定義局面が予定コストで終了しない、主要機能の設計がすすまない→（判断）設計方針の具体化をユーザに依頼、使える仕様かをみて継続可否を判断、プロジェクト・プランの見直し、スキル要員の確保
- ②メンバーの能力不足：（兆候）指導力不足を指摘、成果物の品質が悪い、設計困難な部分は精鋭が配置されていない→（判断）リーダの継続は可能か判断、能力ある担当の割り当て、コンテンジェンシ・プランの発動
- ③PJの変更管理が不十分：（兆候）過小見積もり、正式な変更でないため不満がでる→（判断）変更管理の制度を構築
- ④局目最終段階のワークロード評価不足→（兆候）増員依頼がある、協力会社からの不満→（判断）画面や帳票やデータ項目数の推移を月１回実施、各局面終了でプロジェクト・プラン評価
- 肝心なことは兆候にいかに対応するか
１０．PMSを利用したマネジメントが破綻した時
- 成功のカギ握るPMSを正しく使うポイント
- チーム・リーダはPMS出力のデータ分析を通して、PJを評価する力を養わねばならない
- PMSを利用したマネジメントが破綻したときのPMの判断
- PMSを利用するということ＝認知されたプロジェクトマネジメントの仕組みや手法をPJに導入するのと同じ
気付き
この５章については、スケジュールが遅れだす兆候、コスト超過が発生する兆候に関連する注意点が述べられている。
上流工程の要求定義については、仕様を決めていく段階なのでスケジュールリスクが高い。いかにユーザを巻き込み協業していけるかがＰＭの力の見せ所とも言える。上流工程で、業務仕様を明確にしシステム開発上で必要な技術を確認し、ポイントやリスクを考慮しておかないと、後工程で響いてくる。上流工程の１日分のミスは、後工程では何倍にもなって現れてくる。
ただ、そう言うこと（上流工程の設計が大切なこと）はＰＪメンバーなら誰でも分かっていること。開発手法として、ＸＰ（エクストリーミングプログラミング）やＲＵＰを採用したとしても上流工程の大切さは変わらない（物作りの局面においては、開発手法によっては効率に差が出てくる）。上流工程を確実に実施していかなければならないことは、分かっているが、このままでは納期や開発体制にアイドルが出るとなると、先に進めという呟きが聞こえてくる。このあたりを冷静に分析し待てるかどうか、また、待つと判断すればそれを組織に認めさせられるかが力量であろう。その判断材料のたに用意するものとして、デマルコは「ゆとりの法則」や「熊とワルツを」で、価値を考慮したスケジュールリスクの数量化としてリスク図の作成を推奨しているのだと思う。
コストオーバランについても、リソースの投入スケジュール、工程の遅れ、それにリスクを正確に把握しておかないと兆候さえつかめない。
ＰＭＳについては、スケジュール管理、リソース管理、特にＥＶＭの使用を考えている場合は、ＰＭＳなしにはやっていけないと思われる（やっていけないことはないのであろうが、使える人とそうでない人では効率に差がでるし、情報のリアルタイム性（＝ある意味での正確性）にも差がでる）。初めて使う場合を含め、使うと決めた場合（それまでにコスト効果は考慮）は、教育期間、方針を明確にしておかないと逆効果を生む羽目にもなりかねない。
このブログが少しは役立ったと思われれば人気blogランキングをクリックして頂ければＨＡＰＰＹです。
