2018/10/17に開催されたエンタープライズアジャイル勉強会 2018年10月セミナーでの講演「エンタープライズアジャイルでチームが超えるべきこと」の資料です。

1. エンタープライズアジャイルで
チームが超えるべきこと
2018/10/17
鈴木雄介
グロースエクスパートナーズ株式会社 執行役員
日本Javaユーザーグループ 会長
エンタープライズアジャイル勉強会
2018年10月セミナー

2. 自己紹介
鈴木雄介
• グロースエクスパートナーズ（株）
» 執行役員/アーキテクチャ事業本部長
» http://www.gxp.co.jp/
• 日本Javaユーザーグループ
» 会長
» http://www.java-users.jp/
• SNS
» http://arclamp.hatenablog.com/
» @yusuke_arclamp
1

3. アジェンダ
• エンタープライズアジャイル
• WFとアジャイルの橋渡し
• エンタープライズアジャイルの勘所
»スコープを管理する
»リードタイムを管理する
»プロセスを共有する
• まとめ
2

4. エンタープライズアジャイル
3

5. エンタープライズアジャイル
私の定義
• ウォーターフォール型プロセスや基幹システムといった既
存のルールやシステムが存在する中で導入されたアジャイ
ルのこと
• 導入規模は関係なし。
»この資料では大規模アジャイル（LeSS、DAD、SAFeなど）のこ
とではない
4

6. エンタープライズアジャイル
なぜ取り組むのか？
• 新規事業を支えるITに適用したい！
»いわゆるSoE/mode2的なシステム
• 試行錯誤をしたい！
»仕様を社内だけで考えていても正解が分からない
»動くものを作り、フィードバックを受けて改善したい
• より早く変化に対応したい！
»リリースサイクルを短くしたい
5

7. エンタープライズアジャイル
ウォーターフォールの限界
• 既存のシステム開発プロセスでは対応できない
»SoR/mode1的なシステムを前提としている
• いわゆるウォーターフォールでは対応しにくい
»「全体」を対象に作業を進めるのでリリースまでが遠い
»アジャイルは「部分」を対象に作業を進めるのでリリースタイミ
ングをコントロールできる
6

8. エンタープライズアジャイル
価値が出るタイミングが早くなる
※部分最適によるオーバーヘッドは出てしまうが
7
従来型
アジャイル

9. エンタープライズアジャイル
いかに取り組むか？
• 独立した組織、意思決定プロセス、場所を用意すべし
• 既存と関わる部分にはブリッジを用意すべし
8
既存のやり方
新しいやり方
既存の
やり方
新しい
やり方
ブリッジ
現実的には、この間のどこか

10. エンタープライズアジャイル
ブリッジをうまくやる
• 慣性の法則
»「新しいやり方」は決まっていない
»多くの人は「既存のやり方」との違いがものすごく気になる
▸「既存のやり方」を正しいものとしてやってきた
▸その正しさをどうやって維持すればいいの？
▸もちろん、「新しいやり方」がダメなわけじゃないけど…
• いかに、うまく橋渡しするのか？
9

11. WFとアジャイルの橋渡し
10

12. WFとアジャイルの橋渡し
アジャイルソフトウェア開発宣言
11

13. WFとアジャイルの橋渡し
既存のやり方にも価値があると認める
• 「全てが無価値」とは考えない
»確かに無駄も多いし、非効率的な面もある
»でも、必要性があったからやっていることも多い
»一定の敬意は大切なこと
• ギャップを認め、対応する
»もちろん、すべてを受け入れることもない
»そのための「橋渡し」であるべき
12

14. エンタープライズアジャイル
ありがちなギャップ 1/2
• 旧来型システム開発とのギャップ
»開発プロセス
▸案件決定からリリースまで6か月以上
»システム構成
▸モノリシック、夜間バッチによるファイル連携
»統制
▸品質、セキュリティ、各種手続きと形式的な文書
13

15. エンタープライズアジャイル
ありがちなギャップ 2/2
• 旧来型システム開発を取り囲むものとのギャップ
»組織体制
▸役割分担、文書による引継ぎ
»意思決定プロセス
▸稟議決裁（稟議書通りにできないとダメ）
»業務プロセス
▸マニュアル主義、既存踏襲、人間判断重視
»文化
▸リスク回避、責任回避、保守的
14

16. エンタープライズアジャイルの勘所
15

