本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成したプロジェクトの進捗報告書のテンプレートをご提供しております。

1.ページサンプル

テンプレートPPTのサンプルがわかるようにイメージを添付します。（一部のみ）

2.進捗報告書（PPTテンプレート）の利用方法

進捗報告書（PPTテンプレート）の利用方法については、以下の記事を参考にしてください。

参考

進捗報告書を作成しよう（１）進捗報告（概要）~スケジュール

今回の記事は、プロジェクトの進捗報告資料作成がテーマとなります。 プロジェクトの…

続きを読む

3.進捗報告書（PPTテンプレート）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加

以下は、スプレッドシートでの表示となります。

まとめ

サポーターさん

テンプレートのご利用に関して不明な点があればお問い合わせください。また、テンプレートに対しての要望がありましたらご意見ください。 皆様の役に立つように改善していきたいと思います。

テンプレート関連の記事

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

もう一度、全体の章立てを掲載しておきます。後半では、このうち第3章以降の内容が対象となります。

プロジェクト進捗報告書の前半（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のご紹介 今回は、クリエイティブコンテンツラボトウキョウがお勧めす…

続きを読む

5.要求仕様の追加・変更に関するご報告

続いて、要求仕様の追加・変更に関する報告を行います。プロジェクト開始前にご提案した内容に対して、要件定義を進める中で、もともとお客様が要求していた機能について、変更や取り下げが発生したり、追加の要求が出てくる場合が多々あります。

こういった追加、変更についてお客様と都度合意せず曖昧に進めた結果、開発費用が当初見積もりの倍の金額になってしまい、お客様は予算枠が決まっているため、追加分のお金は払えないということになってしまう可能性があります。

できる限り、週次定例会などで都度お客様と確認するようにしましょう。

要求仕様の管理については、上記の目的以外にも、そもそもお客様の要件がもれなく定義されているか、実現方式や改善効果、優先度などを確認するためにも一覧に取りまとめて管理することを推奨します。

要求仕様管理一覧は、こちらの記事からダウンロードしてご利用いただけます。

参考

要求仕様管理一覧（テンプレート）

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

6.ご連絡・ご依頼事項

最後は、お客様や関係各社への連絡・依頼事項を記載します。

6-1.全関係者様へのご連絡・ご依頼事項

関係各社向けの連絡、依頼事項を記載します。

連絡事項に関しては、具体的に記載し、責任者と期限を明記するようにしましょう。また担当が決まった場合には、タスク管理ツールなどへ転記し進捗を管理するように心がけましょう。

6-2.個別のご連絡・ご依頼事項

お客様や個別の関係者様への連絡、依頼事項を記載します。

進捗報告書作成のまとめ

ここまでで進捗報告書作成の説明は以上となります。

最後に、本記事で説明した進捗報告書のテンプレートを利用したい方は、以下からダウンロードしてご利用ください。

参考

プロジェクト進捗報告書（PPTテンプレート）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

関連記事

プロジェクトの進捗報告については、誰に対して何を報告するか、また報告対象や作業工程によって報告すべき内容は異なってきますが、今回はプロジェクト開始から、お客様に週次定例会で報告するような内容を想定して解説していきたいと思います。

管理人

進捗報告をしっかり行うことでお客様に安心感を与えることができますし、信頼感を得ることにもつながるため、報告すべき内容をしっかり理解して報告書を作成しましょう。

大規模プロジェクトになってくると、上記以外にもより詳細な報告内容を求められることはありますが、中規模程度のプロジェクトでは上記内容で問題ないと思います。

※お客様によって求められる観点とか書式も異なるため一概には言えませんが、プロジェクトの特定に合わせて適宜変更してください。

1.前回定例会で発生したTODOの確認

定例会の場合には、前回の定例会で発生したTODOの進捗状況を確認する場を設けることが多いと思います。

先にプロジェクトの進捗報告を行うほうが良い場合もあります。会議の時間枠や重要な議題があるかどうかなどで、優先順位をつけてスライドを構成するようにしましょう。

また、課題・TODOについては以下のようなスライドにタイトルと内容（サマリー）を纏めて簡単に確認できるようにするとよいでしょう。

もしくは、バックログ（Backog）などの課題・タスク管理ツールを利用している場合には、課題を一覧で表示して状況の確認とアップデートを行うことでタスク管理の効率化が図れます。

エクセルなどで管理されている方は、一度こういったサービスを検討してみるのもよいと思います。

タスク・課題管理については、私もよく利用しているBacklog（バックログ）がお勧めです。お客様や関係各社とタスク・課題の共有やファイルを共有することができ、プロジェクト管理には欠かせない機能がたくさんあります。

無料でお試しできますので、使ってみたいという方はこちらの記事を参考にしてください。

参考

Backlog（バックログ）を使ってタスクやプロジェクト管理を効率化しよう

Backlogのご紹介 今回は、クリエイティブコンテンツラボトウキョウがお勧めす…

続きを読む

2.進捗状況（サマリー）ご報告

続いて、進捗状況のサマリーを報告するページを作成します。

ここでは、あくまでプロジェクト全体状況のサマリーの報告となるため一目でわかるように要点だけを簡潔に説明しましょう。

