Skip to main content

スクラムイベント

AppProjectプロジェクトでは、2週間を1サイクルとしたスプリントを実施します。スプリントでは、以下の5つのスクラムイベントを定期的に開催します。

スプリントの概要​

期間​

  • 固定期間: 2週間（10営業日）
  • 開始: 木曜日
  • 終了: 翌々週の水曜日

基本原則​

  • スプリント期間中は、コミットした目標の達成に集中する
  • 品質を犠牲にしない（テストなしのリリースは行わない）
  • 緊急の変更が必要な場合は、POと協議の上で対応を決定
  • 各スプリントで動作するインクリメントを提供する

スクラムイベントの分類​

AppProjectプロジェクトでは、以下の5つのスクラムイベントを実施します。これらはスプリント内のイベントとスプリント外のイベントに分類されます。

スプリント内のイベント（4つ）​

  1. デイリースクラム: 平日毎日実施。進捗を共有し課題を早期発見
  2. スプリントレビュー: スプリント終了日（水曜日）に実施。完成した成果をデモ
  3. スプリントプランニング: スプリント開始日（木曜日）に実施。作業を計画しスプリント開始を宣言
  4. スプリントレトロスペクティブ: スプリントレビュー後に実施。活動の振り返り

スプリント外のイベント（1つ）​

  1. スプリントリファインメント: スプリント期間外に実施。次スプリント以降のバックログを詳細化

1. デイリースクラム​

平日毎日、進捗を共有し課題を早期に発見するための短いミーティングです。

開催頻度​

  • 頻度: 平日毎日（月〜金）
  • 時間: 毎朝10:00（固定）
  • タイムボックス: 15分

目的​

  • スプリントゴールに向けた進捗の可視化
  • 障害の早期発見と解決
  • チーム間の連携強化

使用ツール​

  • Figjam: カンバンボードと作業報告に使用
  • Linear: 詳細なタスク管理（参照用）

2段階の構成​

デイリースクラムは以下の2つのフェーズで実施します：

フェーズ1: カンバンボードの確認（5分）​

Figjamのカンバンボードを見ながら、タスクの全体ステータスを確認します。

カンバンボードの構成​

カンバンボードは以下の4つのステータスで管理します：

  1. To Do: 未着手のタスク
  2. In Progress: 作業中のタスク
  3. In Review: レビュー待ち・レビュー中のタスク
  4. Done: 完了したタスク
タスクの分割とカテゴリ分け​

カンバンボードでは、以下のようにタスクを分割・分類します：

プロジェクトや優先度別のセクション

  • High/Middleステッカー: 優先度が高い・中程度のタスクをまとめたセクション
  • 設計/BE/インフラ: 機能や担当領域別にセクションを分けて管理

タスクの粒度

  • 1日〜数日で完了する単位でタスクを作成
  • 大きすぎるタスクは小さく分割する
  • 各タスクは具体的な成果物や完了条件が明確であること

ステッカー（付箋）の使い方

  • 各タスクをステッカー（付箋）として表現
  • ステッカーの色でカテゴリを識別：
    • 黄色: 通常の開発タスク
    • 青色: 設計・BE関連タスク
    • 赤/ピンク: インフラ・緊急タスク
    • グレー: 完了または保留中のタスク
  • 担当者のアイコンをステッカーに配置して責任を明確化
  • 複数人で作業する場合は複数のアイコンを配置
カンバンボードの確認内容​

デイリースクラムでは以下を確認します：

  • 全体の進捗: Doneカラムにどれだけタスクが移動したか
  • 作業中のタスク: In Progressにあるタスクとその担当者
  • レビュー待ち: In Reviewにあるタスクとレビュアー
  • ボトルネック: 同じステータスに長く留まっているタスク
  • To Doの状況: 次に着手すべきタスクの優先順位

ステータス管理のベストプラクティス

  • タスクは必ず誰かにアサインされている状態にする
  • In Progressのタスクは1人あたり1〜2個に絞る（並行作業を減らす）
  • In Reviewで長く停滞しているタスクは優先的にレビューする
  • Doneに移動したタスクは定期的にアーカイブして見やすくする

