#redajp
エンタープライズアジャイルにおける
要求探索の勘所
2018/7/23
鈴木雄介
グロースエクスパートナーズ株式会社 執行役員
日本Javaユーザーグループ 会長
要求開発アライアンス
2018年7月定例会

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

アジェンダ
• エンタープライズアジャイル
• なぜアジャイルなのか？
• エンタープライズアジャイルの勘所
»スコープを管理する
»リードタイムを管理する
»プロセスを共有する
• まとめ
2

#redajp
エンタープライズアジャイル
3

エンタープライズアジャイル
定義
• 明確な定義はない
• 私案：
»事業の中心がITサービスではない企業において、ITサービスを絡
めた事業展開を行う状況で採用されるアジャイル型開発のこと
»企業はすでにウォーターフォール型のシステム開発を実施してお
り、その環境下でアジャイル型開発を実施しようとしている
4

エンタープライズアジャイル
大規模アジャイルのこと？
• 他の定義：大企業における複数チーム展開のこと
»LeSS、DAD、SAFeなど
»複数チーム展開をするうえでのノウハウとしては有用
• より重要なのは「すでに完成されているウォータオーフォ
ール型開発プロセスがある上でのアジャイル導入」
»あまり規模には関係ないと考える
5

エンタープライズアジャイル
エンタープライズアジャイルあるある
• 稟議決裁
»決められた期間に決められた機能を決められたコストで
• 既存のルール
»すでに完成されたウォーターフォール前提のルール
• 部署の縦割り
»部署は自分の役割のみしかやらない
6

#redajp
なぜアジャイルなのか？
7

なぜアジャイルなのか？
開発の外側で起きていること
• そもそも、なぜウォーターフォール環境下でアジャイルに
取り組まなくてはならないのか？
• ウォーターフォールでは何がダメなのか？
• システム開発の外側では何が起きているのか？
8

9https://www.flickr.com/photos/iansand/5920421391/https://www.flickr.com/photos/peaceful-jp-scenery/16346037831/
SoR
mode1
SoE
mode2

開発現場の外側
企業システムの類型
• SoR（System of Record）/mode 1
»情報を正しく「記録」するためのシステム
»ユーザーは従業員が中心。取引情報を長期間にわたって保持し、
ビジネスの基幹となるシステム
»変更頻度は低め、システム障害影響大
• SoE（System of Engagement）/mode 2
»顧客や取引先との「絆」を作るためにシステム
»最新の状況を表示し、判断を行ってもらう。機能はユーザーごと
に最適化され、高頻度で改善していく
10

開発現場の外側
企業ITの軸足はSoRからSoEへ
• コストとしてのITから売上としてのITへ
»ITを通じて売上（主にLTV）を向上させる
»継続利用させるための仕掛けとしてのIT
»SoRはなくならないが、より重視するのはSoE
• SoEでは社内で仕様を決めきれない
»本当のユーザーは社内にはいない
»競合他社や市場環境の変化を受けやすい
11

なぜアジャイルなのか？
ウォーターフォールの進め方
• 最終成果物に向けて、フェーズごとの中間成果物を定め、
段階的に品質を確認する
• 中間成果物は基本的に文書
12
基本設計 実装 テスト要件定義
計
画
受
入
文書 文書 文書 文書文書

なぜアジャイルなのか？
ウォーターフォールの課題
• 途中で「欲しい最終成果物」が変化してしまう
»終わるころにはビジネス要件がさらに変化してもらう
• 中間成果物では品質が確認できない
»文書を見ているだけでは評価できないことがある
• 調整が後手後手になりやすい
»PMに集まる情報だけでは情勢の見極めが困難
13

なぜアジャイルなのか？
アジャイルソフトウェア開発宣言（2001年）
• プロセスやツールよりも個人と対話を、
• 包括的なドキュメントよりも動くソフトウェアを、
• 契約交渉よりも顧客との協調を、
• 計画に従うことよりも変化への対応を
14参考：http://www.agilemanifesto.org/iso/ja/

なぜアジャイルなのか？
アジャイルのアプローチ
• リソースを定め、短期＆定期的に計画と評価を繰り返す
• 評価は関係者全員で動くソフトウエアを確認
15
設計 実装 ﾃｽﾄ計
画
受
入
設計 実装 ﾃｽﾄ計
画
受
入
設計 実装 ﾃｽﾄ計
画
受
入

なぜアジャイルなのか？
アジャイルのメリット
• 「今」欲しいものを得られる
»このリリースで何かを得たいか、を決めればいい
• 定期的に評価ができる
»成果物へのフィードバックを元に改善をしていく
• プロセスではなくチーム
»現場チーム内で状況が共有できるので判断が行いやすい
16

なぜアジャイルなのか？
アジャイルのメリット
• ウォーターフォールは計画主導
»最初に決めた計画からのズレを管理する
• アジャイルは調整主導
»適宜、調整しながら最適を目指す
»計画ミスが大きいような領域では探索的なほうが効率的
17

