プロトタイピングの目的とツール

• 日程: Day 10 / セッション 1
• 時間: 9:30-9:55
• 形式: 座学
• ゴール: プロトタイプを作る目的（早く・安く認識合わせと検証を行う）を説明し、モックアップツール（Figma、Atomic、Fluid、NinjaMock、紙）、実行環境（Netlify、Google Cloud Platform）、開発ツール（Bubble、Monaca、Unity）から自チームに合うものを選定できる
• 学習形式: 対話型解説、デモンストレーション

Day 9までで、設計書と実装計画がそろいました。
「さあコードを書くぞ！」と言いたいところですが、その前に今日1日だけ寄り道をします。プロトタイプ作りです。

ここで問いかけです。
設計書は完璧に書いたはず。なぜわざわざ「偽物」を作るのでしょうか？

建築の世界を考えてみてください。
何十億円のビルを建てる前に、建築家は必ず模型を作ります。図面が完璧でも、模型にして初めて「ここ、圧迫感があるな」「動線が変だな」と気づくからです。模型なら数万円。建ててから気づいたら数億円です。

ソフトウェアも同じです。
画面遷移図の上では完璧でも、実際に「タップして遷移してみる」と、迷子になる場所が見つかります。
完璧な設計書より、動く紙芝居。 今日はそれを作るための目的とツールを学びます。

プロトタイプとは「検証のために、本物より早く・安く作る試作品」です。
目的は大きく2つです。

• 認識合わせ: 「こういうものを作ります」をチーム・ユーザと目で見て合意する
• 検証: 設計の問題（使いにくさ・遷移の迷子・項目の漏れ）を実装前に発見する

ポイントは「間違いを早く・安く見つける」ことにあります。
不具合の修正コストは、発見が遅れるほど高くなります。プロトタイプ段階なら付箋1枚の貼り替えで済む修正が、実装後ならコードの書き直し、リリース後なら信頼の失墜になります。

逆に、プロトタイプでやらないことも大事です。
「色を美しく整える」「アニメーションを凝る」は該当しません。それは本物の仕事です。「全画面がそろっていて、ボタンを押すと次の画面に移る」は該当します。検証したいのは見た目の美しさではなく、流れだからです。

ここで考えてみてください。みなさんの製品で「実装前に確かめておかないと一番怖いこと」は何でしょうか？ それが今日のプロトタイプで検証すべきことです。

• プロトタイプの合言葉は「早く・安く・捨てられる」。作り込んだら負け
• 検証するのは「画面の流れ」と「項目の過不足」。装飾は対象外
• プロトタイプは捨てる前提の試作品。愛着を持ちすぎない

「Fail fast（早く失敗せよ）」はシリコンバレーの有名な合言葉です。落書きのような紙プロトタイプから生まれた大ヒット製品は珍しくありません。たとえばDropboxは、製品が存在しない段階で「動いているように見えるデモ動画」だけを公開し、利用希望者が殺到するかを検証しました。作る前に「求められているか」を確かめたわけです。一番高くつく失敗は「誰も使わないものを完璧に作り上げること」——プロトタイプはそれを防ぐ保険です。

モックアップとは「画面の見た目の模型」のことです。今日の主役になる道具を紹介します。

「紙なんて原始的では？」と思うかもしれません。でも紙には独自の強みがあります。
描き直しが数秒、誰でも参加でき、「ラフだから遠慮なくダメ出しできる」。
逆にきれいなモックアップは「もう完成してるから言いにくい…」と意見を引っ込めさせることがあります。

選定の目安です。

• 時間が限られ、全員が初心者 → 紙 または NinjaMock
• チームで同時編集して資産を発表でも使いたい → Figma
• スマホアプリの操作感を確かめたい → Fluid / Atomic

• ツール選びに30分かけるのは本末転倒。今日は70分しか作成時間がない。迷ったら紙かFigma
• どのツールでも目的は同じ: 「画面遷移図の通りに遷移する」を再現すること
• きれいさとフィードバックの量は、しばしば反比例する