フェーズ2: 作業内容の報告（10分）​

Figjam上で各メンバーが付箋を使って日々の作業内容を報告します。

報告の4つのカテゴリ​

各メンバーは以下の4つのカテゴリで報告を行います：

  1. ✅ やりしたこと（緑色の付箋）

    • 昨日完了したタスク
    • 達成した成果
    • 完了した作業の詳細
    • 例: 「〇〇機能のUIデザイン完成」「△△のコードレビュー完了」

  2. 🚀 今日すること（青色の付箋）

    • 今日着手するタスク
    • 目標とする進捗
    • 予定している作業
    • 例: 「〇〇APIの実装開始」「△△のテストケース作成」

  3. 🛑 困っていること（赤/ピンク色の付箋）

    • 進捗を妨げている問題
    • 技術的な課題やブロッカー
    • 判断に迷っていること
    • リソース不足や依存関係の問題
    • 例: 「〇〇のAPI仕様が不明確」「△△の実装方法で悩んでいる」

  4. 💡 アクションプラン（黄色の付箋）

    • 困っていることに対する解決策や次のステップ
    • 今後の方針や計画
    • チームで決定したこと
    • 例: 「POに仕様確認する」「XXさんに技術相談する」
相談・依頼と共有​

報告エリアの下部には以下のセクションを設けます：

相談・依頼セクション

  • 他のメンバーに助けを求めたいこと
  • レビュー依頼
  • 技術的なアドバイスが欲しいこと
  • リソースの調整や協力依頼
  • 例: 「〇〇のコードレビューをお願いします」「△△の実装について相談に乗ってください」

共有セクション

  • チーム全体に知らせたい情報
  • 学びや気づき
  • ツールやライブラリの情報
  • ドキュメントの更新
  • 例: 「〇〇のライブラリが便利でした」「△△の仕様が変更されました」
効果的な相談の提示方法​

「困っていること」や「相談・依頼」を活用する際のポイント：

  1. 具体的に記述する

    • 悪い例: 「実装がうまくいかない」
    • 良い例: 「〇〇APIのレスポンスパースでエラーが発生。JSONの構造が想定と異なる可能性」

  2. すでに試したことを共有する

    • どこまで調査したか
    • どんな解決策を試したか
    • 何が分かっていて、何が分かっていないか

  3. 求める支援を明確にする

    • 悪い例: 「助けてください」
    • 良い例: 「実装方法について30分ほど相談時間をいただけますか？」

  4. 緊急度を示す

    • 今日中に解決が必要か
    • 来週までに解決すればよいか
    • スプリントゴールに影響するか

  5. アクションプランと連動させる

    • 「困っていること」に対して必ず「アクションプラン」を記載
    • 誰に、いつまでに、何を相談するかを明確にする

実施方法​

対面の場合​

  • 場所: 開発エリア（大画面にFigjamボードを表示）
  • 形式: 立ったまま実施（座らない）
  • 準備: 事前にFigjamボードを開いておく

リモートの場合​

  • ツール: Zoom / Google Meet
  • カメラ: 原則ONで参加
  • 画面共有: Figjamボードを共有
  • 準備: 各自が事前に付箋を準備しておくと時間短縮になる

Figjamボードの準備​

デイリースクラム開始前に以下を準備しておくことを推奨：

  • 前日のタスクステータスを最新に更新
  • 完了したタスクをDoneに移動
  • 新しいタスクがあればTo Doに追加
  • 「やりしたこと」の付箋を作成（前日の成果）
  • 「今日すること」の付箋を作成（本日の予定）

ルール​

  • タイムボックス厳守: 15分を超えない
  • 詳細な議論は避ける: 複雑な議論は別途時間を設定
  • 全員参加: 欠席の場合は事前に連絡し、Figjam上で共有
  • 進捗の透明性: 問題は隠さず共有する
  • 付箋は簡潔に: 1つの付箋は1〜2文程度にまとめる
  • 色分けを守る: 各カテゴリの色ルールに従う

