Day 4 イントロ・実装方針

• 日程: Day 4 / セッション 01
• 時間: 9:00-9:30
• 形式: 座学
• ゴール: Day 4の実装の進め方を3分で説明でき、apiary/Monaca/GitHubの役割をそれぞれ1文で言い分けられる
• 学習形式: AI協働型（疑問はAIに即座に質問しながら理解を深める）

ここまで3日間、皆さんは「何を作るか」を徹底的に設計してきました。情報定義書・ペルソナ・情報モデル・状態遷移図・機能一覧・プレゼンテーション一覧・モックアップ・API設計メモ。手元に並んでいる成果物は、もはや小規模なプロジェクトの設計書一式そのものです。

今日はついに、その設計図から実物を組み立てる日です。料理に例えるなら、Day 1〜3は「献立とレシピ作り」「食材の下ごしらえ」、Day 4は「火を入れて皿に盛り、お客様に出す」段階です。

ところで、ここでひとつ問いを置きます。「動くアプリ」と聞いて、頭の中に何が浮かびましたか？画面ですか？ボタンですか？データベースですか？実は今日学ぶ「実装方針」の核心は、画面と機能を別々に作るという考え方です。なぜそうするのか、どう進めるのか。30分かけてマップを共有します。

Day 4最大のテーマを1行で書きます。

プレゼンテーション（UI）と機能（API）を分離して実装する

ここでひとつ思い出してみてください。Day 2で皆さんは「機能一覧」と「プレゼンテーション一覧」を別々の表として作りました。あの分離が、今日の実装スタイルにそのまま現れます。

UIとAPIはJSON形式のリクエスト/レスポンスでやり取りします（UI→API：fetch(JSON)、API→UI：JSON応答）。

UI担当は画面とユーザ操作を作ります。API担当は情報モデルとロジックを作ります。両者はJSONというメッセージでだけ会話します。お互いの内部実装は知らなくていい。これがDay 3 Session08で学んだRESTの真髄でもあります。

• UIとAPIを別々に進めると、作業を並行化できる（2人で同じ画面を一緒に編集する必要がない）
• API仕様（リクエスト/レスポンスの形）を先に固めれば、UIはモックデータで開発を始められる
• 後で技術を入れ替えやすい（UIをReactに変えても、APIをPythonで書き直しても、JSONさえ変わらなければ動く）

2000年代前半まで、Webアプリは「サーバが画面ごとHTMLを組み立てて返す」のが主流でした。PHPやJSPのテンプレートに、データもデザインもロジックも全部混ぜて書いていたのです。2005年、GoogleがGmailとGoogle Mapsで「画面はブラウザ、データだけサーバから取る（Ajax）」という方式を大々的に採用してから、世界は一変しました。今では「UIとAPIを分離する」のは当たり前すぎて誰も議論しません。皆さんは20年前なら最先端だったスタイルを当然のように学んでいるわけです。

Day 4は1日で実装します。完璧を目指すと終わりません。次の3ステップで段階的に進めます。

ここで強調しておきたいことがあります。ステップを飛ばさないでください。「いきなりUIを作ってAPIを後付けする」「データベースから設計し直す」のような飛ばし方は、必ず手戻りを生みます。Day 1〜3の成果物に従って、上から順に積み上げます。

完璧な実装は不要です。動くデモが1つあればOK。最終発表で「ユースケース1つがエンドツーエンドで動く」状態を目標にしてください。

アジャイル開発に「Walking Skeleton（歩く骸骨）」という言葉があります。「中身はスカスカでもいいから、最初に端から端まで動くものを作れ」という意味です。家を建てるときに「1部屋を完璧に作り上げてから次の部屋」ではなく、「全部の部屋を雑でいいから一通り建ててから内装を整える」感覚です。今日の進め方はまさにWalking Skeletonです。

実装で使うツールはたくさんありますが、研修では次の3つを推奨します。

Monacaで作ったUIは、fetchでapiaryのモックURLを呼び出します。

• apiaryは「API Blueprint」というMarkdown風の記法でAPIを書くと、自動的に仕様書ページとモックサーバを生成してくれます。UI担当はモックURLを叩けば、本物のAPIがなくても画面開発を進められます。
• Monacaはブラウザ上でHTML/CSS/JavaScriptを書き、即座にプレビューできるオンライン環境です。インストール不要。
• GitHubはチームで作ったソースコードを集約し、変更履歴を残します。Day 3 Session10で学んだ「ブランチ」「コミット」「マージ」をここで実践します。

別のツール（Postman、Swagger、VS Code、Figma、GitLabなど）に慣れているチームは、それを使ってもかまいません。目的さえ達成できれば、ツールは自由です。

ツールに振り回されないこと。ツールは「役割」を果たすための手段です。apiaryでなくPostman、MonacaでなくVS Codeでも、役割が同じなら大丈夫。重要なのは「API設計 → API実装 → UI実装 → 統合」の流れを止めないことです。

2010年代、AmazonのCEOジェフ・ベゾスが社内に「すべての機能はAPIを介してのみ提供せよ。さもなくば解雇する」という強烈な指示を出したという逸話があります（通称「Bezos API Mandate」）。これにより社内システムが全てAPI化され、後にAWSという外部公開サービスへ進化しました。「APIを先に決める」というアプローチは、現代のサービス開発の標準スタイルになっています。今日のapiaryを使う流れは、そのミニチュア版です。

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

• 「UIとAPIを分離するメリットを、もう一段噛み砕いて説明して」
• 「Walking Skeletonの実例を1つ教えて」
• 「apiaryとPostmanとSwaggerの違いは何？」

Day 4は「プレゼンテーションと機能の分離」が全てです。Step1〜4の進め方を守り、apiary・Monaca・GitHubそれぞれの役割を意識して、まずは「動く骸骨」を作ることを目指します。

次のセッションでは、いきなりapiaryでAPIモックを作ります。手を動かしながら、API仕様書がそのままモックサーバになる体験をしましょう。

• なぜUIとAPIを分離して実装するのか、3つの理由を挙げられますか？
• 今日の実装の4ステップを順番に言えますか？
• apiary / Monaca / GitHub の役割をそれぞれ1文で説明できますか？

• 参考リンク: API Blueprint公式（apiblueprint.org）、Monaca公式（monaca.io）、GitHub Docs
• 発展課題: 自分が使っているサービスを1つ選び、そのAPIが公開されているか調べてみる（Twitter API、GitHub API など）