第４３回目「実践プロジェクトマネジメント」（岡村正司著）（その１：全５回）
サブタイトルが「危機を乗り越える２５の決断」とある様に、著者がプロジェクト経験でえた次の世代に伝えたいノウハウを２５の瞬間に整理されたものです。プロジェクトを推進するにあたっての問題点と確認すべき事項、判断基準が記載されています。PMには是非一読することを勧めます。
今回も学ぶべきことが多いので、フォトリーディングからは少しずれてしまいますが、５回に分けて進めていきます。
なお、各章で著者が表でまとめている事項からの抜粋を記載対象として、考察していきたいと思います（具体的な対策については、本書を参照してください。ためになること、気付かせてくれることがどの章にもあると言えます）。
☆★☆ところで皆さん「Photoreading習得委員会」をご存知ですか。フォトリーディングの仲間同士で、フォトリーディングの技術を楽しみながら向上させて行こうとされているＨＰです。
私のこのブログもリンク集の一つに加えて頂きました。
Photoreading習得委員会のリンク集
☆★☆
１回目：１．支援契約と請負契約の判断、２．開発規模見積りの判断、３．マスタースケジュールの判断、４．ソフトウェア・エンジニアリング選択のリスク判断、５．開発環境構築の判断
２回目：６．要件定義遅延時の判断、７．プロジェクトメンバーの入れ替え、８．外部設計の品質リスクへの対応、９．コスト・オーバーラン発生の兆候,１０．PMSを利用したマネジメントが破綻した時、
３回目：１１．大量取引処理の設計と課題への対応、１２．EVMが破綻した時、１３．拡張性設計とコスト・マネジメントの対立、１４．プログラムの品質悪化の兆候、１５．データベース設計の難しさと対応策、
４回目：１６．本番稼動機器および基盤システム決定の時、１７．SLAが守れない兆候が出た時、１８．予定通りのサービスインを決定する時、１９．追加開発受け入れ時の判断、２０．サービスイン遅延判断
５回目：２１．納品処理のトラブル判断、２２．プロジェクトを終了させる判断、２３．プロジェクト中断を言い渡された時、２４．対応するリスク、放置するリスク、２５．プロジェクトを成功に導くための判断、考察
１．支援契約と請負契約の判断
- 作業内容や実力を考慮して契約方式を決断する
- 支援契約：「仕事の完成」の約束ではなく、善良なる管理者の注意義務をもって「当該業務」の遂行を約束する契約
- 請負契約：供給者が「仕事を完成」することを約束し、購入者が仕事の結果に対して報酬を支払うことを約束する契約
- 請負契約を結ぶときのPM（プロジェクト・マネジャ）の判断
- ①プロジェクト成果物の納品の可能性評価
- ②納品プロジェクト成果が契約の基となるコストで提供可能
- ③プロジェクト成果物が予定の時期に納品可能
- ④お客様の意思決定能力を評価
- ⑤支援契約部分のお客様責任は果たしていただけるか
- ⑥PJ（プロジェクト）側の当PJを推進する能力を評価
- ⑦PJリスクに耐えうる力が存在する
- ⑧お客様の体質評価
- メンバーへの信頼が最後の拠り所
２．開発規模見積りの判断
- 複数の手法を利用して開発規模を的確に見積もる
- 開発規模見積り工程：開発ステップ数見積もり、開発生産性の評価、工数見積もりの三つに大別
- 「マクロ開発生産性から見積もる」「PJ成果物ごとの開発生産性から見積もる」の二つのアプローチが必要
- 開発規模見積もりの最終判断項目
- ①要件定義の品質は確信できるレベルに達しているか
- ②開発規模見積もりで複数の結果がほぼ同じ数値であるか（異なる場合は合理的あ説明がつくか）
- ③目標の開発生産性が出せるか
- ④PJのチーム別要員計画の実現性確認
- ⑤開発規模増加のリスク定義とコンテンジェンシ・プラン評価
- ⑥開発規模に対するPJ推進力評価
３．マスタースケジュールの判断
- 軽視すれば失敗する WBSに基づき作成
- クリティカル・パスを認識していないPJは危機的状況にある
- マスター・スケジュールを作成する前提：WBSの作成⇔マスター・スケジュールとWBSは一体
- マスター・スケジュール作成のPMの判断項目
４．ソフトウェア・エンジニアリング選択のリスク判断
５．開発環境構築の判断
- メンバーの能力を生かす開発環境を構築する
- 開発環境整備を経費としてとらえるのではなく、戦略的投資を考えて開発環境を構築する時代に入った
- IT機器を利用すれば、プロジェクトマネジメント・コストを低減するとともに、品質を高めることができる
- 開発環境構築時に下すべき判断
- ①開発体系に合致した開発環境の構築
- ②PJ計画に沿う開発環境を構築
- ③開発環境構築計画が目的に合致（テスト環境の目的に合致等）
- ④構築された開発環境のPJ支援効果が所定通り出る→構築された開発環境の評価を実施）
- ⑤開発環境構築を可能にするスキル要員が確保されている
気付き
言われている問題点は、ＰＭが意識している／していないに関わらず、普段考えていること。その解決方法についてのポイントを示されている。
見積りについては、個人の経験とともに、会社の過去の情報（参考例）の有無によって精度が異なってくる。見積りによって、そのプロジェクトが成功可否が決まると言っても良いのではないか。
１章では、どういう契約にするべきかについて記されているが、請負を考えている場合は開発環境の構築、ＳＷＥの選択、要員計画、そしてリスクを考慮した上で判断すべき。
目先の受注にとらわれてしまうと、どちらかと言うと、ついつい（デマルコのゆとりの法則にある様に）バラ色の成功計画の作成に比重が移ってしまうケースも多いかと思う。ゆっくり考えている時間もないし、できるだけ安い価格にしないと競合他社に負けてしまう。
この辺りは、自社の実力（生産性、技術力）を見て、冷静に判断しなければならない。
マスタースケジュールについてはＰＭＢＯＫでも記載されている通り、ベースラインは簡単に変更すべきではない。工程が遅れたりすると、クラッシングやファストトラッキングで建て直し、その工程に沿って進めていくことがあるが、それもチーム内だけの工程調整の話であり、マスタースケジュールは変えてはならない。ＷＢＳは、スコープ記述書をインプットとして作成し、そこからアクティビティ所用期間を見積もり、スケジュールを作成する。従って、ＷＢＳはスケジュールと合致していなければならない。スケジュールには記載されているがＷＢＳとして記載されていないアイテムが存在するケースがあるが、これだと成果物とスケジュール、コストのリンクが取れない。
また、マスタースケジュールの作成で、特に注意すべきことは、要員計画と思われる。本書でも要員計画について触れられているが、計画通りに予定しているスキルを持った要員が入ってこなければ計画が成り立たない。プロジェクト体制は最初に決まるが、（フェーズ毎に必要となる）要員についてはＰＪの進捗状況もあり、要員参入の時期は予定からずれるため手配が後回しになることがある。この場合、実際に予定した時に要員が手配できないと、作業が進まずに遅れの原因となる。特に、製作時点の遅れは、品質にも影響していく。上流工程から製作時期に掛けての要員手配の遅れは、スケジュールの遅れだけではなく、品質の劣化を招く。