17. エンタープライズアジャイルの勘所
実践にあたっての勘所
• スコープを管理する
• リードタイムを管理する
• プロセスを共有する
16

18. エンタープライズアジャイルの勘所
スコープを管理する
17

19. スコープを管理する
QCDS
• 品質（Quality）
• 価格（Cost ）
• 納期（Delivery ）
• 範囲（Scope）
»提供される機能の範囲
18

20. スコープを管理する
ウォーターフォール：S→QCD
• ウォーターフォールでは「何を作るか」を決めてから、必
要な期間とコストを決定する
»スコープ管理の成果としてWBSを作成
»WBSを基にスケジュールとコストを算出
»そして、必要なリソースを調達する
• 要件定義のスコープを実現するためにどうするか？
19

21. スコープを管理する
アジャイル：QCD→S
• アジャイルではチームとリズムが先にある
»チームサイズとリリースサイクルが決まればコストとスケジュー
ルは確定してしまう
»その中で実施できるスコープを決定する
• やりたいことは最初には決まらない
20

22. スコープを管理する
なぜQCDを先に決めるのか？
• チームの固定：効率的だから
»繰り返すことが前提のため調達コストが省かれる
»人の学習能力と依存 ＞ 適切な要員の調達
• 日付の固定：リズムが安定するから
»次のリリース日があることでスコープ調整がしやすい
• ゆるやかに変更することは許容される
21

23. スコープを管理する
作業の区切り方が変わる
• 要件定義や基本設計をしないわけではない
22
企画
要件
定義
基本
設計
実装 テスト
企画
要件
定義
基本
設計
実装 テスト
WBS
従来型
（常に全体）
アジャイル
（概要と部分）
基本
設計
実装 テスト
基本
設計
実装 テスト
スプリント0
スプリント1
スプリント2
スプリント3
要件
定義
要件
定義

24. スコープを管理する
いかにして部分のスコープを確定するか？
• そもそも、何のための機能なのか？
»この製品は何を達成したいのか？
»ユーザーは、どんなプロセスを経るのか？
»自社は、どんなプロセスで実現するのか？
»具体的にどういった操作をするのか？
»その機能を実現するには、どうするのか？
• このレベルで、どこまでできていればいいかを決める
23

25. スコープを管理する
「機能そのもの」よりも「使われ方」
• 使い方を基準にして「部分」が成立することを保証する
24
開発
方針
製品に
出会い
製品を
使い
価値を
得る
カスタマー
ジャーニー
ユーザー
ストーリー
タスク
インセプション
デッキ
置かれ
た状況
具体的
な操作
得られ
る結果
DB
実装
画面
実装
テスト
製品
ｺﾝｾﾌﾟﾄ
リーン
キャンバス
どの部
署が
何をし
て
どうす
る
サービス
ブループリント

26. スコープを管理する
リーンキャンバス
• 誰にとって価値があるサービスなのか？
»この時点で優先順位を明確にしてもらう
25
課題
※代替品
ｿﾘｭｰｼｮﾝ 独自の
価値提案
圧倒的な
優位性
顧客
ｾｸﾞﾒﾝﾄ
主要指標 チャネル
コスト構造 収益の流れ
①② ③
④
⑤
誰の
どんな課題を どんな機能で
どんな特徴が
なにで評価する

27. スコープを管理する
インセプションデッキ
26参考：アジャイルサムライ−達人開発者への道
→目標
→概要
→イメージ
→機能の優先順位
→ステークホルダー
→概要アーキテクチャ
→リスク
→マイルストーン
→PDCSの優先順位
→コスト
• 我われはなぜここにいるのか
• エレベーターピッチを作る
• パッケージデザインを作る
• やらないことリストを作る
• 「ご近所さん」を探せ
• 解決案を描く
• 夜も眠れなくなるような問題は何だろう
• 期間を見極める
• 何を諦めるのかをはっきりさせる
• 何がどれだけ必要なのか

28. スコープを管理する
インセプションデッキ/エレベーターピッチ
• リーンキャンバスの結果をサマリ
• [プロダクト名] というプロダクトは、
• [潜在的なニーズを満たしたり、
潜在的な課題を解決したり] したい
• [対象顧客] 向けの、
• [プロダクトのカテゴリー] です。
• これは [重要な利点、対価に見合う説得力のある理由] ができ、
• [代替手段の最右翼] とは違って、
• [差別化の決定的な特徴] が備わっている。
27参考：アジャイルサムライ−達人開発者への道

