10/1に実施したBABOKセミナーのセッション2「Agile meets BABOK」のスライドです。

1. 株式会社ゼンアーキテクツ
岡 ⼤大勝 ／ 三宅宅 和之
Agile meets BABOK
ディシプリンド・アジャイル・デリバリーに⾒見見る
アジャイル・ビジネスアナリシス
「IIBAⓇ、IIBAⓇのロゴ、BABOKⓇ
、およびBusiness
Analysis
Body
of
KnowledgeⓇ
は、Interna6onal
Ins6tute
of
Business
Analysisの登録商標です。
CBAPⓇおよびCCBAⓇは、Interna6onal
Ins6tute
of
Business
Analysisの登録認定マークです。
Cer6fied
Business
Analysis
Professional、Cer6fica6on
of
Competency
in
Business
Analysis、Endorsed
Educa6on
Provider、EEP、および EEPのロゴは、
Interna6onal
Ins6tute
of
Business
Analysisの商標です。」

2. ⾃自⼰己紹介
2
• 三宅宅 和之（Kazuyuki Miyake）
• @kazuyukimiyake
• ゼンアーキテクツ(旧SPEI)共同創業者
• ユーザ出⾝身（元銀⾏行行員）
• PMI認定PMP、MCP（HTML5、CSS3、JavaScript）
• 専⾨門分野
• フロントエンド開発
• 要求管理理
• 書籍・記事など
• 要求の「基本原則」、「本当に使える開発プロセス」
• DAD⽇日本語版翻訳チーム（⽅方向付けフェーズを担当）

3. そもそも「アジャイル」は必要なのか？
3
• ウォーターフォールで何が悪い？
• いや、悪くない
• QCDを最初に厳密に規定し計画するのがウォーターフォール。
• 計画通りにプロジェクトが完了了するのであれば、むしろ望ましい
• なぜ、別の⼿手法が必要なのか
• プロジェクトが「最初に規定し計画した通り」に進まない。
• なぜ、計画通りに進まないのか
• システム開発には、不不確定要素が多い＝「リスク」
• 「要求リスク」「スキルリスク」「技術リスク」「政治リスク」
できるだけ早い時点でリスクをキャッチアップしながら
プロジェクトを進める⼿手法が必要

4. システム開発のリスク
4
• 要求リスク
• 当初想定からの機能の増加（スコープの拡⼤大）
• 要件の認識識不不⾜足（⼿手戻り、再作業）
• 仕様の決定が遅れる
• 不不適切切なUI
• 顧客による継続的な変更更要求
• 技術リスク
• 想定していた性能が出ない
• 想定される動作をしない（接続できない、想定外のエラー）
• ⽬目的に合致しない技術（拡張性、接続性）
• スキルリスク
• 利利⽤用技術の経験がない
• 今回の開発プロセスの経験がない（初めての進め⽅方）
• 政治リスク
• ..
BA（ビジネスアナリシス）の
必要性に異異論論の余地はない

5. 【参考】開発プロセスの歴史
l 1960年年代：「Code & Go」
l 「聞いて、書いて、動かす」
l 1970年年：「ウォーターフォールモデル」Winston Royce
l 「設計」の発明
l 要求を正しく扱うため「分析」の導⼊入など、その後も進化を続ける
l 1988年年：「スパイラルモデル」Barry Bohem
l 「⽬目標」「リスク分析」「実施」「計画」のサイクルで⼯工程が進む
l 1991年年：「反復復型（イテレーティブ）開発」「漸進型（インクリメンタル）開発」
l ⼩小さな単位で開発することで、リスクを早期に識識別する。
l 1992年年：「Vモデル」German Ministry of Defense
l ウォーターフォールモデルに品質保証の観点を追加。
l 1998年年：「ユニファイド・プロセス（UP）」Jacobson, Booch, Rambaugh
l ユースケース・UMLに基づくオブジェクト指向開発プロセス。Rational社による商⽤用版が「RUP」
l 1999年年：「エクストリーム・プログラミング（XP）」Kent Beck
l ドキュメントよりもコラボレーションに焦点を当てた軽量量開発プロセス。
l 2002年年：「スクラム（Scrum）」Ken Schwaber, Mike Beedle
l 価値駆動の軽量量開発プロセス。原型は1986年年に⽵竹内弘⾼高⽒氏、野中郁次郎郎⽒氏が考案した製品開発⼿手法。
l 2009年年：「SEMAT」Jacobson他
l 過去のソフトウェアエンジニアリング体系にアジャイルの⾏行行動を組み合わせたプロセスフレームワーク。
l 2012年年：「ディシプリンド・アジャイル・デリバリー」Scott W.Ambler, Mike Lines
l エンタープライズ開発にアジャイル⼿手法を適⽤用した開発プロセス。
5

