アジャイルコーチから見たScaled Agile Method LeSS版

アジャイルコーチから⾒た
Scaled Agile Method..
〜SAFe and LeSSから学ぶ勘所〜
原田巌/木村卓央/水野正隆
Agile Talks vol.1, 2019.12.09

⽔野正隆
オージス総研
アジャイルコーチ
原⽥巌
オージス総研アジャイルコーチ
（期限切れ）
⽊村卓央
合同会社カナタク代表社員
LeSS派SAFe派
司会進行

Copyright© Kanataku,LLC Takao Kimura.
LeSS Part

⾃⼰紹介
Certified Scrum Professional – ScrumMaster™ and Product Owner ™ / Certified Scrum Developer®
Project Management Professional (PMP)®
PMI Agile Certified Practitioner (PMI-ACP)®
EXIN Agile Scrum Foundation
PMI⽇本⽀部アジャイルプロジェクトマネジメント研究会会員
LeSS Study主催
Agile Discussion!主催
Fearless Changeアジャイルに効くアイデアを広めるための48のパターン共訳
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法共訳
木村卓央
KIMURA Takao
https://www.facebook.com/kanataku.LLC/
https://about.me/tw_takubon
kimura.takao@kanataku.com

⼤規模スクラム Large-Scale Scrum (LeSS)
https://less.works/

LeSS complete picture LeSSは原理・原則をコアにして、複
数チームのコンテキストにスクラム
を適⽤するためのルールとガイドの
セットからなる
n 原理・原則
l LeSSのコア
n フレームワーク
l ルールで定義している
n ガイド
l ルールを効率的に適応するためのもの
l 試す価値がある実験の集まり(経験知)
n 実験
l 限定的な環境で機能する

⼤規模スクラムは
スクラムである透明性
少なくすることで
もっと多く
プロダクト全体
思考
顧客中⼼
完璧を⽬指しての
継続的改善
リーン思考
システム思考
経験的プロセス
制御
待ち⾏列理論
原理・原則 - LeSSのコア
出典: https://less.works/less/principles/index.html

原理・原則
⼤規模スクラムはスクラム LeSSはスクラムの原理・原則、ルール、要素、⽬的を⼤規模開発のコンテキストに可能
な限りシンプルに適応したもの
透明性スクラムと同じ。完成したアイテム、短いサイクル、協働、共通の定義、現場から恐れを
取り除くことがベースになる
少なくすることでもっと多く多くしてしまうと思考停⽌、改善の余地が減る
少なくすることでチームが多くの責任を持つ。
チームがプロセスと意義のある仕事のオーナーシップを持つ
プロダクト全体思考顧客が望んでいるひとまとまりのプロダクトとしての価値ある機能を提供する
顧客中⼼顧客にフォーカスし続ける
⾃分の仕事がお⾦を払うお客様に対してどのような価値提供につながっているのかを理解
する
完璧を⽬指しての継続的改善パーフェクトビジョン＝達成出来ないほどの⽬標に継続的に改善して近づける
例︓コストをかけずに障害のないプロダクトを常に提供し続け、⽣活を豊かにする
リーン思考⼈間性尊重と継続的改善の2つの柱を組織に根付かせ、完璧な⽬標を⽬指す
システム思考システム全体(アイデアから売上を得るまでに関わる⼈・物などすべて)を最適化する
システムモデルを使いシステムの関係性を理解する
経験的プロセス制御スクラムと同じ
継続的にプロダクト、プロセス、ふるまいの検証と適応を⾏う
待ち⾏列理論どこにキューがあるのか。リードタイムを短くするにはどうするのか
『大規模スクラム Large-Scale Scrum(LeSS)』 P.8 より

⼤規模スクラムはスクラムである
Large-Scale Scrum is Scrum

スクラムの成功は抽象的な原理・原則と
具体的な⼿法の絶妙なバランスにある
n抽象的な原理・原則
l透明性・検査・適応
l5つの価値基準
l経験的プロセス制御
n具体的な⼿法
l3つのロール
l3つの作成物
l4つのイベント
Bas
Vodde
出典 : https://less.works/resources/about.html
Craig
Larman

⼤規模スクラムはスクラムである
nLeSS はスクラムと同様にバランスを取っている
l抽象的な原理・原則
l具体的なプラクティス
n⾃分たちの仕事の仕⽅を継続的に改善できるように
l徹底的な透明性の維持
l検査と適応のサイクルを重視
lスクラムに具体的な構造を追加

