週次定例だけで失敗しない｜発注側が用意すべきコミュニケーション設計

「毎週定例を入れています。」——それで失敗しないなら、世の中の炎上は半分になる。定例が報告会化し、決定がチャットに散り、翌週また同じ話をする。頻度の問題ではない。

発注側が用意すべきは、会議の回数ではなく、決める場と、決まったことの残し方だ。

週次定例は装置の一部にすぎない。コミュニケーション設計がない定例は、進捗の錯覚を生む。

設計チェック

要素	内容
アジェンダ	決定事項／確認事項／共有に分ける。共有だけで終わらせない
決定ログ	誰が・何を・いつまでに、を定例後24時間以内に残す
エスカレーション	止められたときの上げ先と期限（例: 2営業日）
デモ	言葉だけでなく、動くものを隔週以上で見る
非同期	仕様質問のチャネルとSLA（放置禁止）
参加者	決められない人だけの定例にしない

赤旗

• 議事録が「議論した」で終わり、決定がない
• 営業だけが定例に出て、実装者が不在
• ブロッカーが何週も同じ行に残る
• チャットの口頭了解が仕様になる

短い Before / After

Before: 60分の定例で状況共有。決定は「持ち帰り」。チャットで追加要望。
After: 最初15分で決定リストを消化。デモ10分。残りはブロッカー。決定ログをチケットに直結。持ち帰りは期限付きエスカレーションのみ。

同じ週次でも、成果は別物になる。

判断軸

今の定例でよい	設計し直す
毎週、決定かブロッカー解消が起きている	共有だけでチケットが動かない
決定ログが実装者に届いている	営業と現場で認識が分岐している
デモで認識ズレが早期に出る	結合直前までズレが見えない

次に確認すること

1. 定例の目的は「決める／見る／上げる」のどれか明示したか
2. 決定ログの置き場は一つか
3. エスカレーションの人名と期限はあるか
4. デモの周期はカレンダーにあるか
5. 追加要望の正式ルートは定例以外にないか（あるなら手順は？）

まとめ

週次定例だけで失敗しないチームは、定例が上手いのではない。決定とデモとエスカレーションが設計されている。発注側の仕事は出席ではなく、その設計を先に置くことだ。

---

進め方・体制の相談は、お問い合わせフォーム からどうぞ。