Leantimeを活用した小規模チームのアジャイル協業実践

この記事は中国語版を AI が翻訳したものです。内容に相違がある場合は中国語版を正とします。

最近、Technical Project Manager（TPM）として担当している大規模プロジェクトについて、プロジェクトマネジメント手法の振り返りを行っています。

大規模プロジェクトでは、SAFe のようなフレームワークを採用していても、開発系のサブプロジェクトに落とし込むと、現場はアジャイルで動いているケースがほとんどです。つまり、プログラムマネジメントを振り返るには、まず小規模チームの日常的な協業のあり方から見直す必要があります。

アジャイルソフトウェア開発宣言や各種の理論は、エンジニアリングチームの間ではすでに馴染み深いものです。ただ実際の現場では、どのチームも多かれ少なかれ自分たちのやり方に合わせてプラクティスを調整し、さまざまなツールを組み合わせて回しています。

私が管轄しているプログラムでも、少なからぬサブプロジェクトが実質的に「なんちゃってアジャイル、実態はウォーターフォール」という状態に陥っていました。大きなウォーターフォールを小さなウォーターフォールに分割しただけの、「スパイラル型反復管理」に近い動き方です。

そこで今回、オープンソースでセルフホスト可能な Leantime のようなツールを手がかりに、ツール設計の視点から「本当の意味でのアジャイルな協業をどう形にするか」を改めて整理してみることにしました。

具体的には、Gemini 4 Argon と壁打ちしながら、8名規模の技術チーム（PO 1名、SM兼任のTech Lead 1名、開発者 5名、QA/DevOps 1名）が2週間スプリントを回す前提で、Leantime v3.9.8 を使った実践フローを組み立てました。

議論と並行して、自宅環境にセルフホストした Leantime 上でも一連のフローを実際に動かして検証しました。一通り試してみて、現場でも十分に回る現実的な運用だと感じたため、議論と検証の内容をこの記事にまとめています。小規模チームでのアジャイル定着を模索している方の参考になれば幸いです。

まずは「ツールで何を解決したいのか」を整理する

小規模チーム向けの協業ツールを選ぶとき、機能一覧の長さはあまり重要ではありません。それよりも気をつけたいのは、「実際の作業とは切り離された、報告のためだけの記録」をメンバーに強いてしまわないかという点です。もしカードが上司への進捗報告のためだけに更新されているなら、ツールを乗り換えても問題は解決しません。

今回 Leantime を試したのは、バックログ、マイルストーン、スプリント、ふりかえりキャンバス、Wiki が1つのプロジェクト空間にまとまっており、ツール間で情報を転記する手間を減らせそうだと考えたからです。とはいえ、モジュールが揃っているだけで自動的にアジャイルが回るわけではありません。フィールドやカンバン列を設定する前に、「何を記録として残すか」「何をもって完了（Done）とするか」「予定外の事態が起きたとき誰とどう取捨選択するか」を決めておく必要があります。

プロセスの網羅性よりも大切な3つの原則

2週間1スプリント（第1週月曜開始、第2週金曜終了）のリズムで回すにあたり、まずは以下の3つの原則をチームの合意事項として置き、ふりかえり（Retrospective）を通じて実態に合わせて調整していきます。

記録は作業を前に進めるために残す

• 報告のためだけの入力項目を増やさない：カードはチームの協業を助けるためのものです。カスタムフィールドをむやみに必須化する必要はありません。工数記録（Time Tracking）も、たとえば「共通の運用サポートにどれだけ時間を取られたか」を把握したい場面などに絞って使い、メンバー全員に1日の作業時間を1時間単位で入力させるような運用は避けます。
• カードの項目は5つに絞る：実用十分なカードには、**「何をするか（Title & Description）」「誰が主担当か（Assignee）」「どこに属するか（Milestone & Sprint）」「どれくらいの規模か（Effort）」「優先度はいくつか（Priority）」**の5つがあれば足ります。
• 日々の更新は数十秒で終わらせる：ステータスの移動や一行コメントの追記は数十秒で終わるのが理想です。要件の整理にはしっかり時間をかけるべきですが、カードのメンテナンス自体が開発の集中を妨げているなら、項目やルールが多すぎないか見直します。

着手数を増やすより、最後まで完了させることを優先する

• 会議は「進捗の順番報告」ではなく「詰まりの解消」に使う：デイリースクラムを1人ずつの業務報告にする必要はありません。カンバンを一緒に見ながら「どのカードが止まっているか、今日どうすれば右の列へ進められるか」を話す場にします。タイムボックスを守り、込み入った技術議論は関係メンバーだけで会の直後に続けます。
• 完了の基準はエンドツーエンドの Done に置く：サブタスクが消化された段階や、コードが書き終わった段階では完了とみなせません。親カードがチーム共通の DoD（完了の定義）を満たして初めて Done に移します。また、本当にビジネス価値を生んだかどうかはリリース後の利用状況やフィードバックで検証すべきものであり、「デモができる状態」を品質ゲートの代わりにしないよう注意します。
• ブロッカーはその場で可視化する：技術的な詰まりや仕様の曖昧さにぶつかったら、Leantime のカードタイトル先頭に 【🔴ブロック】 を付け、コメント欄で関係者に @メンション を飛ばします。金曜日の終業間際になって遅延が発覚するのではなく、日々のフローの中で問題を潰します。

議論はチャットでいいが、結論はカードかWikiに戻す

• 作業のトレーサビリティを保つ：機能追加、技術的負債の解消、バグ修正はいずれもカード（または共通サポート用の親カード）に紐づけます。ただし本番障害が起きたときは復旧が最優先であり、カード起票は事後で構いません。2時間未満の細かな問い合わせ対応も処理後にまとめて記録し、起票のために初動を遅らせないようにします。
• 決まった結論は必ずカードへ書き戻す：チャットツールは素早いやり取りに便利ですが、合意した受入基準（AC）の変更やAPI仕様、エッジケースの扱いは、必ずカードの Description やコメント、あるいは Leantime Wiki に書き戻します。後から作業を引き継いだ人がチャットログを遡って仕様を継ぎ接ぎしなくて済む状態を作ります。
• 情報を相互リンクで繋ぐ：マイルストーン、バックログ、スプリント、ふりかえりキャンバス、Wiki を同じプロジェクト空間に置き、リンクで文脈を繋ぎます。同じツールに置くだけで情報が整理されるわけではないため、リンク付けと更新の習慣はチームで維持します。

用語の定義を揃え、ツールへ自然にマッピングする

ツールを使い始める前に、チーム内で言葉の意味を揃えておく方が設定作業よりも大切です。以下は、Scrum の概念を Leantime の各機能へどう対応づけるかを整理したものです。

なお、このマッピングはあくまでチーム内の運用合意であり、概念として完全に同一という意味ではありません。Product Goal はプロダクトの長期目標、Milestone は段階的なデリバリーの節目、Epic は大きな機能を束ねる一般的な整理単位（Scrum の公式作成物ではない）です。マイルストーンで段階的な目標を管理しつつも、進捗バーのパーセンテージだけで価値達成を判断しないよう気をつけます。

以下の運用では、単一のメインプロダクトワークスペースで To Do → In Progress → Testing & CR → Done の順にカードを流す前提としています。Backlog はカンバン上の列として作るのではなく、「まだスプリントが割り当てられていないアイテムの集合」として扱います。ステータス分類上、Testing & CR は未完了カテゴリに置き、Done のみを完了カテゴリにします。ブロック発生時は元の列に置いたままタイトル接頭辞とタグで状態を示し、WIP（仕掛り）上限はチーム全員で守ります。

最小限の DoD としては、「合意した AC の検証完了」「ピアレビュー完了とマージ」「自動チェックと必要な回帰テストの通過」「関連ドキュメントの同期」「リリース可能な状態であること」を含めます。リリースはスプリント終了を待たず、準備でき次第いつでも行って構いません。開発系サブタスクが完了した時点でテストへ回し、QA系サブタスクは検証完了時にチェックします（Testing & CR へ移す時点で全サブタスクにチェックが入っている必要はありません）。通常カードでは時間単位の工数入力を求めず、共通サポート用の親カードにはストーリーポイントを振らずに実働時間だけを記録して、あらかじめ確保したバッファから消化します。

Leantime v3.9.8 の標準チケット種別には task、subtask、story、bug があり、Effort の XS/S/M/L/XL は内部値 1/2/3/5/8（他に 0.5 と 13 あり）、Priority には Lowest も含まれています。コードには手を入れず、このうち使う範囲だけをチームで決めます。また、Daily Scrum は開発メンバーが Sprint Goal に向けて計画を点検・調整する場であり、SM は進行を助け、PO は必要に応じて参加します。リーダーがメンバーへ作業を割り振る場ではありません。

段階目標から日々の実行までの流れ

flowchart LR
    subgraph SG_PLAN["戦略・計画レイヤー"]
        M["Milestones マイルストーン<br/>Product Goal / Epic"]
        B["To-Dos: Backlog ビュー<br/>Product Backlog"]
    end

    subgraph SG_SPRINT["2週間スプリント実行レイヤー (Sprint コンテナ)"]
        S["Sprints 管理<br/>W1月曜 ~ W2金曜"]
        STORY["To-Do 親カード: Story/Task<br/>ユーザーストーリー / 技術タスク"]
        BUG["To-Do 親カード: Bug<br/>独立バグ修正カード"]
        SUB["Subtasks サブタスク<br/>フロント / バックエンド / 結合 / QA"]
    end

    subgraph SG_METRIC["計測・継続的改善レイヤー"]
        BURN["Sprint ダッシュボード<br/>バーンダウン & ベロシティ"]
        RETRO["Blueprints ふりかえりキャンバス<br/>スプリント改善アイテム"]
        WIKI["Wiki / Docs ナレッジ庫<br/>PRD / 設計ADR / 運用規約"]
    end

    M -->|分解・紐づけ| B
    B -->|Sprint Planningで引き込み| S
    S -->|含む| STORY
    S -->|含む| BUG
    STORY -->|タスク分解| SUB
    STORY -->|Effort ポイント集計| BURN
    BUG -->|Effort ポイント集計| BURN
    S -->|W2金曜にふりかえり| RETRO
    RETRO -->|改善候補カード化| S
    WIKI -.->|参照 / 双方向リンク| STORY

各モジュールに何を持たせるか