フォローアップ​

  • ブロッカーは即座に対応: 困っていることに対してすぐにアクションを起こす
  • 別途ミーティング設定: 複雑な議論は関係者のみで別途時間を設ける
  • 相談・依頼の実行: デイリー後すぐに相談依頼を実行に移す
  • Figjamボードの更新: デイリー後にカンバンボードを最新状態に保つ
  • アクションプランの追跡: 次回のデイリーでアクションの進捗を確認

2. スプリントレビュー​

スプリント最終日に実施します。このスプリントでの活動をPOやクライアントに報告し、スプリントの活動を終了する儀式です。

目的​

  • スプリントの活動をPOやクライアントに説明
  • Linearのカンバンボードをベースに成果を報告
  • 開発成果とデザイン成果のデモンストレーション
  • スプリントの活動終了を宣言する儀式

参加者​

  • プロダクトオーナー（必須）
  • 開発チーム全員（必須）
  • クライアント（招待）
  • ステークホルダー（招待）

アジェンダ​

1. カンバンボードベースの成果報告（15分）​

Linearのカンバンボードを表示しながら、スプリントでの活動を報告します。

  • 完了したイシュー: 今回のスプリントで完了したタスクとゴール
  • 進行中のイシュー: 継続中のタスクと次スプリントへの引き継ぎ
  • スプリントゴールの達成状況: 当初の目標に対する達成度

2. 開発成果のデモンストレーション（30分）​

プロジェクト開発の成果を実際にデモします。

  • 機能デモ:

    • シミュレーター（iOS Simulator / Android Emulator）を使った動作確認
    • 実機での動作デモ（該当する場合）
    • 新機能の操作フローの説明

  • 機能の特徴:

    • 実装した機能の特徴や利点
    • 技術的なアプローチの説明
    • ユーザー体験の改善ポイント

  • 苦労したこと:

    • 実装中に直面した課題
    • 解決方法やアプローチ
    • 学びや改善点

3. デザイン成果の報告（15分）​

デザインタスクの成果を報告します。

  • 仕様整理:

    • デザインにおける要件や仕様の整理結果
    • ユーザーフローやインタラクションの設計
    • デザインシステムやガイドラインの更新

  • デザイン成果物のデモ:

    • UI/UXデザインのプレゼンテーション
    • プロトタイプのデモ
    • デザインの意図や考慮したポイントの説明

4. 質疑応答とフィードバック（10分）​

  • POやクライアントからの質問に回答
  • フィードバックや改善提案の収集

タイムボックス​

  • 所要時間: 1.5時間（70分）
  • 開催時間: スプリント最終日（水曜日）の午後

成果物​

  • スプリント活動報告（Linearのカンバンボードのスナップショット）
  • デモ資料（動画や画面キャプチャ）
  • デザイン成果物（Figmaリンク、プロトタイプなど）
  • フィードバックリスト
  • 次スプリントへのインプット

スプリント終了の儀式​

スプリントレビューの最後に、このスプリントの活動が正式に終了したことを宣言します。

  • チームメンバーの努力と成果を称賛
  • スプリントで達成したことを確認
  • 次のスプリントに向けた準備を確認
  • スプリントの区切りとしてクロージング

3. スプリントプランニング​

スプリント開始日に実施します。次のスプリントで対応する作業内容とスプリントゴールを明確にし、スプリント開始の儀式となります。

目的​

  • 次スプリントで対応するイシューの共有
  • 各案件の背景と目的の説明
  • スプリントゴールの明確化
  • スプリント開始の儀式

事前準備​

Linearで次のスプリントに含まれるイシューを準備します。

  • ステータス: NextSprint でイシューを配置
  • プロジェクトベース: プロジェクトごとにイシューを整理
  • 対象: 開発タスク、デザインタスク、リリース作業など

参加者​

  • PM（プロジェクトマネージャー）: ファシリテーター（必須）
  • PO（プロダクトオーナー）: 必須
  • スクラムチーム全員: 開発者、デザイナー、QA（必須）
  • 案件リード: 必要に応じて
  • ディビジョンリーダー: 必要に応じて

