目的を達成するための『モデル』を描ける者こそが、UIとAIを制する

読むきっかけ

フロントエンドエンジニアとして、簡単な画面デザインを作成したり、他人が作ったUIを調整したりすることはよくある。

ただ、デザインを作る・評価する上で、自分の中に確固たる軸があったわけではない。 『ノンデザイナーズ・デザインブック』で言われているような、よいデザインの法則ぐらいは把握しているつもりだ。しかし、法則を知っているだけでは、結局は「経験＋勘」という主観的なアプローチに頼らざるを得ない。

また、「UX > IA > UI」というヒエラルキーの概念は知っていたものの、それを具体的な方法論に落とし込んで実現する方法については、あまり深く考えてこなかった。

本書を手に取ったのは、業務でも使えるような**「構造計算された基礎」**の上で、デザインの作成や判断ができるようになるのではないか、という期待があったからだ。

学びの要点

• 「モデル」とはデザインの土台である：潜在的なユーザーの用途調査、コンセプトの確立、ユースケースやコンテンツの定義を通じて作られる。
• 土台なきUIは機能しない：「モデル」こそがUIを作る上での土台であり、これが不十分だと、いくら表層のUIを作り込んでも、結局はユーザーにとって使いづらいものになってしまう。
• ソフトウェアデザインの定義：ユーザーから見た使い方を決定していくプロセスである。ユーザーがいるからこそ、ソフトウェアの存在意義がある。
• 複雑性の隠蔽：ユーザーの関心は表側に見える部分だけである。中身（システム）はユーザーから隠蔽すべきであり、複雑なシステムほどその必要性が高い。
• 情報設計の本質：送り手と受け手の双方の意図を満たすような情報の構造を作ること。送り手が意図通りに情報を伝える、あるいは受け手が望む情報を送り手が与えるための設計である。
• UIデザインにおける作業割合：情報を整理する作業が全体の約6割、インタラクション関係が3割、見た目関係が1割程度を占める。
• 機能よりユースケース：機能という成果物を作ること以上に、ユーザーが機能をどう使うのかという「ユースケース」を考えることが重要。逆に言えば、ユースケースに沿わない機能は作らない姿勢が求められる。
• ペルソナモデルの活用：ユースケースの主語となる想定ユーザーの姿を「ペルソナモデル」としてモデル化し、UI設計のための分析材料として活用する。

モデルベースUIデザインの実践

「UXは直接デザインできない」というのが、本書の根本的な出発点だ。

ユーザーストーリーやカスタマージャーニーマップをそのままUIに落とし込もうとしても、その間には大きな変換のギャップが存在する。本書はこのギャップを埋めるために、4つのモデルを介した変換プロセスを提唱している。

1. 概念オブジェクト（Conceptual Objects）

ソフトウェアが扱う具体的な「もの（Things）」を特定するモデルだ。ユーザーストーリーやカスタマージャーニーマップから名詞を抽出することで導き出す。

例えば「ユーザーが購入履歴を確認できる」というユーザーストーリーがあれば、「ユーザー」「購入履歴」という概念オブジェクトが抽出される。抽出したオブジェクトはユースケースの定義と照らし合わせて検証し、ユーザーの意図と整合しているかを確認する。

2. ユースケース（Use Cases）

「誰が（Who）、何を（What）、どのオブジェクトに対して（Which）できるか」 というシンプルな構文で表現する。

「〈購入者〉が〈購入履歴〉を〈閲覧〉できる」のような形だ。この言語的アプローチにより、ユーザーの目的と必要な機能を明確にでき、チーム内での認識合わせにも有効に機能する。

「誰」はユーザーペルソナ（前工程で定義した主語）、「何」は概念オブジェクト（名詞として抽出したもの）、「行動」は後述するタスク（動詞）にそれぞれ対応している。機能一覧ではなく「用途の文」として定義するため、何を・なぜ作るのかという意図がチーム全体で揃いやすい。

3. タスク整理（Task Organization）

UXドキュメントから抽出した動詞を構造化するモデルだ。ユーザーのアクションをシステムの機能にマッピングし、CRUDの原則（Create・Read・Update・Delete）を活用して仕様を精緻に定義する。

