進捗報告の書き方｜顧客向けテンプレートと「進捗説明のためだけの会議」を減らす方法

この記事のポイント（TL;DR）

• 進捗報告の基本（定義・4ブロック構成・頻度・書き方の原則）は「【本題】顧客向けの進捗報告は、社内報告の何を変えるのか」より前でひととおりおさえます。急ぐ場合は目次から必要な章に飛んでください。
• 「進捗報告」で検索したときに1ページ目に並ぶ解説は、2026年9月時点でほとんどが上司や社内のマネージャーに上げる報告の話でした。この記事は、発注元である顧客に読ませる進捗報告に絞ります。
• 顧客向けで事故になりやすいのは、載せる情報を足し忘れることではなく、社内向けの情報を消し忘れることです。工数消化率・残バッファ・要員の稼働状況をそのまま出すと、報告が交渉材料になります。
• 報告書の全行に「次に誰の番か」を持たせると、催促が状態の共有に変わります。先方の宿題（素材・確認・承認）を自社の進捗と同じ表に並べるのが要点です。
• 週次レポートのテンプレート、顧客向けメール例文2本、パワポ1枚の割付は、すべて本文の中に置いています。ダウンロードは不要です。
• 「進捗説明のためだけの会議」は、報告の形を変えないと減りません。非同期に置き換えられる議題と、置き換えられない議題の判別表を載せます。
• 進捗報告を変えれば手戻りが何パーセント減る、という数字は載せていません。理由は「効果の数値を書いていない理由」で書きます。

---

進捗報告とは？進捗管理との違いと、報告する相手で変わるもの

進捗報告とは、案件やタスクが計画に対して今どこまで進んでいるかを、関係者が次の判断をできる形で伝えることです。単に「やったことを並べる」のとは違い、計画との差分と、その差分に対して誰が何をするのかまで含めて初めて報告として成立します。

進捗報告と進捗管理の違い

この2つは近い言葉ですが、担い手も目的も違います。

進捗管理ができていても進捗報告が機能していないケースは珍しくありません。社内の管理表には「顧客からの素材待ち」と正しく書いてあるのに、その事実が顧客に届いていない、という状態がその典型です。

「進捗状況」と「進捗報告」の使い分け

実務では「進捗状況を教えてください」「進捗状況の報告をお願いします」という言い方をよく使います。進捗状況は案件の現在地そのもの、進捗報告はそれを相手に伝える行為を指します。

顧客とのやり取りでは、この2つが混ざったまま会話が進むことがあります。「進捗状況はいかがですか」と聞かれたとき、相手が求めているのは現在地の数字なのか、それとも自分の宿題の確認なのか。多くの場合は後者です。聞かれてから答えるより、聞かれる前に両方を出しておくほうが、結果的にお互いの手間が減ります。

進捗報告のやり方は、3つの要素で決まる

進捗報告のやり方を決めるとは、次の3つを決めることです。

1. 頻度 — いつ出すか（「報告の頻度とタイミング」で扱います）
2. 中身 — 何を載せ、何を載せないか（骨格は「進捗報告に必ず入れる4ブロック」、書き方は「進捗報告の書き方 5原則」以降で扱います）
3. 手段 — どの形で届けるか（「報告の手段をどう選ぶか」で扱います）

この3つのうち、多くの解説は中身だけを扱います。しかし顧客との案件で問題になるのは、頻度と手段の設計であることが少なくありません。

報告する相手で、何が変わるのか

進捗報告は相手によって別物になります。ところが解説記事の多くは相手を「関係者」とひとまとめにしたまま書き方だけを説明するため、顧客に送る段になって手が止まります。

とくに最後の行が重要です。顧客に出した進捗報告は、後で「いつ、何を、どう伝えたか」の証拠になります。社内向けのメモとは、文書としての重みが違います。

この記事が扱うのは、右の列です。受託・制作・コンサルの案件責任者が、発注元に読ませる進捗報告をどう設計するか。上司への報告については、記事末尾のよくある質問で違いだけ触れます。

進捗報告に必ず入れる4ブロック

相手が誰であっても、進捗報告の骨格は4つのブロックでできています。まずこの型を押さえてから、顧客向けの調整に入ります。

1. 状態（報告書では「今週の状態」の欄）— 全体として計画どおりか、遅れているか、リスクがあるか。最初の1行で言い切る
2. 実績（報告書では「今週完了したこと」「進捗の数量」の2欄）— この期間に仕上がったものと、全体に対する到達度。作業の羅列ではなく、区切り（マイルストーン）に対してどこまで進んだか
3. 課題と対応 — 起きている問題と、それに対して誰が何をするか。問題だけを書かない
4. 次の予定（報告書では「次週の予定」の欄）— 次の期間にやること。日付と担当をつける

この4つのうち、どれか1つでも欠けると報告は機能しなくなります。状態がなければ全体像がつかめず、実績だけでは今後が読めず、課題に対応がなければ相手は不安になり、次の予定がなければ相手は自分の準備を始められません。

顧客向けの進捗報告では、この4ブロックに5つ目が加わります。

5. 依頼事項（報告書では「貴社へのお願い」の欄）— 相手にお願いすること。素材の提供、内容の確認、承認の3種類

なお顧客向けでは、3つ目の「課題と対応」は独立した欄にせず、日程に影響するものは状態と「遅れの内容」へ、判断が要るものは「ご決定をお待ちしている事項」へ振り分けるのが実務的です。「週次レポートのテンプレート」はその形になっています。

この5つ目こそが顧客向け報告の中心です。実際の報告書では、状態・実績の2欄・次の予定に、依頼・決定待ち・分担表・案内（末尾の「参考情報」）が加わって全8欄になります。その姿は「週次レポートのテンプレート」で示します。遅れがある週は、これに「遅れの内容」と「復旧のご提案」の2欄を足します（「遅延をどう書くか」で扱います）。分担表の作り方は「次に誰の番か」を1列で示す章から扱います。

「今週完了したこと」の欄でよくある失敗

4ブロックのうち、最も書き方の差が出るのが実績です。とりわけ「今週完了したこと」の欄で差が出ます。多くの報告は、ここに今週やった作業を時系列で並べます。

