実装スプリント6〜最終仕上げと動作確認

• 日程: Day 17 / セッション 2
• 時間: [9:40-12:20]（途中休憩11:00-11:10を含む）
• 形式: 実習
• ゴール: 画面遷移図の最初から最後までを通しで操作し、エラーなく動作する状態に仕上げられる
• 学習形式: ハンズオン実習、相互レビュー

実装最終スプリントです。Day 10のプロトタイプから数えて8日間、作り続けてきた製品を、今日「発表で動かせる状態」に仕上げます。

ここで考えてみてください。
マラソンの最終コーナーで、新しいフォームを試すランナーはいるでしょうか？

いませんよね。最終盤でやることは、いつものフォームでゴールまで走り切ることです。開発も同じで、最終日に新しい挑戦（新機能）をすると、ゴール直前で転びます。

今日のテーマは3つです。

• 新機能の追加を凍結し、仕上げに徹する
• 最初から最後までの「通し」で動作確認する
• 発表当日の環境を想定して備える

朝会で宣言した通り、今日は**フィーチャーフリーズ（機能凍結）**です。新しい機能は追加せず、いまあるものの完成度を上げます。

これは料理の盛り付けに例えられます。お客様に出す直前は、新しい食材を鍋に足す時間ではありません。味を最終確認し、皿を温め、盛り付けを整える時間です。ここで「やっぱりもう一品」と揚げ物を始めたら、全部が冷めます。

何が凍結対象かを線引きしましょう。

• 「ボタンの文言を分かりやすく直す」「デモ用データを整える」「エラーメッセージを丁寧にする」は仕上げに該当します。既存の体験を磨く作業だからです
• 「新しい画面を1枚足す」「入力項目を増やす」「新しい処理を追加する」は仕上げに該当しません。新たなテスト範囲とデグレードの危険を持ち込むからです

ここで自分のかんばんを見てください。
Todoに残っているカードの中に、こっそり「新機能」が混ざっていませんか？

混ざっていたら、いますぐ「対応しない」置き場へ。それは明日からの発表準備で「今後の拡張」として輝く材料です。

凍結後の作業を仕分けた例です。

やる（仕上げ）
- デモ導線上の不具合 2件の修正
- 一覧画面のボタン文言の変更（昨日のなりきり操作の指摘）
- デモ用データの投入（ペルソナの名前で登録しておく）
- エラー画面のメッセージを優しい日本語に変更

やらない（凍結）
- お気に入り機能の追加 → 発表で「今後の拡張」として紹介
- 管理者画面の新設 → 同上
- ソート機能の追加 → 同上

• 凍結は「妥協」ではなく「品質戦略」。変更を減らすことがデグレードを減らす唯一確実な方法
• 文言・見た目・データの整備は凍結対象外。むしろ発表映えに直結する仕上げの主役
• よくある間違い: 「小さい機能だから大丈夫」と例外を作る。小さい変更でも壊れるときは派手に壊れる

フィーチャーフリーズは世界中の開発現場の公式行事です。OSのLinuxカーネルでは、新機能を取り込める「マージウィンドウ」は最初の2週間だけ。残りの約7週間はひたすら修正と安定化に充てられます。OSのDebianに至っては、リリース前のフリーズ期間が数か月に及ぶことも。何千人もの凄腕開発者たちでさえ「新しいものを足しながら品質を上げることはできない」と認めて、わざわざ「足すのを禁止する期間」を制度にしているのです。みなさんの「最終日は凍結」は、世界標準の縮小版というわけです。

仕上げの中心は通し動作確認です。画面遷移図の最初の画面から最後の画面まで、ユーザの一連の流れを途切れずに操作します。

昨日のテストとの違いを整理します。

• 昨日: 機能ごとに切り分けて確認した（部品検査）
• 今日: 最初から最後まで一続きに確認する（完成車の試走）

部品が全部合格でも、組み合わせると問題が出ることがあります。「登録した直後のデータが一覧に反映されない」「画面Aで入れた値が画面Cで消えている」——これらは通しでしか見つかりません。

そして鉄則がもう1つ。通し確認は実装した本人以外が行うことです。

ここで考えてみてください。
なぜ、作った本人だと確認にならないのでしょうか？

本人は無意識に「動く道」を選ぶからです。入力する値も、ボタンを押す順番も、体が正解を覚えています。初見の目こそが、発表会の聴衆の目にいちばん近いのです。

通し確認のシナリオは、CJM（To-Be版）と画面遷移図から作れます。

通しシナリオ例（ペルソナ: 田中さん・32歳）
1. トップ画面を開く
2. 新規登録する（田中さんのプロフィールで）
3. ログインする
4. 目的の情報を検索する
5. 予約（登録）を実行する
6. 完了を確認し、マイページで内容を見る
7. ログアウトする
担当: この機能群を作っていないメンバー
制限: 実装者は口出し禁止（メモのみ）

AIへの相談例です。

• 「画面遷移図とCJM（To-Be版）を貼る。通し動作確認のシナリオを手順書形式で作って」
• 「通し確認で『画面Aの入力値が画面Cで消える』問題が出た。原因として考えられる箇所の候補を挙げて」