6. アジャイルは何が違う？
6
• 進め⽅方が違う（だけ）
• 個々の作業は同じ
• プロセスフレームワークの組み合わせが違う
• “計画通りには進まない“ことに対処する。
• 動くシステムを使って（作って）みなければ、正しいかどうか分からない
• ⼿手直し（軌道修正）しながら進むために、作業⼯工程を⾝身軽にする
• ⼯工程別フェーズ → 反復復型フェーズ
• 成果物駆動 → ジャストインタイム
• 計画駆動 → タイムボックス（価値駆動）
ウォーターフォール ”型” アジャイル ”型”

7. プロセスフレームワークの組み合わせ
• 開発プロセスの違いは、
プロセスフレームワークの組み合わせの違い
• ⼯工程別フェーズ x 成果物駆動 x 計画駆動
• ウォーターフォールモデル
• V字モデル
• 反復復型フェーズ x ジャストインタイム x タイムボックス（価値駆動）
• スクラム
• XP
• 反復復型フェーズ（ゴール指向） x 成果物駆動
x タイムボックス（リスク駆動）
• ユニファイド・プロセス（UP）
• 反復復型フェーズ（ゴール指向） x ジャストインタイム
x タイムボックス（価値・リスク駆動）
• ディシプリンド・アジャイル・デリバリー（DAD）
7

8. 「反復復型」フェーズ
• 要求の実装完了了が、フェーズの完了了基準
• 特徴
• 動作する機能が早期に利利⽤用できる
• 統合とテストの負担が⼤大きい
要求 分析 設計 実装
テス
ト
要求 分析 設計 実装
テス
ト
要求 分析 設計 実装
テス
ト
要求 分析 設計 実装
テス
ト
要求 分析 設計 実装
テス
ト
プロジェクト開始
リリース
技術リスク・要求リスクへの
対処
要求 分析 設計 実装
テス
ト
要求 分析 設計 実装
テス
ト
要求 分析 設計 実装
テス
ト
要求 分析 設計 実装
テス
ト
要求 分析 設計 実装
テス
ト
プロジェクト開始 リリース
反復復型フェーズ⼯工程別フェーズ
8

9. ジャストインタイム（JIT）
• 作業の管理理を、テスト結果によって⾏行行う
• 中間成果物は「それが必要な場合に」作成する
要求 分析 実装 テスト
要求 分析 実装 テスト
要求 分析 テスト
設計
実装設計
設計
チェック
ポイント
要求 分析 設計 実装 テスト
チェック
ポイント
チェック
ポイント
チェック
ポイント
チェック
ポイント
チェック
ポイント
タスクそのものを「必要に応じて」実施
チェック
ポイント
チェック
ポイント
成果物駆動
JIT
9

