ウォーターフォール型プロジェクトマネジメントのポイントのまとめ
なんとなくウォーターフォール型プロジェクトマネジメントのポイントをまとめてみますよ。
前提
- プロジェクトは有期限性を持つ唯一無二の業務活動。
- プロジェクトは、プロジェクトを行う業務の目的を達成するために行う。
- プロジェクトは、目的達成のためのdeliverables（スコープ）を設定する。
性質
- ウォーターフォールは、プロジェクトの目的を達成する作業を複数の局面（フェーズ）に分割して作業を遂行する。
- 作業を複数の局面に分割するのは、プロジェクトの目的の要件からシステムにいきなり作ることができないため。できる場合はウォーターフォールを採用する価値はない。
- 局面は、プロジェクトマネジメントの管理単位で分割し、deliverablesの構成要素を紐付けする。
- プロジェクトの遂行は、局面を順に行う。契約上許容される範囲で前工程に戻っても良いがプロジェクトマネジメントは複雑になり難易度が高くなる。
- 局面ごとに同一の作業を集中して行うことから、原理的に生産性は高いが作業プロセスを複雑化すると生産性が落ちる。
作業
- 局面での作業は、WBS（Work Breakdown Structure）を使用する。
- WBSごとにアウトプット（中間生産物またはdeliverables）を設定する。
- WBSの作成前に作業を標準化すること。標準化しないと、モニタリング対象となるWBSの粒度がバラつくためコントロールし辛い。
- 局面ごとのWBSの完了をプロジェクトマネジメントの管理単位で集約する。
- 進捗は、WBS単位で計測する。
- 進度は、WBSの作業で設定する。
- 進捗管理上の進度は未着手と完了を計測できれば良い。
- 進度は、WBSの作業に度合いを紐付け手も良いが最終的には計測の単位が小さくなるだけで進度は未着手か完了を計測することになることに注意。
品質管理
- 品質管理は、プロジェクトの目的を定量的な目標として設定した数値が神様となる。
- 品質管理は、作業に対し目標に達していることを客観的に計測する活動である。
- 品質管理は、客観的活動をすべての工程の作業の標準化の際に織り込む。
- 品質管理がテスト工程のみと思っているシステムエンジニアは職業を変えるべし。
- 品質管理がバグ潰しと思っているシステムエンジニアは退場すべし。
スコープ管理
- プロジェクトの目的のdeliverablesをコントロールするために行う。
- スコープは、変わることが前提。
- 変わらなければよかったね、程度。
- 変更となった場合、変更管理プロセスを発動する。
変更管理
- スコープを変更したいんだけど、条件飲むならいいよ、嫌だよを公式の場で議決するプロセス。
- スコープを変える場合は、契約元と先で合意し、再見積もりを行う。
人的リソース管理
- 局面ごとの人の手配を行う。
- ただし、計画通りに手配できない、途中で退場するなどが起きるから複雑になる。