議題​

1. 次スプリントのイシュー確認（10分）​

PMがLinearのNextSprintステータスのイシュー一覧を表示し、全体像を共有します。

  • プロジェクトごとのイシュー数
  • 各プロジェクトの概要
  • 優先度の高いイシュー

2. 各案件・作業内容の説明（1.5時間）​

PMがファシリテートし、必要に応じて案件リードやディビジョンリーダーに説明を委ねます。

各イシューについて以下を共有：

背景と目的の説明​
  • なぜこの作業が必要か: ビジネス背景、ユーザーニーズ
  • 何を達成したいか: 期待される成果、KPI
  • 誰のためか: 対象ユーザー、ステークホルダー
要件の明確化​

要件が明確でない場合は、この場で検討・明確化します：

  • 機能要件: どのような機能が必要か
  • 非機能要件: パフォーマンス、セキュリティなど
  • 制約条件: 技術的制約、期限、リソース
  • 受け入れ基準: 完成の定義
必要な活動の確認​
  • 開発作業: 実装が必要な機能や修正
  • デザイン作業: UI/UXデザイン、仕様整理
  • リリース作業: デプロイ、テスト、ドキュメント
  • 調査・検証: 技術検証、PoC
質疑応答​

スクラムチームからの質問に回答し、不明点を解消します。

3. スプリントゴールの明確化（30分）​

全てのイシューの説明が終わった後、このスプリントで達成したいゴールを明確にします。

  • 複数のイシューから共通の目標を抽出
  • 測定可能なゴールを設定
  • チーム全員で合意形成
  • 例: "ユーザーオンボーディングの改善により新規ユーザーの継続率を20%向上させる"

タイムボックス​

  • 所要時間: 2.5時間
  • 開催時間: スプリント初日（木曜日）の午前中

成果物​

  • スプリントゴール（文書化）
  • 次スプリントで対応するイシュー一覧（Linearで管理）
  • 各イシューの背景・目的・要件の共有メモ

スプリント開始の儀式​

スプリントプランニングの最後に、スプリントの開始を宣言します。

  • スプリントゴールの最終確認
  • チーム全員のコミットメント
  • スプリント期間の再確認
  • スプリント開始の宣言

4. スプリントレトロスペクティブ​

スプリントレビュー後に実施します。そのスプリントにおける活動を振り返り、次のスプリントに向けた改善アクションを定義します。

目的​

  • スプリント活動の振り返り（うまくいったこと、改善すべきこと）
  • チームの協働方法やプロセスの改善
  • 次のスプリントに向けた具体的なアクションの合意

達成したいこと​

スプリントを通じて得られた学びを共有し、チーム全体で継続的な改善を実現します。心理的に安全な環境で率直な意見交換を行い、実行可能な改善アクションを少数に絞り込むことが重要です。

開催概要​

  • 参加者: スクラムチーム全員（必須）、プロダクトオーナー（推奨）
  • タイムボックス: 1時間
  • 開催時間: スプリントレビュー直後、またはスプリント最終日（水曜日）の夕方

※クライアントやステークホルダーは参加しない（チームが率直に話せる環境を作るため）

5. スプリントリファインメント​

スプリント期間外に実施します。次スプリント以降のバックログアイテムを詳細化し、実装可能な状態にします。

目的​

  • バックログアイテムの詳細化と明確化
  • 受け入れ基準の定義
  • 技術的な実現可能性の検討
  • 次スプリントプランニングでスムーズに着手できる状態（Ready）にする

達成したいこと​

次スプリント以降で取り組む予定のバックログアイテムについて、POと開発チームが共通理解を持つことを目指します。要件、技術的な制約、実現方法を事前に議論することで、スプリントプランニングでの意思決定を迅速化します。

開催概要​

  • 参加者: プロダクトオーナー（必須）、開発リーダー（必須）、関連する開発者、デザイナー（必要に応じて）
  • タイムボックス: 1時間
  • 推奨タイミング: スプリント期間外（水曜日終了後〜次の木曜日開始前）