PI（Program Increment）プランニングとは、SAFeにおける最も重要なイベントで、ARTに関わる全チームが一堂に会して、次の8〜12週間（通常5スプリント）の計画を立てる2日間のイベントです。

【PIプランニング前】

• チームバックログの整備支援（PBIの優先順位確認・リファインメント）
• チームメンバーへのSAFeプロセス教育（特に初参加者向け）
• 前PIのベロシティ・完了率などのデータ整理
• キャパシティ計算（祝日・有給・他プロジェクト稼働を考慮）
• ロジスティクス調整（会場・ツール・参加者調整）

【PIプランニング中】

• チームのブレイクアウトセッションのファシリテーション（タイムキーピング・議論促進）
• 障害・依存関係を即時RTEにエスカレーション
• チームが現実的なコミットメントをできるよう支援（過剰コミット防止）
• 信頼投票の実施と懸念事項の収集・対応

【PIプランニング後】

• PIオブジェクティブをチームに見える場所に掲示・共有
• 依存関係の継続的なトラッキング（毎週ART Syncで確認）
• Owned/MitigatedリスクをART Syncで継続追跡
• 各スプリントでPIオブジェクティブとの照合・差異の早期発見

ARTイベントとは、SAFeにおいてART全体が同期するための定期的なイベント群です。複数チームが同一ケイデンスで動き、大規模な整合性を維持します。

共通のミッションとビジョンに向かって協働する、5〜12チーム（50〜125人）の長期的な自己組織化チームの集合体です。SAFeの基本デリバリー単位です。

• 電車（Train）のメタファー：定刻（PIケイデンス）で出発し、乗り遅れたら次のPIを待つ
• 固定メンバー：プロダクト・エンジニアリング・ビジネスが一体となった仮想組織
• 主要役割：RTE（リリーストレインエンジニア）・プロダクトマネージャー・システムアーキテクト
• 継続的デリバリー：すべてのPIで価値あるソリューションを届けることを目指す

SAFeには4つのコアバリューがあります。すべての手法・イベント・ツールの基盤となる価値観です。

① Alignment（整合性）

全階層（ポートフォリオ→プログラム→チーム）が戦略目標に整合する状態。PIプランニングが主な整合メカニズムです。整合がないと、各チームが独立して動き価値が届かなくなります。

② Built-in Quality（組み込み品質）

品質は後から追加するのではなく、開発プロセスに最初から組み込む考え方。TDD・CI/CD・DoDが実践手段です。品質の欠如は最終的に速度を下げます。

③ Transparency（透明性）

進捗・リスク・課題・失敗をすべてのステークホルダーに包み隠さず可視化する。プログラムボード・フローメトリクスで実現します。隠蔽は信頼を破壊し、問題の早期発見を妨げます。

④ Program Execution（プログラム実行）

計画よりも、実際に動くプロダクトを届けることにフォーカス。「動くソフトウェアが最高の進捗報告」という精神を大規模組織で実現します。

SAFeには10の原則があります。特に重要な上位5〜6つを深く理解しておきましょう。

WSJFは「最も短い時間で最大のビジネス価値を生む仕事を最優先にする」という考え方に基づいた優先順位付け手法です。

実践手順

1. バックログの各フィーチャーを BV・TC・RR/OE・JS で相対評価する（フィボナッチ数列：1,2,3,5,8,13,20）
2. 絶対値ではなく相対比較でスコアリングする（プランニングポーカーと同じ考え方）
3. WSJF値の高い順にフィーチャーを並べ替える
4. チーム・ビジネスオーナー間で合意形成し、PIプランニングに持ち込む
5. PI実行中・次PI準備でも継続的に見直す（一度決めて終わりではない）

BV（Business Value）とは、PIプランニング中に、PIオブジェクティブそれぞれに対してビジネス側が付与する価値スコア（通常1〜10）です。

使用場面と役割

• PIプランニング中に、ビジネスオーナーがチームのPIオブジェクティブを評価する
• チームは「計画BV（Planned BV）」を設定し、ビジネス側が「実績AV（Actual AV）」を評価する
• PI終了後にPlanned BV vs Actual BVを比較し、プログラム予測精度を測定する
• 10点＝戦略的に最重要、1点＝あれば良いが優先度低

