こんにちは、コーダーのタカギです！
現在はWebサイトの実装を担当しつつ、UI/UXデザインという「設計」のスキルも武器にできるよう、日々学習しています。
前回の記事では、UI/UXは設計から実装までを貫く「線」であり、チームの「共通認識」が何より重要だ、という私自身の大きな気づきについてお話ししました。
では、その「共通認識」はいったいどうやって作っていけばいいのでしょうか？
今回はその共通認識の『土台』となる、サイト設計の最も上流部分、つまり「誰が、何のために使うのか」を定義するプロセスについて、コーダー視点で解説していきます。
「ペルソナ」は、ただの人物設定ではない！
「ペルソナ」と聞いて、どんなイメージを持ちますか？
正直に言うと、学習前の私は「なんかフワフワした理想のユーザー像でしょ？」「そんな架空の人物を設定して、本当に意味あるの？」と、少し懐疑的でした。
根拠を持って判断したいコーダーにとって、少し感覚的な作業に思えてしまったのです。
しかし、それは大きな誤解でした。
ペルソナの本質は、架空の人物設定を作って満足することではありません。チーム全員が同じ方向を向くための「意思決定のモノサシ」であり、道に迷った時に進むべき方向を示してくれる「コンパス」だったのです。
例えば、実装中に仕様の判断に迷った時。
「このペルソナの〇〇さんなら、AとBどっちの仕様を喜ぶだろう？」
「〇〇さんの目的を達成するためには、この機能は本当に必要だろうか？」
このように、チーム全員が同じ人物像を思い浮かべて議論することで、判断の根拠が明確になり、議論がブレなくなります。
そして、この「モノサシ」をより強力にするために、私が特に重要だと感じたのが、ペルソナを使って「誰が、何を、行動できる」という構文でユーザーの振る舞いを定義していくことでした。
ポイントは、行動を「〜する」ではなく「〜できる」と表現することです。
一見、些細な違いに思えるかもしれません。しかし、ここには大きな意味があります。
例えば、ECサイトで考えてみましょう。
この文章が示すのは「検索する」という一つの事実だけです。そのため、思考が「どうやって検索させるか」という機能実装に直結しがちで、「ユーザーが検索しない可能性」の考慮が抜け落ちやすくなります。
「ユーザーは、商品を、検索する」と定義した場合
「ユーザーは、商品を、検索できる」と定義した場合
この文章は、「検索するという選択肢がある」という状態を示します。
すると、自然と「（できるけど）検索しない」という、もう一つの可能性に目が向きます。「検索せずに、トップページの特集から商品を見つけるかもしれない」「検索が面倒で、サイトを離脱してしまうかもしれない」といった、ユーザーの多様な行動シナリオを考慮するきっかけが生まれるのです。
このように「〜できる」と定義することで、一つの機能に対して成功と失敗（あるいは別の行動）という、少なくとも2つ以上の可能性を最初から視野に入れることができます。
これが、ユーザーが本当に求めていることを深く考えるための、第一歩となるのです。
ユーザーの「物語」を実装の「設計図」に変える3ステップ
では、第二章で解説した「意思決定のモノサシ」を、どうやって具体的な設計に落とし込んでいくのか？
ここからは、私がUI/UXについて学んだ内容を、コーダーとしての視点で噛み砕いて整理した3つのステップとして、身近なECサイトを例に解説していきます。
このプロセスは、大きな機能を小さな関数に分解していくコーディングの思考フローにも似ていて、非常にロジカルに進めることができるので、きっと共感してもらえる部分も多いと思います。
STEP1: ペルソナ（誰が？） - ユーザーの解像度を上げる
まず、スタート地点となるペルソナを定義します。 重要なのは、単なるプロフィールではなく、その人が持つ「目的」と「課題」を明確にすることです。
【ECサイトのペルソナ例】
名前
佐藤 美咲（さとう みさき）
人物像
28歳、都内で働く会社員。友人の誕生日プレゼントを探している。
目的
友人が喜びそうな、ちょっとお洒落で気の利いたプレゼントを見つけたい。 できればラッピングも綺麗にして、メッセージカードも付けたい。
課題
ありきたりなものは贈りたくない。 忙しくてお店に買いに行く時間があまりない。 ネットだと、実物の質感やサイズ感が分かりにくくて不安。
この「目的」と「課題」こそが、佐藤さんが私たちのECサイトを訪れた時に「何に魅力を感じ」「どんな情報を探しているか」を教えてくれる重要なヒントになります。
STEP2: 行動シナリオ（どんな物語で？） - 行動の文脈を作る
次に、ペルソナがどんな状況で、どんな感情を抱きながらサイトを利用するかの「物語」を描きます。
これにより、ユーザーの行動に「文脈」が生まれます。
【佐藤さんの行動シナリオ】
来週に控えた友人の誕生日。佐藤さんはプレゼントを探していた。
インスタグラムでお洒落な人が紹介していた「〇〇（商品名）」を思い出し、「たしかギフトにも良さそうだったな」と、ブランド名で検索してECサイトにたどり着いた。
彼女が今一番知りたいのは、「その商品の詳細な情報（特にサイズ感や素材）」と「ギフト用のラッピングはしてもらえるのか」ということ。
このシナリオがあることで、チーム内には以下のような共通認識が生まれます。
「なるほど、佐藤さんのような人は、ギフト目的で来ている可能性が高いんだな」
「商品写真だけじゃなく、サイズ感がわかるような写真や、素材の説明を充実させないと不安にさせてしまうぞ」
「ギフトラッピングの可否やデザインは、分かりやすい場所に明記しておこう」
このように、提供すべきコンテンツの具体的な方向性が見えてくるのです。
STEP3: ユースケース（具体的な手順は？） - 物語をタスクに分解する
最後に、シナリオという「物語」を、具体的な「タスクのリスト」に分解します。
ここで、第二章で解説した「〜できる」という構文が活きてきます。
【佐藤さんのユースケース例】
ユーザー（佐藤さん）は、ECサイトで以下の行動ができる。
- トップページから、商品のカテゴリを閲覧できる。
- 商品名で、商品を検索できる。
- 商品詳細ページで、商品のサイズや素材、複数の写真を確認できる。
- ギフトラッピングのオプションを選択できる。
- メッセージカードを付けるオプションを選択できる。
- 商品をカートに入れ、購入手続きに進むことができる。
- （失敗ケース）商品の情報が不十分で、購入をためらって離脱できる。
このユースケースリストは、そのままサイトに必要な画面（商品詳細ページ、カート画面など）や機能（ギフトオプション選択機能など）の設計図になります。
そして、あえて「7. 離脱できる」という失敗ケースを記述しておくのがポイントです。
これにより、「どうすれば佐藤さんは離脱しないか？」「商品写真をもっと増やすべきか？」「ラッピングが有料なら、その価値が伝わるような見せ方が必要では？」といった、離脱させないための具体的な改善策を考えるきっかけが生まれます。
フワフワして見えたペルソナという「点」が、シナリオという「物語」を経て、具体的なユースケースという「タスクリスト」に落ちてきました。
この論理的なプロセスがあるからこそ、次の画面設計や機能実装のフェーズで「なぜこの機能が必要なのか」という確固たる根拠を持って進めることができるのです。
このプロセスが、私たちの仕事をどう変えるのか？
さて、ペルソナ、シナリオ、ユースケースと、丁寧すぎるくらいの準備をしてきました。
「正直、ちょっと面倒くさい…」と感じた方もいるかもしれません。
ここからは、この一見遠回りに見えるプロセスが、私たちの日々のコーディングや、プロジェクト全体にどれだけ素晴らしい影響を与えるかを、具体的に解説します。ここが、私が一番伝えたい部分です。
コーダーとしてのメリット：「なぜ作るか」が腹落ちする
まず、コーダーとしての私自身が感じているメリットは絶大です。
実装の優先順位が明確になる
ユースケースは、ユーザーが目的を達成するための「最短経路（クリティカルパス）」を示してくれます。
例えば、佐藤さんの例なら「商品を検索し、詳細を見て、カートに入れ、購入できる」という流れが最優先です。
だから、「まず検索機能とカート機能を実装しよう。メッセージカード機能はその次だ」という判断が、チームの共通認識として自然に生まれます。
もう、「どこから手をつけよう…」と悩むことはありません。
細かい仕様の判断に迷わなくなる
「このボタンの文言は『購入する』がいいか、『カートに入れる』がいいか？」――こんな風に、実装中の細かな判断に迷うことは日常茶飯事ですよね。
ここで、ペルソナという「モノサシ」が活きてきます。
「佐藤さんは、友人のプレゼントを色々見て回りたいかもしれない。
だったら『購入する』で手続きを終わらせるより、『カートに入れる』で他の商品も見れるようにする方が親切だよね」と、ユーザー視点に基づいた明確な根拠を持って判断できます。
手戻りが劇的に減る
これが最大のメリットかもしれません。
設計段階で「なぜこの機能が必要か」をチーム全員で合意できているため、開発の終盤になって「やっぱりこの機能いらないかも…」といった、あの忌まわしき仕様変更が格段に減ります。
これは、工数の削減以上に、僕たちの精神的な安定に大きく貢献してくれます。
UI/UXデザイナーを目指す上でのメリット：「意図」を伝えられる
そして、UI/UXデザイナーを目指す皆さんにとっても、このプロセスは最強の武器になります。
なぜなら、「なぜこのデザインなのか？」という根拠を、誰にでも分かる言葉で説明できるようになるからです。
ただ見た目が綺麗な画面を作るだけでは、UI/UXデザイナーとはいえません。
「佐藤さんの『実物の質感やサイズ感が分かりにくい』という不安を解消するために、ここの写真エリアは大きく取り、素材感が伝わるような写真を配置しました」
「ギフト目的の佐藤さんが迷わないように、ラッピング選択のボタンは一番目立つ色にしています」
このように、ペルソナとユースケースを元にデザインの意図を説明することで、あなたのデザインには強い説得力が生まれます。
プロジェクト全体のメリット：ユースケースは最強の「共通言語」
このプロセスの本当の価値は、個人や特定の職種だけでなく、プロジェクトに関わる全員にメリットがあることです。
特にユースケースは、驚くほど強力な「共通言語」として機能します。
対エンジニア（システム側）
「ここでユーザー認証が必要で…」と技術的な話から入るのではなく、「ユースケースの〇番で、ユーザーは購入手続きに進みます。
その前にログインが必要です」と話すことで、まず「何のためにそれが必要か」という目的が伝わります。
これにより、エンジニアは最適な実装方法を考えやすくなり、コミュニケーションが格段にスムーズになります。
対クライアント（UIに詳しくない方）
専門的なワイヤーフレームやデザインカンプをいきなり見せても、クライアントは戸惑ってしまいます。
しかし、その前に「御社のお客様（ペルソナ）は、このような手順（ユースケース）で商品を購入されます。
そのために、このような画面が必要なのです」と説明すればどうでしょう。
自分たちの顧客の物語として聞くことができるため、設計の意図をすんなりと理解し、納得感を持ってプロジェクトを進めてもらえます。
このように、ペルソナから始まる一連のプロセスは、チーム全員が同じユーザー像を描き、同じゴールを目指すための「航海図」を作る作業なのです。
まとめ：論理的な設計が、ユーザーの心を動かす
今回は、UI/UXの土台となる設計プロセスについて解説しました。
一見フワフワして見えるこの工程が、実は開発の「なぜ？」を支える、極めて論理的な設計図を作る作業だと伝わっていれば嬉しいです。
今回のポイントを簡単に振り返ります。
- ペルソナは、チームの「意思決定のモノサシ」である。
- 「〜できる」構文で、ユーザーの多様な行動を想定する。
- 「ペルソナ→シナリオ→ユースケース」の流れで、物語をタスクに分解する。
- このプロセスが、コーディングの迷いを減らし、チームの共通言語となる。
この土台があるからこそ、私たちは迷いなく実装に臨むことができ、本当に「使いやすい」サイトが作れるのだと思います。
さて、これでサイトの「骨格」が決まりました。
次回は、この設計意図を具体的な形にするための最強の仕組み、「デザインシステム」について解説します。これもまた、コーダーならきっとワクワクする世界です。
ぜひ、次回の記事も楽しみにしていてください！
最後まで読んでいただき、ありがとうございました！
