レッスン5：設計意図を言葉で伝える——ワイヤーフレームと仕様の書き方

このレッスンで学ぶこと

ワイヤーフレームの忠実度の段階と、それぞれの使いどころを理解する
画面を見せずに、目的・優先順位・状態・例外を言葉で伝える書き方を身につける
実装者と揉めない仕様の粒度を判断できる
レビューの場で論点をずらさずに進行する方法を学ぶ

レッスン4では、情報のまとまりと階層を組み立てる情報設計を学びました。このレッスンでは、その構造を実際の画面としてどう伝えるかを扱います。設計を担当する人と、それを形にする人が別々である現場は少なくありません。両者のあいだで意図がうまく伝わらないと、できあがった画面は当初の狙いから外れてしまいます。本コースは画像を使わない構成のため、このレッスンでは特に、画面を見せずに意図を伝える書き方に重点を置きます。

ワイヤーフレームとは

ワイヤーフレームとは、画面に何を、どの順番で、どのように配置するかを示す設計図です。実際の配色や書体を決める前段階で使われ、要素どうしの位置関係と優先順位を確認するための道具です。線と枠と文字だけで構成されることが多く、見た目の装飾には踏み込みません。

ワイヤーフレームを作る目的は、関係者どうしで「何を、どこに、どの順番で置くか」という認識をそろえることにあります。装飾を含めた最終的な見た目を決める作業とは、目的が異なります。

この目的の違いを取り違えると、レビューの場で本来話し合うべき論点がずれてしまいます。ワイヤーフレームの段階で「もっと目を引く見た目にしてほしい」という要望が出た場合、それは装飾の段階で扱うべき論点であり、要素の配置や優先順位を確認するワイヤーフレームの段階では、いったん保留にする判断も必要です。両者を混同したまま議論を進めると、骨格についての合意が取れないまま、見た目の話にだけ時間が費やされてしまいます。

注釈で意図を補う

ワイヤーフレームは、線と枠だけでは伝えきれない情報を持っています。なぜその配置にしたのか、なぜこの要素を優先したのかという理由は、図そのものからは読み取れません。この理由を補うために使われるのが、注釈（アノテーション）です。

注釈は、ワイヤーフレームの各要素に番号を振り、番号ごとに補足の説明を添える形で書きます。例えば「1：この一覧は、利用者が直近に確認した項目を新しい順に表示する。表示する件数は、画面の高さに応じて調整してよい」のように、要素の役割や、実装者に委ねてよい範囲までを書き添えます。

注釈がないワイヤーフレームは、図を見た人がそれぞれ異なる解釈をしてしまう余地を残します。図だけで完結させようとせず、意図を文章で補う習慣を持つことが、実装者との認識のずれを防ぐうえで役立ちます。

忠実度の段階

ワイヤーフレームには、粗さの度合い、つまり忠実度に複数の段階があります。忠実度が低いものほど手早く作れますが、伝えられる情報は少なくなります。忠実度が高いものほど詳しく伝えられますが、作るための時間がかかります。

粗い段階：要素の大まかな配置と優先順位だけを示す。四角形と簡単な文字だけで構成されることが多い
詳細な段階：実際の項目名や文言、要素どうしの間隔、状態の変化まで書き込む。実装者がそのまま作業に移れる情報量を持つ

忠実度をどの段階まで作り込むかは、レビューに参加する関係者の人数や立場によっても左右されます。設計の初期段階では、あえて粗い段階にとどめることが有効です。細部まで詰めすぎたものを最初に見せると、関係者は細部の指摘に意識が向いてしまい、そもそもの構成や優先順位についての本質的な議論が後回しになります。まず粗い段階で全体の骨格について合意を取り、そのあとで詳細な段階に進むという順序が、手戻りを防ぎます。

💡 ポイント 忠実度を上げるタイミングは、「関係者どうしで骨格に対する疑問が出なくなったとき」を目安にします。骨格への疑問が残ったまま細部を詰めても、あとで骨格ごと作り直すことになりかねません。

画面を見せずに意図を伝える書き方

本コースはテキストと Mermaid の図解のみで構成されているため、ここでは特に、画面そのものを見せなくても設計意図が伝わる書き方を扱います。これは、画像を使わないという本コースの制約に限った話ではありません。実務でも、離れた場所にいる実装者に文章だけで仕様を伝える場面や、音声だけで打ち合わせをする場面は珍しくなく、汎用的に役立つ技術です。

意図を過不足なく伝えるためには、次の 4 つの観点を押さえます。

観点 1：目的

その画面が、利用者にとってどのような目的を達成する場面なのかを、最初に明記します。「この画面は、利用者が入力した内容を確認し、送信を確定する画面である」のように、一文で言い切れる形にします。目的が曖昧なまま要素の説明に入ると、実装者は個々の要素の意味を推測しながら作業することになります。

観点 2：要素の優先順位

