Agile 101 アジャイル基礎講座 PDF Free Download
1 / 43
/43
100%
Agile 101
アジャイル基礎講座
アジャイル組織開発
チーフコーチ
吉田 雄
1. アジャイルとは？
2. なぜアジャイル？
3. アジャイルの実践
付録. アジャイルスクラム入門
目次
2
アジャイルとは？
3
臨機応変 マニュアル通り 工夫 変えることなく
やってみなはれ
確実なプランを
自己裁量
指示を仰げ
当たって砕けろ
確実なプランで
お お ま か に こ ん な 感 じ で ど う ？ 仕 事 に 想 像 力
完璧主義 真面目にやれ全部出来てから持ってきて
私たちには仕事を、
チームワークを円滑
に進め、人を育てる
英知を昔から持って
います。
一方でその英知の反
対が必ずしも愚行と
言えないのもこの教
えの難しさです。
「アジャイル」は、
この古今東西からの
教えへの取り組みの
現代流の総称です。
4
アジャイルと「試行錯誤」
•イノベーションに試行錯誤(トライアル＆エラー)は不可欠ですが、試行錯誤そのものは有史以来存在しているも
のであり、アジャイルやデザイン思考が発明したものでは当然ありません。
•そもそも、デミングの PDCAサイクル (Plan-Do-Check-Act, W. Edwards Deming, 1950)や、OODAループ (Observe-
Orient-Decide-Act, John Boyd, 1976)は、リーン生産方式が浸透している日本では、既知の繰り返し検証型の問題解
決、ソリューション開発手法です。さらに歴史をもっと遡れば、ソクラテス(紀元前5世紀)や孔子(紀元前6世紀)
など古今東西の哲学者の教えの根底には必ず試行錯誤の思考があります。
•試行錯誤は実は生物学的には私達人間の本能に反する行動です。他の生き物同様、サバイバル本能のおかげで人
間はリスクを避ける基本的性質を持ち、そしてリスク無しには試行錯誤はありえないためです。人間は変化を嫌
うようにそもそもできているのです。
•一方で、リスクはリターンの原資であり、試行錯誤の繰り返しによってリスクが下がり、リターンが上がる現象
は、科学です。試行錯誤無しには進歩も進化もないので、古今よりこの本能に反する行動を説く教えが何千年も
連綿と続いているわけです。人類史は突き詰めればのこの試行錯誤と変化への抵抗の歴史です。
•アジャイルは、簡単に言えば、最新の「試行錯誤の試行錯誤」です。志は変わりません。
5
繰り返し検証型ソリューション開発手法はひとつだけではありません
ウォーター
フォール型開発
Plan
Do
Check
Act OODA
Observe
Orient
Decide
Act
リーン
スタートアップ
Build
MeasureLearn
デザイン思考
共感
問題定義
創造試作
検証
vs
アジャイル
スクラム
PDCA
(デミングホイール、
カイゼンサイクル等)
6
用語集：デザイン思考、アジャイル、リーン、スクラム、スプリント
▪アジャイルとリーンは出自は異なりますが、基本的には同じものと考えて大丈夫です。それは、アジャイルもリーンも
それぞれ繰り返し検証型の問題解決、ソリューション開発手法だからです。
▪デザイン思考も繰り返し検証型の問題解決手法ですので、アジャイルの一種と考えて差し支えありません。
▪リーンはさらに、トヨタに代表されるリーン生産方式・品質管理(1950年代前後発祥)と近代のリーンスタートアップ
(2000年代前後発祥)に分かれますが、いずれも仮説、検証、実験、繰り返しのプロセスですので、こちらも大まかに同義
と考えてください。
▪アジャイルも2000年代前後のスタートアップカルチャー顕在化に合わせて発祥した開発アプローチで、スクラムはその
中でも最も良く使われている実践フレームワークです。スクラムでは開発周期が超短期(典型的には二週間)で固定されて
おり、その周期をスプリントと呼びます。
▪まとめ：デザイン思考 ≈リーン ≈アジャイル ⊇スクラム ∋スプリント
▪その他にデザインスプリントやユーザーストーリーマッピング(USM)等様々な亜流、派生フレームワークがあります。それぞれに用途があり私(吉田コーチ)も使い
分けて併用しています。
▪スクラム以外のアジャイル開発手法としては、XP (エキストリームプログラミング)や Kanban (トヨタ生産方式のカンバンとはまた別)等が挙げられます。
▪大規模、あるいは拡張型スクラムにおいては、LeSS, SAFe, Nexus, Prince2 等様々なフレームワークが乱立しており、大企業向けサービスとして群雄割拠状態です。
7
なぜアジャイル？
8
ウォーターフォール型開発
ステージゲート型リニア開発プロセス
ウォーターフォールでは製品、事業が完成するまで
「売れるかどうか」テストできないので、失敗が高くつく
vs
仮説検証プロセスの繰り返し
プロトタイプ、MVP(実用最小限製品)
は失敗が安くつき、学習頻度が高い
アジャイル
ウォーターフォールはイノベーションの開発には適しません。不確実性要素の多い
プロジェクト、商品・サービス開発には繰り返し検証型のアプローチが必要です。
9
前提条件のマインドセット：繰り返し検証型開発プロセスのサポートにはリスク許容、
忍耐、自由な発想を促す人的開発環境が必要です。
time
output
ウォーターフォール型開発 アジャイル
一方で、アジャイルは自由度を求めるからといってランダムな開発プロセスではありません。アジャイルはマネジメント
サイエンスです： 仮説実験検証の科学的実証性に基づいた、規律のある開発プロセスが正しいアジャイルの姿です。
time
outcome
first step
second step
thereafter
10
従来型組織構造 有機的組織構造
vs
•垂直、統合型指令系統
•戦略的判断はトップリーダーの責任
•戦術的判断、実践指示は中間リーダーの責任
•戦術実践、成果回収は一般社員、チームの責任
•機能別チーム構成
従来型組織ではイノベーションの開発には構造的限界があります。イノベーションチームには
繰り返し検証型ソリューション開発手法により適した組織構造が求められます。
•円形、分散型指令系統
•他のチームとネットワークで繋がれた自律型
組織
•戦略、戦術、実践判断、実行は積極的にチー
ムに権限移譲
•リーダー、マネージャーはアライメントの
ファシリテートに注力、パフォーマンス支援
のコーチ役を担う
•クロスファンクショナル(機能横断的)チーム構成
11
Visual conceptual adaptation of Maslow, A. H. (1969). Theory Z. The Journal of Transpersonal Psychology, 1(2), 31-47.
https://agile-od.com/reflective-leadership/maslows-final-theory-z
自己実現
承認
帰属と愛
安全
生理的
サバイバル
自己超越
帰属と愛
承認
自己実現
自己超越
生理的サバイバル
安全
私達は仕事を任せられることが好きです。仕事を任せられ
ると：
•自分が信頼されていることを感じられ、安全欲求がまず
満たされ、さらにチーム、グループへの帰属欲求が満た
されます。
•自分の存在と実力が認められたと感じ、承認欲求が満た
されます。
•より良い仕事を自分の意志でやりたくなり、自己実現欲
求が満たされます。
また、アジャイルはチームワークです。自律型組織のサー
バントリーダー役に目覚めると：
•チーム員へのケアの精神からEQ(エモーショナルインテ
リジェンス)志向のマネージャー、リーダー的振る舞い
をするようになり、帰属と愛の欲求がより満たされます。
•自己実現を超えて、チーム、組織、社会への貢献に自分
の存在意義を見出し、自己超越欲求が満たされます。
マズローのモティベーション理論から見る
アジャイルに成功するとチーム員のやる気スイッチが入りやすい理由
12
繰り返し検証型開発の経済合理性
Investment Probability of
Success
Return of Success
Weighted
Average ROI
Investment in
1 go
$100 20% x20 $200
5
回に分けて投資
各回
+20% の改善
がみられることを
仮定
200万円 20% x20 800万円
200万円 40% x20 1,600万円
200万円 60% x20 2,400万円
200万円 80% x20 3,200万円
200万円 100% x20 4,000万円
成果
(仮定)1,000万円 12,000万円
プロダクト
マーケット
フィット達成
(仮定)
ROI 3x
ここからは作れ
ば売れる状況
仮説検証型開発はリスクを低減し、投資
収益性を向上させる堅実な開発手法です。
仮説
投資 成功率 成功時リターン 加重平均投資
リターン
一回で全投資
1,000万円 20% x20 4,000万円
ハイリスク、
ハイリターン的
性格のプロジェ
クトを想定
13
アジャイルの実践
14
選べます： 大文字 “A” Agile 、 小文字 “a” agile
Agile (大文字 “A” ) agile / agility (小文字 “a” )
▪大文字 Agile (アジャイル)は、
スクラムなどのフレームワーク
を忠実に導入して実践します。
▪チーム構成や役職、成果評価方
法・期間、予算編成、リクルー
ティング方法等、既存の組織の
枠組みから大幅に変更したセッ
トアップが必要です。
▪小文字 agile / agility (アジャイ
ル・アジリティー)は、アジャイ
ルの精神、マインドセットと習
慣を既存の仕事のフローに取り
入れます。
▪組織構造を手術することなく、
すぐに実践できるプラクティス
から選択的に取り入れられます。
15
大文字 “A” Agile ゾーン、 小文字 “a” agile/agility (アジリティー) ゾーン
Agile agile/agility
マインド 漸次漸進 (インクリメンタル) 導入 導入
マインド 繰り返しチャレンジ (ループ型活動) 導入 可能ならば導入
マインド 失敗歓迎、失敗から学ぶ 導入 可能ならば導入
マインド 不確実性対応 導入 導入
プロセス カスタマーバリューのあくなき追及 導入 導入
プロセス 改善 導入 導入
プロセス 変動プランニング(vs 固定プランニング) 導入 可能ならば導入
プロセス エビデンス・データ主義 導入 導入
組織 ステークホルダー、カスタマーコラボレーション 導入 導入
組織 クロスファンクショナル(機能横断型)チーム体制 可能ならば導入 推奨
組織 小チームセットアップ(10名以下) 導入 推奨
組織 自律型組織、自己管理型チームワーク(判断権限移譲含む) 導入 推奨
組織 リーダー、マネージャーがコーチ、ファシリテーター 導入 推奨
プロセス プロダクト開発マインドセット 導入 推奨
プロセス 特定のプロセスフレームワークを厳格運用 導入 推奨
プロセス タイムボックス、キャパシティーコントロールの使用 導入 推奨
プロセス 複数のアジャイルフレームワークの融合利用 導入 推奨
Agile
zone
agile/
agility
のココロは
組織全体に
Scrum は大文字 “A”
Agile ゾーン
16
アジャイルの精神 (スピリット)
カスタマーバリューの
あくなき追及
仮説、実験、検証 (学び)
漸次漸進 (インクリメンタル)
繰り返しチャレンジ
(ループ型活動)
個人、チームの自己裁量
を尊重
失敗歓迎
正しい失敗を責めない、
心理的安全性のある組織
コーチ、ファシリテー
ターとしてのリーダー、
マネージャー像
クロスファンクショナル
(機能横断型のチーム体制)
自律型組織、自己管理型
チームワーク
17
アジャイルはメソッド？
メソッド、メソドロジー、プロセス
アプローチ、フレームワーク、
スタイル、モード(仕事の仕方)、
態度、思考、マインドセット、
スピリット、志、道、カルチャー
アジャイルはメソッド
やプロセスを使います
が、メソッド、メソド
ロジー、プロセスその
ものではありません。
18
メソッドの先にあるもの
アジャイルの真髄は「クリティカルシンキング」にあり
ロジカル
シンキング
クリティカル
シンキング
メソッドは、ステップを踏んで物事を整理して考える、
ロジカル思考の実践で、大事です。でも、ロジカル思考
だけでは世の中の難しい課題は解決できません。
19
水平型思考
垂直型
思考
メソッド、ロジカルシンキングの限界
リニア思考の呪縛
リストや予定表作りは私たちの日常です。だから、ステップバイステップのメソッド
方式は直感的に受け容れ易く、大好きです。
メソッドはロジカルシンキングの実践です。理路整然として取り組みやすく、他の人
に何をやっているか説明しやすいですし、結果も予測がついて安心です。
でも、そういったメソッドは結局、直線的なアプローチ、リニア思考の域をでません。
リニア思考の問題点は二つです。ひとつはちょっとでも想定外のことが起きるとすぐ
に詰まってしまう、臨機応変さに欠けることです。
もうひとつは、機会損失です。リニア思考だけでは、近視眼的になりがちで、いわゆ
る木を見て森を見ずの状態になってしまいます。あ、なにか違う、という気づきの喜
びも、ちょっと違う風にやってみようかな、という工夫の楽しみもスルーしがちです。
時には立ち止まり周りを見回してみないと、そもそも機会(オポチュニティ、チャン
ス)を捉える以前に、機会があること自体を知らずに看過してしまいます。このあた
りがリニア思考の残念なところです。
20
並列思考 発散収束型思考 モザイク思考
クリティカルシンキングで見える違う景色
ノンリニア思考でブレークスルーしよう
21
クリティカルシンキングは、複雑性・不確実性への対応に必須のスキル
simple
シンプル
complicated
複合的に難易
complex
複雑
chaotic
カオス
難易度は高いが再現
性の高い属性の課題
リニア思考可
並列思考 発散収束型思考 モザイク思考
Cynefin framework, David J.
Snowden,
クナイヴィン・
フレームワーク、デビッ
ド・スノードン、
1999
変動要因が多く、最
終形が予測しにくい
属性の課題
ロジカル
シンキング
クリティカル
シンキング
ノンリニア思考必須
22
Agile & agile, 大切なのは…
個々人レベルでは…
組織レベルでは…
23
アジャイルスクラム入門
24
スクラム： 最もポピュラーなアジャイル実践フレームワーク
•ソフトウェア開発フレームワークとして発祥しましたが、現代では一般的な商品・サービス開発にもその適用は広
まっています。
•スクラムは時間制約型の開発フレームワークです。1~4週間のスプリントに開発周期をタイムボックスして開発成果
をアウトプット、検証、これを繰り返して行きます。
•スクラムは小集団活動です。スクラムチームは最大10名、そして3つの役割のチーム員のみで構成されます：ディベ
ロッパー(開発者、”Dev”)複数人、スクラムマスター(“SM”)一名, そしてプロダクトオーナー(“PO”)一名
•スクラムチームには管理職がいません。自律型組織としてチーム員自身全員でチームをセルフマネージ(自己管理)し
ます。PO、SMはマネージャーではありません。それぞれスクラムチームの「何を」(PO)、「どうやって」(SM)開発
するかをファシリテートする、サーバントリーダーです。
Images courtesy of sp-studio.de. Character concepts by Ron Eringa.
25
スプリント
レビュー
スプリント
レトロスペクティブ
プロダクト
バックログ
スプリント
プランニング
デイリー
スクラム
スプリント
「スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、
人々、チーム、組織が価値を生み出すための軽量級フレームワークである。」
https://scrumguides.org/d
ocs/scrumguide/v2020/20
20-Scrum-Guide-
Japanese.pdf
「プロダクトとは価値を提供する手段である。プロダクトは、明確な境界、既知のス
テークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、
サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある」
スクラムガイド2020年版
26
プロダクトバックログ
エピック
ストーリー
タスク
テーマ
ビジョン
エピック
ストーリー
タスク
スクラム
プロダクト
プロダクトバックログ
27
(1) まずやりたいことを全部書き出す
チーム名 or プロダクト名： [ ]
プロダクト・サービスの開発目標： [ ]
プロダクトバックログの作り方 (1)
現時点で考え得る限りの
コトだけでOK。完全であ
る必要性なし。小さいこ
とから大きいことまで、
あとで並べ直しますので
気にしないで大丈夫！
28
(2) グルーピングをする
チーム名 or プロダクト名： [ ]
プロダクト・サービスの開発目標： [ ]
プロダクトバックログの作り方 (2)
エピック: [ ]
ストーリー：
[ ]
タスク
29
(3) 開発ステップの優先順位をつける
チーム名 or プロダクト名： [ ]
プロダクト・サービスの開発目標： [ ]
プロダクトバックログの作り方 (3)
Priority 1 Priority 4
エピック: [ ]
ストーリー：
[ ]
タスク
Priority 2
Priority 3
30
スプリントプランニング
TO DO WIP (work in progress) DONE
プロダクトバックログ スプリントバックログ： [ スプリントゴール ]
各タスク、ストーリー
等レベル毎に
“Definition of DONE”
「完成の定義」が必要。
31
スプリントボード(かんばん)カスタム例
TO DO WIP TESTING DONE
トリアージュ Bumped Killed
Product Backlog
Mary Daisy
Jon Dan & Jon
Dan & Mary Nic
グループ化
予定外のリクエスト
作業員
ボード
検証
ボード
32
デイリースクラム (デイリースタンドアップ)
•毎日、同じ時間、15分以内
•推奨パターン：三点共有
•念押しです: スクラムマスター(SM)、プロダクトオーナー(PO)はマネージャーではありません。
デイリースクラムはSMやPOへの報告会ではありません。必要に応じてSMがファシリテート可能ですが、必ずしも毎日取り仕
切る必要はありません。参加必須者は開発者だけです。つまり、SMやPOが開発者の一員でない場合は、SMとPOは必ずしもデ
イリースクラムに出席する必要はありません。
•目的はチームワークのシンクロです。ただの朝礼や日時報告会で終わらせないように。
デイリースクラムはスクラムチームによる、スクラムチームのための毎日シンクロミーティングです。あくまで、チームワー
クのためにあるミーティングです。
✓昨日やった仕事の報告
✓本日やる予定の仕事の連絡
✓障害、問題点、要支援事項等の相談リクエスト
33
スプリントレビュー
•スプリントの最後に開催する開発成果発表、報告、検証ミーティングです。
•スクラムチームが主宰し、顧客、ステークホルダー、その他パートナー等を招待し
て開催します。スクラムチーム員のみでの内輪のスプリントレビューは本来の目標
から外れています。
•プロダクトオーナーがスプリントレビューをファシリテートします。
•開発者は、スプリントで開発した項目のうち、「完成の定義 (Definition of Done)」
を満たしたものを、参加者に発表、デモンストレーションします。完成の定義を満
たしていない開発項目(WIP項目)の発表は避けます。参加者に作りかけのものを検
証してもらっても意味がないためです。
•大事なのは、参加者からフィードバックをもらうことです。フィードバックに基づ
き、次のスプリントを現状想定している計画のまま進めるか、修正を入れるか、あ
るいは開発を中止するか、大事な判断が次に待っています。スプリントレビューは
検証の場です。
34
スプリントレトロスペクティブ (“レトロ”)
https://miro.com/
•スプリントレビューが「何 (what) を開発したか」を共有、振り返りするミーティングだとしたら、スプリントレトロスペ
クティブは「どうやって (how) 開発したか」、つまりチームワークの振り返りをするミーティングです。
•スクラムチームのみが参加します。外部オブザーバーは参加不可です。スクラムマスターがファシリテートします。
•チームワーク、開発手法、アプローチが：
1. うまく行っていてもっとやるべき点
2. うまく行っていなくてやめるべき点
3. 新しく試してみたいやり方
を議論するやり方が一例です。レトロはその他いろいろなや
り方がありますので、自由に試してみてください。
•レトロの最後までに必ずひとつ、チームとして改善をコミッ
トするアクションを決めてください。このアクションは次の
スプリントプランニングでスプリントバックログに入れて、
確実に取り組めるようにします。もちろん、完成の定義の設
定と次のスプリントレビューでの検証も忘れずに。
35
スクラムチームと責任
スクラムチーム
スクラムチームは、1人のプロダクトオーナー、1人のスクラムマスター、開
発者で構成されています。スクラムチームは通常10人以下で構成され、サブ
チームや階層はありません。スクラムチームは機能横断的 (cross-functional) で
あり、メンバーは各スプリントで価値を生み出すために必要なすべてのスキ
ルを持っています。また、スクラムチームは自己管理し、誰が何をいつどの
ようにするかを外部の影響を受けずスクラムチーム内で決定します。スクラ
ムチーム全体が毎スプリントで価値のある有用なインクリメントを作成する
責任があります。
開発者
開発者はスクラムチームのメンバーであり、各スプリントで利用可能なイン
クリメントのあらゆる側面を、完成の定義 (Definition of Done) に従って品質を
確保して作成する責任を持ちます。
プロダクトオーナー
プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値
を最大化することの結果に責任を持ちます。
スクラムマスター
スクラムマスターは、スクラムガイドで定義されたスクラムを確立させるこ
との結果に責任を持つ。スクラムマスターは、スクラムチームと組織におい
て、スクラムの理論とプラクティスを全員に理解してもらえるよう支援する
ことで、その責任を果たします。
https://www.scrum.org/resources/blog/accountabilities-scrum
スクラムでは、これらの役割がフルタイムである必要
性があるか、パートタイムで良いかなどは指定してい
ません。これは意図的です。
36
吉田コーチ紹介
コーチ：吉田 雄
Takeshi Yoshida
Chief Coach and Founder,
Lifecycle Pte. Ltd. (シンガポール)
1994~2001: モルガン・スタンレー
2002~2004: バンクオブアメリカ
2004~2009: ドイツ銀行
2009~2011: バークレイズ
2011~現在: Lifecycle Pte. Ltd.
•スタートアップ起業家
•コーチ、トレーナー、ファシリテーター
•Agile Organization Development 主宰
•INSEAD エグゼクティブプログラム講師
1994年: 国際基督教大学
教養学部学士
2002年: 仏INSEAD 経営学修士
(フレッシュフィールド奨学生)
認定資格
International Association of Positive Psychology
Coaches (IAPPC)
Certified Positive Psychology Coach (CPPC) Level II
International Coach Federation (ICF)
Associate Certified Coach (ACC)
(Credential: https://coachfederation.org)
Scrum.org
Professional Scrum Master II (PSM II)
Professional Scrum Product Owner (PSPO)
(Certifications: https://www.scrum.org/user/498256)
Organization and Relationship Systems
Coaching (ORSC ) Trained
Hogan Certified Level I & II (Advanced
Interpretation: HPI, HDS, MVPI, Team Report)
•顧客プロジェクト例(現在):
•コンサルティング大手: Bain External Advisor
•欧州グローバル食料品大手: Agile transformation advisor and agile coach for CIO/CTO board
•欧州グローバル食料品大手: Agile Scrum coach for plant-based food innovation team
•欧州コンサルティング準大手: Organization wide leadership development programme director
•シンガポール政府系機関: Service Design consultant and senior leadership team coach
•グローバル保険大手: Agile cultural transformation programme lead coach and trainer
•顧問エグゼクティブコーチ: Global financial institutions, MNCs, GAFA
行動心理学コーチ プロセスコーチ
組織開発
コーチ
吉田コーチの英文記事
Knowing to Stop, a
Confucius Teaching
Radical Candor, My Go To
Feedback Routine
A Pretty Good Summary of Lean,
Agile, Scrum
Lean, Lean Manufacturing, Lean
Startup: Explained
Try Design Thinking + Scrum: A
Powerful Hybrid Agile Approach
A picture containing drawing
Description automatically generated
How to Get Scrum Right on First
Attempt: Single Sprint Scrum Pilot
A picture containing dune, sand
Description automatically generated
A close up of text on a white background
Description automatically generated
Strategy Session Facilitation with
Design Thinking + Liberating Structures
Waterfall Agile: Addressing the Irony of
Delivering Agile Transformation with
Waterfall
Innovation Manager's Toolkit - Lifecycle - agile-od.com
Innovation Manager’s Toolkit
Mental Model Dōjō TV - Ambidextrous Organizations Explained
Ambidextrous Organizations
Explained