スクラムマスターの役割

• チームがビジネス価値を理解してオブジェクティブを設定できるよう支援する
• BVスコアの根拠をステークホルダーから引き出すファシリテーションを行う
• スコアが低い場合→なぜ価値が低いか理解し、オブジェクティブを修正する

AV（Actual Value）とは、PI終了時にビジネス側が評価する、PIオブジェクティブの実際の達成価値スコアです。

予測精度が常に100%の場合は過小コミットしている可能性があります。差分を分析して次PIの精度向上につなげましょう。

1. チームがドラフトのPIオブジェクティブを作成する（「何を達成するか」を具体的・測定可能な形で記述）
2. ビジネスオーナーがBVを付与する（1〜10点）：10点＝戦略的最重要、1点＝優先度低
3. チームとビジネスオーナーが対話する（スコアが低い場合はオブジェクティブの修正を検討）
4. Uncommitted Objectivesは別管理（BVは付与するが達成できなくてもPIの成否に影響しない）
5. PI終了時にAVを評価し、Planned BV vs AVの差分をI&Aで分析する

RTE（Release Train Engineer）とは、ARTレベルのスクラムマスターであり、ART全体のコーチ・ファシリテーターです。

主な責務

• PIプランニング・システムデモ・I&AなどARTイベントのファシリテーション
• ART全体の障害除去とエスカレーション
• 複数チーム間の依存関係調整
• チームのスクラムマスターへのコーチング
• メトリクス収集と可視化（フロー・品質・予測精度）
• ステークホルダー管理とコミュニケーション

ROAMとは、PIプランニング中に特定されたリスクを4つのカテゴリに分類し、対応方針を合意するフレームワークです。

SMのファシリテーション手順

1. 付箋またはデジタルボードでリスクを全員が書き出す（ブレインストーミング形式）
2. 1つずつ声に出して読み上げ、全体で4分類に仕分ける
3. O・Mのリスクには「誰が・いつまでに」を必ずセットで決める
4. Acceptedのリスクはビジネスオーナーに明示的に同意を取る
5. 全リスクをROAMボードに記録し、ART Syncで毎週ステータスを更新する

1. PIプランニング中にプログラムボードで依存関係を矢印で可視化する
2. 各依存関係に「提供チーム」と「受け取りチーム」を明確にする
3. 毎週のART Sync（スクラム・オブ・スクラム）で進捗と障害を確認する
4. 赤い矢印（未解決の依存関係）をゼロに近づけることを目標にする
5. 解消できない依存はRTEを通じてエスカレーションし、組織的に対処する

プログラムボードは、PIプランニングのアウトプットとして作成される、複数チームのフィーチャーと依存関係を可視化したボードです。

システムデモとは、ART全体で統合されたインクリメントをステークホルダーにデモする場です。各チームのスプリントレビューとは異なり、「全チームの成果を統合した状態」でデモします。

• 個別チームが順調でも統合すると動かない・期待した価値になっていないことを早期発見できる
• ステークホルダーの早期フィードバック獲得に有効

Inspect & Adapt（I&A）は、PI終了後に行うART全体の振り返りと改善の場です。単なるレトロスペクティブではなく、ART全体・システム全体・進め方全体を見直します。

3部構成で実施

1. PI System Demo：PI全体の統合デモ。全スプリントの成果を統合した状態でステークホルダーにデモする
2. 定量的問題分析：フローメトリクス・予測精度・品質指標を確認。根本原因分析（5 Why等）を実施する
3. 改善ワークショップ：特定した課題に対して改善アクションを策定。次PIへの入力とする

IP（Innovation & Planning）スプリントとは、PIの最後のスプリント（通常スプリント5）のことです。通常の開発作業は行わず、4つの目的のために使います。

• 「作業が遅れたときに埋め合わせるバッファスプリント」ではない
• IPスプリントに機能開発を詰め込むと本来の4つの価値がすべて失われる

• チームがIPスプリントを「休息週間」にしないよう意義を説明する
• 革新アクティビティ（ハッカソン等）の企画ファシリテーションを行う
• 次PIプランニングに向けたバックログリファインメントを推進する