紙プロトタイプの有名な実践者に、初代Palm Pilot（1990年代の携帯情報端末）の開発者ジェフ・ホーキンスがいます。彼は木片をポケットに入れて持ち歩き、予定を聞かれるたびに木片を取り出して「使うふり」をしました。木とプリント紙だけで「このサイズで、この操作で、生活に馴染むか」を数週間検証したのです。製品は大ヒット。世界を変えるデバイスの最初のプロトタイプが「ただの木」だった、という話は今もデザイン業界の語り草です。

今日はモックアップが主役ですが、明日からの実装で使う環境とツールも、ここで一度見渡しておきます。
プロトタイプのツール選びは、実装手段とセットで考えると無駄がないからです。

実行環境（作った製品をどこで動かすか）

開発ツール（製品をどう作るか）

選び方の軸は2つだけです。

1. 製品の形: Webサービスか、スマホアプリか、ゲームか
2. チームの手持ちスキル: 前提研修で学んだプログラミング・DBの知識が活きる構成か

たとえば「Webでデータを登録・検索する製品」ならNetlify＋手書きコード、またはBubbleが候補です。「スマホで使う前提のペルソナ」ならMonaca。「ゲームで課題を解決する」ならUnity。ペルソナとCJM（To-Be版）が判断基準になります。

• ツールは手段。「使ってみたいから」ではなく「ペルソナに価値を届けられるか」で選ぶ
• 迷ったら、学習コストが低いものを選ぶ。実装期間は実働6日しかない
• 今日決めた選定は仮決定でよい。明日の実装初日に環境構築して、無理そうなら早めに乗り換える（PDCAを小さく沢山）

「ノーコード」という言葉は新しく聞こえますが、思想は1980年代の表計算ソフトにさかのぼります。Excelの前身VisiCalcは「プログラマでなくても計算プログラムが作れる」革命でした。世界で一番使われているプログラミング環境は、実はExcelだと言う人もいます。BubbleやMonacaはその系譜の現代版。「コードを書くこと」と「ものを作ること」は、イコールではないのです。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「プロトタイプとモックアップとMVPの違いは？」
• 「うちの製品は〜という内容。FigmaとBubble、どちらでプロトタイプを作るのが向いてる？」
• 「Netlifyで公開できるものとできないものを教えて」
• 「紙プロトタイプの具体的なやり方を、手順で教えて」

今回学んだことを一言でまとめると、**「プロトタイプは、間違いを早く・安く見つけるための動く紙芝居」**です。

• 目的は認識合わせと検証。作り込みは目的ではない
• モックアップツール: Figma、Atomic、Fluid、NinjaMock、紙（紙芝居）
• 実行環境: Netlify、GCP / 開発ツール: Bubble、Monaca、Unity
• 選定基準はペルソナへの価値とチームのスキル。迷ったら低コストな方へ

次のセッションでは、選んだツールで主要画面のモックアップを実際に作ります。
ツール選定はセッション冒頭の5分で済ませられるよう、頭の中で候補を1つ決めておいてください。

以下の問いに答えられるか確認してみましょう：

• プロトタイプを作る2つの目的を言えますか？
• 「プロトタイプで検証すること」と「検証しないこと」の例を1つずつ挙げられますか？
• モックアップツールを3つ以上、実行環境を2つ、開発ツールを3つ挙げられますか？
• 自チームはどのツールを選びそうですか？ その理由は？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

• 参考リンク: Figma公式チュートリアル（日本語）、Netlify入門記事、Bubble・Monaca・Unityの公式スタートガイド
• 発展課題: 「ペーパープロトタイピング」で検索し、実際の現場の進め方動画を1本見てみましょう。明日からの実装ツールの候補について、AIに「初心者がつまずくポイント」を先に聞いておくのもおすすめです

このセクションは、受講者が理解を深めることをサポートする参考情報です。