なぜアジャイルなのか？
SoEでは、誰も正しい要求が分からない
• 正しい要求＝ビジネス成果を生み出す仕様
»成果が出るかどうかは結果論。やってみて調整していくしかない
• フィードバックを受けて改善していくことが大事
»アジャイル型で実現しやすいこと
• 継続的に要求探索をしていく必要がある
18

#redajp
Scrum
19

Scrum
Scrum/スクラム
20
スプリント
プランニング
スプリント
レビュー
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
インクリメント
プロ
ダクト
プロダクト利用
仕様検討
開発
リリース
フィードバック
顧客
プロダクト
オーナー
開発
チーム
アイデア
スプリント
レトロスペクティブ
スクラム
マスター

Scrum
主な用語
• 定期的な実行期間：スプリント
»計画：スプリントプランニング
»計測＆調整：スプリントレビュー
• 責任者：プロダクトオーナー
»製品価値の最大化に責任を持つ
▸PM（計画の立案と実行に責任を持つ人）はいない
▸計画の立案と実行はチーム全員で責任を持つ
• サーバントなリーダー：スクラムマスター
21

#redajp
エンタープライズアジャイルの勘所
22

エンタープライズアジャイルの勘所
実践にあたっての勘所
• スコープを管理する
• リードタイムを管理する
• プロセスを共有する
※多くの現場では、上記の段階を経て成熟していく
23
→POレベル
→企画と開発レベル
→組織レベル

#redajp
エンタープライズアジャイルの勘所
スコープを管理する
24

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

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

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

スコープを管理する
アジャイル：QCD→S
• アジャイルではチームとリズムが先にある
»チームサイズとリリースサイクルが決まればコストとスケジュー
ルは確定してしまう
»その中で実施できるスコープを決定する
• 稟議書に書いた範囲を実現できるかは「やりよう」
28

スコープを管理する
なぜQCDを先に決めるのか？
• チームの固定：効率的だから
»繰り返すことが前提のため調達コストを省く
»適度な人への依存
• 日付の固定：リズムが安定するから
»次のリリースが決まっていることでスコープ調整がしやすい
• ゆるやかに変更することは許容される
29

スコープを管理する
MVP（Minimum Viable Product）
• 優先度というよりはMVP（実用最小限の製品）
30https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

スコープを管理する
MVPを決める
• そもそも、何のための機能なのか？
»この製品は何を達成したいのか？
»ユーザーは、どんなプロセスを経るのか？
»具体的にどういった操作をするのか？
»その機能を実現するには、どうするのか？
• このレベルで、どこまでできていればいいかを決める
31
→目的
→要件定義
→基本設計
→詳細設計

スコープを管理する
「機能そのもの」よりも「使われ方」
• 使い方に注目することで機能を削減できる
32
製品
ｺﾝｾﾌﾟﾄ
製品に
出会い
製品を
使い
価値を
得る
カスタマー
ジャーニー
ユーザー
ストーリー
タスク
エレベーター
ピッチ
置かれ
た状況
具体的
な操作
得られ
る画面
DB
実装
画面
実装
テスト

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

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

スコープを管理する
ユーザーストーリー
• 形式：＜ロール＞が＜機能＞を行う。なぜなら＜ビジネス
価値＞をしたいから
»その機能が使われるコンテキストや、背景にあるビジネス価値（
顧客や利用者にとって何が嬉しいか）を伝える
»基本的には企画側で記載する
• このレベルで企画側と開発者がコミュニケーションを行う
»より簡単に実現する方法がないか？など
35

スコープを管理する
時は金なり
• リリースされない機能に意味はない
»リリースして、一刻も早くフィードバックを得る
»そのために、もっとも効率的な方法を選ぶ
• QCDに収まるようにスコープを調整するしかない
»その方が結果的には無駄なく良い製品ができる
36

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

#redajp
エンタープライズアジャイルの勘所
リードタイムを管理する
38

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

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

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

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

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

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

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

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

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

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

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

#redajp
プロセスを共有する
50

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

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

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

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

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

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

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

#redajp
まとめ
58

まとめ
エンタープライズアジャイルとは
• すでに完成されているウォータオーフォール型開発プロセ
スがある上でのアジャイル導入
• 稟議決裁
• 既存のルール
• 部署の縦割り
59

まとめ
なぜアジャイルなのか？
• アジャイルは調整主導
»ウォーターフォールは計画主導
• （特に）SoEでは、誰も正しい要求が分からない
»正しい要求＝ビジネス成果を生み出す仕様
»フィードバックを受けて改善していくことが大事
60

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

まとめ
スコープを管理する
• 「S→QCD」から「QCD→S」へ
• 優先順位というよりもMVPをどうするのか？
»何を提供するとMVPになるのか
»製品コンセプトから機能までのツリーを明確にする
▸エレベーターピッチ → カスタマージャーニー → ユーザーストーリー
• 稟議書との戦い
»何を実現することが本質
62

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

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

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