【悪い例：今週やった作業を時系列で並べる】
・9/1 定例会議
・9/2 デザイン修正対応
・9/2 メール返信
・9/3 実装作業
・9/4 進捗資料作成

これは日報であって、報告ではありません。読み手には、この案件が前に進んだのかどうかが分かりません。定例会議や資料作成は、案件を前に進めた成果ではなく、進めるために使った時間です。

この欄は、区切りに対する到達で書きます。

【良い例：区切りに対する到達で書く】
・トップページの実装完了（9/2）
・商品一覧ページのデザイン確定・貴社ご承認済（9/3）
・お問い合わせフォームの設計書提出（9/4）

この形にすると、書きながら自分でも気づけます。1週間かけて区切りを1つも通過していない週があれば、それは「今週完了したこと」の欄が空になるので隠せません。時系列の作業リストは、進んでいない週でも行数だけは埋まってしまうため、遅れの兆しを覆い隠します。

報告の頻度とタイミング｜日次・週次・月次と、契約類型による違い

報告の頻度は「丁寧なほど良い」わけではありません。頻度が高すぎると読まれなくなり、低すぎると手遅れになってから届きます。

頻度の選び方

定期報告と別に、すぐ出す場面

次のいずれかに当てはまるときは、次回の定期報告を待ちません。

• 納品日や公開日が動く可能性が出たとき
• 顧客の宿題が期限を過ぎ、日程に影響し始めたとき
• 決めてもらう必要のあることが新しく発生し、期限が定例日より前にあるとき
• 相手が別の前提で動いている兆候が見えたとき

4つ目は見落とされがちです。相手からのメールの言い回しが自分の認識とずれていると感じたら、それは報告のタイミングです。放置すると、後で「言った言わない」になります。

報告の手段をどう選ぶか

同じ内容でも、届け方によって残り方が変わります。

現実には、これらを組み合わせます。報告の実体は参照できる場所に置き、メールはそこへの案内にし、判断が必要なときだけ口頭を挟む。この形が、顧客との案件では最も破綻しにくい構成です。

契約類型で、報告の基準が変わる

請負と準委任では、報告が答えるべき問いが違います。

• 請負契約 — 完成が目的なので、報告の基準はマイルストーンです。「この区切りをいつ通過したか」「次の区切りはいつか」を軸にします
• 準委任契約（履行割合型） — 業務の遂行が目的なので、報告の基準は期間と稼働です。「この期間に何を行い、次の期間に何を行うか」を軸にします。この型では稼働工数が報酬の算定根拠になることが多く、稼働報告が契約上の義務になっていることがあります。その場合の稼働の開示は例外になります（詳細は開示境界の表のとおり）
• 準委任契約（成果完成型） — 2020年施行の改正民法が定める型で、報酬は成果に対して支払われます（民法第648条の2。準委任には第656条により準用）。成果が完成しなくても、引き渡せた部分に報酬が生じうる場合があります（完成できなくなった事由が委任者側にない場合や、完成前に解除された場合。同条第2項が準用する第634条）。報告では「どこまでが引き渡せる状態か」を区切りごとに残しておくと後で効きます。どちらの型かは契約書で確認してください

どちらの契約で、どの区切りを報告の単位にするかは、着手前に決めておくのが理想です。この点はキックオフミーティングで決めておくことで扱っています。報告の設計は、実はキックオフの時点でほぼ決まっています。

進捗報告の書き方 5原則

書き方の原則は、上司向けでも顧客向けでも共通です。顧客向けだけに効く調整は「【本題】顧客向けの進捗報告は、社内報告の何を変えるのか」から扱います。

1. 結論から書く

前置きを省き、最初の1行で全体の状態を言い切ります。読み手は最初の数秒で「自分が動く必要があるかどうか」を判断したいと考えています。

• 悪い例 — いつもお世話になっております。先週から進めております実装作業ですが、いくつか確認事項が出てまいりまして……
• 良い例 — 予定どおり進行しています。公開日に変更はありません。貴社へのお願いが3件あります

2. 事実を数値と日付で書く

「だいたい終わっています」「もう少しかかります」は、書き手と読み手で解釈がずれます。

• 悪い例 — 実装はかなり進んでいます
• 良い例 — 全15画面のうち11画面の実装が完了しました。残り4画面は9月18日完了予定です

3. 課題には必ず対応をつける

問題だけを書くと、読み手には「困っている」という情報しか届きません。誰が何をいつまでにやるのかまで書いて、初めて報告になります。

• 悪い例 — 決済連携で不具合が発生しており、調査中です
• 良い例 — 決済連携で不具合が発生しました。原因は特定済みで、弊社にて9月14日までに修正します。日程への影響はありません

4. 求める判断を明示する

相手に何かを決めてほしいなら、決めてほしいことと期限を書きます。「ご確認ください」だけでは、確認して終わるのか、返事が必要なのかが伝わりません。

• 悪い例 — 問い合わせフォームの設定についてご確認をお願いします
• 良い例 — 問い合わせフォームの送信先を、代表アドレスと担当者個人のアドレスのどちらにするか、9月17日までにお知らせください。それ以降になりますと、フォームの実装をやり直すことになります

5. 主観の言葉を使わない

進捗報告で最も危険な言葉は「順調です」です。この一語は書き手の主観であり、読み手にとって検証できません。しかも、書いた本人が問題に気づいていない場合と、気づいているが言いにくい場合の両方で使われます。

「順調です」の代わりに、状態を事実で書きます。

• 予定どおり — 9月30日の公開に向けて、計画どおり進んでいます
• 遅れの兆しあり — 現時点で2営業日の遅れがありますが、9月30日の公開日は維持できる見込みです
• 遅れ確定 — 9月30日の公開は難しく、10月7日への変更をご相談したい状況です

この3段階を使い分けるだけで、報告の信頼度は変わります。とくに2段目を書けるかどうかが分かれ目です。遅れの兆しの段階で共有できていれば、相手にとっては驚きではなく前提になります。

【本題】顧客向けの進捗報告は、社内報告の何を変えるのか

ここからが本題です。社内向けに書いた進捗報告を、宛先だけ変えて顧客に送ってはいけません。読み手の目的が根本的に違うからです。

