進捗報告の書き方と例文 週報テンプレートと遅れの報告メール

進捗報告とは、計画に対して今どこまで進んでいるかを、読む人が次の判断をできる形で伝える文書です。 「順調です」「少し遅れています」といった感想ではなく、状態（順調・注意・遅延）、数字（進捗率・遅れ日数）、次にやること、相談したいことの順に書くと、短くても伝わります。

この記事では、エンジニアがそのまま使える日次・週次・月次のテンプレートを、Markdown とチャット用テキストの両方で載せます。遅れを伝えるときの型と9パターンの文例、進捗率の4つの出し方の比較と Python による検算もまとめました。題材は架空の「社内の備品予約システム」の開発です。

確認環境：Ubuntu 24.04 / Python 3.11.15（進捗率の計算例を実行）。

進捗報告の書き方の早見表

どの報告でも、書く順番は同じです。

状態を「順調・注意・遅延」の3つで伝える

状態は最初の1語で伝えます。 読む人は、順調なら数字を確認するだけ、注意なら見守る、遅延なら対応を決める、と読み方を切り替えられます。判定の基準はチームで先に決めておくと、人によって言葉の重さが変わりません。次の表は基準の一例です。

「注意」は、回復策と回復予定日を書ける状態です。回復の見込みを書けない場合は、遅れの日数が小さくても「遅延」として早めに伝えるほうが、打てる手が多く残ります。

3つの状態の例文（日次・週次・月次）

日次の報告テンプレート

日次の報告は、昨日・今日・困りごとの3点を3〜5行で書きます。朝の短い打ち合わせで話す内容を、そのまま文字にする形です。

Markdown 版（記入例）です。

## 日次報告 2026-10-08(木) 鈴木

- 状態: 注意
- 昨日やったこと
    - 予約一覧画面の実装を完了し、レビューを依頼(完了)
    - 予約の変更: 日時の重なり判定を実装中(8割)
- 今日やること
    - 予約の変更の実装を完了し、単体テストを実施する
- 困っていること・相談
    - 取り消し期限(利用開始の1時間前)の判定に使う時刻を、サーバーの時刻でよいか確認したい(佐藤さんへ)

チャット用テキストです。記号だけで区切り、スマートフォンでも1画面に収まる長さにします。

【日次 10/8 鈴木】状態：注意
■昨日：予約一覧画面を完了（レビュー依頼済み）／予約の変更は8割
■今日：予約の変更を完了し、単体テストまで
■相談：取り消し期限の判定はサーバーの時刻でよいですか？ @佐藤

空欄のテンプレートです。

【日次 （日付） （名前）】状態：（順調・注意・遅延）
■昨日：（完了したこと）／（途中のものは割合）
■今日：（終わらせること）
■相談：（無ければ「なし」）

週次の報告（週報）テンプレート

週報は、先頭の3行（状態・進捗率・要約）だけで全体が分かるように書きます。詳細は下の表に回します。

Markdown 版（記入例、状態は「注意」）です。

# 週報 2026-10-05〜10-09 備品予約システム開発(鈴木)

- 状態: 注意
- 進捗率: 41.7%(計画 50.0%) / 遅れ 1.25日 ※50-50法で算出
- 要約: 予約一覧画面まで完了。予約の変更で想定より1日多くかかった。取り消しを高橋さんと分担し、10/14 に計画へ戻す見込み。

## 今週やったこと

| 作業 | 予定 | 結果 | 補足 |
|---|---|---|---|
| 予約登録画面 | 完了 | 完了 | レビュー指摘 2 件を反映済み |
| 予約一覧画面 | 完了 | 完了 | 並び順を利用開始日時の昇順に変更 |
| 予約の変更 | 完了 | 着手(8割) | 日時の重なり判定の条件が 3 件増えた |
| 予約の取り消し | 完了 | 着手(5割) | 期限の判定方法を確認中 |
| 通知メール | 着手 | 着手(3割) | 文面の確定待ち |

## 来週やること

| 作業 | 完了予定日 | 担当 |
|---|---|---|
| 予約の変更 | 2026-10-13 | 鈴木 |
| 予約の取り消し | 2026-10-14 | 鈴木、高橋 |
| 通知メール | 2026-10-16 | 鈴木 |

## 課題・リスク

