第47回目「実践プロジェクトマネジメント」(岡村正司著)(その5:最終回)

サブタイトルが「危機を乗り越える25の決断」とある様に、著者がプロジェクト経験でえた次の世代に伝えたいノウハウを25の瞬間に整理されたものです。プロジェクトを推進するにあたっての問題点と確認すべき事項、判断基準が記載されています。PMには是非一読することを勧めます。
今回も学ぶべきことが多いので、フォトリーディングからは少しずれてしまいますが、5回に分けて進めていきます。
なお、記載事項は各章で著者が表でまとめている事項について記載するともに、考察していきたいと思います(具体的な対策については、本書を参照してください。ためになること、気付かせてくれることがどの章にもあると言えます)。
この本に興味があれば→実践プロジェクトマネジメント
※1回目から5回目までをまとめた内容(ブログで紹介した内容)をワードorPDFにしたものをアップしています(最下行参照)。こちらも参考にして、この書籍を購入され読まれた時の参考として使ってください。
1回目:1.支援契約と請負契約の判断、2.開発規模見積りの判断、3.マスタースケジュールの判断、4.ソフトウェア・エンジニアリング選択のリスク判断、5.開発環境構築の判断、
2回目:6.要件定義遅延時の判断、7.プロジェクトメンバーの入れ替え、8.外部設計の品質リスクへの対応、9.コスト・オーバーラン発生の兆候,10.PMSを利用したマネジメントが破綻した時、
3回目:11.大量取引処理の設計と課題への対応、12.EVMが破綻した時、13.拡張性設計とコスト・マネジメントの対立、14.プログラムの品質悪化の兆候、15.データベース設計の難しさと対応策
4回目:16.本番稼動機器および基盤システム決定の時、17.SLAが守れない兆候が出た時、18.予定通りのサービスインを決定する時、19.追加開発受け入れ時の判断、20.サービスイン遅延判断
5回目:21.納品処理のトラブル判断、22.プロジェクトを終了させる判断、23.プロジェクト中断を言い渡された時、24.対応するリスク、放置するリスク、25.プロジェクトを成功に導くための判断

21.納品処理のトラブル判断

  • 納品トラブル防止の基本は顧客視点での保守の考慮
  • 納品成果物はあらかじめ契約書にCWBS(コントラクト・ワーク・ブレークダウン・ストラクチャ)として記述しておく
  • 保守対象の選定には注意すべき:将来の保守対象にはなり得ないのに納品の対象になる場合がある
  • 納品処理で発生しやすいトラブルとその対策
    • ①納品成果物について顧客と開発側が合意できない←CWBSの合意が不成立:顧客とともに合意案を作成
    • ②納品成果物の品質を確保できずサービスインが遅延←PJ遂行で品質を確保できず:再設定のサービスインに向けPJを推進
    • ③サービスインを実施したが一部に開発残あり←開発の一部に遅延:サービスイン部分の納品のみを実施
    • ④納品成果物相互の整合性が一部とれない←納品成果物作成の開発標準の徹底が不十分:納品成果物に限定して成果物相互の整合性確保
    • ⑤納品成果物への変更案件の反映が遅延→変更案件の多発←変更案件の多発:遅延した変更案件を除く本体部分を納品
    • ⑥納品成果物の障害対応の反映が遅延←障害多発で仕様反映が遅延:障害部分を除く本体部分を納品
  • 顧客と開発側は「このプロジェクトのサービスインはどんな状態なのか」について、共通認識を持つ必要がある。
  • サービスイン時の体制をいつまで構築するか検討→納品の品質について事実上合意できたことにもなる
  • 成果物の納品:プロジェクト終結の作業に限定されるものではない。契約時点のCWBS作成から始まり、納品対象成果物の変更管理を通して、納品に向かう一連の作業

22.プロジェクトを終了させる判断

  • 見通しの確かさが試されるプロジェクト体制の解除
  • 安定稼動を確認し契約を考慮した上で、PMはプロジェクト体制の解除を判断する
  • プロジェクト体制解除計画時の判断
    • ①新システム開発のPJのサービスイン安定度合い評価:継続的に障害が発生するか初期障害で終結するかを判断
    • ②初回本番処理立会い:リアルタイム処理や日次、週次処理への立会いを実施 等
    • ③移行データの欠陥修正:リアルタイム処理、週次処理に立ち会う 等
    • ④初期障害対応:初回本番処理立会いに準じる
    • ⑤保守体制への引継ぎ:保守体制へのスキル移転に時間がかかる場合、スキル移転体制を別途置く 等
  • 保守要員のモラルを考慮

23.プロジェクト中断を言い渡された時

  • 3重苦のなかで判断する プロジェクト中断の作業
  • 大型PJはリスクの高い仕事、どこでもPJ中断のリスクが存在
  • 使命感だけでは大型システムを作り上げることはできない
  • 成果物を引き継ぐ再開プロジェクト側:中断プロジェクトでできた仕様書の中身の判断が重要→そこに新システムの仕様が過不足なく記述されているかを見極める
  • 統括:再開プロジェクトを立ち上げる基本方針につながり、成功には不可欠