SAFeでは6つのフローメトリクスを用いて、価値の流れを測定・改善します。

CFD（Cumulative Flow Diagram）とは、バックログ・進行中・完了の各ステータスにある作業量を時系列で積み上げ表示したグラフです。

• WIPの増減をリアルタイムで可視化：帯の幅が広がっている＝WIPが増えている（ボトルネックのサイン）
• リードタイムの変化：帯の傾き角度でスループットと平均リードタイムを把握する
• スコープ変化の検知：上端のラインが急に上がる場合はスコープ追加が発生している

プログラムカンバンとは、ARTレベルでフィーチャーの流れを可視化し、WIPを制限してフロー効率を高めるカンバンボードです。チームバックログに入れる前段階のフィーチャー管理ツールです。

Jira Alignとは、SAFeのような大規模アジャイルフレームワークを支援するエンタープライズ向けポートフォリオ管理ツールです（Atlassian社製）。

• ポートフォリオ→プログラム→チームの3階層を一元管理できる
• デジタルPIプランニングのサポート：オンラインPIプランニングで主要ツールとして活用
• プログラムボードのデジタル化：依存関係・マイルストーン・フィーチャーをリアルタイム管理
• ROAMリスクの管理：リスクの分類・担当者アサイン・進捗追跡
• フローメトリクスのダッシュボード：予測精度・BV vs AV・ベロシティをリアルタイム表示
• Jiraとの統合：チームレベルのJiraデータを上位計画に自動反映

スクラムとは、複雑な問題に対応するためのフレームワークで、価値の高いプロダクトを反復的・漸進的に届けます（スクラムガイド2020）。

⚠️ 右辺も重要ですが、左辺をより重視するという意味です。

12の原則（特に重要なもの）

• 価値あるソフトウェアを早く継続的に届ける
• 要件変更を歓迎する（たとえ開発後期でも）
• 動くソフトウェアを数週間〜数ヶ月ごとに届ける
• ビジネスと開発者は毎日協働する
• 信頼できる人々に環境と支援を与え、仕事を任せる
• 動くソフトウェアが進捗の主要な尺度
• 持続可能なペースで開発を継続
• シンプルさ（やらない作業量を最大化すること）
• 自己組織化チームが最良のアーキテクチャ・要件・設計を生む
• 定期的にチームの効果を振り返り調整する

スクラムは経験的プロセス制御理論（経験主義）に基づいており、3つの柱で支えられています。

① 透明性（Transparency）

プロセスと作業を担当者全員が見える状態にします。実践例：プロダクトバックログの公開・DoDの明確化・スプリントボードのオープン化

② 検査（Inspection）

アーティファクトと目標達成の進捗を頻繁に検査します。実践例：スプリントレビュー・デイリースクラム・レトロスペクティブ

③ 適応（Adaptation）

問題が発見されたらプロセスや成果物を調整します。実践例：バックログリファインメント・スプリント中の計画修正・レトロのアクション実施

スクラムマスターはサーバントリーダーとして、3方向に対して責務を持ちます。

• チームメンバーへの指示・命令はしない
• タスクのアサインはしない（チームが自己組織化して行うこと）
• スプリントゴールの決定は自分ではしない（チームとPOの仕事）
• チームの代わりに問題を解決しない（チームが自律的に解決できるよう支援する）

1. 可視化：デイリースクラムで「今日の障害は何か？」を確認。障害リスト（Impediment Backlog）を作成・全員に公開する
2. 分類：チーム内で解決可能か？チーム外の支援が必要か？を判断する
3. 対応：技術的な問題→IT部門・アーキテクトへ連絡、人間関係→コーチング・1on1、外部依存→RTE経由で組織調整
4. 追跡と完了確認：障害が実際に解消されたか確認する。再発防止のためレトロスペクティブで根本原因を議論する

サーバントリーダーシップとは、リーダーがチームに「奉仕する」ことで、チームの能力を最大化するリーダーシップスタイルです。Robert Greenleafが提唱し、スクラムの根幹にある考え方です。

スクラムマスターとしての実践

