Webディレクターとしての仕事の一つに、サービスにおける要件定義およびワイヤーフレームがある。
要件定義はそのサービスにどういった機能が必要なのか、その機能の詳細はどういうものかを決めていく作業。ターゲットユーザーのニーズを満たし、抱える課題を解決する機能を洗い出し、制作・開発工程にのせていく具体的な仕様の策定が重要なポイントだ。最終的なアウトプットとしては「要件定義資料」や「機能一覧」などが一般的かな。
ワイヤーフレームは要件および仕様をもとにした、サービスの設計図のこと。各ページの要素（画像やテキスト）や情報整理、ナビゲーションなどの導線を詳細に落とし込んでいく。一昔前は、PowerPointやEXCELで作成してたけど、最近は「Adobe XD」や「Figma」などで作成するケースのほうが多い。私は最近「Miro」がお気に入りだ。
今日も陥った要件膨張の罠
で、要件の引き算について。今日もあるサービスの要件を整理しながらワイヤーを詰めてたら、いつものごとく要件が盛々になって収集がつかなくなってしまう状況に陥った。もちろん「この機能もこの導線もあったら便利」という前向きな気持ちからではあるんだけど、これが罠だ。
あれもこれもと欲張ると仕様が複雑かつ重たいものになり、なによりユーザーにとって分かりづらく使いづらいものになるのが常道。案の定、今日も打ち合わせに参加してるメンバー全員が「なんだかしっくりこない」「すっきりしない」「シンプルじゃない」とモヤモヤしていて、どうにも腹落ちしない状況にハマってた。やばいぞ。
私自身、Webディレクターの立場で「ユーザー視点で！」「シンプルに！」と常日頃から口酸っぱく唱えてるくせに、プロジェクトにどっぷりはまり込んでいると、往々にしてこの罠にハマってしまいがち。ほんと反省だ。
罠から抜け出すための対策
この罠から抜け出すには、ターゲットユーザーが誰なのか、一番に解決すべきニーズと課題は何なのかという根本に立ち返ることが大事。ユーザー視点でサイト設計されているか、ユーザーの体験はどうかをあらためて議論していくことが重要。そして勇気をもって余分な贅肉ならぬ余分な要件を削るべし。引き算するべし。これしかない。
ただ、どっぷりと案件にはまり込んでるメンバー同士だとこれがなかなか難しい。やはり客観視できる第三者的な人からアドバイスしてもらったり指摘をもらうのが効果的だ。一歩引いた視点で冷静な意見をもらう。もしくは少し時間をおいてあらためて議論するのもあり。
そんなわけで、今日の打ち合わせではなんとかメンバー全員が根本に立ち返り、最終的には引き算に同意することができたので一安心。スモールスタートでいいんだよと。ほんと膨らみがちな要件には要注意だ。
今日の気づき
要件定義でいつも陥るのは「あったら便利」の罠。でも「便利」と「必要」は違う。ユーザーが本当に必要としてるのは何かを見極めることが肝心だ。
10年以上Webディレクターをやってるけど、この引き算の難しさは変わらない。むしろ経験を積むほど「こんな機能もできる」「あんな導線も作れる」と選択肢が増えて、逆に迷いが生じることもある。
だからこそ、原点回帰が大切。ユーザーは誰で、何を解決したいのか。それを忘れずに、いつでもシンプルに。気概をもって。自戒を込めて。
