SAFe実践から見えた、フレームワークより大切な組織変革の道程(Scrum Fest Sendai 2025 発表資料)

© 2025 NTT DATA Group Corporation
Scrum Fest Sendai 2025
SAFe実践から見えた、
フレームワークより大切な
組織変革の道程
2025年8月30日
NTTデータグループ平井翔一郎

© 2025 NTT DATA Group Corporation 2
はじめに
Target Audience
• 大規模アジャイル導入を検討・推進している方
• アジャイルな組織の設計に課題を感じている実践者
Learning Outcome
• 自組織の特性を分析し、適切な大規模アジャイルフレームワークの選択判断を行える
• チームの自律性と組織全体の整合性を両立する目標設定の仕組みを設計できる
• チームの自己肯定感を高める具体的な施策（ウィンセッション等）を自組織で行える
• SAFeのFW自体はそんなに悪いものでもないと思える
注意事項
• 本セッションは個人の経験や学びにもとづく見解であり、所属する企業や部門を代表するものではありません
• 本スライドはslideshareにて公開予定です

アジェンダ
1. 自己紹介
2. 本講演の対象となる組織と
プロダクトの紹介
• 食品ビジネス推進部
• 「あい作」プロジェクトのご紹介
• 体制図
3. 選択
• 大規模アジャイル手法の種類
• PI Planning
4. 適用
5. 成果と学び
6. まとめ

01
自己紹介

経験と専門分野
• 金融機関のお客様の情報系システムを中心に
WF型の開発に従事
• アジャイルプロジェクトを担当したことが契機となり、
全社のアジャイル支援を行う部署へ異動
• スクラムマスター/アジャイルコーチとして、
自動車・官公庁・保険・エネルギー系のお客様を担当
• 2025年度より生成AIを活用したソフトウェア開発の手法検討、
日本国内案件への普及展開
保有資格
• PMP、Scrum Allianceの各種資格他
• JFA公認D級コーチ、サッカー4級審判員
自己紹介
平井翔一郎
株式会社NTTデータグループ
技術革新統括本部 AI技術部

スライドのURL
過去の登壇
これまで、アジャイルな計画の立て方・アジャイルなソフトウェア開発の方法・
アジャイルな品質管理について登壇してきました。
スライドのURL
スライドのURL 動画のURL（YouTube）動画のURL（YouTube）
XP祭り
動画のURL（YouTube）
スクラム
フェス
大阪
スクラム
フェス
大阪

宣伝
9月と10月に私が実行委員、オーガナイザーをやっている3つのカンファレンスが開催されます
参加者絶賛募集中です、よろしくお願いします！
InnerSource Gathering
Tokyo
スクラム祭り XP祭り
2025/9/12(金) 2025/10/3(金)～10/4(土) 2025/10/4(土)
オンライン：なし
オンサイト：docomo R&D
OPENLAB ODAIBA
オンライン：あり
オンサイト：全国各地のサテライ
ト会場
オンライン：あり
オンサイト：三菱電機
INNOVATION HUB（横浜）