• “どうすれば解決できると思う？” と問いかける（答えを与えない）
• チームの障害を取り除くために組織に働きかける
• 自分の「承認」を必要としない意思決定をチームに促す
• チームの成功を自分の成功と捉える

目的：スプリントで「何を」「どうやって」届けるかを計画する。タイムボックスは1スプリント1時間/週が目安（2週間スプリントなら最大4時間）。

• スプリントゴールを最初に確定する
• バックログアイテムの整備はプランニング前に完了させておく（DORの確認）
• キャパシティを数値で提示し、過剰コミットを防ぐ
• 全員が理解・コミットしているかを確認してから終了する

• POが未準備：事前のバックログリファインメントを徹底する
• チームが過剰コミット：実績ベロシティを見せてリアルな計画に誘導する

目的：15分以内でスプリントゴールに向けた進捗を同期する。進捗報告会ではなく、チームが計画を自律的に調整するための場。

• デイリースクラムの主体はDevelopers。SMは必要に応じてファシリテーションを支援する
• 時間を守る（15分厳守）。詳細な議論は「アフタースクラム」に誘導する
• チームがゴールを意識して話せているかを確認する

• 進捗報告会にしない（マネジメントへの報告の場ではない）
• SMがすべての発言を整理・まとめる必要はない

目的：インクリメントをステークホルダーに披露し、フィードバックを得る。SMはイベントが目的に沿って効果的に行われるよう支援・ファシリテートする。タイムボックスは1スプリント1時間/週が目安。

• デモ環境の準備支援（技術的な準備はチームと協力して事前に確認しておく）
• ステークホルダーを積極的に議論に参加させる（一方的なプレゼンにしない）
• 「完成」の定義（DoD）に合致しているかを確認する（未完了は含めない）
• フィードバックをバックログに反映するようPOを支援する
• チームの努力を認め、祝う文化を醸成する

目的：チームがプロセス・関係性・ツールを改善する場を支援・ファシリテートする。タイムボックスは1スプリント1.5時間/週が目安。

• 心理的安全性の確保：「これは批判の場ではなく学びの場」と明示する
• 具体的なアクションアイテムの合意：担当者・期日付きで決める
• 前回のアクションの振り返り：「実施できたか？」を最初に確認する

DoR（Definition of Ready）とは、バックログアイテムがスプリントプランニングに持ち込める状態になったかを判断するための現場プラクティスです。

• 受け入れ基準（Acceptance Criteria）が明確に定義されている
• チームが見積もりできる粒度まで分解されている
• 依存関係が解消されている（または計画されている）
• ビジネス価値が明確になっている
• UIモックアップ・API仕様など必要な情報が揃っている

DoD（Definition of Done）とは、プロダクトインクリメントが「完成した」と言えるための条件リストです。チームとステークホルダー全員が合意している必要があります。

• コードがレビュー済みでメインブランチにマージされている
• 自動テスト（ユニット・統合）がすべてパスしている
• ドキュメントが更新されている
• ステージング環境でデプロイ・動作確認済み
• 受け入れ基準をすべて満たしている

ベロシティとは、チームが1スプリントで完了するストーリーポイントの平均値です。チームの生産能力の内部指標として使用します。

• スプリントプランニング：次スプリントで取り込めるポイント数の基準として使用する
• リリース計画：残バックログ ÷ 平均ベロシティ ＝ 残スプリント数を予測する
• 改善施策の効果測定：レトロの改善アクション後のベロシティ変化を確認する

• ベロシティを「上げること」を目標にしない→品質低下・燃え尽きの原因になる
• チーム間のベロシティ比較に使わない→見積もり基準が異なるため意味がない
• 管理者がベロシティを「目標値」として設定すべきではない

ストーリーの見積もりには相対見積もりを使います。絶対時間（時間・日数）ではなく、ストーリーポイント（相対的な複雑さ・労力）で表現します。

• フィボナッチ数列（1, 2, 3, 5, 8, 13, 21）が最もよく使われる
• Tシャツサイズ（XS/S/M/L/XL）を使うチームもある
• まず「基準ストーリー（例：3ポイント＝このくらいの規模）」を決めてから見積もりを始める
• チーム全員で見積もることでナレッジを共有できる