10. 【参考】なぜエンタープライズで「JIT」が有効なのか
• テクノロジーの進化で、JITベース開発が現実的に
• システムのあり⽅方（主にUI）にコンセンサスが醸成されてきたこともあり、技術がシンプルに洗
練されてきた。（J2EE→Railsの流流れ）
• 技術が限定され、標準的な利利⽤用⽅方法で作成できる割合が増加。カスタムコンポーネントの減少。
（アーキテクチャ準拠、専⽤用設計の減少）
• さらに、OSSで提供されるモジュール、ライブラリの適⽤用範囲拡⼤大に伴い、記述コード量量の⼤大幅
な減少（同⼀一システムでコード量量が1/5程度度に）
• ドキュメントの主⽬目的の保守利利⽤用へのシフトと、DevOpsも含めた継続的システム修正への対応の
ため、「ドキュメント→作業」から「作成/修正→ドキュメント⽣生成」へ変化。
要求 分析 設計 実装 テスト
要求 分析 設計 実装 テスト
要求 分析 設計 テスト
※本資料料は株式会社ゼンアーキテクツによる調査と考察によるものです。
アーキテクチャ/
アーキテクチャドキュメント
「標準的」な作り⽅方の機能は
省省略略できる
フレームワーク/ライブラリ
モジュール
コーディングから「設定/宣⾔言」へ
実装⽅方法が変化
実装
10

11. 要件3要件2
要件1
タイムボックス（価値駆動・リスク駆動）
• プロジェクト開始時に、要件を価値/リスク基準で優先順位を設定。
• 期間 x リソースのタイムボックスに割り当てながら進める。
要件1
要件2
要求 分析 設計 実装 テスト
要求 実装 テスト
要件3
要件4
要件5
⾼高
優先順位
低
10⽉月/1W〜～2Wタイムボックス
テスト
10⽉月/3W〜～4Wタイムボックス
要件4 要件5 要件n
優先順位の⾼高い要件（バックログ）から、タイムボックスに割り当て
価値/リスクの変動
＝優先順位の⼊入れ替え
⼯工数⾒見見積もり≒ベロシティ
≒イテレーション
11
実装

12. アジャイル”型”で何が得られる？
12
得られるもの
1. 不不必要な作業の削減
• JITの効果
• ＝⽣生産性向上＝コスト最⼩小化（最適化）
2. リスクの減少
• 反復復型の効果
• リスクの早期識識別と早期（⼩小さいうちに）対処
• ＝再作業の削減 ＆ 我慢（＝ビジネス価値低下）の最⼩小化
• 再作業の原因（リスク）のほとんどは「要求」
• 「ほしいものはこれじゃない」
• 動くものを触ってもらう
• ITは、社会活動全体から⾒見見るとそこまで成熟していない
（モノを⾒見見るまで安⼼心できない）

13. 「エンタープライズ」のコンテキスト
13
• エンタープライズ開発 ≒ 業務システム開発
• 価値観の異異なる他の組織体と連携しながら進める開発
• 連携が避けられない、とも⾔言う
• 計画に基づく活動
• 事業から⾒見見るとマイルストーンが重要。⼈人、モノ、カネを動かすタイミング。予算、
期間、リソース制約も含む。
• 戦略略に則った選択
• 事業戦略略、技術戦略略、既存資産の利利⽤用（⼈人、設備、組織の経験）
• 利利害関係者との調整
• 複数のユーザー部⾨門、他のシステムの運⽤用・保守・開発チーム、システムオーナー部
⾨門⻑⾧長、役員
• コンプライアンスの遵守
• 業界の法律律・規制、組織の規則・ルール・標準
アジャイルであっても
避けられない

14. DADの⽬目的
14
• エンタープライズのコンテキストに、
アジャイルで得られた知⾒見見を適合させる
• それによって、こんなシステム開発を実現させたい。
• リスクをできるだけ少なく、
• ROI（作業効率率率・⽣生産性）を⾼高め、
• 計画に従い、
• 事業戦略略に沿った、
• 関係者皆に喜んでもらえるシステム
• Disciplined Agile Delivery
• ディシプリンド・アジャイル・デリバリー
• DAD（”ダッド”）と読みます