| No | 内容 | 影響 | 対応 | 期限 |
|---|---|---|---|---|
| 1 | 通知メールの文面が確定していない | 10/13 を過ぎると通知メールの完了が遅れる | 田中さんから利用部門へ確認を依頼済み | 2026-10-09 |

## 相談・お願い

- 取り消し期限の判定に使う時刻について、10/13 の定例で決定をお願いします。

チャット用テキスト（同じ内容の短縮版）です。

【週報 10/5〜10/9 鈴木】状態：注意
進捗率 41.7%（計画 50.0%）／遅れ 1.25日
■完了：予約登録画面、予約一覧画面
■途中：予約の変更 8割／取り消し 5割／通知メール 3割
■来週：変更 10/13、取り消し 10/14（高橋さんと分担）、通知メール 10/16
■課題：通知メールの文面が未確定（田中さんが確認依頼済み、回答期限 10/9）
■お願い：取り消し期限の判定に使う時刻を、10/13 の定例で決めてください

空欄のテンプレートです。

【週報 （期間） （名前）】状態：（順調・注意・遅延）
進捗率 （ ）%（計画 （ ）%）／遅れ （ ）日
■完了：
■途中：（作業名と割合）
■来週：（作業名と完了予定日）
■課題：（内容・影響・対応・期限）
■お願い：（無ければ「なし」）

週報の文を具体的にする書き直し例

月次の報告テンプレート

月次の報告は、作業の細部ではなく、節目の達成状況・工数の予定と実際・リスクを中心に書きます。読む人は開発の詳細を知らない場合があるため、作業名より「何ができるようになったか」で表します。次の記入例は、リリース日を 11/13 とした別の日程で書いています。

# 月次報告 2026年10月 備品予約システム開発

- 報告日: 2026-10-30(金) / 報告者: 佐藤
- 状態: 注意
- 要約: 節目 3 件のうち 2 件を予定どおり達成。結合テストの開始が 2 日遅れたが、テスト期間内に回復し、リリース日(11/13)への影響はない。

## 節目の達成状況

| 節目 | 予定日 | 達成日 | 結果 |
|---|---|---|---|
| 要件の確定 | 2026-10-09 | 2026-10-09 | 予定どおり |
| 実装の完了 | 2026-10-16 | 2026-10-16 | 予定どおり |
| 結合テスト開始 | 2026-10-19 | 2026-10-21 | 2 日遅れ |

## 進み具合と工数

| 項目 | 予定 | 実際 | 差 |
|---|---|---|---|
| 進捗率(月末時点) | 75.0% | 73.3% | -1.7 ポイント |
| 工数(10月) | 40 人日 | 43 人日 | +3 人日 |
| 工数(累計) | 60 人日 | 63 人日 | +3 人日 |

- 工数が 3 人日増えた理由: 予約の変更で、日時の重なり判定の条件が 3 件増えたため。

## 今月できるようになったこと

- 予約の登録・変更・取り消しが、テスト環境で一通り操作できる。
- 予約の前日に通知メールが届く。

## リスクと対応

| No | リスク | 起きた場合の影響 | 対応 | 担当 |
|---|---|---|---|---|
| 1 | 受け入れテストで文言の修正が多く出る | 修正に 2 日程度かかる | テスト前に画面の文言一覧を利用部門へ共有する | 田中 |

## 来月の予定

| 節目 | 予定日 |
|---|---|
| 結合テスト完了 | 2026-11-04 |
| 受け入れテスト | 2026-11-09〜11-11 |
| リリース | 2026-11-13 |

## 判断・支援をお願いしたいこと

- なし

チャット用テキストです。

【月次 2026年10月 備品予約システム開発】状態：注意
■要約：節目3件中2件を予定どおり達成。結合テスト開始が2日遅れたが回復済み。リリース日（11/13）への影響なし
■進捗率：73.3%（予定 75.0%）
■工数：10月 43人日（予定 40人日、+3人日。重なり判定の条件が3件増えたため）
■来月：結合テスト完了 11/4／受け入れテスト 11/9〜11/11／リリース 11/13
■リスク：受け入れテストでの文言修正 → 事前に文言一覧を共有（田中）
■お願い：なし
詳細：（報告書の保存場所）

遅れの報告は5項目の型で書く

