【PM試験対策3】プロジェクト統合マネジメント
だいぶ間が空いてしまいました。
最初の2回の間隔が近かったのでさぞかし三日坊主に見えたことでしょうが、とりあえずそれは免れました。
先週は弾丸で神戸に行ったり2日続けて登壇やったりしてて、仕事も結構ハードだったためバテちゃってたんですよね。
ビットコインのやつはアップするかどうか未定です。
さて、遅れ取り戻すために頑張ります。今回は「プロジェクト統合マネジメント」です。
他の全プロセスに関わる重要分野です。
プロジェクト憲章作成
プロジェクト憲章作成は、立ち上げプロセス群に含まれる。
プロジェクト立ち上げ以前に策定される計画
- というか、個別プロジェクトの位置付け
- ITストラテジストの作成する中長期計画の一部
- 中長期計画の後ろには情報化戦略
- 個別プロジェクトは経営層の優先順位に従って選定される
プロジェクトの立ち上げとプロジェクト憲章
- プロジェクトの立ち上げ
- スポンサーがプロジェクトの存在を公式に認め、開始させること
- プロジェクト憲章
- プロジェクトの目的または妥当性
- 測定可能な、目標および成功基準
- ハイレベルの要求事項、プロジェクト記述、リスク
- 要約版のスケジュールと予算
- プロジェクト承認要件
- 任命されたPMとその責任・権限
- スポンサー名or憲章を認可する人
- これは、PMを選定するためのプロジェクト概要書
- スポンサーはキックオフミーティングを開催する
- ステークホルダを集める
- プロジェクト憲章の説明を行う
プロジェクトマネジメント計画書作成
- インプット
- プロジェクト憲章
- 他のプロセスからのインプット
- 組織体の環境要因
- 組織のプロセス資産
- ツールと技法
- 専門家の判断
- ファシリテーション技法
- 両方とも憲章の作成と一緒
- アウトプット
- プロジェクトマネジメント計画書
- 他の知識エリアの計画書を定義・作成・調整して、計画書に統合するプロセス
- なお、他の知識エリアの計画書の調整については出題されない
- 実務ではいちばんつらいらしい
- 他の知識エリアというのは、PMBOKの他の知識エリアのこと
- つまり、スコープ・マネジメントとかスケジュール・マネジメントとか
統合変更管理
- インプット
- プロジェクトマネジメント計画書
- 作業パフォーマンス報告書
- 変更要求
- 組織体の環境要因
- 組織のプロセス資産
- 後半、もう書かなくてもいいっすか……
- ツールと技法
- 専門家の判断
- 会議
- 変更管理ツール
- アウトプット
- 承認済み変更要求
- 変更ログ
- プロジェクトマネジメント計画書更新版
- プロジェクト文書更新版
- 全プロセスにおいて発生したすべての変更要求を処理する
- 変更要求のレビュー
- 変更の承認
- 成果物や計画書の変更
- 最終的な処置の伝達
変更要求の例
- 例えばこんな
- 変更の工数は、要求の発生が本番稼働に近ければ近いほど大きい
仕様変更手順
- 一番多い変更要求は仕様変更
- 組織のプロセス資産としてルーチンでこなせるものと想定されている
- 変更の申請書とか手順書とか
- 教本には仕様変更手順の例が示されている
仕様変更手順上の留意点
- 仕様変更手順を検討する場合は次の点に留意
- 書類による変更依頼
- 口頭でやるとか舐めてんのか
- 仕様変更管理メンバの選定
- 窓口は一本化
- 専任の担当者に受付から完了までを管理してもらう
- 変更管理委員会（CCB）の設定
- 依頼者側と開発側の対立を調停する、社内の第三者機関
- 揉めたときの最終決定権をあらかじめ固定しておく
- 仕様変更基準の設定
- 可否の検討をする場合の基準
- 例えば、チェックリスト形式
- 仕様変更の多発を防げる
- 可否の検討をする場合の基準
- 仕様変更受付の制限条件の設定
- 受付最大数や最終期日を設定
- ここを超えると変更凍結かお金いっぱいください
- 仕様変更による影響度調査
- 品質、納期、費用の面から調査
- スコープからすげ変わるような変更を安易に受け入れてはいけない
- レグレッションテストの実施
- 仕様変更時に影響を受けないはずの部分が影響を受けていないか
- 疎結合な設計がいかに重要か……
- 仕様変更情報の連絡
- 発生と対応の状況を全員が共有できる仕組みを作っておく
- 特に協力会社のメンバーには
- 書類による変更依頼
構成管理
- つまり、成果物のバージョン管理
- ハードやソフトの構成を記録することも構成管理と言ったりする
- 構成要素の集合をベースラインと呼ぶ
- なんかしっくりこない名前だ……
- PMBOKの領域ではないが、試験の出題範囲
- 構成管理の対象となる成果物
- 一切合切全て。あらゆる差別はなく平等が基本。
- 構成管理担当メンバの選任
- 全成果物がedgeであることを保障するための人員
- 構成管理ソフトウェアの導入
- 構成管理の手順
- ローカルで作業してチェックイン
- 翌日、チェックアウトして作業再開
終電定時になったらチェックインして帰る- 作業が終わったらステータスを完了にしてチェックイン
- 構成管理メンバは成果物のステータスを監視して、適宜働きかける
- 世代管理
- 過去のバージョンをすべて保存し、そのつながりを明らかにすること
- Googleドライブなんかはすべてのファイルでこれを自動でやってくれる
プロジェクトやフェーズの終結
- 終了プロセス群に属し、すべての作業を終わらせるプロセス
- 振り返りで教訓をまとめる
- 作業を公式に終わらせる
- リソースを解放する
- インプット
- プロジェクトマネジメント計画書
- 受け入れ済み成果物
- 組織のプロセス資産
- ツールと技法
- 専門家の判断
- 会議
- 分析技法
- アウトプット
- 最終プロダクト、サービス、所管の移管
- 組織のプロセス資産の更新版
- これには、プロジェクト完了報告書が含まれる
- プロジェクト完了報告書
- 実績記録、成果物の一覧、教訓が含まれる
- 教訓が特に重要なので、これが別の書類になることも
- ステークホルダは少しずつ教訓を書き留めていき、最終的にまとめる
問題演習から
- 変更管理において、分類項目を設定したほうが良い
- 分類の基準は発生原因、発生フェーズ、発生チーム、発生機能など
構成管理や変更管理、ちょっと具体的なツール名が出てこないなあ。
Gitはなんか違う気がするんですよね。Git+[GitHub|Gitlab]+G Suiteなところが多い気がするんですけども。
プロジェクト統合マネジメントは1回で終わっちゃいました。
次は「スコープ・マネジメント」です。
