---
title: あなたのアジャイルがうまくいかない理由 for エンタープライズアジャイル勉強会
tags: 
author: [Shigeki Morizane](https://www.docswell.com/user/samuraiRed)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/LELMXPWR7R.jpg?width=480
description: 2026年6月度エンタープライズアジャイル勉強会より
published: June 22, 26
canonical: https://www.docswell.com/s/samuraiRed/ZDMMDR-2026-06-22-210426
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/LELMXPWR7R.jpg)

あなたの
アジャイルが
うまくいかない
10の理由
〜“Reboot”のための処方箋〜
森實 繁樹
for 2026年6月エンタープライズアジャイル勉強会
1


# Page. 2

![Page Image](https://bcdn.docswell.com/page/4JMYL49PJW.jpg)

ただし、それはアジャイルを具体的に体
現する流派の一つ、「スクラム」の考え
をどのような場合にも同じように適用す
るべきと見なしているわけではない。局
面によって、スクラムの適用の仕方を変
えるところが現れてくる。
-市谷聡啓（『作る、試す、正す。』ISBN：978-4-8025-1329-6）
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/PJR9KWGY79.jpg)

森實 繁樹
株式会社レッドジャーニー
Swise株式会社 外部顧問
Pluslab株式会社 外部顧問
国立筑波大学 非常勤講師
（所属ユニット）
侍塊s
プロジェクトマネージャ保護者会
ITかあちゃんず
（所属（運営）コミュニティ）
日本XPユーザグループ
BIT VALLEY –INSIDE保険xアジャイルコミュニティ
人材業界ビジネスアジャイルコミュニティ
Agile Tour Yokohama
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/PEXQLPX4JX.jpg)

あなたのアジャイルが
うまくいかない10の理由
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/3EK9LDWPED.jpg)

本日の前提
SIerで15年以上、事業会社で4年以上の経験から、
マネジメントの基本は、
①中日程 ②体制図 ③課題管理表
にあると考えます。
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/L73W3R1475.jpg)

其の壱
プロジェクトマネジメントがスクラ
ムのイベントに盛り込まれていない
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/87DK4YX5JG.jpg)

其の壱
プロジェクトマネジメントがスクラ
ムのイベントに盛り込まれていない
計画駆動型のプロジェクト→プロジェクト憲章およびプロジェクト計画から始まる
プロジェクト計画＝プロジェクトをうまくいかせるための戦略を描いたもの
世の中のだいたいのスクラム（アジャイル型）プロジェクト
プロジェクト計画を飛ばして…スプリントイベント（セレモニー）を実行している
そのデイリースタンドアップにプロジェクトをうまくいかせるための戦略は反映されていますか？
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/VJPKM6PDE8.jpg)

本当はさらにステアリングコ
ミッティや必要に応じたアプリ
横断連絡会、運用要件確認
会などなど足していくのかど
こかに埋め込んでいくべき
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/2EVV932GEQ.jpg)

其の弐
既存のガバナンスを満たすような
アジャイルの設計になっていない
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/57GLZ3LDEL.jpg)

其の弐
既存のガバナンスを満たすような
アジャイルの設計になっていない
自社のソフトウェア開発標準やISMSなどに沿わせた開発方法およびガバナンス設計は、
計画駆動型プロジェクトにアラインするようにできている
→これはこれで過去の失敗に学んだガードレールでありゲートの役割を果たしている
→ここでやりたかったことは、必要なプロセスが踏まれ、堅牢なシステムを世に出すこと
一方、だいたいのスクラム（アジャイル型）プロジェクトは、プロセスよりも価値となりがち…
成すべきプロセスを組み込みながら既存ガバナンスを突破できる形を目指していますか？
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/4EQYL5YXJP.jpg)

どんな開発であれ、やるべき
ことは原則同じ。どうして
PMBOKで標準的にあらわさ
れているアクティビティに対す
る実行をしないでよいのか
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/KJ4WD9W271.jpg)

