非同期の週次報告テンプレート：進捗・予定・問題の形式と、誰が投稿するか

週次報告テンプレート

チームで使っているツールにそのままコピーしてください。角かっこの中だけを書き換えます。

**[プロダクトまたは領域] — [日付]の週**

**状況：** 順調 / 懸念あり / 遅れ
**担当：** [名前]

**進捗**
- [リリースまたは完了した項目、リンク付き]
- [リリースまたは完了した項目、リンク付き]
- [決めたこと、どこに記録したか]

**予定**
- [次の報告までに完了させること]
- [次の報告までに完了させること]
- [着手すること]

**問題**
- [障害、解消できる人、期限]
- [日程をずらしかねないリスク、何があれば変わるか]
- なし（本当にないなら）

**数字**
- [指標]：[値]（先週 [値]）
- [指標]：[値]（先週 [値]）

**判断が必要なこと**
- [質問]、[名前]から、[日付]まで

見出しは六つ、行数はおよそ十二行、どの段落も一文以内。エレベーターの中でスマートフォンから読める長さです。

進捗・予定・問題の形式が機能する理由

この形式が何十年も使われてきたのは、各セクションが読み手の一つの疑問に答えるからです。

進捗は「何か起きたのか？」に答えます。取り組んだことではなく、終わったことを並べます。「チェックアウトに取り組んだ」は活動で、「チェックアウトをトラフィックの40%で公開」は進捗です。各項目にリンクを付けて、詳細を知りたい人が質問せずに自分で見に行けるようにします。

予定は「来週は何を期待すればいいか？」に答えます。これは約束なので、三項目までにします。来週の進捗セクションは今週の予定と照らし合わせて読まれ、その比較から正直さが生まれます。同じ予定が三週間続けて現れたら、誰も口にしなくても、報告が問題をあぶり出したことになります。

問題は「どこで私の助けが要るのか？」に答えます。管理する側が最初に読むセクションであり、書く側が最もよく省くセクションでもあります。良い問題の行は、障害と、それを解消できる人と、期限を名指しします。「法務待ち」は愚痴です。「木曜までにDanaの契約承認がないとパイロットが一週間ずれる」は依頼です。

追加の二つのセクション、数字と判断が必要なことは任意ですが、これがあることで報告は会議より価値のあるものになります。数字は週の形を時間軸で見せてくれます。判断の依頼は、読み手に返信する理由を与えます。

週次報告は誰が投稿するか

一人一つではなく、プロダクトまたは領域ごとに一人の担当者です。三つのプロダクトを持つ八人のチームなら、投稿は八つではなく三つです。個人単位の報告はタスクの羅列になり、他人のタスク一覧を読む人はいません。

担当者は、会議で「どうなってる？」と聞かれるはずの人です。たいていはプロダクトのリード、最も多くの作業を抱えるエンジニア、あるいはリードが決まっていないものについては創業者です。持ち回りはうまくいきません。報告の価値は、一つの声が一つの対象を週をまたいで追い続けることから生まれます。

何も起きていなくても投稿してください。「進捗：なし、チームはカンファレンスに出ていた」という週も有用な報告です。抜けた週は穴になり、読み手はそれを不安で埋めます。

いつ出すか

曜日と時刻を一つ決めて動かさないこと。私たちが知るチームの多くは、記憶が新しいうちに週を締める金曜の午後か、週を立ち上げる月曜の10時前に投稿しています。金曜の報告はどのみち月曜に読まれるので、選択はほぼ書き手がいつ書きたいかで決まります。

コメントの締切は投稿時刻のおよそ二時間後に設定します。それ以降、スレッドで解決しなかったことは翌週の問題セクションに載せるか、意見の合わない二人の間で通話を予定します。締切がないとスレッドは一週間開きっぱなしになり、報告は終わらない会議になってしまいます。

進捗会議の代わりになるもの

進捗会議には四つの役割があります。進捗を報告する、障害を表に出す、判断を迫る、そして互いの話を聞く。書かれた報告は最初の二つを会議より上手にこなします。記録が残り、誰も出席しなくていいからです。残りの二つには別の居場所が要ります。

うまくいくパターンはこうです。進捗会議をやめ、全員が報告を読んでいる前提の20分の週次通話を残し、そこでは未決の判断と雑談だけを扱う。議題がなければ五分で終える。通話に出る価値が出てきたことに、みんな気づきます。

どこに投稿するか

適切な場所は、必要とする人がすでに見ている場所で、三つの条件を満たすところです。後から検索できること、その下にコメントできること、その日のチャットに流されて消えないこと。

チャットのチャンネルは三つ目の条件を満たしません。活発なチャンネルに投稿した週次報告は、昼には流れて見えなくなります。チャットしかないなら、報告をピン留めするか、それ以外は何も流れないチャンネルに投稿します。

Slackのキャンバスは、Slack内のドキュメントで、チャンネルのタブとしてピン留めでき、コメントも付けられます。Slackのヘルプセンターによると、キャンバスは有料プランで利用でき、Proプランは2026年10月時点で月払いならユーザーあたり月8.75ドル、年払いなら7.25ドルです。プロダクトごとに一つのキャンバスを毎週更新すれば、履歴が一か所にまとまり、会話のすぐ隣に置けます。