29. カスタマージャーニー
• 顧客がサービスを利用する際の行動を時系列で整理
»顧客視点で思考・感情を表現
»タッチポイントに自社業務が入ってくる
スコープを管理する
28http://www.ux-lady.com/wp-content/uploads/2013/03/time-line-exp-map-starbucks.jpg
感情（ポジティブ/ネガティブ）
フェーズとタッチポイント
具体的な行動

30. スコープを管理する
サービスブループリント
• カスタマージャーニーを業務フロ
ーに落とし込む
»組織内のアクター（含むシステム）
が登場し、どのように処理をおこな
っていくのかを記載する
»いわゆるアクティビティ図として記
載してもOK
▸概要レベルと画面単位レベルの2段階
29https://u-site.jp/alertbox/service-blueprints-definition

31. スコープを管理する
ユーザーストーリー
• ＜ロール＞が＜機能＞を行う。なぜなら＜ビジネス価値＞
をしたいから
»その機能が使われるコンテキストや、背景にあるビジネス価値（
顧客や利用者にとって何が嬉しいか）を伝える
»より大きな単位で整理することも可＝エピック
• このレベルで企画側と開発者がコミュニケーションを行う
»より簡単に実現する方法がないか？など
»このレベルで見積もり可能になっていること
30

32. エピック
スコープを管理する
タスク
• ユーザーストーリーを実現するための具体的な作業
»この時点で見積もりを行って、そのスプリントに入る範囲を整理
する
31
ﾕｰｻﾞｰｽﾄｰﾘｰ
ﾕｰｻﾞｰｽﾄｰﾘｰ
ﾕｰｻﾞｰｽﾄｰﾘｰ
エピック
ﾕｰｻﾞｰｽﾄｰﾘｰ
ﾕｰｻﾞｰｽﾄｰﾘｰ
ﾕｰｻﾞｰｽﾄｰﾘｰ
プロダクトバックログ スプリントバックログ
ﾕｰｻﾞｰｽﾄｰﾘｰ
ﾕｰｻﾞｰｽﾄｰﾘｰ
タスク
タスク
タスク
タスク
タスク

33. スコープを管理する
プロジェクトを立ち上げる
• 最初のリリースまで3か月を目標に
»スプリント0を1～2か月で駆け抜ける
»スプリント3ぐらいでβリリース
32
ﾘｰﾝ
ｷｬﾝﾊﾞｽ
ｲﾝｾﾌﾟｼｮﾝ
ﾃﾞｯｷ
ｶｽﾀﾏｰ
ｼﾞｬｰﾆｰ
ｻｰﾋﾞｽ
ﾌﾞﾙｰﾌﾟﾘﾝﾄ
ﾕｰｻﾞｰ
ｽﾄｰﾘｰ
ﾀｽｸ 成果物
ﾕｰｻﾞｰ
ｽﾄｰﾘｰ
ﾀｽｸ 成果物
ﾕｰｻﾞｰ
ｽﾄｰﾘｰ
ﾀｽｸ 成果物
スプリント0
スプリント1
スプリント2
スプリント3
ｶｽﾀﾏｰ
ｼﾞｬｰﾆｰ
ｻｰﾋﾞｽ
ﾌﾞﾙｰﾌﾟﾘﾝﾄ
ｶｽﾀﾏｰ
ｼﾞｬｰﾆｰ
ｻｰﾋﾞｽ
ﾌﾞﾙｰﾌﾟﾘﾝﾄ

34. スコープを管理する
MVP（Minimum Viable Product/実用最小限の製品）
• どうやって部分を積み重ねるかが肝
»残念ながら「こうすればいいです」はない…
33https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

35. スコープを管理する
稟議書との戦い
• 稟議書の書いた内容/期限/費用を守って欲しい
»試行錯誤の結果、工数が足りなくなっても
• 全部、大事なんです
»優先順位を決められず「要件が決まった機能」から作ってしまう
▸要件がすぐ決まる≒あまり価値がない機能
• 全部ないと意味がないんです
»全機能そろうまでリリースができない
34

36. スコープを管理する
稟議書との戦い
• だって、稟議書に書いてあるし
»稟議書に書いてあるとおりにやってうまくいくならアジャイルに
しなければよかったのに
• 稟議書通りに実行することも大事だし、価値あるものを作
ることも大事
»この戦いを真剣にやれるかどうか
35

