Day 4 - 本日のサマリー: 設計図を、動くソフトウェアと発表に変える日
概要
- 日程: Day 4
- 本日のゴール: 情報の設計とシステムの設計、プレゼンテーションと機能を分離した形で、開発テーマを実装し、成果を発表できるようになる
- 対応する到達目標: No.1〜No.6(3日間の総合実践)
- 本日の成果物: 動作するプロトタイプ(API+UI)、成果発表資料、確認テスト結果と復習メモ
🧭 今日の航海図(なぜ・なにを・どこへ)
🗣️ 要約
3日間で作った情報定義書・ペルソナ・情報モデル・設計思想の選択を、今日は動くAPIとUIに変える 午前の途中に確認テストと復習を挟み、Day1〜Day3の理解を自分の言葉で言い直す 情報アーキテクチャという「地図」を描いてから実装という「旅」に出る1日
この3日間で作ってきた情報定義書・ペルソナ・情報モデル・状態遷移図・設計思想の選択は、すべて「紙の上(画面の上)の設計」でした。今日はそれを、実際に動くAPIとUIに変え、最後はチームで発表するところまで進みます。午前の途中には確認テストと復習を挟み、Day1〜Day3の理解を一度自分の言葉で言い直す時間も取ります。今日1日が終わる頃には、情報アーキテクチャという「地図」を描いてから実装という「旅」に出ることの意味を、自分の手で確かめられているはずです。
⏱ 今日の流れ
🗣️ 要約
午前は「動かして確かめる」実装と自分の理解度の棚卸し、午後は「つないで見せる」実装と発表準備 実装①→確認テスト→復習→実装②→発表資料作成→成果発表という順で進む
| 時間 | セッション | 形式 | このセッションで手に入るもの |
|---|---|---|---|
| 9:00-9:20 | オリエンテーション/実装の進め方・推奨ツール | 座学 | apiary・Monaca・GitHubの役割の見取り図 |
| 9:20-9:40 | (演習)apiaryでAPIモックを作って呼び出してみる | 実習 | 研修全体で最初の「動いた!」という体験 |
| 9:40-9:50 | 休憩 | - | - |
| 9:50-11:20 | (演習)開発テーマに沿った実装① | 演習 | 情報モデルから作った、動くAPI(情報の設計とシステムの設計の分離) |
| 11:20-11:50 | 確認テスト実施 | 確認テスト | 自分の理解度の可視化(Day1〜Day3・到達目標No.1〜No.4) |
| 11:50-12:00 | 休憩 | - | - |
| 12:00-13:00 | 昼休憩 | - | - |
| 13:00-13:20 | 不正解項目の復習 | 復習 | 誤答を「自分の言葉で説明できる知識」に変えた復習メモ |
| 13:20-14:50 | (演習)開発テーマに沿った実装② | 演習 | UIとAPIが接続された、動くプロトタイプ(プレゼンテーションと機能の分離) |
| 14:50-15:00 | 休憩 | - | - |
| 15:00-15:20 | 成果発表資料作成のポイント | 座学 | 発表資料に必要な5要素の整理 |
| 15:20-16:00 | (演習)成果発表資料作成 | 演習 | 完成した成果発表資料 |
| 16:00-16:10 | 休憩 | - | - |
| 16:10-17:00 | 成果発表 | 演習 | チームの成果発表とフィードバック |
| 17:00-17:10 | 研修全体のまとめ | 座学 | 4日間の学びを1本につなげた全体像 |
午前は「動かして確かめる」実装と自分の理解度の棚卸し、午後は「つないで見せる」実装と発表準備という、前半・後半で役割が違う1日です。
🎯 今日の成果物
🗣️ 要約
動くAPI(apiaryモック+呼び出しコード)と、それにつながるUI(プロトタイプ) 役割分担実績・構成・デモ・KPT・アピールポイントを含む成果発表資料 確認テストの結果と、誤答項目についての復習メモ
夕方には、次のものが手元に揃っている状態を目指します。
- 開発テーマの情報モデルに対応する、動くAPI(apiaryモック+呼び出しコード)
- そのAPIとつながった、画面から操作できるUI(プロトタイプ)
- 役割分担実績・構成・デモ・KPT・アピールポイントの5要素を含む成果発表資料
- 確認テストの結果と、誤答項目についての復習メモ
たとえば GET /expenses のようなAPIエンドポイントに対して、画面のボタンを押すとデータが表示される——そこまで動けば、今日の目標は達成です。
⚠️ 今日のつまずきポイント
🗣️ 要約
確認テストの点数に一喜一憂しやすいが、目的は弱点を見つける「健康診断」 エンドポイント名やUIのコードに「機能」を混ぜ込んでしまいやすい KPTのProblemを隠して良いことだけ書いてしまいやすい
- 確認テストの点数に一喜一憂してしまう:このテストは順位づけではなく「弱点を見つけるための健康診断」です。思い出そうと頭を捻ったこと自体に記憶定着の効果があるので、間違えても収穫だと捉えて大丈夫です
- エンドポイント名やUIのコードに、つい「機能」を混ぜ込んでしまう:
/getExpensesのような動詞入りのエンドポイント名や、画面のイベント処理の中に業務判断のロジックを直接書いてしまうのは、多くの人がやりがちな詰まりどころです。「情報(名詞)とHTTPメソッド」「表示(UI)と判断(ロジック)」を分けて考える、という原則に何度でも立ち返って大丈夫です - KPTのProblemを隠して良いことだけ書いてしまう:うまくいかなかったことを正直に書いたチームほど、発表の説得力が増します。個人名ではなく「仕組み・進め方」の問題として書くのがコツです
これらは全部、「今日初めて実装や発表をする」なら誰でも通る道です。詰まったら、その場でAIに具体的な状況を伝えて相談しましょう。
🤖 今日のAIの使いどころ
🗣️ 要約
まず自分で実装やエラーと向き合い、詰まったところだけ具体的にAIに聞く 確認テストの復習では、自分の言葉で説明した後にAIへ不足点を指摘してもらう
- まず自分で実装やエラーメッセージと向き合い、詰まったところだけ「〜というエラーが出た」「このコードはUIとロジックが分離できているか判定して」と具体的に聞く
- 確認テストの復習では、答えを見る前に自分の言葉で説明してみて、そのあとAIに「今の説明のどこが不足しているか指摘して」と聞くと、理解の抜けが見つかりやすくなります