ワイヤーフレームとモックアップ作成

• 日程: Day 2 / セッション8
• 時間: [15:00-16:00]
• 形式: 実習
• ゴール: 午前に作成したプレゼンテーション一覧をもとに（条件）、主要画面のワイヤーフレームを2枚以上作成し（行動・基準）、モックアップツールまたは手書き＋HTMLで試作品を作成できる（行動）
• 学習形式: ハンズオン実習（AIサポートあり）

Day2の最終セッションです。今日ここまでで、情報モデル→状態遷移→機能一覧→プレゼンテーション一覧、と積み上げてきました。

でも、プレゼンテーション一覧はまだ「画面の名前のリスト」にすぎません。「支出一覧画面」と聞いて、あなたとAIと未来の実装者が、同じ画面を思い浮かべられるでしょうか？ おそらく無理です。ここに絵が要る理由があります。

このセッションでは、画面の設計図＝ワイヤーフレームを描きます。前セッションで学んだ「UIはペルソナが決める」を、手を動かして実践する時間です。描いた絵は、Day4の実装でそのまま画面の下敷きになります。

ワイヤーフレームとは、画面の構成要素を線（wire）と枠（frame）だけで描いたスケッチです。

たとえ話をすると、ワイヤーフレームは家の「間取り図」です。どこに玄関があり、どこがキッチンか。壁紙の色や家具のデザインはまだ決めません。決めるのは「何がどこにあるか」だけです。

似た言葉と対比して整理します。

• ワイヤーフレーム: 線と枠のスケッチ。「何をどこに置くか」を決める。白黒・手書きで十分
• モックアップ: 見た目を作り込んだ静的な試作品。色・文字・レイアウトが本物に近い
• プロトタイプ: 操作もできる動く試作品

家計簿の画面に色鉛筆で配色を塗り込むのはワイヤーフレームではありません。逆に、ノートに枠と「ここに支出リスト」と書いた走り書きは、立派なワイヤーフレームです。なぜなら、この段階の目的は「配置の合意」であって「見た目の完成」ではないからです。

そして最重要の原則です。ワイヤーフレームに置く要素は、情報モデルの属性から導くこと。 「支出記録」に日付・カテゴリ・金額という属性があるから、一覧画面に日付・カテゴリ・金額の列を置く。この対応関係（トレーサビリティ）が切れると、「なんとなく置いたボタン」だらけの画面になります。思いつきで要素を足したくなったら、「この要素はどの情報モデルの何の属性か？」と自問してください。答えられなければ、情報モデルの見直しに戻るサインです。

情報モデル→画面要素のトレーサビリティの例:

情報モデル「支出記録」
  属性: 日付, カテゴリ, 金額, メモ
    ↓
支出一覧画面の要素
  支出リストの列 = 日付・カテゴリ・金額（メモは詳細画面に回す）
  合計表示 = 金額の集計（ペルソナ「節約したい新社会人」の最重要情報）

• ワイヤーフレームは「何をどこに置くか」だけ。色やデザインは描かない
• 全ての画面要素は情報モデルの属性まで遡れること（トレーサビリティ）

「ナプキンの裏のスケッチ」から生まれたサービスは実在します。サウスウエスト航空の路線戦略はバーのナプキンに描いた三角形から始まったと言われ、Twitterの原型もジャック・ドーシーの手書きスケッチ「stat.us」が残っています。共通点は、最初の絵がどれも驚くほど雑なこと。ペーパープロトタイピングの研究でも、雑な絵の方が「デザインではなく中身」への率直な意見を引き出せることが知られています。きれいに描くほど、人は遠慮して指摘しなくなるのです。堂々と雑に描きましょう。

ツールは次の4択から選びます。迷ったら、今日は「手書き＋簡単なHTML」で十分です。

• draw.io: 午前の状態遷移図で使った人はそのまま使える。図形配置が速い。無料
• Figma: 本格的なUIデザインツール。共有・コメントが強力。今後も使うなら投資価値あり
• Excalidraw: 手描き風の作図ツール。ブラウザで即開始でき、「雑に描く」に最適
• 手書き＋簡単なHTML: 紙に描いてから、AIと一緒に最小限のHTMLモックにする。実装の感覚もつかめる

使い分けの目安は「学習コストと今日の残り時間」です。新しいツールの習得に20分使うくらいなら、紙とHTMLで2枚描き切る方が価値があります。

家計簿システムを例に、プレゼンテーション一覧からワイヤーフレームへの落とし方を示します。午前の抽出結果がこうだったとします。

プレゼンテーション一覧（情報モデル「支出記録」由来）
  1. 支出入力画面（Create）
  2. 支出一覧画面（Read: 一覧表示）
  3. 支出詳細画面（Read: 1件表示）
  4. 支出編集画面（Update）
  5. 削除確認ダイアログ（Delete）

このうち主要な2枚の構成要素を、テキストで書き出すとこうなります。描く前にこの「要素リスト」を書くのがコツです。

【支出一覧画面】
  - ヘッダ（アプリ名、設定アイコン）
  - 月選択（← 2026年7月 →）
  - 合計表示（今月の支出合計 ※ペルソナの最重要情報なので上部に）
  - 支出リスト（1行 = 日付・カテゴリ・金額。タップで詳細画面へ）
  - 追加ボタン（→ 支出入力画面へ）

【支出入力画面】
  - ヘッダ（タイトル「支出を記録」、戻るリンク）
  - 日付入力（既定値: 今日）
  - カテゴリ選択（食費／交通費／娯楽…）
  - 金額入力（数字のみ）
  - メモ入力（任意）
  - 保存ボタン／キャンセル

