第24章最終発表と次の学習計画

第24章は、成果物を見せるだけでなく、課題・判断・確認・学び・次の行動を証拠つきで説明する章である。内容は発表とふりかえりの進め方が中心で、発表の骨子や証拠の整理は本書独自の文書・課題提出物として進める。発表で扱う技術的な中身は、PRRの判断なら第23章、品質の証拠なら第13章、AI利用の検証なら第3章・第18章・第19章で解説した内容を振り返って使う。ここでは、最終発表で繰り返し使う語を解説する。

final evidence index

読み：ファイナルエビデンスインデックス／final evidence index
一言で言うと：最終発表で使う証拠、補足証拠、足りない証拠、見せないものを整理する一覧である。
くわしく：final evidence indexは、発表の主張と証拠を対応させるために作る。core evidence、supporting evidence、missing evidence、do not showを分け、source of truth、safe to show、fallbackも書く。発表資料をきれいにする前に、どの主張がどの成果物で支えられるかを確認する。
具体例：project-brief.mdはユーザーと課題の証拠、release-decision.mdはPRR判断の証拠、.envはdo not show、redact済みスクリーンショットはfallback evidenceとして扱う。
つまずきやすい点：成果物を全部見せようとして、発表の筋が散らばる。あるいは、証拠がない主張を強く言ってしまう。
関連語：core evidence（第24章）、source of truth（第20章）、fallback evidence（第24章）
テキスト本文での登場箇所：第24章「Final Evidence Indexで証拠を選ぶ」

core message

読み：コアメッセージ／core message
一言で言うと：発表全体で最も伝えたい一文である。
くわしく：core messageは、ユーザー、課題、成果、確認したことを短く結ぶ。機能名を全部入れる必要はない。中心の一文があると、デモ、技術判断、品質証拠、学びを選びやすくなる。長くなりすぎる場合は、発表で扱う範囲が広がりすぎている可能性がある。
具体例：「研修中の学習ログを整理し、相談が必要なログを見つけやすくするWebアプリを作り、status追加の改善とリリース前確認まで行った。」
つまずきやすい点：できた機能を全部並べてしまい、聞き手が何を評価すればよいか分からなくなる。
関連語：presentation brief（第24章）、Outcome（第2章）
テキスト本文での登場箇所：第24章「Core Messageを一文で決める」

presentation brief

読み：プレゼンテーションブリーフ／presentation brief
一言で言うと：発表の中心メッセージ、聞き手、価値、判断、証拠、残課題をまとめる骨子である。
くわしく：presentation briefは、スライドを作る前に話の流れを決める文書である。User、Problem、Outcome、Product Summary、Key Technical Decisions、Quality and PRR Evidence、AI Use and Verification、Risks and Follow-up、Feedback Wantedをつなぐ。強い主張には証拠を対応させ、証拠がない話は未確認やfollow-upへ弱める。
具体例：status設計、既存ログのlearned扱い、go with follow-up判断を、理由、trade-off、evidenceと一緒に並べる。
つまずきやすい点：スライドを先に作り込み、証拠のない話や成果物と矛盾する話が混ざる。
関連語：final evidence index（第24章）、technical decision（第24章）、feedback wanted（第24章）
テキスト本文での登場箇所：第24章「Final Presentation Briefで発表の骨子を作る」

fallback evidence

読み：フォールバックエビデンス／fallback evidence
一言で言うと：デモや画面表示が失敗したときに、同じ主張を支える代替証拠である。
くわしく：fallback evidenceは、スクリーンショット、smoke test結果、実行ログ、PRR文書、redact済みメモなどである。デモが失敗しても、主張を証拠で支え続けるために用意する。見せてはいけない情報が出そうなときも、安全な代替証拠へ切り替える。
具体例：ローカル環境が起動しない場合に、事前に撮ったスクリーンショットとsmoke-test-plan.mdで主要フローを説明する。
つまずきやすい点：デモが失敗したら終わりだと思い、証拠を用意しない。発表の目的は画面操作の成功だけではない。
関連語：demo script（第24章）、smoke test（第23章）、final evidence index（第24章）
テキスト本文での登場箇所：第24章「Demo Scriptは、価値を見せるための台本である」