遅れを伝えるときは、「遅れ日数・原因・影響・回復策・判断してほしいこと」の5項目をこの順番で書きます。読む人が知りたいのは「どのくらい」「どこに響くか」「どうするか」「自分は何を決めればよいか」だからです。

遅れの程度によって、伝える相手と手段を変えます。

遅れの報告文例9パターン（程度別・手段別）

程度（小・中・大）と手段（メール・チャット・口頭）の組み合わせで、9パターンを載せます。

遅れが小さいとき（1〜2日・担当の範囲で回復できる）

パターン1：メール

件名：【進捗報告・注意】予約の変更が1日遅れています（10/14に回復見込み）

佐藤さん

鈴木です。予約の変更について、状況を報告します。

・遅れ日数：計画より1日遅れています（完了予定 10/9 → 10/13）。
・原因：日時の重なり判定で、確認する条件が1件増えたためです。
・影響：後ろの作業（予約の取り消し）の着手が1日遅れます。結合テストの開始日（10/19）への影響はありません。
・回復策：通知メールの作業を半日前倒しで進めており、10/14 に計画へ戻る見込みです。
・お願い：ご判断いただく点はありません。10/14 の時点で、あらためて状況を報告します。

パターン2：チャット

【進捗・注意】予約の変更が1日遅れています
・原因：重なり判定の条件が1件増えた
・影響：取り消しの着手が1日遅れ。結合テスト開始（10/19）には影響なし
・回復：通知メールを前倒しで進め、10/14 に計画へ戻る見込み
・お願い：特にありません。10/14 に再度報告します

パターン3：口頭

予約の変更が、計画より1日遅れています。
重なり判定の条件が1件増えたのが理由です。
結合テストの開始日には影響しません。
通知メールを前倒しで進めていて、14日には計画に戻る見込みです。
今のところ、お願いしたいことはありません。

遅れが中くらいのとき（3〜5日・分担や順番の調整が必要）

パターン4：メール

件名：【進捗報告・遅延】予約の変更が3日遅れています（分担変更のご相談）

佐藤さん

鈴木です。予約の変更で遅れが出ているため、報告と相談です。

1. 遅れ日数
 予約の変更が計画より3日遅れています（完了予定 10/9 → 10/14）。

2. 原因
 日時の重なり判定の条件が、設計時の2件から5件に増えました。
 10/6 の要件ヒアリングで追加された3件（繰り返し利用、準備時間、複数備品の同時予約）の影響です。

3. 影響
 このままでは、予約の取り消しと通知メールの完了が 10/21 になり、
 結合テストの開始（10/19）が2日後ろにずれます。リリース日（10/30）には影響しません。

4. 回復策
 予約の取り消し（2人日）を高橋さんに担当してもらえれば、10/16 に実装が完了し、
 結合テストを 10/19 に開始できます。高橋さんには、作業に入れることを確認済みです。

5. 判断をお願いしたいこと
 高橋さんの担当を、テストデータの作成から予約の取り消しへ 10/13〜10/14 の2日間入れ替えてよいか、
 本日 17 時までにご判断をお願いします。
 テストデータの作成は 10/15〜10/16 に行い、結合テストの開始には間に合います。

パターン5：チャット

【進捗・遅延】予約の変更が3日遅れています（先ほど口頭でお伝えした件の記録です）
・遅れ：完了予定 10/9 → 10/14
・原因：重なり判定の条件が 2件 → 5件に増加（10/6 のヒアリングで3件追加）
・影響：このままだと結合テスト開始が 10/19 → 10/21。リリース日（10/30）は影響なし
・回復策：取り消し（2人日）を @高橋 さんが担当 → 結合テストは 10/19 に開始できる
・決定：@佐藤 さんの承認により、10/13〜10/14 は高橋さんが取り消しを担当。テストデータ作成は 10/15〜10/16 に移動

パターン6：口頭

5分ほどよろしいですか。予約の変更で遅れが出ているので、相談させてください。
計画より3日遅れていて、完了は14日になる見込みです。
重なり判定の条件が、先週のヒアリングで2件から5件に増えたのが理由です。
このままだと、結合テストの開始が19日から21日にずれます。リリース日には影響しません。
取り消しの実装を高橋さんにお願いできれば、19日の開始に間に合います。高橋さんには確認済みです。
高橋さんの担当を2日間入れ替えてよいか、今日中に決めていただけますか。

