プロジェクトの成功はヒアリングで9割決まる
2022.11.04
ちょっとブログっぽいタイトルにしてみました。笑
Web制作において最も大事な工程って何だと思いますか?
プロジェクト全体の軸となる企画やコンセプト?しっかりと成果に繋げるためのマーケティング?分かりやすく伝えるための設計?結局デザインが良くないと台無しだからデザイン?バグや崩れのない正確なコーディング?
…どれも正解だと思いますが、私はヒアリングだと思っています。
ヒアリングでお客さまが感じている課題や想い、価値観をどこまで抽出できるかによって、プロジェクトの成否の9割が決まると言っても過言ではないと考えています。
ヒアリングで確認すること
プロジェクトによって項目や進め方は変わりますが、
基本的にmono.では以下の項目の中で、事前情報から分からなかった部分やもっと掘り下げたいと感じた部分を顔合わせ時にお伺いするようにしています。
- サービスについて
- サイト名(サービス名・企業名など)
- URL
- どのようなサービスか
- サービス名、サイト名の由来
- サービスの強み / こだわり
- ユーザーに選ばれているポイント
- 主な競合
- 集客手段
- ターゲット層
- プロジェクトについて
- ご要件
- プロジェクトの目的
- サイト立ち上げ/リニューアルの背景(なぜ今やるのか)
- お声がけいただいた理由
- 対応範囲
- ご予算
- 公開希望時期
- 現状の課題と残したい点について
- リニューアル後も残したい点
- リニューアルで改善したい点
- 表現について
- 色味(指定やご希望がある場合)※理由も確認する
- 参考サイト
- どのように参考にしたいか
- 参考にしたくないサイト
(他にも実績の掲載可否や保証ブラウザ、サーバー契約の話などもしますが、この記事の主旨からは少しずれるので割愛します。)
大項目としては以下の4つです。
- サービスについて
- プロジェクトについて
- 現状の課題と残したい点について(リニューアルの場合のみ)
- 表現のイメージについて
これらについて、事前にいただいている資料やメール、既存のWebサイトなどを見て埋められるところは埋め、埋められない部分も分かる情報を元に「多分こういうことかな?」と仮説を立ててヒアリングに臨むようにしています。
4.についてはヒアリング・ディスカッションの材料にできるよう、ある程度想定される参考サイト・事例を事前に集めておきます。
(良い例だけでなく、あえて合わなそうな例もいくつか集めます。)
しっかりと仮説を立てることである程度質問の回答を予測することができるのでスムーズに会話ができます。
また、仮説が当たっていればお客様から自分のことを分かってくれているという評価をいただけますし、たとえ外れていたとしても、根拠を持って、失礼がないように仮説を伝えれば主体的に考えて提案できる人という風に見ていただけて今後の信頼関係にも繋がりやすいです。
…と、少し話がそれましたが、それぞれの項目について、掘り下げて説明していきます。
1.サービスについて
そのプロジェクトよりも前の話である、そもそもどんなサービスのサイト制作を担当させていただくのかといった情報をまず理解していきます。
文字通りそのサービスが何を出来るサービスなのか?といった話から始まり、サービスの強みや選ばれている理由、ターゲット、といった一歩踏み入った情報、お客様から何と言っていただけることが多いか?のような別視点での意見も分かるような質問もさせていただきます。
そのほか、サービス名の由来といった直接的には制作に関係のない情報もなるべく多く把握しておくと、あとあとコンテンツやデザインに深みを出していきやすいです。
2.プロジェクトについて
どのくらいの制作期間・予算で、どれだけの範囲の対応を請け負うか、といった情報や、ご依頼の背景などのこのプロジェクトに限った話を整理していきます。
少し事務的な内容も多いですが、のちのち認識のすれ違いなどで問題を起こさないためにも重要です。
また、与件に対してスケジュールや予算的に厳しい場合、実現できない可能性があるご要望がある場合などはこの時点で相談します。
あまりネガティブなことを伝えると失注になってしまうかも、、と怖くなる気持ちもありますが、ここで誤魔化して受注すると後々トラブルになって成果にもつながらず、お客さまとの信頼関係が崩れるような結果にもなりかねないので、ここは勇気を持って伝えます。
(もちろん、ただ出来ませんというだけでなく、なるべく「こういう形であれば実現できますよ」という代替案もセットでご提案するようにします。)
また、そういった条件的な話だけでなく
- なぜ今やるのか
- なぜ私にお声がけいただけたか
といったプロジェクトの背景事情についてもお伺いさせていただきます。
この質問の答えは、現在の本質的な課題やお悩み、お客さまの価値観や歴史、これからの展望など後のプロジェクトコンセプトにも通ずる重要な情報が多く詰まっていることも多いと感じます。
3.現状の課題と残したい点について(リニューアルの場合のみ)
リニューアルの場合は、現状のサイトの課題点と残したい点を整理します。
せっかくリニューアルをするならと現状サイトの全てを一新したくなる気持ちに燃えたりもしますが、実際には現在のサイトの全てが悪いわけでなく、改善したい部分があるが、何かしら残したいエッセンスもある場合がほとんどだと思います。
(もしもブランドを1から全て作り変えるようなリニューアルになりそうな場合は、そうする理由を念入りに確認します。)
なので、この項目では、お客さまが今持っている価値までもが失われないよう、ヒアリングを通じて残すべき部分、変えるべき部分を整理していきます。
ちなみに余談ですが、この項目について話す際は既存サイトの課題点を洗い出す必要がありますが、その時に既存サイトを無闇に悪く言わないように気をつけています。
何か課題があってリニューアルすることになったというのは間違いないことですし、プロとして必要な意見はしっかり伝える必要がありますが、 今のサイトにも様々な想いや経緯が詰まっており、公開当時はこれがベストと判断されてリリースされたもののはずなので、なるべくそういった過去に寄り添った言い方を心がけるようにしています。
4.表現のイメージについて
最後に、参考サイトなどを交えながらどういうイメージならプロジェクトに合いそうか、逆にどういう表現は今回のプロジェクトとは合わなそうか、といった点をヒアリング(というよりディスカッションの性質が強くなることも多いです)をしていきます。
1〜3は言語化重視な分、言葉では通じ合ったように感じても頭で思い描いているイメージは全然違った!みたいなこともよくあるので、4.はその辺りの言語化しきれない範囲のピントを合わせていく工程です。
ちなみに、具体例としてデザインや構成の話をしますが、
初期のヒアリングの段階で大事にしているのはもっと手前の「価値観のすり合わせ」です。
ヒアリングの時点ではあまり何かを決める話よりも、
「こういう雰囲気のサイトどう思いますか?」とか、「このサイトの伝え方どう思いますか?」とか、お客さまの考えを一つでも広く、深く知るということを重要視しています。
価値観を知ることが最も大事で、この時点での参考の表現はあくまでその一例、という考え方です。
ちなみにちょっと余談ですが、参考について話す時は参考のどの部分について話しているのか要注意です。
デザイントーンの話なのか、分かりやすさの話なのか、使いやすさの話なのか、ブランドの性質的な話なのか、アイデアの話なのか、などの認識がずれていると後になって大きな問題になることがあります。
この辺を冷静に切り分けて話すのは意外と経験が必要なので、ヒアリングする際は常に気をつけておき、話がずれていると感じたら一度立ち止まって前提をすり合わせる話をした方が良いです。
大体ここまで来ると、やっとそのプロジェクトにおける輪郭のようなものがぼんやりと見えてきて、良しとする価値観、悪しとする価値観が分かってくるので、
それを元にこの後の戦略や設計、デザインの話に進んでいきます。
はっきりとした回答がない場合
ちなみに余談ですが、質問によってはお客様の中でも回答が言語化されていないケースなどもあります。(経験上そこまで頻繁ではないのですが)
ここでも仮説の出番です。
それぞれの項目に仮説を持って臨んでいると、仮にお客様が質問の回答をまだ言語化できていなかった場合、こちらから仮説を当てて質問することができます。
例えば「現在のwebサイトにこういう文章があったので、おそらくこういうことをお考えではないかなと推測しているのですが、実際のところどうでしょうか?」と。
そうすればその仮説が「合ってる」「間違ってる」「分からない」といったレベル感の回答はいただけることが多いです。
Webサイトの制作というのは決して安くないご予算をいただいて行うものなので、本当に目的がはっきりしないままご相談いただくケースというのは稀で、言語化までは出来ていなかったとしても感覚的にある程度の答えをお持ちである場合が多いです。
なので、仮説を伝えた上で、その仮説が合ってるならなぜ良いと思ったか、間違ってるなら何が違うと思ったか、分からないのであれば何で判断できないか、ということを深ぼっていくと、結果的にその会話で欲しい回答を得ることができます。
ちなみにこの「なぜ」の回答に詰まってしまっていそうだった場合は、またこちらから理由の仮説も当てて考えを深掘っていきます。
まとめ
いかがだったでしょうか?
途中で「輪郭」という言葉を使いましたが、ヒアリングとはプロジェクトの輪郭をクリアにしていく工程だと考えています。
もちろんその後の工程がダメだと台無しなのでヒアリングが全てというわけではないですが、ヒアリングによってプロジェクトの課題や目的、制約、価値観などをしっかりと整理できていないプロジェクトは枠線のない塗り絵みたいな感じで何を作っているのか分からなくなり、収拾が付かなくなってしまいます。
ちなみに今回は受託系プロジェクトをイメージして書いた話でしたが、
自社開発のプロジェクトなどの場合の要件定義にも似たようなことが言えるのではと思います。
(自社開発はあまり経験がないので想像ではありますが…)
上司やリーダーに、あるいは自分自身にヒアリングしながら今回のような項目を埋めていくことで、精度の高いプロジェクトの第一歩が踏み出せると思います。
MDNデザイナーズファイル2022
今を代表するデザイナーや制作会社がまとめられた本です。グラフィック系がメインですが、web制作会社もノミネートされています。