上司はあなたの仕事を監督する立場にいます。だから上司向けの報告は、状況を余さず伝えるほど価値があります。工数の消化状況も、要員のやりくりも、リスクの生々しい見立ても、全部が判断材料になります。

顧客はあなたの仕事を監督しているのではありません。顧客は、あなたの報告を読んで自分の仕事を進めます。社内の稟議を通す、上長に説明する、自分の宿題に着手する、公開日に合わせて別の準備を始める。顧客にとっての進捗報告は、監督のための資料ではなく、自分が次に何をすればいいかを知るための資料です。

この違いから、顧客向けの報告では4つのことを変えます。

1. 出す情報の線引きを変える — 自社の内部事情は出さない。代わりに、相手の判断に必要な情報を足す
2. 主語を変える — 自社が何をやったかだけでなく、次に誰が動く番かを全行に持たせる
3. 決定待ち事項（報告書では「ご決定をお待ちしている事項」の欄）の扱いを変える — 相談事項ではなく、期限と影響を持つ台帳として出す
4. 置き場所を変える — 送って終わりではなく、いつでも参照できる場所に置く（考え方は「報告の手段をどう選ぶか」のとおりです。「進捗説明のためだけの会議」を減らす章で、前提としてもう一度扱います）

もう1つの調整：相手の言葉に置き換える

上の4点に加えて、書き方の原則にも顧客向けだけの調整が1つ入ります。自社の中で通じる言葉を、そのまま使わないようにすることです。

制作や開発の現場では、工程名・ツール名・社内の呼称が日常的に使われます。これを報告にそのまま持ち込むと、相手は意味を確認するために時間を使うか、確認せずに分かったつもりで読み飛ばします。どちらも困った結果になります。

すべての用語を言い換える必要はありません。基準は、相手がその言葉を使ってこちらに話しかけてきたことがあるかどうかです。相手が使っていない言葉は、こちらからも使いません。

なお、専門用語を完全に排除すると説明が長くなりすぎることもあります。その場合は用語を使ったうえで、初出時に括弧で短く補足します。毎回説明する必要はありません。

ここまでが変更点の概要です。順番に見ていきます。

出す情報と、出さない情報｜顧客向け報告の開示境界

顧客向け報告で事故になりやすいのは、情報を足し忘れることではありません。社内向けの情報を消し忘れることです。

社内の管理表をそのまま共有した、社内向けの報告書のフォーマットを流用した、という経緯で、出すつもりのなかった数字が顧客の手元に残ります。しかも本人は事故に気づきません。

期間指標の開示境界

顧客に出す進捗報告では、下記の項目に固有の判断が要ります。単に消すのではなく、何に翻訳して出すかまで決めておきます。

この表は、期間の状況を示す指標についてのものです。会議1回の記録（議事録）を顧客に共有するときの書き分けは論点が別で、発言者の扱い、検討段階の金額、他社名、前提条件とスコープ外の明記などが焦点になります。そちらは議事録の書き方で、社内向けと顧客向けの書き分けとして扱っています。

消し忘れが起きるのは、原本が1つしかないとき

事故の構造はほぼ共通しています。社内向けの1ファイルを使い回し、送る直前に消す運用にしていると、急いでいる週に消し忘れます。

安全なのは、社内向けの完全版を先に作り、そこから顧客向けの版を作る運用です。順序を逆にして、顧客向けを先に作ってから社内向けに書き足そうとすると、社内で必要な情報が抜け落ちます。

もう1つ有効なのが、顧客向け報告のフォーマットに、そもそも工数・原価・要員の欄を用意しないことです。欄がなければ、埋める習慣も生まれません。

出さないことと、隠すことは違う

ここまで「出さない」項目を並べてきましたが、これは不都合な事実を伏せることとは違います。線引きの基準は1つで、その情報が相手の判断に必要かどうかです。

要員が1人体調を崩したという事実は、相手の判断には要りません。相手にできることが何もないからです。しかしその結果として納品が3日ずれるなら、それは伝えます。伝えるのは体制の事情ではなく、日程への影響です。

逆に、伏せてはいけないものもあります。

• 納品日・公開日に影響が出る可能性があること
• すでに納品したものに不具合が見つかったこと
• 相手の宿題が遅れており、それが日程に影響し始めていること
• 当初の想定と違う仕様で作っていることに気づいたこと

これらは、こちらにとって都合が悪くても出します。判断の材料が発注側にないまま日程が進むと、後から分かったときの損害が大きくなります。そして、後で分かったという事実そのものが、それまでの報告全体の信頼を失わせます。

「相手にできることがあるか」で切り分けると、迷う場面は減ります。相手が何かを決められる、あるいは準備できるなら出す。相手にできることが何もない自社の事情なら出さない。この基準です。

「次に誰の番か」を1列で示す｜先方の宿題を並記する

一般的な進捗報告のテンプレートは、自社が何をやったか、次に何をやるかの1軸でできています。顧客向けでは、ここに1列足します。

この列の名前は「次の担当」です。今どちらが動く番なのかを、行ごとに1語で示します。この列を持つ表を、以降では分担表と呼びます（報告書では「現在の分担」の欄にあたります）。

なぜ同じ表に並べるのか

顧客の宿題を報告書の外に置くと、たいていメール本文の末尾に「お忙しいところ恐れ入りますが、素材のご提供をお願いいたします」という形で追記されます。これには2つの問題があります。

1つは、催促に見えることです。本文の最後にお願いだけが並ぶと、報告ではなく督促状の体裁になり、回を重ねるほど書きにくくなります。

もう1つは、記録に残らないことです。メール本文のお願いは、後から探せません。日程がずれたときに「いつからお願いしていたか」を示せなくなります。

自社の進捗と同じ表に並べると、この2つが同時に解決します。催促ではなく状態の共有になり、かつ報告書という参照可能な形で残ります。

分担表の書き方

進行中の行では、3列目に「弊社」「貴社」「第三者」のいずれかが必ず入ります。完了した行だけが「—」になります。空欄を作らないのが要点です。空欄があると、そこは誰も動いていない項目になります。

第三者の行を独立させているのにも意味があります。審査・法務確認・外部APIの提供元など、自社にも顧客にも動かせない待ちがあると、それを書かないかぎり「何も進んでいない期間」に見えてしまいます。

顧客の宿題は3種類しかない

