Part 6 最終プロジェクト・動画
第24章 最終発表と次の学習計画
動画台本ナレーション全文
Slide 01. 最終発表と次の学習計画
第24章では、最終発表と次の学習計画を扱います。この章は、発表をきれいに見せるテクニックの章ではありません。第21章の個人プロジェクト、第22章の改善、第23章のリリース前確認を使います。何を作り、なぜ作り、どう確かめ、何を学んだかを、自分の言葉で話せるようにします。研修の終わりではなく、次の仕事への入口として扱います。
Slide 02. この章で持ち帰ること
この章で持ち帰ってほしいのは、作ったものを発表と90日計画に整理する手順です。画面やファイルを並べるだけでは、聞き手には伝わりません。発表で見せる根拠を選び、中心メッセージを決め、価値、判断、確認、AI利用、失敗からの学びにつなげます。発表の上手さより、成果物と説明が合っていることを重視します。強い主張には証拠を対応させ、証拠がない話は未確認やfollow-upとして弱めます。
Slide 03. 第23章との接続
第23章では、Production Readiness Reviewを行いました。これは、リリース前の確認レビューです。そこでrelease decision、リリース判断を作りました。第24章では、その結果を発表の根拠として使います。goなら、なぜ出せると言えるか。go with follow-upなら、何をあとで追うか。no-goでも、止めた理由を説明できれば大事な学びです。
Slide 04. 最終発表の目的
最終発表は、作った画面を順番に見せるショーケースではありません。聞き手が知りたいのは、完成度だけではなく、配属後にどう仕事を進められそうかです。何を課題として捉え、どう範囲を決め、どう実装し、どう確認し、何を削り、何を学んだのか。ここまで説明できると、成果物の見た目以上に、仕事の進め方が伝わります。
Slide 05. 成果物を書き出す
発表準備の最初の仕事は、スライド作成ではありません。まず、手元の成果物を書き出します。企画、作る範囲、デモ手順、改善PRのまとめ、リリース前確認、リリース判断、残課題などです。英語のファイル名を全部覚える必要はありません。何の根拠として使うか、source of truthはどれか、見せてよい情報かを選ぶことが大事です。
Slide 06. 中心メッセージ
発表には中心メッセージが必要です。たとえば、研修中の学習ログを整理し、相談が必要なログを見つけやすくするWebアプリを作った。さらに、status、つまり学習状態を表す項目を追加し、リリース前確認まで行った、という一文です。一文で言えると、構成が安定します。できた機能を全部並べるより、どんな価値を届けようとしたかが伝わります。
Slide 07. 価値から説明する
技術発表でも、最初は価値から説明します。誰が、何に困っていて、どう楽になるのかを話します。学習ログアプリなら、研修中の学びが増えるほど、相談が必要なログを見つけにくくなる、という課題があります。そこでstatusと絞り込みを追加した、とつなげます。何を作ったかの前に、なぜ作ったかを置くと、技術判断の意味が伝わります。
Slide 08. 技術判断を説明する
技術判断は、使った技術名を並べることではありません。なぜその作り方にしたか、他の案は何か、何を今回はやらなかったか、どう確かめたかを説明します。発表では全部を詳しく話しすぎず、重要な判断を二つか三つ選びます。たとえば、statusを三種類にした理由、既存ログをlearned扱いにした理由、絞り込みをどこで処理するかの判断です。
Slide 09. 品質確認を説明する
品質確認は、動きました、だけでは足りません。確認したこと、残るリスク、次に追うことを分けて話します。第23章のrelease-decision.md、リリース判断の文書が中心材料になります。たとえば、主要フローは確認済みだが、大量データ時の性能はあとで追う課題にした、のように説明します。
Slide 10. デモを構成する
デモは、機能一覧を順番に見せる時間ではありません。主要ユーザーフローを使って、利用者がどう助かるかを見せます。開始状態、操作、期待結果、価値を短く説明します。学習ログアプリなら、ログが増えた状態から始め、needs-helpのログを作成し、絞り込みで見つけます。失敗したときに備えて、スクリーンショットや確認ログも用意します。見せてはいけない情報が出そうなら、デモを止めて安全な代替証拠に切り替えます。
Slide 11. AI利用を説明する
AI利用は、使ったかどうかだけではなく、どこに使い、どう確かめたかを説明します。入力前は、secret、個人情報、本番データを入れないことを確認します。採用前は、差分、テスト、公式資料、実行結果で裏取りします。共有前やPR前には、自分の言葉で説明できるかを確認します。AIに任せなかった判断も大事です。
Slide 12. 失敗と学び
最終発表では、うまくいったことだけを話さなくて大丈夫です。詰まったこと、最初の見積もりが大きすぎたこと、削った範囲、レビューで直したことも学びになります。ただし、失敗談を長く話すだけでは弱いです。次は早めに相談する、確認ログを先に残す、AIの答えをそのまま信じない、のように次に変える行動まで話します。
Slide 13. フィードバックを受ける
最終発表は、評価されるだけの場ではなく、フィードバックを受ける場でもあります。発表前に、見てほしい観点を決めます。たとえば、技術判断、スコープの切り方、品質確認、AI利用、次の90日計画です。即答できなくても構いません。受けた内容を記録し、反映するもの、後で検討するもの、今回は採用しないものに分けます。
Slide 14. 次の90日計画
次の90日計画は、気合いを書くものではありません。配属後に何を試し、何を成果物として残すかを決めるものです。伸ばす領域を三つ以内に絞り、最初の30日、31日から60日、61日から90日に分けます。たとえば、小さな改善PRを出す、runbookを更新する、テストを一つ追加する、という形です。各行には、できたと言えるsuccess signalと、必要な支援も書きます。
Slide 15. オンボーディングへの接続
研修は終わりではなく、配属後のオンボーディングにつながります。オンボーディングは、新しいチームや業務に慣れ、貢献できるようになる過程です。研修成果物は、自己紹介、最初の相談、技術課題の共有に使えます。自分の強み、まだ弱いところ、支援が必要なことを話せると、配属後の最初の一歩が具体的になります。
Slide 16. ケース
ここからは、学習ログ整理アプリを例にします。中心メッセージは、相談が必要な学習ログを見つけやすくするWebアプリを作り、status追加とリリース前確認まで行った、です。発表では、課題とユーザー、デモ、技術判断、品質確認とPRR結果、AI利用、失敗と学び、次の90日計画の順に見せます。
Slide 17. evidence index例
evidence indexは、最終発表で使う根拠リストです。企画メモは、なぜ作ったかの根拠です。スコープ表は、どこまで作ると決めたかの根拠です。改善PRのまとめは、何を変えたかの根拠です。PRRとリリース判断は、何を確認し、どう判断したかの根拠です。core evidence、supporting evidence、missing evidence、do not showに分け、見せないものには安全な代替証拠を用意します。
Slide 18. presentation brief例
presentation briefは、発表の骨子です。中心メッセージ、聞き手、ユーザー、課題、成果、判断、品質確認、AI利用、残課題、見てほしいことを書きます。発表スライドを先に作り込むと、話を削りにくくなります。まず骨子を作ると、どの根拠を見せるか、どの話を短くするかを決めやすくなります。証拠がない話は、言わないか、未確認として扱います。
Slide 19. demo script例
demo script例では、見せる流れを一つか二つに絞ります。初期状態は、学習ログが複数あり、相談が必要なものが混ざっている状態です。操作は、needs-helpのログを作成し、statusで絞り込むこと。期待結果は、相談が必要なログだけを見つけられることです。事前に、使うデータ、見せないもの、起動コマンド、確認済みcommitをメモします。デモが失敗した場合は、スクリーンショットやsmoke test結果を代わりに見せます。
Slide 20. technical decision例
technical decision例では、status設計を説明します。statusはdraft、learned、needs-helpの三種類に絞りました。学習状態を少ない種類で表せて、入力チェックもしやすいからです。既存ログはlearned扱いにし、過去のログが一覧から消えないようにしました。自由入力は、不正な値が増えやすいため採用しなかった、と説明できます。
Slide 21. quality evidence例
quality evidence例では、PRRとリリース判断を使います。確認済みは三つです。既存ログが表示されること、新しいログにstatusを保存できること、needs-helpで絞り込めることです。不正なstatus、キーボード操作、README更新も確認したと話します。大量データ時の性能とCloudWatch Logsでの確認は、あとで追う課題にします。
Slide 22. AI use例
AI use例では、Claude CodeなどのAIをどう使ったかを説明します。たとえば、影響範囲の候補出し、テスト観点、PR説明の下書き、発表構成のレビューに使った、と分けます。検証では、検索結果、実際の差分、テスト、手動確認、PRR文書で裏取りしたと話します。採用した提案だけでなく、MVP外として採用しなかった提案も説明できると、AIに流されていないことが伝わります。
Slide 23. failure例
failure例では、削ったことと理由を話します。通知機能や権限機能は便利そうでした。ただ、研修期間ではstatus改善と回帰確認に集中するため削った、と説明します。これは弱さではありません。削った理由と、future work、つまり今後の課題を話せれば、仕事としての判断になります。失敗や迷いは、次に変える行動とセットで話します。
Slide 24. feedback request例
feedback request例では、見てほしい観点を先に出します。たとえば、status設計に無理がないか。go with follow-upの判断でよいか。AI利用の確かめ方は足りているか。90日計画は細かすぎないか、です。聞き手は具体的にコメントしやすくなります。発表後は、受けた内容を記録し、next 90 days planに反映します。
Slide 25. 90 days plan例
90 days plan例では、30日、60日、90日に分けます。最初の30日は、配属先のプロダクトを読み、主要フローとrunbookを理解する。31日から60日は、小さな改善PRを一つ出し、テストまたは文書を更新する。61日から90日は、運用ログやユーザー影響を見ながら改善案を提案する。各期間に、成果物、success signal、相談したい相手を書きます。週次で進捗と支援が必要なことを見直します。
Slide 26. 評価観点
評価では、発表の上手さだけを見ません。ユーザー、課題、成果から話せているか。技術判断が、目的、制約、他の案、確認結果とつながっているか。デモが価値を示しているか。品質確認、AI利用、失敗や残課題を隠していないか。次の90日計画が、行動と成果物になっているかを見ます。
Slide 27. no-goの場合
第23章でno-goになった場合でも、最終発表は成立します。no-goは、重大なリスクが残るので今は出さない、という判断です。大事なのは、どのリスクが大きかったか、何を直せばgoに近づくかを説明することです。未完成を隠すより、理由と次の行動を言える方が実務に近いです。止められることも、重要な学習成果です。
Slide 28. Exercise 1
Exercise 1では、final evidence index、最終発表で使う根拠リストを作ります。第1章から第23章までの成果物を一覧にし、発表で使うものを選びます。それぞれが何の主張の根拠になるかを書きます。使わないが残しておくもの、足りないもの、見せないものも分けます。secret、実在の個人情報、本番データ、AWSアカウントID、内部URL、実ログ全文が含まれていないことも確認してください。
Slide 29. Exercise 2
Exercise 2では、final presentation brief、発表の骨子を書きます。一文の中心メッセージ、ユーザー、課題、成果、判断、品質確認、AI利用、残課題、見てほしいことをまとめます。できた機能の羅列ではなく、価値、判断、確認、学びがつながる流れにしてください。
Slide 30. Exercise 3
Exercise 3では、final demo script、デモ手順を作ります。デモで見せるユーザーフローを一つか二つに絞り、開始状態、操作、期待結果を書きます。デモが失敗した場合に見せる代替証拠も用意します。デモ後に補足する品質確認を一つ選び、見せた価値と確認結果がつながるようにします。
Slide 31. Exercise 4-5
Exercise 4では、learning reflection、学びの振り返りを書きます。うまくいったこと、詰まったこと、削った範囲、AI利用で学んだこと、次に変える行動を整理します。Exercise 5では、next 90 days planを書きます。伸ばす領域を三つ以内に絞り、30日、60日、90日の行動、成果物、success signal、支援が必要なことを書きます。週次で何を見直すかも決めます。
Slide 32. まとめ
第24章のまとめです。最終発表は、成果物のショーケースではなく、自分がどう考え、作り、確認し、学んだかを話す場です。手元の成果物を書き出し、発表で使う根拠を選びます。中心メッセージ、価値、技術判断、品質確認、AI利用、失敗と学びにつなげます。最後に、次の90日計画へ書き込みます。まずは根拠リストと発表の骨子から作り始めましょう。