報告するお客さまがどの層の方なのかによって、記載内容や粒度は変えたほうが良いです。

経営に近い方が参加されるような場合には、QCD（品質、コスト、納期）に関する事項を優先して報告するようにしましょう。参加されるトップの人が何を知りたいのかを意識して資料を作成しましょう。

どうしても自社の視点で資料を作成してしまうことが多くなりがちですが、お客様の視点（または第三者の視点）に立って、報告することが大切になってきます。

報告内容は以下のように基本的に1つの事項に対して1、2行程度でまとめて状況を記載します。重要な事項や補足は別のページで詳細を報告します。

スケジュールの遅延が発生していたり、仕様変更や追加等でお客様の予算を超過しそうな状況が発生しているような場合には、状況と合わせて、具体的な対策を検討したうえで打ち合わせに臨むようにしましょう。

2-1.マスタスケジュールの計画に対する進捗状況の報告

全体の状況を簡単に報告したあとは、個別のサマリーを報告します。まずは、マスタスケジュールに対する進捗状況を報告します。

各工程間で多少のスケジュールの遅延があったとしてもマイルストーンの節目やリリース時期が遅延しないというのが最重要事項となります。

お客様は、システムリリースに向けて、エンドユーザとの調整や業務・運用切替の準備、検収・支払いなどで経理部門との調整を行うなど、多岐にわたっての調整・承認が必要となります。

またお客様自身のプロジェクト推進の評価にも直結するため、スケジュールに遅延がないかどうかは非常に気にされる事項となります。

報告日の時点で、スケジュールの遅延があるかないかをまずは明確に報告しておきましょう。

もし遅延が発生もしくは遅延のリスクがある場合には、正直に報告するとともに、リカバリー策を提示して承認をいただくようにしましょう。

例えば要件定義工程で要件の取りまとめが遅れており、4人日程度の遅延が発生しているといった場合には、週末の2日間に2名出勤して遅延をリカバリーするなど。※あまり休日出勤や残業してリカバリーというのは推奨できませんが、本番リリース直前など状況によっては、このような対策も講じる必要がでてきます。

遅延しているのをお客様に隠して、リカバリーもできなくなってから報告するような事態だけは避けるようにしましょう

2-2.工程別のスケジュールに対する進捗の報告

マスタスケジュールの進捗の次は、工程別の進捗状況サマリーを報告するページを用意します。

こちらでは、作業工程ごとの進捗（オンスケジュール、遅延あり（リカバリー可能）、遅延（リカバリ不可）、クリティカルな課題あり）など状況が一目でわかるようにアイコンを使って図示するなど工夫をするとよいでしょう。天気のアイコンなどで表現するとわかりやすいでしょう。

ポイントとしては、工程別に遅延が発生している場合には、その原因は何か具体的に記述することです。

また合わせてリカバリー策を検討し、記載しておきましょう。原因は、外部要因と内部要因に分けて記述し、それぞれに対して対策を検討するようにしましょう。

外部要因：

（発生原因）お客様側で課題の対応や仕様の検討が遅延している。お客様内部の承認プロセスが遅延しているなど。

（対策）期限を明確に設定して、いつまでに実施いただけない場合は、スケジュールの遅延が発生するなど、お客様にスケジュール遅延のリスクがあることを説明し、催促する。

内部要因：

（発生原因）テストケースの検討が遅延している。バグが大量に発生してバグ改修に時間がかかっているなど。

（対策）開発メンバーを増員して、バグの改修効率を上げる。

2-3.WBSベースの定量報告

工程別のスケジュール報告では、定量的な方向となりますが、続いては、WBSのタスクベースでの定量報告を行います。

ここでは、WBSのタスクを工程別などある程度の単位に取りまとめて集計した結果を報告するとよいでしょう。

計画に対して、現時点の完了率、達成率を集計し、遅延が発生している場合には、遅延しているタスクの数や遅延日数と合わせて備考欄に遅延内容や理由などを記述します。

また合わせて集計結果をグラフ化しておくとタスクの消化具合も一目でわかるので可能なら入れておきましょう。

WBSの集計は、タスク管理ツールを利用していれば自動的に集計される場合が多いと思います。

最初にご紹介したBacklogでもバーンダウンチャートでタスクの消化具合はトップページで確認することができます。工程ごとにバーンダウンチャートは表示されるため、Backlogをお使いの場合は、これをそのまま進捗報告資料に添付するやり方が効率的かと思います。

（Backlogのバージョンチャート）

2-4.遅延発生時のリカバリー策についてのご報告

これまでの報告の中で、進捗に遅延がある場合には、リカバリー策を報告するようにしましょう。

リカバリー策は、具体的で現実的な案としましょう。

まとめ

ここまでは、進捗報告のサマリー部分の報告内容となります。後半は、詳細な進捗報告とともに課題や仕様変更に関する報告の説明となります。

後半の内容を確認したい場合は、次の記事を参照してください

参考

進捗報告書を作成しよう（２）工程別詳細報告~その他連絡事項まで

プロジェクトの報告資料作成の後半は、各工程ごとの詳細な進捗報告とともに、課題の棚…

続きを読む