---
title: エンタープライズアジャイルと権限委譲 - 尊重すべきはPOの決定ではなく、部門横断の意思決定
tags: 
author: [Graat](https://docswell.com/user/graat)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/YE9LYQGV73.jpg?width=480
description: 2026年11月9日に開催されたエンタープライズアジャイル勉強会セミナー（2026年11月）での講演「エンタープライズアジャイルと権限委譲 - 尊重すべきはPOの決定ではなく、部門横断の意思決定」の資料です。 https://www.docswell.com/slide/KL3P4G/edit
published: November 09, 26
canonical: https://docswell.com/s/graat/KL3P4G-easg202611
---
# Page. 1

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

エンタープライズアジャイル勉強会セミナー（2026年11月）
エンタープライズアジャイルと権限委譲
尊重すべきはPOの決定ではなく、部門横断の意思決定
2026/11/9
グロース・アーキテクチャ＆チームス株式会社


# Page. 2

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

自己紹介
鈴木雄介
• Graat（グラーツ）
» 正式名称：グロース・アーキテクチャ＆チームス(株)
» 代表取締役社長
• (株)アイムデジタルラボ
» 三越伊勢丹グループ DX推進機能子会社
» 取締役
• JACK
» 正式名称：ジャパンアジャイルコラボレーションカーネル
» 代表理事
• 日本Javaユーザーグループ
» 社団法人CCC協会
代表理事
• SNS
» @yusuke_arclamp
» http://arclamp.hatenablog.com/
2


# Page. 3

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

組織とチームを”仕組み”でつなぎ、エンタープライズDXを実現する


# Page. 4

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

アジェンダ
アジャイルと権限委譲
意思決定を迅速化する
組織モデルと権限
日本型組織と意思決定
組織的意思決定の設計
事例
まとめ
5


# Page. 5

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

アジャイルと権限委譲


# Page. 6

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

アジャイルと権限委譲
アジャイルといえば権限委譲
• プロダクトオーナー（PO）には権限が必要とされている
スクラムガイド(2020)
IPA アジャイル開発モデル契約
“ プロダクトオーナーをうまく
“ 適切なプロダクトオーナーを
機能させるには、組織全体で
プロダクトオーナーの決定を
尊重しなければならない。
選任し、権限委譲ができるか
p.7
Schwaber
2020
Sutherland
プ
年
』
ス
出
ロ
ク
版
典
ラ
「
ダ
、
：
ム
ク
ガ
トイ
オド
ー
ナー」 『
出典：Schwaber & Sutherland『スクラムガイド』2020年版、p.7「
プロダクトオーナー」
8.契
IPA
「
』
情
出
報
典
『
約
シ
：
前
ステ
チム
ェ
ッ
・
ク
モ
リ
デ
ス
ル
ト
取
」引・
契約書（
アジャ
イル開発版）
出典：IPA『情報システム・モデル取引・契約書（アジャイル開発
版）』「契約前チェックリスト」8.
7


# Page. 7

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

アジャイルと権限委譲
権限委譲は悩みの種でもある
• グローバルでも組織とチーム関係は課題になる
アジャイルをチームから組織全体へ広げる際の課題
複数回答
経営層の理解不足・障壁となる行動
36%
チームの自己組織化・自律のための権限不足
33%
事業部門のアジャイル理解不足
29%
優先順位・方針が不明確
28%
部門間のサイロ化
22%
組織文化との衝突
22%
,p.17
2024
Digital.ai,
State
of Agile Report（
2023
項典
年
出
目：
公
調
・
。
表
査
数
）
／
値The
を抜17th
粋して
和訳。
出典：Digital.ai, The 17th State of Agile Report（2023年調査／2024年公表）, p.17。項目・数値を抜粋して和訳。
8


# Page. 8

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

アジャイルと権限委譲
組織とチームの関係
意思
決定者
• チーム：横の調整
» POは、顧客/ユーザーの求めるこ
とを定義し、開発者と調整する
• 組織：縦の合意形成
» POは、プロダクトを組織として提
供できるようにする必要がある
• POは両方やる必要がある
説明責任
価値設計
顧客/
ﾕｰｻﾞｰ
実現調整
PO
チーム
業務調整
社内
社内
社内
関係部署
関係部署
関係部署
9


# Page. 9

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

アジャイルと権限委譲
組織とチームの関係
意思
決定者
• どちらかだけを優先してもう
まくはいかない
説明責任
» 横を優先する？
▸ユーザーにとって価値があっても組織
として提供できない
» 縦を優先する？
▸組織の論理が優先され、ユーザーにと
っての価値が実現できない
価値設計
顧客/
ﾕｰｻﾞｰ
実現調整
PO
チーム
業務調整
社内
社内
社内
関係部署
関係部署
関係部署
10


# Page. 10

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

アジャイルと権限委譲
権限委譲は何のため？
• 「迅速で継続的な意思決定」のため
» チームとして何かを決定するのに、いちいち組織内調整をしてい
ては、アジリティが実現できない
» とはいえ、組織内調整をしなくていいわけでもない
▸特にエンタープライズでは組織で認められないとプロダクトが継続できない
• 本日のテーマ：組織とチームの関係を権限委譲だけで解決
するのは難しいのではないか
11


# Page. 11

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

意思決定を迅速化する


# Page. 12

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

意思決定を迅速にする
「迅速で継続的な意思決定」を実現する
• アジャイルは「迅速で継続的な意思決定」を求める
» では、それをどのように実現すべきなのか？
» 歴史の中で、どのように議論がされてきたのかを振り返る
▸2001年→2026年の25年
14


# Page. 13

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

歴史的経緯


# Page. 14

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

歴史的経緯
アジャイル
• アジャイルソフトウェア開発宣言
» 2001年に「不確実なソフトウェア開発」
の進め方として提唱
▸長期計画、フェーズ、変更管理への懸念
» 時代背景としてのインターネット
▸いわゆるウォーターフォール型管理の限界
» 手法：Scrum、XP、Crystal、Adaptive
Software Development…
https://agilemanifesto.org/iso/ja/manifesto.html
16


# Page. 15

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

歴史的経緯
大規模アジャイル
• Scaling Agile手法の登場
https://less.works/
» 巨大化するサービスにおいて、複数の
アジャイルチームをどうやって協調・
整合させるか
▸2005：LeSS、2011：SAFe、2012：
Disciplined Agile、2015：Nexus、2018
：Scrum@Scale
▸チームの外側の問題にも意識的ではある
が、それが主題ではない
https://framework.scaledagile.com/safe-6-0-configurations
https://scruminc.jp/scrum-at-scale/guide/
17


# Page. 16

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

歴史的経緯
プロダクト思考
• 2007『INSPIRED』
» ビジネス側が「どう価値を発見するか」
▸アジャイルを前提にするとマネージャーの責任が機
能を作ることから、成果を改善することへ
▸プロダクトマネージャー、プロダクトマネジメント
» プロダクトディスカバリー
▸本当にそのプロダクトを欲しがるユーザーがいるの
かを発見・検証すること
▸ユーザーの問題に対して、使えて、価値があり、実
現可能な解決策を発見すること
18


# Page. 17

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

歴史的経緯
リーン
• 2014『Lean Enterprise』
» 2011『Lean Startup』
▸Build → Measure → Learn
» 企業そのものが継続的に仮説検証し、学習で
きる仕組みをつくる
https://speakerdeck.com/jezhumble/lean-enterprise?slide=13
▸Explore：価値を小さく仮説検証する
▸Exploit：継続的に顧客へ価値を届ける
▸Portfolio：学習結果に応じて投資を増減する
▸Organization：目的を共有した自律的チームを作る
19


# Page. 18

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

歴史的経緯
プロジェクトからプロダクト型
• 2018『Project to Product』
» 企業のIT投資・ソフトウェアデリバリーの
運営モデルを変える
▸継続的に価値を生み出すものを、一時的な
Projectとして管理していることが問題
▸仕事の管理単位をProjectからProduct Value
Streamへ変える
▸顧客・事業にとって意味のある仕事が、Value
Streamをどのように流れているかを計測する
20


# Page. 19

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

歴史的経緯
プロダクト運営モデル
• 2024『TRANSFORMED』
» Product Operating Model(POM)とは
▸会社がテクノロジーを使って顧客価値と事業成果を
継続的に生み出すための“組織運営モデル”
✓ 経営が事業目標を示す
✓ リーダーが「解くべき問題」を選ぶ
✓ チームが「どう解くか」を探索する
✓ 小さく継続的にデリバリする
✓ 成果を測って次の判断につなげる
21


# Page. 20

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

歴史的経緯
企業のアジリティ
• 2026『Manifesto for Enterprise Agility』
» PMIとAgile Allianceが共同で公開
» アジャイル宣言の書き直しではなく、拡張
▸4つの価値と9つの原則を定義
» Enterprise Agilityとは「企業が一貫性を失う
ことなく、大規模に”適応”する能力」
▸素早く意思決定する
▸意図的にリソースを再配分する
▸現実の変化の中でも戦略を実行可能な状態に保つ
Manifesto for Enterprise Agility
https://www.pmi.org/learning/agile/manifesto-for-enterprise-agility
22


# Page. 21

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

Manifesto for Enterprise Agility


# Page. 22

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

Manifesto for Enterprise Agility
4つの価値
• 明確な目的を、適応的な計画によって実現する
» Clear purpose realized through adaptive plans
• 部門/機能別の最適化より、企業全体の成果を重視する
» Shared enterprise outcomes over functional optimization
• 現状維持より、継続的な自己変革を重視する
» Continuous reinvention over preservation
• 変化の中でも、人間中心であることを重視する
» Human centricity amidst change
24


# Page. 23

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

Enterprise Agility
9つの原則
• 企業のあり方 → 組織運営の仕組み →
現場の仕組み
区分
日本語訳
原文
目的を明確にし、企業全体の成果に向けて足並みをそろえる
Create clarity of purpose and align on enterprise
outcomes
リーダーシップ アジリティをパートナーやエコシステムにまで広げる
Leadership Behavior
組織設計
Organization Design
実行
Execution
Expand agility across partners and ecosystems
テクノロジーと分散した人材を積極的に活用する
Embrace technology and distributed talent
承認者ではなく、明確なガードレールによって統治する
Govern with clear guardrails, not gatekeepers
実行活動ではなく、目的と意図に対して資金を配分する
Fund purpose and intent, not execution activity
効率性だけでなく、適応可能性を重視して設計する
Design for adaptability, not just efficiency
価値が生み出される場所へ、権限と意思決定を移す
Move authority and decision-making to where value
is created
価値を頻繁に届け、仕事を可視化する
Deliver value frequently and make work visible
兆候を早期に捉え、素早く学び、確信を持って行動する
Sense early, learn quickly, act with confidence
25


# Page. 24

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

意思決定を迅速にする


# Page. 25

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

意思決定を迅速にする
25年の結論
• 組織が、チームの意思決定を迅速にする
» 2001年： チームはいかに自律的に活動し、継続的に改善するか
» 2026年： 組織はいかにチームの自律性を成立させ、企業全体の成
果と整合させるか
• チームの自律性を成立させるための取り組み
▸経営レベル：目標や成果、エコシステム、人材
▸組織運営レベル：統制、予算配分、組織設計
▸実行レベル：権限と意思決定、デリバリ、文化
✓ 権限委譲も1つの要素ではある
27


# Page. 26

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

組織モデルと権限


# Page. 27

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

組織モデルと権限
米国と日本では問題解決のモデルが違う
• 1986年、青木は米国と日本を比較した
» 階層的：全体最適に優れるが、管理者の能力に依存する
» 水平的：日常の適応に優れるが、抜本的な変革には弱い
▸一部の部門に犠牲を求めるような組織革新や戦略変更には抵抗が生じる
A-firm：階層的調整
J-firm：水平的調整
管理
管理
現場
現場
上位に情報を集めて判断・指示
青木昌彦（1986）『Horizontal vs. Vertical Information Structure of the Firm』
現場
現場
現場の知識を使って相互調整
30


# Page. 28

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

組織モデルと権限
Scrumは何をもたらすのか


# Page. 29

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

Scrumは何をもたらすのか
竹内・野中のラグビー型からScrumへ
• ラグビー型（Type B・C）
» 多様な専門分野のメンバーが開発の最初から最後まで協働し、工程を重ねながら進める。専門
領域を越えて責任を共有し、情報交換と試行錯誤を通じて、迅速かつ柔軟に製品を開発する。
1986年：部門横断チームが一体となる開発の研究
1990年代以降：反復・検査・適応を支える枠組み
竹内・野中：新製品開発の「実態・条件」
Scrum：実践に必要な「最小限のルール」
A：リレー型
B・C：ラグビー型
責務
PO ／ スクラムマスター ／ 開発者
イベント
スプリント、プランニング、デイリー、
レビュー、レトロスペクティブ
作成物
プロダクトバックログ、スプリントバッ
クログ、インクリメント
図：Takeuchi & Nonaka, “The New New Product Development Game,” HBR, Jan–Feb 1986, Exhibit 1（p.139）を基に再作図。
Scrum：Schwaber & Sutherland, The Scrum Guide（2020）。両者の位置づけは本講演の解釈。
32


# Page. 30

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

Scrumは何をもたらすのか
竹内・野中における組織とチーム
意思
決定者
• チームが自律するための成立条件
» 経営：意図的な不安定性と緩やかな統制
▸挑戦的な目標と大まかな方向性のみを提示
▸チームの自律性を支えるメンバーの選定、成果評価
、チェックポイント、失敗を許容する環境
意図的な不安定性と
緩やかな統制
実現調整
PO
チーム
» 関係部署：チームへの統合
▸専門分野の異なるメンバーをチームに取り込み、そ
こで知識を統合し、意思決定する
• これも1つの組織とチームの関係
チームへの統合
社内
社内
社内
関係部署
関係部署
関係部署
33


# Page. 31

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

Scrumは何をもたらすのか
階層的調整におけるScrum
A-firm：階層的調整
• Scrumは、変革への対応に適していた
» 変革時には管理者自身も正解がわからず、ボ
トルネックになる
» 管理階層がもっていた権限を現場に渡して、
自律的に現場で解決させた方が良い
▸チームが現場で得られる情報を使って、自ら検査を
適応を繰り返すことで変革に対応できる
▸チームには部門間を調整する権限もある
▸管理層はチームから適切な報告を受ける
管理
現場
現場
階層的調整とチーム
管理
現場
チーム
現場
34


# Page. 32

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

Scrumは何をもたらすのか
J-firm：水平的調整
水平的調整におけるScrum
管理
• Scrumが、調整を増やしてしまう
» そもそも、権限が分散しているため、
POに必要な権限をまとめて委譲できない
▸そもそも、管理層に「与えるべき権限」がない
▸各部門の権限が残った状態になる
現場
現場
水平的調整とチーム
» 竹内・野中の成立条件を満たせない
管理
▸経営層が「任せる」と言っても、現場で機能しない
▸本来はチームに専門家を移動させるべき
✓ 既存業務に影響を与えるので拒否される
チーム
現場
現場
35


# Page. 33

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

組織モデルと権限


# Page. 34

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

組織モデルと権限
階層的調整とチーム
ここまでの整理
管理
• 水平的調整では権限委譲が機能しない
» アジャイルの実践には「チームの迅速で継続
的な意思決定」が必要
» チームの自律的な活動を支えるために、組織
は経営、組織運営、実行を変えていくべき
▸階層的調整組織では、管理層にあった権限をチー
ムに委譲することが変革につながる
▸水平的調整組織では、権限が分散しており、チー
ムへの移譲ができないため、逆にチームから見る
と調整が複雑になってしまう面がある
現場
チーム
現場
水平的調整とチーム
管理
チーム
現場
現場
38


# Page. 35

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

日本型組織と意思決定


# Page. 36

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

日本型組織と意思決定
日本型組織でも
迅速な意思決定を実現したい
水平的調整とチーム
管理
• 組織がチームの自律性を支援する
» チームの自律性を成立させるための組織設計
やガバナンスを整備することが必要
» 権限委譲も重要ではあるが、そこから開始し
ても水平的調整組織ではうまくいかない
• では、どうするのが良いのか？
» 弊社の実践から共有したい
チーム
現場
現場
？
41


# Page. 37

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

意思決定を迅速にする
構造的無能化


# Page. 38

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

構造的無能化
組織は合理的に無能化する
• 構造的無能化
» 大企業では、合理的な判断で分業が進み、
業務がルーティン化している
①断片化
②不全化
③表層化
各部門がサイロ化し、個別最適が優先される
各部門では会社全体の環境変化を捉えきれず、
全体像が捉えられない
表層的な問題解決を繰り返し、変革を伴う全体
最適に取り組めない
「わからない」壁：何が問題なのかが決まらない
「進まない」壁 ：問題が複雑で、進め方が決まらない
「変わらない」壁：施策を示しても人や組織が動かない
企業変革のジレンマ 「構造的無能化」
はなぜ起きるのか
宇田川元一 (著)
出版社 : 日経BP 日本経済新聞出版
発売日 : 2024/6/22
43


# Page. 39

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

組織モデルと権限
構造的無能化は慢性疾患
• 慢性疾患は、生活習慣の改善が必要
» 急性期であれば手術するか、死ぬか
» 慢性疾患は、自己調整能力の回復が必要
▸診断能力・代謝・免疫・生活習慣を取り戻す
▸明確な改善効果は中長期的にしか現れない
• 組織でも、仕事の習慣の改善が必要
書籍 P15
» 組織が自分たちの問題を認識し、考え、
調整し、自ら変化できる状態を取り戻す
44


# Page. 40

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

構造的無能化
構造的無能化からの回復
• 変化に応じて自身を継続的に更新できる能力を回復する
» 回復の4つのプロセス
① 全社戦略を考えられるようになる
経営が外部環境や現場の問題を踏まえて「どこへ向かうか」を考える能力を取り戻す
② 全社戦略へのコンセンサス形成
経営陣・各部門が、方向性だけでなく「自分たちの役割」を理解する
③ 部門内での変革の推進
全社戦略を現場の具体的な問題と接続し、各部門が自ら変化を起こす
④ 全社戦略・変革施策のアップデート
現場で分かったことを経営へ戻し、戦略や施策自体を修正する
» 組織が自らの「思考の循環」を取り戻す
▸現場で起きている違和感を拾う → 複数の立場から見る → 背後の構造を考え
る → 戦略との関係を考える → 実際に動く → 分かったことから戦略を修正
する
45


# Page. 41

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

構造的無能化
対話が必要
• 対話とは
» 部門ごとに異なる事情や合理性を持つ人々が、互いの認識を変え、
新しい関係性を構築するための方法論
段階
意味
実践のポイント
① 準備 自分と相手の間にナラティヴの溝があることを認める 自分の正しさを絶対視しない
② 観察 相手の状況や、溝が生じている背景を探る
相手の行動だけでなく、置かれた状況を見る
③ 解釈 相手のナラティヴから問題を捉え直す
相手にとって何が合理的なのかを理解する
④ 介入 新しい関係性を構築するために働きかける
小さな行動を試し、関係性を変えていく
» ナラティヴがズレている状態で「意思決定を迅速化しよう」「権限
を委譲しよう」としても受け入れられない
46


# Page. 42

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

日本型組織と意思決定
日本型組織と意思決定


# Page. 43

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

日本型組織と意思決定
部門間対話の実現を、Scrumから学ぶ
• 部門間対話の実践手法としてのScrum
» 宇田川：対話とは、新しい関係性を構築すること
▸単なる話し合いや相互理解ではなく、異なるナラティヴ（解釈の枠組み）の
間に橋を架け、新しい関係性を構築すること
» スクラム：スクラムのルールが人々の関係性と相互作用を導く
• Scrumの枠組みが対話の土台になる
» 異なるナラティブを持った人を共通の土台に乗せる
▸ただし、水平的調整では「誰が決めるか」ではなく「協議と合意」
48


# Page. 44

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

水平的調整とチーム
日本型組織と意思決定
管理
対話のルールを作る
• 部門横断で意思決定を導くために
チーム
» Scrumの仕組みを応用する
▸時間的な制約、全体の優先順、状況の透明化…
» 何をいつ部門横断で決めるべきかを決める
▸逆説的にチームが決めていいことがわかる
現場
現場
水平的調整と対話ルール
• この組織的意思決定を設計していく
管理
» POは意思決定の推進役になる
チーム
対話の
ルール
• 弊社の具体的なフレームを紹介
現場
現場
49


# Page. 45

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

組織的意思決定の設計


# Page. 46

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

組織的意思決定の設計
進め方
• 関係者を集めて、以下を整理する（半日ワークショップ）
» 関係者への理解促進
▸チームを機能させるために関係者は何をすべきか？
▸何は組織で決めて、何はチームで決めていいのかを分ける
» 意思決定リズムの設計
▸案件カテゴリとサイクル
▸フェーズとリードタイム
» プロダクト運営の設計
▸チームのリズム、ミーティング、ドキュメントなど
51


# Page. 47

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

関係者への理解促進


# Page. 48

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

関係者への理解促進
スクラムを電車で理解する
• 1周=スプリント
» ホーム＝案件一覧
バックログアイテム
▸プロダクトバックログ
» 電車の車両
▸スプリントバックログ
» 子供＝案件
▸バックログアイテム
» スプリントの開始後、プロダクト
バックログを優先順に並べ直す
53


# Page. 49

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

関係者への理解促進
ビジネス側の責任
• 電車に間に合うのは乗客の責任
» 出発時間に準備ができていないな
ら、電車は出てしまう
▸時間までに来る、切符を買う…
バックログアイテムが
準備できているか確認
» 飛び乗り・飛び降りしない
• 子供の準備＝親の責任
» ビジネス側が主導すべき
親が間に合うように
連れてくる
54


# Page. 50

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

関係者への理解促進
電車に乗せられるのか？
• 電車に乗せるのは技術的問題
» 要件が不明瞭な案件が開発対象にな
ると、見積もりが曖昧になる
» 電車の運行が乱れてアジャイルが機
能しなくなる
子供の乗車準備をする
(スプリントの外側)
• 適応課題を電車に持ち込まない
» プロダクトオーナーが主導して、乗
車前に仕様を確定させる
55


# Page. 51

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

意思決定リズムの設計


# Page. 52

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

意思決定リズムの設計
検討に必要な2つの考え方
• リリースサイクル：リリース頻度
• リードタイム：企画〜リリースまでの時間
» フェーズ：企画からリリースまでに必要な工程
リードタイム
要件定義
開発
要件定義
リリースサイクル
受入
開発
要件定義
受入
開発
受入
57


# Page. 53

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

意思決定リズムの設計
組織に求められる価値提供サイクルを定義
• 案件の種類別にリリース間隔を考える
» 「年に何回リリースしたいですか？」
» 組織とチームが共有できるカテゴリで区切る
種類
概要
新機能 業務調整を含む新しい機能。個別稟議
改善
既存機能の改善や追加。部門内調整
保守
ちょっとした修正や作業。チーム判断
緊急
障害対応
リリースサイクル
3ヶ月/年4回
1ヶ月/年12回
1週間/年50回
随時
※スプリントの期間ではありません。スプリントについては後述します
58


# Page. 54

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

意思決定リズムの設計
リリースまでの流れを設定
• リードタイム：企画してからリリースされるまでの期間
» 必要なプロセスと、その期間を定義する
» 要件定義期間＝開発期間にする方がPOと開発者で分担は容易
種類
新機能
改善
保守
緊急
フェーズ
要件定義(3m)、開発(3m)、受入(1m)
要件定義(1m)、開発(1m)、受入(0.5m)
要件整理(1w)、実施(1w）
＜フェーズなし＞
リードタイム
7ヶ月
2.5ヶ月
2週間
ASAP
※スプリントの期間ではありません。スプリントについては後述します
59


# Page. 55

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

意思決定リズムの設計
組織と何を、どう合意するか？を設定
• 合意形成をする会議は月1回固定を推奨
» その時点で実施されている複数のサイクルを報告する
» 持ち帰りNGを前提に、事前に個別合意したうえで会議を開催
» 名称案：協議会、意思決定会など
何を？
説明
候補要件 何を要件定義するのか？
開発対象 何を開発するのか？
リリース 何をリリースするのか？
判断材料
候補要件一覧
目標成果と概算見積もり
リリース対象と受入状況
60


# Page. 56

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

チーム運営の設計


# Page. 57

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

チーム運営の設計
チームのリズムと車両設計
• チームは1 or 2週間スプリントで活動
» 案件カテゴリごとに基準となるリソース配分(車両サイズ)を決める
» 週次で各案件状況とすり合わせしながら活動を実施
種類
新機能
改善
保守
緊急
開始期 成長期 安定期
作業内容
70%
50%
30% 新機能の実装
0%
30%
50% 既存機能の改善
30%
20%
20% メンテ、見積もり、その他相談
62


# Page. 58

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

チーム運営の設計
どんな情報でフェーズを繋ぐのか？
• 主担当、記載内容、利用タイミングを整理する
» 特に重要なのは組織→チームへのINPUTとなるもの
▸主要な項目や記載方法やタイミングを整理する
▸一緒にOUTPUTするものを整理することも重要
主なドキュメント
候補案件一覧
案件一覧(エピック)
計画単位(バックログ)
作業タスク
記入者
事業部門
PO
PO/開発者
開発者
記載方法と内容
Wordで主担当、概要、予算など
Excelで概要、概算見積りなど
ITSでストーリ形式、見積り
ITSで作業説明、実績
ITS（Issue Tracking System）：Jira、Redmine、Backlog、GH Issuesなど
63


# Page. 59

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

組織的意思決定の設計


# Page. 60

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

組織的意思決定の設計
メリット
水平的調整と対話ルール
• リズムを明示することが重要
» 全員の要望を一覧化して優先度を話す
管理
チーム
▸個別で聞かないことが大事
» 次のタイミングがあることを明示する
▸曖昧な要望は「次回に送る」ようにする
▸次は、こうしましょうが言いやすい
対話の
ルール
現場
現場
» 現状は隠さず、報告する
▸小さな失敗は「学び」と言い換えられる
» 結果的に、適切な権限委譲が行われる
65


# Page. 61

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

事例
67


# Page. 62

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

事例
概要
• 顧客：大手ゼネコン
• 状況
» 建設業務を支える業務システム群（数十個）を見直していきたい
» 要件調整の相手は複数部門に跨るので、スピード感を持って調整し
ていきたい
• 解決の方向
» プラットフォーム型開発と組織プロセスの整備
レポート：パネルディスカッション－大成建設：8000社／9万人が利用する業務システム群における開発サイクルについて
https://www.graat.co.jp/blogs/cm7d2izyt6nxo07zm0569ed49/
68


# Page. 63

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

事例紹介
プラットフォーム型開発
社内外のユーザー
• 建設業務に関わる業務システム群を開発
・統合するデータ管理プラットフォーム
» 2019年 検討開始、2020年 開発開始、2021
年運用開始し、段階的に機能拡充中
» 現在、15システムがプラットフォーム上で開
発され、15の外部システムと連携中。全体の
ユーザー数は8000社/9万人
» 認証認可の統合、フルクラウド、業務システ
ムに必要な共通機能の提供など
Ａ
サービス
B
サービス
SaaS
D
運用
管理
データ
ベース
共通
機能
システム運用担当者
69


# Page. 64

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

事例紹介
組織プロセスについて
• 2024年より協議会制に移行
» プラットフォーム上の案件が、様々な部署から同時並行で発生する
状況になってきたため、管理を一元化するために協議会を設置
▸スクラムガイドとしてはアンチパターン
» 3ヶ月おきに案件を取りまとめ、3ヶ月検討、その後の開発
部内要件整理
建築/設計
土木
全体調整
協議会
案件管理
開発管理
開発実施
情報企画
システム
子会社
ベンダー①
ベンダー②
調達本部
ベンダー③
子会社
※スクラムで実施
70


# Page. 65

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

事例紹介
協議会の実施プロセス例
3月
1週
マイルストーン
各事業本部
協議会
情報企画部
2週
3週
4週
4月
1週
2週
3週
4週
5月
1週
夏季
休暇
3週
案件会議
2週
3週
4週
★案件確定・見積承認
★要望受付期限
★要望
★業務要件完成
★案件候補選定
（7月検討対象）
受付開始
★案件候補確定
★案件起案 ★実施承認
★検討対象決定
要望シート
記入
稟議
業務要件
仕様調整
承認
取りまとめ
要望シート
検討
準備
見積調整
★協議会
★協議会
対象 ★協議会
（案件候補決定）
（案件決定）
選定 （検討対象決定）
案件資料取りまとめ
IT子会社
開発ベンダー
4週
6月
1週
アーキテクチャ
検討
レビュー
概算
算出
概要設計
見積作成
案件審査
71


# Page. 66

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

事例紹介
連携方法選択フロー
協議会設置に向けた準備
• 勉強会の実施
» 概要説明、業務サービスの紹介、
仕組みなどを説明
連携方法とコストイメージ
» 連携方式とコストの説明
• 各事業部との調整
» 協議会出席者の設置依頼
» 要望シートの記入依頼など
72


# Page. 67

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

事例紹介
協議会の成果 1/2
• 組織内でプロセスが共有できた
» 3ヶ月おきに案件を募集し、3ヶ月で検討、その後の開発
▸個別バラバラな依頼がなくなり、全て上記の流れに統一
▸日程とゴールが明確なので、事前相談も適切なタイミングでされる
» その「次のタイミング」があるので無理な押し込みがなくなる
• 優先順位の調整がしやすい
» 開発リソースは固定しているので、3ヶ月おきに、その時点の優先
度で開発対象を決めるのは公平性が保たれやすい
73


# Page. 68

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

事例紹介
協議会の成果 2/2
• 開発チームとの調整がやりやすい
» 3ヶ月間の計画が約束できるので双方にとって効率的
» 一方で新規開発の予算稟議は枠取りではないので、課題は残る
• プラットフォームがあるのは重要
» 「簡単にできること」と「できないこと」が明確
» システムが増えても運用負荷が上がらない
74


# Page. 69

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

まとめ
75


# Page. 70

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

まとめ
アジャイルといえば権限委譲
• プロダクトオーナー（PO）には権限が必要とされている
スクラムガイド(2020)
IPA アジャイル開発モデル契約
“ プロダクトオーナーをうまく
“ 適切なプロダクトオーナーを
機能させるには、組織全体で
プロダクトオーナーの決定を
尊重しなければならない。
選任し、権限委譲ができるか
p.7
Schwaber
2020
Sutherland
プ
年
』
ス
出
ロ
ク
版
典
ラ
「
ダ
、
：
ム
ク
ガ
トイ
オド
ー
ナー」 『
出典：Schwaber & Sutherland『スクラムガイド』2020年版、p.7「
プロダクトオーナー」
8.契
IPA
「
』
情
出
報
典
『
約
シ
：
前
ステ
チム
ェ
ッ
・
ク
モ
リ
デ
ス
ル
ト
取
」引・
契約書（
アジャ
イル開発版）
出典：IPA『情報システム・モデル取引・契約書（アジャイル開発
版）』「契約前チェックリスト」8.
76


# Page. 71

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

まとめ
権限委譲は何のため？
• 「迅速で継続的な意思決定」のため
» チームとして何かを決定するのに、いちいち組織内調整をしてい
ては、アジリティが実現できない
» とはいえ、組織内調整をしなくていいわけでもない
▸特にエンタープライズでは組織で認められないとプロダクトが継続できない
• 本日のテーマ：組織とチームの関係を権限委譲だけで解決
するのは難しいのではないか
77


# Page. 72

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

まとめ
25年の結論
• 組織が、チームの意思決定を迅速にする
» 2001年： チームはいかに自律的に活動し、継続的に改善するか
» 2026年： 組織はいかにチームの自律性を成立させ、企業全体の成
果と整合させるか
• チームの自律性を成立させるための取り組み
▸経営レベル：目標や成果、エコシステム、人材
▸組織運営レベル：統制、予算配分、組織設計
▸実行レベル：権限と意思決定、デリバリ、文化
✓ 権限委譲も1つの要素ではある
78


# Page. 73

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

まとめ
階層的調整とチーム
ここまでの整理
管理
• 水平的調整では権限委譲が機能しない
» アジャイルの実践には「チームの迅速で継続
的な意思決定」が必要
» チームの自律的な活動を支えるために、組織
は経営、組織運営、実行を変えていくべき
▸階層的調整組織では、管理層にあった権限をチー
ムに委譲することが変革につながる
▸水平的調整組織では、権限が分散しており、チー
ムへの移譲ができないため、逆にチームから見る
と調整が複雑になってしまう面がある
現場
チーム
現場
水平的調整とチーム
管理
チーム
現場
現場
79


# Page. 74

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

水平的調整とチーム
まとめ
管理
対話のルールを作る
• 部門横断で意思決定を導く
» 基本的ルール
▸部門を横断するような案件については、一定のリズ
ムでリリースを行う（四半期が基準）
▸そのリリースに必要なリードタイムは、フェーズ型
で運用する（6-9ヶ月が基準）
▸毎月、協議会を実施し、状況と優先順を確認する
✓ 全体責任者、関係部署責任者も参加する
チーム
現場
水平的調整と対話ルール
管理
チーム
対話の
ルール
• この組織的意思決定を設計していく
▸弊社の取り組みを紹介
現場
現場
現場
80


# Page. 75

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

さいごに
権限委譲から始めない
• 結果としては権限委譲は必要
» どこまでをチームが決めていいのかの線引きは明確にすべき
» ただ、それを関係者を集めて認識を合わせることが重要
» 難しいのは「最初に関係者を集める」こと…
• これは水平的調整組織での妥協ではなく、積極的な適応
» 全社のために、という視点で語ることに異論がある人は少ない
» リズムが安定してくると、積極的に調整が進むようになる
81


# Page. 76

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

組織とチームを”仕組み”でつなぎ、エンタープライズDXを実現する