「週次報告」を調べる人は、だいたい二手に分かれます。上司から「来週から出して」と言われて何を書けばいいのか探している人と、チームに導入しようとして進め方を探している管理職です。求めているものは違いますが、どちらも最初に引っかかるのは「そもそもこれは何のためにあるのか」ではないでしょうか。
私は後者から入りました。グループリーダーとして週次報告を運用していたころ、報告は毎週きちんと提出されていました。それでも目を通して終わりになる週が続き、これを集めて何になっているのかという引っかかりが消えず、最終的には週次報告のシステムを自分で作りました。そこではっきりしたのは、週次報告で掴むべき情報はメンバーが抱えている課題であり、それが支援の要否を判断する材料になる、ということです。
週次報告とは何か
週次報告は、1週間を単位に、その週にやったことと、そこで見えた課題、翌週の予定を共有する仕組みです。日次で出せば日報、月次なら月報。区切りの長さが違うだけに見えますが、運用してみると掴めるものが変わります。
日報で見えるのはタスクの進捗です。何が遅れているかはすぐ分かりますが、その遅れが今週たまたま起きたことなのか先月から続いているのかは、何十本並べても読み取れません。
月報で見えるのは成果です。1か月あれば仕事がひととおり完結するので、何を達成したかを書けます。ただ、月の途中のつまずきは、振り返る頃には解消しているか手遅れです。
週次報告が拾えるのは、その中間にある課題です。1週間は、ひとつの仕事が形になり始めて、うまくいかない部分が見えてくる長さです。しかも、まだ間に合う。「検索条件の仕様で認識齟齬があった」と週の終わりに書かれていれば、翌週の頭に手を打てます。
頻度ごとの向き不向きは日報・週報・月報の使い分けに整理しました。
目的は進捗管理ではない
導入するとき、目的として真っ先に挙がるのは進捗管理です。誰が何をどこまでやったかを把握したい。自然な動機だと思います。
ただ、進捗管理だけを目的にすると、週次報告はほぼ確実に形骸化します。進捗なら、もっと精度の高い情報源が別にあるからです。チケット管理ツールならステータスは常に最新ですし、朝会をやっていれば口頭で共有されています。週に一度、文章で書き起こされた進捗は、それらより粗くて遅い。書く側もそれに気づくので、「先週の続きです」で埋まるようになります。
では何のために集めるのか。書く側と読む側で分けて考えます。
書く側にとっては、週に一度立ち止まる機会です。 日々の作業に追われていると、うまくいったこととつまずいたことを並べて眺める時間は取れません。毎週書いていると、先週と同じところで詰まっていることに気づけます。気づいた分を目標欄に改善施策として書けば、翌週の動きを考える時間にもなります。
読む側にとっては、支援が必要な人を見つけるための材料です。 全員の状況を毎週個別に聞いて回るのは現実的ではありません。週次報告があれば、まず全員分に目を通したうえで、気になった人にだけ時間を使えます。
目的をどちらに置いたかは、報告への反応の仕方に表れます。進捗を確かめるつもりで読んでいると、予定どおりなら「了解」、遅れていれば理由を聞くだけで、返すことがなくなります。支援のために読んでいれば、つまずきに対して返せることが必ずあります。この違いが、形だけの報告になるかどうかを分けます。
すでに運用していて意味を疑っているなら、原因の切り分けを「週報は意味ない」と感じたらに書きました。
何を書き、いつ出すか
導入時に決めることは、突き詰めると項目と締切の2つです。
項目は3つで足りる
記述式は「作業内容」「振り返り」「目標」の3つ。ここに残業時間を添えます。
- 作業内容：今週やったこと。箇条書きで数行
- 振り返り：うまくいったこと、つまずいたこと
- 目標：来週やることと、振り返りで出たつまずきをどう直すか
目標に改善施策まで入っていれば、同じつまずきを繰り返しているのか手を打てているのかを、週をまたいで追えます。
項目を絞るのは、書く負担が閾値を超えた週から報告が空欄とコピペで埋まり始めるからです。忙しい週から順に手が抜かれるので、項目を増やすほど集まる情報はむしろ減ります。
コピペで使える型と記入例は週次報告のテンプレート公開に、この構成に落ち着くまでの経緯は週次報告のはじめかたに置いています。
文章に加えて、負荷や達成度を5段階で選ぶ項目を足すと、後から効いてきます。「大変でした」の重みは書き手の性格に左右されるので、文章だけでは週ごと・人ごとの比較ができません。選択式なら数秒で答えられて、比較できるデータとして溜まります。ストレスを含む自己評価の扱い方はストレス可視化がチームを救うに書きました。
記述3項目に5段階の自己評価を組み合わせた入力画面。この粒度なら数分で書き終えられる
締切は週の終わりか、翌週の頭か
締切をいつに置くかは、あまり議論されないわりに運用の続き方に効きます。選択肢は実質2つ、週の終わり（金曜の夕方）か翌週の頭（月曜）です。
金曜に出してもらうと、その週の記憶が新しいうちに書けます。ただ、金曜の夕方は締めの作業が集中する時間帯でもあり、「後で書く」が積み上がって翌週に持ち越されます。読む側が反応を返せるのも早くて月曜になります。
私のチームは月曜締切にしていました。週の頭のほうが時間を取りやすく、少し離れてから振り返るほうが整理して書けるからです。難点は、金曜の出来事の解像度が落ちることです。
どちらを選ぶにしても決めておきたいのは、その報告がどの週について書いたものなのかです。月曜に出す報告が指しているのは前の週なのか、始まったばかりの週なのか。ここが曖昧だと人によって解釈が分かれ、後から並べたときに揃いません。
報告依頼の設定画面。締切に合わせた曜日・時刻に加えて、どの週について書いてもらうかも指定できる
形骸化する原因と、手段で潰せる範囲
報告が形だけになっていく原因は、書く負担、反応のなさ、蓄積が使われないことの3つです。提出が途絶えるより先に、出てはいるが中身が薄くなるという形で表れます。それぞれの中身は週次報告のはじめかたに書きました。この3つは、手段で潰せるものと潰せないものに分かれます。
書く負担は、設計で減らせます。ただし自動化ではありません。何をやってどう感じたかを知っているのは本人だけで、機械が埋めた報告には読む価値がないからです。減らせるのは入力の手数のほうです。数値を選択式にする、前週の内容をコピーして直せるようにする。この程度でも負担は目に見えて下がります。
読む側の手間は、下読みまで任せられます。直近数週分を集約して変化を短くまとめる作業は、内容の理解が要るわりに判断が入らないので機械に向いています。何がどう生成されるのかは週次サマリーとはに書きました。
潰せないのは、反応を返すところです。定型文の自動返信でごまかすと、読まれていないことがかえってはっきり伝わります。その週の報告を読んでいないと書けない一言が入っていれば、長さは要りません。というより、前の2つを効率化するのは、ここに時間を回すためです。どこまでを手段に寄せられるかの線引きは週報作成を効率化する方法に整理しました。
3つめの「蓄積が使われない」は、手段というより使い道の問題です。読み返す場面を運用に組み込めば解決します。効いたのは1on1の前に直近数週分を読むことで、近況確認が数分で終わり、残りを対話に使えるようになりました（1on1の質を高める週報活用術）。四半期や評価面談の前に数か月分を振り返れば、期の前半の成果も記録に基づいて扱えます。
この運用を仕組みにした fluxweek
ここまで書いたことを仕組みにしたのが、週次報告サービスの fluxweek です。もともと自分のチーム用に作り、そのまま公開しました。
報告依頼メールは設定した曜日・時刻に自動配信され、メンバーはリンクから入力画面に直接入れます。入力するのは記述3項目と5段階評価、残業時間だけです。提出された報告は直近数週分がサマリーに集約され、変化と注意点を文章で確認できます。ストレスと残業時間から算出する0〜100点のアラート指標も並ぶので、誰から声をかけるかを数値でも見分けられます。
ダッシュボード。アラート指標の高い順に、声をかける相手を絞り込める
これから週次報告を始める方も、いまの運用を見直したい方も、無料プランから試せます。