受託・制作・コンサルの案件で顧客にお願いすることは、突き詰めると3つに分かれます。

3つを区別せずに「ご対応をお願いします」とまとめると、相手はどれから手をつけるか判断できません。とくに承認は、担当者ではなく決裁者の時間が必要です。承認が要ると分かった時点で伝えないと、期限の直前に判明して間に合いません。

相手の行を書くときの言葉づかい

分担表に相手の行を並べることに、抵抗を感じる人は少なくありません。催促していると受け取られないか、という懸念です。

書き方で解決できます。要点は、相手の状態を評価しないことです。

左側は状態を評価する言葉で、右側は事実を述べる言葉です。伝えている内容は同じですが、受け取られ方が変わります。

期限を過ぎた項目についても、色を変えたり感嘆符をつけたりする必要はありません。期限の日付をそのまま残しておけば、過ぎていることは相手にも分かります。強調しないほうが、かえって事実として伝わります。

ご決定をお待ちしている事項｜期限と、決まらなかった場合の影響

進捗報告の多くは、決めてもらう必要のあることを「相談事項」や「課題」の欄にまとめます。ここまでは一般的な解説にも書かれています。

書かれていないのは、決まらなかった場合に何がどれだけずれるかです。これがないと、相手は急ぐべきかどうかを判断できません。

台帳の形

■ ご決定をお待ちしている事項

1. 会員データの移行範囲（全件 / 直近3年分）
   ご決定期限：10月2日（金）
   期限を過ぎた場合：移行リハーサルが1回分実施できず、切替日が 11月4日 → 11月11日 に変更となります

2. 退会済み会員の扱い（削除 / 匿名化して保持）
   ご決定期限：10月9日（金）
   期限を過ぎた場合：単独では日程への影響はありません（10月下旬までは吸収可能です）

3. 旧システムの停止日
   ご決定期限：10月16日（金）
   期限を過ぎた場合：旧システムの保守契約が自動更新され、貴社に1か月分の費用が発生します

「影響なし」の行を、あえて混ぜる

3項目のうち2番目には、期限を過ぎても日程に影響しないと書いてあります。これは意図的です。

すべての項目を等しく急がせると、どれも急がれなくなります。全部が赤字で「至急」と書かれた報告は、受け取る側からは全部が同じ重さに見え、結果としてどれも動きません。

影響のない項目を正直に「影響なし」と書くことで、影響がある項目の重みが伝わります。そして相手からの信頼も上がります。急ぐ必要のないものを急がせない人の「これは急ぎです」は、信じてもらえます。

決まったことは、決定として残す

決定待ち事項は、決まった瞬間に台帳から消えます。ただし消すだけにすると、後から「いつ、誰が、何を決めたか」が分からなくなります。

決まったものは、次回の報告の「今週完了したこと」の欄に「10月2日、移行範囲は直近3年分で決定」と1行残します。報告書の中に決定の履歴が積み上がっていくと、案件の終盤で経緯を掘り返す手間がなくなります。決定を記録として残す手順は議事録の書き方で扱っています。

遅延をどう書くか｜書き直しの例と、復旧案を2案で出す

遅延の報告は、進捗報告で最も書きにくい部分です。そして最も差が出る部分でもあります。

よくある遅延報告と、その問題点

【悪い例：状況を説明して、判断材料を出さない】

いつもお世話になっております。
今週の進捗についてご報告いたします。

実装作業を進めておりますが、想定より工数がかかっており、
スケジュールがやや厳しい状況です。
できる限り巻き返せるよう対応してまいりますので、
何卒よろしくお願いいたします。

この報告には、相手が動くために必要な情報が1つも入っていません。どれだけ遅れているのか、公開日は動くのか動かないのか、自分は何かすべきなのか。すべてが不明です。

「できる限り巻き返す」という一文は、書き手には誠実さの表明ですが、読み手には何も伝えません。むしろ、次の報告でさらに悪い知らせが来る予感だけを残します。

書き直した例

【良い例：遅れの幅・復旧2案・判断期限を出す】

■ 今週の状態
現時点で3営業日の遅れが出ています。
ご判断の内容により、9月30日の公開を維持するか、10月7日に変更するかが決まります。
いずれの場合も、9月11日（金）までのご判断が前提です。

■ 遅れの内容
商品一覧ページの絞り込み機能について、当初想定していない
条件の組み合わせが判明し、設計の見直しに3営業日を要しました。
（弊社の設計時の確認不足によるものです）

■ 復旧のご提案（いずれかをお選びください）
公開日維持案
    絞り込み機能を「カテゴリのみ」に限定して9月30日に公開し、
    価格帯・在庫での絞り込みは10月中旬に追加リリースします。
    → 公開日は動きません。初回公開時の機能が一部限定されます。

機能維持案
    絞り込み機能を当初の仕様どおり実装し、公開日を10月7日に変更します。
    → 機能は当初のままです。公開日が1週間後ろにずれます。

■ ご決定をお待ちしている事項
9月11日（金）までにいずれかをお知らせください。
それ以降になりますと、公開日維持案を選択いただいた場合でも
9月30日の公開が難しくなります。

この例はメール本文ではなく、報告書の中の該当セクションです。同じ内容をメールでどう案内するかは「顧客向け進捗報告メールの例文2本」で扱います。

遅延報告で守る4つのこと

1. 謝罪と事実を分ける — 詫びる文と、状況を説明する文を混ぜない。「申し訳ありませんが想定より時間がかかっており」と続けると、事実がぼやける。詫びは詫びとして短く独立させ、事実は事実として書く
2. 原因の帰属をごまかさない — 自社起因なら自社起因と書く。顧客の宿題の遅れが原因なら、責める書き方をせず事実として書く。どちらでもない外部要因なら、そう書く。ここを曖昧にすると、後で費用負担の話になったときに揉める
3. 復旧案は2つ出す — 「公開日維持案」と「機能維持案」のように、何を守るかを名前にして並べる。1案だけだと相手は選べず、案なしだと相手が考える羽目になる。何を犠牲にするかは、本来は発注側が決めること
4. 判断の期限を書く — いつまでに決めてもらえれば間に合うのか。この期限がないと、遅延の報告そのものが宙に浮きます

早く出すほど、選べる案が増える

