（演習）開発テーマに沿った実装②

• 日程: Day 4 / セッション6
• 時間: [13:20-14:50]
• 形式: 演習
• ゴール: プレゼンテーション（UI）と機能（ロジック）を分離した形で、開発テーマのUI部分を実装し、API部分と接続できる
• 学習形式: AIペアプログラミング

🗣️ 要約

• 午前はAPI（機能）を実装し、データをやり取りする窓口ができている
• APIを呼び出す側（UI）まで書き直しが必要だと不便であり、これが「プレゼンテーションと機能の分離」というテーマ
• このセッションでは画面（UI）とロジックが独立して動くプロトタイプを作る

午前は「情報の設計とシステムの設計を分離する」ことをテーマに、APIの部分を実装しました。ここまでで、開発テーマのデータをやり取りする窓口ができています。

では、そのAPIを呼び出す側はどうなっているでしょうか？ここで少し考えてみてください。もしボタンの色を変えたいとき、API側のコードまで書き直す必要があるとしたら、どう感じますか？

きっと「それは面倒だ」と感じるはずです。実はそれこそが、今日の後半で扱う「プレゼンテーションと機能の分離」というテーマです。このセッションが終わる頃には、画面（UI）とデータのやり取り（ロジック）が独立して動く、動くプロトタイプが手元にできています。

不正解項目の復習で確認した内容を思い出しながら、実際に手を動かして定着させていきましょう。

🗣️ 要約

• UIとロジックは「注文伝票（API）」のような決まった取り決めでやり取りし、互いに独立して変更できる
• 実装例2〜4はいずれも「既存のUIの土台」に「自分たちのAPI」を接続する構造

🗣️ 要約

• UI（ホール係）は注文を取り運ぶだけで調理せず、ロジック（厨房）は調理に専念する
• UI側はAPIの取り決め（インタフェース）だけを知り、内部の処理方法は知らない
• UIのイベント処理の中にDB直接アクセスや業務ロジックの計算式が書かれていると分離できていない

分離するというのは、いわば「レストランの厨房とホール」のようなものです。ホール係（UI）は注文を取り、料理を運びますが、自分で調理はしません。厨房（ロジック・API）は調理に専念し、お客さんの前には出ていきません。この2つが「注文伝票」という決まったフォーマットでやり取りしているからこそ、ホールの接客スタイルを変えても、厨房の調理方法を変えても、お互いに影響しません。

• 該当する例：UI側は「このURLにこの形式のデータを送れば、こういう形式で結果が返ってくる」というAPIの取り決め（インタフェース）だけを知っていて、内部の処理方法は知らない
• 該当しない例：UI側のボタンを押した処理の中に、データベースへの直接アクセスやビジネスロジックの計算式が直接書かれている状態。これは分離できていません。なぜなら、画面のレイアウトを変えるだけのはずが、ロジックにまで手を入れる必要が出てしまうからです

ここまでで、UIとロジックを分ける意味についてイメージできましたか？分からない場合は、AIに「レストラン以外のたとえ話で説明して」と聞いてみるのもよい方法です。

🗣️ 要約

• 実装例2はMonacaのTwitterサンプルを自分たちのAPIに接続する改修
• 実装例3はAngular.js/React.js等でapiary APIモックにアクセスするプログラムの新規作成
• 実装例4はMonacaサンプルを開発テーマに沿って改修するもので、動くサンプルを土台にする方が現実的

実装例2〜4として紹介されているのは、次のようなパターンです。

• 実装例2：MonacaのTwitterサンプルを、自分たちのapiary APIモックにアクセスするよう改修する
• 実装例3：Angular.js/React.js等のフレームワークで、apiary APIモックにアクセスするプログラムを新規作成する
• 実装例4：Monacaのサンプルを開発テーマに沿うよう改修する

どの実装例も共通しているのは、「既存のUIの土台」に「自分たちのAPI」を接続する、という構造です。ゼロからUIを作るよりも、動くサンプルを土台にする方が、今日という限られた時間の中では現実的です。

なぜサンプルを土台にするとよいのでしょうか。少し考えてみてください。実は、UIの見た目や操作性を一から設計する時間を省き、「情報とロジックの分離」という本来学びたいテーマに集中できるからです。

UI側からAPIを呼び出す部分のイメージです（fetchを使ったJavaScriptの例）。

// UI側（プレゼンテーション）はこの窓口だけを知っていればよい
async function fetchItemList() {
  const response = await fetch("https://your-apiary-mock.example.com/items");
  const items = await response.json();
  return items;
}

// 画面表示のロジックは、データの中身がどう作られたかを知らなくてよい
function renderItemList(items) {
  const list = document.getElementById("item-list");
  list.innerHTML = items.map(item => `<li>${item.name}</li>`).join("");
}

fetchItemList の中身（URLや通信方法）が変わっても、renderItemList は一切変更する必要がありません。これが「分離できている」状態です。

