📖 テーマ設定
🔊 音声設定
1.2
1.0
1.0
▶️ 再生コントロール
🎵 BGM設定
0.3
🔔 効果音設定
0.3

朝会〜実装最終日の計画

概要

  • 日程: Day 17 / セッション 1
  • 時間: [9:30-9:40]
  • 形式: 演習
  • ゴール: 実装完了の判断基準(何ができていればDoneか)をチームで合意できる
  • 学習形式: グループワーク
  • 本日のテーマ: 新機能の追加を凍結し、仕上げと安定化に集中する実装最終日

進め方(10分)

いよいよ実装最終日です。今日の朝会は、いつもと違う宣言から始めます。

「今日から新機能の追加は原則禁止」

ソフトウェア開発の世界では、これをフィーチャーフリーズ(機能凍結)と呼びます。残りの時間はすべて、いまある機能を確実に動く状態に仕上げることに使います。

時間 内容
4分 「実装完了」の判断基準(Doneの定義)をチームで合意
3分 1人1分で本日の予定を共有
3分 昨日決めた優先順位の最終確認と、通し確認の時間の予約

「Doneの定義」の決め方

「何ができていれば実装完了か」を、観測できる文で合意します。例を挙げます。

  • 画面遷移図の最初から最後まで、エラーなく通しで操作できる
  • デモ導線上の不具合がゼロである
  • デモ用のデータが投入されている
  • 作った本人以外が操作しても詰まらない

逆に、次のような基準は該当しません。「だいたい動く」「みんなが満足する」——観測できないため、完了かどうか判定できないからです。

flowchart LR A["観測できる文""uot;"] --|OK|--> B["Doneの定義"]の定義"] C["主観的な文"] -- "NG" --> D["合意不能"]

仕上げと新機能の線引き

凍結対象を明文化しておきます。

区分 OK(仕上げ) NG(凍結対象)
文言 ボタン名・メッセージの修正 -
表示 配置・色の微調整 新しい画面の追加
入力 エラーメッセージの改善 新しい入力項目の追加
処理 既存のバグ修正 新しい処理の追加
データ デモ用データの投入 -

AIへの相談例です。

  • 「私たちの製品のDoneの定義の案を貼る。曖昧で判定できない表現がないかチェックして」
  • 「残り2時間30分で不具合修正と通し確認を両立する時間割を提案して」

ここがポイント

  • 「新機能を足したい」誘惑は必ず来る。提案自体は禁止しないが、合意のハードルは最大に。原則は「明日からの発表準備で語る」
  • 通し確認の時間(最低30分)を先に予約する。修正作業は予約地を侵食しがち
  • Doneの定義は終会で「実装完了宣言」のチェックリストになる

まとめ

Doneの定義は合意できましたか。終会でこの基準と突き合わせて「実装完了」を宣言します。9:40から最後のスプリントです。

🔄 振り返りチェック

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

  • チームで合意した「Doneの定義」を諳んじて言えるか
  • なぜ最終日に新機能を追加してはいけないのか、デグレードという言葉を使って説明できるか
  • 通し確認の時間を何分予約したか言えるか

答えに自信がない場合は、スプリント開始前にチームで読み合わせましょう。

学習ガイド

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

想定される質問と回答例

質問 ヒント
どうしても入れたい機能が残っている 「それがないとデモが成立しないか」で判定する。成立するなら凍結対象。発表で「今後の拡張」として語る方が安全に価値を伝えられる
Doneの定義が厳しすぎて達成できなそう 基準を下げるのではなく範囲を絞る。「全画面」を「デモ導線上の画面」に絞るのは健全な調整
文言修正は本当にOK? テキストの変更だけならデグレードはほぼ起きない。表示が崩れないか1度確認すれば十分
Doneの定義はいくつ書けばいい? 3〜5項目が現実的。多すぎると確認しきれず、少なすぎると判定基準として弱い

つまずきやすいポイント

つまずきポイント ヒント
「ついでの改善」で新機能が紛れ込む 文言修正・表示調整はOK、新しい画面・項目・処理の追加はNG、と線引きを朝会で明文化する
Doneの定義を決めずに作業を始める 基準がないと終会で「完了宣言」ができない。最初の4分を必ずこれに使う
通し確認の時間を予約せず、修正に全時間を使う 修正作業は膨張する。「11:50から通し確認」のように時刻で予約する
主観的な定義(「いい感じ」「みんな満足」)にしてしまう 観測可能な動詞(「操作できる」「表示される」「ゼロである」)で書き直す
読み上げを開始します...

AIに質問する