私の事例：面談後の報告書
面談後の報告書づくりで大事なのは、「どういう文章がいいか」を指示文で説明することではなく、過去に自分が納得した報告書を1本そのまま手本として渡すことです。文体の硬さや粒度のニュアンスは言葉だけでは詰め切れないという、私自身の経験からの気づきをまとめました。
なぜこのやり方にしたか
面談のたびに「もっと具体的に」「硬すぎない文体で」と指示を重ねるのは時間がかかります。私の場合、指示文を長くするより、過去に自分が納得して出した報告書をそのまま参照させるほうが早く伝わりました。
情報全体の流れ
面談の音声を文字起こしする → 面談相手の背景資料を読む → 過去の合格ラインの報告書を参照する → ドラフトを作る（計画→生成→評価を最大2周）→ 自分が確認する → Wordテンプレートへ流し込む → 記録と顧客情報を更新する
文字起こしは、対面ならMacの標準アプリ「ボイスメモ」、オンラインならGoogle Meetの自動文字起こし機能を使っています。有料の議事録AI（PLAUD、Nottaなど）は使っていません。面談相手の背景資料は、顧客管理に使っているNotionから取得します。文字起こしだけでは「今回何を話したか」しか分からず、過去の経緯を踏まえた報告書にするためのひと手間です。
文章の基準は、言葉で説明するより実物を見せる
ここがいちばん伝えたいところです。「どういう文章がいいか」を言語化するより、合格ラインの実物を1本渡すほうが確実に伝わります。
指示文をどれだけ丁寧に書いても、文体の硬さや粒度のニュアンスは言葉だけでは詰め切れません。過去に自分が「これでいい」と判断した報告書を参照材料として渡せば、そこにある暗黙の基準ごと引き継がれます。
構成は3分類で固定している
書くたびに構成を考え直すことをやめ、次の3つに固定しました。文体も「である」調で統一しています。
| 分類 | 内容 |
|---|---|
| 経営者聴取内容 | 面談で聴き取った現状・悩み・意向 |
| 課題・改善点 | 聴取内容から見えた課題の整理 |
| 今回の支援内容 | 今回の面談で実施した支援・助言 |
この3分類は、面談の内容がどう変わっても崩れません。構成を固定したことで、ドラフトを作る側も何を埋めればいいかが毎回はっきりします。
つまずいたところ
- 自分が確認しただけでは渡っていない：手本のファイルを自分が開いて読んでも、書かせる側には届いていません。ファイルの置き場所を次の工程へ明示的に渡す必要があります。渡したつもりで渡っていない、という事故が起きやすいところでした
- ヘッダー情報を本文に書かせない：会社名・日付などはテンプレート側で管理し、本文には書かせないようにしています。両方に持たせると、どちらかが必ず古くなります
ヒント同じことをやるなら
文体や粒度の基準は、指示文を長くするより「合格ラインの実物を1本渡す」ほうが確実に伝わります。過去の成果物が1本でもあるなら、それを手本として読ませる工程を最初に組み込んでみてください。