learning reflection

読み：ラーニングリフレクション／learning reflection
一言で言うと：うまくいったこと、難しかったこと、変えた判断、次の行動を証拠つきで振り返る文書である。
くわしく：learning reflectionは感想文ではない。何が起きたか、どの判断を変えたか、何を削ったか、AI利用で何を学んだか、次に何を変えるかを、成果物や確認結果と結びつける。失敗や迷いは、次の行動へ変換して初めて実務で使える学びになる。
具体例：AIが提案した通知機能をMVP外として削り、次はacceptance criteriaと照合して採否を決める、と書く。
つまずきやすい点：「大変だった」「勉強になった」で終える。次に変える行動と証拠が必要である。
関連語：feedback wanted（第24章）、next 90 days plan（第24章）
テキスト本文での登場箇所：第24章「失敗、迷い、削った範囲を学びに変える」

next 90 days plan

読み：ネクストナインティデイズプラン／next 90 days plan
一言で言うと：配属後の最初の90日で何を読み、作り、確認し、相談するかを決める行動計画である。
くわしく：next 90 days planは、長期キャリアの理想を書く文書ではない。focus areaを三つ以内に絞り、30日、60日、90日に分けて、action、output、success signal、support neededを書く。週次で見直し、配属先の状況やフィードバックに合わせて更新する。
具体例：最初の30日に主要フローを一つ読み、product-flow-note.mdを作り、主要フローを図か箇条書きで説明できる状態をsuccess signalにする。
つまずきやすい点：「頑張る」「理解を深める」のような抽象目標で終わる。成果物と成功条件がないと、進んだか判断できない。
関連語：success signal（第24章）、support needed（第24章）、feedback to incorporate（第24章）
テキスト本文での登場箇所：第24章「Next 90 Days Planは、気合いではなく行動と成果物で書く」

success signal

読み：サクセスシグナル／success signal
一言で言うと：行動が進んだと言える小さな合図や確認条件である。
くわしく：success signalは、90日計画のactionが実際に成果へ近づいたかを見分けるために置く。厳密なKPIでなくてよいが、観察できる形にする。「主要フローを説明できる」「小さなPRを一つ出す」「runbookの改善案を書く」のように、outputや説明可能性に結びつける。
具体例：「配属先プロダクトの主要フローを読む」のsuccess signalを「主要フローを一つ、図か箇条書きでメンターへ説明できる」にする。
つまずきやすい点：行動だけを書き、できたかどうかの見分け方を書かない。
関連語：next 90 days plan（第24章）、Success Signal（第21章）
テキスト本文での登場箇所：第24章「Next 90 Days Planは、気合いではなく行動と成果物で書く」

trade-off

読み：トレードオフ（trade-off）
一言で言うと：何かを取ると別の何かを手放す、両立しにくい選択肢の間の釣り合い。
くわしく：技術判断には、たいてい良い面と代償がある。速さを取れば費用が増える、単純さを取れば柔軟性が下がる、といった関係である。良い技術説明は、選んだ案の利点だけでなく、何を手放したか（trade-off）と、なぜその釣り合いを選んだかを示す。技術名を並べるより、理由とtrade-offで語るほうが、聞き手は判断の妥当性を評価できる。
具体例：支援ステータス機能で「未提出者フィルタをAPI側で処理する」案を選んだ理由を、「画面側より実装は増えるが、担当外アクセスの認可を一箇所で守れる」とtrade-offつきで説明する。
つまずきやすい点：採用案の利点だけを話し、手放したものを言わない。trade-offを示さない説明は、検討が浅く見える。
関連語：ADR（第20章）、MoSCoW（第2章）、Output / Outcome（第2章）
テキスト本文での登場箇所：第24章「技術判断は、技術名ではなく理由とtrade-offで説明する」

第24章 最終発表と次の学習計画