「言った・言わない」を防ぐ!ヒアリング後の認識合わせドキュメント作成法|現場で使える実践テクニック

C
クリオ
Web制作ディレクター / フロントエンジニア

こんにちは!

今日は「ヒアリング後の認識合わせドキュメント作成法」について解説します。
実はね、ヒアリングって聞くだけじゃなくて、その後の「確認」が超重要なんですよ。

僕が経験した「言った・言わない」トラブル

実は僕も新人時代、めっちゃな失敗をしました。
クライアントとのヒアリングを終えて、企画書を作成して納品したんですよ。
そしたらね、クライアントから「こんなの聞いてない!」って連絡が来たんです。

「えっ、でも確か聞きましたけど…」って思ったんですが、実は微妙にズレてたんですよ。
僕は「この要素は必要そうだな」って勝手に解釈して、クライアントの本当の意図を見落としてたんです。

その時に気付いたんですが、ヒアリング直後に「聞いたこと」を文書にして、クライアントに確認してもらうって、ほんま大事だなって。
これがないと、プロジェクトが進むにつれてどんどんズレが広がって、最後に「え、これじゃない」ってことになるんですよ。

認識合わせドキュメントの役割と必須要素

認識合わせドキュメント(僕たちは「ヒアリング確認書」と呼ぶことが多い)は、単なる報告書じゃないんです。
これはね、クライアントと制作チームが「同じゴール」を見ているかを確認するための重要なツールなんですよ。

このドキュメントに入れるべき要素は以下の通りです:

  • プロジェクト概要
    プロジェクト名、目的、背景、完成時期などの基本情報。
    「なぜこのサイトを作るのか」という根本が書いてあると、後で判断に迷った時に役立ちます。
  • ビジネスゴール
    「成功とは何か」を具体的に。
    例えば「PV数を月10万から30万に増やしたい」「問い合わせを月20件から50件に増やしたい」といった、測定可能な目標ですね。
  • ターゲットユーザー
    年代、職業、どういう課題を持ってるか、どんな行動をするか。
    ペルソナまで落とし込むといいですよ。
  • 主な機能・コンテンツ一覧
    どんなページが必要か、どんな機能が必要か。
    フォーム、お知らせ、メルマガ機能など、具体的に列挙しておくんです。
  • デザイン・トーンに関する方向性
    「モダンで洗練された」「親しみやすく温かい」みたいな感じですね。
    参考サイトなんかも一緒に載せるといいですよ。
  • 技術的な制約・要望
    既存システムとの連携が必要か、特定のプラットフォーム必須か、などですね。
    WordPress使いたい、とかもここに入ります。
  • スケジュール・予算の確認事項
    いつまでに何を納品するのか。
    どこまでが予算に含まれるか。
    ここが曖昧だと後で揉めるんですよ。

実践的なドキュメント作成フロー

では実際に、どうやってこのドキュメントを作って、クライアントに承認してもらうかという流れをお話しします。

ステップ1:ヒアリング直後に下書きする

ヒアリング会議が終わったら、できるだけ早く(遅くても翌日中に)、聞いたことを整理しましょう。
時間が経つと「あ、何て言ってたっけ?」って忘れちゃいますからね。
当日中なら記憶も新鮮ですし、もし不明な点があれば、翌日すぐにクライアントに確認できます。

ステップ2:「事実」と「解釈」を分ける

これ、めっちゃ大事なんです。
例えば、クライアントが「サイトで商品を売りたい」って言ったとします。
この「事実」は「商品を売りたい」です。

そこから僕たちが「だからECサイトにして決済機能つけましょう」って解釈するわけですね。
でも実は、クライアントの本意は「見積もりフォームからの問い合わせを増やしたい」だったかもしれません。
だから、ドキュメントには「聞いたこと」と「それに対する僕たちの解釈・提案」を分けて書くんです。

  • [聞いたこと] 商品を売りたい
  • [僕たちの理解] ECサイト化して、オンライン決済に対応する必要がある
  • [質問・確認事項] 現在の売上分析のデータはありますか?ターゲット層はどの年代ですか?

こんな感じで、クライアントが見た時に「あ、ちょっと違う」って気付きやすくするわけですね。

ステップ3:ビジュアルで補足する

ドキュメントは文字だけじゃなく、図解や表も入れるといいですよ。
例えば、クライアントジャーニーマップとか、機能のツリー図とか。
「話してたことはこういうことですよね」って、ビジュアルで確認してもらうと、認識ズレが一気に減ります。

ステップ4:クライアントに確認依頼する

ドキュメントができたら、クライアントに共有するんです。
その時に「このドキュメントの内容で間違いないか、確認いただけますか?」って一言添えるんですよ。
ここでね、返信期限も決めておくといいですよ。「来週金曜までに確認いただけると幸いです」みたいな感じで。

クライアントが確認して、修正点があれば修正します。
この往復が何回か続くかもしれませんが、これが「本当の要件定義」なんです。
この手間を惜しむと、開発が始まった後にめっちゃなトラブルになります。

ステップ5:サイン(確認)をもらう

最終的には「このドキュメントで了解します」っていう確認をもらいましょう。
メールでOKでもいいですし、Word形式でコメント返してもらってもいい。
とにかく「クライアントが確認した」という記録を残すんです。
これが後のトラブル防止になります。

よくある質問と対策

Q1:ドキュメントはどんなフォーマットで作るのがいいですか?

現場ではね、Word、