遅延報告を出しにくいのは、確定してから伝えたいという心理が働くためです。しかし確定してからでは、選べる案が減っています。

3営業日の遅れの段階なら、機能の縮小か日程の変更かを選べます。2週間の遅れになってから伝えると、日程の変更しか残りません。「進捗報告の書き方 5原則」で挙げた「遅れの兆しあり」の段階で出すことに意味があるのは、このためです。

週次レポートのテンプレート｜項目とサンプル文

ここまでの内容を1枚にまとめたのが、次のテンプレートです。空欄の表だけを渡されても書けないので、各項目にサンプル文をつけています。そのままコピーして使えます。

週次進捗報告テンプレート

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
コーポレートサイトリニューアル 週次進捗報告
2026年9月4日（金）｜第6回｜報告者：株式会社◯◯ 田中
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■ 今週の状態
予定どおり進行しています。
9月30日の公開日に変更はありません。
貴社へのお願いが3件あります（期限：9月9日・9月10日）。
※状態は「予定どおり」「遅れの兆しあり」「遅れ確定」の3つから選ぶ
※状態・日程への影響・貴社へのお願いの件数を1行ずつ。この3行が決裁者の読む範囲になる

■ 今週完了したこと
・トップページの実装（9/2 完了・メインビジュアルは差し替え待ち）
・商品一覧ページのデザイン確定（9/3 貴社ご承認済）
・お問い合わせフォームの設計書提出（9/4）
・決済サービスの利用申請を提出（9/4・手数料の負担区分は8/28にご決定済）
※作業の羅列ではなく、区切りに対して何が終わったかを書く
※貴社の承認を得たものは「ご承認済」と日付つきで残す

■ 進捗の数量
全15画面のうち、11画面の実装が完了しています（残り4画面）。
※工数の消化率ではなく、成果物の数量で書く

■ 次週の予定
・商品詳細ページの実装（9/8〜9/11・弊社）
・お問い合わせフォームの実装着手（9/11・弊社）
・商品一覧ページ実装の完了（9/11・弊社）

■ 現在の分担
┌────────────────────┬──────────────────────────┬──────────┬──────────┐
│ 項目               │ 状態                     │ 次の担当 │ 期限     │
├────────────────────┼──────────────────────────┼──────────┼──────────┤
│ 商品一覧ページ実装 │ 進行中                   │ 弊社     │ 9/11     │
│ 掲載写真データ     │ お待ちしています         │ 貴社     │ 9/9      │
│ 会社概要ページ原稿 │ ご確認をお願いしています │ 貴社     │ 9/10     │
│ 決済サービス審査   │ 申請済・審査中           │ 第三者   │ 9/18予定 │
└────────────────────┴──────────────────────────┴──────────┴──────────┘
※「次の担当」を必ず埋める。空欄の行は誰も動いていない行になる

■ ご決定をお待ちしている事項
1. トップページのメインビジュアル（A案 / B案）
   ご決定期限：9月10日（木）
   期限を過ぎた場合：公開日が 9月30日 → 10月7日 に変更となります

2. 問い合わせフォームの項目確定
   ご決定期限：9月17日（木）
   期限を過ぎた場合：単独では日程への影響はありません

■ 貴社へのお願い（再掲・期限が近い3件）
・掲載写真12点のご提供（JPEG・長辺1500px以上）｜9月9日まで
・会社概要ページ原稿のご確認（文言と役職表記のみ）｜9月10日まで
・メインビジュアルのご決定（A案 / B案）｜9月10日まで
※素材・確認・承認を区別して書く
※「ご確認ください」で終わらせず、見てほしい範囲を限定する

■ 参考情報
・進捗の詳細と最新の資料はこちらから随時ご確認いただけます
　（案件ページのURL）
・次回報告：2026年9月11日（金）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

送信前チェックリスト

書き終えたら、送る前に7項目を確認します。

1. 最初の1行で、状態と日程への影響を言い切っているか
2. 「順調です」「だいたい」「かなり」など、検証できない言葉が残っていないか
3. 分担表の「次の担当」に空欄がないか
4. 貴社へのお願いに、それぞれ期限が入っているか
5. 決定待ち事項に、決まらなかった場合の影響が書かれているか
6. 工数・原価・要員の稼働状況・社内の懸念が残っていないか
7. 前回お願いした項目が、まだ未完了のまま消えていないか

6番目と7番目が特に重要です。6番目は事故の防止、7番目は宿題が静かに消えるのを防ぐためです。前回の報告でお願いした項目が今回の報告から消えていると、相手は「もう不要になった」と受け取ります。

報告書をどこに置くか

置き場所そのものの選び方は顧客と共有できるプロジェクト管理ツールにまとめています。

「わかりやすい進捗報告」とは何か｜30秒と3分の2階層設計

「わかりやすく書きましょう」という助言は、それ自体がわかりにくいものです。何をもってわかりやすいとするかの基準がないからです。

顧客向けの進捗報告では、わかりやすさを読み手の所要時間で定義します。

• 決裁者は30秒で、案件が問題ないかどうかを判断できること
• 担当者は3分で、自分がいつまでに何をすべきかを特定できること

この2人は同じ報告書を読みますが、読む深さが違います。だから報告書は2階層にします。

上30秒に置くもの

冒頭に置くのは3つだけです。状態、日程への影響、貴社へのお願いの件数。この3点が3行に収まっていれば足ります。

■ 今週の状態
（状態）予定どおり進行しています。
（日程）◯月◯日の公開日に変更はありません。
（依頼）貴社へのお願いが3件あります（期限：◯月◯日・◯月◯日）。

決裁者はここだけ読んで、問題があるかどうかを判断します。3行に「変更はありません」と書いてあれば、それ以上は読みません。それでいいのです。

下3分に置くもの

今週完了したこと、進捗の数量、次の予定、分担表、ご決定をお待ちしている事項、貴社へのお願いの詳細。担当者はここを読んで、自分の作業を組み立てます。なお末尾の「参考情報」は報告の中身ではなく、置き場所と次回日程への案内なので、2階層の外側に置きます。

順番を逆にしない

読みにくい報告の多くは、この2階層が逆になっています。今週やった作業を時系列で並べ、最後まで読むと実は公開日が動くと書いてある、という構成です。

