月に一度の、顧客との定例会。
先月の稼働状況を報告して、障害があれば説明して、質問がなければ30分で終わる。
「今日も特にありませんでした」
正直に告白します。私は長いこと、この状態を「順調な証拠」だと思っていました。
でも、あるとき顧客の担当者にこう言われました。
「この会議、必要ですかね」
言葉を失いました。こちらは報告義務を果たしているつもりだったのに、相手にとっては時間を取られるだけの場になっていた。
今回は、定例会をどう組み立てるかについて書きます。
なぜ定例会は形骸化するのか
原因を整理すると、3つあります。
1. 報告が「過去の話」しかない
先月何が起きたか。何件対応したか。
これは記録であって、会議でやる必要がありません。 資料を送れば済む話です。
2. 顧客が判断すべきことが出てこない
会議の価値は、その場で何かが決まることです。
報告だけなら、顧客は聞いているだけ。参加している意味を感じられません。
3. 毎回同じフォーマットで、変化がない
月次報告のテンプレートを埋めて、読み上げる。これを1年続ければ、誰でも飽きます。
定例会で話すべき3つのこと
では何を話すか。私は次の3点を軸にしています。
①過去：何が起きたか（15分）
これは必要です。ただし、時間をかけすぎないこと。
- 障害・トラブルの発生状況
- 対応した内容と結果
- 定型作業の実施状況
資料は事前に送っておき、会議では要点だけにします。数字の読み上げに時間を使うのはもったいない。
ここで大事なのは、「何も起きなかった」も報告すること。
「今月は障害ゼロでした」で終わらせず、「〇〇の監視で予兆を検知し、事前に対処しました」と伝える。防いだことを見せないと、何もしていないように見えます。
②現在：今どうなっているか（10分）
見落とされやすいのが、ここです。
- リソースの使用状況（ディスク、CPU、メモリの推移）
- 増加傾向にあるもの
- 気になっている兆候
「今は問題ないが、この傾向が続くと半年後に危ない」
こういう話ができると、会議の価値が変わります。顧客は将来の判断材料を得られるからです。
③未来：これから何を判断すべきか（20分）
ここが定例会の本体だと思っています。
- 対応が必要になりそうな課題
- 予算化を検討すべき事項
- 改善提案
- スケジュール調整が必要なこと
顧客に持ち帰ってもらう「宿題」を出す。
「こういう課題があるので、次回までに方針を相談させてください」
これがあると、次回の議題が自動的に決まります。会議が連続性を持つようになります。
資料の作り方
定例会の質は、資料でほぼ決まります。
事前に送る
当日配って読み上げるのは、時間の無駄です。2〜3営業日前に送っておく。
顧客が目を通していれば、会議はいきなり議論から始められます。
1枚目にサマリーを置く
顧客の担当者は、これを持って社内に説明します。1枚で状況がわかる資料があると、そのまま使ってもらえます。
サマリーに入れるのは、この4点です。
- 今月の状況（一言で）
- 発生した障害の件数と影響
- 対応が必要な事項
- 次回までの宿題
推移をグラフで見せる
数字の羅列より、グラフのほうが伝わります。特にリソース使用率は、推移が見えると将来の判断がしやすくなります。
形骸化を防ぐ工夫
続けていると、どうしてもマンネリ化します。私がやっていることを書きます。
①たまに議題を変える
毎回同じ流れではなく、その月ごとのテーマを入れます。
- 今月は監視設定を見直したので、その報告
- 来年度の更改について、早めに情報共有
- 他社事例の紹介
「今月はこれを話したい」というものを1つ持っていく。 これだけで印象が変わります。
②顧客の状況を聞く
こちらから報告するだけでなく、顧客側の予定や課題を聞く時間を作ります。
- 業務システムで何か変更予定はあるか
- 組織変更や人事異動の予定
- 予算の動き
これを知っていると、先回りした提案ができます。
「来期に拠点が増えるらしい」と聞いていれば、そのための準備を提案できる。情報を持っているかどうかで、提案の質が変わります。
③参加者を見直す
同じメンバーで長く続けていると、議論が固定化します。
- 実際に作業している担当者を連れていく
- 顧客側の別部署の人に同席してもらう
- こちらの設計担当を呼ぶ
視点が増えると、会議が動きます。
定例会でやってはいけないこと
逆に、避けるべきこともあります。
1. 悪い報告を後回しにする
障害やミスがあったとき、報告を先送りしたくなります。
でも、定例会で初めて聞かされるほうが顧客は怒ります。 発生時点で一報を入れ、定例会では経過と対策を話す。この順番です。
2. 技術用語をそのまま使う
顧客の担当者は理解できても、その人が上長に説明できない言葉は避けます。
「CPU使用率が閾値を超過」ではなく、「サーバーの処理能力が想定より高い状態が続いている」。
3. 提案を売り込みにしない
改善提案は必要ですが、毎回「これを買ってください」では警戒されます。
費用がかからない提案も混ぜる。 設定変更で改善できること、運用の工夫でできること。こういう提案があると、有償提案のときも聞いてもらえます。
4. 議事録を残さない
「言った言わない」を防ぐためにも、決まったことは記録に残します。
そして次回の冒頭で前回の宿題を確認する。 これがないと、話しただけで終わります。
定例会の頻度について
最後に、頻度の話を。
月1回が基本ですが、状況によって変えていいと思っています。
- 安定稼働が続いている → 隔月や四半期に減らす
- 大きな案件が動いている → 週次や隔週に増やす
「毎月やるものだから」で続けるより、必要な頻度に合わせる。
減らす提案をすると顧客が不安がるのでは、と思うかもしれません。でも、「内容がないのに時間を取らせている」ほうが、実は評価を下げます。
私は実際に「今は落ち着いているので、隔月にしませんか」と提案したことがあります。顧客の反応は「助かります」でした。
まとめ
顧客との定例会の組み立て方をまとめます。
話すべき3つのこと
- 過去（15分）— 何が起きたか。防いだことも報告する
- 現在（10分）— 今どうなっているか。傾向を見せる
- 未来（20分）— これから何を判断すべきか。宿題を出す
資料の作り方
- 2〜3営業日前に送る
- 1枚目にサマリー（顧客が社内展開できる形で）
- 推移はグラフで見せる
形骸化を防ぐ工夫
- たまに議題を変える
- 顧客の状況を聞く
- 参加者を見直す
やってはいけないこと
- 悪い報告を後回しにする
- 技術用語をそのまま使う
- 提案を売り込みにしない
- 議事録を残さない
定例会は、報告の場ではなく判断の場だと思っています。
何も決まらない会議なら、資料を送るだけで十分です。逆に、顧客が判断できる材料を出せれば、時間を取る価値があります。
「この会議、必要ですかね」と言われないために。そこを意識して組み立ててみてください。
コメント