フレームワーク - ルール LeSS Rules (April 2018)
n LeSSフレームワーク
2~”8”チームで開発するプロダクトに
適⽤
n LeSS Hugeフレームワーク
“9”チーム以上で開発するプロダクトに
適⽤

基本は1チームのスクラムと同じ
スクラムのプラクティスとアイデアを保持
n1つのプロダクトバックログ
n1⼈の(全体の)プロダクトオーナー
n1つの完成の定義
n各スプリントの終わりに出荷可能なインクリメント
nクロスファンクショナルなチーム
nスプリント
lLeSSでは、全てのチームが共通のスプリントで
共通の出荷可能なインクリメントをデリバリーする

LeSSの⽅向性
n シンプルであるべき(More with LeSS)
l 余計な役割/成果物/プロセスを追加してしまう罠にはまらないよう
にする
n スケールしたスクラム(Large-Scale Scrum is Scrum)
l スクラムの各要素を理解した上で、同様の効果を⼤規模開発におい
て実現する⽅法を模索する
n 削ぎ落しではなくスケールアップ(LeSS→LeSS Huge)
l 汎⽤的なフレームワークからスタートして削ぎ落としていく⽅法で
は、メタボなプロセスになる。
常に「最⼩限」から始めて必要最低限のものをビルドアップ
14

コミュニティ
スクラムマスター
チーム
顧客価値による組織化
フィーチャーチーム
組織構造
LeSSの構造
https://less.works/less/structure/index.html

LeSSルール︓ LeSSの構造
n 実際のチームを組織の基本構成要素として組織を構成します。
n それぞれのチームは、(1)⾃⼰管理、(2)クロスファンクショナル、(3)同⼀ロケーション、(4)⻑期間存続で
す。
n チームの⼤半は顧客中⼼のフィーチャーチームです。
n スクラムマスターはLeSSの導⼊が問題なく⾏われることに責任を持ちます。注⼒する対象は、チーム、プロ
ダクトオーナー、組織、技術的⼿法であり、１チームだけの改善に留まることなく、組織全体の改善を⾏う
必要があります。
n スクラムマスターは専任でフルタイムのロールです。
n １⼈のスクラムマスターが１〜３チームを担当することができます。
n LeSSではマネージャーは必須ではありません。もしマネージャーがいる場合でも多くの場合役割が変わりま
す。マネージャーがフォーカスすべきことは、⽇々の作業の管理からプロダクトを開発するシステム全体の
価値提供能⼒の向上に移ります。
n マネージャーの役割はプロダクト開発の仕組みの改善を促進することです。「現地現物」の実践、「⽌めて
直す」の推奨、「適合するよりも実験をする」ことを通じて改善を促進します。
n プロダクトグループは、「最初から」完全なLeSSの構造を適⽤します。これはLeSSを導⼊する際の肝とな
ることです。
n プロダクトグループを越える、より⼤きな組織には、「現地現物」の考え⽅を使い、実験や改善があたりま
えとなる環境を作っていくことで段階的にLeSS導⼊を進めます。
『LeSSルール(2018 4月)』より

ロール
n プロダクトオーナー︓1⼈
l 前提︓全てのアイテムの詳細を把握することは不可能
l 明確化よりも優先順位付けに重きをおく
l チームとユーザー(ステークホルダー)をつなぐコネクター
n スクラムマスター︓専任、1~3チームを担当
l LeSSの導⼊が問題なく⾏われることに責任を持つ
l 1チームだけではなく、組織全体の改善を⾏う
n チーム︓スクラムで⾔う開発チーム
l フィーチャーチーム
n LeSSでは、プロダクトグループ（明確には定義していない）
l スクラムチームでは無い

実際のチームを組織の基本構成要素とし
て組織を構成します。
それぞれのチームは、(1)⾃⼰管理、(2)
クロスファンクショナル、(3)同⼀ロ
ケーション、(4)⻑期間存続です。
チームの⼤半は顧客中⼼のフィーチャー
チームです。
『LeSSルール(2018 4月)LeSSの構造』より

コンポーネントチーム vs フィーチャーチーム
同期依存関係
コンポーネントをいじるときに依存関係が発⽣する
個⼈が協⼒しあう環境
⾮同期依存関係