遅れが大きいとき（節目やリリース日に影響する）

パターン7：メール

件名：【重要・進捗報告】リリース日（10/30）に5日の影響が出る見込みです（10/14 までにご判断のお願い）

佐藤さん
（写し：利用部門 山本様）

鈴木です。リリース日に影響する遅れが見込まれるため、報告します。
本日 14 時に口頭でお伝えした内容の詳細です。

1. 遅れ日数
 実装の完了が計画より5日遅れる見込みです（10/16 → 10/23）。

2. 原因
 カレンダー連携について、想定していた項目（利用者の所属）が連携先から取得できないことが、
 10/9 の調査で分かりました。所属を別の方法で取得する処理（5人日）が新たに必要です。

3. 影響
 結合テスト、受け入れテストがそれぞれ5日後ろにずれ、リリース日が 10/30 から 11/6 になります。
 利用部門で予定している 11/2 からの利用開始に影響します。

4. 対応案
 A案：カレンダー連携を今回の範囲から外し、10/30 にリリースする。
   連携は 11/20 の追加リリースで提供する。当面、所属は利用者が画面で選ぶ。
 B案：範囲を変えず、リリース日を 11/6 にする。利用開始は 11/9 からとなる。
 C案：メンバーを1名追加し、10/30 のリリースを目指す。
   引き継ぎに2日かかるため、間に合うかどうかは 10/20 の時点で再度判断する。
 開発チームとしては、利用開始日を守れるA案を推奨します。

5. 判断をお願いしたいこと
 A案・B案・C案のどれで進めるか、10/14（水）の定例までにご判断をお願いします。
 A案の場合は、連携を後から提供することについて、利用部門のご了承が必要です。

判断の材料として、各案の日程と作業の一覧を添付します。

パターン8：チャット（第一報）

【重要・第一報】リリース日（10/30）に影響する遅れが見込まれます
・内容：カレンダー連携で、利用者の所属が取得できないことが判明（本日の調査）
・影響：追加の処理に5人日。このままではリリースが 11/6 になる見込み
・次の動き：対応案を3つ整理し、本日 17 時までにメールで送ります
@佐藤 さん 15 時以降で15分、お時間をいただけますか

パターン9：口頭

お時間をいただきありがとうございます。リリース日に影響する遅れが見込まれるので、先にお伝えします。
実装の完了が5日遅れ、このままではリリースが10月30日から11月6日になります。
カレンダー連携で、利用者の所属が取得できないことが今日の調査で分かり、別の処理が5人日分必要になったためです。
利用部門の11月2日からの利用開始に影響します。
対応案は3つあります。連携を後のリリースに回して30日を守る案、リリース日を6日にする案、メンバーを追加する案です。
チームとしては、連携を後に回す案を推奨します。
14日の定例までに、どの案で進めるかを決めていただけますか。詳細は17時までにメールでお送りします。

遅れの報告で意識したい3点

進捗率の出し方：4つの方法の比較

進捗率は、出し方によって同じ状況でも数字が大きく変わります。 報告には、どの方法で出したかを1語添えると、読む人が数字の意味を取り違えません。

0-100法と50-50法は、「完了」「着手」という事実だけで決まるのが長所です。担当者に「何割ですか」と聞かずに済み、数字が感覚でぶれません。

計算例と Python での検算

8件・合計30人日の作業で、4つの方法を計算します。計画では今日までに15人日（50.0%）が終わっている想定で、2名で1日に2人日進める前提です。

"""進捗率を4つの方法で計算して比べる。 実行: python3 progress.py"""

# (作業名, 見積もり工数[人日], 状態, 担当者が申告した進み具合[%])
TASKS = [
    ("予約登録画面",   5, "完了",   100),
    ("予約一覧画面",   3, "完了",   100),
    ("予約の変更",     4, "着手",    80),
    ("予約の取り消し", 2, "着手",    50),
    ("通知メール",     3, "着手",    30),
    ("管理者画面",     6, "未着手",   0),
    ("CSV取り込み",    2, "未着手",   0),
    ("権限チェック",   5, "未着手",   0),
]
PLANNED_TODAY = 15   # 計画では今日までに終わっているはずの工数[人日]
PER_DAY = 2          # 1日に進められる工数[人日]（2名で作業）

total = sum(t[1] for t in TASKS)
done_count = sum(1 for t in TASKS if t[2] == "完了")