プランニングポーカーとは、チーム全員がカードを同時に開示することで合意形成バイアスを排除し、全員の意見を均等に反映する見積もりゲームです。

1. POがストーリーを説明する
2. 全員が見積もりカードを選ぶ（まだ見せない）
3. 全員が同時にカードを開示する（同時開示が最重要ポイント）
4. 最高値・最低値のメンバーが理由を説明する
5. 議論した後、再度見積もりを実施する（合意するまで繰り返す）

ストーリー分割とは、大きすぎるユーザーストーリーを、1スプリントで完了できる小さな単位に分割するテクニックです。

バーンダウンチャートとは、スプリント期間中に残っている作業量（ストーリーポイント）を時系列で表示した折れ線グラフです。

• 理想線（直線）と実際の残作業線を比較してスプリントゴール達成可能性を判断する
• 右肩下がりの曲線が理想（毎日作業が減っている）
• 横ばいや上昇が続く場合は障害・スコープ追加が発生しているサイン

バーンアップチャートとは、完了した作業量（ストーリーポイント）とスコープ合計を時系列で表示した2本のグラフです。

リードタイムとは、顧客がリクエストを出した時点（バックログに入った時点）から、価値が顧客に届く（デプロイ・完了）までの経過時間です。

• WIP制限：仕掛中の作業量を減らして完了速度を上げる
• バッチサイズ削減：大きなフィーチャーを小さく分割して早く届ける
• 依存関係解消：待ちの時間を減らす
• 承認フロー短縮：レビュー・承認にかかる待ち時間を削減する

サイクルタイムとは、実際に作業を開始した時点から完了するまでの経過時間です。

スループットとは、一定期間（例：1スプリント）に完了した作業アイテムの数です。ストーリーポイントではなく「アイテム数」で測ります。

• チームの生産性を客観的に把握できる
• 予測モデル（モンテカルロシミュレーション）の入力データとして使用できる
• ポイント見積もりを使わない「ノーエスティメーション」アプローチで活用される

• スプリントプランニング：次スプリントで取り込めるポイント数の基準として使用する
• リリース計画：残バックログ ÷ 平均ベロシティ ＝ 残スプリント数を予測する
• 改善施策の効果測定：レトロの改善アクション後のベロシティ変化を確認する
• キャパシティ管理：メンバー変更・休暇等によるベロシティ変動を計画に反映する

• ベロシティを「上げること」を目標にしない：品質低下・燃え尽きの原因になる
• チーム間のベロシティ比較に使わない：見積もり基準が異なるため意味がない

1. 変更を直接受け取らない：必ずPOを通じて対処するよう丁寧に伝える
2. スクラムのルールを説明：「スプリントバックログはチームのもの。スプリント中の変更は原則禁止です」と伝える
3. POへの橋渡し：追加要求をプロダクトバックログに追加し、次スプリントの候補として検討する
4. 緊急の場合のみ：スプリントキャンセルまたはトレードオフ（既存作業を外す）を検討する

ステークホルダーへのコミュニケーション例

「ご要望はプロダクトバックログに追加し、次スプリントの候補として検討します。今スプリントの変更はチームの集中を妨げ、コミットを守れなくなるリスクがあります。」

まず事実確認（パニックにならない）：急落は1スプリントだけか、複数継続しているか？チームの人数に変化はあったか？

よくある対立パターン：「なぜこんなに時間がかかるのか」vs「技術的制約を理解してほしい」、「要件を変えたい」vs「今さら変えないでほしい」

1. 個別ヒアリング：双方の立場・懸念・期待を別々に聞く。感情論ではなく、事実と影響を整理する
2. 対話の場を設定：双方が安心して話せる中立的な場を作る。SM自身は判定者ではなく、ファシリテーターに徹する
3. 共通ゴールを確認：「両者とも良いプロダクトを届けたい」という共通点を強調する
4. 合意の形成：技術的制約をPOが理解できる言葉で可視化。優先順位の意思決定権はPOにあることを明確にしつつ、影響を透明に伝える

抵抗の根本原因を理解する：「今のやり方で問題ない」という信念・変化への不安・過去のアジャイル導入失敗経験・「名ばかりアジャイル」への不信感など