LeSSの組織構造
n よく⾒られる組織構造
プロダクトグループ
の責任者
ほとんどのLeSS組織ではマネージャーが存在する
現地現物によってチームを⽀援。障害を取り除く
Undone部⾨理想的には存在しない部⾨
システム保証などの名前で存在することがある
https://less.works/jp/less/structure/organizational-structure.html
LeSSではマネージャーは必須ではありま
せん。もしマネージャーがいる場合でも多
くの場合役割が変わります。マネージャー
がフォーカスすべきことは、⽇々の作業の
管理からプロダクトを開発するシステム全
体の価値提供能⼒の向上に移ります。
マネージャーの役割はプロダクト開発の仕
組みの改善を促進することです。「現地現
物」の実践、「⽌めて直す」の推奨、「適
合するよりも実験をする」ことを通じて改
善を促進します。
『LeSSルール(2018 4月)LeSSの構造』より

LeSSのプロダクト

LeSSルール︓ LeSSのプロダクト
n 1⼈のプロダクトオーナーと1つのプロダクトバックログがあり、出荷可能なプロダクト全体を運
⽤します。
n プロダクトオーナーだけでプロダクトバックログリファインメントをするべきではありません。
複数のチームが顧客やユーザー、ステークホルダーと直接コミュニケーションをとり、プロダク
トオーナーをサポートします。
n 全ての優先順位付けはプロダクトオーナーが⾏います。が、要求や仕様を明確にするのは出来る
限りチームと、顧客やユーザーそしてステークホルダーとの間で直接⾏います。
n プロダクトの定義は現実的な範囲で、エンドユーザーまたは顧客中⼼でなければなりません。プ
ロダクトの定義は広い⽅が好ましく、時間の経過とともに拡張する可能性があります。
n プロダクト全体で全チーム共通の1つのDoneの定義を持ちます。
n 各チームは共通のDoneの定義を拡張してより厳しい独⾃のものを定めても構いません。
n 究極のゴールはDoneの定義を拡張し、毎スプリント（あるいはより⾼い頻度で）出荷可能なプロ
ダクトを作れるようになることです。

LeSSのプロダクト
1⼈のプロダクトオーナーと1つのプロダクトバックログがあり、
出荷可能なプロダクト全体を運⽤します。
１つのプロダクトに関わる全てのチームは同じスプリントで作業します。
スプリントの開始も終了も全チーム共通です。スプリントの終わりには
プロダクト全体が１つに統合されている状態にします。

LeSSルール︓ LeSSのスプリント
n １つのプロダクトに関わる全てのチームは同じスプリントで作業します。スプリントの開始も終了も全チーム共通です。スプリントの終わ
りにはプロダクト全体が１つに統合されている状態にします。
n スプリントプランニングは２つのパートで構成されています。スプリントプランニング１は全てのチームが合同で実施します。それに対し
てスプリントプランニング２は通常、各チームごとに個別で⾏われます。ただし、関連性が強いアイテムがある場合は共有スペースで、複
数チームのスプリントプランニング２を⾏います。
n スプリントプランニング１にはプロダクトオーナーとチーム全員またはチームの代表者が参加します。参加者は⼀緒に、各チームがこのス
プリントで作業するアイテムを暫定的に選択します。チームは協働する部分を特定し、質問を明確にします。
n 各チームにはチームごとのスプリントバックログがあります。
n スプリントプランニング２は各チームがどのようにアイテムを実現させるかを考える場であり、設計やスプリントバックログの作成を⾏い
ます。
n デイリースクラムはチームごとに⾏います。
n チームどうしの調整はチームに委ねられています。中央集権的な調整ではなく、個別の判断で⾃由かつ⾮公式に調整する⽅が好ましいです。
重要なのは、「ただ話す」ことや、⾮公式のコミュニケーションである「コードでのコミュニケーション」、チームをまたいだミーティン
グ、「コンポーネントメンター」、「トラベラー」、「偵察」、そして「オープンスペース」を活⽤することです。
n プロダクトバックログリファインメント（PBR）は、シェアード・ラーニング(訳注:学習したものをシェアする)を増やし、調整の機会とし
て活⽤できるため、複数チームで⾏うのが望ましいです。
n スプリントレビューは全てのチームが共同で⾏います。検査と適応を⾏うのに適切な情報を得られるよう、必要なステークホルダーが参加
するようにします。
n スプリントレトロスペクティブは各チームで⾏います。
n オーバーオール・レトロスペクティブは各チームのレトロスペクティブの後に⾏われます。ここでは複数チームやシステム全体にまたがる
課題を扱い、改善に向けての実験を議論します。この場にはプロダクトオーナー、全スクラムマスター、チーム代表者と、（いるなら）マ
ネージャーが参加します。