読み手の立場では、最も重要な情報が最後に来る文書は読むのが苦痛です。しかも途中で読むのをやめた人には、最も重要な情報が届きません。

情報を減らすのではなく、順番を変える

わかりやすくするために情報量を削るのは、多くの場合で逆効果です。削られるのは書きにくいこと（遅れ、リスク、相手の宿題）からで、結果として当たり障りのない報告が残ります。

減らすのではなく、順番を変える。判断に必要な情報を上に、作業に必要な情報を下に。これだけで読みやすさは変わります。

顧客向け進捗報告メールの例文2本

報告書を置く場所を決めたら、メールは短くなります。メールの役割は、状態を1行で伝え、報告書へ案内し、期限のあるお願いを再掲することの3つです（判断をお願いする回だけ、要点を本文にも置きます）。

例文1：週次の定例報告

件名：【進捗報告 9/4】コーポレートサイトリニューアル（第6回）

株式会社△△
山田様

いつもお世話になっております。株式会社◯◯の田中です。
今週の進捗をご報告いたします。

■ 状態
予定どおり進行しています。9月30日の公開日に変更はありません。

■ 貴社へのお願い（3件）
・掲載写真12点のご提供（JPEG・長辺1500px以上）｜9月9日まで
・会社概要ページ原稿のご確認（文言と役職表記のみ）｜9月10日まで
・メインビジュアルのご決定（A案 / B案）｜9月10日まで

詳細な進捗と資料は、下記の案件ページにまとめております。
（案件ページのURL）

ご不明な点がございましたら、お気軽にお知らせください。
次回のご報告は9月11日（金）を予定しております。

株式会社◯◯ 田中

件名に日付と回数を入れているのは、後から探しやすくするためです。「進捗のご報告」だけの件名が並ぶと、何週目のものか区別がつきません。

例文2：遅れを含む報告

同じ第6回の報告を、遅れが出た場合に書き換えるとこうなります。

件名：【進捗報告 9/4・ご判断のお願い】コーポレートサイトリニューアル（第6回）

株式会社△△
山田様

いつもお世話になっております。株式会社◯◯の田中です。
今週の進捗と、ご決定をお待ちしている事項についてご報告いたします。

■ 状態
現時点で3営業日の遅れが出ています。
ご判断の内容により、9月30日の公開を維持するか、10月7日に変更するかが決まります
（メインビジュアルを9月10日までにご決定いただいた場合）。

■ 遅れの内容
商品一覧ページの絞り込み機能について、当初想定していない条件の
組み合わせが判明し、設計の見直しに3営業日を要しました。
弊社の設計時の確認不足によるものです。ご迷惑をおかけし申し訳ございません。

■ ご決定をお待ちしている事項（絞り込み機能・いずれか）
公開日維持案：絞り込みを「カテゴリのみ」に限定して9月30日に公開し、
　　　　　　　価格帯・在庫での絞り込みを10月中旬に追加リリースする
機能維持案：絞り込みを当初仕様どおり実装し、公開日を10月7日に変更する

9月11日（金）までにお知らせいただけますと幸いです。
それ以降になりますと、公開日維持案でも9月30日の公開が難しくなります。

■ 貴社へのお願い（再掲・3件）
・掲載写真12点のご提供（JPEG・長辺1500px以上）｜9月9日まで
・会社概要ページ原稿のご確認（文言と役職表記のみ）｜9月10日まで
・メインビジュアルのご決定（A案 / B案）｜9月10日まで

判断材料として、両案の詳細を案件ページにまとめております。
（案件ページのURL）

株式会社◯◯ 田中

件名に「ご判断のお願い」を入れているのは、通常の報告と区別するためです。定例の報告メールは、忙しい週には後回しにされます。判断が必要な回だけ件名で知らせておくと、開封が早くなります。

謝罪の一文は、事実の説明の直後に1回だけ置いています。冒頭から詫び続けると、何が起きたのかが伝わりません。

パワポ1枚にまとめる場合の割付

定例会で投影する、あるいは先方の社内会議でそのまま使ってもらう目的で、報告を1枚のスライドにまとめることがあります。

1枚に載せるのは4つの区画だけです。

下段の右側に相手の欄を集めているのは、投影したときに視線が右へ流れるためです。左半分で状況を把握し、右側で自分の宿題を確認する、という読み方になります。

1枚に載せないものも決めておきます。

• 今週やった作業の全リスト（区切りの通過状況に要約する）
• ガントチャートの全体像（変更があった箇所だけを抜く）
• 課題管理表の全件（今週動いたものだけ）
• 工数・原価・要員に関する一切の情報

1枚に収まらないときは、フォントを小さくするのではなく、載せる情報を減らします。読めないスライドは、ないのと同じです。詳細は報告書に書いてあり、スライドはその入口だと割り切ります。

「進捗説明のためだけの会議」を減らす

進捗報告を丁寧にしているのに、定例会議の時間が減らない。むしろ報告資料を作るために時間が増えている。これは受託の現場でよく起きる逆転です。

原因は、報告と会議が二重になっていることにあります。報告書を作り、その報告書を会議で読み上げ、会議の議事録をまた作る。同じ情報が3回加工され、そのたびに時間が使われます。

会議そのものが悪いわけではありません。減らせるのは、進捗を説明するためだけに開かれている部分です。

その議題は、非同期に置き換えられるか

定例会の議題を、置き換えられるものと置き換えられないものに仕分けます。

上の3つを会議から外すだけで、定例会は短くなります。読み上げに使っていた時間がそのまま消えるためです。どの程度短くなるかは案件によりますが、まず自分たちの直近の定例で、上の3つに何分使っているかを測ってみてください。

会議を減らす前に、揃っている必要がある3条件

ただし、報告の形を変えないまま会議だけを減らすと、情報が消えます。次の3つが揃っていることが前提です。

1. 報告が決まった場所にある — 毎回同じURLで、最新版と過去分の両方が見られること。メールに添付する運用のままだと、探せない情報は存在しないのと同じになります
2. 先方が読んだかどうかが分かる — 読まれていない報告を前提に会議を減らすと、当日になって「聞いていない」が起きます。確認状況が見えていれば、読まれていない週だけ声をかければ済みます。読まれているかどうかの見分け方は「報告が読まれていないときに、どう気づくか」で扱います
3. 決定が同じ場所に残る — 会議を減らすと、決定が個別のメールやチャットに散ります。決めたことが報告と同じ場所に積み上がる形にしておかないと、後から経緯を追えなくなります