• 強制しない・問いかける：「今のプロセスでどんな課題を感じていますか？」
• 小さな実験から始める：まずデイリースクラムだけ。「2週間だけ試して、効果がなければ元に戻す」と約束する
• 成功体験を作る：小さな改善を「見える化」して、チームが変化のメリットを体感できるようにする
• 心理的安全性の確保：「失敗しても責めない」文化を構築。実験・学習・改善のサイクルを繰り返す

1. 参加しない理由を個別にヒアリングする（強制的に解決しない。まず「聴く」）
2. セレモニーの「目的と価値」を改めて説明する（形式的に感じている可能性がある）
3. セレモニーの内容・時間・進め方を改善する（「何を得られるか」が見えていないとき）
4. チームで「作業協定（Working Agreement）」を作り、参加を共通ルール化する

1. プログラムボードまたはスクラム・オブ・スクラムで依存関係を可視化する
2. ブロックされているチームと提供側チームを直接つなぎ、対話を促進する（チケットのやり取りではなく直接会話）
3. 解消できない場合はRTEにエスカレーションし、組織レベルで対処する
4. 再発防止策として、PIプランニング時の依存関係の洗い出し精度を向上させる
5. ART Syncを活用してクロスチームの依存関係を毎週確認する

1. ステークホルダーの懸念を丁寧にヒアリングする（「アジャイル＝管理できない」という誤解が多い）
2. アジャイルの透明性・予測可能性・早期リスク発見のメリットをビジネス言語で説明する
3. スプリントレビューやシステムデモに招待し、実際の成果を体感してもらう
4. 定量的な成果データ（ベロシティ・リードタイム・品質指標）を提示する
5. RTEやアジャイルコーチと連携し、組織変革を支援する

1. まず障害対応を最優先させ、スプリントゴールの達成可否を正直に判断する
2. POに状況を即時報告し、スプリントバックログのトリアージ（優先順位の再設定）を支援する
3. 障害対応チームと開発チームのコミュニケーションを橋渡しする
4. レトロスペクティブで根本原因を分析（5 Whyを活用）し、再発防止策を立案する

1. 1on1や匿名アンケートでチームの状態を把握する（まず「聴く」）
2. 過剰コミットが原因なら、キャパシティに基づいた現実的な計画に修正する
3. 割り込みや緊急対応が多い場合、バッファを確保するか優先順位ルールを明確化する
4. 業務外学習の強制がある場合は排除し、持続可能なペースを守る
5. SMが組織に対して「チームへの過剰な負荷」を明示し、シールド（防波堤）の役割を果たす

• ツールの統一：Slack・Teams・Zoom等のコミュニケーションチャンネルを一本化する
• 作業の見える化：Jiraやデジタルカンバンボードで全員が進捗を確認できる状態にする
• オーバーラップ時間の確保：タイムゾーンが異なる場合、全員が参加できる時間帯をデイリースクラムに設定する
• 非同期コミュニケーションのルール化：回答期待時間・形式・チャンネルを事前に合意する
• 定期的な顔合わせ：可能であれば四半期に一度の対面（またはPIプランニング時）を実施する
• 心理的安全性の構築：オンラインでも「発言しやすい」文化を意識的に作る

1. まず1on1で個人の状況・悩み・障害を聴く（評価・批判しない。SMは評価者ではなくコーチ）
2. パフォーマンス低下の原因を特定する（技術的問題・モチベーション・個人的な事情・チームとの関係性）
3. 原因に応じたサポートを提供する（学習機会・ペアプログラミング・業務調整等）
4. 改善が見られない場合は、マネージャーや人事との連携を検討する

1. 実際のキャパシティ（稼働日数・ベロシティ実績）を数値で可視化する
2. スプリントプランニングで「このポイント数は過去の実績から見て現実的か？」を問いかける
3. 過剰コミットが繰り返される原因（外部からのプレッシャー・完璧主義等）を探る
4. 「コミットメントを守ること」の価値をチームと共有する（信頼性の積み上げが長期的な評価に繋がる）