スプリントプランニング
スプリントプランニングは２つの
パートで構成されています。スプ
リントプランニング１は全ての
チームが合同で実施します。それ
に対してスプリントプランニング
２は通常、各チームごとに個別で
⾏われます。ただし、関連性が強
いアイテムがある場合は共有ス
ペースで、複数チームのスプリン
トプランニング２を⾏います。

スプリントプランニング１
n プロダクトオーナーはカードをテーブルに広げる
n チームがどのアイテムを持っていくか決める
l ディスカッションする
n チームが取ったアイテムの優先順位が全体最適になっているか確認す
る
n 共通でやらなければならない作業
の明確化
l 複数チームの
スプリントプランニング２
n プロダクトオーナーが
チームの判断を超えて、やってはいけない

プロダクトバックログリファインメント(PBR)
プロダクトバックログリファイン
メント（PBR）は、シェアード・
ラーニング(訳注:学習したものを
シェアする)を増やし、調整の機会
として活⽤できるため、複数チー
ムで⾏うのが望ましいです。

スプリントレビュー・レトロスペクティブ
スプリントレビューは全てのチームが共同
で⾏います。検査と適応を⾏うのに適切な
情報を得られるよう、必要なステークホル
ダーが参加するようにします。
スプリントレトロスペクティブは各チーム
で⾏います。
オーバーオール・レトロスペクティブは各
チームのレトロスペクティブの後に⾏われ
ます。ここでは複数チームやシステム全体
にまたがる課題を扱い、改善に向けての実
験を議論します。この場にはプロダクト
オーナー、全スクラムマスター、チーム代
表者と、（いるなら）マネージャーが参加
します。『LeSSルール(2018 4月)』より

調整と統合
チームどうしの調整はチームに委ねられています。中央集権的な調整で
はなく、個別の判断で⾃由かつ⾮公式に調整する⽅が好ましいです。重
要なのは、「ただ話す」ことや、⾮公式のコミュニケーションである
「コードでのコミュニケーション」、チームをまたいだミーティング、
「コンポーネントメンター」、「トラベラー」、「偵察」、そして
「オープンスペース」を活⽤することです。
n ただ話す
n コードでのコミュニケーション
n ブランチは使わない
n コミュニティ
n オープンスペース
n トラベラー
n コンポーネントメンター
n 偵察

Copyright© Kanataku,LLC Takao Kimura. https://less.works/less/adoption/index.html
はじめに
導⼊マップ
継続的改善
コーチング
3つの原則
LeSSの導⼊

ガイド︓3つの導⼊原則
n 広く浅くよりも、狭く深く
l １つのプロダクトを上⼿く回してから
n トップダウンとボトムアップ
l トップダウトとボトムアップの両⽅が必要
l 特にマネジメント(通常はプロダクトグループの責任者)の⽀援が重要
Ø コントロールでなく⽀援をする
Ø 以下をはっきりと伝えて⾏動に移す
•LeSSを導⼊する意図、必要な構造的変化を起こす約束、教育と
コーチングの提供
n ボランティアを活⽤する
l ⾊々なところで、希望する
l 参加しないことも選択肢として与える

ガイド︓はじめに（６つのレシピ）
n 全員を教育する
l LeSSの知識だけではなく、⽬的を理解することが重要︕
n 「プロダクト」を定義する
l 導⼊の範囲、プロダクトバックログ、適切なプロダクトオーナー
n 「Done」を定義する
l より強いDoneの定義は、弱いDoneの定義よりも組織的な変化(グループ、役割、
ポジションの排除)をもたらします
n 正しい構造を有したチームをつくる
l 機能部⾨を離れ、新しいチームに参加する(機能部⾨を排除する)
n プロダクトオーナーのみがチームに仕事を与える
n プロジェクトマネージャーをチームに近づけない
l プロジェクトマネジメントの責任はプロダクトオーナーとチームにある

ラーマンの組織⾏動の法則
1. 組織は、中間及び現場のマネージャーや、単
⼀専⾨職といったポジションの権⼒構造を維
持するために、暗黙に最適化されます。
2. 1.の結果として、組織を変えようという試みは、
今まで使っていた⽤語をただ、別の名前に変
えるか、⽤語を⼤量につくって何か分からな
くする事で現状を維持します。
3. 1.の結果として、組織を変えようという試みは、
弱みを指摘される事を嫌がったり、マネー
ジャー/スペシャリストの現状を維持しようと
する⼈々により、「純粋主義者」、「理論主
義者」、「⾰命主義者」、「現実に合わせる
ためにカスタマイズが必要だ」と⾮難されま
す。
4. ⽂化は構造に従います。
出典 : https://2016-conference.less.works/speakers/craig-larman.html