3つ目が抜けていると、半年後に「あれは誰がいつ決めたのか」を探すことになります。これは会議を減らしたことによる副作用ではなく、置き場所を用意しないまま減らしたことによる結果です。

段階的に減らす

いきなり定例会をなくすと、相手に不安を与えます。順序をつけて減らします。

第1段階で「会議では読み上げをやめる」と決めるとき、相手に一言伝えておきます。「事前に報告をお送りしますので、会議ではご質問とご判断だけをいただければと思います」と最初に合意しておくと、進めやすくなります。

会議を減らすことが目的ではない

念のため書いておくと、目的は会議を減らすことそのものではありません。目的は、判断が必要なときに早く判断できる状態を作ることです。

会議を減らした結果として判断が遅れるなら、それは減らしすぎです。とくに立ち上がり直後と、仕様が動いている時期は、会議の回数を維持したほうが結果的に早く終わります。減らすのに向いているのは、実装や制作が安定して進んでいる中盤です。

進捗報告がうまくいかない5つの原因と対策

報告の形を整えても機能しないことがあります。多くは次の5つのどれかです。

原因1：相手の宿題が片側にしか見えていない

自社のタスクは管理ツールで追跡されているのに、顧客の宿題はメールの文面にしか存在しない。この非対称が、待ちを長引かせます。

顧客側も忘れているわけではなく、多くは自分の宿題が何件あって期限がいつなのかを一覧で持っていません。分担表に相手の行を並記するのは、相手のためでもあります。

原因2：頻度が案件に合っていない

週次で十分な案件に日次で報告して疲弊する。逆に、動きの速い立ち上げ期に月次のままで、気づいたときには方向がずれている。どちらも頻度のミスマッチです。

対策は、フェーズごとに頻度を見直すことです。立ち上がりは細かく、安定期は粗く、山場の前後でまた細かく。着手時に決めた頻度を最後まで守る必要はありません。変えるときは相手に理由とともに伝えます。

原因3：報告書と実態が食い違い、参照されなくなる

報告書はメールに添付、資料はファイル共有サービス、決定はチャット、タスクは管理ツール。こうなると、どこかで食い違いが生まれやすくなります。

一度でも報告書と実態が食い違うと、相手は報告書を信じなくなります。そして確認のための問い合わせが増え、その対応でまた時間が減ります。

対策は、情報の置き場所を減らすことです。すべてを1か所にできなくても、少なくとも「最新の状況を見る場所」は1つに決めます。報告書に書いてある内容が、その場所を見れば裏取りできる状態にします。

原因4：読んでも、次に何をすべきかが書かれていない

報告はしている、相手も読んでいる。それでも何も動かない。これは報告に判断の依頼が含まれていない場合に起きます。

「ご確認ください」で終わる報告は、確認して終わります。何を決めてほしいのか、いつまでか、決まらないと何が起きるのかを書いて、初めて相手は動けます。「ご決定をお待ちしている事項」の台帳は、このための道具です。

原因5：楽観的な報告が積み上がる

毎週「順調です」と報告し続けて、終盤で一気に遅れが露見するパターンです。書き手に悪意はなく、多くは「まだ挽回できる」と思っている間に時間が過ぎます。

対策は、状態を主観ではなく事実で書くことです。「進捗報告の書き方 5原則」で挙げた3段階（予定どおり／遅れの兆しあり／遅れ確定）を使い、2段目を使うことを恥ずかしがらない運用にします。

もう1つ有効なのが、進捗を残日数ではなく残量で書くことです。「あと1週間で終わります」は希望を含みますが、「残り4画面」は事実です。残量が減っていない週が2回続けば、本人も周囲も気づけます。

この5つに共通しているのは、報告の文章力の問題ではないという点です。書き方を磨くより、置き場所と項目の設計を変えるほうが効きます。顧客と同じものを見る状態をどう作るかはクライアントワークの解説でも扱っています。

報告が読まれていないときに、どう気づくか

進捗報告の設計をどれだけ整えても、読まれていなければ意味がありません。そして読まれていないことは、たいてい手遅れになってから判明します。

読まれていない案件に出る3つの兆候

1. 報告書に書いてあることを、あらためて質問される — 「公開日はいつでしたっけ」「あの機能は入る予定でしたか」。これは相手を責める場面ではなく、報告が届いていないことを示す信号です
2. 依頼した項目に、期限が来ても反応がない — 断りでも延期の相談でもなく、無反応が続く。読まれていないのか、読まれたが自分の宿題だと認識されていないのかは、この兆候だけでは切り分けられません（切り分け方は「確認状況が、打ち手を切り分ける」で扱います）
3. 相手の社内で、別の前提の話が進んでいる — 先方の上長から、こちらの報告と食い違う内容の質問が来る。決裁者まで情報が届いていないケースです

読まれない理由は、たいてい相手の怠慢ではない

読まれない報告に共通するのは、長いこと、相手の欄がないこと、そして件名から「判断が要るのか、見るだけでよいのか」が読み取れないことです。いずれも「わかりやすい進捗報告」とは何かの章で扱った2階層設計と、分担表で解消できます。相手の読む力ではなく、こちらの設計の問題として扱ってください。

確認状況が、打ち手を切り分ける

「反応がない」の原因は、読まれていないのか、読まれたが相手の社内で止まっているのかの2つに分かれます。この2つを外から見分ける手がかりが、先方がその報告を開いたかどうかという確認状況です。打つ手は原因によって逆になります。読まれていない週は、催促ではなく「今週は判断をお願いしたい件が1件だけあります」と要点だけを短く送り直します。読まれているのに反応がない週は、内容ではなく相手の社内で止まっている可能性が高いので、決裁者への説明資料が要るかどうかを聞きます。

確認状況が分からないままだと、どちらの場合も同じ催促を繰り返すことになり、関係も消耗します。それでも催促が必要になったときの文面は、顧客への催促メールの例文に場面別・段階別でまとめています。

案件のフェーズで、報告の中身は変わる

