「今どこまで？」 に答えられる僕が使う進捗共有テンプレ

クライアントを不安にさせない途中経過の伝え方

クライアントが本当に不安になる瞬間はいつか、知っていますか？

バグが出たときでも納期が遅れそうなときでもありません。

「何も聞こえてこないとき」です。

沈黙が不安を育てた、 あの炎上の記憶

フリーランスになって数年が経った頃、僕はある案件で炎上を経験しました。

仕様が曖昧なまま進んだプロジェクト。
積み重なる修正依頼。
ある日、クライアントから届いたメッセージ。

その言葉が刺さったのは、進んでいたからでした。

バグと格闘しながらも、着実に実装は進んでいた。
でも、その事実をクライアントに伝えていなかった。
僕は「完成してから報告すればいい」と思っていたのです。

相手は違いました。
完成を待っているのではなく、生きているか確認したかったのです。

沈黙は、信頼の消耗です。
何も言わないことで、クライアントの頭の中に最悪のシナリオが育っていく。
「今どこまで？」という質問は、不安が限界に達したサインだったのです。

この経験が、僕の進捗共有設計を変えました。

途中経過を見せることへの 3 つの誤解

進捗共有を後回しにしてしまう理由は、だいたい以下の 3 つです。

【誤解 1】 完成してから報告すればいい

完成品を渡して「お待たせしました！」が一番インパクトがある。
——そう思っていました。
実際には、完成まで沈黙が続くことで、クライアントは不安を大きくしていきます。

途中経過を見せることは、未完成を晒す恥ずかしさではなく、プロジェクトが生きていることの証明なのです。

【誤解 2】 問題がなければ連絡不要

問題が起きたときだけ連絡する、というスタイルでやっていた時期がありました。
これは、クライアント側から見ると「問題が起きていないなら、なぜ何も言わないの？」という疑問になります。

順調なときこそ、共有する価値があります。
「問題なく進んでいます」を伝えるだけで、相手の不安は大幅に減る。

【誤解 3】 詳しく報告するほど誠実

これについては進捗報告を「3行」に削る記事で詳しく書きましたが、長文報告は相手の脳を疲れさせます。

誠実さは文字数ではなく、タイミングと頻度で伝わります。

吃音の僕が、 なぜテキスト報告にこだわるのか

少し個人的な話をします。

僕は吃音症で、口頭での報告が非常に苦手です。
電話で進捗を伝えようとすると言葉が詰まり、焦りで余計に詰まる。
「今どこまで？」という質問に、まともに答えられないことが何度もありました。

だからこそ、テキストでの報告は僕にとって「生命線」でした。
口で伝えられない分、書いて伝える。
書いて合意を取る。書いて信頼を積む。

フリーランス 15 年の中で、吃音の僕が案件を安定して継続できてきたのは、この「書いて伝える」設計を磨いてきたからだと思っています。

途中経過の共有も同じです。
「言いにくいから後回し」ではなく、「言いにくいからこそ、型を持って先に送る」
——この姿勢が、僕のクライアントワークを支えてきました。

【進捗共有の型】 タイミング × 内容 × 頻度

進捗報告（どう短く書くか）は既存の記事に譲るとして、今回は「途中経過の設計」
——いつ、何を、どの頻度で共有するかに絞って共有します。

【タイミング】 節目に必ず送る

節目とは、以下のような区切りのことです。

📌 着手時:
作業を始めたことを伝える
（「本日着手しました」）

📌 半分経過時:
工程の半分が終わったことを伝える

📌 問題発生時:
詰まりや不確定要素が出てきたとき、すぐに伝える

📌 完了見込み更新時:
当初見込みから変化があったとき

完成したときだけではなく、これらの節目で送ることで、クライアントは「プロジェクトが動いている」を常に感じられます。

【書く内容】 「現在地」「次のアクション」「確認事項」

節目ごとの報告には、この 3 点だけ入れます。

【現在地】
〇〇機能の実装完了。現在△△のテストを進めています。

【次のアクション】
本日中にテスト完了予定。明日の午前中にはステージング環境に反映します。

【確認事項（あれば）】
〇〇の仕様について 1 点確認させてください。
[具体的な質問]
いつまでにご回答いただけますと助かります。

「確認事項」がない場合は省略してかまいません。
あるときだけ追記するからこそ、「これは返信が必要なメッセージだ」と相手に伝わります。

【頻度】 案件規模に応じた基準

| 案件規模 | 報告頻度の目安 |
|:--|:--|
| 短期案件（1 週間以内） | 1 日 1 回・進捗があれば都度 |
| 中期案件（1 ヶ月程度） | 2〜3 日に 1 回 |
| 長期案件（3 ヶ月以上） | 週 1 回の定期報告＋節目都度 |

頻度が多すぎると相手の負担になり、少なすぎると不安になる。
このバランスは、案件開始時のキックオフで「週次報告でよいですか？」と合意しておくと、お互いに楽です。

【実物テンプレート】 3 種類の状況別フォーマット

実際に僕が使っているテンプレートを公開します。
コピペして使えるように、そのまま貼っています。

【テンプレ 1】 着手報告

お世話になっております。

本日より〇〇案件の作業を開始しました。

【本日の着手内容】
△△の実装から着手。環境確認と初期設定を完了。

【今週の予定】
水曜日までに△△の実装を完了。
木曜日から□□のテストを開始予定。

【スケジュールに変更が生じる場合は都度ご連絡します】

引き続き、よろしくお願いいたします。

【テンプレ 2】 中間報告 （順調なとき）

