成果発表

• 日程: Day 4 / セッション9
• 時間: 16:10-17:00
• 形式: 演習
• ゴール: チームごとに5〜10分で成果を発表し、開発したソースコードと発表資料を提出できる
• 学習形式: ケーススタディ

🗣️ 要約

• 発表は3日間の情報整理・設計と今日の実装を合わせた集大成であり、主役は話術ではなくソフトウェアそのもの
• 前回のセッションで作った発表資料を使って、実際に発表する

いよいよ最後のセッション、成果発表です。

3日間かけて情報を整理・分類し、情報モデルを作り、設計思想を選び、今日1日で実装してきました。その集大成を、これからチームごとに発表してもらいます。

ところで、発表と聞いて何を思い浮かべますか。緊張する、うまく話せるか不安、という人も多いはずです。でも今日の発表の主役は「話術」ではありません。主役は、皆さんが作ったソフトウェアそのものです。

このセッションが終わる頃には、自分たちの成果を人に伝え、他のチームの発表から新しい気づきを持ち帰れるようになっています。

前回のセッションでは、役割分担実績・構成・デモ・KPT・アピールポイントを含む発表資料を完成させました。今回はその資料を使って、実際に発表する番です。

🗣️ 要約

• 発表の時間配分（チーム紹介・情報モデル・デモ・KPT）
• 発表を聞く側にも「良かった点を1つ伝える」という役割がある
• 発表準備の迷いはAIに相談できる

🗣️ 要約

• 発表は1チームあたり5〜10分で、デモ（3〜4分）に最も時間を割く配分になる
• 発表に含めるのは「何を作ったか」「なぜその設計にしたか」であり、実装コードの逐次説明は含まない

発表は1チームあたり5〜10分です。時間配分の目安はこうです。

• チーム紹介・開発テーマ（1分）
• 情報モデル・設計思想の選択（2分）
• デモ（3〜4分）
• KPTとアピールポイント（1〜2分）

ここで少し考えてみてください。もし発表時間が5分しかないとしたら、3日間の学びの中で何を一番伝えたいですか。全部を話そうとすると、結局何も伝わりません。これは料理のコース選びのようなものです。フルコースを全部出そうとすると時間内に食べきれませんが、その日一番自信のある一皿に絞れば、印象に残ります。

発表に含めるべき要素は該当しますが、実装コードを1行ずつ読み上げることは該当しません。なぜなら、聞き手が知りたいのは「何を作ったか」「なぜその設計にしたか」であって、コードの詳細ではないからです。

特に注意してほしいのは、デモを「主役」にすることです。よくある間違いとして、スライドの説明だけで終わってしまい、実際に動く画面を見せないケースがありますが、正しくは画面を実際に操作して見せることです。動くものを見せられることこそ、この4日間の一番の成果だからです。

エンジニアの世界には「デモの魔物（デモジンクス）」という有名な言い伝えがあります。普段は問題なく動いていたシステムが、なぜか本番の発表やお客様の前でだけ突然エラーを起こす、という現象です。原因は複合的だと言われますが、緊張による操作ミスや、直前の環境変更を忘れることが多いようです。対策はシンプルで、発表直前に一度リハーサルをすること、そして万が一動かなくても慌てず「ここで何が起きているか」を正直に説明することです。実は、うまくいかなかった瞬間ほど、聞き手の記憶に残ることも少なくありません。

🗣️ 要約

• 発表を聞いたチームは必ず「良かった点」を1つ伝える
• フィードバックは相手を評価するためではなく、お互いの学びを厚くするためのもの

発表するチーム以外は、ただ座って聞いているだけではありません。聞く側にも役割があります。

このセッションのルールとして、発表を聞いたら必ず「良かった点」を1つ、その場かフィードバック用紙で伝えてください。

なぜでしょうか。少し考えてみてください。批判や指摘だけを集めると、次に発表するチームが萎縮してしまいます。一方で「良かった点」を意識して聞くと、聞く側も他チームの工夫を自分ごととして持ち帰りやすくなります。これは、Day4の午前中に行った確認テストの復習と同じで、フィードバックは相手を評価するためではなく、お互いの学びを厚くするためのものです。