ガイド︓⽂化は構造に従う
“組織”の構成要素（グループ、役割、
階層、ポリシーまたはより広範には
“組織システム/設計“）が変更されない
限り、⾏動や考え⽅は変わることはな
いのです。
出典 : https://2016-conference.less.works/speakers/craig-larman.html

LeSSのコンセプト
組織をシンプルにし、“アジャイル”になるためには
どうすれば良いのか︖
少なくすることでもっと多く-More with LeSS

その他導⼊のガイド
n 役割は守らないが雇⽤は守る
l 改善の結果、⾃分が解雇されると思うと改善をしようとしない
n 完璧を⽬指しての組織ビジョン
l LeSSの完璧なビジョン
l この改善により、私たちは組織が理想とするビジョンに近づきますか︖
l この改善により、現場が改善されますか︖
n 継続的改善
l チームレトロスペクティヴ、オーバーオール・レトロスペクティブ
n 導⼊の拡⼤
l 他のプロダクトへ、Doneの定義の拡張、プロダクトの拡張など
『大規模スクラム Large-Scale Scrum(LeSS)』 P.64-69 より
「価値提供または、方向転換をいつでも
追加コストなしにできる組織をつくり出す」

マネジメント
⾃⼰管理
問題の解決⽅法
を教える
現地現物
マネージャーの役割
スクラムマスター
としてのマネージャー
改善サービスの提供
https://less.works/less/management/index.html

⾃⼰管理
n Y理論によるマネジメント
n 改善も含め⾃⼰管理するチームに責任を委譲する
43
全体の⽅向性の決定
チームと組織的
サポートの設計
作業プロセスと
進捗の監視と管理
チームタスクの実⾏
マネジャー
主導チーム
⾃⼰管理
チーム
⾃⼰設計
チーム
⾃⼰統治
チーム
マネジメントの責任
チームの⾃⼰責任
Leading Teams: Setting the Stage for Great Performances Harvard Business Review Press 2002年
著:J. Richard Hackman

組織の強さを作る存在としてのマネージャー
● 多くの権限をチームに移譲する
● チームとスクラムマスターが取り組んでいる障害の排除と改善を⼿助けする
114 5 マネジメント
図 5.1 LeSS の組織の概要
• プロダクトづくりと提供
• プロダクトのビジョンと方向性
• 組織の能力向上

LeSSでのマネージャーの役割5.1 LeSS でのマネジメント 115
図 5.2 3 つの重点領域への役割と責任
ります．たとえばですが，チームはデプロイの自動化を改善し，マネージャーはデ『大規模スクラム Large-Scale Scrum(LeSS)』 P.115 より

まとめ

LeSSでのポイント
n LeSSは基本的な考え⽅、プロセスはスクラムと同じ
l いきなりLeSSではなく、まずは1チームのスクラムを実践して
n LeSSの原理・原則は押さえておくことが重要
n LeSSを導⼊する際には、上級マネジメントの協⼒が必要になる
l 正しい構造を有したチームをつくる(組織構造を変える)
l ただしトップダウンだけではダメ。ボランティアを活⽤する
l 上級マネジメントを巻き込み、プロダクトチーム全体の
課題を取り除く(このあたりは@ScaleのEMTが参考になる)
「われわれに選択権はない．マネージャーがLeSS をやれといっている!」
と主張しはじめます．そして，おそらく無意識に，快適な，少なくとも慣れている被
害者という立場に身を置いたままやり過ごそうとします．

⼤規模スクラム Large-Scale Scrum (LeSS)
『⼤規模スクラム Large-Scale
Scrum(LeSS)』が丸善出版より出版
Less.works(https://less.works/)
最新の情報を掲載(⼀部⽇本語あり)

LeSS Study
n LeSS Large-Scale Scrum の勉強会
n LeSSのサイトである less.works を翻訳しながら
学び合う場として2015年から開催していた
n 2019年『⼤規模スクラム Large-Scale Scrum(LeSS)』
が丸善出版より出版されたことを期に読書会
として活動を開始
https://less-study.doorkeeper.jp/
https://www.facebook.com/groups/less.study/

アジャイルコーチから見たScaled Agile Method LeSS版

More Related Content

What's hot (20)

Similar to アジャイルコーチから見たScaled Agile Method LeSS版 (20)

More from Takao Kimura (18)

アジャイルコーチから見たScaled Agile Method LeSS版