中間発表の準備〜進捗まとめとデモ準備
概要
- 日程: Day 14 / セッション 02
- 時間: [9:40-11:00](80分)
- 形式: 実習(ハンズオン、AIサポートあり)
- ゴール: 進捗状況・デモ・課題と相談事項をまとめた中間発表資料を80分以内に作成し、デモの動作確認を完了できる
- 行動: 5枚程度の資料を作成し、デモを通しで1回動作確認する
- 条件: 80分以内に、AIに資料レビューを1回以上依頼する
- 基準: 進捗が「完了タスク/全タスク」の数字で書かれており、デモが本番環境で動く
- 学習形式: ハンズオン実習(AIサポートあり)
導入(5分)
中間発表で評価される資料の条件は、たった1つです。「正直に書いてあるか」。
「順調です」「だいたいできています」と書いた資料は、聞き手にもAIにも何も伝えません。「20タスク中14タスク完了。残り6タスクのうち3つはデモ未動作」と書いた資料は、相手の頭の中に絵を描かせます。具体的な数字は、抽象的な形容詞より強い。
そして、もう一つ大事なルール。デモは必ず動作確認をしてから資料に載せる。「資料には書いたけど本番では動かない」は最悪のパターンです。残り80分を「資料60分+デモ確認20分」の配分で使い切ります。
本編(30分相当)
1. 中間発表資料の骨格(5枚テンプレート)
中間発表は短いです(5分発表+3分質疑などの設定)。スライドを盛り込みすぎると、結局何も伝わりません。最小5枚で組み立てます。
コード例・実例
進捗スライドの良い例と悪い例
# 悪い例
## 進捗
- 設計はだいたい終わった
- 実装は順調に進んでいる
- いくつか課題はあるが対応中
# 良い例
## 進捗(Day9-13の実績)
- WBSタスク: 24/30 完了(80%)
- 動作する画面: 6/8(残り「会員登録」「予約完了」)
- DB接続: 完了
- 課題: 「予約完了」画面のメール送信機能が未着手
ここがポイント
「順調」「だいたい」「いくつか」は禁止語。すべて数字に置き換える。数字で書けない場合は、まだ自分たちの状態を把握できていないサインです。その場でかんばんを見直しましょう。
コラム
ソフトウェア開発には「90% 完了の罠」という言葉があります。「あと10%です」と言い続けて、いつまでも終わらない現象です。原因の多くは、見えていない作業(テスト、設計の見直し、デグレード対応)が10%に含まれているからです。「7タスク中5完了」のようにタスク単位で数えると、この罠を避けられます。
2. 課題と相談事項を具体的に書く
「困っていることは何ですか?」と聞かれて、「特にありません」と答えるチームほど、後で困ります。中間発表は相談する場です。
# 悪い例
## 課題
- パフォーマンスが少し気になる
- ユーザビリティに課題あり
# 良い例
## 課題と相談事項
1. 「予約一覧画面」で100件表示すると3秒かかる。
ページネーション導入か全件取得を見直すべきか相談したい。
2. ペルソナ「30代主婦」がスマホで操作する想定だが、
現在のUIはPC前提。レスポンシブ対応は残り日数で間に合うか相談したい。
具体的に書けば、聞き手は的確な助言を返せます。「少し気になる」「課題あり」では、エスパーじゃないと答えられません。
3. デモ動作確認のチェックリスト
「資料には書いたけど本番で動かない」を防ぐため、デモは必ず通しで動かして確認します。
| 確認項目 | 内容 |
|---|---|
| 環境 | 本番と同じURL・端末・ブラウザで起動するか |
| データ | デモ用データが投入済みか(リセットされていないか) |
| 操作手順 | 第1ステップから最終画面まで紙に書く |
| 所要時間 | 何分かかるか実測する |
| 失敗時の代替 | スクリーンショット or 録画を準備 |
| アカウント | ログインID/PWを資料の発表者ノートに記載 |
ここがポイント
デモは「最も動作確認した人」が操作する。発表担当と操作担当を分けてもOK。喋りながら操作するのは難易度が高いので、二人体制を推奨。
💬 AIに聞いてみよう
資料ができたら、AIに以下のように依頼してみてください。
- 「以下の中間発表資料を見て、聞き手として『もっと知りたい』と思う点を3つ挙げて:(資料貼り付け)」
- 「以下の進捗報告に曖昧な表現があれば指摘して:(進捗スライド貼り付け)」
- 「以下のデモシナリオで失敗しそうなポイントを3つ予測して:(手順貼り付け)」
AIは聞き手役・批判役として優秀です。発表前に1回叩いてもらうと、本番でハマる罠を事前に潰せます。
実習・演習(45分)
課題
チームで以下を80分で完成させてください。
- 5枚(最小)の発表資料(表紙/ペルソナ・課題/進捗/デモ/課題と相談事項)
- デモの通し動作確認(本番環境で1回成功)
- AIに資料レビューを1回以上依頼し、指摘を1件以上反映
成果物
- 中間発表資料(PDF/スライド/Markdown形式可)
- デモ手順メモ(発表者ノート)
- AIからの指摘事項と対応メモ
ヒント
- 60分で資料、20分でデモ確認、の時間配分を厳守
- 「表紙」と「進捗」を最初に作る(最重要)
- デモが動かない場合はスクショ・動画で代替してOK。隠さず正直に
- 役割分担:資料作成2人・デモ確認2人など並行作業を推奨
まとめ(5分)
中間発表資料は5枚で十分。大事なのは「正直な数字」と「具体的な相談」。デモは必ず通しで動作確認する。AIに1回レビューしてもらえば本番のハマりが減る。次のセッションは本番です。
🔄 振り返りチェック
- 進捗スライドに「順調」「だいたい」「いくつか」が含まれていませんか?
- 相談事項は具体的に書かれていますか?(聞き手が答えやすい粒度か)
- デモを通しで動作確認しましたか?失敗時の代替手段はありますか?
補足資料
- 参考: バーンダウンチャートで進捗を可視化する方法
- 発展課題: 資料作成後、AIに「投資家・顧客・技術者」それぞれの立場から質問を出させて想定問答に追加
学習ガイド
想定される質問と回答例
| 質問 | 回答例 |
|---|---|
| デモが動かない場合は発表しないほうがいい? | スクショ/動画で代替して必ず実施。「動かない原因」自体が相談事項になる |
| スライドは何枚まで作っていい? | 5分発表なら5〜7枚が目安。1スライド1分。詰め込みすぎると伝わらない |
| 課題が思いつかない | かんばんのTodoを眺める。残り日数で間に合わなそうなものが課題候補 |
つまずきやすいポイント
| つまずきポイント | ヒント |
|---|---|
| 進捗を数字にできない | かんばんのDone/Doing/Todo数を機械的に書く。それが現在地 |
| 資料に時間を使いすぎる | タイマー60分。残り20分はデモ確認に絶対使う。資料は完璧でなくてOK |
| デモのデータが消える | 投入スクリプトをファイルで残す。本番直前にもう一度実行できる状態にしておく |