🗣️ 要約

• 発表内容の絞り方、デモ失敗時の説明方法、発表原稿の改善などをAIに相談できる

発表準備で迷ったら、AIに聞いてみましょう。たとえば：

• 「5分の発表で、この内容をどう削ればいいか一緒に考えて」
• 「デモが失敗したときの説明の仕方を教えて」
• 「この発表原稿、もっと聞き手を引き込む言い方に直せる？」

🗣️ 要約

• チームごとに発表・質疑応答を行い、他チームには「良かった点」を1つ以上フィードバックする

🗣️ 要約

• 発表資料とデモ環境の最終確認→発表順に5〜10分で発表→質疑応答→他チームへのフィードバック、という流れで実施する

チームごとに、以下を実施してください。

• 発表資料とデモ環境を最終確認する
• 発表順にしたがって、5〜10分で発表する
• 発表後、簡単な質疑応答を受ける
• 他チームの発表を聞き、「良かった点」を1つ以上フィードバックする

🗣️ 要約

• 発表の実施（可能であれば録画・写真）
• 提出物は開発したソフトウェアのソースコードと成果発表資料

• 発表の実施（記録が可能であれば録画・写真等）
• 提出物：開発したソフトウェアのソースコード（GitHub等）、成果発表資料

🗣️ 要約

• デモが動かない場合はバックアップの録画を見せながら状況を正直に説明する
• 時間が足りない場合はKPTの「Try」を優先して話す
• 質疑応答で詰まったらAIに相談してよい

• デモがうまく動かない場合は、事前に録画しておいたバックアップ動画を見せながら「ここでこういう問題が起きています」と正直に説明すると、聞き手にも状況が伝わります
• 時間が足りなくなりそうな場合は、KPTの「Try（次にやること）」を優先して話すと、チームの学びが一番伝わります
• 質疑応答で答えに詰まったら、その場でAIに「〜という質問をされたが、どう答えるとよいか」と相談してもかまいません

🗣️ 要約

• 作ったものは、伝えて初めて価値になる
• 次回は研修全体のまとめ

今回学んだことを一言でまとめると、「作ったものは、伝えて初めて価値になる」です。

どんなに良い情報モデルを作り、どんなに丁寧に設計思想を選んでも、それが誰にも伝わらなければ、その価値は半分しか実現していません。今日の発表で、皆さんは4日間の学びを人に伝えるところまでやり遂げました。

次回は研修全体のまとめです。今日感じた「伝わった」「伝わらなかった」という手応えも、次のセッションの振り返りに活かしましょう。

🗣️ 要約

• 自分たちのチームが一番伝えたかったことを一言で説明できるか
• 他チームの発表から自分たちにない工夫を1つ挙げられるか

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

• 自分たちのチームが一番伝えたかったことを、一言で説明できますか？
• 他チームの発表から、自分たちにない工夫を1つ挙げられますか？

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

🗣️ 要約

• 参考リンクはなく、チーム発表資料・ソースコードが本セッションの主教材
• 発展課題は、他チームの開発テーマを自分たちならどう整理するか考えること

• 参考リンク: なし（チーム発表資料・ソースコードが本セッションの主教材です）
• 発展課題: 発表後、他チームの開発テーマを1つ選び、自分たちならどう情報アーキテクチャの手法で整理するかを考えてみましょう

🗣️ 要約

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

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

🗣️ 要約

• 発表時間オーバー時は説明を減らすのではなく、デモを主役にして伝えたいことを1つに絞る
• デモのエラーは慌てず状況を説明する。バックアップ録画があると安心
• フィードバックは機能に限らず、ペルソナ設定や資料の見やすさなども対象になる

🗣️ 要約

• スライド説明だけで終わり、実際の画面を見せられないことがある
• コードの詳細を1行ずつ説明して時間切れになりやすい
• 批判的なフィードバックばかりになりやすい