画面に含まれる要素を、優先順位の順に並べて説明します。「1 位：送信内容の確認一覧、2 位：送信を確定するボタン、3 位：内容を修正するための戻るボタン」のように、番号を振って示すと、画面上でどの要素を目立たせるべきかが、実装者にも明確に伝わります。優先順位を示さずに要素を羅列するだけでは、実装者はすべての要素を均等に扱ってしまい、結果として何が重要な画面なのかがわかりにくくなります。

観点 3：状態の変化

画面は、常に 1 つの見た目だけを持つわけではありません。利用者の操作や、システムの処理の進み具合によって、見た目や振る舞いが変化します。代表的な状態には、次のようなものがあります。

初期状態（画面を開いた直後）
入力中の状態（利用者が操作している最中）
処理中の状態（システムが処理をしている最中）
完了状態（処理が正常に終わった状態）
エラー状態（処理が正常に終わらなかった状態）

stateDiagram-v2
    [*] --> 初期状態
    初期状態 --> 入力中
    入力中 --> 処理中 : 送信ボタンを押す
    処理中 --> 完了状態 : 処理が成功する
    処理中 --> エラー状態 : 処理が失敗する
    エラー状態 --> 入力中 : 内容を修正する
    完了状態 --> [*]

この図は、入力を伴う画面が取り得る 5 つの状態と、状態が移り変わる条件を示しています。仕様を書く際は、それぞれの状態で画面がどう見え、利用者に何を伝えるかを、状態ごとに整理して説明します。状態の変化を書き漏らすと、実装者は「処理中はどう見せればよいのか」「エラーのときは何を表示すればよいのか」を、実装の段階で初めて考えることになり、手戻りの原因になります。

観点 4：例外時の挙動

想定どおりに進まない場合の挙動も、あらかじめ言葉にしておきます。「入力すべき項目が 1 つも入力されていない場合はどうなるか」「通信が途中で切断された場合はどうなるか」「一覧に表示すべき情報が 1 件もない場合はどうなるか」といった、例外的な状況を洗い出し、それぞれの対応を明記します。

⚠️ 注意 例外時の挙動は、後回しにされがちな観点です。しかし、実装者が例外時の仕様を確認できないまま作業を進めると、独自の判断で処理を決めてしまい、結果として利用者にとってわかりにくい振る舞いが生まれることがあります。想定外の状況こそ、あらかじめ言葉で決めておく価値があります。

具体例で確認する——4 つの観点を使った仕様の書き方

4つの観点を、実際の文章として組み立てるとどうなるかを、具体的な例で確認しましょう。ここでは、パスワードを再設定する画面を例に、文章だけで意図を伝える書き方を示します。

目的：この画面は、利用者がパスワードを忘れた際に、本人確認を経て新しいパスワードを設定するための画面である。

要素の優先順位：1 位は、新しいパスワードを入力する欄である。2 位は、確認のため同じパスワードを再度入力する欄である。3 位は、設定を確定するボタンである。4 位は、条件を満たさない入力があった場合に表示する注意書きである。4 位の注意書きは、常に表示するのではなく、条件を満たさない入力があったときにのみ表示する。

状態の変化：初期状態では、2 つの入力欄は空欄で、確定ボタンは押せない状態にしておく。両方の入力欄に条件を満たす文字列が入力され、かつ 2 つの内容が一致した時点で、確定ボタンを押せる状態に切り替える。確定ボタンが押されたあとは、処理中であることが伝わる表示に切り替える。処理が正常に終わった場合は完了の状態を、正常に終わらなかった場合はエラーの状態を表示する。

例外時の挙動：2 つの入力欄の内容が一致しない場合は、確定ボタンを押せない状態のまま、一致していないことを伝える注意書きを表示する。パスワードの条件（文字数や使用できる文字種など）を満たさない入力があった場合も、同様に確定ボタンを押せない状態のまま、条件を満たしていないことを伝える。通信が途中で切断されるなど、処理そのものが行えなかった場合は、入力した内容を保ったまま、もう一度試すよう促す表示に切り替える。

このように、目的・優先順位・状態・例外の 4 つを順番に文章にするだけで、画面を見せなくても、実装者がその画面のふるまいを一通り把握できる情報がそろいます。ここで示した例のように、条件によって表示や操作の可否が変わる部分は特に丁寧に言葉にしておくと、実装段階での疑問や、独自判断による仕様のずれを減らせます。

📖 もっと詳しく このような文章による仕様は、粗い段階のワイヤーフレームと組み合わせて使うと、さらに効果を発揮します。おおまかな配置は図で示し、状態の変化や例外時の挙動といった、図だけでは表現しにくい情報は文章で補うという役割分担が、実務では現実的です。

実装者と揉めない仕様の粒度

仕様を書く際、どこまで細かく書くべきかという粒度の判断に悩む方は多いはずです。細かすぎる仕様は、実装者の裁量を奪い、かえって非効率になることがあります。粗すぎる仕様は、実装者が独自に判断せざるを得ない部分が多くなり、意図とは異なる結果を招きます。