支出一覧画面の最小HTMLモック例です。見た目の作り込みはせず、配置だけを確認します。

<header>
  <h1>家計簿</h1>
</header>
<main>
  <nav>&larr; 2026年7月 &rarr;</nav>
  <p>今月の支出合計: <strong>45,300円</strong></p>
  <table border="1">
    <tr><th>日付</th><th>カテゴリ</th><th>金額</th></tr>
    <tr><td>7/6</td><td>食費</td><td>480円</td></tr>
    <tr><td>7/3</td><td>交通費</td><td>340円</td></tr>
  </table>
  <button>＋ 支出を追加</button>
</main>

このファイルを mock.html として保存し、ブラウザで開けばモックアップの完成です。CSSは今日は不要です。

• ツール選びに時間をかけない。「今日中に2枚」が最優先
• 描く前に「要素リスト」をテキストで書く。要素の根拠は情報モデルの属性
• 合計表示のような「集計値」も立派な画面要素。ペルソナにとって重要なら目立つ位置へ

ペーパープロトタイピングの効用は数字でも示されています。ユーザビリティ研究の草分けヤコブ・ニールセンは「5人にテストすれば問題の約85%が見つかる」と述べました。紙のプロトタイプでも、操作の詰まりどころは十分にあぶり出せます。修正コストは、紙なら数十秒、実装後なら数時間〜数日。「安い段階で失敗する」ための道具がワイヤーフレームです。PDCAを小さく沢山、はここでも合言葉です。

• 「家計簿の支出一覧画面のワイヤーフレームに置くべきUI要素を、情報モデル『支出記録』の属性（日付・カテゴリ・金額・メモ）から提案してください」
• 「このワイヤーフレームの要素リストをもとに、CSSなしの簡単なHTMLモックを作ってください: （自分の要素リストを貼る）」
• 「あなたは私のペルソナ『（自分のペルソナ）』です。このワイヤーフレームを見て、目的を達成できるか、足りない要素はないかレビューしてください」

1. 画面を2つ選ぶ（5分）: 自分のプレゼンテーション一覧から、ペルソナが最も頻繁に使う画面を2つ選ぶ。迷ったら「一覧画面」と「入力画面」
2. 要素リストを書く（10分）: 各画面について、置く要素をテキストで列挙する。各要素の横に「由来する情報モデルの属性」をメモする。AIに抜け漏れを確認してもらう
3. ワイヤーフレームを描く（10分）: 4択のツール（draw.io / Figma / Excalidraw / 手書き）のいずれかで2枚描く。白黒・枠と線だけでよい
4. モックアップにする（10分）: 手書きの人はAIと一緒に簡単なHTMLモックを作る。ツール派はその画面をモックとして仕上げ、ペルソナ視点でAIレビューを受ける
5. 振り返り（最後の10分）: AIに「今日学んだこと」を自分の言葉で説明する（下記参照）

• ワイヤーフレーム（モックアップ）2枚以上（画像・PDF・HTMLファイルのいずれか）
• 各画面の要素リスト（要素→情報モデルの属性の対応メモ付き）

• 時間が足りないと感じたら、きれいさを捨てて枚数を守る。雑な2枚は、美しい1枚に勝る
• 要素の置き場所に迷ったら「ペルソナが最初に知りたい情報は何か」と自問する。それを一番上に置く
• AIにHTMLモックを頼むときは、要素リストをそのまま貼り付けると精度が上がる
• 「この画面、情報モデルにない要素を置いていないか？」を最後に必ずチェックする。あれば情報モデル側の見直し候補としてメモする（明日以降の宝になる）

AIに向かって、今日1日（情報モデル〜ワイヤーフレーム）で学んだことを自分の言葉で説明してください。「話す＆行う」が記憶定着の最強の方法です。

• 例:「今日、情報モデルと状態遷移から機能と画面を抽出する方法を学びました。私の理解では〜。この理解に誤りや抜けがあれば指摘してください」
• AIの指摘で曖昧だった箇所が見つかったら、該当セッションの教材をメモしておき、明日の朝に読み返す

今回学んだことを一言でまとめると「画面は思いつきで描くものではなく、情報モデルから導くもの」です。

• ワイヤーフレームは線と枠の設計図。目的は配置の合意であり、見た目の完成ではない
• 全ての画面要素は情報モデルの属性まで遡れる（トレーサビリティ）
• 雑に速く描いて、安い段階で失敗をあぶり出す

これでDay2の成果物が揃いました。情報モデル一覧、状態遷移図、機能一覧、プレゼンテーション一覧、非機能要件一覧書、そしてワイヤーフレーム。明日のDay3では、これらを「どんな設計思想で実装に落とすか」を学び、RESTful APIの設計まで進みます。今日描いた画面とAPIが、Day4でつながって動き出します。

• ワイヤーフレームとモックアップの違いを一文で言えますか？
• 自分のワイヤーフレームの各要素について、「どの情報モデルのどの属性か」を答えられますか？
• ツール4択（draw.io / Figma / Excalidraw / 手書き＋HTML）の使い分けの目安を言えますか？

• 参考リンク: Excalidraw（excalidraw.com、登録不要で即利用可）、draw.io（app.diagrams.net）、Figma（figma.com）
• 発展課題: 描いたワイヤーフレームを、スマホ幅（縦長）とPC幅（横長）の2パターンで描き分けてみる。マルチプラットフォーム設計の入り口になる