（演習）成果発表資料作成

• 日程: Day 4 / セッション8
• 時間: [15:20-16:00]
• 形式: 演習
• ゴール: 役割分担実績・構成・デモ・KPT・アピールポイントを含む発表資料を1つ完成できる
• 学習形式: AIブレスト

🗣️ 要約

• 発表資料には役割分担実績・構成・デモ・KPT・アピールポイントの5要素が必要
• 作業時間は40分で、まずは粗くても全部埋めることを優先する

前のセッションで、発表資料に必要な5つの要素を確認しました。役割分担実績、構成、デモ、KPT、アピールポイントでしたね。

ここからは、実際に手を動かして資料を完成させる時間です。

このセッションが終わる頃には、明日から誰かに見せても恥ずかしくない発表資料が1つ手元にある状態になっています。時間は40分です。短いと感じるかもしれませんが、5つの要素をすべて丁寧に作り込む時間はありません。まずは「粗くてもいいから全部埋める」ことを優先しましょう。

🗣️ 要約

• 資料はデザインより先に骨組み（5つの見出し）を埋める
• デモは発表当日に初めて動かすのではなく、事前に動く状態にしておく

🗣️ 要約

• デザインを整える前に、5つの見出しに箇条書きで内容を埋めていく
• チームが4日間で一番苦労したことが、そのままKPTの「Problem」になる
• アピールポイントは技術用語の羅列ではなく、学んだ考え方とセットで語る

いきなりスライドのデザインを整え始めると、時間が足りなくなります。

料理に例えると、盛り付けを気にする前に、まず材料を全部そろえて下ごしらえを終わらせるようなものです。見た目は後からいくらでも直せますが、中身がなければ発表は成立しません。

最初にやるべきことは、5つの見出し（役割分担実績／構成／デモ／KPT／アピールポイント）をスライドや文書に並べ、それぞれに箇条書きで思いつくことをどんどん書き込んでいくことです。

ここで一度考えてみてください。あなたのチームが4日間で一番苦労したことは何でしょうか？　その苦労は、そのままKPTの「Problem」になります。

骨組みの例（Markdownで書く場合）：

# ○○チーム 成果発表資料

## 役割分担実績
- Aさん: 情報モデル設計・API実装
- Bさん: UI実装・モックアップ作成
- Cさん: ペルソナ定義・情報整理
- Dさん: 発表資料・進行管理

## 構成（使用した開発ツール・フレームワーク）
- API: apiary（モック） / GitHub（ソース管理）
- UI: Monaca（HTML/JavaScript）

## デモ
- ペルソナ「田中さん」が家計簿を登録→一覧表示するまでの流れを実演

## KPT
- Keep: 毎朝Whyを確認してから作業に入ったので手戻りが少なかった
- Problem: 情報モデルの再定義に時間がかかり、実装時間が圧迫された
- Try: 次回はレビューのタイミングをもっと早く設定する

## アピールポイント
- ペルソナ視点でLATCH法とカードソーティングを両方使い切った

特に注意してほしいのは、KPTの「Problem」を隠さないことです。うまくいかなかったことを正直に書いたチームほど、発表の説得力が増します。

よくある間違いとして、アピールポイントを技術用語の羅列にしてしまうケースがあります。「RESTful APIを実装しました」だけでは伝わりません。正しくは「情報の設計とシステムの設計を分離したので、UIだけ後から差し替えられる作りになっています」のように、この研修で学んだ考え方とセットで語ることです。

KPT（Keep Problem Try）は、もともとアジャイル開発の「ふりかえり」手法の1つとして広まった型です。似たものにYWT（やったこと・わかったこと・つぎにやること）という日本発の手法もあります。

面白いのは、多くのチームが最初は「Problem」を書くのを恥ずかしがることです。ところが実際に発表会で聞いてみると、聴衆が一番身を乗り出して聞くのはKeepでもTryでもなく、Problemだったりします。「うちも同じところで詰まった！」という共感が生まれるからです。失敗の共有は、実は一番価値のある情報なのです。

🗣️ 要約

• デモは当日その場で初めて動かすのが一番のリスク
• 該当するのは実際に画面を操作して見せるデモ、該当しないのはスクリーンショットだけのもの
• エラー対策として、動く状態を撮影した動画をバックアップに用意しておく