15. DADの特⾊色
15
• ゴールドリブン
• 反復復型フェーズにおけるマイルストーン
• ⼿手順よりもゴールを重視
• リリースライフサイクルを3Cリズムに拡張
• Coordinateとして「⽅方向付けフェーズ」を、
• Concludeとして「移⾏行行フェーズ」を追加
• プロセスディシジョンフレームワーク
• 作業や成果物を厳密に規定しない
• プラクティスとして過去のソフトウェアエンジニアリングの成果を活⽤用しよう。
• アジャイルプラクティスだけで進める必要はない

16. DADの基本的な進め⽅方
引⽤用：ディシプリンド・アジャイル・デリバリー(2013/翔泳社) 16

17. 【参考】スクラムの基本的な進め⽅方
17

18. DADの3Cリズム
Conclude
インクリメントの
コミット
Collabolate
1⽇日の作業
Coordinate
⽇日次調整
ミーティング
デイリーリズム
Conclude
完了了、
イテレーションレビュー、
ふりかえり
Collabolate
イテレーション
Coordinate
イテレーション
計画セッション
イテレーションリズム
Conclude
ソリューションのデプロイ、
運⽤用開始、
拡張要求のフィードバック、
利利害関係者の喜ぶ顔
Collabolate
構築フェーズ
Coordinate
⽅方向付けフェーズ
リリースリズム
18
+

19. DADの「ゴール」
⽅方向付けフェーズのゴール
-‐‑‒初期チームの編成
-‐‑‒プロジェクトのビジョンを特定
-‐‑‒利利害関係者のビジョンへの合意
を取り付ける
-‐‑‒企業の⽅方針に準ずる
-‐‑‒初期の技術戦略略、初期の要求、
初期のリリース計画を策定する
-‐‑‒作業環境をセットアップする
-‐‑‒予算確保
-‐‑‒リスクの特定
構築フェーズのゴール
-‐‑‒使⽤用可能なソリューションを構
築する
-‐‑‒利利害関係者のニーズの変化に応
える
-‐‑‒デプロイ可能なリリースへ近づ
ける
-‐‑‒現在の品質レベルを維持・向上
させる
-‐‑‒アーキテクチャーを早期に実証
する
移⾏行行フェーズのゴール
-‐‑‒ソリューションが運⽤用準備完了了
していることを確認する
-‐‑‒利利害関係者のソリューション受
⼊入準備が整っていることを確認
する
-‐‑‒ソリューションを運⽤用環境に載
せる
作業進⾏行行中のゴール
-‐‑‒プロジェクト⽬目標の達成 -‐‑‒チームのプロセスと環境を改善
-‐‑‒チーム・メンバーのスキル向上 -‐‑‒既存のインフラの活⽤用
-‐‑‒既存のインフラを拡張 -‐‑‒リスクに取り組む
引⽤用：ディシプリンド・アジャイル・デリバリー(2013/翔泳社) 19

20. ⽅方向付けフェーズ
• アジャイルとエンタープライズのギャップを埋める
• プロジェクト全体の「⾒見見通しを⽴立立てる」
• ⼤大まかなスコープ （＋要求リスク）
• アーキテクチャーの指針と実現性 （＋技術リスク）
• ⾒見見積もり基礎値 （＋スキルリスク）
• 計画と予算（幅を持たせて）
⽅方向付けフェーズのゴール
-‐‑‒初期チームの編成
-‐‑‒プロジェクトのビジョンを特定
-‐‑‒利利害関係者のビジョンへの合意を取り付ける
-‐‑‒企業の⽅方針に準ずる
-‐‑‒初期の技術戦略略、初期の要求、初期のリリース計画を策定する
-‐‑‒作業環境をセットアップする
-‐‑‒予算確保
-‐‑‒リスクの特定
20

21. 構築フェーズ
21
構築フェーズのゴール
-‐‑‒使⽤用可能なソリューションを構築する
-‐‑‒利利害関係者のニーズの変化に応える
-‐‑‒デプロイ可能なリリースへ近づける
-‐‑‒現在の品質レベルを維持・向上させる
-‐‑‒アーキテクチャーを早期に実証する
• 動作するシステムを作る
• イテレーション毎に内部リリース
• 継続的にフィードバックを得て調整を続ける
• プロダクトバックログ／イテレーションバックログ管理理