粒度を判断する目安は、「利用者にとっての意味が変わる部分」と「利用者にとっての意味が変わらない部分」を区別することです。前者は明確に仕様として書き、後者は実装者の裁量に委ねます。例えば、ボタンを押してから結果が表示されるまでの間、利用者に「処理中である」と伝わることは、利用者にとっての意味が変わる部分なので仕様に含めます。一方、その表現を具体的にどのような言葉で示すかという細部は、実装者の裁量に委ねてもよい場合があります。

🔰 初学者の方へ 迷ったときは、「この判断を実装者に委ねたら、利用者にとって困る結果になり得るか」を自問してみましょう。困る結果になり得るなら仕様に書き、そうでなければ委ねる、という判断軸が実務で役立ちます。慣れないうちは、細かめに書きすぎてしまっても構いません。振り返りの中で少しずつ、委ねてよい範囲の感覚をつかんでいきましょう。

仕様の粒度は、実装者の経験や、チームでの過去のやり取りによっても適切な水準が変わります。初めて一緒に仕事をする実装者とは、最初は細かめに仕様を書き、認識のずれが少ないとわかってきたら、徐々に粒度を粗くしていくという進め方も現実的です。

粒度の判断に迷ったときに役立つもう 1 つの目安が、「同じ状況が、ほかの画面でも繰り返し起きるかどうか」です。一度きりしか起きない特殊な状況であれば、実装者と直接相談しながらその場で決めても大きな支障はありません。一方、複数の画面で繰り返し起きる状況であれば、そのつど個別に判断するのではなく、共通の考え方として仕様書にまとめておくほうが、後々の手戻りを防げます。例えば、一覧に表示する情報が 1 件もない場合の扱いは、多くの画面で共通して起こり得る状況です。画面ごとに毎回相談するのではなく、「一覧が 0 件のときは、次に取るべき行動を案内する文言を表示する」という共通の方針として、あらかじめ言葉にしておくと効率的です。

レビューで論点をずらさない進行

仕様やワイヤーフレームを関係者に見せる場を、レビューと呼びます。レビューの場では、しばしば議論が本来の論点から外れてしまうことがあります。「この文言をもう少し丁寧にしたい」といった細部の指摘から始まり、いつの間にか「そもそもこの画面は必要なのか」という、もっと大きな論点の議論に発展してしまう、といった具合です。

論点をずらさずに進行するための工夫として、次のような進め方が有効です。

レビューの目的を最初に共有する：「今日は骨格に対する疑問を洗い出す場です。文言の細部は後日別途確認します」のように、扱う範囲を最初に宣言する
論点の種類を分けて記録する：骨格に関する指摘、細部の表現に関する指摘、将来の検討事項に関する指摘を、別々の欄に書き分ける
その場で決めない判断を許容する：すべての指摘をその場で解決しようとせず、持ち帰って検討する事項として残すことも認める

📝 補足 レビューの参加者が多いほど、議論は発散しやすくなります。骨格についての合意を取る場と、細部を詰める場を、あえて別の会議として分けることも、論点をずらさないための有効な工夫です。

進行の実例を見てみましょう。あるレビューで、参加者から「この確定ボタンの位置を、もっと目立たせたほうがよいのではないか」という発言が出たとします。この発言自体は、要素の優先順位という骨格に関わる指摘です。しかし、そこに別の参加者が「ボタンの色も、もっと目立つ色にすべきだ」と続けると、話題は装飾の議論に移り始めます。ここで進行役が「色の議論は、装飾を検討する段階で改めて扱いましょう。いまは配置と優先順位についてのご意見をお願いします」と一言添えるだけで、議論は本来の論点に戻ります。

進行役がこうした軌道修正を担うためには、あらかじめ「今日の論点は何か」を自分自身が明確に把握しておく必要があります。レビューの冒頭で目的を共有する一手間は、進行役自身が論点を見失わないための備えでもあります。

まとめ

このレッスンでは、以下のことを学びました。

ワイヤーフレームには忠実度の段階があり、初期段階では粗い段階にとどめることで手戻りを防げる
画面を見せずに意図を伝えるには、目的・要素の優先順位・状態の変化・例外時の挙動の 4 つの観点を押さえる
仕様の粒度は、「利用者にとっての意味が変わる部分」を仕様に書き、変わらない部分は実装者の裁量に委ねる判断が目安になる
レビューでは、扱う範囲を最初に宣言し、論点の種類を分けて記録することで、議論の発散を防げる

次のレッスンでは、設計の前提として位置づけられる「アクセシビリティ」を扱います。WCAG の 4 原則と、日本の規格、そして法制度における合理的配慮の位置づけまで、厚く掘り下げていきます。ここまで学んできた「言葉で意図を伝える」という姿勢は、次のレッスンでも形を変えて登場します。

確認クイズ

このレッスンの理解度をチェックしましょう。