お世話になっております。中間報告です。

【現在の進捗】
全体の約 60% が完了。〇〇機能・△△機能の実装が終わり、
現在□□機能の実装を進めています。

【当初スケジュールとの比較】
現時点では予定通り。〇〇日の納品に変更はありません。

【次の報告】
〇〇日（水）に最終確認前の報告をお送りします。

【テンプレ 3】 問題発生時の報告

問題発生時は「沈黙して考え続ける」が最悪のパターンです。
解決していなくても、発生を伝えます。

お世話になっております。
1 点ご報告があります。

【状況】
〇〇の実装中に、△△の挙動が想定と異なることを確認しました。

【現在の対応】
現在原因を調査中です。
本日中に原因の特定と対応方針をお伝えできる見込みです。

【スケジュールへの影響】
現時点で〇〇日の納品に影響はない見込みですが、
本日中に判断できない場合は改めてご連絡いたします。

ご心配をおかけして申し訳ありません。

問題報告の鉄則は「悪いニュースほど早く」です。
解決してから報告しようとすると、その間に相手の不安は最大化します。
「まだ解決していないが、動いている」を伝えるだけで、信頼は保てます。

途中経過を共有するクセを作る

テンプレを手元に置いても、送るタイミングを忘れてしまうことがあります。

僕が使っているのは、Obsidian の案件ノートに「進捗共有チェック」を仕込む方法です。

## 〇〇案件 進捗共有チェック

- [ ] 着手報告（〇〇日）
- [ ] 中間報告（〇〇日）
- [ ] 問題発生時 即時報告
- [ ] 最終確認前報告（〇〇日）
- [ ] 納品報告（〇〇日）

案件を開始したら、このチェックリストを作って日付を入れる。
それだけで「今日、報告する日だ」が一目で分かります。

進捗共有のタイミング管理を、記憶ではなく仕組みに任せる。
吃音症で「言いにくいこと」をつい先延ばしにしてしまう僕には、この仕組みで送る設計がとても助かっています。

途中経過は信頼の積み立てである

進捗共有の本質は、情報伝達ではなく、信頼の積み立てだと思っています。

「この人は、ちゃんと動いている」
「問題があっても、隠さずに教えてくれる」
「黙って抱え込まない」

これが積み重なることで、また頼みたいという継続につながります。

吃音症の僕が電話を使わずに信頼を築いてきた理由の一つは、沈黙を恐れて先に伝えるクセを持っていたからかもしれません。
口で言えない分、書いて送る。
声が出なくても、文字なら届く。

途中経過を共有することは、未完成を晒すことではなく、一緒に進んでいることの証明です。

あなたのクライアントが「今どこまで？」と聞いてくる前に——先に届けてみませんか？

Q&A 募集

途中経過の共有について、こんなことで悩んでいませんか？

💭 「報告が多すぎる」「少なすぎる」と言われたことがある
💭 問題発生時に何をどこまで伝えればいいか分からない
💭 クライアントごとに報告スタイルが変わって統一できない
💭 長期案件で「いつ報告すればいい？」と毎回迷う

上記のような状況、あるいは別の悩みがあれば、コメントや X でシェアしてください。
回答できるものは次の記事や Q&A ダイジェストで取り上げます。

ひとりごと

沈黙が信頼を消耗するという感覚、今でも鮮明に覚えています。

あの炎上案件のクライアントから「今どこまで？」と届いたメッセージを読んだとき、ちゃんと作ってるのに、なんで怒られてるんだろうと思いました。

でも相手の立場から見たら、「何も聞こえてこない = 何かまずいことが起きているのでは」でしかないんですよね。

人は見えないものを悪い方向に想像する。
だから見せる。
まだ完成していなくても動いていることを。

吃音症で「言う」が苦手な僕にとって、「書いて伝える」は最初からの選択肢でした。
今は、それが苦手を強みに変えてくれた気がしています。

口で伝えられない分、文字で届ける。
声が出なくても誠実さは伝わる。

そう思えるようになるまで、少し時間がかかりましたけれど。

あわせて読みたい

▼ 報告の書き方を短く・読みやすく整えたいときに

「どのタイミングで報告するか」の設計が今回の記事なら、「どう短く書くか」の技術がこちら。
15 年かけて磨いた 3 行テンプレと、長文報告が伝わらない理由を解説しています。
セットで読むと進捗共有の全体が整います。

▼ 打ち合わせ後の言った言わないを防ぎたいときに

進捗共有と並んで重要な合意の記録について。
打ち合わせ後 5 分で書ける合意形成テンプレートを公開しています。
途中経過の報告と合わせて使うと、言った言わないが構造的に起きなくなります。

▼ 案件開始時に期待値を握る設計を知りたいときに

進捗共有の頻度と形式は、キックオフで合意しておくと後がずっと楽になります。
事前に「どんな報告が望ましいか」を確認するための質問リストと、キックオフメールの設計を解説しています。

次の一歩を一緒に決める 「作戦会議室」 へ

途中経過の伝え方一つとっても、案件の規模・クライアントの性格・コミュニケーション手段によって、最適解は変わります。

僕のメンバーシップ「フリーランス開発者の作戦会議室」では、こうしたクライアントワークの実務設計——進捗共有の型・問題発生時の伝え方・継続案件に繋げるコミュニケーション術を、具体的なテンプレと実例を交えて毎週共有しています。

「また頼みたい」と言ってもらえるフリーランスを目指す仲間と、一緒に磨いていきませんか？

参加する