22. 移⾏行行フェーズ
22
• ユーザーの利利⽤用準備
• 計画駆動の作業が多くなる
• データ移⾏行行、ユーザー環境の更更新、トレーニングなど
• 並⾏行行運⽤用
• いわゆるUATの期間
• 継続的フィードバックは続ける
• リリース
• 継続的リリースを基本として考える
• フィードバックループを途切切れさせない。DevOps。
移⾏行行フェーズのゴール
-‐‑‒ソリューションが運⽤用準備完了了していることを確認する
-‐‑‒利利害関係者のソリューション受⼊入準備が整っていることを確認する
-‐‑‒ソリューションを運⽤用環境に載せる

23. プラクティスの活⽤用
• 既存のソフトウェアエンジニアリングの成果を活⽤用する
Waterfall
PMBOK
CMMI
ITIL
RUP
XP
SCRUM
Lean
BABOK
23

24. DADに息づくプラクティス
• スクラム
• プロダクトバックログ
• 価値駆動ライフサイクル
• デイリースクラム
• リリース計画
• スプリント計画
• ・・・
• エクストリームプログラミング（XP）
• コーディング規約
• 共同所有
• 継続的インテグレーション
• ・・・
• リーン
• OpenUP
• ・・・
7つのプロセス
60のプラクティス
24

25. DADに備えられている戦略略
• 要求モデリングの⼿手段
• ビジネスプロセス図
• ドメインモデル
• エピック
• 機能⼀一覧
• フローチャート
• マインドマップ
• UMLアクティビティ図
• ユースケース仕様書
• ユーザーストーリー
• バリュー・ストリーム・マップ
• ・・・
• プロジェクト予算確保戦略略
• ⾦金金額固定（範囲あり）
• ⾦金金額固定（範囲なし）
• 段階的予算確保
• タイム＆マテリアル
• ・・・
37の戦略略⽐比較表
195個の戦略略
引⽤用：ディシプリンド・アジャイル・デリバリー(2013/翔泳社)
25

26. プラクティスとしてのBABOK
26
• BABOK®はプラクティス
• いつ、何を実施すべきかまでは規定されていない
• ベースとなるプロセスがあることが前提
• 再利利⽤用可能で⼿手順化された⼀一連のアクティビティ
• 組織が採⽤用するアプローチ、ライフサイクルによって、
対応するBABOK®タスクは異異なる
引き出し 要求アナリシス
要求のマネジメントとコミュニケーション
3.1 3.2
3.3 3.4
4.1 4.2 4.3 4.4 4.5
6.1 6.2
6.4 6.5
6.3
6.6
3.2 6.2 6.5 6.3
4.1
BABOK プロセス
4.2
「International Institute of Business Analysis™」

27. BABOK適⽤用パターン1
27
• 計画駆動型プロセスへの適⽤用例例
業務プロセスの分析
ステークホルダーの
識識別
2.2
ステークホルダーの
分析を主導する
ステークホルダー
要求の引き出し
機能要求の定義
⾮非機能要求の定義
要求の評価 ベースラインの策定
機能仕様の定義
⼊入出⼒力力仕様の作成
5.4
ソリューションス
コープを定義する
4.1
ソリューションスコー
プと要求をマネジメン
トする
6.1
要求に優先順位
を付ける
6.1
要求の仕様化と
モデリングを⾏行行う
3.3
引き出しの結果を
⽂文書化する
3.2
引き出しのアクティ
ビティを主導する
6.2
要求を体系化する
6.5
要求を検証する
2.1
ビジネスアナリシスの
アプローチを計画する