NTTデータグループのご紹介
情報技術で新しい「しくみ」や「価値」を創造し、より豊かで調和のとれた社会の実現に貢献。
グループ全体で約20万人の社員が、世界50以上の国と地域、200を超える都市においてサービスを展開。
拠点 (2025年3月31日時点）
北米
17,100+
中南米
22,900+
日本
47,100+
10,500+
中国
4,700+
中東
アフリカ
10,000+
欧州
48,000+
インド
37,100+
197,800+人
APAC
基本情報
株式会社NTTデータグループ
東京都江東区豊洲三丁目3番3号
1988年5月23日
142,520百万円
連結：197,800人
(2025年3月31日時点)
◼ 会社名（商号）
◼ 本社
◼ 設立年月日
◼ 資本金
◼ 従業員数
（グループ全体）
4月1日から翌年3月31日まで
6月
東京証券取引所プライム市場
証券番号9613
三井住友信託銀行株式会社
有限責任あずさ監査法人
◼ 事業年度
◼ 定時株主総会市場
◼ 株主名簿管理人
◼ 会計監査人

40.4%
57.5%
2.1%
65.5%
32.0%
2.5%
※2019年3月期より国際財務報告基準（IFRS）を適用しています。
総資産
7兆,7,774億円
売上高
4兆6,387億円
営業利益
3,239億円
従業員数
約197,777人
（50カ国・地域超、国内を含む）
連結子会社
611社 2025年3月末時点
NTTデータグループ
日本
売上高
19,332億円
営業利益
2,052億円
その他
海外
売上高
27,509億円
営業利益
1,002億円
事業の多様化を推進するビジネスポートフォリオ
売上高（外円）／営業利益（内円）
会社全般｜財務データ事業セグメント別業績（2025年3月期）

取締役会
社長
監査等委員会
監査等委員会室コストセンタ
技術革新統括本部グローバル技術戦略推進部
グローバルアーキテクト推進部
AI技術部
Innovation技術部
品質保証部
経営会議
コーポレートスタッフ
グループ経営企画統括本部コーポレート戦略本部
サステナビリティ経営推進本部
グローバルイノベーション本部
コンサルティング & ビジネスアクセラレーション本部
プロキュアメント部
財務部 IR室
人事本部
グローバルガバナンス本部
グローバルマーケティング & コミュニケーション本部
ITマネジメント室
監査部
株式会社
NTT データグループ
株式会社
NTT データ
株式会社
NTT DATA, Inc.
日本リージョン
海外リージョン
2025年7月1日現在
会社全般｜組織図（NTTデータグループ社）

会社全般｜組織図（NTTデータ社）
取締役会
社長
監査役
監査役室
経営会議
コーポレートスタッフ
経営企画本部
業務統括本部
コンサルティング & ビジネスアクセラレーション本部
監査部
株式会社
NTT データ
グループ会社
2025年7月1日現在
公共・社会基盤分野
第一公共事業本部
第二公共事業本部
第三公共事業本部
第四公共事業本部
社会基盤ソリューション事業本部
テレコム・ユーティリティ事業本部
金融分野
第一金融事業本部
第二金融事業本部
第三金融事業本部
金融イノベーション本部
金融高度技術本部
法人分野
インダストリ統括本部
第一インダストリ統括事業本部
第二インダストリ統括事業本部
コンサルティング事業本部
ペイメント事業本部
システムインテグレーション事業本部
テクノロジーコンサルティング＆ソリューション分野
テクノロジーコンサルティング事業本部
ソリューション事業本部
第二金融事業本部
食農ビジネス
推進部

02
本講演の対象となる
組織とプロダクトの紹介

食農ビジネス推進部の役割
JAグループ様の信用事業であるJAバンク様のご支援に加え、
食農領域においても、JAグループと農業に従事されている皆様の業務をご支援
総合事業での
価値創出
価値提供価値提供
対価対価
• 農業従事者
• 地域住民
弊社
食農の取り組み領域（地域区々の取り組みを直接支援）
信用領域の取り組み（主に全国システムで貢献）
JAグループ

食農ビジネス推進部の「あい作」プロジェクト
https://aisaku.nd-agri.jp/

「あい作」が提供するプロダクト
「あい」にあふれた地域コミュニティの創造のための5つのプロダクトを現在提供中
「あい作」のロゴマークは、トンボをモチーフにしています。
特定の環境下でしか生息できないトンボは、水質をはじめとする
自然環境の健康状態を表す指標ともされる生物です。
私たちが提供する「あい作」もいつまでもトンボが飛び交うような
健全な地域コミュニティを持続させるソリューションでありたいとの思いが
込められています。
また、トンボの前方にしか飛ばない不退転に倣い、より良いサービスを
求めて常に前進し続けるという私たちの意思の表れでもあります。
トンボについて
－健全なコミュニティ環境の象徴ー

5つのプロダクト 1/5 栽培管理ソリューション
農業協同組合、農事組合法人と生産者双方から利用するクラウドサービスです。
栽培計画、栽培記録、連絡・相談をスマートフォン・タブレット・PCから利用でき、
産地の営農活動の高度化・効率化を支援します。
https://aisaku.nd-agri.jp/solution/01

5つのプロダクト 2/5 資材受注ソリューション
農業協同組合における資材購買業務を変革するITソリューションです。
JA特有のニーズに応える使いやすいECサイトを最短2週間でスピード構築。
職員様の生産性向上と組合員様の満足度向上を実現します。

5つのプロダクト 3/5 出荷予測ソリューション
気象の影響を受けやすい露地栽培などの農作物の収穫時期や収穫量の予測を可能にする
システムです。栽培情報、生育情報、気象情報等をインプットに産地独自の予測アルゴリズム
で生成した出荷予測データを農家の農業経営やJAの選果、販売活動に活用することで、
産地全体の販売力向上や業務合理化に寄与します。

5つのプロダクト 4/5 組合員マイページ
組合員マイページは、コアな組合員様とのコミュニケーションに特化したソリューションです。
各JAの特色に合わせて簡易に構築可能とします。
https://aisaku.nd-agri.jp/union-mypage
https://aisaku.nd-agri.jp/union-mypage

5つのプロダクト 5/5 職員マイページ
https://aisaku.nd-agri.jp/staff-mypage
https://aisaku.nd-agri.jp/staff-mypage
組合員を中心に、営農指導事業、信用事業、共済事業、その他事業の各領域において、
分断されバラバラで管理されているデータと渉外業務を繋ぎ直し、
ひとつのプラットフォームに統合することが可能な総合事業の営業支援サービスソリューション
（CRM・SFA）です。

食農ビジネス推進部の体制図（2024年1月時点）
組織長の配下には3人のマネージャーがいて、各マネージャーの配下に複数チームが存在
組織長
マネージャーマネージャーマネージャー
PO
SM
PO
SM
Dev
（B社）
PO
SM
チーム
リーダー
PO
SM
Dev
（A社）
PO
SM
Dev
（C社）
チーム
リーダー
Dev
（A社）
チーム
リーダー
担当者
チーム
リーダー
担当者
栽培管理
プロダクト担当
スクラムチーム
出荷予測
資材受注
CSチーム
組合員
マイページ
職員
マイページ
インフラチーム
Dev
（A社）
Dev
（B社）
Dev
（A社）
営業チーム
マーケティング
チーム

成果の共有が
出来ていない
組織の現状課題
複数プロダクトを抱える組織の3つの課題
チーム間の
情報共有が不足
ビジネスバリューの
意識が欠如
プロダクト間の連携が弱く
重複作業や相反する意思決定が発生。
部門間のサイロ化が進行している
プロダクトとしては前に進んでいるものの
組織全体でのフィードバックができておらず
盛り上がりに欠けている
技術的な成果は出ているが
顧客価値への貢献が不明確で
市場投入のタイミングが
最適化できていない

情報共有
課題1：チーム間の情報共有が不足
基本的にマネージャー単位で情報共有されるので、
情報のスピードや情報量が欠けることも多い（事実は伝わるが、背景迄は伝わらない）
組織長
栽培管理
出荷予測
資材受注
CSチーム
組合員
マイページ
職員
マイページ
インフラチーム営業チーム
チーム

情報共有
組織長
栽培管理
出荷予測
資材受注
CSチーム
組合員
マイページ
職員
マイページ
チーム

課題2：成果の共有が出来ていない
新しく機能を作ること、改修することが当たり前になっていて、
組織全体でのフィードバックや盛り上がりが欠けている気がする
組織長
栽培管理
出荷予測
資材受注
CSチーム
組合員
マイページ
職員
マイページ
チーム
新しい機能を
リリースしました！

課題2：成果の共有が出来ていない
新しく機能を作ること、改修することが当たり前になっていて、
組織全体でのフィードバックや盛り上がりが欠けている気がする
組織長
栽培管理
出荷予測
資材受注
CSチーム
組合員
マイページ
職員
マイページ
チーム
新しい機能を
リリースしました！
承知しました、
お疲れ様です。

課題3：ビジネスバリューの意識が欠如
熱い思いで組織の立ち上げからやってきた組織長やマネージャーとチームとで
プロダクトオーナーシップという観点で隔たりが出来ていると感じる
組織長
栽培管理
出荷予測
資材受注
CSチーム
組合員
マイページ
職員
マイページ
チーム

課題3：ビジネスバリューの意識が欠如
熱い思いで組織の立ち上げからやってきた組織長やマネージャーとチームとで
プロダクトオーナーシップという観点で隔たりが出来ていると感じる
組織長
栽培管理
出荷予測
資材受注
CSチーム
組合員
マイページ
職員
マイページ
チーム
日本の食と農を
当社のIT技術で支える！
冷めている印象
熱がある
プロダクトオーナーシップの壁

すでに
複数のチームで
スクラムでプロダクト開発しているので
大規模アジャイルのフレームワークを
活用して
この課題を解決したい！

03
選択

私たちの組織設計
前提をおさらい
• 基本的に1チーム1プロダクトを担当
• プロダクトを担当するチームは
チームトポロジーにおけるストリームアラインドチーム
• プロダクトごとに担当するパートナー会社は異なる
（オフショアもある）
• プロダクト開発そのものを直接担当しないCSや
営業チームも存在
基本情報
• リリースから5年以上経過している安定している
プロダクトもあるが、リリース半年やこれからリリース
する新規プロダクトも存在
– 但し、プロダクトによって担当するパートナー会社さんは
異なるのでチーム間の異動は考えていない
• プロダクト間で共通して考えたい共通の機能は
これから出てきそう
• チーム間の同期はうまくやっていきたい
組織戦略として

私たちの組織設計
前提をおさらい
• 基本的に1チーム1プロダクトを担当
• プロダクトを担当するチームは
チームトポロジーにおけるストリームアラインドチームで
クロスファンクショナルな状態
• プロダクトごとに担当するパートナー会社は異なる
（オフショアもある）
• プロダクト開発そのものを直接担当しないCSや
営業チームも存在
基本情報
• リリースから5年以上経過している安定している
プロダクトもあるが、リリース半年やこれからリリース
する新規プロダクトも存在
– 但し、プロダクトによって担当するパートナー会社さんは
異なるのでチーム間の異動は考えていない
• プロダクト間で共通して考えたい共通の機能は
これから出てきそう
• チーム間の同期はうまくやっていきたい
組織戦略として

フレームワーク選択
大規模アジャイルのためのフレームワークとして
当時候補としたのは
① SAFe、
② Scrum@Scale、
③ LeSS、
④ Nexus の4つ
これらは2024年1月において
最新のState of Agile Report 17thから
日本国内の事例や情報が多いものを
候補として選定
引用元：State of Agile Report 17th RE-SA-17th-Annual-State-Of-Agile-Report.pdf
1
2
3
4

大規模アジャイル手法①：Nexus概要
3～9のスクラムチームが単一のプロダクトバックログを共有し、スプリントごとに統合された
インクリメントを作成できるように、スクラムを最小限に拡張したフレームワーク
※ロールにはScrumで定義されていないものを記載
考案者 Scrumの共同考案者であるケン・シュエイバー氏が考案し、彼の設立し
たScrum.orgによって2015年に発表された手法
ロール※ Nexus統合チームメンバーを各チームから選出
人数 3～9チーム程度（合計で数十名規模）
特徴 • 複数チームが単一のプロダクトバックログを共有し、全チームの成果物
をまとめた統合済みインクリメントを毎スプリント作成
• 各チーム横断の課題を扱うNexus統合チームが存在し、チーム間の依
存関係や障害を最小化しながら統合を促進
• Nexusはスクラムを必要最小限に拡張したフレームワークであり、スクラム
にいくつかのイベントや成果物を追加定義している
公式サイト https://www.scrum.org/resources/online-nexus-guide

大規模アジャイル手法②：LeSS概要
1つのプロダクト（但し、LeSSのプロダクトは通常のものより幅広い定義）をスクラムのまま
大規模に取り組むためのフレームワーク
考案者認定スクラムトレーナーのバス・ボッテ氏とクレイグ・ラーマン氏らが
開発した手法
ロール※ APO（8チーム以上の時のみ）
人数 10人～（2チーム～）
特徴 • LeSSはスクラムであるというコンセプト
• 1つのプロダクトを2チーム以上で開発する時の手法
• スクラムマスターは3チームまで兼務可能。プロダクトオーナーは7チーム
までは1人。といったようにできるだけ1チームのスクラムを維持しつつ、
開発者をスケーリングさせるように考慮されている
• チームはフィーチャーチームとしてプロダクトの中の様々なバックログに対
応できることが求められる
公式サイト https://less.works/jp

大規模アジャイル手法③：Scrum@Scale概要
スクラム考案者のジェフ・サザーランド氏を始め、世界中のスクラム実践者達が協働考案して
おり、いくつかのScrum Patternsを内包している大規模なスクラムの手法
考案者 Scrum考案者の1人であるジェフ・サザーランド氏が中心となって開発し
た手法。Spotifyでコーチをされていたヘンリック氏も開発に携わっており、
Spotifyモデルと似ていたり、組み合わされることも多い
ロール※ チーフプロダクトオーナー、スクラムオブスクラムマスター
人数 10人～（2チーム～）
特徴 • スクラムを継承したまま、組織運営や組織全体にスクラムをスケール
させる
• スクラムの形を維持したままスケールするフラクタル（自己相似）構造
• プロダクトオーナーのサイクルのための定期的なフォーラム「エグゼクティ
ブメタスクラム（EMS）と組織全体のスクラムマスターのサイクルとして
機能する「エグゼクティブアクションチーム（EAT）」が存在する
公式サイト https://scruminc.jp/scrum-at-scale/

大規模アジャイル手法④：SAFe概要
考案者のディーン氏がラショナル社でグローバルに企業が統合されていく中で、プロダクトや
組織改革をアジャイルに行った体験が基となり作られているナレッジベースのフレームワーク
考案者ラショナル（現在はIBMが買収）にてRUPという手法の普及を行っていた
ディーン・レフィングウェル氏が中心となって開発した手法
ロール※ RTE,ProductMgmt,SystemArchitecht,BusinessOwner等々
人数 50人～（6～8チーム～）
特徴 • 経営の目線でポートフォリオをマネジメントすることが組み込まれている
• 大規模に運営する上での組織体系や、スプリントのルール等が細かく
詳細に幅広く決められている
• 公式の研修やドキュメントが手厚い
• 非常に重厚長大なのでアジャイルの重鎮やコミュニティから懐疑的な
意見が出てくることも多い
公式サイト https://scaledagileframework.com/
出典：https://framework.scaledagile.com/ja/#largesolution

大規模アジャイル手法まとめ
Nexus LeSS Scrum@Scale SAFe
1チームの人数 10人以下の職能横断型チーム
対象チーム数 3～9チーム 2チーム～ 2チーム～ 5チーム～
スクラムとの関係性最小限の拡張スクラムのまま継承しているコンバインしている
対象プロダクト中心プロダクトも組織変革も対象
組織変革チームガイドの中では対象外
経営者も含めたチームを組成
EAT LACE
スクラムにないプロセス統合チームイベントチーム全体イベント
スケール単位の
イベント
PI（2,3ヶ月）単位＆
チーム間のSyncイベント
スクラムにないロール Nexus統合チーム
APO
（4チーム以上）
SoSM、CPO
BO、RTE,
システムアーキテクト,
ProductManagement
バックログの数全体で1つ各チームに1つ
POの人数全体で1人各チームに1人
フラットな構造
チーム間は密結合
階層も含む構造
チーム間は疎結合

バックログが全体で1つでチーム間が密結合ということは
LeSSのフレームワークを例に取ると、各チームは組織規模で完全なフィーチャーチームとして
大きなプロダクトのどのシステムのどのコンポーネントも対応できることを目指している

バックログが全体で1つでチーム間が密結合ということは
LeSSのフレームワークを例に取ると、各チームは組織規模で完全なフィーチャーチームとして
大きなプロダクトのどのシステムのどのコンポーネントも対応できることを目指している
といったようにフィーチャーチームになるために投資が必要。
我々の組織では隣のチームのプロダクトまで担当できるような
ケイパビリティは求めていなかった
トラベラー
エキスパートメンバーがスプリント毎に
チームを変わる
偵察
他のチームにスクラムマスターではない人が偵
察に行く
オーバーオール
イベント
スクラムのイベントを全体で実施
クロスチーム
ミーティング
複数のチーム間で打ち合わせや、
チームを跨るモブプログラミング
そのためのプラクティスとして

WHOLE-3
事業部門
×
エンドツーエンドのスキル
チームが目指す状態はどこか
各チームにおけるスキルの幅と仕事の範囲について、組織として目指す姿はどこか
Org.Topologiesのマップを参考に戦略を立てたる
広
狭
広
狭
単一スキル複数スキルエンドツーエンドの
スキル
更に拡張範囲の
スキル
機能
個人やチームが持つスキルのケイパビリティ
チ
ー
ム
が
担
う
仕
事
の
範
囲
プロダクト
事業部門
組織全体
TASKS-1
機能
×
単一スキル
TASKS-2
機能
×
複数スキル
TASKS-3
機能
×
TASKS-4
機能
×
更に拡張範囲のスキル
CAPS-1
プロダクト
×
単一スキル
CAPS-2
プロダクト
×
複数スキル
CAPS-3
プロダクト
×
CAPS-4
プロダクト
×
PART-1
事業部門
×
単一スキル
PART-2
事業部門
×
複数スキル
PART-3
事業部門
×
PART-4
事業部門
×
WHOLE-1
事業部門
×
単一スキル
WHOLE-2
事業部門
×
複数スキル
WHOLE-4
事業部門
×
Mapping | Org Topologies を元に作成

WHOLE-3
事業部門
×
広
狭
広
狭
単一スキル複数スキルエンドツーエンドの
スキル
更に拡張範囲の
スキル
機能
個人やチームが持つスキルのケイパビリティ
チ
ー
ム
が
担
う
仕
事
の
範
囲
プロダクト
事業部門
組織全体
TASKS-1
機能
×
単一スキル
TASKS-2
機能
×
複数スキル
TASKS-3
機能
×
TASKS-4
機能
×
CAPS-1
プロダクト
×
単一スキル
CAPS-2
プロダクト
×
複数スキル
CAPS-3
プロダクト
×
CAPS-4
プロダクト
×
PART-1
事業部門
×
単一スキル
PART-2
事業部門
×
複数スキル
PART-3
事業部門
×
PART-4
事業部門
×
WHOLE-1
事業部門
×
単一スキル
WHOLE-2
事業部門
×
複数スキル
WHOLE-4
事業部門
×
Delivery
Discovery
Delivery
Delivery
チームが目指す状態はどこか
各チームにおけるスキルの幅と仕事の範囲について、組織として目指す姿はどこか
Org.Topologiesのマップを参考に戦略を立てたる
Mapping | Org Topologies を元に作成

EAT LACE
イベント
APO
SoSM、CPO
BO、RTE,
ProductManagement
組織単位で完全なフィーチャーチームを
目指す必要がない状況なら
こちらの方がチームの負荷は少ないと判断

我々はSAFeにおいて
2,3ヶ月単位のビジネス目標を
各チームが立てて推進していく方法に
特に魅力を感じた
その中心となる
PI（プランニングインターバル）について
詳しく説明する

PI（プランニングインターバル）について
チームA
スプリント1
(2週間）
スプリント2
(2週間）
スプリント3
(2週間）
スプリント4
(2週間）
スプリント5
(2週間）
スプリント6
(2週間）
スプリント1
(2週間）
スプリント2
(2週間）
・・・
PI 次のPI
チームB
スプリント1
(2週間）
スプリント2
(2週間）
スプリント3
(2週間）
スプリント4
(2週間）
スプリント5
(2週間）
スプリント6
(2週間）
スプリント1
(2週間）
スプリント2
(2週間）
・・・
チームC
スプリント1
(2週間）
スプリント2
(2週間）
スプリント3
(2週間）
スプリント4
(2週間）
スプリント5
(2週間）
スプリント6
(2週間）
スプリント1
(2週間）
スプリント2
(2週間）
・・・
8～12週間のタイムボックスを設け、関連するチーム間で同期を取りながら
ビジネス目標を推進する仕組み
インスペクト＆アダプト
デモ、目標に対するレビュー、全体での
振り返りを実施する
PIプランニング
12週間（6スプリント）の計画を立て、
ビジネス目標を定める

PI Planningとは
PIの開始時に関連するすべてのチーム・ステークホルダーが集まり、
これから開始するPIに向けてミッションとビジョンの意識合わせを行い、
全員でベクトルを合わせるイベント

PI Planningのタイムスケジュール
通常2日間かけて実施する。ビジネス状況やプロダクトビジョンを改めて共有し、
各チームボトムアップで目標と計画を作成する
Day 1 Day 2
9:30～10:30 アイスブレイクワーク
2日間のワーキングアグリーメント検討や
ドラッカー風エクササイズ等
9:30～10:30 朝会
チームごとに今の課題や今日やるべきこと
について話す
10:30～11:00 ビジネスコンテキスト
事業責任者が市場やビジネス状況を
共有
10:30～12:00 チームブレイクアウト
昨日の続き
必要ならチーム間の依存関係や合流ポイ
ントについても話しておく
11:00～11:30 プロダクトビジョン
プロダクト責任者がプロダクトビジョンを
共有
11:30～12:00 アーキテクチャビジョン
システムアーキテクトがアーキテクチャに
ついての目論見や懸念点を説明
12:00～13:00 ランチ 12:00～13:00 ランチ
チームに分かれて、チームごとに3ヶ月で達
成する目標とそのための計画を立てる
13:00～14:30 ファイナルプランレビュー
最終的なチームの目標とその計画を共有
する
14:30～15:00 全体リスク検討
組織としてのリスクとのその対処について検
討を行う
16:00～17:30 ドラフトプランレビュー
現時点の目標と計画を共有し、フィードバッ
クを貰う
15:00～16:00 プランの再調整
レビューのフィードバックやリスクを踏まえて
最後の微調整を行う
17:30～18:00
翌日のプランニング
問題解決
現時点の課題や解消に向けたアクションプ
ランについて話す
16:00～17:00 レトロスペクティブ
2日間のPI Planningのふりかえりを実施
する

いや、
6スプリントの計画立てるとか
無理では？
それって
ミニウォーターフォールでは
ないの？

PI Planningで計画すること 1/3
チームA
スプリント1
（2週間）
スプリント2
（2週間）
スプリント3
（2週間）
スプリント4
（2週間）
スプリント5
（2週間）
スプリント6
（2週間）
イノベーション＆
プランニングイテレーション
原則現在のPIのふりかえり、
次のPIのための準備
チームのイノベーション活動や
継続的な教育のための活動に
使う
直近のバックログは
細かい粒度
先のバックログは
粗い粒度
PI
プロダクトバックログ
各スプリントの中で完成の定義を満たすインクリメントのリリースは自由に実施可能
PI期間最後のスプリントは計画しない期間なので、
6スプリントを1PIとする場合は、5スプリント分の計画を立てる。
【あくまで私の個人的な解釈】
PI Planning の中では各スプリントのバックログの計画も立てるが、
特に先のスプリントで予定しているバックログは粒度も粗く当てにならないのでそこまで時間をかけなくてよい
計画通り全てのバックログを完了させなければならないというのは現実的ではないし、アジャイルではない
How や作る機能よりも What やどういう状態を目指すかの計画を議論の中心にする

プロダクトの4階層の中で、つい How の部分に時間をかけてしまうが、
What や Why に関する議論をすべき
Core
プロダクトの世界観
ミッションビジョン
企業への貢献
事業戦略
How
どのように実現するか
UI 設計・実装 Go to Market
Why
誰をどんな状態にしたいか
ターゲットユーザーペイン・ゲイン
なぜ自社がするのか
競合分析
市場分析
What
ユーザー体験
メンタルモデル
カスタマー
ジャーニー
ビジネスモデル
コスト構造収益モデル
ロードマップ
指標マイルストーン
プロダクトの4階層
出典：『プロダクトマネジメントのすべて』（及川卓也、小城久美子、曽根原春樹著、2021年、翔泳社）

アウトプットのイメージとしては、目指す状態についてのロードマップを先に検討し、
それを実現するための機能としてのバックログが計画されていること（粗々でも可）が望ましい
プロダクトロードマップを3本にわける
出典：時は金なり！「時間配分」を最適化できる、エンジニアのためのロードマップ活用マニュアル【連載：小城久美子】 - エンジニアtype | 転職type
できるだけずらさない
事業数字
仮設検証をして随時アップデート
目指す状態
こまめに仮説検証して変更する
つくる機能
売上目標：X億円
目指す状態
その状態を測る指標
目指す状態
その状態を測る指標戦略に
分解
施策に
分解
機能
機能
機能
機能
機能

プロダクトマネジメントのすきまを埋める
組織やプロダクトには様々な計画のレイヤーが存在するが、
大きな組織目標と開発チームの日々の作業にはギャップが存在している。
それはプロダクトマネジメントのすきまと呼ばれる
プロダクトマネジメントのすきま出典：『プロフェッショナルプロダクトオーナー』（Don McGreal、Ralph Jocham (著)花井宏行、高江洲睦、水野正隆、斎藤紀彦、木村卓央(訳)、2024年、丸善出版）
「プロダクトマネジメントのすきま」を埋めるのがPI Planningの重要な要素の1つ
プロダクト
マネジメントの
すきま
このすきまが大きくなると
• ビジネスと開発の分断が深まる
• 変化に柔軟に対応できなくなる
• 無駄な作業や手戻りが増える
⇩
顧客に提供できる価値が減る

EAT LACE
イベント
APO
SoSM、CPO
BO、RTE,
ProductManagement
PIの考えが
組織にマッチするので
SAFeを採用

SAFeについてよく聞く先入観：階層構造っぽい
階層構造のような側面はあるものの、実際多くの組織でSAFeでなくとも、
スクラムチームに加えてCEO,CTO,CPO他様々なステークホルダーが関りを持っていることが
多い。スクラムチームが自己組織化されていれば気にならない
Dev Dev Dev
Dev Dev Dev
SM
PO
Dev Dev Dev
Dev Dev Dev
SM
PO
Dev Dev Dev
Dev Dev Dev
SM
PO
TeamA TeamB TeamC
Product Management：複数のPOをケア
上位レイヤーとの橋渡し
System Architect：全体のアーキテクチャの方針、
ミドルウェア等の選定
RTE：複数のSMをケア、
組織課題の対応
Business Owner：事業責任者

実践的なノウハウが
多く書かれている。
ナレッジベースと言われる所以
SAFeについてよく聞く先入観：フレームワークが重厚長大
実はここまで説明してきたPI（スプリントとは異なる2～3ヶ月単位のタイムボックス）と
ロールで大部分は説明できている
OKRを使った
目標設定をしよう！
Communities of Practice を
活用しよう！
出典：https://framework.scaledagile.com/ja/#largesolution

04
適用

組織へのSAFe適用
1. 活動計画
2. コミュニケーション設計
3. 目標設定
4. ウィンセッション（成果共有会）
5. 組織全体でのレトロスペクティブ

活動計画
会社の会計年度に合わせてPIを年間4つの期間で運営
スクラムがマッチしないチームはカンバンを採用
FY2024 1Q
PI1
FY2024 2Q
PI2
FY2024 3Q
PI3
FY2024 4Q
PI4
2024/04 2024/05 2024/06 2024/07 2024/08 2024/09 2024/10 2024/11 2024/12 2025/01 2026/02 2025/03
栽培管理
チーム
出荷予測
チーム
資材受注
チーム
組合員ページ
職員ページ
CSチーム
インフラチーム
マーケチーム
営業チーム
▼PI Plannning
▼Win Session
Inspect&Adapt▼ ▼PI Plannning
▼Win Session
▼Win Session
▼Win Session
Inspect&Adapt▼
PI1-1 PI1-2 PI1-3 PI1-4 PI1-5 PI1-6 PI2-1 P2-2 PI2-3 PI2-4 PI2-5 PI2-6 PI3-1 PI3-2 PI3-3 PI3-4 PI3-5 PI3-6 PI4-1 PI4-2 PI4-3 PI4-4 PI4-5 PI4-6
PI1 PI2 PI3 PI4
PI1 PI2 PI3 PI4
PI1 PI2 PI3 PI4
PI1 PI2 PI3 PI4

コミュニケーション設計
スクラムのイベントに加え、SAFeのイベントを追加
一部のイベントについてはSAFeのガイドから見直して独自に設定することにした
単位イベント頻度
PI単位 PI Planning 3ヶ月
スプリント単位スプリントプランニング隔週
デイリースクラム日次
バックログリファインメント随時
スプリントレビュー隔週
レトロスペクティブ隔週
PO・SMシンク週次
ウィンセッション 1.5ヶ月
Inspect&Adapt
（ウィンセッション＋全体レトロスペクティブ）
3ヶ月

チームの目標を設定する
会社として組織全体やマネージャー・個人ごとの目標設定は年単位で行うが、
チームやプロダクトの目標はなかったり、年間ノルマになっている。
そして個人目標は人事評価に係るので現実的でワクワク感がないこともしばしば
組織
目標
部目標
チーム
目標
チーム
目標
PI Plannigでは人事評価には直接関係のないチームやプロダクトごとの
3ヶ月単位をボトムアップで作成する！
目標があることで3ヶ月間チームが同じ目線で会話できる
課目標
組織長担当部長
担当部長担当課長
担当課長一般社員
一般社員
資材受注チーム
栽培管理チーム
個人
目標
個人
目標
個人
目標
一般社員

ワクワクする目標を設定する
“ 私は目標設定の力を信じています。
ワクワクとした目標を設定することでチームが
いきいきとする。
いきいきとしたチームがワクワクと目標に向かい
続けることでグングン成長し、周囲が、そして
自分たち自身が驚くような成果を上げていく。
そんな姿を自分が所属してきた組織で何度も
目撃しています。 ”
出典：『アジャイルチームによる目標づくりガイドブック』
（小田中育生(著)、2024年、翔泳社）

ワクワクする目標設定の場としてのPI Planning
通常2日間かけて実施するPI Planning。
ビジネス状況やプロダクトビジョンを改めて共有し、
Day 1
10:30～11:00 ビジネスコンテキスト事業責任者が市場やビジネス状況を共有
11:00～11:30 プロダクトビジョンプロダクト責任者がプロダクトビジョンを共有
システムアーキテクトがアーキテクチャについての
目論見や懸念点を説明
12:00～13:00 ランチ
チームに分かれて、チームごとに3ヶ月で達成
する目標とそのための計画を立てる
17:30～18:00
問題解決
Day 2
9:30～10:30 朝会
チームごとに今の課題や今日やるべきことに
ついて話す
昨日の続き。必要ならチーム間の依存関係や
合流ポイントについても話しておく
12:00～13:00 ランチ
13:00～14:30 ファイナルプランレビュー最終的なチームの目標とその計画を共有する
14:30～15:00 全体リスク検討
組織としてのリスクとのその対処について検討を
行う
15:00～16:00 プランの再調整
16:00～17:00 レトロスペクティブ 2日間のPI Planningのふりかえりを実施する
改めてタイムスケジュールを見ると
ワクワクする目標設定をするための仕掛けが
多く存在していることに気付く

ワクワクする目標設定の場としてのPI Planning ➀
通常2日間かけて実施する。
Day 1
12:00～13:00 ランチ
17:30～18:00
問題解決
Day 2
9:30～10:30 朝会
ついて話す
昨日の続き。必要ならチーム間の依存関係
や合流ポイントについても話しておく
12:00～13:00 ランチ
14:30～15:00 全体リスク検討
行う
15:00～16:00 プランの再調整
改めてPI Planningのタイムスケジュールを見ると
① 目標はチームが主体となりボトムアップで作成するので
目標に対するオーナーシップを持つことが出来、
自分事化される
② ビジネスコンテキストの共有といった事業責任者目線での
情報共有も行われ、情報の非対称性が是正される
③ CFR（Conversation(対話）・Feedback（フィードバック）・
Recognition（承認）が組み込まれている）

ワクワクする目標設定の場としてのPI Planning ②
Day 1
システムアーキテクトがアーキテクチャについて
の目論見や懸念点を説明
12:00～13:00 ランチ
17:30～18:00
問題解決
Day 2
9:30～10:30 朝会
ついて話す
12:00～13:00 ランチ
14:30～15:00 全体リスク検討
行う
15:00～16:00 プランの再調整

③ CFR（Conversation(対話）・Feedback（フィードバック）
・Recognition（承認）が組み込まれている）
ワクワクする目標設定の場としてのPI Planning ③
Day 1
システムアーキテクトがアーキテクチャについて
の目論見や懸念点を説明
12:00～13:00 ランチ
17:30～18:00
問題解決
Day 2
9:30～10:30 朝会
ついて話す
12:00～13:00 ランチ
14:30～15:00 全体リスク検討
行う
15:00～16:00 プランの再調整
◼ Conversation（対話）：チームブレイクアウト
◼ Feedback（フィードバック）：ドラフトプランレビューと
ファイナルプランレビュー
◼ Recognition（承認）：ドラフトプランレビューと
ファイナルプランレビュー

ワクワクする目標設定の場としてのPI Planning ➀～③
Day 1
12:00～13:00 ランチ
17:30～18:00
問題解決
Day 2
9:30～10:30 朝会
ついて話す
昨日の続き。必要ならチーム間の依存関係や
合流ポイントについても話しておく
12:00～13:00 ランチ
14:30～15:00 全体リスク検討
行う
15:00～16:00 プランの再調整
チームが自主的に3ヶ月のビジネス目標を立てることが
PI Planningの重要な要素の1つ

Objectives：目標
何を目指すのか
Key Results：目標を測る指標
到達度を測定する指標
O KR
KR
組織単位
O
O
KR
KR
KR
チーム/プロダクト単位
OKRがあれば不要では？
はい、そう思います！
残念ながら当社では人事評価に係る個人目標が主で
チームやプロダクトの目標をOKRで
運用している組織は少ない

目標から計画を立てることは難しい
どうしても目先必要なバックログに追われてしまい、
目標達成に向けて何から考えたらいいか見失うこともある
思考するためのプラクティスの1つとして
TOCfEの「アンビシャス・ターゲットツリー」を紹介し、ワークショップを実施
5つのステップで目標から実施することを逆算するためのツール
手順①：目標を書く
手順②：目標の達成を阻む障害を考える
手順③：挙げられた障害を使い、中間目標を考える
手順④：中間目標達成のための行動を考える
手順⑤：中間目標達成の順序を考える

アンビシャス・ターゲットツリー
5つのステップで目標から実施することを逆算するためのツール
【目標】市民マラソン大会でフルマラソン完走

持久力が不足している
ランニング用品がない
トレーニングの時間がない
足や膝をけがしやすい
ペース配分が不明
障害
凡例：

持久力が備わっている
ランニング用品が揃ってる
トレーニングの時間がある
怪我を防止できている
ペース配分が分かっている
手順③：挙げられた障害を使い、
中間目標を考える
障害
凡例：中間目標

週3回以上トレーニング
足型に合うシューズを買う
朝型の生活で朝ラン
セルフケアの方法を学ぶ
ランニングアプリを活用
手順④：中間目標達成のための
行動を考える
手順⑤：中間目標達成の
順序を考える
ランニング用品が揃ってる
トレーニングの時間がある
障害
凡例：中間目標行動

手順④：中間目標達成のための
行動を考える
手順⑤：中間目標達成の
順序を考える
ランニング用品が揃ってるトレーニングの時間がある
週3回以上トレーニング
足型に合うシューズを買う朝型の生活で朝ラン
セルフケアの方法を学ぶ
ランニングアプリを活用
障害
凡例：中間目標行動

ウィンセッション（成果共有会）
本来SAFeではスプリントごとに全体を統合したレビューを行うシステムデモがイベントとして
存在するが、この組織では同じブランドの中に複数プロダクトが存在する状況のため
1.5ヶ月ごとにお互いの成果を称え合う場（ウィンセッション）に見直した
組織長に対して進捗報告を行う場ではない
メンバーが主役となって
チームや個人の成果をアピールする場

冒頭のチェックインにて、ウィンセッションの位置付けを確認

同僚の行動、成果に対して
惜しみない称賛を送りましょう

組織全体のレトロスペクティブ
毎スプリントは組織全体でのレトロスペクティブは実施していないものの、
PI単位の3ヶ月に1回は組織全体でのレトロスペクティブを実施
ワールドカフェ形式オープンスペーステクノロジー形式

ビジネスバリューの意識付け
PIプランニングを軸に、各チームがビジネスバリューを意識した
計画の立案・目標管理・成果共有・ふりかえりのサイクルが回り始めたことで
普段の会話も目標とのアラインを意識した内容が自然と増えた
チームメンバー
プロダクトマネジメント
プロダクトの目標（アウトカム）を達成するために
どんなアウトプットが必要なのか
自律的に柔軟に考えられるチームへの変化が見られた
次のスプリントでは、コアユーザー増加に向け
こんなバックログが必要だと思います
いいね！ CSチームとも連携して
一緒に考えてみよう

実はプロダクトオーナーシップの壁なんてものはなく、
元々プロダクトをよくしたいと考えている人がほとんど
踏み出すきっかけや、何から始めたらよいかわからない
権限がないと思い込んでいたことが
問題だった

05
成果

FY2024のビジネス成果
既存プロダクトの利用者数
1.5 倍
新規プロダクトのリリースによる
大規模（数万人）ユーザーの獲得
1. 既存機能を基にマーケティング・
営業活動を実施し、利用者獲得
2. 新規機能追加による新規利用者層の
拡大
1. 新規プロダクトについてリリースを
実施し、導入予定の組織の
試行利用は評価も上々
2. 導入地域への営業活動を実施し、
大規模ユーザーが見込める受注を
獲得
1 2

コミュニケーションが取りやすく、
お互いに意見を出し合える
環境です！
メンバーからのアンケートコメント
アジャイル開発によって顧客提供価値を
追求しながらプロダクトを改善していく
営みを学べます
顧客に対する価値をチーム全体で
考え、対話し、練り上げていくという
活動が浸透しており、納得感の高い
仕事ができます
ビジネス創出～拡販、産地サポートまで
一気通貫で取組について知ることができ
ました！
課題の本質を追求する姿勢と
その土壌がある組織だと感じます

06
まとめ

アジャイルな組織を目指す上で欠かせないポイント
1. 大規模アジャイルに取り組む前に
組織が目指す姿のビジョンを持つべし
2. プロダクトマネジメントのすきまを埋めるべし
3. 組織全体でお互いの成果を認め合うべし

アジャイルな組織を目指す上で欠かせないポイント 1/3
1. 大規模アジャイルに
取り組む前に
組織が目指す姿のビジョンを
持つべし
どのレベルでスキルのケイパビリティを持つのか、
どれだけ育成に投資するか、
組織の目指すところ・状況によって異なる

2. プロダクトマネジメントの
すきまを埋めるべし
単にバックログをこなすための
チームになっていないか、
組織全体にチームのプロダクトビジョンや
プロダクトの目指す姿が伝わっているか

3. 組織全体で
お互いの成果を
認め合うべし
お互いのチームの活動を
更に深く知れる上に、
明日からの活力に繋がる

本当の鍵
フレームワークは手段
どんなoutcomeを生み出し
世の中にimpactを残そうとしているかが
組織に浸透していること
真の原動力は
具体的な指標を伴う
目標管理の仕組み
出典：Output vs Outcome vs Impact - Crisp's Blog

今後の展望
1. 他組織へ展開
• まだまだNTTデータの多くの組織はアジャイルな状態になれていない
• 特に企画型プロダクトを抱える組織は変革のチャンスがある
2. 多面的な指標で組織の成長を支援する
• 4keys+SPACEメトリクス等を活用した改善サイクルを回す
• 開発者満足度、働きやすさによる持続可能性をもっと大事にしたい
3. 組織全体でケーパビリティ高くスキルを持ちたい組織への挑戦
• LeSSのプラクティスを参考に、個人としてはそういった組織への挑戦もしてみたい

記載されている会社名、商品名、サービス名等は、各社の商標または登録商標です

SAFe実践から見えた、フレームワークより大切な組織変革の道程(Scrum Fest Sendai 2025 発表資料)

More Related Content

What's hot

Similar to SAFe実践から見えた、フレームワークより大切な組織変革の道程(Scrum Fest Sendai 2025 発表資料)

More from NTT DATA Technology & Innovation

SAFe実践から見えた、フレームワークより大切な組織変革の道程(Scrum Fest Sendai 2025 発表資料)