役割は明確にするが、協業を「承認リレー」にはしない

小規模チームでは1人が複数の役割を兼任することが珍しくありません。ここで役割を書き分けるのは、縄張りを作るためではなく、「普段その領域を誰が気にかけているか」「トレードオフを判断するとき誰と相談すべきか」をはっきりさせるためです。

PO はバックログの並び順とビジネス価値の説明、そして迅速なフィードバックを担います。Tech Lead は技術リスクに目を配り、SM を兼務する場合はみんなに代わって見積もりや範囲を決めるのではなく、流れの詰まりを取り除くことに注力します。開発者と QA は要件整理の段階から見積もり・タスク分解・検証に一緒に関わり、DevOps の環境整備やリリース作業も最後に押し込むのではなく計画に組み込みます。

Leantime 上では、各親カードに進行役となる主担当（Owner）を1名置き、サブタスクで実際の作業分担を示します。ただし「主担当がいる」ことは「その1人だけが責任を負う」という意味ではなく、コードレビューやテスト、ブロッカー解消に他のメンバーが関わらなくていい理由にもなりません。

細かい権限マトリクスを作る代わりに、次の5つの場面で「誰と何をすり合わせるか」を確認できれば十分です。

Sprint Goal が変わらない限り、作業の進め方やスコープは状況に応じて相談しながら調整できます。ここで言う「スプリント範囲のロック」とは、相談なしにこっそりタスクを増やさないという意味であり、学びや調整を禁じるものではありません。また、これらの役割分担はチームの合意であり、Leantime のシステム権限で縛る必要はありません。

着手する前に、要件を「迷わず作り始められる状態」に整える

カンバンは「今動いている作業」を見える化してくれますが、「なぜそれを作るのか」までは教えてくれません。一方では、日々の細かいチケット消化に埋もれないための段階的な目標（Milestone）が必要であり、もう一方では、作り始めてから「仕様が決まっていなくて手が止まる」事態を防ぐための事前整理が必要です。

そこで、段階的な提供目標は Milestone で束ね、具体的に何を作ってどう検証するかは Backlog のカードに書き分けます。その橋渡しをするのがバックログリファインメントであり、月曜日の Sprint Planning で初めて要件の詳細を見る状態を避けます。

Milestone で段階的なゴールを見失わないようにする

Epic → Story → Subtask という階層はよく使われますが、Scrum が公式に義務づけている構造ではありません。この規模のチームなら、Leantime の Milestone をリリース単位や大きな機能群の器として使い、その下に独立して検収できる To-Do カードを紐づけ、必要に応じて Subtask に分解する形がシンプルです。長期的な Product Goal は別途明記し、Milestone・Epic・Product Goal を同じ意味として混同しないようにします。

リリース目標から日々のタスクまでの分解イメージ

flowchart TD
    subgraph SG_STRAT["戦略・リリース層（月次 / 四半期ロードマップ）"]
        M1["Milestone 1: [v1.2.0] 統一権限・SSO認証基盤<br/>(Epic / Release Goal として利用)"]
        M2["Milestone 2: [v1.3.0] リアルタイム集計ボード＆出力エンジン<br/>(Epic / Release Goal として利用)"]
    end

    subgraph SG_DELIV["スプリント提供層（2週間 Sprint / Product Backlog）"]
        S1["To-Do (Story): 企業チャットQRログイン＆アカウント連携<br/>Sprint S21 | Effort: 5 | Priority: High"]
        S2["To-Do (Story): RBAC ロール権限管理画面<br/>Sprint S21 | Effort: 8 | Priority: High"]
        B1["To-Do (Bug): トークン更新時に稀に 401 ループが発生する<br/>Sprint S22 | Effort: 2 | Priority: Critical"]
        S3["To-Do (Story): レポート非同期生成＆CSVストリームダウンロード<br/>Sprint S22 | Effort: 5 | Priority: Medium"]
    end

    subgraph SG_EXEC["エンジニアリング実行層（デイリー粒度 0.5〜1日）"]
        T1["Subtask: [BE] DB user_oauth テーブル変更"]
        T2["Subtask: [BE] OAuth2 コールバックAPI＆JWT発行実装"]
        T3["Subtask: [FE] ログイン画面QRコンポーネント結合＆異常系処理"]
    end

    M1 --> S1
    M1 --> S2
    M1 --> B1
    M2 --> S3
    S1 --> T1
    S1 --> T2
    S1 --> T3

マイルストーンにどこまで書くか

四半期の初めや大型リリースの着手前に、PO は左メニューの Milestones から + Add Milestone で目標を作成します。

1. 命名規則（プレフィックスを揃えると見分けやすい）：
   • バージョン単位：[v1.2.0] 加盟店精算基盤リファクタリングと自動突合
   • 機能群（Epic）単位：[Q4-Epic01] マルチテナント権限基盤と監査ログ
2. 計画期間（Plan Dates）の設定：
   • 開始予定日（Start Date）と目標リリース日（End Date）を入力します。
   • 終了日をいずれかの スプリント最終日（金曜日） に合わせておくと、反復リズムとリリース判断を揃えやすくなります。
3. 色分け（Color Coding）の例：
   • 青（#1B75BB）：主要ビジネス機能リリース（Feature Release）
   • 紫（#6F42C1）：アーキテクチャ改善・基盤整備（Tech Debt / Infra Epic）
   • オレンジ/赤（#FD7E14）：法対応や対外的な必達期限がある案件（Compliance / Hard Deadline）
4. 依存関係（Depending Milestone）：
   • たとえば「v1.3 精算レポート出力」が「v1.2 精算コアエンジン」に依存する場合、Depending Milestone に v1.2 を指定しておくとガントチャート上で依存線が描かれます。

進捗バーが示すものと、示さないもの

Leantime v3.9.8 では、Milestone の進捗率は紐づいたチケットから自動計算されます。具体的には、各チケットの Effort に優先度係数（Priority ごとの重み）を掛けた値について、完了ステータスの合計点を全体で割った割合が表示されます。Effort や Priority が未設定の場合はデフォルト値が使われます。そのため、この数字は単純なカード消化枚数でも純粋なストーリーポイント消化率でもなく、ましてビジネス目標の達成度そのものでもありません。

1. 任意の To-Do カード詳細を開くか、Table View の行内で直接編集します。
2. Milestone ドロップダウンから対象のリリースを選択します。
3. 保存すると、そのチケットの Effort・Priority・ステータス種別が Milestone の表示に反映されます。進捗バーの見栄えを良くするために優先度やポイントをいじるのは本末転倒です。また、親カードとサブタスクの両方に Milestone が入っていると集計に含まれる可能性があるため、集計範囲を確認し、このパーセンテージをそのままチームのベロシティとして扱わないようにします。
4. タイムラインは対話の材料として使う：他部署やステークホルダーと状況を共有する際、Milestones -> Timeline を映せば期間や依存関係、大まかな進捗を一目で共有できますが、背景にあるリスクや計画変更の理由は言葉で補う必要があります。

DoR（着手準備完了の定義）でスプリント途中の手戻りを減らす

「CSV出力機能を作る」という一行だけでは開発を始められません。誰が使い、どの項目を出し、データ量は最大どれくらいで、失敗時にどう振る舞うのかによって実装もテストも大きく変わります。着手前にこれらをすり合わせておくのは、書類仕事を増やすためではなく、作り始めてからの手待ちや手戻りを減らすためです。

DoR（Definition of Ready）は Scrum が公式に定めるゲートではなく、チームが自分たちのために持つチェックリストです。すべての不確実性をゼロにする必要はなく、事前に答えが出ない技術課題は小さな調査タスク（Spike）として切り出します。

チケット種別に応じて調整できる DoR チェックリスト

直近のスプリントに入れる候補カードについて、以下の6点を確認します。画面変更を伴うStoryにはデザインリンクが必要ですが、バックエンドのみや基盤改善のTaskに無理やり画面モックを添付する必要はありません。

CSV出力の要望を例にした User Story テンプレート

以下は取引明細のCSV出力機能を例にした Story テンプレートです。数値基準や構成はあくまで記入例なので、実際のシステムに合わせて調整し、小さな要望では必要な項目だけを残します。Wiki のトップに置いておくと新規カード作成時にコピーして使えます。

### 1. ユーザーストーリー (User Story)

- **誰として (As a)**：[具体的なロール。例：経理担当の請求照合スタッフ / 運営管理者]
- **何をしたいか (I want)**：[主な操作。例：月度と決済チャネルで取引明細を絞り込み、CSVで一括出力したい]
- **なぜなら (So that)**：[得られる価値・解消したい課題。例：月初の手作業による請求突合を4時間から10分以内に短縮するため]

---

### 2. 背景とデザイン資料 (Context & Assets)

- **背景 / Wiki ディープリンク**：[背景の要約、または Leantime Wiki の要件仕様ページへのリンク]
- **UI / プロトタイプリンク**：[Figma 等の対象画面リンクとバージョンメモ]
- **主なビジネスルール**：
  1. 1回の出力で指定できる期間は最大92日間（3ヶ月）。超えた場合はフロントエンドで抑止して案内を表示する。
  2. 金額は小数点以下2桁固定とし、通貨記号はセル内ではなくヘッダー行に記載する。
  3. `finance:export` 権限を持つロールにのみ「CSV出力」ボタンを表示する。

---

### 3. 技術的制約とインターフェースメモ (Technical Constraints)

> _（リファインメント前または会中に Tech Lead・主担当開発者が追記）_

- **関連サービス / モジュール**：`order-service`、`report-worker`、`admin-web`
- **基本方針・制約**：
  - 1万件を超える場合は非同期出力キュー（Redis + Worker）へ回し、オブジェクトストレージ（OSS）へアップロード後にアプリ内通知でダウンロード案内を送る。
  - 検索条件は既存の `/api/v1/orders/query` の構造を流用し、非同期ジョブ登録用に `/api/v1/orders/export-tasks` を追加する。
- **外部依存 / リスク**：本番 OSS の一時出力ディレクトリに対し、7日自動削除のライフサイクル設定をリリース前にインフラ側で入れておく必要がある。

---

### 4. 受入基準 (Acceptance Criteria - AC)

> _（QA 検証および DoD 判定の共通基準）_

