成果発表資料作成のポイント

• 日程: Day 4 / セッション7
• 時間: [15:00-15:20]
• 形式: 座学
• ゴール: 発表資料に含めるべき5つの要素（役割分担実績・構成・デモ・KPT・アピールポイント）を挙げられる
• 学習形式: 対話型解説

🗣️ 要約

• 発表資料で重要なのは見た目の美しさではなく、決められた要素を書くこと
• 4日間の意思決定の過程を人に伝える場が発表

いよいよ実装セッションが終わりました。ここからは、今日の締めくくりである「成果発表」に向けた準備に入ります。

ところで、発表資料と聞いて何を思い浮かべますか？「スライドをきれいに作ること」を想像した人もいるかもしれません。でも、この研修で求めている発表資料は、見た目の美しさではありません。

このセッションが終わる頃には、発表資料に何を書けばよいか、迷わず言えるようになっています。前のセッションまでで実装が一区切りついたチームも、まだ手を動かしたいチームもあると思いますが、20分だけ「伝え方」に頭を切り替えましょう。

🗣️ 要約

• 発表資料に含める要素は、役割分担実績・構成・デモ・KPT・アピールポイントの5つ
• KPTのProblemは失敗の記録ではなく、次に活かすための資産

🗣️ 要約

• 発表資料に含める5要素は、役割分担実績・ソフトウェア構成・デモ・KPT・アピールポイント
• 役割分担実績は予定ではなく実際の動きを書く
• デモは実際に操作して見せられる状態にしておく

4日間、チームでたくさんの意思決定をしてきました。ペルソナを決め、情報を整理し、設計思想を選び、実装を進めてきましたね。発表は、その意思決定の過程を人に伝える場です。

発表資料に含めるべき要素は、次の5つです。

• チームの役割分担実績
• 開発したソフトウェアの構成（開発ツール、フレームワーク）
• 開発成果のデモ
• KPT（Keep Problem Try）
• その他アピールポイント

一つずつ見ていきましょう。ここで少し考えてみてください。この5つのうち、あなたのチームがまだ何も準備していないものはどれでしょうか？

「誰が何を担当したか」の記録です。予定していた役割分担ではなく、実際にどう動いたかを書くのがポイントです。たとえば、当初は「Aさんが実装、Bさんが設計」の予定でも、途中でBさんも実装に加わったなら、その通りに書きます。予定と実績がずれること自体は、チーム開発ではよくあることです。

使った開発ツールやフレームワーク（apiary、Monaca、React.jsなど）を書きます。これは技術選定の記録であり、後で見返したときに「なぜこの技術を選んだか」を思い出す手がかりにもなります。

実際に画面を動かして見せる部分です。スライドで説明するだけでなく、実際に操作して見せられる状態にしておくことが重要です。

振り返りのフレームワークです。

• Keep：うまくいったので続けたいこと
• Problem：うまくいかなかったこと、困ったこと
• Try：次に試したいこと

チームとして工夫した点、こだわった点を自由に書く欄です。

🗣️ 要約

• KPTのProblemは失敗の記録ではなく、次に活かすための資産（航海日誌のたとえ）
• Problemは「仕組みの問題」として書き、個人への責任追及にしない

ここが今日いちばん伝えたいポイントです。KPTのP（Problem）を書くとき、「うまくいかなかったことを発表するのは恥ずかしい」と感じる人がいます。しかし、それは逆です。

たとえるなら、KPTは「今回の航海日誌」のようなものです。順調だった区間（Keep）だけでなく、嵐に遭った区間（Problem）を記録しておくからこそ、次の航海（Try）で同じ嵐を避けられます。Problemを書かない発表は、次に活かせる情報がない発表と同じです。

たとえば「情報モデルの状態遷移を最初に細かく作りすぎて、実装段階で機能一覧を作り直した」という失敗は、立派なProblemです。該当しない例は、単なる愚痴や個人への責任追及です。「〇〇さんが遅かった」ではなく「タスクの見積もりが甘かった」のように、仕組みの問題として書くのがコツです。

発表資料の構成例（スライド1枚に1要素、目安6〜7枚）：

1. チーム紹介・役割分担実績
2. 開発テーマとペルソナ
3. ソフトウェア構成（使用ツール・フレームワーク）
4. デモ（画面キャプチャ or 実演）
5. KPT
6. アピールポイント

特に注意してほしいのは、デモを「見せられる状態」にしておくことです。よくある間違いとして、スライドの中にスクリーンショットだけ貼って終わりにしてしまうケースがありますが、正しくは、可能な限り実際に画面を操作して見せる準備をしておくことです。動かないときのために、スクリーンショットや録画を保険として用意しておくとなお安心です。

KPTはもともとアジャイル開発のふりかえり手法として広まったフレームワークです。面白いのは、多くのチームが最初は「P（Problem）ばかり大量に出てTばかり増えて実行しきれない」という状態に陥ることです。これも一種の「あるある」で、KPTのふりかえりでは、Problemを全部解決しようとせず、次に1つか2つだけTryを選ぶのがコツだと言われています。完璧を目指さない、というのもチーム開発の知恵の一つです。

🗣️ 要約

• KPTのPの書き方、デモが動かないときの対処、役割分担のずれの説明方法などをAIに質問できる

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

• 「KPTのPをどう書けば個人攻撃にならない？」
• 「デモがうまく動かないときの発表の乗り切り方は？」
• 「役割分担実績と予定が大きくずれた場合、どう説明すればいい？」

🗣️ 要約

• 発表資料は見た目ではなく、役割分担実績・構成・デモ・KPT・アピールポイントの5要素で伝える
• KPTのPは失敗の記録ではなく次への資産という考え方が資料作りの土台になる

今回学んだことを一言でまとめると、発表資料は「見た目」ではなく「役割分担実績・構成・デモ・KPT・アピールポイント」の5要素で伝える、ということです。

次回は、実際にこの5要素を使って成果発表資料を完成させます。今回学んだ「KPTのPは失敗の記録ではなく次への資産」という考え方が、資料作りの土台になるので、しっかり意識しておきましょう。

🗣️ 要約

• 発表資料に含めるべき5つの要素を挙げられるか
• KPTのProblemに書くべき内容と書くべきでない内容の違いを説明できるか

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

• 発表資料に含めるべき5つの要素を挙げられますか？
• KPTのProblemに書くべき内容と、書くべきでない内容の違いを説明できますか？

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

🗣️ 要約

• 参考リンクは特になく、社内資料・自チームの実装記録を参照する
• 発展課題は、開発以外の経験（部活動やアルバイトなど）でもKPTを1つ作ること

• 参考リンク: なし（社内資料・自チームの実装記録を参照）
• 発展課題: 過去に参加した部活動やアルバイトなど、開発以外の経験でもKPTを1つ作ってみる

🗣️ 要約

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

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

🗣️ 要約

• KeepとTryの違いは、Keepが「続ける」、Tryが「新しく試す」
• デモ環境が壊れた場合に備え、画面録画やスクリーンショットを保険として用意する

🗣️ 要約

• Problemに個人名を書いて責任追及のようになってしまいやすい
• 役割分担実績を「予定」のまま書いてしまいやすい