以前、あるクライアントの要望をヒアリングし、その内容をそのまま要件定義書にまとめて公開直前まで進めたことがあります。ヒアリングでは「使いやすいサイトにしたい」「問い合わせを増やしたい」と言われた通りに項目を並べ、抜け漏れなく仕上げたつもりでした。
ところが完成間近になって、クライアントから「なんだかイメージと違う」と言われてしまったのです。要件は一つひとつ確認しながら進めていたのに、です。
原因は、要件定義の「項目」は埋めていても、「視点」が足りていなかったことでした。クライアントの言葉を正確に拾うことと、クライアントが本当に実現したいことを見抜くことは、実は別の作業なのです。
「進め方」を知っていても要件定義でつまずく理由
要件定義の進め方や決めるべき項目は、調べればいくらでも情報が出てきます。5W1Hで整理する、機能要件と非機能要件に分ける、要件定義書のフォーマットに沿って埋めていく――どれも大切な基本です。
ただ、フォーマットを正しく埋めることと、良い要件定義ができることは、必ずしもイコールではありません。項目はすべて埋まっているのに、後工程で「思っていたのと違う」「これでは実装できない」といった食い違いが起きるのは、その項目を誰の視点で埋めたかが抜け落ちているからです。
進め方や項目そのものについては、以前まとめたWebディレクターの要件定義とは？仕事内容・進め方・要件定義書の作り方を解説で詳しく触れていますので、今回は「何をやるか」よりも「どう見るか」に絞ってお話しします。
要件定義でぶれてはいけない3つの視点
現場で要件定義を担当するとき、私は次の3つの視点を常に行き来するようにしています。どれか一つに偏ると、必ずどこかで歪みが出ます。
| 視点 | 見るべきもの | 抜け落ちたときに起きること |
|---|---|---|
| ①クライアントの視点 | 要望の奥にある本当の目的・ビジネスゴール | 表面的な要望だけを反映し、「言った通りなのに違う」と言われる |
| ②ユーザーの視点 | サイトを実際に使う人にとっての分かりやすさ・使いやすさ | 発注側の都合を優先し、成果につながらないサイトになる |
| ③制作チームの視点 | 予算・スケジュール・技術で実現できる範囲 | 決めた要件が制作段階で実現できず、手戻りが発生する |
①クライアントの「本当の目的」を見る視点
クライアントが口にする要望は、あくまで表面的な言葉であることがほとんどです。「使いやすいサイトにしたい」という言葉の裏には、「問い合わせ対応の負担を減らしたい」「営業が説明しなくても成約できるサイトにしたい」といった、本人も明確に言語化できていない目的が隠れています。要望をそのまま要件に変換するのではなく、「なぜそれが必要なのか」を一段掘り下げて聞くことが欠かせません。
②使う人(ユーザー)の視点
要件定義は発注者と制作側の合意形成の場になりがちですが、そこに実際にサイトを使う人の視点が抜けると、内輪の理屈だけで仕様が決まってしまいます。「自分がそのサービスのユーザーだったら、この導線で迷わないか」を都度想像しながら要件を精査することが、実務では大きな武器になります。
③制作チームの「実現可能性」の視点
クライアントの要望をすべて盛り込みたい気持ちは分かりますが、予算・スケジュール・技術的な制約を無視した要件定義書は、後工程で必ず破綻します。要件定義の段階でエンジニアやデザイナーに「これは現実的に可能か」を確認しておくことで、制作フェーズでの手戻りを大きく減らせます。
3つの視点がぶつかったとき、ディレクターがすべき判断
3つの視点は、常に一致するとは限りません。クライアントが望む機能が、ユーザーにとって使いにくかったり、制作側の予算・期間で実現できなかったりすることは日常茶飯事です。
そんなとき私は、次の順番で考えるようにしています。
- その要望は、クライアントの本当の目的を達成する手段として本当に必要かを、まず問い直す
- 必要だと判断できたら、ユーザーにとって不利益にならない実現方法がないかを探す
- それでも実現が難しい場合は、代替案を持ってクライアントに相談する(できない、で終わらせない)
大事なのは、「クライアントが言ったから」でも「作りやすいから」でもなく、目的に照らして判断することです。判断に迷ったときほど、①〜③のどの視点を優先しているのかを自分の中で言語化しておくと、後からクライアントにも説明がしやすくなります。
現場でよくある「視点の抜け落ち」失敗パターン
クライアントの言葉をそのまま要件にしてしまう
ヒアリングで出た言葉を疑わずにそのまま書き起こしてしまうと、クライアント自身も気づいていなかった認識のズレが、公開直前まで表に出てきません。要件定義の段階で「つまりこういうことですよね」と自分の言葉で言い換えて確認する一手間が、後の手戻りを防ぎます。
作りやすさ優先で仕様を決めてしまう
制作側の負担を減らそうとするあまり、既存のテンプレートやよくある構成に寄せてしまうことがあります。効率を考えること自体は悪くありませんが、それがユーザーにとっての使いやすさよりも優先されてしまうと、本末転倒です。
技術確認を後回しにして手戻りが発生する
要件定義の段階でエンジニアの確認を挟まず、クライアントとの合意だけを優先して進めてしまうケースです。設計や実装の段階になって「その仕様は難しい」と判明すると、スケジュールと信頼関係の両方にダメージが及びます。
3つの視点を自然に拾うための工夫
3つの視点を毎回意識するのは、慣れないうちは負担に感じるかもしれません。私が実務でやっているのは、ヒアリングや要件定義書のチェック段階で、次のような問いを自分に投げかけることです。
- この要望の「目的」は何か、クライアントに一段掘り下げて確認したか
- この仕様は、実際に使う人の立場だったらストレスなく使えるか
- この要件は、今のスケジュールと予算で本当に実現できるか
要件定義書の各項目の横に、この3つの視点でチェックした形跡を残しておくと、後から見返したときにも「なぜこの仕様にしたのか」を自分自身で説明できるようになります。
まとめ:視点を持つことが要件定義書の質を決める
要件定義は、項目を漏れなく埋める作業ではありません。クライアント・ユーザー・制作チームという3つの視点を行き来しながら、要望の奥にある目的を見極める仕事です。
進め方や項目そのものをもう一度確認したい方は、Webディレクターの要件定義とは？仕事内容・進め方・要件定義書の作り方を解説もあわせてご覧ください。
ディレ和尚のひとこと
要件は言葉で埋めるものにあらず、視点で満たすものなり。