• フォーマットを変える：毎回同じ形式では飽きる。Start/Stop/Continue → 4Ls → Mad/Sad/Gladと変えてみる
• アクションを小さく具体的にする：「コミュニケーションを改善する」でなく「毎週火曜に15分の技術共有をする」
• 前回のアクションを確認する：「やった・やれなかった」を最初に確認することで継続性が生まれる
• 心理的安全性を高める：匿名付箋の活用・SMが最初に「自分の失敗」を共有する
• 時間帯・場所を変える：オフサイトやカジュアルな場での開催も効果的

1. POの状況を把握する（多忙で物理的に参加できない？役割を理解していない？）
2. POの関与がない場合の「コスト」を可視化する（手戻り・手待ち・方向性のズレのリスク）
3. POのセレモニー参加に向けた具体的なスケジュール調整を支援する
4. それでも改善しない場合、RTEまたはマネジメントにエスカレーションする

• レトロスペクティブの記録：毎スプリントの学びとアクションをページとして蓄積する
• チームの作業協定（Working Agreement）の掲示：全員がいつでも参照できる場所に公開する
• PIオブジェクティブの共有：チーム内外に見える形で掲示・更新する
• ナレッジベース：よくある障害と解決策・技術ドキュメントを文書化する
• ステークホルダー向けプロジェクト状況ページ：スプリント進捗・リスク・次アクションを定期更新する
• DoDの掲示：チームのDoDをConfluenceで管理し、スプリントレビュー前に参照できるようにする

• デジタルPIプランニング：オンラインPIプランニングで主要ツールとして活用する
• デジタルプログラムボードの管理：フィーチャー・依存関係・マイルストーンをデジタルで可視化
• ROAMリスクの管理：リスクの分類・担当者アサイン・期限設定・進捗追跡を一元管理する
• フローメトリクスのダッシュボード：予測精度・BV vs AV・フローベロシティをリアルタイムで確認
• ポートフォリオ管理：エピック→フィーチャー→ストーリーの階層整合をJiraと連動して管理する
• ART Syncのサポート：クロスチームの依存関係・障害・PIオブジェクティブの進捗を毎週更新する

アジャイルダッシュボードは、チームの状態とプロセスを一目で把握できる「情報ラジエーター」として機能させることが重要です。

• Jiraのビルトインレポート活用：バーンダウン・ベロシティ・スプリントレポートを活用する
• カスタムダッシュボード：WIP・完了数・障害数・スプリントゴール達成率を一覧表示する
• 更新頻度：スプリント毎に必ず更新し、最新の状態を維持する
• 閲覧者を意識した設計：チーム向けと経営層向けは必要な情報が異なる

• Jiraとの連携：Power BIコネクタまたはAPIでJiraデータを取得し、レポートを自動更新できる
• ベロシティトレンド：複数スプリントのベロシティ推移を折れ線グラフで可視化する
• フローメトリクスの可視化：リードタイム・サイクルタイム・スループットのトレンド表示
• クロスチーム分析：複数チーム・複数PIをまたいだ横断分析がJira単独より容易に実施できる
• ステークホルダー向けレポート：経営層向けにKPIを分かりやすく視覚化して自動配信する

• バックログ管理：エピック・フィーチャー・ユーザーストーリー・タスクを階層管理できる
• スプリントボード：カンバンボードでWIPを可視化。スプリントバックログをドラッグ&ドロップで管理する
• CI/CDパイプライン：Azure Pipelinesでビルド・テスト・デプロイを自動化（Built-in Quality（組み込み品質）の実現に直結）
• テスト管理：Azure Test Plansでテストケースを管理し、DoDの達成を追跡する
• レポート：ビルトインのスプリントバーンダウン・累積フロー図（CFD）を活用する

• デジタルプログラムボード：スプリント×チームのグリッドを作成し、フィーチャーカードと依存関係の矢印をリアルタイムで可視化する
• ROAMリスクボード：付箋で洗い出したリスクを4象限（R/O/A/M）に分類するファシリテーションに使用する
• レトロスペクティブ：4Ls・KPT等のテンプレートで分散チームのレトロを実施する
• タイムライン作成：PI全体のマイルストーンをタイムライン形式で可視化する
• ブレインストーミング：付箋＋投票機能で参加者の意見収集と優先順位付けを効率化する