Chapter 06

プロジェクトの歩き方③～要件定義・設計・開発・試験・移行～

このチャプターの目次

実行プロセス群＆監視・コントロールプロセス群

実行しながら監視と制御を行う。そのため、これら2つのプロセス群は同時実行が期待される。

■実行プロセス群

知識エリア	実行プロセス群
統合	・プロジェクト憲章の作成・プロジェクト作業の指揮・マネジメント・プロジェクト知識のマネジメント
品質	・品質のマネジメント
資源	・資源の獲得・チームの育成・チームのマネジメント
コミュニケーション	・コミュニケーションのマネジメント
リスク	・リスク対応策の実行
調達	・調達の実行
ステークホルダー	・ステークホルダの特定・ステークホルダ―エンゲージメントのマネジメント

■監視・コントロールプロセス群

以降では、一般的なウォーターフォールの流れで記載していく。
実際の業務では組織文化や技術ナレッジによって変わってくると思うので、都度読み替えていただきたい。

『計画プロセス群』の時点では計画レベルであったが、ここでは5W2Hを意識して詳細に要件定義を行う。

5W2H	内容
Why	・何でやるの？（目的・背景・目標・効果）
What	・何をやるの？（解決すべき課題）・何がいるの？（資源・調達）
Where	・どこまでやるの？（スコープ・品質）・どこでやるの？（作業場所）
Who	・誰がやるの？（ステークホルダ）・誰とやるの？（コミュニケーション）
How	・どうやってやるの？（実現方法・実現手段）
When	・いつまでにやるの？（スケジュール）
How much	・いくらかかるの？（コスト）

計画を要件に落とし込む上で、RFP(提案依頼書)を作成する事もある。
その際は、上記に加えて、発注者に求める体制や想定作業時間も提案してもらうようにする。
（発注者側のヒトや時間を無視して提案を受け、受注後に発注者のヒトや時間が確保できずに遅延や超過が発生する事を防ぐ。）

計画を要件に落とし込む上で、プロジェクトの進捗阻害要因が出てくる事もある。
その際は、リスクとして登録・管理し、必要に応じてスコープ・コスト・スケジュールなどの統合変更管理も行う。
（後述する「コンティンジェンシープラン」もその一つ。）

計画を要件に落とし込む上で、要件が定まらず、将来的に大幅な見直しが発生する可能性がある事もある。
その際は、アジャイルも視野に入れる。
（ウォーターフォールでは柔軟な対応ができない場合は、アジャイルに切り替えた方がいいケースもある。）

コミュニケーション計画を立てる際は、意味ある会議体を設ける。
（報告連絡会議、問題解決会議、意思決定会議、アイデア出し会議、など）

コミュニケーション計画を立てる際は、エスカレーションや細かい口出しは、メンバーではなくリーダーに行う。
（PMは、メンバーの能力を最大限に引き出して与えた責務が担えるように、PLに働きかけて環境整備する事に努める。）

本フェーズでは人員が増えるため、コミュニケーションミスが生じやすい。
立場が違えば意見も違うので、否定せず、傾聴し、衝突しないようコントロールする。

本フェーズ開始時には、要件定義の読み合わせと今後の展開、成果物や品質目標の意識合わせを行う。
適切な会議体で、指揮・監視コントロール・リスクマネジメントを行う。

設計開発担当が効率的に作業できるよう、環境整備や間接業務の短縮検討などを行う。
メンバーの体調も考慮し、労務管理もしてあげる。

本フェーズで問題を見落とすと、業務に支障が出る。
システムが本稼働できない場合に備えて、コンティンジェンシープランを策定しておく。
（コンティンジェンシープランは、要件定義の時点で策定しておくとよい。更には、計画の時点で各業者に作成依頼を出させる方針を示していてもよい。）

システムを使ってもらうために、新システムのユーザ教育を行う。
新システムを前向きに捉えるユーザもいれば、変化が嫌いでクレームを言うユーザもいる。
全ては意見として傾聴し、要件定義書などを冷静に確認した上で対応有無を検討する。
（メンバーのモチベーションを下げないように指揮する。）

要件定義書に記載されていないスコープ外の機能追加や改善については、両社間で冷静に有償無償を協議し、対応を検討する。
バグ対応は優先度高なので、さっさとやる。
（メンバーのモチベーションを下げないように指揮する。）