24.対応するリスク、放置するリスク

  • 信頼されるマネジャはときにはリスクを見守る
  • プロジェクト・リスクへの対応
    • ①問題を認識する:スケジュール/コスト・ベースライン作成が前提
    • ②解決に向け優先順位をつける:損害が大きいものから着手
    • ③リスクを見極める:プロジェクト計画の変更につながるか判断
    • ④対応するリスクと見守るリスクを切り分ける:顧客と開発現場の両者が納得する解を見つける
    • ⑤リスクを開示する:日頃の信頼関係が大切
  • リーダーには常に位置決定が求められる→正しい決定の連続が、プロジェクトをベースラインに乗せる
  • 対応するリスク
    • ①プロジェクト途中で開発規模過小見積もりを発見→正しい開発規模の見積もりを実施し、それに沿ってプロジェクトを運営
    • ②リーダーの力量不足で、チームの進捗が予定通りでない→チーム・リーダーを支援する体制構築、改善効果がない場合は異動を想定
    • ③開発基準が遵守されない→各チーム最初に作成した成果物を、開発基準または開発支援チームによりレビュー
    • ④クリティカル・パスの作業遅延が拡大している→最優先で対応策を立案し、それを推進する
  • 見守るリスク
    • ①クリティカル・パス以外の作業遅延→フロートのある期間の範囲で進捗を見守る
    • ②チーム・ビルディングの最中の作業遅延→チーム・ビルディングの進捗を見守る
    • ③作業開始直後で、当初目標の生産性に到達しない→習熟にとる開発生産性向上を確認
    • ④遅延した作業の対応策を実施しているあいだ→対応策実施中は辛抱強く見守る
  • リーダの力不足がプロジェクトに与える影響は大きすぎる
  • プロジェクトのバイブルである開発基準が遵守されていない事態が見えたら即刻、対応

25.プロジェクトを成功に導くための判断

  • 押さえておくべき必要最低限の判断
  • 成功したプロジェクト:必ず正しいプロジェクト計画書が存在
  • 失敗したプロジェクトの原因:プロジェクト計画書の間違いが一番多い
  • プロジェクト成功の例
    • ①プロジェクト計画書の作成:正しいプロジェクト計画書ができて、初めてプロジェクトは成功する
    • ②WBSおよびWBSデクショナリの作成
    • ③業務仕様を決定する顧客側要員および開発を推進できる要員の確保:両者の要員配置に問題があれば、業務仕様決定または開発に遅延が発生する
    • ④プロジェクト成果物で作成するもの造りの工程確立と個々の成果物作成ノウハウ確保:ソフトウェアエンジニア技術の確保、各設計ノウハウの確保
    • ⑤プロジェクトを推進する開発環境の確保:コミュニケーションマネジメントが大型プロジェクトではキーワード



気付き
21章からは納品時の処理や、中断時についての対応、そしてプロジェクト全体を通して、リスク対応と総括として成功に導く判断が記載されている。
納品時の処理は、当たり前だが何を納品するかが明確になっていることが前提。納品物はプロジェクト開始時に必ず成果物記述書に記載しておく。WBSを作成する前には必要。納品前に多少の改訂は入るであろうが、開発の一連の作業を通して完成させていくもの。
また、契約段階で何を納品するかは発注側と合意をとっておくべきで、契約書に記載するなど、必ず文書化しておくこと。
リスクについては、常に意識する、探し出す努力が必要。分かっているリスクについては、対応策を放置しないこと。本書では、見守るリスクが記載されているが、見守ることと放置は違う。見守ると言うことは、フォロー(ウォッチ)はしておく。必要に応じてヒントを与える。また、管理側は見守りというつつも、実施している方は問題対策に懸命でプレッシャーもかかっている。そのため、自分たちが妥協した方法で解決できたと報告してくる時もある。PMは、解決策が正しいかどうかを、その理由を鵜呑みにするのではなく必ず確かめる目が必要である。時として、妥協してはいけないところは、厳しく接する必要がある。変に妥協していると(特に技術面)、後で妥協したがために大きな問題となって噴出してくることが多い。ゴールとする品質を見極めての判断が要求される。
最後に成功に導くための方法であるが、著者が言われているとおり、「正しい」プロジェクト計画書ができているかは、その後のプロジェクトの進行に大きく影響を及ぼす。プロジェクトの初めにプロジェクト計画書は作成するが、実際にプロジェクトが開始されるとあまり参考にされないプロジェクトも多いのではないだろうか。プロジェクト計画書の方針をメンバーが理解でき、それを徹底していく気持ちが浸透していれば、メンバーのベクトルが一致し成功に向けて軌道修正が働く。本書にも記載されているが、プロジェクトを成功に導くには、まずは計画が正しく立案されていること(正しいプロジェクト計画書)、必要な要員が確保できていることが大前提と考える。その上で、スケジュール品質が良いこと、PMの能力がプロジェクトの規模を超えていないこと、PMをサポートする組織力があることが条件であると考える。
<考察>
PMとして、どういう局面で何を基準に考えどう判断すべきかについて、非常に参考になる本である。多少、大型プロジェクトに関連して記載されているところはあるが、本質的なところはどのプロジェクトでもあまり変わらない。岡村氏が何を考えて、どの用に判断してきたかを少しでも知ることができるのは、これから岡村氏のようなPMを目指して行く人には本書は良い教材になる。プロジェクトを成功に導くためのエッセンスが記載されていると言えよう。後は、この本に記載されちるエッセンスを自分なりにどう消化して、プロジェクトに活かしていくか、それが一番大切で難しい点であるが、強い心をもって、正しい判断基準を持って勇気をもってプロジェクトに当たっていこう。

☆★1回目から5回目までの本書抜粋と考察をまとめたものを作成しておいました。よろしければダウンロードし、本書を読まれたときに自分なりの気付きを追加してみてください。ワード版はこちらから→実践PMから(word版)/PDF版はこちらから→実践PMから(PDF版)
このブログが少しは役立ったと思われれば人気blogランキングをクリックして頂ければHAPPYです(^o^)