其の参
チームメンバー全員が、ロールという帽子
をかぶりわけるべきことがわかっていない
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/LE1YZKYK7G.jpg)

其の参
チームメンバー全員が、ロールという帽子
をかぶりわけるべきことがわかっていない
スクラムマスターが開発者と兼務しているときなどは、
「スクラムマスターの帽子と開発者の帽子を被り分けましょう」
といったりします。
しかし、チームメンバー全員でプロジェクトを推進するのに、
ユーザーの体験を考えるのはUXデザイナーだけなのか、競合他社を分析するのはPOだけな
のか…
開発者だろうがUXデザイナーはおろかユーザーの帽子を被ってみていますか？
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/GEWG9DGPJ2.jpg)

其の肆
権限・役割の委譲の単位は、
小さくていいことがわかっていない
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/47ZL9GL6J3.jpg)

其の肆
権限・役割の委譲の単位は、
小さくていいことがわかっていない
権限・役割の委譲（Delegation）というと何を思い浮かべるでしょうか？
一番身近なところで言うと、スクラムマスターが当初仕切っていたファシリテーション業をチーム
メンバーに役割を委譲していくというのがあると思います。
「ファシリテーション業」という塊、大きくないですか？？
もっと小さく、「今日の司会」「今日のタイムキーパー」「今日の議事メモ係」…
小さく小さく権限・役割を委譲していくことで、受け取る側の心理的ハードルも下がります。
※ 委譲：権限などを上位者が下位者に「任せる」ことで最終的な責任は上位者にある
移譲：権限や財産などを対等な立場の他者に「移しゆずること」で、責任も移る
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/YJ6WKYWLJV.jpg)

其の伍
ふりかえりはマイナスをゼロやプラ
スにもっていくことだけではない
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/GJ5MPGMMJ4.jpg)

其の伍
ふりかえりはマイナスをゼロやプラ
スにもっていくことだけではない
ふりかえりをやると、どうしても問題（Problem）が多く出て、
TryもProblemからの小さなカイゼンを出さないといけない雰囲気がありませんか？
それならKeepを出す意味が何もなくなってしまいます。
Problemも小さな改善の種かもしれませんが、Keepというのは成功体験の言語化です。
言語化された成功体験は再現性を生み出し、更によい成功を生むエナジーなのです。
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/9E296Y9R7R.jpg)

其の陸
チームで決めるということと責任者
を置かないことは同じではない
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/D7Y49G45EM.jpg)

其の陸
チームで決めるということと責任者
を置かないことは同じではない
計画駆動型のプロジェクトの場合、リーダーやマネージャーといったいわゆる責任者をたてます。
これは、責任を持って遂行に当たるために、割り当てられた権限の裏返しでもあります。
では、責任を持って遂行に当たるために、スクラム（アジャイル型）プロジェクトには、チームに
権限があるといえるのでしょうか。
これは権限を分解する必要があり、例えばRACIで考えると、「実行責任者」、「説明責任
者」、「相談先」、「報告先」があります。
この場合、チームに与えられているのは実行責任であり、説明責任は誰かが担うのが組織
で活動するチームなのではないでしょうか？説明責任は一箇所で担うべきです。
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/VENYLGY4J8.jpg)

其の漆
専門職にも越境するマインドが必要
であることがわかっていない
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/Y79P4WP4E3.jpg)

其の漆
専門職にも越境するマインドが必要
であることがわかっていない
専門職とは、専門性を持ち且つ協調して働ける人であり、専門性しか持たない偏った人
ではありません。
例えば、みなさんの周りでもPOが忙しいというのをよく見たり聞いたりしませんか？
それはみなさんのせいかもしれません。
相談とは提案です。「どうしたらいいですか？」ではなく、「こうするのはどうでしょう？」です。
つまり、POの意思決定をしてもらう相談（提案）を行うには、自分の領域を超えて、POの
興味関心を知らないと相談（提案）は通りません。事実に基づく妄想力が必要なのです。
あなたはどれくらいPOの考えていることをわかろうと（越境）していますか？
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/G78DQNDV7D.jpg)