28. BABOK適⽤用パターン2
28
• 価値駆動型プロセスへの適⽤用例例
フィードバック
リリース
イテレーション
変更更
イテレーション計画
6.1
要求に優先順位
を付ける
3.2
引き出しのアクティ
ビティを主導する
4.1
ソリューションスコー
プと要求をマネジメン
トする
3.2
引き出しのアクティ
ビティを主導する
5.4
ソリューションス
コープを定義する
テスト
6.5
要求を検証する
4.5
要求を伝達する

29. 5.4
ソリューションス
コープを定義する 4.1
ソリューションスコープと
要求をマネジメントする
6.3
要求の仕様化と
モデリングを⾏行行う
6.1
要求に優先順位
を付ける
3.2
引き出しのアクティ
ビティを主導する
2.2
ステークホルダーの
分析を主導する
2.1
ビジネスアナリシスの
アプローチを計画する
6.6
要求を
妥当性確認する
7.2
要求を割り当てる
7.5
ソリューションを
妥当性確認する
BABOK適⽤用パターン3
• DADへの適⽤用例例
29
3.3
引き出しの結果を
⽂文書化する
5.5
ビジネスケースを定
義する

30. 5.エンタープライズアナリシス
• ビジネスニーズを定義する
• 能⼒力力ギャップをアセスメントする
• ソリューションアプローチを決定する
• ソリューションスコープを定義する
• ビジネスケースを定義する
6. 要求アナリシス（継続的）
• 要求に優先順位をつける
• 要求を体系化化する
• 要求を仕様化しモデル化する
• 前提条件と制約条件を決める
• 要求を検証する
• 要求を妥当性確認する
7. ソリューションのアセスメント
と妥当性確認
• 提案ソリューションをアセスメントする
• 要求を割り当てる
• 組織の準備状況をアセスメントする
• 移⾏行行要求を定義する
• ソリューションを妥当性確認する
• ソリューションのパフォーマンスを評価する
4. 要求のマネジメントとコミュニケーション
• ソリューションスコープと要求をマネジメントする
• 要求のトレーサビリティをマネジメントする
• 再利利⽤用に備えて要求を保守する
• 要求パッケージを準備する
• 要求を伝達する
2.ビジネスアナリシスの
計画とモニタリング
• BAへのアプローチを計画する
• ステークホルダの分析を主導する
• BAのアクティビティを計画する
• 要求マネジメントプロセスを計画する
• BAのパフォーマンスを管理理する
6. 要求アナリシス（初期）
• 要求に優先順位をつける
• 要求を体系化化する
• 要求を仕様化しモデル化する
• 前提条件と制約条件を決める
• 要求を検証する
• 要求を妥当性確認する
3. 引き出し
DAD -‐‑‒ BABOKマッピング（例例）
30

31. BABOKのアジャイル適⽤用ポイント1
31
• BABOKのタスクは、進め⽅方が変わるだけ。
• 「しっかり1回」から「軽く何度度も」
• プロジェクト前半に集中していたタスクが、全体に分散する
6. 要求アナリシス（継続的）
7. ソリューションのアセスメント
と妥当性確認
4. 要求のマネジメントとコミュニケーション
（継続的）
6. 要求アナリシス（初期）
3. 引き出し（初期）
7. ソリューションのアセスメント
と妥当性確認（初期）
3. 引き出し（継続的）
4. 要求のマネジメントとコミュニケーション
（初期）

32. BABOKのアジャイル適⽤用ポイント2
32
6. 要求アナリシス（初期）
5.エンタープライズアナリシス
2.ビジネスアナリシスの
計画とモニタリング
• 構築イテレーションに⼊入る前に⾏行行うべきタスクを明⽰示
• 「2. 計画」「3. 引き出し」「5. エンタープライズアナリシス」
• 「⽅方向付けフェーズ」で実施する
5.4
ソリューションス
コープを定義する
6.1
要求に優先順位
を付ける
3.2
引き出しのアクティ
ビティを主導する2.2
ステークホルダーの
分析を主導する
2.1
ビジネスアナリシスの
アプローチを計画する
5.5
ビジネスケースを定
義する
3. 引き出し

