「言った・言わない」を防ぐ!ヒアリング後の認識合わせドキュメント作成法|現場で使える実践テクニック
こんにちは!
今日は「ヒアリング後の認識合わせドキュメント作成法」について解説します。
実はね、ヒアリングって聞くだけじゃなくて、その後の「確認」が超重要なんですよ。
僕が経験した「言った・言わない」トラブル
実は僕も新人時代、めっちゃな失敗をしました。
クライアントとのヒアリングを終えて、企画書を作成して納品したんですよ。
そしたらね、クライアントから「こんなの聞いてない!」って連絡が来たんです。
「えっ、でも確か聞きましたけど…」って思ったんですが、実は微妙にズレてたんですよ。
僕は「この要素は必要そうだな」って勝手に解釈して、クライアントの本当の意図を見落としてたんです。
その時に気付いたんですが、ヒアリング直後に「聞いたこと」を文書にして、クライアントに確認してもらうって、ほんま大事だなって。
これがないと、プロジェクトが進むにつれてどんどんズレが広がって、最後に「え、これじゃない」ってことになるんですよ。
認識合わせドキュメントの役割と必須要素
認識合わせドキュメント(僕たちは「ヒアリング確認書」と呼ぶことが多い)は、単なる報告書じゃないんです。
これはね、クライアントと制作チームが「同じゴール」を見ているかを確認するための重要なツールなんですよ。
このドキュメントに入れるべき要素は以下の通りです:
- プロジェクト概要
プロジェクト名、目的、背景、完成時期などの基本情報。
「なぜこのサイトを作るのか」という根本が書いてあると、後で判断に迷った時に役立ちます。 - ビジネスゴール
「成功とは何か」を具体的に。
例えば「PV数を月10万から30万に増やしたい」「問い合わせを月20件から50件に増やしたい」といった、測定可能な目標ですね。 - ターゲットユーザー
年代、職業、どういう課題を持ってるか、どんな行動をするか。
ペルソナまで落とし込むといいですよ。 - 主な機能・コンテンツ一覧
どんなページが必要か、どんな機能が必要か。
フォーム、お知らせ、メルマガ機能など、具体的に列挙しておくんです。 - デザイン・トーンに関する方向性
「モダンで洗練された」「親しみやすく温かい」みたいな感じですね。
参考サイトなんかも一緒に載せるといいですよ。 - 技術的な制約・要望
既存システムとの連携が必要か、特定のプラットフォーム必須か、などですね。
WordPress使いたい、とかもここに入ります。 - スケジュール・予算の確認事項
いつまでに何を納品するのか。
どこまでが予算に含まれるか。
ここが曖昧だと後で揉めるんですよ。
実践的なドキュメント作成フロー
では実際に、どうやってこのドキュメントを作って、クライアントに承認してもらうかという流れをお話しします。
ステップ1:ヒアリング直後に下書きする
ヒアリング会議が終わったら、できるだけ早く(遅くても翌日中に)、聞いたことを整理しましょう。
時間が経つと「あ、何て言ってたっけ?」って忘れちゃいますからね。
当日中なら記憶も新鮮ですし、もし不明な点があれば、翌日すぐにクライアントに確認できます。
ステップ2:「事実」と「解釈」を分ける
これ、めっちゃ大事なんです。
例えば、クライアントが「サイトで商品を売りたい」って言ったとします。
この「事実」は「商品を売りたい」です。
そこから僕たちが「だからECサイトにして決済機能つけましょう」って解釈するわけですね。
でも実は、クライアントの本意は「見積もりフォームからの問い合わせを増やしたい」だったかもしれません。
だから、ドキュメントには「聞いたこと」と「それに対する僕たちの解釈・提案」を分けて書くんです。
[聞いたこと]商品を売りたい[僕たちの理解]ECサイト化して、オンライン決済に対応する必要がある[質問・確認事項]現在の売上分析のデータはありますか?ターゲット層はどの年代ですか?
こんな感じで、クライアントが見た時に「あ、ちょっと違う」って気付きやすくするわけですね。
ステップ3:ビジュアルで補足する
ドキュメントは文字だけじゃなく、図解や表も入れるといいですよ。
例えば、クライアントジャーニーマップとか、機能のツリー図とか。
「話してたことはこういうことですよね」って、ビジュアルで確認してもらうと、認識ズレが一気に減ります。
ステップ4:クライアントに確認依頼する
ドキュメントができたら、クライアントに共有するんです。
その時に「このドキュメントの内容で間違いないか、確認いただけますか?」って一言添えるんですよ。
ここでね、返信期限も決めておくといいですよ。「来週金曜までに確認いただけると幸いです」みたいな感じで。
クライアントが確認して、修正点があれば修正します。
この往復が何回か続くかもしれませんが、これが「本当の要件定義」なんです。
この手間を惜しむと、開発が始まった後にめっちゃなトラブルになります。
ステップ5:サイン(確認)をもらう
最終的には「このドキュメントで了解します」っていう確認をもらいましょう。
メールでOKでもいいですし、Word形式でコメント返してもらってもいい。
とにかく「クライアントが確認した」という記録を残すんです。
これが後のトラブル防止になります。
よくある質問と対策
Q1:ドキュメントはどんなフォーマットで作るのがいいですか?
現場ではね、Word、