• 実装者は隣で見ていてよいが、口出し禁止。「あ、そこはこう操作して」と言いたくなった場所こそ直すべき場所
• 通し確認は最低2周。1周目で見つけて直し、2周目で「直した状態で最初から最後まで」を確認する
• 修正後にいきなり最終通しをしない。修正→デグレード確認→通し、の順番を守る

2007年、スティーブ・ジョブズが初代iPhoneを発表したときの逸話です。実はあの伝説のデモの裏で、試作機はメモリ不足やネットワークの問題で頻繁にクラッシュしていました。エンジニアたちは、クラッシュせずに最後まで通る操作の道順を必死に探し出し、ジョブズはその「ゴールデンパス（黄金の道）」だけを、順番まで厳密に守ってリハーサルを重ねたといいます。本番のデモは完璧に成功し、世界が変わりました。みなさんが今日やる通し確認は、まさに自分たちの製品のゴールデンパス探しです。あのiPhoneですらそうだったのですから、堂々と「確実に通る道」を磨きましょう。

製品が完璧でも、当日の環境で動かなければデモは失敗します。仕上げの最後のピースは環境の想定です。

遠足の前日に天気予報を見て雨具を準備するのと同じです。当日の朝に空を見てから慌てても、傘は買えません。

確認しておく観点は次の通りです。

AIへの相談例です。

• 「明日から発表準備に入る。Webアプリのデモを会場のプロジェクタで行う場合の、環境起因のトラブルとその予防策を一覧にして」
• 「デモ用データとして登録しておくべきデータの観点（件数・内容・名前のリアリティ）を提案して」

• デモ用データは製品の一部。ペルソナの名前・現実的な内容で登録しておくと、発表の説得力が一段上がる
• 「動く環境」を今日確定させ、明日以降はその環境を変えない。環境変更は実質的に凍結破りと同じ
• 代替手段（録画・スクリーンショット）の準備はDay 20のリハーサルでも行う。今日は「最悪でも見せられる素材」を残す意識で十分

環境トラブルの最も有名な犠牲者は、おそらくビル・ゲイツです。1998年、Windows 98の発表イベントで、ステージ上でスキャナを接続した瞬間、世界中のメディアの前で画面が真っ青なエラー画面（ブルースクリーン）になりました。ゲイツは「これがまだ製品版を出していない理由ですね」と切り返し、会場は爆笑。デモの失敗を一言のユーモアで切り抜けた例として語り継がれています。教訓は2つ。デモの神様は最高の舞台ほど意地悪をすること、そして万一のときに備えて「切り返しの一言」と「代替手段」を持っておくことです。

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

• 「フィーチャーフリーズとコードフリーズは違うもの？」
• 「通し確認で問題が出たとき、直すか・回避するかの判断基準は？」
• 「実務では実装完了をどうやって判定しているの？『Doneの定義』についてもっと教えて」

朝会で合意した「Doneの定義」を満たす状態に製品を仕上げます。

1. 残修正（9:40-10:40）: 昨日の優先順位リストに従い、デモ導線上の不具合から修正する。修正ごとにデグレード確認を行う
2. 通し確認1周目（10:40-11:00）: 実装した本人以外が、通しシナリオに沿って最初から最後まで操作する。問題と「迷い」を記録する
3. 休憩（11:00-11:10）
4. 最終修正（11:10-11:50）: 1周目で見つかった問題のうち、デモに影響するものを修正する。デモ用データもここで整える
5. 通し確認2周目（11:50-12:20）: 直した状態で再度、最初から最後まで通す。発表に使う端末・想定環境で行い、エラーなく完走することを確認する

• 完成した製品（画面遷移図の最初から最後までエラーなく通しで動作するもの）
• 通し確認の記録（シナリオと結果、2周分）
• 整備済みのデモ用データ
• 完了状態に向けて更新されたかんばん

• 通し確認中に新しい改善アイデアが浮かんでも、今日は実装しないこと。メモして発表の「今後の拡張」の材料にしましょう
• 修正が11:50までに終わらない場合は「直す」から「隠す・避ける」に切り替えましょう。導線から外せばデモは守れます
• 環境起因で動かないときは、AIに「開発環境では動くが、別の端末で〜というエラーが出る」と状況を貼って相談しましょう
• 2周目の通しで新たな問題が出たら、デモへの影響度を冷静に判断。影響しないなら「既知の問題」として記録だけ残すのも正解です

今回学んだことを一言でまとめると、**「最終日は足さずに磨く。通しで確かめ、環境ごと仕上げる」**です。

• フィーチャーフリーズは品質を上げる世界標準の戦略
• 通し確認は「作った本人以外」が「最初から最後まで」行う
• デモは製品＋データ＋環境のセットで完成する

このあとの終会で、いよいよ実装完了を宣言します。明日からは「作る」フェーズから「伝える」フェーズへ。8日間かけて作った製品の価値を、ペルソナの物語とともに世に出す準備が始まります。

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

• フィーチャーフリーズの目的を、デグレードという言葉を使って説明できるか
• 通し動作確認を「作った本人以外」が行う理由を説明できるか
• 自チームの製品の「ゴールデンパス」（確実に通るデモの道順）を口頭で再現できるか

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

• 参考リンク: 自チームで使っている実行環境（公開先）の公式ドキュメント
• 発展課題: 「実務のリリース判定会議では何をチェックするのか」をAIに聞き、今日のDoneの定義と比べてみましょう

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