クライアントとの認識の違い FirE♯ 729

大規模なWEBサイトのリニューアル案件で問題が生じています。

それは認識の違いでした。

【要件定義書】

大規模な案件であったために要件定義書を作成しヒアリングを元に要件定義書を作成していきました。

要件定義は、クライアント一緒に進めていくわけですが、今回の案件はクライアント側の年齢層が高く「絵を見ないとわからない」という意見が出るのでした。

絵とはデザインのことです。

要件定義が完了しない段階からデザインをすることになるため、これは行わず要件定義書で認識を合わせていきました。

これが失敗の始まりであったのです。

【正直ワカラン】

要件定義書について書いている側からしても意味がわからないというのが事実でした。

今回の要件定義書については、
デザイナー兼ディレクターの指示のもとに作成をしていきました。

正直なところ、ブレブレなのでした。

定期的に要件定義書をクライアントと共有するために、整理する作業を行いました。

ここでデザイナー兼ディレクターとともチェックをし、内容、表現、文末の言い回し、箇条書きなどといったところまで直していきました。

そしてこれでOK！なりクライアントと共有します。

そしてクライアントから質問がきます。

そして改めて要件定義書をデザイナー兼ディレクターと見直します。

ここでまさかの発言。
「この書き方じゃ伝わらない、日本語がおかしい」

「いやいやいや！おまえがそう言うたし直しとんねん！！」

という言葉を飲み込み
「あ、なるほど〜、ほんまですね〜」

と、言ってまた直すのです。

このような事が幾度もあり、「主観」によって構成された要件定義書は、見ただけでは意味がわからないものになっていくのでした。

だって本人も毎回言う事が変わるわけで、
「定義」などできていないのです。

【反省点】

問題の根本はリテラシーの差です。

制作側はITリテラシーは一定は持っています。
しかし、そのクライアントの業界の常識と言えることをわかっているかと言えばそうではない。

つまり、リテラシーの差は制作側もクライアント側もお互い様なのです。

しかし、制作側が常識をクライアントの押し付けすぎたことで、十分な理解がすすまないままに進んでいきデザインの定時の段階で、

「え？この機能は？」
「このコンテンツ、ページはどうするの？」

と言った事が出てきて
追加費用が発生したり、納期の延長といったことになるのです。

制作側はクライアント側に立って認識を合わせにいく必要があります。
クライアントに認識を合わさせるような立ち位置を取ると失敗します。

【ワイヤーフレーム】

今回の反省点から具体的な解決先としてはワイヤーフレームの提示になります。

うちの場合の制作の流れは
参考サイトや、クライアントの要望を聞いた上で、デザインを作成します。

小規模な案件はこれで良いでしょう。

しかし、大規模な案件の場合にこれを行うとデザインの修正に時間を要することになります。

また、今回のようなリニューアル案件の場合には、コンテンツの移行、統合、削除などの認識が要件定義書で十分に認識合わせが進まないこともあります。

ここでワイヤーフレームがあれば、どのコンテンツがどこにあるのかが、一目でわかります。

今回の案件でクライアントが言っていた
「絵で見ないとわからない」は、
「デザインをみたい」ではない
「ワイヤーフレームを見せて欲しい」という訴えであったのです。

要件定義書という文章レベルでの認識合わせは非常に高度です。
ワイヤーフレームでよりWEBサイトのページをイメージしやすい形で提示することで確実な認識合わせと、
巻き戻しの作業を起こさないことにも繋がります。

【まとめ】

クライアントとの認識の違いについて書きました。

制作側がクライアントの立場に立って認識を合わせていく事が重要です。

あと、もう一つ必要なのは「聞く耳」です。