- [ ] **AC1（正常系・同期 / 少量データ）**：絞り込み結果が 10,000 件以下の場合、「CSV出力」押下から3秒以内にブラウザのダウンロードが開始され、ファイル名が `精算明細_YYYYMMDD_HHMM.csv` になること。
- [ ] **AC2（正常系・非同期 / 大量データ）**：絞り込み結果が 10,000 件超の場合、「レポートを生成中です。完了後に通知でお知らせします」と表示され、10万件の基準テストデータで60秒以内にバックグラウンド生成が完了すること。
- [ ] **AC3（データの正確性と文字コード）**：CSV の総行数および実収金額の合計が画面上部の集計カードと一致し、UTF-8 BOM 付きで Windows 版 Excel および WPS で文字化けせず開けること。
- [ ] **AC4（異常系・境界値）**：指定期間が92日を超える場合、または該当データが0件の場合、「CSV出力」ボタンが非活性となり、ホバー時に理由が表示されること。
- [ ] **AC5（権限とドキュメント同期）**：`finance:export` 権限のないアカウントで API を直接叩いた場合に `403 Forbidden` が返ること。また追加した設定項目が Leantime Wiki に反映されていること。

バグカードは「他の人がそのまま再現できるか」を重視する

独立したバグカード（Type = Bug）で一番大切なのは、体裁の美しさではなく、他のメンバーが見てすぐに再現し影響範囲を判断できることです。以下のテンプレートでは概要、再現手順、期待結果と実際の挙動、環境証跡の4点を押さえています（記載のIDやログはすべて架空の例です）。

### 1. 不具合概要 (Summary)