「閲覧する」はRead、「登録する」はCreate、という形で整理することで、必要な機能の抜け漏れを防ぎ、実装仕様の粒度を揃えることができる。

ユーザー側の動詞とシステム側の処理を対にして表に並べ、そこへCRUDのラベルを付与するのが基本的な作り方だ。これにより、似たような言葉でも「更新（U）なのか削除（D）なのか」を明確に区別でき、実装の仕様漏れや粒度のばらつきが起きにくくなる。

4. コンセプト（Concept）

以下の4つの柱でデザインの方向性を定義する：

1. ユーザーに体験してほしいこと（Desired user experience）
2. デザイン哲学（Design philosophy）
3. 目的ステートメント（Purpose statement）
4. コンセプトイメージ（Conceptual imagery）

このコンセプト定義があることで、UIの個々の意思決定に一貫した軸が生まれる。「なぜこのレイアウトなのか」「なぜこのフローなのか」という問いに対して、主観ではなくコンセプトを根拠として答えられるようになる。

ボーナス：リバースモデリング

本書では、既存のソフトウェアを分析する手法として「リバースモデリング」も紹介されている。可視化されているUIから逆算して概念モデルを推測するアプローチだ。

競合製品のデザインを「なぜこうなっているのか」という視点で読み解いたり、自社プロダクトの現状モデルを洗い出したりする際に活用できる。既存UIがあるチームにとっては、ゼロから設計するより先にリバースモデリングで現状を可視化するのが現実的な第一歩になるだろう。

業務活用ポイント

実際に一部を試してみて

本書の「モデル」定義の方法論は、どの開発フェーズにいるかに関わらず、解決策を導き出した際に用いた「モデル」として活用できると考えている。

例えば、ユースケースの洗い出しを行った上で、それを満たすためのUI提案やプロトタイプ作成を求めることができるだろう。そして、そのユースケースはそのまま、ユーザーがソフトウェアを使う際の「シナリオ」としても活用可能だ。

本書ではユースケースを「〈誰〉が〈何〉を〈行動〉できる」という構文で表現しているが、これを拡張すればそのままユーザーストーリーになる。最後に「なぜならば〈目的〉だから」を追加するだけで、ユーザーストーリーの形式が完成するからだ。

実際に業務で、ユーザーストーリーを基にした統合テストをパイロット導入してみたが、実装の意図が明確になり、真にカバーすべきユーザー導線にも対応できるため非常に有効であった。

さらに試してみたいこと

ユースケースの主語となる想定ユーザーを深く知るには、ユーザーと直接接して得られる1次情報（ユーザーインタビューやテストなど）から抽出するのが一番有効だと考える。

ユーザー定義とユーザーストーリーが掛け合わされば、どんなユーザー導線を想定してその機能が考えられたかという「経緯」を明確に共有できる。 今後は、想定ユーザーの定義を1次情報から抽出し、より解像度の高いモデル化に挑戦してみたい。

読んでみての所感

これまで私が「UX + IA」という基礎として捉えていたものを、本書を通じて「モデル」として再定義できたことが最大の収穫だった。 この「モデル」をベースに情報設計を行った上でUIデザインをする（まさに本書のタイトル通り）という視点を得られたのは非常に大きい。

「モデル」という土台をしっかりと構築できれば、自信を持ってUIを作ることができるし、ユーザーにとって本当に使いやすいソフトウェア設計が可能になる。

完成されたデザイン（本書でいうルック&フィール）だけでは、「なぜこうなっているのか？」という意図が、受け手の主観によって解釈されてしまう。しかし、デザインの背後にある「モデル」を洗い出すことで、その意図が第三者にも正確に伝わるようになる。

これは、AIに指示するプロンプトや実行プランを作ることと非常に似ていると思う。

デザインを作る際にも、AIに指示する際にも、目的を達成するための「モデル」をしっかりと作ることが不可欠だ。 デザイン・開発・その他の業務プロセス全てにおいて、この「モデル構築」へのメンタルモデルのシフトが、今後のAIシフトにおいても重要な鍵を握るはずだ。

言わば、「モデル」を作ることができる人が、AIを真に使いこなせる人になるのだろう。