成果発表資料作成とデモ

• 日程: Day 4 / セッション 5
• 時間: [14:00-14:45]
• 形式: 演習
• ゴール: 役割分担実績（AI協働の記録）・ソフトウェア構成・デモ・KPT・アピールポイントの5項目を含む成果発表資料を作成し、AI を聴衆に見立てて5分間の発表と質疑応答を実施できる
• 学習形式: 発表演習（AIレビューあり）

手元に動くソフトウェアと GitHub のリポジトリがあります。最後の仕事は、それを「伝わる形」にすることです。

ここで少し考えてみてください。あなたの4日間の成果を一番よく知っているのは誰でしょうか？　あなた自身です。しかし「知っている」と「説明できる」の間には大きな谷があります。発表とは、この谷を渡る行為です。

そしてこの発表には学習効果の仕掛けがあります。「話す＆行う」は記憶定着率が最も高い学習形式です。デモを行い、自分の言葉で話すことで、4日間の学びが長期記憶に変わります。発表は儀式ではなく、学習の最終工程です。

教育要件で定められた5項目を、そのまま資料の章立てにします。形式はスライドでもMarkdown 1枚でも構いません。5分で話せる分量（スライドなら5〜7枚）が上限です。

1. 役割分担実績（AI協働の記録）

   • 本来はチームの役割分担を書く項目。本研修は「あなた＋AI」のチーム開発だったので、AIとの分担実績を書く
   • 例:「情報のブレストはAIに発散させ、取捨選択は自分」「db.json の変換はAI、属性名の最終決定は自分」「エラー解決はエラー文をAIに貼り、原因説明を自分の言葉で記録」
   • 良い書き方: 「何をAIに任せ、何を自分が判断したか」の境界線を書く。「全部AIがやりました」は分担実績ではない
2. 開発したソフトウェアの構成

   • 開発ツールとフレームワーク: JSON Server（または apiary）、素のHTML+JavaScript（fetch）、GitHub
   • 構成図を1枚入れる。api/（機能）と ui/（プレゼンテーション）の分離、成果物とコードの対応（情報定義書→db.json 等）を線で結ぶ
   • ここが研修の採点ポイント。「2つの分離」が構成図で語れれば到達目標 No.4・No.5 の証明になる
3. 開発成果のデモ

   • 主要ユースケース1本を実際に操作して見せる（一覧→詳細→登録 等）
   • 裏側も見せると強い: 登録操作の後に db.json を開き「UIの操作がAPIを通ってデータを変えた」ことを示す
4. KPT（Keep / Problem / Try）

   • Keep: うまくいったので続けたいこと（例: 動いたらコミット）
   • Problem: 困ったこと・課題（例: 分離の判断に迷って時間を使った）
   • Try: 次に試したいこと（例: React への置き換え、本物のDBへの差し替え）
   • 各2〜3個。事実ベースで書く（「頑張った」ではなく「curl のログを貯めて再利用した」）
5. その他アピールポイント

   • 工夫・こだわり・4日間で一番の発見。1つに絞ると印象に残る

構成図の例です（発表資料にそのまま使える形）。

• 資料作成は15分で切り上げ、発表練習に時間を残す。資料の美しさより、デモが動くことと話の筋
• デモは必ず本番前に1回通す。「さっきまで動いていた」は世界共通の悲劇

デモの世界には「デモの神様（demo gods）」という言い回しがあります。本番の瞬間だけ動かなくなる現象への、エンジニアの諦めと祈りの表現です。史上最も有名なデモは1968年のダグラス・エンゲルバートによる「The Mother of All Demos」。マウス、ウィンドウ、ハイパーテキスト、ビデオ会議を90分で披露し、現代のコンピューティングの原型を一夜で示しました。彼が徹底したのはリハーサルです。神様に祈るより、通し練習1回。

本研修の聴衆は AI です。人間より容赦なく、しかし何度でも付き合ってくれる理想の練習相手です。次の3ラウンドで進めます。

• ラウンド1: 発表（5分）

  • AI に聴衆役を依頼してから、資料の内容を順に話す（テキストで貼る、または読み上げ内容を書き込む）
  • 依頼プロンプト例:「あなたは新入社員研修の成果発表会の審査員です。これから私が発表します。最後まで聞いてから、良かった点2つと改善点2つを指摘してください。発表内容: （資料を貼る）」
