中間発表の準備〜進捗まとめとデモ準備

• 日程: Day 14 / セッション 2
• 時間: [9:40-11:00]
• 形式: 実習
• ゴール: 進捗状況・デモ・課題と相談事項をまとめた中間発表資料を80分以内に作成し、デモの動作確認を完了できる
• 学習形式: ハンズオン実習（AIサポートあり）

ここから80分で、中間発表の資料とデモを仕上げます。

その前に1つ問いかけです。
「『開発は順調です』という報告を聞いて、あなたは何が分かりますか？」

実は、ほとんど何も分かりません。「順調」は報告者の感想であって、事実ではないからです。聞き手が知りたいのは「どこまで終わって、何が残っていて、何に困っているか」という事実です。

中間発表は成果発表会（Day 21）とは目的が違います。成果発表会は製品の価値を「アピール」する場、中間発表は現在地を「共有」して助言をもらう場です。かっこよく見せる必要はありません。正確に伝えることに集中しましょう。

進捗報告の鉄則は、感想ではなく数字で語ることです。

たとえるなら、マラソンの中継です。「選手は頑張っています」では何も伝わりませんが、「30km地点を通過、先頭と2分差」なら誰でも状況が分かります。かんばんがあるみなさんは、この数字をすぐに作れます。

• 数字での報告に該当する例: 「全タスク20個のうち12個が完了（60%）。計画では14個の予定だったので2個の遅れです」
• 該当しない例: 「だいたい半分くらい終わって、まあまあ順調です」。基準が報告者の感覚にしかなく、聞き手が遅れの有無を判断できないからです

数字に加えて「計画との差」と「差の理由」を一言添えると、報告の質が一段上がります。

ここで考えてみてください。
「遅れを正直に数字で報告すると、評価が下がると思いますか？」

逆です。遅れを早く正確に共有するチームほど、助言と支援を早く受けられます。仕事の世界では「悪い報せほど早く」が鉄則です。

発表資料の構成例（5〜7枚で十分）:

• 進捗は「完了タスク数／全タスク数」＋「計画との差」＋「理由」のセットで
• かんばんがそのまま進捗の証拠になる。昨日の終会で数えた数字を使う
• よくある間違い: 「あと少しで終わるタスク」を完了に数える。Doneの条件を満たしたものだけがDone

「順調です」報告の危険性は、ソフトウェア業界で「90%シンドローム」として知られています。プロジェクトの進捗報告が90%に達してから、残り10%に全体の半分の時間がかかる現象です。原因は、残作業を楽観的に見積もる人間の癖にあります。だからこそ「Done条件を満たしたタスク数」という客観的な数字が大切なのです。ちなみに名著『人月の神話』の著者ブルックスは「プロジェクトはどうやって1年も遅れるのか？ ……1日ずつだ」という名言を残しています。1日の遅れを毎日数字で見ていれば、1年の遅れは防げるのです。

課題は具体的に書くほど、もらえる助言の質が上がります。

質問の仕方を対比してみましょう。

• 具体的な相談に該当する例: 「予約一覧の検索機能で、日付の絞り込みが遅い。データ300件で3秒かかる。クエリの書き方を見直すべきか、表示の工夫で逃げるべきか意見がほしい」

  • 状況・数字・選択肢があり、聞かれた側はすぐ助言できます
• 該当しない例: 「検索がうまくいきません」

  • 何がどう「うまくいかない」のか分からず、聞かれた側は質問を返すしかありません

課題スライドは「困っていること」＋「相談したいこと（質問文）」のセットで書きます。質問文の形にしておくと、発表後の質疑が自然に始まります。

**デモ準備の鉄則は「本番と同じ条件で通すこと」**です。

• デモシナリオを決める: 「誰が・どの画面から・何を入力して・何を見せるか」を1本の流れにする
• 本番の機材・画面で最低1回通す
• 失敗に備える: スクリーンショットや画面録画を保険として用意する

• 課題は「状況＋数字＋聞きたいこと」の形に。あいまいな相談にはあいまいな助言しか返らない
• デモは欲張らない。動く1機能を確実に見せる方が、不安定な5機能より伝わる
• デモ中の入力値は事前に決めておく。その場で考えると焦って詰まる

デモの失敗はプロでも避けられません。1995年、マイクロソフトのビル・ゲイツがWindows 98のデモ中に画面が真っ青なエラー（ブルースクリーン）になり、会場は大爆笑。ゲイツは「これがまだ出荷していない理由です」と切り返して拍手をもらいました。この事件以来、業界では「デモの神様」という言葉が冗談で使われます。本番のデモは必ず何かが起きるもの。だから保険（スクリーンショット・録画）と、何かあっても笑って切り返す心の準備が大事なのです。

準備を進める中で困ったら、AIに相談してみましょう。たとえば：

• 「この進捗データ（完了12／全20、計画比−2）を、1分で伝わる報告文にして」
• 「この課題の説明を、聞いた人が助言しやすい質問文に直して」
• 「デモが途中で失敗したときの切り返し方を3パターン教えて」

朝会で確認した分担に従い、チームで次を完成させます。

1. 進捗まとめ（目安15分）

   • かんばんから完了タスク数／全タスク数を確定する
   • 計画との差と、差が出た理由を1〜2行でまとめる
2. 発表資料の作成（目安25分）

   • 本編の構成例（テーマ・進捗・デモ・課題相談・今後の予定）に沿って5〜7枚作る
   • 課題スライドは「状況＋数字＋聞きたいこと」の形にする
   • 文章はAIに推敲を手伝ってもらってよい（数字と事実はチームが責任を持つ）
3. デモ準備と動作確認（目安15分）

   • デモシナリオ（操作の流れ・入力値・見せ場）を決める
   • 本番と同じ機材・画面で最低1回通しで確認する
   • 失敗時の保険（スクリーンショット・録画）を用意する
4. ミニリハーサル（目安5分）

   • 役割分担どおりに1回通す。時間を計り、持ち時間に収まるか確認する

• 中間発表資料（進捗・デモ・課題と相談事項を含む）
• 動作確認済みのデモ（＋失敗時の保険）
• 発表のタイムテーブルと役割分担メモ

• 時間が足りないときの優先順位は「デモ確認 ＞ 進捗の数字 ＞ 課題の文章 ＞ 資料の見た目」
• 資料の見た目に凝り始めたら危険信号。中間発表は伝われば十分
• デモでエラーが出たら、エラー全文をAIに貼り付けて相談すると解決が早いです
• 「相談したい課題が思いつかない」チームは、AIに「この進捗状況のチームが他チームに相談すべきことは？」と聞いてみましょう

今回学んだことを一言でまとめると、**「中間発表の準備とは、現在地を数字で示し、助言を引き出す問いを用意すること」**です。

• 進捗は感想ではなく「完了／全タスク＋計画との差＋理由」
• 課題は「状況＋数字＋聞きたいこと」の質問形に
• デモは本番条件で通し、保険も用意する

次回（本日セッション3）はいよいよ中間発表本番です。

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

• 自チームの進捗を数字で、計画との差まで含めて言えますか？
• 発表で相談する課題を、質問文の形で言えますか？
• デモは本番と同じ条件で通りましたか？ 失敗時の保険はありますか？

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

• 参考リンク: 「報連相 数字で報告」「進捗報告 書き方」で検索
• 発展課題: 完成した発表資料をAIに見せて、「聞き手が突っ込みたくなる点」を予想してもらい、回答を1つ準備してみましょう

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