はじめに
前回作成したプロジェクト計画書の書き方
の続編で、プロジェクト管理要領編となります。
経験値＝１なので、もしかしたらレガシーなやり方かもしれません。
ご了承ください。
プロジェクト管理要領とは
これに従えばプロジェクトをいい感じに進めることができる資料です。
「デジタル・ガバメント推進標準ガイドライン」には以下のように記載されています。
最後に出典を記載しますが、引用は全て上記資料から行います。
プロジェクト管理要領には、プロジェクトを遂行する際に、プロジェクトを管理する手法、手順、遵守事項等を明確に記載するものとする。
ただし、要領をガチガチに定めて誰も守らなくならないように、実現可能なラインで書いていきます。
「仏を作って魂入れずに」ならないようにしましょう。
プロジェクト管理要領に明記するように定められている項目は以下の通りです。
- 本書の目的
- ステークホルダー管理
- コミュニケーション管理
- 工程管理
- 指標管理
- リスク管理
- 課題管理
- 変更管理
- 品質管理
- 記録管理
各章を説明していきます。
本書の目的
プロジェクト計画書に書いたものとほぼ同じものでいいと思います。
ステークホルダー管理
ガイドには以下のように記載されてます。
プロジェクトに係る主要なステークホルダーを定義し、プロジェクトへの関わり方について記載する。
ステークホルダー管理についての序文を書いて、体制図を持ってくればいいでしょう。
ここはあっさりで良いと思います。
コミュニケーション管理
ガイドには以下のように記載されてます。
ステークホルダーとの情報共有方法や合意形成方法等として、ステークホルダー間の連絡調整に関する方法、会議体の種類や開催頻度、合意形成手順、議事録管理等の具体的内容について記載する。
・会議体
・連絡方法
・合意形成手順
・議事録管理
・Q&A管理
・エスカレーションルール
の６つに分けましょう。以下で詳細を書きます。
会議体
会議体は以下の情報は必要ですね。
・会議の目的
・議題
・出席者
・開催頻度/開催回数
・開催場所
・会議の成立条件
・議事録の承認者
・議事録の担当者
フォーマットを作って内容を埋めましょう。
月次定例会議だったり、進捗会議だったり、会議の数だけ定義します。
連絡方法
slackや、teamsで行う場合はその旨記載します。
電子メールの場合は、甲乙のメールアドレスを書きましょう。
合意形成手順
これにはいろんなやり方があるみたいです。
基本は議事録を最初に配布するのですが、
・議事録に承認者名と承認日を書いて、承認の旨を記載したメール連絡をする。
・次の会議の時にもう一回読み上げてなんかあるなら言ってね。ないなら承認ね。
みたいなパターンとか、いろいろあるみたいですね。
ただ、相手次第で最適解は変わるため、上長に確認して各会社のやり方で行うのがベターです。
承認までのフローチャートも作ってあげた方が優しそうです。
議事録管理
議事録は記録文書です。ファイル末尾にYYYYMMDDとつけて管理します。そのことを書いて、どこに保存するか明記しておきます。
Q&A管理
プロジェクトを進めるとQ&Aなんて山のように出ます。
Q&Aを送る媒体や、連絡票のフォーマット、誰が送るかを記載します。
連絡のフローチャートを作り、Q&Aを管理する台帳も作成します。
エスカレーションルール
進捗遅れとか、なんかやばいことあったらこのルールに則って連絡しなさいね。です。
工程管理
ガイドには以下のように記載されてます。
作業内容・スケジュールを所定の時期に完了させるために、作業管理方法、進捗状況の報告先、内容、頻度等について記載する。
各工程の定義を記載します。
一般的に開発には以下の工程があります。
- 要件定義（計画）
- 基本設計
- 詳細設計
- 開発
- 単体テスト
- 結合テスト
- システムテスト
- 本稼働
各工程の詳細はここでは端折りますが、基本的な書き方としては
・工程の概要
・成果物
・開始、終了条件
を書きます。
残りの作業管理方法は、工程管理フローを作って明記した方がわかりやすいでしょう。
そこで工程の承認方法とかを定めます。
指標管理
ガイドには以下のように記載されてます。
「目標及びモニタリング」に定めたプロジェクトの目標の達成状況を適切に管理するために把握すべき指標項目、実績値の取得目的・取得手法・取得頻度、実績値の変動による対応策等について記載する。
なお、本項目で定めた指標は、サービス、業務、情報システムの改善検討にも活用する。
品質管理に利用する品質指標等の説明を当項目で記載します。
品質管理の工程でも触れますが、開発なら
- 障害発生数/ステップ数
- レビュー指摘数/対象機能数
のような指標が考えられます。
後日別記事で当該項目については詳しく記載します。
リスク管理
ガイドには以下のように記載されてます。
プロジェクトの遂行を阻害する可能性のあるリスクについて、リスク顕在時の報告先、報告内容、リスクの管理手法等を記載する。
なお、情報セキュリティ対策リスクについては、自府省の情報セキュリティポリシーを参照して記載内容を検討するものとする。
リスク管理台帳を作成して、そこでリスク管理をしましょう。
リスクの対応状況確認タイミング、見直しタイミングも明記します。
管理フローも作成しましょう。
リスク特定→リスク分析→リスク評価
でのアクションも明記しましょう。
課題管理
ガイドには以下のように記載されてます。
プロジェクトの遂行上発生する解決すべき課題について、その発生時の報告
先、報告内容、課題の管理手法等を記載する。
リスクの時と同様、課題管理台帳で管理します。
課題の対応状況確認タイミング、見直しタイミングも明記します。
管理フローも作成しましょう。
障害管理
障害管理表に記載していきます。
障害内容・原因・作り込み工程・検出工程などなど…記載します。
また、管理方法・管理フローの資料を作成しましょう。
変更管理
ガイドには以下のように記載されてます
プロジェクトの進捗により発生する変更について、管理対象、変更手順、管
理手法等を記載する。
大体は仕様変更のフローです。
これは責任者を交えた、しっかりした検討が必要です。納期の調整、費用の調整などいろいろ生まれるので決定する際の会議にはプロジェクトの責任者及び権限委任者の出席が必須となります。
品質管理
ガイドには以下のように記載されてます
プロジェクトの各工程で実施する作業の品質を管理する手法及び改善する手
法について記載する。
品質目標を「プロダクト品質」、「プロセス品質」の両方から定めます。
プロダクト品質は成果物の正常動作で品質の担保をします。
プロセス品質は定性、定量評価で品質を担保します。
品質目標を定めることも忘れずに行います。
品質指標値を明記し、それに従って定性、定量分析を行ってください。
例）レビュー指摘数、障害数
記録管理
ガイドには以下のように記載されてます
プロジェクト実施中に作成する各種文書・データの保存期間、保存期間満了
時の措置等について記載する。
資産別の管理方法を定めます。
ドキュメント、プログラムで大分変わるので要注意。
どこに資産を保存するかも明記します。
セキュリティが担保されていることは絶対条件です。
文書の版数、日付などの命名規則も明記しましょう。
おわりに
前回のプロジェクト計画書、今回のプロジェクト管理要領で超ザックリしたプロジェクトの立ち上げ資料が用意できました。（質がまだまだ悪い）
別紙の資料や、各項目の掘り下げは別の記事で行おうと思います。
余裕があれば加筆修正、図の挿入などでどんどんブラッシュアップしていきたいと思います。