図解で磨くプロマネ技術（実践マニュアル）

システム構築の成否は、プロジェクトマネジメントにかかっていると言っても過言でない。
プロジェクトマネジメントのノウハウは、現場の経験・ノウハウがベースであり、かっこよい理論とはほど遠い。この現場のノウハウを読み物としてまとめた書籍が「図解で磨くプロマネ技術（実践マニュアル）」である。著者は、住友生命の情報システム子会社で、システム構築に長年携わってこられたベテランである。
プロマネ技術を、１．プロジェクト計画（成否を決める計画立案）、２．プロジェクト遂行（危機を防ぐプロジェクト遂行）、３．評価、報告、フィードバック、４．フェース別開発ドキュメントに分けて、具体的ドキュメントを活用しながら、改善点を示している。
経験に裏打ちされ、心構え論に終わらない実践的なＩＴプロジェクトマネジメント本である。



具体的には、以下の内容となっている。
１.プロジェクト計画
　プロジェクト計画は、成否を分ける重要なものでありスタート時点で以下に注意せよと説く。
　①キックオフでは、利用者も参加し、思いを語るべし。
　　　なぜならば、
　　　・プロジェクトの目標、制約事項、意思決定の方法
　　　・課題の優先順位の決定、要件確認、仕様の確定、納期調整、
　　　　稼動可否判断
　　　は、利用者の決定事項である。利用者の参画・責任感がプロ
　　　ジェクトの成否を決める。
　②マスタースケジュールには、フェーズ、アクティビテイ、成果物の
　　　完成時期や納期だけでなく、プロセスを管理する方法、品質管
　　　理、資源管理、コミュニケーション計画も書くべき。
　　　・プロジェクトは、単線的に進行するのではなく、どのように品質
　　　　目標を定め、どのようなテストやレビューによって品質を確保
　　　　するか、コミュニケーションの食い違いをどうやって食い止め
　　　　るか、手戻りや仕様の膨張をどう防止するか。がポイントで
　　　　あり、それらを入れた立体的計画にする必要がある。
　③作り手だけでの計画ではなく、レビュー、レビュー後の修正、再
　　　レビューも入れる。
　④コミュニケーション計画でも進捗会議を意味のあるものにしよう
　　とすると事前準備、会議後のフォローが必要。
　⑤リスク管理で既におきてしまったこと（発現）は課題であって、
　　　リスクではない。
　　　・リスク管理表には「発現可能性」（確率）、「発現した場合の
　　　　インパクト」（影響度、重要度）を書いてプライオリティ付けす
　　　　べし。定期的にトラッキングを行っていくことが不可欠。
　⑥体制図では実質的なメンバーが必要、役割定義表には部門間
　　　調整、要件・優先順位の決定、品質コスト納期についての判断
　　　等を忘れずに書く。会議体一覧では下位の会議から上位の会
　　　議に課題をエスカレーションしやすいようにする。

２.プロジェクト遂行
　　プロジェクトが実際にスタートすると、以下のことに注意すべし説く。
　①課題管理表では、責任者を明確にし、解決期限も入れる。
　②変更管理理表には、影響や優先度、代替策、コストを記載し、
　　権限者が判断を下す。
　　　　・インパクト分析→対応分析→可否判断
　③問題管理表で仕様ミス、コーデイングミスを管理。
　　　　・解決へのアクション→横展開と再発防止→確実に対応
　④定例会議のアジエンダとしては、前回の議事録確認、今回
　　　の結論、課題解決期限、担当者の確認、次回の日程、
　　　テーマ確認が不可欠である。
　⑤作業環境を軽視するとメンバーの信頼が得られないので、
　　　作業環境をきちっと準備する。
３.評価、報告、フィードバック
　　プロジェクトが進捗しているときに評価、報告等のマネジメント
　　として以下の心得を説いている。
　①中日程表、進捗管理表において、管理する作業のメッシュを
　　統一する。
　　ブレイクダウンする作業期間の粒度は「管理サイクルの半分
　　以下」。月次管理なら管理するアクティビィティは２週間以内。
　②スケジュールには、成果物の顧客承認や検収、受発注の契
　　　約手続き、フェーズイン、フェーズアウトの判定、成果物の
　　　品質評価や次工程計画の策定、見直し、要員のアサインと
　　　リリース　、作業場所や開発リソースの準備を考慮する必要
　　　ある。開発だけでなく関連するイベントを考慮する必要性を
　　　説く。
　③品質評価報告書はケースの充足性や不具合の検出状況を
　　客観的に評価するものであり、「問題なし」の結論を無理に作
　　ることではない。統計は対策につながることを目的に取得する。
　④リカバリー計画書は、内部で現状把握して方針を検討するた
　　めの初動版、顧客と合意するための合意版、計画を実行する
　　ための実行版を必要に応じて作成すべし。
　　リカバリー計画は変更できないので、妥当性検証と綿密なモニ
　　タリングが必要。

４.フェーズ別開発ドキュメント
　①提案時のプレ要件定義にも注意し、付帯条件を明確にしておく
　　こと。この場合は、対象外であることを明記したほうがよい。
　　・「移行データの作成および移行、移行後の検証については
　　　対象外とします。」等
　　・スケジュールやシステム化範囲について要件定義後に見直
　　　すことも合意しておく。
　　　現行システムの機能を踏襲する場合、注意が必要。
　 ②要件定義では、相手の説明を無条件で信頼せず、矛盾をついて
　　　現状をあぶリ出すことが必要。
　　　例外や数字（データ量、業務量、作業回数、頻度）を把握。
　　　重要度、代替案、対応コストを作り「要望を絞る仕掛け」を分析表
　　　に埋め込む。
　③設計書の記述は、作り手の視点になりがち。既存システムのコード
　　設計も無条件の流用は危険。
　　　「ユーザビュー・外部設計のこつ」を参考に。
　　機能ばかりではなく、性能、バックアップや障害時の対応も設計対象
　　にする。
　　コード内に事業部、部、課、係などの意味を持ち込まないようにする。
　　持ち込むとソートや条件判定が複雑になる。
　④要件定義の段階から移行方針を検討する。現行データを過信せず、
　　移行結果の検証、現行データ整備、一部を手作業で移行等につい
　　て計画を立てておくべき。

以上箇条書き的に書いたところもあるが、システム構築プロジェクトの
マネジメントのノウハウとして、大変よくまとまっている。