特に注意してほしいのは、UIのコードの中に直接データの加工ロジックや業務判断（例：「在庫が0なら売り切れと表示する」といった条件分岐の元になる計算）を書き込んでしまうことです。よくある間違いとして、画面のボタンのイベント処理関数の中に、データベースの都合に合わせた計算式をそのまま書いてしまうケースがありますが、正しくは、そうした判断はAPI側（機能）で済ませ、UI側はその結果を表示するだけにするべきです。

判断基準はシンプルです。UIのコードを別のフレームワーク（例：ReactからVueへ）に丸ごと差し替えたとして、API呼び出し部分のURLやデータ形式の取り決めを変えずに済むかどうかを確認してみてください。

Twitterのサンプルアプリを改修する実装例2は、実は多くの現場でも使われている手法です。ゼロから作るのではなく「動いているものを少しずつ自分たちのものに置き換えていく」というやり方は、リバースエンジニアリング的な学習法とも言えます。有名なソフトウェアエンジニアの中には、新しい技術を学ぶときに必ず「既存の動くコードを1行ずつ書き換えて壊してみる」ことから始める人もいるそうです。壊れたら「なぜ壊れたか」を考えることこそが、一番の近道だったりします。今日UIを改修していて予期せぬエラーに遭遇したら、それは学びのチャンスです。落ち込まずにAIと一緒に原因を探ってみましょう。

🗣️ 要約

• 書いたコードがUIとロジックを分離できているか、実務でのUI/API間の取り決めの作り方などをAIに質問できる

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

• 「UIとロジックが分離できているか、このコードを見て判定して」
• 「MonacaのサンプルをこのAPIに接続する手順を教えて」
• 「実務ではUIとAPIの間にどんな取り決め（仕様書）を作るの？」

🗣️ 要約

• セッション3で作ったAPIに、モックアップをもとにしたUIを接続し、動くプロトタイプを完成させる演習

🗣️ 要約

• 実装例2〜4のいずれかを選び、UIからAPIを呼び出す処理を実装し、取得データを画面に表示し、UI/APIの分離をチームでレビューする

セッション3で作成したAPI（機能）に、モックアップやプレゼンテーション一覧をもとにしたUI（画面）を接続してください。

• (1) 実装例2〜4のいずれか、チームに合った方法を選ぶ
• (2) UIの画面から、セッション3で作ったAPIを呼び出す処理を実装する
• (3) 取得したデータを画面に表示する
• (4) UIのコードとAPI呼び出しのコードが分離されているか、チームでレビューする

🗣️ 要約

• API（機能）とUI（プレゼンテーション）が接続され、画面上でデータが表示・操作できるプロトタイプ

API（機能）とUI（プレゼンテーション）が接続され、実際に画面上でデータが表示・操作できるプロトタイプ

🗣️ 要約

• 接続できないときはAPIの応答を直接確認し、UI側かAPI側かを切り分ける
• エラーが出たらAIに伝えると原因の候補を教えてもらえる
• 時間が足りない場合は1つの機能が最後まで動くことを優先する

• うまく接続できない場合は、まずAPIの応答をブラウザやPostman等で直接確認し、UI側の問題かAPI側の問題かを切り分けてみてください
• エラーが出たら「〜というエラーが出た」とAIに伝えると、原因の候補を教えてもらえます
• 時間が足りない場合は、画面をすべて作り込む必要はありません。1つの機能が最後まで動くことを優先してください

🗣️ 要約

• UIとロジックは「注文伝票」のような決まった取り決め（API）でつながっているからこそ、互いに独立して変更できる
• 次回は今回のプロトタイプを使って成果発表資料を作成する

今回学んだことを一言でまとめると、UIとロジックは「注文伝票」のような決まった取り決め（API）でつながっているからこそ、互いに独立して変更できる、ということです。

次回は、この動くプロトタイプを使って成果発表資料を作成します。今回作ったものがそのままデモの材料になるので、動く状態を保っておきましょう。

🗣️ 要約

• UIとロジックが分離できているかどうかの確認方法
• 自分たちのAPIをUIから呼び出す処理をコードで示せるか

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

• UIとロジックが分離できているかどうかを、どうやって確認すればよいか説明できますか？
• 自分たちのAPIをUIから呼び出す処理を、コードで示せますか？

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

🗣️ 要約

• 参考資料は使用しているUIフレームワークの公式ドキュメント
• 発展課題は「読み込み中」表示やエラーメッセージ表示などのUX改善

• 参考リンク: 使用しているUIフレームワーク（Monaca / Angular.js / React.js等）の公式ドキュメント
• 発展課題: 通信中に「読み込み中」の表示を出す、エラー時にエラーメッセージを表示する、といったUXの改善を加えてみる

🗣️ 要約

• 受講者からよく出る質問への回答例と、つまずきやすいポイントへの対処法をまとめている

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

🗣️ 要約

• APIとUIのデータ形式が違う場合はUI側に変換層（アダプター）を挟むとよい
• CORSエラーはブラウザのセキュリティ制限によるもの

🗣️ 要約

• UIのイベント処理関数の中に業務判断のロジックを直接書いてしまいやすい
• 見た目を完璧に作り込もうとして時間切れになりやすい