33. BABOKのアジャイル適⽤用ポイント3
33
6. 要求アナリシス（継続的）
3. 引き出し（継続的）
• 要求アナリシスは、継続的に⾏行行われる
• 要求の仕様化、要求の優先順位付けなどの要求アナリシスのタスクは、各イテレー
ションで継続的に実施する
6.3
要求の仕様化と
モデリングを⾏行行う
3.3
引き出しの結果を
⽂文書化する

34. BABOKのアジャイル適⽤用ポイント4
34
4. 要求のマネジメントとコミュニケーション
（継続的）
• 要求管理理は、プロセスに組み込まれる
• 「プロダクトバックログ」、「イテレーションバックログ」、
「ワークアイテムスタック/プール」
• アジャイル＝要求ライフサイクルプロセスと⾔言える。別途準備する必要はない
• チケット管理理システム等のツール利利⽤用を推奨
4.1
ソリューションスコープと
要求をマネジメントする

35. BABOKのアジャイル適⽤用ポイント5
35
7. ソリューションのアセスメント
と妥当性確認
• 妥当性確認は「動作するシステム」で⾏行行う
• イテレーション毎に回帰的に妥当性が確認される
• ⾃自動テスト環境を推奨
• 移⾏行行フェーズではリリース全体での妥当性確認を⾏行行う
6.6
要求を
妥当性確認する
7.5
ソリューションを
妥当性確認する

36. DADからみたBABOK
36
• BABOKはプラクティス集のひとつ
• DADからみれば、XPやScrumのプラクティスと同列列
• DAD書籍ではBABOKはマッピングされていないが、前
述の通り、フェーズやアクティビティ毎に拡張が可能
• DADは、“知識識体系”であるBABOK
の活⽤用を促すきっかけ
• BABOKではプロセスを規定していない
• DADは「プロセスディシジョンフレームワーク」

37. 【参考】DAD実践例例
37
• 投信Webサイト開発プロジェクト
• 開発: 株式会社ゼンアーキテクツ
• リリース: 2013年年2⽉月
• ユーザ: 約5,000⼈人
• プロジェクト期間: 約7ヶ⽉月
• プロセス: DAD
⽅方向付けフェーズ
• 2ヶ⽉月
• モックアップ作成を中⼼心に要求を定義
• 機能⼀一覧を全てチケット化
構築フェーズ
• 3ヶ⽉月
• 2W x 6回のイテレーション
• ATDDベースの内部リリース
移⾏行行フェーズ
• 1ヶ⽉月
• 本番環境でのテスト・チューニング
• データ移⾏行行
• パイロットユーザによる先⾏行行利利⽤用
主な利利⽤用ツール
プロジェクト管理理
• Redmine（要求管理理）
⾃自動ビルド + テスト
• TFS（⾃自動ビルド）
• Selenium（⾃自動テスト）
要件定義
• Enterprise Architect（モデリング）
• Twitter Bootstrap（モックアップ）
主な利利⽤用テクノロジー
Webフレームワーク
• ASP.NET MVC4
• Kendo UI (HTML5 + jQuery)
クラウド基盤
• Windows Azure
• Redmine（インシデント管理理）
• TFS（リリース管理理）

38. • DAD公式書籍
– 「ディシプリンド・アジャイル・デリバリー
エンタープライズ・アジャイル実践ガイド」（翔泳社）
※電⼦子書籍もあります
• DAD関連サイト
– ⽇日本: http://disciplinedagiledelivery.jp/ （DAD⽇日本語版翻訳チーム）
– ⽶米国: http://disciplinedagiledelivery.com/ （DAD著者）
• DAD関連イベント
– 10/28 IBM Innovate 2013 B-‐‑‒1セッション（IBM 和⽥田 洋 さん）
• DAD等のアジャイル開発プロセス導⼊入⽀支援サービス
– 「ソフトウェアプロセスエンジニアリング⽀支援サービス」
（株式会社ゼンアーキテクツ）
http://zenarchitects.co.jp/process/