37. エンタープライズアジャイルの勘所
リードタイムを管理する
36

38. リードタイムを管理する
起こりがちな問題
• 開発中に続々と「急ぎの案件」が持ち込まれる
»「急ぎ」がバックログに積まれていく
• 承認者と合意した後で技術的に実現できないことが分かる
»見積り精査できていない機能で承認されている
• 開発したものの業務や営業調整で変更がはいる
»仕様が固まっていないものがバックログに入る
37

39. リードタイムを管理する
バックログの精度を明確にする
• プロダクトバックログには見積り可能なものしかいれない
»仕様が不明瞭、技術的に曖昧
»技術的に可能かを確認する、といったバックログはOK
• 手前に「候補」を管理する箱を作る
»Opportunity Backlogなどと呼称
38
候補
バックログ
プロダクト
バックログ
スプリント
バックログ

40. リードタイムを管理する
リリースサイクルとリードタイム
• リリースサイクル：製品を出荷するサイクル
»1日、1週間、2週間、1か月、3か月、6か月、12か月…
»短いほど、たくさんフィードバックを得ることができる
• リードタイム：企画してから配送されるまでの期間
»調整事項が少ないほど短くできる
»短いほど、フィードバックをたくさん改善できる
39

41. リードタイムを管理する
リリースサイクルとリードタイムの一致
• リリースは3か月おきにしたいがリードタイムは6か月
»つまり、2チームいないと回らない
»もしくは、企画と開発が交互
40
6か月
6か月
6か月
3か月（企画） 3か月（開発）
3か月（企画） 3か月（開発）
3か月（企画） 3か月（開発）

42. リードタイムを管理する
リードタイムは調整の多さに依存する
• 調整が多いほどリードタイムは長くなる
»稟議を伴う新機能のリリース
»業務プロセスの変更を伴うリリース
»新しい技術を採用するリリース
• 調整が少ないほどリードタイムは短くなる
»単純なバグの修正
»UIのちょっとした改善
»少しのリファクタリング
41

43. リードタイムを管理する
複数のリリーストレインを走らせる
• リリーストレイン
»列車は定刻通りに出発し、規定の乗客を乗せる
»遅刻したら次の電車を待つか、別料金でタクシーに乗るしかない
• 複数のリリーストレイン
»近距離：少しの駅に止まり、小さく、頻繁に運行される
»長距離：たくさんの駅に止まり、大きく、たまに運行される
42

44. リードタイムを管理する
近距離リリーストレイン
• リードタイムが短い案件
»調整ごとが短く、短期でリリースされる
»リリースサイクルとリードタイムが一致しやすい
▸2週間～1か月ごとにリリース
▸2週間～1か月で企画から開発まで完了させる
43

45. リードタイムを管理する
長距離リリーストレイン
• リードタイムが長い案件
»調整ごとが多く、段階を経てリリースされていく
»3-6か月程度のかたまりで検討を行う
▸もちろん、細かい
44

46. リードタイムを管理する
臨時リリーストレイン
• 緊急対応のバグ
»本番影響ありのバグに対する対応
»いつでも走らせておくようにできること
▸近距離リリーストレインに保守作業バッファを持っておく
▸予定外作業の割合を管理しておく
»影響度が大きい場合は定刻列車に影響を与えて対応する
▸スコープをより小さくする
▸定刻スケジュールを変えるのは最後の手段
45

47. リードタイムを管理する
稟議とバックログ
• 稟議が通ったらバックログに追加する
»稟議を通すための作業（見積り/検証など）は、見積りや検証作業
として保守作業枠で実施する方が便利
»稟議との戦いは前提として
46

48. 利用期間
リードタイムを管理する
本当のリードタイム
• 企画してから学びを得るまで
»リリース後、顧客からのフィードバックが得られるまでを期間と
して見るほうが望ましい
»稟議は効果検証まで伴っているのを見ることは少ないが…
47
3か月（企画） 3か月（開発）
3か月（企画） 3か月（開発）
3か月（企画） 3か月（開発）
3か月（企画） 3か月（開発）

49. プロセスを共有する
48

50. プロセスを共有する
起こりがちな問題
• たくさんの関係部署から個別に相談が持ち込まれる
»POがオーバーワークになって開発に相手ができない
• 複数チーム間で技術的な不整合や重複が生まれる
»チーム間で互いのやることを知らないというムダ
• 既存ルールに従わないことが受け入れられない
»部署の縦割りによって「今まで通り」以外は対応しない
49