其の捌
プロダクトのマネジメントにラインの
マネジメントを持ち込んではいけない
22


# Page. 23

![Page Image](https://bcdn.docswell.com/page/L7LMXPMRJR.jpg)

其の捌
プロダクトのマネジメントにラインの
マネジメントを持ち込んではいけない
プロダクトにおけるマネジメントは、小さなスクラムチームを想像する場合、POがプロダク
トマネジメントの中心にいます。
しかし、例えば職能ごとに、エンジニアやデザイナーには自部署自組織があり、そこにおけるラ
インの課長や部長といった役職も存在します。
プロダクトの観点で会話をするとき、ラインマネージャーの課長の意見は所詮1メンバーの発言
にすぎません。プロダクトのマネジメントの会話に職能の役職による上下を持ち込むのはナンセ
ンスです。しかし、周りの人が相手の役職を慮って意思決定が歪むことは往々にしてあること
です。
ラインのマネジメントをするとき、意図的にプロダクトから離れておこなっていますか？
23


# Page. 24

![Page Image](https://bcdn.docswell.com/page/4EMYL4YPEW.jpg)

其の玖
POは本当に
CEO​
（ミニCEO）なわけではない
24


# Page. 25

![Page Image](https://bcdn.docswell.com/page/PER9KW9YJ9.jpg)

其の玖
POは本当に
CEO​
（ミニCEO）なわけではない
POはミニCEOであるとかよく言われます。
端的に言います。POはCEOでもミニCEOでもありません。
POは、ただの雇われ店長です。
プロダクトへの愛情をもつことは、自分のためであり、ユーザーのためであり、社会のためです。
しかし、雇われ店長に一番求められるのは、今月の稼ぎであり、安定した経営です。
みんな本当はわかっているので、そんな雇われ店長業の中でも、ちょっとだけでいいのでプロダ
クトに愛情を持ってもらえることを祈っています。それがPOの最善でありビジネスです。
25


# Page. 26

![Page Image](https://bcdn.docswell.com/page/P7XQLPQ4EX.jpg)

其の拾
生産性の高さとビジネスの成功は
比例しない
26


# Page. 27

![Page Image](https://bcdn.docswell.com/page/37K9LD9P7D.jpg)

其の拾
生産性の高さとビジネスの成功は
比例しない
アウトプット→アウトカム→インパクトという流れについてよく聞くと思います。
しかし、一般的な成果評価の期間で区切ると、アウトカムに至るところまでが計測できず、必
然的にアウトプットでの評価をせざるを得ません。つまり、結果指標ではなく、行動指標による
評価です。
結果指標を導くために行う行動指標を先行指標としてターゲットにするのは正しいです。し
かし、行動指標を高めることが結果指標を押し上げることにつながるかは別の話です。
生産性を高めればビジネスの求める結果指標に近づくとは限りません。ビジネスの求める結
果指標をいかに早期に先行指標におけるかが、行動に変化をもたらしビジネスの成功の
確度をたかめるのです。
27


# Page. 28

![Page Image](https://bcdn.docswell.com/page/LJ3W3RW4J5.jpg)

まとめ
28


# Page. 29

![Page Image](https://bcdn.docswell.com/page/8JDK4YK5EG.jpg)

まずは中日程を引きましょう
あなたの
アジャイルを
Reboot
するために…
守破離の守は自分たちが大事にすべ
き本質から生まれます
教科書からは生まれません
右ができるようになったら、品質確保
計画やリリース計画などを落とし込む
破や離を目指しましょう
◦ 3ヶ月～半年先のロードマップを今すぐ描きましょう
◦ 中日程はいつどこで見直すのか
◦ プロダクトバックログリファインメントで見直しましょう
次に体制図を描きましょう
◦ 体制図はステークホルダーの関係図です
◦ 同じ高さには同じレイヤーの握るべき人がいます
◦ 線が繋がっているところ以外に必要な会議体が見えてきます
◦ 勝てる戦略を勝てる実行計画にするために箱（イベント）を調整しましょう
◦ スプリントの営みそのものを再設計しましょう
課題管理は開始期限で管理しましょう
◦ 開始期限を管理し、タスクの一つとして実行することで、想定外は減ります
◦ また、短期のリスクは事前に課題管理でサキヨミ対応しましょう
◦ スプリントプランニングで課題と短期リスクをタスク管理しましょう
◦ あわせて、長期のリスク管理も今まで通りしましょう
◦ リスクの判断は組織的に行うべきで、スプリントレビューでフィードバックをもらいましょう
29


# Page. 30

![Page Image](https://bcdn.docswell.com/page/VEPKM6KD78.jpg)

おまけ
30


# Page. 31

![Page Image](https://bcdn.docswell.com/page/27VV93VG7Q.jpg)

チームを良くしようと思ったら
より個人をみないといけない
チーム力を高めるということは、すなわち個々が十分に実力を発揮できる環境を整え、
その上でチームの総合力とするためのバランスをとる事が必要です。
チーム力を高めるためには、まず個人と向き合い、個人の特性や強みを認め、それ
を最大限引き出せる、あるいは伸ばせるための策を講じていく必要があります。
チームから始まる成長はありません。
個人にいかに向き合うかです。
31


# Page. 32

![Page Image](https://bcdn.docswell.com/page/5JGLZ31D7L.jpg)

『ゼロからはじめる
チームプロジェクトマネジメント』
2026/1/8 インプレスさんより発売します！
チームのみんなで一度読んでみてください！
32


# Page. 33

![Page Image](https://bcdn.docswell.com/page/47QYL5DXEP.jpg)

全体像：AI時代のAgileで見る4つの変化
速く作れる時代ほど、検証・プロダクト観・構造設計が重要になる
検証計画ドリブンなロードマップ
検証単位のバックログ
作る順番表ではなく、学ぶ順番表。仮説
・検証・判断を並べる。
バックログやエピックは、作業の箱では
なく学習できる最小単位へ。
AI時代の
Agile
学習 × 意思決定 × 実行力
プロダクトスコープの拡張
アーキテクチャとSpec
ソフトウェアだけではなく、顧客接点・
マーケ・データ・運用まで含める。
AIが安全に動く構造、守るべき制約、検
証できる仕様を設計する。
作る速度だけでは勝てない。顧客から学び、構造を変え、判断し続ける組織が勝つ。
AI時代のアジャイル｜dip新卒向け研修
33


# Page. 34

![Page Image](https://bcdn.docswell.com/page/KE4WD9Z2J1.jpg)

ディスカバリーとデリバリーの再帰的ループ
どこが速くなり、どこは速くならないのかを理解して設計する
課題・機会の
発見
仮説の立案
検証計画の設
計
実装・テスト
リリース・提
供
計測・データ
取得
分析・洞察
意思決定
人・市場
AI支援
人の判断
AIで高速化
高速化
AI支援
人×AI
人の判断
継続的にループを回し、仮説を磨き、価値を届ける
AIで速くなる部分：作る・処理する領域
AIでは速くならない部分：人・市場の反応領域
仮説整理、アイデア出し、仕様化、実装、テスト、ドキュメント作成、データ集計・可視化
など。
課題の発見、仮説の妥当性判断、ユーザーの利用・反応、現場の受容、意思決定・合意形成
など。
AI時代のアジャイル｜dip新卒向け研修
34


# Page. 35

![Page Image](https://bcdn.docswell.com/page/L71YZKRKJG.jpg)

Agileとは何か
ソフトウェア開発宣言やスクラムの手順だけではなく、プロダクトライフサイクルを回す考え方
Agile = 不確実な状況で、価値仮説を小さく検証し、学びながら次の判断に進む方法
Discovery
Delivery
Measurement
Learning
何が価値かを探す
価値を届ける
反応を観測する
次の判断に変える
スクラムガイドでは足りない
開発だけでもない
PMBOK第8版ともつながる
スクラムは有効なフレームワークだが、今日の主役はもっと広い「学習と判断」の話。
顧客理解、マーケティング、データ分析、運用まで含めてプロダクトを見る。
価値・原則・パフォーマンス領域・プロセスを横断して捉える。
AI時代のアジャイル｜dip新卒向け研修
35


# Page. 36

![Page Image](https://bcdn.docswell.com/page/G7WG9D1PE2.jpg)

大切なものは、PMBOK第8版にある
Agileを「スクラムの手順」ではなく、価値提供とマネジメントの体系として捉える
AI時代のプロダクト開発は、プロダクトマネジメントとプロジェクトマネジメントを統合して見る必要がある。
※ここではPMBOK第8版の細かな解説ではなく、「価値を実現するための考え方」として接続します。
AI時代のアジャイル｜dip新卒向け研修
36


# Page. 37

![Page Image](https://bcdn.docswell.com/page/4JZL9GP6E3.jpg)

ロードマップは「検証計画」ドリブンになる
いつ何を作るかではなく、いつ何を検証し、何を学び、何を判断するか
従来のロードマップ
AI時代の検証計画ドリブンロードマップ
6月：検索機能を作る
7月：レコメンド機能を作る
8月：ダッシュボードを作る
6月：顧客は検索で商品を探したいのかを検証
7月：提案が購買率を上げるかを検証
8月：どの指標が現場の行動を変えるかを検証
主語：機能
問い：いつまでに作るか
主語：仮説
問い：何がわかれば判断できるか
ロードマップとは、未来を当てる表ではなく、わからないことをわかるようにする順番表である。
AI時代のアジャイル｜dip新卒向け研修
37


# Page. 38

![Page Image](https://bcdn.docswell.com/page/YE6WKYMLEV.jpg)

検証計画ドリブンロードマップの型
仮説 → 検証方法 → 必要な変更 → 指標 → 判断をつなげる
仮説
検証方法
必要な変更
観測指標
判断
検索で探したい
LP＋簡易検索
最小UI
検索率・CVR
本実装へ
通知で再訪する
限定セグメント配信
通知文面
再訪率
継続/中止
指標で行動が変わる
ダッシュボードβ
取得ログ
閲覧率・行動率
優先度調整
ポイント
AIで実装が速くなるほど、検証設計なしに作ると「速く作ったが、何も学べない」状態になりやすい。
AI時代のアジャイル｜dip新卒向け研修
38


# Page. 39

![Page Image](https://bcdn.docswell.com/page/GE5MPGZME4.jpg)

バックログ・エピックは「検証単位」になる
作業の箱ではなく、学習できる最小単位に切る
× 悪い切り方：部品・作業単位
○ 良い切り方：学習・検証単位
・ログイン画面を作る
・マイページを作る
・検索画面を作る
・通知機能を作る
・初回ユーザーは3分以内に目的に到達できるか
・通知で再訪率が上がるか
・マイページで問い合わせが減るか
・検索よりカテゴリ導線が使われるか
→ 作った事実はわかるが、顧客について何が
わかったのかが曖昧
→ 次に何を判断すべきかが明確になる
バックログやエピックが、検証単位としてかぶらないように設計する。
AI時代のアジャイル｜dip新卒向け研修
39


# Page. 40

![Page Image](https://bcdn.docswell.com/page/97296YRRJR.jpg)

プロダクトの範囲を広げる
ソフトウェアだけではなく、顧客の行動全体を設計・検証する
認知・集客
利用前
利用中
データ取得
分析・指標
サポート
継続・購買
きっかけ
期待形成
体験
設計
設計
オペレーション
ロイヤル化
プロダクト開発の本質
マーケティング、データ分析、オペレーション、価格、キャンペーンまで含めて「価値仮説」を検証すること。
AI時代は、アプリだけを速く作るのではなく、顧客の行動変化を速く学ぶ。
さらに、それをプロダクトに関わるすべての役割、メンバーが関与していく。
AI時代のアジャイル｜dip新卒向け研修
40


# Page. 41

![Page Image](https://bcdn.docswell.com/page/DJY49GD57M.jpg)

AI駆動開発の肝は「アーキテクチャ」と「仕様」
AIが安全に・効率的に動ける構造と境界を設計する
アーキテクチャ
Spec駆動（仕様アーキテクチャ）
・変更しやすく壊れにくい構造
・責務分離・テスト容易性
・セキュリティ・スケーラビリティ
・AIが扱いやすいコンテキスト設計
・保守性と再現性を守る境界
・何を満たすべきかを明確化
・制約、境界、禁止事項を定義
・検証方法、受け入れ基準を定義
・AIエージェントが動くための設計図
・品質を守るための共通言語
※AIが作るものだけでなく、AIが動くための環境を含むた
め、この死守が生命線ともいえる
※Specとは業務仕様をシステム仕様に落とし込むことでは
なく、AIエージェントに実装パターンを落とし込むこと
アーキテクトは、AIがコードを書く時代の「開発環境の建築家」へ。
AI時代のアジャイル｜dip新卒向け研修
41


# Page. 42

![Page Image](https://bcdn.docswell.com/page/V7NYLG64E8.jpg)

役割は消えない。仕事の重心が移るだけ。
AI時代は、ロールの名前よりも「何を守り、何を判断するか」が重要になる
PO / PdM
エンジニア
デザイナー
PM
アーキテクト
要件管理
→ 仮説・検証・
意思決定の設計へ
実装者
→ AI出力を評価し
構造を守る人へ
画面制作
→ 体験仮説と
顧客理解の設計へ
進捗管理
→ 学習サイクルと
意思決定の支援へ
技術構造の設計
→ AIが安全に動く
生態系の設計へ
AIに仕事を奪われるかではなく、AIを前提にした役割へどう進化するか。
AI時代のアジャイル｜dip新卒向け研修
42


# Page. 43

![Page Image](https://bcdn.docswell.com/page/YJ9P4WL473.jpg)

AIエージェント群は「デジタルワーカー」になる
でも、AIを働かせるための環境・制約・品質判断は人間が設計する
AIが担いやすい仕事
人が担うべき仕事
チームで整えるもの
・コード生成
・テスト生成
・ドキュメント作成
・コードレビュー補助
・デプロイ補助
・データ集計
・仕様の整形
・目的の設定
・価値仮説の設計
・検証方法の判断
・制約と品質基準の定義
・ステークホルダーとの合意
・倫理・リスク判断
・AIが動く開発環境
・Specの書き方
・レビュー観点
・テスト戦略
・ログと計測
・意思決定ルール
もしかしたら…
ユーザーのペルソナを用いたエージェントを作成することで、本当にすべてユーザー行動をみないとわからない
こともない、確からしさをあげられる世界を作ることも可能…かもしれない（最終的にリアル検証はしたほうがいい）
「AIがコードを書く」時代ほど、人間は目的・制約・品質・判断に強くなる必要がある。そして、作る＝技術的負債の始まりでもある。
AI時代のアジャイル｜dip新卒向け研修
43


# Page. 44

![Page Image](https://bcdn.docswell.com/page/GJ8DQNXVJD.jpg)

『ゼロからはじめる
チームプロジェクトマネジメント』
2026/1/8 インプレスさんより発売しました！
AI時代にもチームのみんなで一度読んでみてください！
44