- **対象モジュール**：[例：モバイル決済画面 - クーポン割引計算]
- **深刻度 (Severity)**：[致命的 / 重大 / 中程度 / 軽微（影響範囲の広さ・深さ）]
- **修正優先度 (Priority)**：[Critical / High / Medium / Low（影響・緊急度・回避策の有無で判断し、Severity と自動的には同一視しない）]
- **関連ストーリー**：[対応する User Story の To-Do 番号またはリンク。例：#142]

---

### 2. 再現手順 (Steps to Reproduce)

1. テストアカウント `test_vip_01` でステージング環境（Staging）にログインする。
2. 商品 SKU `10086`（単価 100.00 元、数量 2 個）をカートに入れて決済画面へ進む。
3. 「200元以上で30元引きクーポン」を選択したあと、商品の数量を手動で `1` に減らす。
4. 画面下部の「支払う」ボタンを押し、画面表示と通信レスポンスを確認する。

---

### 3. 期待される結果 vs 実際の結果 (Expected vs Actual)

- **期待される結果 (Expected)**：
  - 数量を1個に減らした時点（合計100元 < 適用条件200元）でクーポンの選択が自動的に外れ、支払金額が `100.00` 元に更新されて決済画面へ進む。
- **実際の結果 (Actual)**：
  - 画面上の支払金額が `70.00` 元のまま変わらず、「支払う」を押しても画面上にエラーが出ず、コンソール上で API が `500 Internal Server Error` を返している。

---

### 4. 実行環境と証跡 (Environment & Evidence)

- **環境**：`Staging (v1.2.0-rc2)` | **クライアント**：`iOS 17.4 / WeChat 内蔵ブラウザ 8.0.48`
- **テストアカウント / データ ID**：`UserID: 99201` / `CartID: c_8839201`
- **通信ログ / エラー内容 / スクリーンショット**：
  - リクエスト URL：`POST /api/v1/checkout/submit` | TraceID：`7f8a9d10-3b2c-4e1a-9f00-123456789abc`
  - エラー抜粋：`CouponDiscountExceedsThresholdException: coupon 4021 requires min_amount 20000, actual 10000`
  - _（ここにスクリーンショットや画面録画を貼り付ける）_

要件のすり合わせは Sprint Planning の前に済ませておく

月曜日の Sprint Planning の場で初めて要件の中身を見ると、スコープ選定・仕様確認・技術検討が一度に重なり、会議が何時間あっても足りなくなります。スプリントの途中に短時間のバックログリファインメント（Backlog Grooming）を設け、次スプリント候補の疑問点を先に潰しておくことで、Planning 当日はゴールとキャパシティ、トレードオフの判断に集中できます。

確認の時間を確保しつつ、深い議論は別枠に切り出す

• 開催タイミング：各スプリントの 第2週火曜午後（15:00 - 15:45）（または第1週木曜午後）。翌週月曜の Sprint Planning まで3営業日ほど空くため、デザインの手直しや簡単な技術調査を入れるのにちょうどよい間隔です。
• 所要時間：30〜45分 を目安にします。1枚のカードで8分以上議論しても結論が出ない場合は、その場で一旦保留にし、関係メンバーだけで別途すり合わせます。
• 参加者：PO と、実際に実装・検証を担当する開発者・QA が参加し、Tech Lead が技術リスクを補足します。8名規模なら全員参加でも回りますが、特定領域の深い議論に全員を付き合わせる必要はなく、またリファインメントだけで未知の要素がすべて消えるわけでもない点は意識しておきます。

Table View を使って候補カードを効率よく整える

リファインメントでは To-Dos -> Table（テーブルビュー） を使うと、優先度の並び替えやフィールドのインライン編集がスムーズです。おおよそ次の5ステップで進めます（時間配分は目安です）。

1. ステップ1：未割当のバックログに絞り込む（1分）
   • To-Dos を Table 表示に切り替え、上部の Sprint フィルタを Backlog に設定して Priority 順に並べます。
2. ステップ2：優先度の見直しと古いカードの整理（5分）
   • PO が上位15〜20件をざっと見渡し、行内の Priority ドロップダウンで優先度（Critical \rightarrow High \rightarrow Medium \rightarrow Low）を調整します。何か月も放置されていて今後も着手予定がないカードは、その場でクローズまたはアーカイブします。
3. ステップ3：背景の共有と受入基準（AC）のすり合わせ（15〜20分）
   • 上位の未見積もりカードから順に、PO が2分ほどで背景と AC を説明し、開発者と QA が既存データとの互換性、性能面の懸念、異常系、べき等性などの観点で質問します。
   • その場でカードに書き込む：合意した境界条件や追加の AC は、PO または Tech Lead がその場でカードの Description に追記して保存します。
4. ステップ4：フィボナッチ数での見積もりと大きなカードの分割（10分）
   • 「3、2、1」の合図で、開発者と QA が一斉にフィボナッチ数（1, 2, 3, 5, 8, 13）をチャットに出すか指で示します。
   • ばらつきが小さければそのまま Effort 欄に入力し、大きく割れた場合（2 と 8 など）は最小値と最大値を出した人が30秒ずつ理由を話して再見積もりします。
   • 13 ポイント以上になったカードは、業務ステップごとに \le 8 ポイントの小ストーリーへ分割するか、先に 2 ポイント程度の技術調査カード（Spike）を切り出します。
5. ステップ5：次スプリント候補のストック量を確認する（2分）
   • Table View で DoR を満たした Ready カードを絞り込み、Effort の合計を確認します（テーブル上部で自動集計される前提は置かず、対象カードの合計を見ます）。
   • ストック量の目安：たとえばチームの過去実績が1スプリントあたり約 40 SP なら、60 SP ほど Ready な候補があると Planning で柔軟に取捨選択できます。なお 40 SP はあくまで例であり、8名チームの標準値ではありません。また数合わせのために遠い将来の要望まで無理に詳細化する必要はありません。

2週間スプリントで日々の協業をどう繋ぐか

候補カードの下準備ができたら、次はスプリント期間中に作業をどう淀みなく流すかです。ここでは Sprint 2026-S21 を例に、計画・実装・コードレビュー・テスト・ふりかえりを10営業日の流れに置いてみます。

以下のカレンダーは、毎日を分刻みで縛るためのスケジュール表ではありません。一番の目的は、「第1週は全員が黙々とコードを書き、第2週の木曜になって初めて QA に大量のカードが雪崩れ込む」というミニ・ウォーターフォール化を防ぐことにあります。

カレンダーの役割は「次の工程へ早めに渡す」意識を揃えること

第1週のうちに一部のストーリーをレビュー・テストへ回し、第2週の半ばには未提出の大きな作業が残っていないか点検するリズムをチームで共有しておきます。下の表にある「第1週木曜時点で約30%が検証に入る」「第2週水曜時点で残りの提出リスクを確認する」という目安は、あくまで流れを見るためのチェックポイントであり、比率を達成するために未完成のカードを無理やり動かすためのノルマではありません。本質的に改善したいのは、ストーリーの粒度、QA が関わるタイミング、そしてレビュー待ち時間の短縮です。

2週間スプリント（10営業日）の進行イメージ

gantt
    title 8名チーム 2週間スプリント（10営業日）リズムのイメージ
    dateFormat  YYYY-MM-DD
    axisFormat  %m-%d
    excludes weekends
    section スプリントイベント
    Sprint Planning (60分以内)        :milestone, m1, 2026-11-02, 0d
    デイリースクラム (毎日15分)       :active, d1, 2026-11-02, 10d
    次期Grooming (45分以内)           :milestone, m2, 2026-11-10, 0d
    Review ＆ Retro (60分)            :milestone, m3, 2026-11-13, 0d
    section 開発・テストの流れ
    実装・単体テスト (主力期間)       :dev1, 2026-11-02, 8d
    初回30%テスト投入目安 (W1木曜)    :crit, milestone, c1, 2026-11-05, 0d
    継続的テスト投入＆相互CR          :cr1, 2026-11-04, 7d
    機能テスト投入目安 Code Freeze (W2水曜) :crit, milestone, c2, 2026-11-11, 0d
    バグ収束＆ステージング回帰 (W2木曜) :qa1, 2026-11-12, 1d

Sprint Planning は「ゴール」と「現実的なキャパシティ」から始める

開催時間：W1月曜 09:30 - 10:30（前週火曜に Backlog Grooming が済んでいる前提で60分以内）。
進行役：Tech Lead 兼 Scrum Master（SM）。
目的：チームの現実的な稼働キャパシティを把握し、スプリントのスコープを選び、サブタスクへの分解と Sprint Goal の合意を行う。

ストーリーポイントの前に、まず使える時間を見積もる

「1人2週間＝10人日」だからといって、10日丸ごと新機能の実装に使えるわけではありません。会議、有給休暇、定常業務で時間は削られますし、開発・レビュー・テストのどこがボトルネックになるかも頭数だけでは見えません。キャパシティ計算の目的は、緻密な数字を作ることではなく、こうした制約を最初からテーブルに乗せることです。

利用可能キャパシティの計算式（例）

PO を除く7名のデリバリーメンバーについて、まず個々の稼働可能日数を見積もって合算します。

C_{\text{計画}} = \sum_{i=1}^{7} (D_i - L_i - M_i - F_i) \times (1 - B)

各項はすべて人日（Person-Days）単位です。D_i は実営業日数、L_i は予定休暇、M_i は既知の会議時間、F_i はその他の定常業務に取られる時間、そして B は突発対応や運用サポートのために残りの時間から確保するバッファ比率（まずは 15%〜20% 程度から試行）です。同じ業務を二重に差し引かないよう注意します。また、コードレビューや結合確認、テストはデリバリーそのものの活動なので、キャパシティから差し引いた上でストーリー見積もりにも乗せるような二重計上はしません。

本稿の例にある Planning、10回分のデイリースクラム、Grooming、Review、Retro を合計すると約5.25時間です。1日8時間換算なら約0.66人日であり、固定で10%と決め打ちせずチームの定例会議に合わせて計算します。

人日の制約と、過去ベロシティからのポイント予測は分けて扱う

ストーリーポイントは、完了までに必要な作業量・複雑さ・不確実性を相対的に表すものであり、「1ポイント＝何人日」と固定換算するものでも、個人別のノルマとして割り振るものでもありません。立ち上げ初期は、Ready になった少数のストーリーを選び、サブタスクへ分解した上で開発・CR・QA の時間と並列数に無理がないかを確認します。最初に決めたポイント上限まで無理やりカードを詰め込む必要はありません。

同条件で比較できるスプリントを3回以上回した後は、直近で DoD を満たした親カードのポイント平均を予測の参考にできます。

V_{\text{参考}} = V_{\text{直近3回平均}} \times \frac{C_{\text{今回}}}{C_{\text{直近3回平均}}}

分子と分母には同じ控除基準を使います。過去の実績値にすでにバッファ分が含まれているなら、今回の予測値にさらに 80%〜85% を掛けて二重に割り引く必要はありません。また、これはあくまで目安であり、特定メンバーの不在や QA のボトルネックは個別に確認します。1/2/3/5/8 の各ポイントは過去の基準カード（Anchor Story）との横比較で決め、8 ポイントを1枚の上限目安とします。

候補ストーリーを実行計画に落とし込む4つのステップ

ステップ1：Sprint を作成し、共通サポート用の親カードを置く（09:30 - 09:35、5分）

1. 担当：Tech Lead / SM。
2. 手順：対象プロジェクトを開く \rightarrow 上部ナビゲーション To-Dos \rightarrow 左上の Sprint ドロップダウン \rightarrow + Add Sprint / Manage Sprints。
3. 名称と期間：
   • Sprint 名：Sprint YYYY-S番号 (MM.DD-MM.DD) 形式（例：Sprint 2026-S21 (11.02-11.13)）。
   • Start Date：2026-11-02（W1月曜）、End Date：2026-11-13（W2金曜）。
4. 共通サポート用カードの作成：このスプリント内に [Sprint-S21] 本番調査・日常運用サポート受け皿（後述）を作成し、今週の当番エンジニア（Batman）を割り当てます。

ステップ2：テーブルビューで優先度の高い Story をスプリントへ入れる（09:35 - 09:50、15分）

1. ビュー切替：To-Dos 右上で Table / List View に切り替え、Sprint フィルタを Backlog にします。
2. DoR の最終確認：PO が優先度順（Critical \rightarrow High \rightarrow Medium）にカードを上から確認し、前回金曜日のふりかえりから上がった [Retro改善] 候補カードも含めて DoR を満たしているか見ます。
3. スプリントへの割り当て：
   • 対象行の Sprint 列を Backlog から Sprint 2026-S21 (11.02-11.13) に変更します。
   • 1枚入れるごとに、Effort の合計・依存関係・開発とQAのバランスを確認し、チームの予測レンジに近づいたところで止めます（40 SP という数字はあくまで例です）。なお Sprint Goal の叩き台はストーリーを選ぶ前に提示し、最後のステップで全員で確定します。

ステップ3：親カードの主担当を決め、Subtasks に分解する（09:50 - 10:20、30分）

親カードは「何を届けるか」を示し、サブタスクは「そのために何が必要か」を見えるようにします。サブタスク分解の目的は、依存関係や受け渡しを事前に把握することであり、細かいコーディング手順をすべてチケット化することではありません。

1. 親カードの主担当（Story Owner）を決める：
   • Sprint 2026-S21 のボードまたはリストに戻ります。
   • 各 Story 親カードの Assigned To には 1名の主担当開発者（Story Owner） を設定します。フロントとバックエンドにまたがるストーリーでも、結合からテスト投入までの進行役を1人決めておくことで「全員担当＝誰も見ない」状態を防ぎます。
2. Subtasks への分解（0.5〜1日粒度を目安）：
   • 各自が担当 Story のモーダルを開き、Subtasks タブに切り替えます。
   • 完了までに必要な フロント実装、バックエンドAPI、FE/BE結合、DB変更、QAテスト設計・実施 をサブタスクとして書き出します。

• 粒度の目安：半日から1日（4〜8時間）で区切れる協業単位を目安にすると、通常の Story 1枚あたり3〜6個のサブタスクになります。短い作業を無理に水増しする必要はなく、1人で数時間で終わる小さなストーリーならサブタスクを分けなくても構いません。

【記入例】親カード #123 [Story] 法人顧客向け月次請求書PDF出力＆非同期メール送信 (5 SP) の Subtasks 分解例：

• [契約] 請求書出力の OpenAPI 定義を作成し FE/BE で合意する —— 担当：開発 A | 目安：4h
• [BE] PDF テンプレート描画エンジンと OSS 一時署名付きアップロードの実装 —— 担当：開発 A | 目安：8h
• [BE] 非同期メッセージキュー連携とメール再送通知ロジックの実装 —— 担当：開発 A | 目安：6h
• [FE] 請求一覧画面の出力条件モーダルと進捗ポーリング表示の実装 —— 担当：開発 B | 目安：6h
• [結合] 出力トリガー・上限超過表示・ダウンロード導線の FE/BE 結合と自己検証 —— 主担当：開発 A、協力：開発 B | 目安：4h
• [QA] 請求書出力の境界値テストケース作成と結合検収の実施 —— 担当：QA C | 目安：6h

ステップ4：Sprint Goal を確定して Wiki に残す（10:20 - 10:30、10分）

1. 1〜2文でゴールを言語化する：カードの番号を並べるのではなく、このスプリントで実現したい価値を短くまとめます。
   • ❌ 避けたい例：「カード #123、#124、#128、#130 の計8枚の開発とテストを完了する」（ただのタスク一覧）
   • ✅ 良い例：「法人顧客が月次請求書をセルフサービスで発行・PDF出力・メール受領できる一連の流れを通し、経理への手動発行依頼を減らす」
2. Leantime に記録する：特定のダッシュボード欄に依存せず、Sprint 2026-S21 ゴールとふりかえり という Wiki ページを作ってゴールを記載し、関連カードからリンクします。「問い合わせを80%削減する」といった数値目標を置く場合は、事前ベースラインとリリース後の計測が必要であり、スプリント終盤のデモ時点で達成を宣言しないよう注意します。

デイリースクラムは「人」ではなく「カードの流れ」を中心に回す

毎日決まった時間に15分間、開発メンバーで現在のスプリントのカンバンを開き、Sprint Goal に向けた進捗と今日の段取りを確認します。立ってやるかや画面共有を誰がするかは重要ではなく、込み入った技術相談は関係メンバーだけで直後に続けます。

カンバンを「右から左へ」見て、完了に近いものから片付ける

「昨日やったこと、今日やること、困っていること」を順番に話すやり方自体は悪くありませんが、人単位で順番に話すと作業同士の繋がりが見えにくくなります。

1. 管理者への報告会になりやすい：自分の番が終わると他の人の話に意識が向かず、隣のカードが詰まっていても気づきにくい。
2. 仕掛り（WIP）の滞留が見えにくい：毎日「今日も〇〇モジュールを実装中です」と報告が続き、第2週水曜になって5枚のカードがすべて進捗80%のまま1枚もテストに入っていないことに気づく。
3. 「完了」より「新規着手」に流れやすい：Testing & CR でレビュー待ちやバグ修正待ちのカードがあるのに、To Do から新しいカードを取って自分の実装を始めてしまう。

カンバンを 右から左へ（Walk the Board） 見る順番に変えると、「一番 Done に近いカードが何待ちか」から会話が始まり、次に In Progress を確認し、余力があるときだけ To Do から新規カードを引く流れになります。もちろん本番障害や最優先事項があればそちらを優先し、また「ここまでコストをかけたから価値がなくても最後まで作る」といったサンクコストの正当化に使わないよう気をつけます。

flowchart RL
    subgraph SG_BOARD["Leantime カンバン確認順序（右から左へ）"]
        direction RL
        D["Done<br/>(今スプリント完了分)"]
        T["① Testing & CR<br/>(最優先：CR・テスト・バグ修正を進める)"]
        P["② In Progress<br/>(第2優先：サブタスク進捗とブロッカー解消)"]
        TODO["③ To Do<br/>(第3優先：WIP上限内で今日着手するカードを確認)"]

        D -.->|完了に一番近い作業から確認| T
        T -->|仕掛り中の流れを通す| P
        P -->|WIP上限を守って新規引き込み| TODO
    end

カンバン上で確認する3つのポイント

ボードを見るときは、Testing & CR → In Progress → To Do の順に進めます。

① Testing & CR 列（約5分）

• 確認すること：このカードは今日 Done に入れられるか？ コードレビュー待ちか、テスト環境待ちか、それとも不具合修正待ちか？
• その場での調整：
  • CR 待ちなら、誰がいつまでにレビューできるかを確認し、必要なら他の作業順序を調整します。
  • テストで不具合が見つかっているなら、影響度と修正順序をすり合わせ、完了間近のカードが放置されたまま新規カードばかり進む状態を防ぎます。

② In Progress 列（約7分）

• 確認すること：サブタスクはどこまで進んだか？ テスト投入まであとどれくらいか？ FE/BE 間の結合で止まっているところはないか？
• その場での調整：
  • 画面上でカードの Subtasks を開き、昨日終わったサブタスクのチェック漏れがあればその場でチェックします。
  • WIP（仕掛り数）の確認：開発者4〜5名のチームなら、In Progress にある親 Story は全体で 5〜6枚以内（1人あたり1〜2枚）を目安にします。1人で3〜4枚同時に抱えている場合は、動いていないカードを一旦 To Do に戻し、1枚を完了させることに集中します。
  • 滞留カードの確認：In Progress に3営業日以上留まり、サブタスクの動きもないカードがあれば、何が詰まっているかを確認してブロッカー表示を付けます。

③ To Do 列とバーンダウンの確認（約3分）

• 確認すること：今日手元のカードをテストへ回して、新しく To Do からカードを引く人はいるか？ 前提条件（デザインや外部API）は揃っているか？
• その場での調整：新規着手するカードの結合相手を確認し、Sprint Burndown の傾向をざっと見て10:15に終了します。

ブロッカーは10秒で印を付け、深い議論は関係メンバーで続ける

デイリースクラムが長引く原因の大半は、その場で2人が技術詳細のデバッグを始めるか、エッジケースの仕様議論に全員が付き合わされることです。「その場ではブロッカーの印だけ付け、終了後の5〜10分で関係者だけ残って相談する」 ルールにしておくと全員の時間を守れます。

1. ブロッカー（Blocked）の10秒マーキング
   • 操作：カードは元の列（In Progress など）に置いたまま、タイトル先頭に 【🔴ブロック】 を付け、Blocked タグを追加して「誰が・いつまでに何を確認するか」を書きます。このときビジネス上の Priority を自動的に Critical へ変える必要はありません（ブロック状態とビジネス上の重要度は別軸です）。
   • 記録：Discussion に1行メモを残します（例：2026-11-05 朝会メモ：決済サンドボックスの証明書期限切れで結合中断。@TL が本日14:00までにインフラ担当へ更新確認）。
2. 終了後の小グループ相談（10:15 - 10:20）
   • 関係ないメンバーはすぐ開発へ戻る：10:15になったら、ブロッカーに関係しないメンバーはそのまま解散して作業に戻ります。
   • 必要なメンバーだけで相談する：技術課題なら担当開発者と QA・Tech Lead、スコープや仕様に関わるなら PO も交えて方針（スコープ調整、ペア作業、別枠での設計相談など）を決めます。5分で決めきれない重い課題を無理にその場で即決する必要はありません。

コードを書き終えてからが協業の後半戦

カンバン上の「進行中」には、実装だけでなくレビュー待ち、デプロイ、テスト検証までが含まれます。ブランチや PR のリンク、テスト引き継ぎメモをカードに残しておけば、「このカード今どこまで進んでる？」と毎回聞き回らずに済みます。

flowchart TD
    START(["Sprint Planning でスプリントへ投入"]) --> ToDo["To Do / 着手待ち"]
    ToDo -->|カードを引き受け feat/LT-ID ブランチ作成| InProgress["In Progress / 実装中"]
    InProgress -->|開発サブタスク完了・PR作成・自己検証パス| TestingAndCR["Testing & CR / レビュー＆テスト"]

    subgraph SG_VERIFY["Testing & CR 内の連携"]
        direction LR
        CodeReview["TL / ピアがCR完了＆テスト環境へ反映"] --> QAVerify["QA が受入検証を実施"]
    end

    TestingAndCR -.-> SG_VERIFY
    TestingAndCR -->|パターン1: Story内の軽微な不具合<br/>親カードに Bug Subtask を追加し差し戻し| InProgress
    TestingAndCR -->|全ACクリア ＆ Wiki同期完了| Done(["Done / 完了"])

    subgraph SG_BUG["パターン2: 独立 / デグレ / 本番不具合"]
        NewBugCard["独立した Type=Bug カードを起票"]
    end

    NewBugCard -->|当期バッファ消化 または Backlog へ| ToDo

コードとカードを双方向に辿れるようにする

Leantime のカード番号（カードを開いた左上に表示される #123 のような番号）をブランチ名やコミット、PR に入れておくと後から追跡しやすくなります。以下は命名の一例であり、既存リポジトリに定着している規約があればそれを使いつつ、カードと PR のリンクだけ相互に貼っておきます。

1. Git ブランチ命名例：
   • 機能開発：feat/LT-123-monthly-bill-pdf
   • 独立バグ修正：fix/LT-156-token-refresh-race
   • 基盤・リファクタリング：chore/LT-140-ci-docker-cache
2. Commit メッセージと PR / MR：
   • Commit 例：feat(billing): add async pdf generation worker (Ref #123)
   • PR / MR タイトル：[LT-123] 法人顧客向け月次請求書PDF出力＆非同期メール送信
   • PR 本文の先頭に Leantime カードの URL を貼り、Leantime カードの Discussion にも PR リンクを貼っておきます。

Testing & CR に移すときは、検証に必要な文脈も一緒に渡す

カードを Testing & CR に動かすのは、「コードを書き終えた瞬間」ではなく「レビューと検証を受けられる状態が整ったとき」です。開発者自身でメインフローを通し、環境・PR・設定変更・回帰テストの注意点をメモして渡すことで、QA が前提条件を確認し直す手間を減らせます。

まずは以下の4点を、In Progress から Testing & CR へ移す際の引き継ぎチェックとして合意します（これは検証工程へ入るための確認であり、最終的な DoD の代わりではありません）。

1. 開発系 Subtasks の完了：カードの Subtasks タブで、[契約]、[FE]、[BE]、[結合] などの開発項目が完了していること。
2. PR/MR の作成と検証環境の準備：CI ビルド、静的解析、単体テストが通っていること。PR ごとのプレビュー環境があればそれを使い、共有の Staging 環境しかない場合は、未レビューのコードで共有環境を壊さないよう、先にコードレビューとマージを済ませて Staging へ反映してから QA へ渡します。
3. ハッピーパス（主要フロー）の自己確認：Story Owner がテスト環境で AC に沿って一通り動作を確認していること（複雑な画面遷移なら QA と3分ほど画面共有してウォークスルーすると手戻りが減ります）。
4. コメント欄への引き継ぎメモ記載：カードの Discussion タブに以下のテンプレートでメモを残し、@QA と @Reviewer にメンションします。

📋 Leantime カードコメント欄《テスト引き継ぎ＆自己検証メモ例》

• 【検証環境・ブランチ】：Staging 環境 | ブランチ：feat/LT-123-monthly-bill-pdf
• 【関連 PR リンク】：BE PR #408 / FE PR #215（@TechLead レビューお願いします）
• 【設定・DB変更点】：V20261105__add_bill_export_task.sql 適用済み。Redis 設定 BILL_EXPORT_TTL=3600 を追加
• 【自己検証結果】：
  • AC1：直近12ヶ月の任意の月を指定して出力トリガーが動くこと（確認済み）
  • AC2：10,000件超でバックグラウンド非同期生成＋通知に切り替わること（確認済み、テストアカウント：corp_test_01）
  • AC3：対象データ0件の月で空状態の案内が表示されること（確認済み）
• 【影響範囲と回帰確認のお願い】：共通メール送信部品 MailSender に手を入れたため、「パスワード再設定メール」の送信もあわせて確認をお願いします。@QA_C よろしくお願いします。

不具合を親カードにするかサブタスクにするかは「追跡のしやすさ」で決める

テストで見つかった不具合は、大きく2つに分けて扱います。現在進行中の Story で AC を満たしきれていない細かな不備は元のカード内のサブタスクとして直し、モジュールをまたぐデグレや本番不具合、独立して追跡すべき問題は Type = Bug の親カードとして起票します。目的は「バグ件数を少なく見せること」ではなく、後から経緯を追えるようにすることです。

2種類の不具合の記録ルール

なお、ストーリー内の不具合であっても、監査上またはリリース判断上で個別に追跡したい場合は、独立した Bug カードを起票して元の Story にリンクして構いません。

Sprint Review は「成果」を点検し、Retro は「協業のやり方」を点検する

第2週金曜午後の Review と Retro は続けて開催できますが、見る対象が異なります。Review はステークホルダーと一緒に実際のプロダクト増分とゴールの進捗を確認して次の一手を相談する場であり、Retro はチームの働き方やプロセスを見直す場です。以下では各30分（計60分）の例を示しますが、時間が足りない場合は時計に無理やり合わせるよりも対話の質を優先します。

flowchart LR
    subgraph SG_REV["前半：Sprint Review (16:00 - 16:30)"]
        R1["16:00-16:05<br/>Sprint Goal とバーンダウン確認<br/>計画範囲と完了分の整理"] --> R2["16:05-16:25<br/>Done 列の実機デモ<br/>AC に沿って動くソフトウェアを確認"]
        R2 --> R3["16:25-16:30<br/>未完了カードの扱いを確認<br/>Backlog へ戻し次期計画で再判断"]
    end

    subgraph SG_RET["後半：Sprint Retro (16:30 - 17:00)"]
        T1["16:30-16:35<br/>無言でのカード記入 (5分)<br/>Continue / Stop / Start を書く"] --> T2["16:35-16:45<br/>グルーピングと投票 (10分)<br/>1人2票で上位1〜2件の課題に絞る"]
        T2 --> T3["16:45-16:55<br/>原因の深掘りと対策決定 (10分)<br/>具体的なアクションに落とし込む"]
        T3 --> T4["16:55-17:00<br/>改善候補 To-Do カード化 (5分)<br/>Owner を決め次期計画で確認"]
    end

    R3 --> T1

Sprint Review は単なる「完了カードのデモ会」ではない

Review で大切なのは、実際の成果物とビジネスフィードバックです。DoD を満たした増分を実機で動かして見せるだけでなく、完了しなかった項目や途中で変わった前提条件も率直に共有します（未完成のものを完成したかのように見せるのは避けます）。スライドを使うかどうかは本質ではなく、報告資料で実際のソフトウェア確認を置き換えないことが肝心です。

1. Sprint Goal とバーンダウンの振り返り（16:00 - 16:05、5分）
   • スプリント計画時に残したスコープ記録と現在のバーンダウンを見比べ、ゴールの結果・完了した範囲・途中で追加や除外した項目を分けて共有します。たとえば「当初40 SP選び、38 SP完了した」というのは初期スコープの消化率であり、それ自体が Sprint Goal の達成を意味するわけではありません。実際の成果や周囲の状況変化を踏まえ、次に何を優先すべきかをステークホルダーと議論します。
2. Done 列のカードに基づく実機デモ（16:05 - 16:25、20分）
   • カンバンの Done 列にある（DoD を満たした）増分を実機でデモし、未完了の作業や残存リスクは成果に含めず別途説明します。
   • 各 Done カードの Story Owner（または検証した QA） が、Staging または本番環境で AC に沿って動作を見せます。
   • デモ中に「こうするともっと使いやすい」といった追加アイデアが出た場合は、その場で新規 To-Do として Backlog に起票し、すでに合意した AC を満たしているカードの Done は覆しません。
3. 未完了カード（Carry-over）の扱い（16:25 - 16:30、5分）
   • 自動的に次スプリントへ押し込まない：Done に入らなかったカードは一旦 Backlog に戻して価値と残作業を見直します。Sprint 2026-S22 の候補として印を付けることはできますが、実際に次スプリントへ入れるかどうかは翌週月曜の Planning で改めて決めます。
   • ストーリーポイントの記録ルール：DoD を満たさなかった Story は、今スプリントの完了実績としては 0 SP とします。カードの Sprint 属性を変更する前に、今スプリントの初期スコープ・完了分・持ち越し分を Sprint Wiki に記録して履歴が消えないようにします。次のスプリントで完了した際に元のポイント数を1回だけ計上し、Planning 時のキャパシティ計算では残作業分だけを見積もります（ポイントを「今週2点、来週3点」のように分割したり二重に差し引いたりしません）。持ち越しが続く場合は、ストーリーをもっと小さく分割できないかを話し合います。

ふりかえり（Retro）では、追跡可能な1〜2個の改善アクションだけを持ち帰る

ふりかえりでは、個人を責めるのではなく仕組みややり方に目を向けられる心理的安全性が欠かせません。たくさんの付箋を並べて満足するのではなく、次のスプリントで実際に試せる改善を1〜2個だけ選び、担当者と完了条件を決めて、次回のふりかえりで効果を検証します。

1. ふりかえりキャンバスを開き、無言でカードを書く（16:30 - 16:35、5分）
   • Blueprints の retros テンプレートで Sprint 2026-S21 ふりかえり というキャンバスを作り、Sprint Wiki にリンクを貼ります（スプリント選択と自動連動する仕組みではないため、名前とリンクで紐づけます）。3つの列に各自がカードを追加します：
     • 🟢 Continue（続けたいこと）：今スプリントでうまく機能したプラクティスや工夫
     • 🔴 Stop Doing（やめたいこと・課題）：手戻り、待ち時間、環境トラブルなど進行を妨げた要因
     • 🔵 Start Doing（新しく試すこと）：次のスプリントで試したい具体的なアクション
2. 似たカードをまとめ、投票で上位1〜2件に絞る（16:35 - 16:45、10分）
   • 重複するカードをまとめた上で、1人 2票 を投じます（専用プラグインがなくてもコメント欄等で集計できます）。得票上位の1〜2件に議論を絞ります。
3. 原因を掘り下げ、検証可能なアクションを決める（16:45 - 16:55、10分）
   • 「次は気をつける」「コミュニケーションを密にする」といった精神論で終わらせず、5 Whys（なぜなぜ分析） で具体的な仕組みや手順の変更に落とし込みます。

4. 次スプリントの候補カードとして起票する（16:55 - 17:00、5分）
   • 決まった1〜2件の改善アクションを、[Retro改善] プレフィックス付きの Type = Task カードとして作成します。担当者と完了条件、目標日を入れ、一旦 Backlog に置いて S22 の候補とします。月曜日の Planning でキャパシティを確認した上でスプリントへ組み込み、次回の Retro の冒頭で実際の効果を確認します。

完了したカードだけでなく、生きたナレッジを残す

スプリントが終わればカードはアーカイブされますが、API の仕様や技術選定の理由、リリースの注意点はその後も開発に影響し続けます。もしそうした背景知識が当時の担当者の頭の中にしかなければ、後から関わるメンバーは何度も口頭で説明を受けることになります。

私が Leantime の Wiki とタスクカードをセットで使いたいと考えたのもそのためです。カードには「今回のスプリントで何を実行するか」を書き、Wiki には「スプリントをまたいで参照される知識」を残します。ドキュメントの維持には当然コストがかかるため、将来の繰り返し説明を減らせる部分に絞って投資します。

ドキュメントの置き場所よりも「見つけやすさ」と「鮮度」が大事

ドキュメントツールが複数に分かれていること自体が問題なのではありません。本当に困るのは、「どれが最新かわからない」「リンクが切れている」「実装は変わったのにドキュメントが去年のまま」という状態です。すでに使いやすい外部 Wiki があるなら、固定の入口リンクと双方向参照を保つだけで十分であり、無理に引っ越す必要はありません。

Leantime 内蔵の Wiki / Docs を使うのは、タスクとナレッジの距離を近く保つための選択肢の1つです。いずれの場合も、誰がどの領域を更新するかは決めておく必要があります。

flowchart LR
    subgraph SG_WIKI["Leantime 内のナレッジ循環ループ"]
        A["プロダクト目標＆マイルストーン"] -->|仕様のブレイクダウン| B("Leantime Wiki<br/>PRD / ADR / 運用手順書")
        B <-->|ディープリンクで双方向参照| C("Sprint To-Do カード<br/>実装内容 / 受入基準")
        C -->|DoD チェックを通じて更新| B
    end

よく使う少数のフォルダから始める

Leantime の Wiki / Docs は階層構造の記事ツリーを作れます。以下はオンボーディング、要件仕様、アーキテクチャ決定、API・DB、リリース運用の5つに分けた構成例です。最初から空のディレクトリを完璧に揃える必要はなく、毎週参照する2〜3個のページから始めるのが現実的です。

📚 プロジェクト Wiki ルート (Project Wiki Root)
├── 📂 01-オンボーディング・環境構築 (Onboarding)
│   ├── 📄 チームの働き方合意とアジャイルカレンダー（朝会/Grooming/Review/Retro）
│   ├── 📄 ローカル開発環境 半日構築ガイド（ミドルウェア、Hosts、環境変数テンプレート）
│   └── 📄 Git ブランチ戦略とコミット規約（Story・Bug テンプレート付き）
├── 📂 02-プロダクト要件・プロトタイプ保管 (PRD & Specs)
│   ├── 📄 ドメイン用語集（ユビキタス言語の統一）
│   ├── 📄 [v1.2.0] ユーザー・権限管理モジュール仕様とプロトタイプリンク
│   └── 📄 [v1.3.0] 注文ステータス遷移と返金例外ルール
├── 📂 03-システム構成・技術的意思決定 (ADR & Architecture)
│   ├── 📄 システム全体構成図とサービス境界
│   ├── 📄 ADR-001：シャーディングではなく PostgreSQL を選択した理由
│   └── 📄 ADR-002：非同期メッセージキュー選定とリトライべき等設計
├── 📂 04-API 規約・データベース定義 (API & Schema)
│   ├── 📄 共通 API 規約（レスポンス構造、エラーコード一覧、認証ヘッダー）
│   ├── 📄 主要テーブル定義とインデックス変更履歴
│   └── 📄 外部サービス連携・サンドボックス接続メモ（機密情報は除く）
└── 📂 05-リリース手順・障害対応ランブック (Runbooks & Release Checklist)
    ├── 📄 開発・ステージング・本番環境の構成とリソース一覧
    ├── 📄 本番リリースチェックリストとロールバック手順書
    └── 📄 よくある本番障害の初期対応手順（DBロック、外部APIタイムアウト時の縮退など）

各ディレクトリの主なメンテナンス担当

• 01-オンボーディング・環境構築：Tech Lead が初版を作り、新しく入った開発者や QA が実際に環境を作る中で古い記述を直します。目安はシンプルで、「新メンバーが周囲に聞き回らずに、半日以内でローカルのフロント・バックエンドを起動してテストAPIを1回通せるか」 です。
• 02-プロダクト要件・プロトタイプ保管：PO がマイルストーンや業務ドメイン単位で整理します。
• 03-システム構成・技術的意思決定：Tech Lead と主要開発者 が更新します。「なぜ当時その選択をしたのか」を残し、半年後に同じ議論を蒸し返したり同じ落とし穴にはまったりするのを防ぎます。
• 04-API 規約・データベース定義：主に バックエンド開発者 が書き、フロントエンドと QA が参照します。Swagger / OpenAPI などで自動生成している場合は、共通規約と主要 ER 図、自動生成ドキュメントへの固定リンクだけをここに置きます。
• 05-リリース手順・障害対応ランブック：QA / DevOps と Tech Lead が維持し、リリース作業の抜け漏れを防ぎます。

付録テンプレート1：軽量アーキテクチャ決定記録（ADR）

ミドルウェアの選定や主要テーブルの設計変更、外部ライブラリの導入など、後の保守に影響する技術判断を行った際は、03-システム構成・技術的意思決定 配下に短い ADR を残します。フォーマットは簡潔にし、議論そのものにかける時間は課題の重さに応じて確保します。

# ADR-[番号]：[技術判断を一行で要約。例：分散セッションと高頻度キャッシュに Redis を採用する]

- **ステータス**：採択（提案中 / 採択 / 廃止 / ADR-XXX により置換）
- **決定日**：2026-MM-DD
- **参加者**：@[Tech Lead] @[開発A] @[開発B]
- **関連カード**：#[To-Do ID]

## 1. 背景と課題 (Context)

_現在直面している業務上・システム上の課題と制約条件（例：8名体制で運用負荷を増やせない、今スプリント内のリリースが必要など）を簡潔に書く。_

- 事象・課題：
- 制約条件：

## 2. 検討した選択肢 (Options Considered)

_比較した2〜3案と、それぞれのメリット・デメリットを端的に書く。_

- **案A（採用）**：[概要]
  - 利点：
  - 欠点・リスク：
- **案B（見送り）**：[概要]
  - 見送った理由：

## 3. 決定事項 (Decision)

_採用する具体的な構成、バージョン、主要な設定方針を明記する。_

## 4. 影響と後続対応 (Consequences)

_この決定によって得られる効果、許容する技術的負債、合わせて変更が必要な箇所。_

- **プラスの影響**：
- **トレードオフ・技術的負債**：
- **関連する変更作業**：デプロイスクリプトの更新 / 環境変数 `XXX` の追加

付録テンプレート2：本番環境リリースチェックリスト

リリースはスプリント最終日に限らずいつでも行えます。以下のチェックリストはあくまで叩き台であり、実際のサービス構成やマイグレーション方式、リスク許容度に合わせて手順を調整してください（特に手順の順番をすべてのシステムにそのまま当てはめないよう注意します）。

# [バージョン番号、例：v1.4.0] 本番環境リリースチェックリスト

- **リリース日時**：2026-MM-DD HH:mm
- **リリース責任者 (Release Manager)**：@[氏名]
- **関連マイルストーン**：[マイルストーン名 / リンク]
- **ロールバック判断基準**：サービスのリスクに応じてエラー率・主要導線・監視時間の閾値を事前に合意しておく。データ破損やセキュリティ上のリスクがある場合は固定の30分を待たずに即座に止血し、検証済みの復旧手順とデータ互換性に基づいてロールバックまたは前方修正を判断する。

---

## 1. リリース前準備 (Pre-Release)

- [ ] **コードのマージとタグ付け**：対象バージョンの To-Do がすべて `Done` に入り、PR がメインブランチへマージされて Release Tag が切られていること。
- [ ] **データベース変更の確認**：
  - [ ] DDL/DML スクリプトの有無（[ ] なし / [ ] あり、場所：_______）
  - [ ] SQL 変更に後方互換性があるか（ローリングアップデート中に旧コードと共存できるか）？
  - [ ] 本番 DB のリリース前スナップショット・バックアップが完了しているか？
- [ ] **設定・環境変数**：
  - [ ] 追加・変更された環境変数、設定値、シークレットが本番環境に準備されているか？（一覧：_______）
  - [ ] 外部連携先のコールバック URL や IP 許可リストが開通しているか？
- [ ] **成果物の確認**：CI/CD イメージまたはビルド成果物が生成され、Staging 環境で動作確認済みであること。

## 2. リリース実施順序の例 (Release Execution)

1. [ ] **Step 1**：DB の増分マイグレーションを実行し、エラーや長時間ロックがないことを確認する。
2. [ ] **Step 2**：本番環境の新規設定値の反映 / 必要に応じた Redis キャッシュのウォームアップ。
3. [ ] **Step 3**：バックエンドサービスのローリングアップデート（まず1ノードでログを確認し、問題なければ全体へ展開）。
4. [ ] **Step 4**：フロントエンド静的アセットの配信と CDN キャッシュのパージ。
5. [ ] **Step 5**：定期バッチ / メッセージキューコンシューマーの有効化。

## 3. リリース後検証 (Post-Release Verification)

- [ ] **主要導線のスモークテスト（QA 主導）**：ログイン認証、主要業務フロー、決済・ステータス遷移の動作確認。
- [ ] **監視・ログ確認（リリース責任者主導）**：リリース後15分間、エラーログ、CPU/メモリ使用率、スロークエリに異常な跳ね上がりがないか確認。
- [ ] **完了連絡**：チームチャンネルに「v1.4.0 リリース完了」を共有。

## 4. 緊急ロールバック計画 (Rollback Plan)

1. [ ] アプリケーションイメージを直前の安定版 Tag へ戻す：`[直前の Tag 名、例：v1.3.2]`
2. [ ] 設定値の復元手順：`[戻す必要がある設定値。後方互換なら変更不要と明記]`
3. [ ] データ復旧と互換性方針：`[前方互換での修正、データ補正、または検証済みリストア手順を記載。未検証の逆向き SQL を本番で直接実行しないこと]`

必要なドキュメント更新をデリバリーの流れに組み込む

To-Do カードの Description には「今回の目的、スコープ境界、AC、Wiki へのリンク」を書き、何千字もの設計書を丸ごと貼り付けるのは避けます。逆に Wiki 側からも実装チケットへリンクを残しておくと、後から変更の経緯を辿りやすくなります。

カードに書くこと、Wiki に残すこと

どの変更で Wiki 更新を DoD に含めるか

環境変数、DB スキーマ、外部公開 API、デプロイ手順の4つに触れる変更では、対応する Wiki の更新を DoD に含めておくと、次に触るメンバーが困りません。誰か1人の承認ハンコを増やすのではなく、レビューと検証の場で「運用や引き継ぎに必要な記述が同期されているか」を一緒に確認します。

flowchart TD
    A["開発者が実装・自己検証を完了"] --> B{"設計・運用の4領域に変更があるか？"}
    B -->|いいえ: 通常の機能変更のみ| D["Testing & CR で検証へ"]
    B -->|はい| C["対応する Leantime Wiki ページを更新"]
    C --> D
    D --> E{"QA ＆ Tech Lead による DoD 確認"}
    E -->|コード検証OK かつ Wiki 同期済み| F(["Done へ移動"])
    E -->|Wiki 未更新または実装と乖離| G["In Progress へ戻して追記"]
    G --> C

1. 環境変数・設定の変更：設定キー、シークレット、外部接続先、Feature Flag の追加・変更 \rightarrow 01-ローカル環境ガイド および 05-リリース手順書 に反映。
2. DB・キャッシュ構造の変更：新規テーブル、カラムの意味変更、主要インデックス追加、Redis キー規約の変更 \rightarrow 04-API 規約・データベース定義 に反映。
3. 外部・画面間 API 仕様の変更：結合中にフィールド名やステータスコード、ページング仕様を調整した場合 \rightarrow マージ前に 04-API 規約 を更新し、口頭合意とドキュメントのズレを防ぐ。
4. ミドルウェア導入・運用スクリプト変更：新しいミドルウェア、定期ジョブ（CronJob）、データ補正スクリプト、特殊なリリース順序の追加 \rightarrow 03-システム構成 (ADR) または 05-リリースチェックリスト に反映。

予定外の作業にも最初から居場所を作っておく

ここまで整理してきた流れは一見きれいに見えますが、実際の現場では計画通りにいかない日がつきものです。本番の不具合、運用チームからの問い合わせ、急ぎの追加要望はどれも同じメンバーの時間を奪います。もし計画内の機能開発だけをボードに載せていると、キャパシティの計算もバーンダウンもすぐに実態から乖離してしまいます。

計画を100%詰め込むより、バッファとトレードオフのルールを持つ

そこで、計画段階で一定のバッファを残した上で、「本番障害」「スプリント途中の緊急要望」「日々の細かな問い合わせ対応」の3つを分けて扱います。どれも必要な仕事ですが、元の計画がそのまま維持できるふりをして黙ってスプリントへ押し込むのは避けます。

バッファは実績を見ながら調整する仮説として扱う

Sprint Planning では、休暇・会議・定常業務を差し引いた後のキャパシティから 15%〜20% のバッファ を確保し、実際に発生したサポート量を見ながら比率を調整します。前述のキャパシティ計算式と同じ基準で1回だけ確保し、すでにバッファ込みの実績である過去ベロシティから予測する際に二重で割り引かないよう注意します。

• 特定メンバーへの集中（属人化）に気をつける：あるモジュールを1人しか把握していない場合、その人が半日障害対応に抜けると、本人の実装だけでなく周囲の結合やレビューまで止まります。チーム全体の合計時間に余りがあっても、特定の工程に余裕があるとは限りません。
• バッファが余っても無理に使い切らない：第2週水曜の時点でバッファが残っていれば、まずはコードレビューやテスト、回帰確認、改善タスクの消化に回します。Sprint Goal や品質を脅かさず、残り期間で確実に完了できるごく小さな Ready カードがある場合に限り、PO と相談して引き込みます。

予定外の作業はまず性質を見極める

スプリントの途中で予定外の作業が発生したら、即座に止血すべき障害なのか、スコープ交換の相談が必要なのか、日常サポートの受け皿に入れるものなのかを振り分けます。

flowchart TD
    A["スプリント途中で予定外の作業が発生"] --> B{"どの種別の作業か？"}

    B -->|"1. 本番の重大障害 (P0/P1)"| C["ただちに緊急対応を開始"]
    C --> D["本番復旧を最優先し、復旧後に Leantime へ Bug 起票"]
    D --> E["#Hotfix タグを付け当期 Sprint に紐づけて実働時間を記録"]
    E --> F["15%~20% バッファから消化し、Retro で振り返る"]

    B -->|"2. スプリント途中の緊急ビジネス要望"| G["PO が緊急度と価値を確認"]
    G --> H{"今スプリント内でないと駄目か？"}
    H -->|"いいえ: 次スプリントまで待てる"| I["Product Backlog に入れて通常の優先度付けへ"]
    H -->|"はい: 見送ると大きな業務影響がある"| J["【等量交換 Swap In / Swap Out】を相談"]
    J --> K["Tech Lead と開発・QA で新規カードの規模 X を見積もる"]
    K --> L["PO が当期 To Do 列から同規模 X の未着手カードを Backlog へ戻す"]
    L --> M["新規カードに #Swap-In タグを付け当期 Sprint へ入れる"]

    B -->|"3. 日常の細かな問い合わせ・データ抽出 (< 2h)"| N["今週の当番エンジニア / 共通サポート親カードへ記録"]

パターン1：P0/P1 の本番障害 —— まず復旧、カード起票は事後

1. 復旧が最優先：Tech Lead と関係する開発・DevOps でロールバックや Hotfix にあたり、Leantime の起票を待って復旧を遅らせることは絶対にしません。
2. 復旧後2時間以内を目安に記録を残す：サービスが落ち着いた後、現在のスプリントに Type = Bug、Priority = Critical、タイトル先頭 [Hotfix]、#Hotfix タグ付きでカードを作成し、実際にかかった時間を記録します。
3. バッファ超過時のアラート：スプリント内の Hotfix 累計時間が確保していた 15%〜20% のバッファを超えた場合は、翌日のデイリースクラムで PO と状況を共有し、スプリント後半の優先度が低い Story を後ろ倒しにするか相談します。

パターン2：スプリント途中の緊急要望 —— 何を後ろ倒しにするかを一緒に決める（Swap In / Swap Out）

スプリントの途中で「どうしても今週中に入れたい要望」が出た場合は、等量交換（Swap In / Swap Out） の考え方で「代わりに何を外すか」を話し合います。ポイント数が同じでもそのまま置き換えられるとは限らないため、依存関係や仕掛り中の作業、QA の負荷もあわせて確認します。

対外的に説明する際も、「手一杯でできません」と突っぱねるより、「今週この3ポイントの要望を優先するなら、予定していた〇〇レポート改善（3ポイント）を次スプリントへ回す形になりますが、どちらを優先しましょうか？」と選択肢を提示する方が建設的な議論になります。もちろんその判断は要望元だけに丸投げせず、PO と開発チームが一緒に実現可能性を確認します。

日常の細かなサポートは「受け皿カード」にまとめてボードの氾濫を防ぐ

運用担当からのデータ抽出依頼や2次サポートの調査、テスト環境のちょっとした調整など、1件あたり30分〜1時間半ほどの作業は毎日のように発生します。これらをすべて独立した親カードにするとカンバンが小粒なカードで埋め尽くされ、逆に何も記録しないと「なぜ今週は機能開発が進まなかったのか」が分からなくなります。

そこで、共通の受け皿となる親カード（Bucket Card） と 週替わりの当番制（Batman） を組み合わせます。なお、独立した検証や数日がかりの対応が必要な技術的負債は、受け皿カードに隠さず通常の Backlog カードとして計画します。

受け皿カードと当番制でサポート負荷を見える化する

1. Sprint Planning で定常枠の「受け皿カード」を作る 各スプリントの開始時に、確保したバッファ枠を使う親 To-Do カードを1〜2枚作成します。

2. 2時間ルールと簡単な記録手順
   • 2時間未満の定常的な小作業：対応後に受け皿カードの Subtasks に1行追加し、内容・実際の対応者・かかった時間を Time Tracking に記録します（累計値を手書きで上書きするのではなく、明細として追加します）。ただし本番障害、セキュリティ問題、独立した回帰テストが必要な不具合は、所要時間にかかわらず独立カードとして起票します。
   • 2時間以上かかる作業：Backlog に独立した Story / Task として起票し、通常の優先度付けと見積もりに乗せます。
3. 週替わりの当番エンジニア（On-Call / Batman）と組み合わせる
   • 週次ローテーション：開発者5名で当番プールを組み（Tech Lead はエスカレーション先としてバックアップに回り、5名の枠には重複カウントしない）、毎週1名が日常の問い合わせ窓口になります。スプリント途中で当番が交代する際は親カードの Assignee を更新し、サブタスクごとに実際の対応者を残します。
   • 窓口の一本化：運営やCSからの日常的な調査・データ抽出依頼はまず当番エンジニアが受け、他の4名が集中して実装できる時間を守ります。
   • 実績データをもとに自動化する：もし2スプリント連続で Ops-Bucket の消費時間が24時間を大きく超えるなら、サブタスクの内訳をもとに管理画面の機能化や自動化スクリプトの開発を正式な Story として Backlog に起票します。

ツール運用で陥りやすい5つのアンチパターンと対策

1. サブタスクを1時間単位まで細かく割りすぎる

• よくある状態：3ポイントの Story の下に15個の Subtask（「テーブル作成 1h」「Entity 作成 0.5h」「DAO 作成 1h」……）が作られ、毎日のカード移動と入力だけで疲弊する。
• 試したい調整：
  1. サブタスクは「0.5日〜1日（4〜8時間）」を目安にする：通常の Story なら3〜6個程度で十分であり、下限数は設けません。短い作業を無理に分割しないようにします。
  2. 細かい実装メモは本文のチェックリストに書く：「インデックス追加」「DTO 修正」のような数十分単位のメモは、カードの Description やコメント欄にチェックリストとして書き、Subtask にはしません。

2. ストーリーポイントを個人の人事評価（KPI）に使ってしまう

• よくある状態：月末に個人ごとの消化ポイントランキングを集計した結果、Planning での見積もりが水増しされ（2ポイントの作業を5ポイントと申告するなど）、誰もコードレビューや共通基盤の改善に手を挙げなくなる。
• 試したい調整：
  1. ストーリーポイントを個人評価から完全に切り離す：Leantime の Effort は チーム全体のベロシティ把握とキャパシティ予測 にのみ使い、個人別のポイント集計は行いません。
  2. 基準カード（Anchor Stories）を Wiki に置く：過去に完了した代表的なカードを 1ポイント / 3ポイント / 5ポイント の基準例として Wiki に固定し、見積もり時に横比較できるようにします。

3. 普段はボードが止まっており、朝会の5分前にまとめて動く

• よくある状態：月曜から木曜までカンバンが全く動かず、毎朝09:55に一斉にカードが動くか、金曜午後に To Do から Done へ一気にカードが飛ぶ。
• 試したい調整：
  1. 開発の自然な区切りとボード更新を紐づける：次の3つのタイミングだけ、10秒使ってカードを更新する習慣にします。
     • ブランチを切って実装を始めたとき（git checkout -b feat/LT-xxx） \rightarrow In Progress へ移動。
     • PR/MR を出して自己検証を終えたとき \rightarrow 引き継ぎメモを貼って Testing & CR へ移動。
     • 他チーム待ちや仕様確認で2時間以上止まったとき \rightarrow タイトルに 【🔴ブロック】 を付けて担当者に @メンション。
  2. デイリースクラムで画面を見ながら合わせる：口頭で「もうテストに出しています」と話が出たら、その場で一緒に画面上のカードを動かし、引き継ぎメモが入っているか確認します。

4. 第2週の木曜午後にテストが一斉に雪崩れ込む（ミニ・ウォーターフォール）

• よくある状態：最初の8日間は開発者がひたすらコードを書き、QA は手空きになる。第2週木曜の午後に10枚のカードが一気に Testing & CR へ入り、QA がパンクする。
• 試したい調整：
  1. スプリント途中の2つの節目を意識する：W1木曜/金曜 時点で約30%のカードが Testing & CR に入っているか、W2水曜 18:00（Feature Code Freeze） 時点で未提出の機能 Story が残っていないかを確認します。
  2. 1人あたりの仕掛り数（WIP）を絞る：開発者1人が同時に In Progress に置く Story を 1〜2枚まで に抑え、3枚目を始める前に手元のカードをテストへ通しきるようにします。

5. ふりかえりが「愚痴の言い合い」で終わり、次の行動に繋がらない

• よくある状態：1時間かけてたくさんの付箋を書き出すものの、具体的なタスクにならず、次のスプリントでも同じ問題が繰り返される。
• 試したい調整：
  1. 改善テーマは上位1〜2件に絞る：投票で チーム自身の裁量で変えられる上位1〜2件の課題 だけに絞ります。
  2. その場で候補カードにする：[Retro改善] 付きの To-Do カードを作り、担当者と完了条件を書いて次スプリントの計画候補に入れ、次回のふりかえりで結果を点検します。

最初から全部入りを目指さず、まずは2スプリント試して観察する

立派なルールを書くことよりも、チームが無理なく続けられることの方がはるかに大切です。実際に導入するときは、最初からすべてのルールを適用するのではなく、まずは「今の作業を見えるようにする」「完了の定義を揃える」ところから小さく始め、必要に応じて仕組みを足していきます。

最初のスプリント：作業がボード上を自然に流れるかを見る

最初は、1つのメインワークスペース、内容が整理された少数のストーリー、To Do → In Progress → Testing & CR → Done の基本レーン、そしてテンプレートを置いた Wiki ページが1つあれば十分です。Backlog は未割当スプリントのフィルタとして扱い、余計な列は増やしません。

1回目のスプリントでは、見積もりポイントが当たったかどうかを気にするよりも、次のような具体的な流れを観察します。「作り始めてからどれくらい仕様の追加確認が発生したか」「PR やテストがどこで一番待たされたか」「突発のサポート作業が記録に残ったか」「カードの位置を見れば状況が分かる状態だったか」。初回の Review と Retro ではこれらを振り返り、次に試す調整を1〜2個だけ選びます。

2回目のスプリント：どの合意が役に立ったかを確かめる

2回目の計画では、前回の完了実績や稼働日数、差し込み作業の記録を参考にします（ただし1回分の実績だけで安定したベロシティとはみなせません）。もし前回終盤にテストが詰まったならストーリーの分割や早めのテスト引き継ぎを意識し、突発の問い合わせで開発が細切れになったなら当番制と受け皿カードを取り入れ、ドキュメント不足で引き継ぎに手間取ったなら DoD の Wiki 更新チェックを少し丁寧に行います。

2スプリント回した時点で大切なのは、「導入チェックリストが何点取れたか」ではありません。「計画と実績のズレを自分たちの言葉で説明できるか」、そして「Leantime 上の記録が、余計な事務作業ではなくトレードオフの判断に役立ったか」をチームで確認できるかどうかです。

おわりに

今回、TPM の視点から小規模チームのアジャイル実践を改めて整理してみて、ルールやフレームワークの価値は「どれだけ教科書通りに揃っているか」ではなく、「待ち時間を減らし、トレードオフの判断を助けられるか」にあると再確認しました。Leantime はそうしたチームの合意事項を一箇所にまとめる良い器になってくれますが、ツール自体が優先順位を決めてくれたり品質を保証してくれたりするわけではありません。

ここにまとめた内容は、実機での試行を踏まえた1つの出発点です。まずは作業を見えるようにし、フィードバックを早く回し、実際の記録をもとに少しずつ調整していく。もしある入力項目や会議、ルールがチームの協業を助けていないなら、「アジャイルっぽさ」のために残しておく必要はありません。

バージョン根拠・参考リンク

• Leantime v3.9.8 ソースコード：本稿でツールの仕様を確認したベースラインバージョン。
• チケット種別・Effort・Priority・ステータス定義：システム標準の選択肢と、本稿の運用で使う範囲の切り分け。
• マイルストーン進捗率の計算ロジック：getMilestoneProgress を参照（Effort に優先度係数を掛けた重み付き集計）。
• スプリント統計の実装：残タスク数、Effort、工数、日次スナップショットの集計仕様の確認。
• ふりかえりキャンバステンプレート・Wiki リポジトリ実装：3列構成と階層型 Wiki 記事のサポート確認。
• Scrum Guide 2020：Scrum 公式の責任・作成物と、本稿で提案するチーム独自の運用合意の切り分け。