朝会〜本日の作業計画
概要
- 日程: Day 16 / セッション 1
- 時間: [9:30-9:40]
- 形式: 演習
- ゴール: テスト対象と担当をチームで合意できる
- 学習形式: グループワーク
- 本日のテーマ: テストとレビューで製品の品質を高める日
進め方(10分)
今日はこれまでのスプリントと性格が違う日です。テーマは「品質」。
最初に1つ問いかけます。
「作る時間」と「確かめる時間」を分けずに進めると、何が起きるでしょうか?
作る作業はつい優先されます。気づけば一日中作り続け、確かめる時間がゼロになる。今日はそれを防ぐため、朝会の時点で時間を分けて計画します。
| 時間 | 内容 |
|---|---|
| 3分 | 昨日の終会で決めた優先順位と残タスクの確認 |
| 4分 | 1人1分で本日の予定を共有 |
| 3分 | テスト対象と担当の合意 |
テスト担当の決め方
今日の鉄則は1つです。
- 自分が作った機能は、自分でテストしない。作った本人は「正しい操作」しかしないからです
担当を決めるときは次を確認します。
- 誰がどの機能をテストするか(作った人と交差させる)
- 何を見ながらテストするか(画面遷移図・機能設計書がチェックリストになります)
- 見つけた不具合をどこに記録するか(記録先を1か所に決める)
flowchart LR
A["作った人: Aさん(機能X)"] -- "交差" --> B["テスト担当: Bさん"]
C["作った人: Bさん(機能Y)"] -- "交差" --> D["テスト担当: Cさん"]
E["作った人: Cさん(機能Z)"] -- "交差" --> F["テスト担当: Aさん"]
AIへの相談例です。
- 「メンバー3人で機能が6つある。作成者と交差するテスト分担表を作って」
- 「残タスクの完了とテストを両立したい。2時間30分の時間割の案を出して」
ここがポイント
- 「作る時間」と「確かめる時間」をスプリントの中で区切って計画する(例: 前半は残タスク、後半はテスト)
- 不具合は見つかるのが正常。今日たくさん見つかるほど、明日と発表当日が安全になる
- テストは「設計書 vs 実物」の突き合わせ。チェックリストは作らずに済む(Day5-8の設計書がそのまま使える)
まとめ
担当と時間割は決まりましたか。9:40から実装スプリント5を開始します。今日の不具合発見数は、明日の安心の貯金です。
🔄 振り返りチェック
以下の問いに答えられるか確認してみましょう:
- 自分がテストする機能と、それを誰が作ったか言えるか
- 今日の「作る時間」と「確かめる時間」の配分を説明できるか
- 自作機能を自分でテストしてはいけない理由を1文で言えるか
答えに自信がない場合は、開始前にチームで確認し直しましょう。
学習ガイド
このセクションは、受講者が理解を深めることをサポートする参考情報です。
想定される質問と回答例
| 質問 | ヒント |
|---|---|
| 残タスクが多くてテストの時間が取れない | 昨日「削る」判断をしたはず。それでも溢れるなら再度削る。テストゼロで明日を迎えるのが最悪のシナリオ |
| テストは全員でやるべき? | 残タスク担当とテスト担当に分かれてもよい。ただし全員が最低1機能はテストを経験する配分にする |
| 1人開発の場合は交差できない | 時間を空ける(午前に作り午後にテスト)、ペルソナになりきって視点を変える、AIに意地悪な操作の案を出させる、で代替する |
| 機能数が人数より多い | 1人2機能ずつなど均等に分け、相互ペアで交差させる。優先度の低い機能は午後に回す |
つまずきやすいポイント
| つまずきポイント | ヒント |
|---|---|
| 自作機能を自分でテストする分担にしてしまう | 作った人は無意識に「動く操作」を選ぶ。必ず交差させる。人数が足りなければAIに意地悪な操作の案を出させて補う |
| テストを「余った時間でやるもの」と扱う | 時間割に「確かめる時間」を先に予約する。作る作業は膨張する性質があると知っておく |
| チェックリストを作るところから始めようとして時間を浪費する | チェックリストは設計書から機械的に作れる。「画面遷移図の矢印1本=確認1項目」「機能設計書の入力チェック1ルール=確認1項目」 |