• ラウンド2: 質疑応答（5分）

  • プロンプト例:「次に、審査員として私に質問を3つしてください。1つは『2つの分離』について、1つは技術選定の理由、1つは意地悪な質問にしてください。私の回答にも講評をください」
  • 答えに詰まった質問こそ収穫。それが自分の理解の穴
• ラウンド3: 改善（5分）

  • 指摘を1つだけ選んで資料を直す。全部直そうとしない（時間管理も発表技術）

質疑応答で想定される定番質問も予習しておきましょう。

• 「なぜモックAPIを使ったのですか？　本物のDBではだめだった理由は？」
• 「UIをスマホアプリに変えるとしたら、どのファイルが無傷で残りますか？」
• 「情報の設計とシステムの設計の分離は、あなたの成果物のどこに現れていますか？」

3問とも即答できれば、この研修は完全合格です。

• 発表は書き言葉ではなく話し言葉で。資料を読み上げるのではなく、デモを軸に語る
• 質疑で答えられなかった質問は、次セッションの復習リストに追加する（確認テストと同じ扱い）

KPT の元をたどると、ソフトウェア業界の「ふりかえり（レトロスペクティブ）」文化に行き着きます。ノーム・カースの著書『Project Retrospectives』（2001年）は「どんな結果であれ、全員がその時点で最善を尽くしたと信じる」という有名な最優先条項（Prime Directive）を掲げました。ふりかえりは犯人探しではなく学びの回収である、という宣言です。KPT はその日本での定番形式で、ホワイトボードを3分割するだけで始められる手軽さから広まりました。あなたの KPT も、自分を責める場ではなく、明日の自分への申し送りです。

• 「私の発表資料の下書き（貼り付ける）を、審査員の視点で採点して。特に『2つの分離』の説明が伝わるかを重点的に」
• 「あなたは辛口の技術審査員です。私のソフトウェア構成（貼り付ける）に技術的な質問を3つして。回答したら10点満点で講評して」
• 「私の KPT（貼り付ける）が事実ベースになっているか確認して。感想文になっている項目があれば、事実ベースに書き直す例を示して」

1. 発表資料を作成する（15分）

   • 5項目（役割分担実績・構成・デモ・KPT・アピール）を含む資料を作る
   • 構成図1枚（Mermaid可）を必ず入れる
2. AI聴衆に発表する（10分）

   • ラウンド1（発表）とラウンド2（質疑応答3問）を実施する
   • 答えに詰まった質問をメモする
3. 改善して確定する（5分）

   • 指摘から1つ選んで資料を修正し、提出版とする
   • GitHub リポジトリの URL を資料に記載する

• 成果発表資料（5項目＋構成図、5分で話せる分量）
• 提出物一式: 発表資料＋ソースコード（GitHub リポジトリ URL）
• 質疑応答メモ（答えに詰まった質問と、その後の回答案）

• 時間が足りなければ、資料は Markdown の箇条書きで十分。構成図とKPTを優先する
• デモが不安定なら、操作手順を資料に書いておく（デモ台本）。最悪スクリーンショットで代替
• 「AI協働の記録」は今日1日のチャット履歴を見返すと早い。印象的なやり取りを2〜3個引用する

今回学んだことを一言でまとめると「発表は成果の報告であると同時に、話す＆行うによる最強の復習である」です。

• 5項目の資料で、4日間の成果物と学びを1つの物語にした
• 構成図で「2つの分離」を自分の言葉で語れるようにした
• AIとの質疑応答で、理解の穴を発表前に発見した

次のセッションは確認テストです。発表で言語化した知識が、問題を解く力になっているかを測ります。質疑で詰まった箇所は要注意です。

• 発表資料に含める5項目を、見ずに全部言えますか？
• 「なぜモックAPIを使ったのか」に30秒で答えられますか？
• あなたの KPT の Try は、明日から実行できる具体性がありますか？

• 参考リンク: エスター・ダービー／ダイアナ・ラーセン『アジャイルレトロスペクティブズ』、GitHub Docs「READMEについて」
• 発展課題: 発表資料を GitHub リポジトリの README.md に統合し、「リポジトリを開けば全部わかる」状態にする。スライドツール（Marp等）でMarkdownからスライド化するのも良い