Basecampの自動チェックインは、逆の方向からこの問題を解きます。「今週は何に取り組みましたか？」のような質問を、毎日・毎週・毎月のいずれかの頻度で設定すると、Basecampが各メンバーに尋ねて回答を一か所に集めます。Basecampの料金は2026年10月時点で、Freelancerプランが月29ドルで5ユーザーまで、Proが79ドルで10ユーザーまで、Pro Plusが99ドルで15ユーザーまで。無料プランは3ユーザーまでです。チェックイン方式は個人の報告に向いていて、数字を含むプロダクト単位の報告には、やはりドキュメントが必要です。製品の他の部分はBasecampとの比較で扱っています。

フィード付きのプロジェクトツールが、私たちの使い方です。Atrixでは各プロダクトに専用の更新ストリームを持つページがあり、そこに投稿した報告はワークスペースのフィードにも流れます。報告の中に誰かの名前を書くと、その人に通知が届き、スマートフォンへのプッシュ通知も飛びます。そのため、報告が本当にその人を必要とするときだけ名前を書きます。実際には問題セクションと判断が必要なことセクションだけで、それ以外では書きません。六人の名前を挙げた報告は、形を変えた会議の招集です。その後の会話はチームチャットで行います。

数字セクションの値は、記憶ではなくトラッカーから取るべきです。AtrixのMCPサーバーにはproject_statusというツールがあり、一つのプロダクトの状況を数字で返します。完了率、ステータス別の作業数、期限超過のもの、一週間以上「進行中」や「レビュー中」で止まっているもの、今後七日以内に期限が来るもの、今週完了したもの。アシスタントに「project_statusをもとにCheckoutの今週の報告を下書きして」と頼むと、進捗と数字のセクションが一分ほどで出てきて、担当者は書くのではなく直すだけで済みます。ただし問題セクションは書いてくれません。Danaが休暇中だということをトラッカーは知らないからです。

五つのステップで導入する

1. 担当者と曜日を決める。 誰もが見える場所に書き出します。担当者がはっきりしないプロダクトがあれば、それが報告の明らかにする最初の問題です。
2. 最初の一通は自分で投稿する。 創業者かリードが上のテンプレートで最初の報告を書き、本物の問題セクションを含めます。チームは最初の一通の調子を真似るので、正直で短いものにします。
3. 二週目から進捗会議をやめる。 「短くする」ではありません。会議が残っていれば、報告はいつの間にかそこへ戻ります。
4. 締切までに読んで返信する。 二週目に、担当者は誰かがコメントしたかを確認します。誰もしていなければ、リードが各報告に一つ質問を返します。報告は手間ではなく沈黙で死にます。
5. 六週間後に見直す。 予定セクションと、その後の進捗セクションを比べます。予定がめったに達成されていないなら、テンプレートは役目を果たしており、直すべきは計画の立て方です。

よくある失敗

• 長すぎる。 スマートフォンでスクロールが要るなら、それは報告ではなくレポートです。詳細はリンク先のページに移します。
• 一か月間、問題なし。 四週間問題ゼロのチームはありません。問題セクションが空なのは、たいてい担当者が書くのをためらっているからです。普通に感じられるまで、週に一つは問題を書いてもらいます。
• 成果ではなく活動。 「仕入先と三回打ち合わせた」は活動です。「仕入先が11月12日の納品を確定した」は進捗です。
• 全員の名前を挙げる。 言及した人に通知が飛ぶツールなら、名前一つが割り込み一回です。関心がありそうな人ではなく、動くべき人の名前を書きます。
• 先週の値のない数字。 指標が一つだけなら事実です。先週の値と並べれば傾向になります。

よくある質問

週次報告には何を含めるべきですか？

最低でも三つのセクションです。先週からの進捗（完了したこと、リンク付き）、来週の予定（約束は三つまで）、問題（それぞれに担当者と期限を明記）。先週の値を並べた数字セクションと、読み手に求める判断の短いリストを加えます。

チームの週次報告はどのくらいの長さが適切ですか？

スマートフォンでほとんどスクロールせずに読める長さです。150〜300語、箇条書きでおよそ十二行。それ以上のスペースが必要なものは、報告を長くするのではなくリンク先のページにします。

週次の状況報告は誰が書くべきですか？

プロダクトまたは領域ごとに一人の担当者で、通常はリードか最も多くの作業を抱えている人です。メンバー全員の個人報告は、誰も読まないタスク一覧になります。三つのプロダクトを持つ八人のチームなら、投稿は三つであるべきです。

書面の報告で本当に進捗会議を置き換えられますか？

報告の半分は置き換えられます。未決の判断と互いに話すための短い任意の通話を残し、進捗は議題に載せません。会議を完全にやめて通話だけ残したチームでは、通話が週を追うごとに短くなっていきます。

非同期の週次報告に向いているツールは？

報告を後から検索でき、コメントが付けられ、チャットに流されて消えないツールならどれでも使えます。チャンネルにピン留めしたSlackのキャンバス、Basecampの自動チェックイン、Atrixのようなプロダクトごとの更新フィードを持つプロジェクトツールはいずれも条件を満たします。普通のチャットチャンネルは満たしません。

週次報告と日次スタンドアップの違いは何ですか？

日次スタンドアップは次の24時間の調整が目的で、通常は個人単位です。週次報告は一週間を通したプロダクトの状態が対象で、プロダクトまたは領域単位です。小さなチームは、週次が安定して回るようになれば、日次はたいてい不要になります。

次のステップ

報告が作業のすぐ隣にあれば、進捗セクションはほぼ自動的に埋まります。プロダクト、サイクル、更新フィードがどう組み合わさるかはAtrixのプロジェクト管理をご覧ください。あるいは、いま使っているツールで上のテンプレートから始めてください。