オリエンテーション／実装の進め方・推奨ツール
概要
- 日程: Day 4 / セッション1
- 時間: [9:00-9:20]
- 形式: 座学
- ゴール: apiary・Monaca・GitHubそれぞれの役割を一言で説明できる
- 学習形式: デモンストレーション
導入（5分）
🗣️ 要約
いよいよ最終日、実装の日です。ところで、この3日間で作ってきたものを思い出してみてください。
- Day1: 情報定義書、整理分類済み情報定義書、ペルソナ
- Day2: 情報モデル一覧、状態遷移図、機能一覧、プレゼンテーション一覧
- Day3: 設計思想の選択（MVCで分解する、RESTで通信する、など）
これらはすべて「紙の上（あるいは画面の上）の設計」でした。今日はこれを、実際に動くソフトウェアに変えていきます。
「情報の設計」と「システムの設計」を分離して進める、というDay2から続くテーマを、今日は自分の手で体感することになります。このセッションが終わる頃には、今日1日をどう進めるか、どんな道具を使うかがイメージできているはずです。
前回（Day3まとめ）は、開発テーマに合う設計思想を1つ選びましたね。今日はその選択を、実際のコードとして形にしていきます。
本編（20分）
🗣️ 要約
1. 実装の進め方 ―― 成果物を橋渡しする
🗣️ 要約
実装とは、ゼロから何かを生み出す作業ではありません。むしろ、これまでの3日間で作った成果物を「橋渡し」する作業だと考えてください。
- 情報モデル・状態遷移図 → データの持ち方・API設計
- 機能一覧 → APIのエンドポイントやロジック
- プレゼンテーション一覧・モックアップ → 画面（UI）
- 設計思想の選択（Day3） → 実装の構造（MVCで分けるか、REST APIにするか等）
たとえるなら、これまでの3日間は「設計図を描く」工程で、今日は「その設計図をもとに家を建てる」工程です。設計図がしっかりしているほど、家は建てやすくなります。逆に、設計図なしにいきなり柱を立て始めると、あとで「あれ、部屋の形がおかしい」となりがちです。
ここで少し考えてみてください。もし今日、設計図（情報モデルや機能一覧）を見返さずに実装を始めたら、どんなことが起きそうでしょうか。チームで一言ずつ挙げてみましょう。
2. 推奨ツール ―― apiary・Monaca・GitHub
🗣️ 要約
今日使う3つの道具を紹介します。
- apiary：APIモック作成ツールです。実際のサーバーを構築しなくても、「こういうAPIがある」という取り決め（仕様）を先に定義し、それに対してリクエストを送ると決まったレスポンスが返ってくる、という疑似的なAPIを作れます
- Monaca：Universalアプリケーション開発環境です。1つのコードでWebアプリ・スマートフォンアプリの両方を作れます
- GitHub：ソースコード管理サービスです。チームで同じコードを編集し、変更履歴を残せます
apiaryは「見た目より先に約束事（インタフェース）を決める」という考え方の道具です。これは、Day2で機能一覧とプレゼンテーション一覧を別々に抽出したこと、Day3でプレゼンテーションと機能を分離する話をしたことと、そのままつながっています。
apiaryは実際のロジックを書かなくても「動くふりをするAPI」を用意できます。似ているようで違うものに、ただの静的なHTMLモックアップがありますが、あちらは「クリックしても裏側にデータのやり取りが発生しない」点が異なります。apiaryは該当しますが、静的なモックアップ画面は該当しません。なぜなら、apiaryは実際にHTTPリクエスト・レスポンスのやり取りを体験できるからです。
ここがポイント
特に注意してほしいのは、今日使うツールは「本番で必ず使わなければいけないもの」ではないという点です。apiary・Monaca・GitHubはあくまで、このチームサイズ・この研修期間で「情報の設計とシステムの設計の分離」「プレゼンテーションと機能の分離」を体験しやすくするための例です。実務では、チームやプロジェクトに応じて別のツール（Postman、Firebase、React Native等）を使うこともあります。道具そのものより、「なぜその道具を選ぶと分離がしやすくなるのか」という考え方を持ち帰ってください。
コラム
apiaryのような「APIモック」という考え方は、実は建築の世界の「モックアップ（模型）」から来ています。建築家は本物の建物を建てる前に、縮尺模型や設計図だけで施主にプレゼンし、「ここの窓はもう少し大きく」といった調整を、コンクリートを流し込む前に済ませます。ソフトウェア開発も同じで、本物のサーバーやデータベースを用意する前に、モックで「このAPIは使いやすいか」を確認できると、あとからの手戻りがぐっと減ります。実際、大規模なWebサービスの多くは、フロントエンドチームとバックエンドチームが同時に開発を進めるために、こうしたAPIモックを日常的に使っています。今日みなさんが体験するのは、現場でも実際に行われている進め方そのものなのです。
3. 実装例1〜4の概要
🗣️ 要約
今日から明日にかけて（本研修ではDay4の1日で）、次のような実装例を参考にできます。
- 実装例1：apiaryでRESTful APIを作成し、JavaScriptから呼び出す（→次のセッションで体験します）
- 実装例2：MonacaのTwitterサンプルを、apiary APIモックにアクセスするよう改修する
- 実装例3：Angular.js／React.js等で、apiary APIモックにアクセスするプログラムを作成する
- 実装例4：Monacaサンプルを開発テーマに沿うよう改修する
どれか1つに正解を絞る必要はありません。チームの得意分野や開発テーマに応じて、参考にする実装例を選んでください。迷ったら、AIに「私たちの開発テーマ（〇〇）には、実装例のどれが近いか」と相談してみましょう。
💬 AIに聞いてみよう
🗣️ 要約
ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：
- 「apiaryとMonacaの役割の違いをもう一度整理して」
- 「私たちの開発テーマだと、実装例のどれから始めるのがよさそう？」
- 「実務ではAPIモックをどんな場面で使うの？」
まとめ（5分）
🗣️ 要約
今回学んだことを一言でまとめると、「今日はこれまでの3日間の成果物を、実際に動くソフトウェアへ橋渡しする日」です。
次回（次のセッション）は、実際にapiaryでAPIモックを作り、JavaScriptから呼び出してみます。研修全体で最初に「動いた！」を実感できる時間になるので、今日紹介したapiaryの位置づけをしっかり頭に入れておきましょう。
🔄 振り返りチェック
🗣️ 要約
以下の問いに答えられるか確認してみましょう：
- apiary・Monaca・GitHubそれぞれの役割を一言で説明できますか？
- 今日の実装が、Day1〜Day3の成果物とどうつながっているか説明できますか？
答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。
補足資料
🗣️ 要約
- 参考リンク: apiary公式サイト、Monaca公式サイト、GitHub公式サイト（各チームで検索し、実際のダッシュボード画面を眺めておくとよい）
- 発展課題: 自分たちの開発テーマにapiary以外のAPIモックツール（Postman Mock Server等）を使うとしたら、何が同じで何が違うか調べてみる
学習ガイド
🗣️ 要約
このセクションは、受講者が理解を深めることをサポートする参考情報です。
想定される質問と回答例
🗣️ 要約
| 質問 | ヒント |
|---|---|
| apiaryとMonacaは何が違うの？ | apiaryは「APIの取り決めを模擬的に用意する道具」、Monacaは「画面を含むアプリそのものを作る道具」。役割のレイヤーが異なる |
| GitHubは今日から使わないといけない？ | チーム開発でコードを共有・履歴管理するために推奨するが、必須ツールを限定するものではない。チームで使いやすい方法でよい |
| 実装例のどれを選べばいいか分からない | 開発テーマの主な操作が「一覧・詳細・登録・更新・削除」中心ならAPI＋シンプルなUI（実装例1・3）から、モバイルアプリらしい体験を重視するならMonaca系（実装例2・4）から検討するとよい |
つまずきやすいポイント
🗣️ 要約
| つまずきポイント | ヒント |
|---|---|
| ツールの説明を聞いただけで「分かった気」になり、実際に触る前に不安になる | 次のセッションで実際に手を動かすので、まずは「役割の名前と位置づけ」だけ覚えておけば十分 |
| 「本番でも必ずこのツールを使うべきか」と誤解する | 今日のツールは体験のための例であることを再確認する。考え方（分離の原則）を持ち帰ることが目的 |