51. プロセスを共有する
企画から配送までの流れを共有する
• 部署を跨がって全体を整理し、共有する
• 企画～開発～運用～業務～営業
»企画：企画書を書いて稟議を通す
»開発：企画書に従って開発を行う
»運用：開発成果物を動かす
»業務：業務を回す
»営業：顧客に売る
50

52. プロセスを共有する
VSM（Value Stream Mapping）
• 製品またはサービスを初期から顧客に提供までの「価値の
流れ」を表現することで課題を洗い出し、改善するための
手法
»特にリードタイム（待ち時間）に注目して無駄を取り除く
»元々は製造業におけるリーンマネジメントの手法で、トヨタでは
「材料と情報フローのマッピング」として知られる
51

53. プロセスを共有する
VSM（Value Stream Mapping）
• タスク単位にリードタイムを明確にする
»待ち時間：前タスクの完了から、タスクが開始されるまでの時間
»実施時間：タスク自体に必要な時間
»リードタイム＝待ち時間＋実施時間
• 成果物も併記するとよい
»特にチームを跨がるところのIN/OUTは明確に
• 課題箇所を発見し、改善策を練る
»ムリ、ムラ、ムダの排除
52

54. プロセスを共有する
53
約5.5メートル
約2メートル

55. プロセスを共有する
プロセスとして定義
• 部署間で共有し、プロセスと日付をすり合わせる
»リリースサイクルのスケジュールは1年間決めてしまう
»誰と合意するのか、誰が承認するのか、などを明確に
• 概要プロセスの例：
54
全体方針
策定
候補案件整理
（4w）
候補案件整理
（随時実施）
ﾘﾘｰｽ内容確定
（6W）
テスト
（3w）
ﾘﾘｰｽ内容確定
（2W）
実装
（12w）
実装
（4w）
テスト
（1w）
リリース
（1w）
リリース
（0W）
リードタイム：
26w（6~7か月）
リードタイム：
7w（2か月弱）
新機能リリース（リリースサイクル：3-4か月）
定期改善リリース（リリースサイクル：毎月）

56. プロセスを共有する
プロセスに対する厳密さは重要課題
• アジャイルはプロセスが厳密
»実はウォーターフォールのほうが適当にごまかせる
• この厳密さを組織全体で共有し、実践することが大事
»ウォーターフォール環境を大きく変えることなく、アジャイルの
実践は可能
»ただし、各部署の協力は必須（縦割りのままでは難しい）
55

57. まとめ
56

58. まとめ
エンタープライズアジャイル
• 既存のウォータオーフォール型開発プロセスやレガシーシ
ステムがある上でのアジャイル導入
• 既存のやり方と新しいやり方をブリッジする
»否定せず、両者の折り合いをつけていく
57

59. まとめ
エンタープライズアジャイルの勘所
• スコープを管理する
• リードタイムを管理する
• プロセスを共有する
58

60. まとめ
スコープを管理する
• 「S→QCD」から「QCD→S」へ
• 全部を相手にせず、部分を積み重ねる
»「使い方」に注目して検討を進める
▸リーンキャンバス → インセプションデッキ → カスタマージャーニー →
サービスブループリント → ユーザーストーリー →タスク
• 稟議書との戦い
»何を実現することが本質
59

61. まとめ
リードタイムを管理する
• バックログの精度を管理する
»見積もれない精度のものをプロダクトバックログにいれない
• リリーストレイン
»リリースサイクルよりもリードタイムを重視する
»調整事の多さに合わせて長距離～近距離向けの電車を走らせる
▸長距離：6-12ヶ月リリース
▸近距離：1ヶ月リリース
▸臨時：バグなど随時
60

62. まとめ
プロセスを共有する
• 開発チームが1つだとしても、実質的には複数チーム
»エンタープライズアジャイルではたくさんの部署を跨がる
• VSMを使って現状を整理し、改善を行う
»ムリ、ムラ、ムダの排除
• プロセスを厳密に運用することで組織として効率化を目指
す
61

63. まとめ
エンタープライズアジャイルは楽しい
• いままでとは違うことができるというワクワク感が強い
»もちろん、面倒なこともたくさんある
• 組織内の全ての人がアジャイルプロセスに参加する
»エンタープライズアジャイルの目指す姿
»ウィーターフォールプロセスにも良い影響を与えるはず
62

64. QA
63