プロジェクトの報告資料作成の後半は、各工程ごとの詳細な進捗報告とともに、課題の棚卸や要求仕様に関する変更の報告などに関する説明となります。
もう一度、全体の章立てを掲載しておきます。後半では、このうち第3章以降の内容が対象となります。
[toc]
【進捗管理報告資料（章立て）】参考
- 前回定例会のTODO確認
- 2.進捗状況（サマリー）ご報告
- マスタスケジュールの計画に対する進捗状況
- 工程別スケジュールに対する進捗のご報告
- WBSベースの定量報告
- 遅延発生時のリカバリー策ご報告
- 工程別進捗状況ご報告
- 要件定義
- 設計・開発・単体テスト
- 結合テスト、総合テスト、受入テスト
- 教育、移行
- 課題の対応状況に関するご報告
- 重要課題の発生状況と対応方針に関するご報告
- 課題管理表の棚卸
- 要求仕様の追加・変更に関するご報告
- 要求仕様管理状況ご報告
- ご連絡・ご依頼事項
- 全関係者様へのご連絡・ご依頼事項
- 個別のご連絡・ご依頼事項
プロジェクト進捗報告書の前半（1章、2章）の内容を確認したい場合は、以下の記事を参照してください。
-
-
参考進捗報告書を作成しよう（１）進捗報告（概要）~スケジュール
今回の記事は、プロジェクトの進捗報告資料作成がテーマとなります。 プロジェクトの進捗報告については、誰に対して何を報告するか、また報告対象や作業工程によって報告すべき内容は異なってきますが、今回はプロ ...
続きを見る
3.工程別詳細状況報告
前半では、プロジェクトの全体のサマリーについて報告してきましたが、後半では工程別の詳細な状況報告をしていきます。
工程別ということで、要件定義、設計、開発、テストという順番となりますが、基本的に複数プロジェクト同時並行でないような場合や、アジャイル開発でない場合は、特にウォーターフォールの場合には、基本的に工程が重複することはあまりないと思います。
工程ごとに報告すべき内容や観点が異なってきますが、それぞれの工程での進捗が明確にわかるように定性報告に加えて、定量的な報告も合わせて実施するようにしましょう
まずは定性報告を行い、そのあと定量報告を分けて行う（順序はどちらが先でもよい）といった報告がよいでしょう。
サンプルでは要件定義に関する報告内容を例としていますが、定性報告については、要件定義以外の他の工程についても同様の報告で問題ないでしょう。
以下は、報告のまとめ方の1つの例です。
- 今週の作業予定に対して、実績はどうだったのか。
- 予定分の内容がすべて検討できたのか、積み残しとなっているタスクや課題があるかどうか。
- 次週予定している作業は何か。積み残しについては、次回で消化できるのか、別途追加の調整が必要なのか。
- 今週発生した課題についての報告。※特にQCD（品質・コスト・納期）に影響するような内容は必ず報告に含めてください。
- 進捗遅延については、具体的にどのようにリカバリーするのか対策も報告する
図をクリックすると拡大表示されます。
続いて、以下は定量報告のサンプルとなります。要件定義フェーズの場合、定量報告する基準としてここでは成果物をベースにした報告を実施しています。
要件定義書（ドキュメント）の構成に対して、各章ごとに何ページ作成する予定で、それに対して報告時点でどの程度（何ページ）出来上がっているのかをもって進捗率を算出しています。
ここで重要なのは、「進捗率の何%ってどの程度仕上がっている状態なのか」を明確に定義してお客様と合意しておくことです。
下記の例では、0%を未着手とし、お客様の最終レビュー完了で90%としてます。
その間の作業中や内部レビューなど細かく分けていますが、細かくするほど管理が大変になるので、プロジェクトの規模や進捗管理担当者によって適切な管理粒度としてください。
また何をもって実績の頁数としてカウントするのかを明確にして、補足として記載しておくとよいでしょう。
ページ下段のグラフについては、スケジュールの進捗と同様、報告時点での計画に対する進捗が一目でわかるように添付してもよいでしょう。
※図の中の数値はランダムなものに差し替えています。
補足）
設計・開発フェーズでは、定量報告の指標として機能数ベースの成果物とするのが基本となります。
Salesforce〇〇システム 会計業務領域 NN機能 作成予定設計書数：NN件 開発プログラム：NN件
また、テストフェーズでは、計画数（テストシナリオ件数、ケース数）に対する実績数（消化済みシナリオ、ケース数）が一般的です。
さらに、品質管理の観点から、バグの検出率などについても報告したほうがよいでしょう。
バグについては、故障管理表などを用いて、どの工程でどのようなバグが何件発生したのか、定性的、定量的に把握し傾向分析を行い、結果によってテストケースの追加ややり直し等を検討する必要があります。
バグの内容やバグの傾向分析は必ず実施し、同じようなバグが多発している場合には、原因を特定し対策を検討してください。
また、同じようなバグがないかどうか必ず横展開して確認するようにしましょう。
まずは正しく状況を把握し、報告できるようにしましょう。故障管理表を用いた品質管理については、以下の記事を参考にしてください。
-
-
参考故障管理表（バグ管理表）（Excelテンプレート）サンプル
本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した故障管理表（バグ管理表）のテンプレートをご提供しております。 内部テストやユーザ受け ...
続きを見る
4.課題の対応状況
4-1.重要課題の発生状況と対応方針に関するご報告
プロジェクトのQCD（Quality、Cost、Delivery）に影響するような重要課題がある場合には、別途詳細な報告を行います。
課題については、これまでどうよう課題の内容に加えて、原因と対策をしっかり報告するようにしましょう。
特にこの場合、発生原因は重要で、例えば開発メンバーによるスキル不足により遅延が発生しマスタスケジュールの変更が必要な場合などには、開発ベンダー側に非があるため、追加コストは開発ベンダー側で負担しないといけない場合があります。
逆にお客様起因の場合には、追加費用は支払っていただくように調整する必要が出てきます。
4-2.課題・TODOの棚卸
タスク・課題管理の棚卸を実施する場合には、PPT（パワーポイント）のスライドで説明するよりも、課題管理のエクセルや課題管理ツールを使って報告したほうが効率的でしょう。
会議の時間も限られているため、無駄の内容に要点だけを伝え、状況を確認、報告するように心がけましょう。
課題管理ルーツについては、Backlog（バックログ）の利用がお勧めです。お客様や関係各社とタスク・課題の共有やファイルを共有することができ、プロジェクト管理には欠かせない機能がたくさんあります。
無料でお試しできますので、使ってみたいという方はこちらの記事を参考にしてください。
-
-
参考Backlog（バックログ）を使ってタスクやプロジェクト管理を効率化しよう
Backlogのご紹介 今回は、クリエイティブコンテンツラボトウキョウがお勧めするお勧めのタスク管理ツールであるBacklogをご紹介いたします。 Backlogは単純にタスクを管理するだけではなく、 ...
続きを見る
5.要求仕様の追加・変更に関するご報告
続いて、要求仕様の追加・変更に関する報告を行います。プロジェクト開始前にご提案した内容に対して、要件定義を進める中で、もともとお客様が要求していた機能について、変更や取り下げが発生したり、追加の要求が出てくる場合が多々あります。
こういった追加、変更についてお客様と都度合意せず曖昧に進めた結果、開発費用が当初見積もりの倍の金額になってしまい、お客様は予算枠が決まっているため、追加分のお金は払えないということになってしまう可能性があります。
できる限り、週次定例会などで都度お客様と確認するようにしましょう。
要求仕様の管理については、上記の目的以外にも、そもそもお客様の要件がもれなく定義されているか、実現方式や改善効果、優先度などを確認するためにも一覧に取りまとめて管理することを推奨します。
要求仕様管理一覧は、こちらの記事からダウンロードしてご利用いただけます。
-
-
参考要求仕様管理一覧（テンプレート）
本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した要求仕様管理一覧のテンプレートをご提供しております。 プロジェクト発足時点でお客様の ...
続きを見る
6.ご連絡・ご依頼事項
最後は、お客様や関係各社への連絡・依頼事項を記載します。
6-1.全関係者様へのご連絡・ご依頼事項
関係各社向けの連絡、依頼事項を記載します。
連絡事項に関しては、具体的に記載し、責任者と期限を明記するようにしましょう。また担当が決まった場合には、タスク管理ツールなどへ転記し進捗を管理するように心がけましょう。
6-2.個別のご連絡・ご依頼事項
お客様や個別の関係者様への連絡、依頼事項を記載します。
進捗報告書作成のまとめ
ここまでで進捗報告書作成の説明は以上となります。
最後に、本記事で説明した進捗報告書のテンプレートを利用したい方は、以下からダウンロードしてご利用ください。
-
-
参考プロジェクト進捗報告書（PPTテンプレート）サンプル
続きを見る
関連記事
