第４６回目「実践プロジェクトマネジメント」（岡村正司著）（その４：全５回）
サブタイトルが「危機を乗り越える２５の決断」とある様に、著者がプロジェクト経験でえた次の世代に伝えたいノウハウを２５の瞬間に整理されたものです。プロジェクトを推進するにあたっての問題点と確認すべき事項、判断基準が記載されています。PMには是非一読することを勧めます。
今回も学ぶべきことが多いので、フォトリーディングからは少しずれてしまいますが、５回に分けて進めていきます。
なお、記載事項は各章で著者が表でまとめている事項について記載するともに、考察していきたいと思います（具体的な対策については、本書を参照してください。ためになること、気付かせてくれることがどの章にもあると言えます）。
１回目：１．支援契約と請負契約の判断、２．開発規模見積りの判断、３．マスタースケジュールの判断、４．ソフトウェア・エンジニアリング選択のリスク判断、５．開発環境構築の判断、
２回目：６．要件定義遅延時の判断、７．プロジェクトメンバーの入れ替え、８．外部設計の品質リスクへの対応、９．コスト・オーバーラン発生の兆候,１０．PMSを利用したマネジメントが破綻した時、
３回目：１１．大量取引処理の設計と課題への対応、１２．EVMが破綻した時、１３．拡張性設計とコスト・マネジメントの対立、１４．プログラムの品質悪化の兆候、１５．データベース設計の難しさと対応策、
４回目：１６．本番稼動機器および基盤システム決定の時、１７．SLAが守れない兆候が出た時、１８．予定通りのサービスインを決定する時、１９．追加開発受け入れ時の判断、２０．サービスイン遅延判断
５回目：２１．納品処理のトラブル判断、２２．プロジェクトを終了させる判断、２３．プロジェクト中断を言い渡された時、２４．対応するリスク、放置するリスク、２５．プロジェクトを成功に導くための判断、考察
この本に興味があれば→
※最終回には、１回目から５回目までをまとめた内容（ブログで紹介した内容）をワードorPDFにしたものをアップする予定です。こちらも参考にして、この書籍を購入され読まれた時の参考として使ってください。
１６．本番稼動機器および基盤システム決定の時
- ハード仕様変更のリスクを管理する
- IT機器決定の過程
- ①要件決定：業務要件定義終了時→業務要件と基盤システムの要件の合致、基盤システム要件の実現性評価
- ②詳細仕様決定：業務外部設計終了時→業務の外部設計成果物との整合性、基盤システムの仕様確定と並行してIT機器仕様確定
- ③実装機能確定：基盤システムのシステム・テスト終了時→業務統合テストに基盤システムを提供できるかどうか、実装レベルのIT機器確定
- ④稼動条件確定：業務システムテスト開始前→基盤系システム自体のサービスイン判定を実施、業務キャパシティ・プランを受けIT機器決定
１７．SLAが守れない兆候が出た時
- SLAの危機を予知できるマネジャになるための要件
- SLAは設計に大きな影響を与える
- PMはSLAを実現する一連の作業を把握する
- SLAを確実なものとする→ユーザと開発担当者側が用語を共有化し、的確な指標を使う
- サービス・レベルの定義は明確でなければならない
- SLAが守れない兆候への対策
- ①新システムのアーキテクチャを実装できない→要件定義局面内で対応
- ②基盤システムがサービス・レベルを確保できる仕様になっていない→基盤システムの改善を計画
- ③業務仕様が十分でない→外部設計局面で仕様を決めて確認、開発局面以降で問題発生の場合は優先順位をつける
- ④不要不急の機能で性能悪化→機能を削除したり開発を後回しにしてサービスインを優先
- 先人のノウハウなしには、SLAを実現できないシステムもある
１８．予定通りのサービスインを決定する時
- 稼動直後の障害発生を防ぐサービスイン決定の判断
- サービスインの判断：新システムで業務処理が可能かどうか、サービスインしたら処理を続行できるかどうか
- サービスイン判定基準をシステム・テストを通してクリアしていく
- 心配な機能は実行すべきではない→稼動させる機能を確実で安心できるものに限定する←これが最大のリスク対策となるプロジェクトは多い
- コンテンジェンシ・プランは顧客優先で作成する
１９．追加開発受け入れ時の判断
- 開発途中の変更受け入れでマネジャの手腕が問われる
- 顧客による一次の承引会議を開催してもらう→システム利用側の担当者の判断だけでは小型の変更が大量に発生し、開発工数見積もりを行うだけでプロジェクトの負荷が重くなる危険性がある
- 変更案件：発生のつど採用・不採用の承認を行い、承認されたものは最後まで開発をする
- 変更案件：業務仕様に変更が発生したから変更案件になるのではない、成果物に変更が発生したから変更案件になる
- 変更案件の開発：遅くともシステム・テスト開始前には追いつくべき
- 開発計画立案時の判断で考慮すべき項目（主なもの）
- ①開発スケジュール案：システムテストは変更案件を含む全体を対象に実施 等
- ②要員計画：変更案件開発期間はプロジェクト全体の要員数を増やす
- ③その他：開発要員増加に伴う開発環境を構築
- 一時的ではあるが、高いスキルを持っている要員を集中的に投入する
- サービスインに必要な機能を凍結で押さえ込むことはできない→変更を出させる努力が必要→ＰＭは「今出してください」と頻繁にＰＪ会議で指示をし、プロジェクトの担当者を回る⇒この作業は不可欠
- ＰＭは、自分自身のプロジェクトマネジメント能力の限界を見極める（指揮できる要員数、顧客に対する説得力、ＰＪ推進スタッフの能力、リスク発生時の対応能力 等）
- 自己を冷静にみつめ、自分の足りないところは、プロジェクト・スタッフの強化と経験者の指導で補うべき→プロジェクトを成功に導く
２０．サービスイン遅延判断
- サービスインの遅延は顧客優先で判断、収拾に全力
- サービスインの遅れ：顧客の新システムによる業務開始が遅延し、経営計画そのものに大きな影響を与える
- ぎりぎりのサービスイン判断→以下ができればユーザとサービスインを判断
- ①サービスイン必須機能に限定し、サービスイン直後を乗り切る
- ②障害の影響がユーザに出るのを水際で防ぐ
- ③障害対応の特別体制で、障害のつど対応する体制を構築
- ④ピーク時に処理性能不足の場合、稼動時間延長で当分逃げる
- 毎日の業務処理が可能であり、さらにデータベースの破壊が起きないか起きても対応できる範囲であれば、サービスインを決断する
- ＰＭの作業を、組織が全面的にバックアップすることが求められる
気付き
今回はサービスインに向けての課題について記載されている個所が多い。
プロジェクトのステークホルダーにとって、無事サービスインを迎えられるかどうかは一番の関心事。多くの場合、サービスインする日から、対外的にも内部的にも新しい業務やサービスが開始される。特に対外的なものでは、お客様向けのサービスの開始を既に宣伝・約束してしまっている場合があり、サービスインができなくなることは正に会社の信用問題に発展する。ステークホルダー全員にとって、死守しなければならない。
サービスイン日程については、開発当初から決まっている。全ての作業は無事サービスインすることに向けて進められる。だが、途中で仕様が膨らんだり、設計ミス等が発覚したり、あるいは、品質上の問題で工程が遅れ、ぎりぎりの品質、機能（あるいは、ぎりぎり以下）でサービスインを迫られるケースもある。
そうならないために、仕様についてはどこかで凍結する必要はあるが（できれば製作前）、他部門からの要請や気が付かなかった機能等で仕様追加要求、変更要求が発生する。著者が、仕様変更を凍結で抑えこむことはできないと述べられている様に、費用の問題はあるが、仕様変更は発生する。問題は仕様変更が発生する時期である。遅くなればなるほど、基幹部分になるほど、対応するための対策が取れなくなり、それは品質を含めサービスインへ影響を及ぼす。そのため、できるだけ変更を出させる努力＝システム仕様について考えて頂く努力が必要。逆説的にも聞こえるが、この方が仕様を速く凍結される方向に向かわせさせるのかもしれない。
他には、ＰＭは自分自身を知ること。正確には、現在の自分の力量を知ることが大切。やればできる精神は大切であるが、今の限られた時間の中で、自分がどこまで出来るのかを知らないと、プロジェクト全体に大きな影響を与えてしまう。ＰＭの判断は、その後にプロジェクトの進み方に大きな影響を与える。何ができないか、そのために何が必要かを見極めておかないと、プロジェクトメンバーに迷惑をかけてしまうことを知ること。
このブログが少しは役立ったと思われれば人気blogランキングをクリックして頂ければＨＡＰＰＹです（＾o^）