デモは、発表当日にその場で初めて動かす、というのが一番のリスクです。

これは、結婚式のスピーチをぶっつけ本番でやるようなものです。一度も声に出して練習していないと、本番で思わぬところで詰まります。

該当するのは「実際に画面を操作して見せる」デモです。該当しないのは「スクリーンショットを貼っただけ」のものです。なぜなら、動く画面を見せることで、ペルソナが本当に価値を感じられる体験になっているかを、聴衆が判断できるからです。

ここで少し考えてみてください。もしデモの途中でエラーが出てしまったら、どうしますか？　あらかじめ「バックアップとして動画を撮っておく」というのも、立派な対策の1つです。

🗣️ 要約

• KPTのProblemが思いつかないとき、アピールポイントの言い換え、資料構成の順番などをAIに相談できる

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

• 「KPTのProblemが思いつかないので、こういう作業でよくある詰まりどころを教えて」
• 「アピールポイントを技術用語だけじゃなく伝わる言葉に言い換えて」
• 「発表資料の構成、5つの要素の順番はこの並びでいい？」

🗣️ 要約

• チームで役割分担し、5要素を含む成果発表資料を1つ完成させる演習

🗣️ 要約

• 役割分担実績・構成・デモ（実際に動かせる状態）・KPT・アピールポイントの5要素を含む資料を完成させる

チームで役割分担し、以下の5つの要素を含む成果発表資料を1つ完成させる。

1. チームの役割分担実績
2. 開発したソフトウェアの構成（開発ツール、フレームワーク）
3. 開発成果のデモ（実際に画面を動かせる状態）
4. KPT（Keep Problem Try）
5. その他アピールポイント

🗣️ 要約

• 成果発表資料（1チーム1部）。形式はスライド・Markdown文書など自由

成果発表資料（1チーム1部）。形式はスライド・Markdown文書・その他チームが発表しやすいものでよい。

🗣️ 要約

• 時間内に終わらない場合は5つの見出しを埋めることを優先し、装飾は後回しにする
• デモのエラーはAIに伝えると解決策を教えてもらえる
• 「聴衆だったら何を知りたいか」を1人ずつ言うと抜けている観点に気づきやすい

• 時間内に終わらない場合は、まず5つの見出しを全部埋めることを優先し、装飾は後回しにする
• うまくいかない場合は、前のセッションで確認した5つの要素が全部揃っているか見直してみてください
• デモでエラーが出たら「〜というエラーが出た」とAIに伝えると解決策を教えてもらえます
• チーム内で「聴衆だったら何を知りたいか」を1人ずつ言ってみると、抜けている観点に気づきやすくなります

🗣️ 要約

• 発表資料は「技術の説明」ではなく「価値の説明」
• 次回はこの資料とデモを使って成果発表を行う

今回学んだことを一言でまとめると、発表資料は「技術の説明」ではなく「価値の説明」だということです。

次回は、いよいよこの資料を使ってチームごとに成果発表を行います。今回作った資料とデモが、そのまま本番で使われます。デモが本当に動くか、休憩時間にもう一度だけ確認しておきましょう。

🗣️ 要約

• 発表資料に含めるべき5つの要素を資料を見ずに言えるか
• 自分のチームのKPTの「Problem」を1つ具体的に言えるか

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

• 発表資料に含めるべき5つの要素を、資料を見ずに言えますか？
• あなたのチームのKPTの「Problem」を1つ、具体的に言えますか？

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

🗣️ 要約

• 参考リンクはなし。発展課題は発表時間に収まるよう声に出して通しリハーサルをすること

• 参考リンク: なし（社内資料・独自開発テーマのため）
• 発展課題: 発表時間（5〜10分）に収まるよう、資料をもとに一度声に出して通しリハーサルをしてみる

🗣️ 要約

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

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

🗣️ 要約

• KeepとTryの違いは「続けたい良かったこと」と「次に試したいこと」
• アピールポイントは「その技術でペルソナにどんな価値が生まれたか」を添えると伝わる
• デモが直前で動かなくなったら、直前に動いていた状態のスクリーンショットや動画に切り替えてよい

🗣️ 要約

• KPTのProblemを隠して良いことだけ書いてしまいやすい
• アピールポイントが技術用語の羅列になりやすい
• 装飾にこだわって時間内に資料が完成しないことがある