RULE_0_100 = {"完了": 1.0, "着手": 0.0, "未着手": 0.0}
RULE_50_50 = {"完了": 1.0, "着手": 0.5, "未着手": 0.0}

earned = {
    "重み付け(工数×申告)": sum(e * p / 100 for _, e, _, p in TASKS),
    "0-100法":             sum(e * RULE_0_100[s] for _, e, s, _ in TASKS),
    "50-50法":             sum(e * RULE_50_50[s] for _, e, s, _ in TASKS),
}

print(f"全体: {len(TASKS)}件 / {total}人日  計画: {PLANNED_TODAY}人日 ({PLANNED_TODAY / total:.1%})")
print(f"{'件数基準':<14} {done_count}/{len(TASKS)}件 = {done_count / len(TASKS):.1%}")
for name, ev in earned.items():
    gap = PLANNED_TODAY - ev
    print(f"{name:<14} 完了した量 {ev:>5.1f}人日 = {ev / total:.1%}  計画との差 {gap:>4.1f}人日 → 遅れ {gap / PER_DAY:.2f}日")

実行結果です。

全体: 8件 / 30人日  計画: 15人日 (50.0%)
件数基準           2/8件 = 25.0%
重み付け(工数×申告)    完了した量  13.1人日 = 43.7%  計画との差  1.9人日 → 遅れ 0.95日
0-100法         完了した量   8.0人日 = 26.7%  計画との差  7.0人日 → 遅れ 3.50日
50-50法         完了した量  12.5人日 = 41.7%  計画との差  2.5人日 → 遅れ 1.25日

同じ状況でも、進捗率は 25.0%〜43.7%、遅れは 0.95日〜3.50日と幅があります。読み取れることは次の3点です。

どの方法を選ぶか

重み付けを使う場合は、「設計が終われば 30%、実装が終われば 70%、テストが終われば 100%」のように、区切りと割合を先に決めておくと、申告が感覚に左右されにくくなります。どの方法でも、途中で方法を変えないことが大切です。変えた週は、前の週と数字を比べられなくなります。

報告を続けやすくする工夫

よくある質問

Q. 進捗率は何%刻みで報告すればよいですか？ A. 計算で出た数字をそのまま使うのが基本です。0-100法や50-50法なら、作業の状態から機械的に決まるため、刻みを考える必要がありません。担当者の申告で出す場合は、0・30・70・100 のように区切りを決めておくと、「85%」と「90%」の違いを説明する手間が減ります。

Q. 遅れているけれど、自分で回復できそうです。報告は必要ですか？ A. 報告します。状態は「注意」とし、遅れ日数・回復策・回復予定日を書きます。回復できた場合はそのまま「順調」に戻せばよく、回復が難しくなった場合も、先に共有してあれば周りが早く動けます。

Q. 書くことが無い週は、どう書けばよいですか？ A. 完了した作業が無い週でも、途中の作業の進み具合（何件中何件、どの区切りまで）、分かったこと、来週の完了予定日を書けます。「調査の結果、A の方法では実現できず、B の方法に切り替えた」も立派な進み具合です。

Q. メールとチャットのどちらで報告すればよいですか？ A. 急ぎの度合いと、記録として残す必要で選びます。当日中に共有したい小さな遅れはチャット、判断を求める内容や社外の相手にはメールが向いています。重要な遅れは、まず口頭で伝えてから文字で記録を残すと、伝わる早さと正確さの両方を確保できます。

まとめ

• 進捗報告は「状態・数字・やったこと・次にやること・課題と相談」の順で書く。
• 状態は「順調・注意・遅延」の1語で最初に示し、判定の基準をチームで決めておく。
• 日次は3〜5行、週報は先頭3行で全体が分かる形、月次は節目・工数の予定と実際・リスクを中心にする。
• 遅れの報告は「遅れ日数・原因・影響・回復策・判断してほしいこと」の5項目で書く。
• 遅れが大きいほど、口頭の第一報→メールで詳細の順に、対応案と推奨を添えて伝える。
• 進捗率は出し方で数字が変わる（計算例では 25.0%〜43.7%）。方法を報告に添え、途中で変えない。
• 短い作業に分けてあれば 0-100法、数日の作業が多ければ 50-50法が、事実だけで決まり扱いやすい。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。