進捗報告のテンプレートを探しているとき、本当に欲しいのは書式そのものではありません。欲しいのは「これを埋めれば、あとで揉めない」という安心と、書くたびに30分かかっていた時間を削ることです。ところが世の中に出回っている報告様式の多くは項目が多く、埋めるのに時間がかかるわりに、読む側が知りたいことが書かれていません。
進捗報告に入れるべきものは、突き詰めると2つです。期日に対していまどこにいるかという数字と、次に困りそうなことです。この2つが書いてあれば、読む側は判断できます。逆にこの2つが抜けていると、どれだけ丁寧に作業内容を並べても「で、間に合うの」と聞き返されます。
この記事では、5人から数十人のチームで進行のとりまとめをしている人に向けて、進捗報告に必ず入れる要素、書かなくてよいこと、宛先によって変わる粒度、そしてそのまま使える文例を整理します。あわせて、テンプレートを配っても2週間で埋まらなくなる理由と、その手前で何を変えればよいかも扱います。
進捗報告のテンプレートを探す人は、たいてい次のどれかの状況にいます。ひとつは、新しく進行のとりまとめを任されて、何をどう報告すればよいか分からない状態。もうひとつは、いまの報告の形が長すぎる、あるいは読まれていないと感じていて、書き直したい状態。三つめは、部下やメンバーから上がってくる報告の質がばらばらで、様式をそろえたい状態です。
この3つは、必要なテンプレートが少しずつ違います。1つめの人には項目の意味の説明が要ります。2つめの人には削る基準が要ります。3つめの人には、配ったあとに埋めてもらうための仕掛けが要ります。項目名を並べただけの様式をコピーしても、2つめと3つめの困りごとは解けません。
とりまとめ役が週次の報告を作るのに1時間かかっているとします。メンバー8人がそれぞれ自分の分を書くのに15分使っているとすると、チーム全体では週に3時間が報告のために消えます。月にすると12時間を超えます。1人分の1日半に相当する時間です。
この時間が丸ごと無駄だという話ではありません。判断のための材料をそろえる時間は必要です。問題は、その12時間のうち、実際に誰かの判断を変えた部分がどれだけあるかです。現場でよく聞くのは、報告書のうち読まれているのは冒頭の数行と、赤字になっている行だけだという話です。残りは作った人だけが目を通しています。
だから進捗報告のテンプレートを見直すときの基準は、項目を足すことではありません。読む側の判断を変える情報だけを残して、それ以外を削ることです。削れば書く時間が減り、書く時間が減れば頻度を上げられます。頻度が上がれば、遅れに気づくのが早くなります。
長い報告書は、たいてい過去の事故の積み重ねでできています。何かが漏れて問題になるたびに、二度と漏らさないよう項目が1つ足されていきます。足すのは簡単で、外すのには勇気が要るので、項目は片方向に増え続けます。
その結果、報告書には「書かれているが誰も見ていない欄」が生まれます。書く側はそれに気づいているので、だんだん形式的に埋めるようになります。前回の内容をコピーして日付だけ変える、といったことが起こります。こうなると、報告書の見た目は整っているのに中身が実態とずれていく状態になります。読む側は形式が整っているぶん、ずれていることに気づきにくくなります。
報告の様式を作り直すなら、最初にやるべきは項目の棚卸しです。それぞれの欄について、直近3か月でその欄の内容によって誰かの行動が変わったかを確認します。変わっていない欄は外します。外して困ったらまた足せばよく、外した瞬間に困るなら、それは本当に必要な欄だったということです。
宛先や粒度が変わっても、進捗報告の骨格は変わりません。次の5つがそろっていれば、報告としては成立します。
| 要素 | 書く内容 | 抜けたときに起きること |
|---|---|---|
| 現在地 | 期日に対していまどこにいるか | 間に合うかどうかが分からない |
| 差分 | 前回の報告から何が変わったか | 読む側が毎回全部を読み直す |
| 予兆 | 次に困りそうなこと | 問題が起きてから知らされる |
| 判断 | 決めてほしいこと、いつまでに | 待ちが発生していることに気づかれない |
| 次回 | 次に報告する日 | 催促が発生する |
進捗報告の1行目は、期日と現在地です。「順調です」「おおむね予定通りです」は現在地ではありません。読む側はその言葉から何も判断できないので、結局質問が返ってきます。
現在地は、数えられるもので書きます。20ある画面のうち12が完了、残り8。原稿30本のうち18本が初稿済み。このように書くと、読む側は残りの量とこれまでのペースから、自分で見通しを立てられます。
期日との関係も1行で添えます。「残り8画面、期日まで2週間、直近のペースは週5画面」と書けば、間に合うかどうかは計算するまでもありません。書く側が結論を言い切らなくても、事実だけで結論が見えます。これが、報告が短くなる一番の近道です。
2つめは差分です。前回から何が動いたか、何が動かなかったかを書きます。毎回すべてを書き直すと、読む側は前回との違いを自分で探すことになります。差分が書いてあれば、読むのは数行で済みます。
動いたものだけでなく、動かなかったものを書くのが要点です。「先週から変わっていないのは、外部との調整が要る2件です」と書けば、そこに手当てが要ることが伝わります。動かなかったものを黙っていると、あとで「それ、ずっと止まってたの」と言われます。
3つめが、この記事の軸です。進捗報告でいちばん価値があるのは、まだ起きていない問題です。すでに起きた問題は、報告しなくてもいずれ表に出ます。まだ起きていない問題は、報告されなければ誰も知りません。
「次に困りそうなこと」は、予言ではありません。いま見えている条件から、そのままいくと詰まる箇所を挙げるだけです。承認が返ってこない、素材が届かない、担当が休みに入る、テスト環境が空いていない。こうしたものは事前に見えています。見えているものを書けば、読む側は先に手を打てます。
現場でよく聞くのは、問題が表に出た時点ではもう選択肢が残っていない、という話です。1週間前に共有されていれば人を足せた、別の順番で進められた、という後悔が繰り返されます。この差を埋めるのが予兆の欄です。
書き方は簡単です。「このままだと、来週の頭に◯◯待ちで止まります」という形にします。止まる時期と、止まる原因の2つが入っていれば十分です。原因が分からないときは「理由は特定できていませんが、進みが落ちています」と書きます。分からないことを書かないより、分からないと書くほうが役に立ちます。
4つめは判断の依頼です。進捗が止まる原因の多くは、作業の遅さではなく決まっていないことです。仕様が決まらない、優先順位が決まらない、予算の枠が決まらない。これらは作業する人には決められません。
判断を仰ぐときは、3点をそろえます。何を決めてほしいか、いつまでに決まらないと何が起きるか、こちら側の推奨案はどれか。推奨案を添えるかどうかで、返答の速さが大きく変わります。選択肢だけ並べて投げると、読む側は考える時間を確保しないと返事ができません。推奨案があれば、同意か否かの返事で済みます。
期限も必ず書きます。「早めにお願いします」では動きません。「9月8日までに決まらないと、公開が1週間ずれます」と書けば、優先度が伝わります。
5つめは次回の予告です。1行で済みます。次にいつ報告が来るかが分かっていれば、読む側は途中で確認する必要がなくなります。催促のやりとりは、双方にとって気分のよいものではありません。予告を書くだけで、その往復が消えます。
テンプレートを短くするには、足す基準より外す基準のほうが役に立ちます。次の4つは、多くの報告で削れます。
「月曜に打ち合わせをして、火曜に設計書を修正し、水曜にレビューを依頼しました」という記述は、書く側にとっては働いた証拠ですが、読む側の判断は何も変わりません。読む側が知りたいのは、その結果としていまどこにいるかです。
実況を削ることに抵抗が出るのは、仕事をしていないと思われる不安があるからです。この不安は、報告の様式ではなく、評価のされ方の問題です。とりまとめ役の側から「作業内容は書かなくてよい、数字と困りごとだけでよい」と明示しておくと、書く側の負担が減ります。
遅れているときほど、説明が長くなります。誰の対応が遅かった、想定外のことが起きた、他の依頼が割り込んだ。これらは事実であっても、報告の本体ではありません。
事情は1行にまとめます。「外部からの返答待ちで4日止まりました」で十分です。そのあとに、いつ取り戻すのか、取り戻せないなら何をずらすのかを書きます。読む側が知りたいのは原因ではなく、これからどうなるかです。原因の掘り下げが必要なら、報告とは別の場で行います。
「認識が甘かったと反省しています」「今後は前倒しで進めます」といった記述は、報告から外して構いません。読む側はこれを読んでも次の行動を決められません。決意ではなく、具体的にどう進め方を変えるかを書きます。「レビュー依頼を金曜ではなく水曜に出す形に変えます」であれば、読む側も判断できます。
複数の人が読む報告に、特定の1人にしか関係のない話を混ぜると、他の全員にとって読む量が増えます。個別の話は個別に送ります。報告に載せるのは、複数の人が知っておくべきことだけです。
この線引きをはっきりさせておくと、報告の長さは自然に安定します。目安として、週次の報告であれば15行前後、日次であれば3行で収まります。それを超えるなら、載せる場所が違うものが混ざっています。
進捗報告の要は数字ですが、数字の作り方を間違えると、かえって実態から離れます。
「80%完了」という報告は、多くの場合あてになりません。残りの20%に、これまでと同じだけの時間がかかることがよくあるからです。作業の後半には、細かい調整、確認、手戻りが集まります。
進捗率が信頼できないのは、基準が人によって違うためでもあります。ある人は作業量の割合で言い、別の人は経過時間の割合で言い、また別の人は感覚で言います。同じ70%という言葉が、3人それぞれ別の意味になります。並べても比較できません。
代わりに使うのが、数えられる単位です。画面、原稿、部品、店舗、申請、面談。仕事の中身に応じて、1つ終わったと言い切れる単位を決めます。単位が決まれば、進捗は「全体のうちいくつ終わったか」で表せます。
単位を決めるときの目安は、1つあたりが1日から3日で終わる大きさです。これより大きいと、報告のたびに「まだ途中」しか言えなくなります。これより小さいと、数える手間のほうが大きくなります。
終わった量より、残っている量のほうが判断に使えます。「12終わりました」より「残り8です」のほうが、期日までの日数と並べたときに意味を持ちます。
さらに、直近のペースを添えると精度が上がります。「残り8、直近2週間のペースは週3」と書けば、あと3週間弱かかることが自動的に出ます。期日が2週間後なら、その時点で手当てが要ると分かります。ペースを添えるのは1行増えるだけですが、報告の価値はここで大きく変わります。
調査や検討のように、数えられる単位に割りにくい仕事もあります。この場合は、量ではなく工程で位置を示します。「情報収集は終わり、いまは案を3つに絞る段階です。来週には1案に絞ります」という形です。
このときも、次の節目の日付は必ず書きます。日付がないと、進んでいるのか止まっているのかが外から判断できません。日付を書いておけば、その日を過ぎた時点で自動的に確認のきっかけができます。
予兆の欄は、書く価値が高いぶん、書くのが難しい欄でもあります。慣れないうちは、次の4つを順に見るだけで十分です。
タスクの一覧を見て、3日以上動いていないものを拾います。動いていない理由は、たいてい本人にしか分かりません。忙しいだけなのか、詰まっているのか、そもそも着手できない事情があるのか。止まっている期間が長いほど、後者である確率が上がります。
特定の1人しか手を出せない仕事は、その人の体調や休暇で全部が止まります。報告の時点でその状態に気づいていれば、引き継ぎの手当てができます。気づいていなければ、休みに入ってから慌てることになります。
作業の前提として決まっていなければならないことのうち、まだ決まっていないものを挙げます。仕様、担当、予算、公開日。決まっていない期間が長いほど、後工程が圧縮されます。決まっていないこと自体を報告に載せるのは、判断を促す最も穏当な方法です。
社外や他部署に依頼して、返答を待っているものを一覧にします。待ちは自分たちでは動かせないので、期日から逆算して催促の日を決めておきます。報告に「9月10日までに返答がなければ、公開日をずらす判断が要ります」と書いておけば、その日が来たときに議論が短く済みます。
同じ進捗を報告するのでも、宛先によって必要な粒度は変わります。1つの様式を全員に配ると、誰にとっても過不足のあるものになります。
経営層が知りたいのは、間に合うかどうかと、金と人が追加で要るかどうかです。作業の中身はほぼ関係ありません。
分量は5行で足ります。期日に対する見通し、そう判断した根拠の数字、リスク、必要な判断、次回報告日。これ以上書くと読まれません。色や記号で状態を示す形式も有効ですが、色の基準は先に決めておきます。基準が曖昧だと、赤にするかどうかで毎回悩むことになります。
社外の依頼主に出す報告では、こちらの内部事情を書かないのが原則です。誰が休んだ、社内の承認が降りない、といった話は相手に判断の材料を与えません。相手が知りたいのは、約束したものが約束した日に届くかどうかと、相手側で用意すべきものが何かです。
相手側の宿題を明示するのが要点です。素材の提供、確認の返答、アカウントの発行。これらが遅れると、こちらの進行が止まります。報告のたびに宿題と期限を書いておけば、遅れたときにどちら側の要因かが後から追えます。この記録は、揉めたときにも役に立ちます。
上司に対しては、判断を仰ぎたいことを中心に据えます。上司の役割は、部下では決められないことを決めることと、外との調整をすることです。だから報告も、その2つに寄せます。
数字は簡潔に、困りごとは具体的に書きます。上司に対しては「うまくいっていないこと」を早めに出すほど得です。遅れて出すと、選べる手が減ったうえに、隠していたと思われます。
チーム内向けの報告は、全体の中で自分がどこにいるかを共有するためのものです。ここでは他の人の進み具合が見えることに意味があります。自分の前工程が遅れていれば、自分の予定を組み替えられます。
チーム内向けでは、評価の匂いを消すのが重要です。遅れている人が責められる場になると、報告は必ず美化されます。美化された報告は、判断の役に立ちません。遅れは責める対象ではなく、手当ての対象だという扱いを、とりまとめ役が言葉と態度で示す必要があります。
ここからは、実際に使える文例を挙げます。日付や数字は自分の案件のものに置き換えてください。
今週の進捗を共有します。
現在地は、全20画面のうち13画面が完了、残り7画面です。
期日は9月26日、直近2週間のペースは週4画面です。
このペースが続けば9月19日前後で完了する見込みです。
先週から動いたのは、一覧画面と詳細画面の2つです。
先週から動いていないのは、決済まわりの2画面です。
外部の仕様確認の返答を待っており、9月5日に再度催促します。
次に困りそうなこととして、9月15日の週に検証環境が別の案件と重なります。
重なる前に検証を終えたいので、来週の作業順を検証優先に入れ替えます。
次回の共有は9月8日の朝に出します。
進捗を1点だけ共有します。
残り7画面、期日まで3週間、直近のペースは週4画面です。
このままなら間に合います。
1点だけ、決済まわりの仕様確認が先方で止まっています。
9月10日までに返答がないと、検証の期間が1週間削られます。
その場合は検証の範囲を絞る判断が必要になるので、先にお伝えしておきます。
遅れが出ているのでご報告します。
現在地は全30本のうち16本、期日は9月20日です。
残り14本に対して、直近のペースは週4本です。
このままでは9月20日に3本ほど間に合いません。
原因は、確認の返答待ちで先週4日間止まったことです。
すでに返答は届いており、今週から通常のペースに戻っています。
取り戻す案として2つ考えています。
1つめは、9月20日の納品を14本のうち11本に絞り、残る3本を9月27日に回す案です。
2つめは、来週から1名を追加して14本すべてを9月20日に間に合わせる案です。
品質の面では1つめを推奨します。
9月5日までにどちらで進めるかご判断をいただけますでしょうか。
判断をお願いしたい件が1つあります。
対象は、申込フォームの項目数です。
現在の設計では入力項目が18あり、当初想定の12を超えています。
このまま進めると、開発は9月19日に完了します。
項目を12に減らす場合は9月12日に完了し、1週間の余裕ができます。
営業の観点では18項目のほうが情報は集まりますが、
入力の途中で離脱する割合が上がることが一般に指摘されています。
こちらの推奨は、12項目で公開し、公開後に必要な項目を足す進め方です。
9月8日までにご判断いただけると、そのまま予定通り進められます。
株式会社〇〇
△△様
いつもお世話になっております。
8月分の進捗をご報告いたします。
■ 全体の状況
全5工程のうち、3工程が完了しております。
9月30日の公開に向けて、現時点では予定通りに進んでおります。
■ 8月に完了した内容
・設計の確定
・画面デザインの確定
・主要機能の実装
■ 9月に進める内容
・残りの機能の実装(9月13日まで)
・検証(9月20日まで)
・公開前の最終確認(9月26日まで)
■ お願いしたい事項
・掲載する写真データのご提供(9月8日まで)
・原稿のご確認とご返答(9月12日まで)
上記の2点が遅れますと、検証の期間が短くなり、
公開日の調整が必要になる可能性がございます。
次回のご報告は9月30日を予定しております。
ご不明な点がございましたら、お気軽にお申し付けください。
先にお伝えしたいことがあります。
9月26日の公開に間に合わない可能性が出てきました。
現時点では間に合う見込みですが、余裕がほぼありません。
残り7画面に対して、使える日数が10営業日です。
直近のペースは週4画面なので、計算上は9月19日に終わります。
ただし、この計算には手戻りの時間が含まれていません。
今後1週間で1画面でも遅れが出た場合は、
公開日をずらすか、公開時の機能を絞るかの判断が必要になります。
判断が必要になる時点は9月9日と見ています。
その日に改めて状況をお伝えします。
今週の進捗です。
残り7画面、期日は9月26日、直近のペースは週4画面です。
先週から3画面が完了し、止まっているものはありません。
判断をお願いしたい事項もありません。
次回は9月8日に共有します。
順調なときほど短く書きます。短い報告が続いたあとに長い報告が来ると、それだけで異常の合図になります。毎回同じ長さの報告を出していると、この合図が使えません。
様式を配っても、しばらくすると埋まらなくなります。原因は意志ではなく設計にあります。
作業の記録がある場所と、報告を書く場所が別だと、報告のたびに転記が発生します。転記は退屈で、間違いやすく、しかも書いた人以外には価値が見えません。だから真っ先に省略されます。
転記が発生しているかどうかは、報告を書く手順を数えれば分かります。別の画面を開いて内容を確認し、それを写して整形する手順が入っているなら、転記です。報告のもとになる情報が1か所にあり、そこを見ながら数行書くだけで済むなら、転記はありません。
チャットで報告し、表計算ソフトで管理し、メールで依頼主に送る。この3つが別々だと、同じ情報を3回書くことになります。3回書けば、どこかが古くなります。古くなった情報が残っていると、次に見る人が混乱します。
現場でしばしば出るのは、どの数字が最新か分からないという問題です。報告書には13と書いてあり、管理表には12と書いてある。どちらが正しいかを確かめるために、また人に聞くことになります。
管理表をとりまとめ役が1人で更新している場合、その人が休むと情報が止まります。さらに、更新する人が1人だと、その人の解釈が全部に入ります。作業している本人が「詰まっている」と思っていても、とりまとめ役が「進んでいる」と判断すれば、報告には進んでいると書かれます。
これを避けるには、状態を変える操作を本人ができるようにします。操作が重いと本人はやらないので、操作は1手で終わる形にします。カードを次の列に動かすだけ、というくらいの軽さが要ります。
日次で報告を求めているのに、仕事の単位が週をまたぐ大きさだと、毎日「継続中」としか書けません。書く意味がないので、やがて出なくなります。逆に、動きの速い仕事を週次で報告していると、週の途中で起きた問題が翌週まで表に出ません。
頻度は、仕事の単位が終わる周期に合わせます。1つの作業が2日で終わるなら日次でも意味があります。1週間かかるなら週次で十分です。頻度を合わせるだけで、報告の中身は自然に濃くなります。
業務委託や、他社と組んで進める案件では、進捗報告の位置づけが変わります。相手は自分の裁量で仕事をしており、こちらが作業の手順まで指示できる関係ではないためです。
このとき気をつけたいのが、進捗の把握と、働き方の管理を混同しないことです。何時から何時まで作業していたかを細かく求める形は、契約の性質によっては適切でない場合があります。労働時間の把握については、公的なガイドラインで使用者の責務が示されています。
使用者には、労働時間を適正に把握するなど労働時間を適切に管理する責務がある。労働時間の把握にあたっては、原則として客観的な記録を基礎として確認し、適正に記録することが求められる。 出典: mhlw.go.jp
この責務が及ぶ範囲は、契約の形態によって変わります。自社の従業員なのか、業務委託の相手なのかで扱いが違うため、判断に迷う場合は所管の窓口や社会保険労務士などの専門家に確認してください。この記事で法の解釈を断定することはできません。
実務としては、社外のメンバーには時間ではなく成果物の状態を報告してもらう形が無難です。「何を、いつまでに、いまどこまで」の3点に絞ります。相手にとっても書く負担が軽く、こちらにとっても必要な情報がそろいます。
報告の頻度も、相手の負担を考えて決めます。週1回、3行程度で十分な案件が多くあります。頻度を上げたい場合は、報告という形ではなく、作業の場そのものを共有する形に切り替えるほうが、双方の手間が減ります。
ここまで挙げてきた困りごとは、どれも様式の問題ではなく置き場所の問題です。数字が作れないのは数えられる単位で並んでいないから、予兆が見えないのは止まっているものが目立たないから、報告が続かないのは転記が発生しているからです。
ボード型のタスク管理では、1枚のカードが1つの仕事に対応し、列が工程を表します。この形にすると、進捗報告に必要な数字がそのまま画面から読み取れます。残り何枚か、どの列に何枚たまっているか、何日動いていないカードがあるか。報告のために別途集計する必要がありません。
報告を短くする最短の道は、報告のもとになる場所を1つに決めることです。依頼が来る経路はチャットでもメールでも構いませんが、「いま誰が持っていて、どの工程にいるか」が書かれる場所は1か所にします。
どこまでを1つの板に載せられるかは、道具の作りによって変わります。ボード型のタスク管理で何ができるのかは、できることのページに機能ごとに整理されています。カード、列、担当、期限といった基本の要素がどう組み合わさるかを見ておくと、いまの管理表のどの列が板の上で表現できるかが分かります。
費用の面では、プランの区切り方が長く使ううえで効いてきます。料金のページでは、機能で絞らず、区切るのは人数とボードの数だけという構造が示されています。機能でプランが分かれる形だと、「この機能を使いたいから上のプランへ」という判断が定期的に発生し、そのたびに社内の承認で止まります。区切りが人数とボードの数だけなら、増えるかどうかは事前に読めるので、費用の見通しが立てやすくなります。
いま使っている道具を変えるかどうかは、報告のたびに発生している手間がどこから来ているかで決まります。手間の出どころが道具の作りにあるなら入れ替える価値がありますし、運用の決め方にあるなら道具を変えても同じことが起きます。
見極めの材料として、比較のページ群が使えます。付箋のように軽く使えるボード型の道具との違いはTrelloとの比較に、複数の見え方を切り替えて使う道具との違いはAsanaとの比較に整理されています。文書とデータベースを組み合わせて自由に作り込む道具との違いはNotionとの比較に、自動化や外部連携を軸にした道具との違いはmonday.comとの比較にまとまっています。国内の開発現場で広く使われている道具との違いはBacklogとの比較に、日本語のボード型の道具との違いはJootoとの比較にあります。どの道具が候補に挙がっているか決めきれていない段階なら、比較の一覧から自分のチームに近い使い方のページを選ぶのが早道です。
これらのページで共通して先に置かれているのは、「相手のままがいい場合」です。乗り換えなくてよい条件が最初に書かれているので、いまの道具で足りているかどうかを先に確認できます。道具の入れ替えは、それ自体が数週間の負荷を生む作業です。負荷を払う価値があるのは、いまの道具の弱点が毎週の作業時間として表に出ているときだけです。
移すと決めた場合、最初に確認するのは既存の情報をどう運ぶかです。Trelloからの移行のページには、既存のボードを取り込む手順が説明されています。自動で取り込めるのはTrelloだけで、他の道具からは手作業になる点も明記されています。ここは移行の工数に直結するので、先に読んでおくほうが安全です。
もうひとつ確認しておきたいのが、情報の扱いです。進捗報告には、公開前の企画や取引先の名前といった、外に出せない情報が含まれます。データがどこに置かれ、誰が見られるのかについての考え方は安全性の考え方のページにまとめられています。社内の承認を通す場面では、ここに書かれている内容がそのまま説明の材料になります。
導入の前後で出てくる細かい疑問は、よくある質問のページで確認できます。人数の数え方、ボードの数え方、支払いの方法といった、契約前に決めておくべき点が並んでいます。
最後に、進捗報告の様式を変えるときの順番を整理しておきます。先に様式を作り直すより、先に置き場所を決めるほうが結果が出ます。置き場所が1つになっていれば、様式は数字を読み取って数行書くだけの薄いものになります。逆に置き場所が分かれたまま様式だけ整えると、転記の手間が増えるので、以前より早く形骸化します。項目を足す前に、まず情報が1か所に集まっているかを確認してください。そこが整えば、報告に書くのは数字と、次に困りそうなことだけで足ります。
現在地の数字、前回からの差分、次に困りそうなこと、決めてほしいこと、次回の報告日の5つで足ります。特に現在地は「順調です」ではなく「残り8画面、期日まで2週間、直近のペースは週4画面」のように数えられる形で書いてください。この形にすると、読む側が自分で見通しを立てられるので、質問の往復が減ります。
作業が均等に分割されていて、1つ終わるごとに同じだけ全体が進む仕事なら有効です。そうでない場合、進捗率の基準が人によって違うため、並べても比較できません。画面や原稿のように数えられる単位に割り、終わった数ではなく残っている数で書くほうが、期日との比較に使えます。
経営層には見通しと必要な判断だけを5行程度で、依頼主には約束の期日と相手側の宿題を、上司には判断を仰ぎたいことを中心に書きます。チーム内向けは、前工程と後工程の関係が見えることを優先します。1つの様式を全員に配ると、誰にとっても過不足のあるものになります。
多くは、報告を書く場所と作業の記録がある場所が分かれていて、転記が発生していることが原因です。報告のもとになる情報が1か所にあり、そこを見ながら数行書くだけで済む形にすると続きます。あわせて、報告の頻度を仕事が1つ終わる周期に合わせてください。頻度が実態と合っていないと、書く意味のない報告が増えます。