同じ案件でも、フェーズによって相手が知りたいことは変わります。着手時に決めたフォーマットを最後まで使い続けると、途中から中身が実態に合わなくなります。

とくに検収前のフェーズは、報告の性質が変わる場面です。それまでは自社の進捗を伝えていたのが、検収前には相手に作業をお願いする文書になります。

何をどこまで見てもらう必要があるのか、いつまでに指摘をもらえれば修正が間に合うのか、指摘はどの経路で受け付けるのか。これらを報告に書いておかないと、検収が長引きます。検収の合格条件そのものは着手前に決めておくべき事項で、キックオフミーティングで決めておくことに含まれます。

フェーズを変えるときは、変えることを相手に伝えます。「来週から実装フェーズに入りますので、報告の形式を変更します」の一言があるかないかで、受け取り方が変わります。

工期が予定どおりにならない要因は何か｜調査で確認できること

進捗報告を丁寧にしても案件が遅れるとき、原因を自分たちの作業スピードに求めがちです。調査データを見ると、要因はもう少し複雑です。

一般社団法人 日本情報システム・ユーザー協会（JUAS）の『企業IT動向調査報告書2026』では、工期が予定より遅延したと回答した企業に、その要因を尋ねています。2025年度調査の結果は次のとおりです。上位だけを抜くと解釈を誤るため、全項目を載せます。

（出典：一般社団法人 日本情報システム・ユーザー協会『企業IT動向調査報告書2026』図表7-1-8「システム開発の工期が予定どおりにならなかった要因（複数回答）」 https://juas.or.jp/cms/media/2026/04/JUAS_IT2026.pdf 2026年9月6日確認。母数は工期について「予定より遅延」と回答した企業 n=297。調査全体はアンケート実施期間 2025年9月5日〜10月24日、対象は東証上場企業とそれに準じる企業 計4,500社、回収 957社／有効回答率 21.3%）

この調査が言っていること、言っていないこと

計画と仕様に関わる要因（計画時の考慮不足・想定以上の複雑さ・仕様変更の多発）が高い一方で、3番目には社員のスキル不足が入っています。同報告書はこの点を明示していて、当該節の見出しは「予定どおりにいかない要因は、3大要因とともにスキル不足の傾向がより顕著に」であり、本文でも「品質・工期においては『社員のスキル不足』が『仕様変更の多発』を上回る要因になり」と述べています。品質についてはベンダーのスキル不足が59.9%で最大の要因です（図表7-1-6、品質について「不満」と回答した企業 n=172）。図表7-1-8 とは母数の異なる別の設問です。

つまりこの調査は「遅れは作業能力の問題ではない」とは言っていません。計画・仕様の要因と能力の要因が、同程度の重みで並んでいるというのが実際のところです。

引用にあたって、範囲も明確にしておきます。

• 回答しているのは発注側です。ユーザー企業のIT部門長を対象とした調査であり、受託側の自己申告ではありません
• 対象はシステム開発です。Web制作・デザイン・コンサルティングなど他の受託業務にそのまま当てはまるとは限りません
• これは要因の分布であって、進捗報告との因果関係を示すものではありません
• 同報告書はQCD（品質・予算・工期）の悪化に影響する工程として要件定義と設計・実装・テストを挙げています。同報告書の本文が示す57.4〜69.0%と51.7〜74.1%は品質・予算・工期を横断したレンジで、工期単独では要件定義69.0%、設計・実装・テスト51.7%です（図表7-1-9、工期 n=174）。図表7-1-8（n=297）とは母数の異なる別の設問である点にご注意ください

この記事の設計が効く範囲

そのうえで、この記事の設計と接続できることを1つだけ書きます。

要因のうち、進捗報告の作り方で手が届くのは計画・仕様の側だけです。決まっていないことを期限つきで可視化し、仕様変更を決定として記録に残すことは、報告書の設計で改善できます。決定待ち事項に、期限と、決まらなかった場合の影響まで書く理由はここにあります。

一方、社員やベンダーのスキル不足は報告書の書き方では解けません。採用・育成・体制の問題です。報告でできるのは、それが日程に影響し始めた時点を早く共有することまでです。ここを混同して「報告を変えれば遅れが解決する」と読むと、打つべき手を間違えます。

効果の数値を書いていない理由

この記事には「進捗報告を改善すると手戻りが何パーセント減る」といった数値がありません。書けないからです。

進捗報告の形式と案件の成否を結びつけた調査を、一次ソースで確認できませんでした。報告の改善と工期の改善に相関があったとしても、両方が「案件の管理が丁寧な会社」という別の要因から生じている可能性を排除できません。

確認できない数値を書けば、記事は説得力を持ちます。しかし、その数値を根拠に社内を説得した読者が、後で根拠のなさに気づく結果になります。ここでは、検証できることだけを書いています。

よくある質問（FAQ）

まとめ

顧客向けの進捗報告は、自社の作業実績を伝える文書ではありません。自社と顧客のどちらが次に動く番かを、双方で確認するための文書です。この一点が、上司向けの報告と決定的に違うところです。

この記事で扱ったことを、4つに整理します。

1. 消し忘れが最大の事故 — 工数消化率、残バッファ、要員の稼働状況、社内のリカバリ判断は顧客向けには出しません（契約上の例外は本文の開示境界の表のとおりです）。伏せるだけでなく、成果物ベースの進捗や、条件つきのリスク表現に翻訳して出します
2. 全行に「次に誰の番か」を持たせる — 相手の宿題（素材・確認・承認）を自社の進捗と同じ表に並べます。催促が状態の共有に変わり、記録としても残ります
3. 決定待ちには期限と影響を書く — 決まらなかった場合に何日ずれるかまで書きます。影響のない項目は正直に「影響なし」と書くことで、影響がある項目の重みが伝わります
4. 会議を減らすには、置き場所が先 — 報告が決まった場所にあり、先方が読んだかどうかが分かり、決定が同じ場所に残る。この3つが揃わないまま会議だけ減らすと、情報が消えます

書き方を磨くより、項目の設計と置き場所を変えるほうが効きます。今週の報告から、分担表に相手の行を1行足すところだけでも変えてみてください。相手の宿題が相手にも見える状態になれば、こちらから催促する回数は減っていきます。