イノベーションスプリント2011 nttデータにおける制約理論を活用した分散アジャイル開発～アジャイルとtocの融合

NTTデータにおける制約理論を活用した分散アジャイル開発
～アジャイルとTOCの融合～

2011年1月13日
株式会社ＮＴＴデータ
Copyright © 2011 NTT DATA CORPORATION 技術開発本部柴山洋徳

ＩＮＤＥＸ

1. なぜ分散アジャイル？
2. 事例プロジェクト概要
3. 分散アジャイル開発プロセス概要
4. 分散アジャイル開発プロセス詳細
5. 分散アジャイル開発プロセス適用の結果
6. 今後の挑戦

Copyright © 2011 NTT DATA CORPORATION 1

1. なぜ分散アジャイル？


Keep：アジャイルによる短期開発

 近年の短期開発ニーズの増加
⇒ 開発期間短縮により，お客様へ「ビジネス変化への対応力」という価値を提供
NTTデータ短期開発案件（新規、更改）の件数の変化
（案件数指標）～２００５年度の案件数を１００とした場合の比率の変化～約２．５倍
300 の増加
250
200 開発期間
150 ６～１２カ月
100 ～６カ月
50
0
2005 2006 2007 2008 2009 （年度）
（NTTデータ社内調査より）

短期開発へのNTTデータの取り組み
～アジャイル開発はその一実現手法～

Problem：グローバルリソースの活用

 NTTデータグループにおけるグローバル規模での体制整備
⇒ グローバルリソース活用により，お客様へ「最高のサービス」という価値を提供

30countries 128cities 20,134members

Europe North America
46 cities 49 cities
3600 members 6200 members
Asia Pacific
33 cities
11300 members
９０００ members
in India
２０１１．１．１時点

グローバルリソース活用へのNTTデータの取り組み
～分散開発はその一実現手法～

Try：分散開発＋アジャイル開発

 徹底した顧客指向の追求を目指して

アジャイル
＋分散開発
開発


２．事例プロジェクト概要


事例システム概要

● 業務：
プロジェクトマネジメントシステム（社内システム）

● 技術：
Ｃ＃，.NET，Microsoft Project， Microsoft Project Server

● アーキテクチャ
Webシステム

● 規模
100K Step

● 特徴
・ Microsoft Project，Microsoft Project Server上のアドオンソフトウェア
・ベースとなるMicrosoft製品の機能はブラックボックス


事例プロジェクト概要

 日本拠点（NTTデータ）とインド拠点（VERTEX）の分散拠点
・日本とインドの各開発チームの役割はほぼ同一
・要求・仕様の決定は日本拠点

●Tokyo Japan

Pune India ●

開発メンバ：8名

開発メンバ：14名


事例プロジェクト体制

 プロジェクトマネジメントコミッティ（PMC）を設置
・日本・インド開発チームのコミュニケーションを円滑にするためのヴァーチャルチーム
・重要な意思決定要素（プロセス構築，リリース計画策定etc）はPMCで決定
日本（NTTデータ) インド（VERTEX)

私はここ！ Product Owner Delivery Manager

PMC
SCRUM Master SCRUM Master

QA Team QA Team
3名 4名

GUI Team GUI Team
2名３名

Dev Team Dev Team
2名５名


３．分散アジャイル開発プロセス概要


分散アジャイル開発プロセスのオーバービュー

 スプリント：スケジュールの最小単位 (本プロジェクトでは4週間単位)
 スプリントの単位で定義された小機能（フィーチャ）の開発を複数完了
 QAチームがスプリントにより開発されたフィーチャのテストをスプリント終了後に実施
 リリース：複数のスプリントにより構成する単位(本プロジェクトでは2～3スプリント単位)
 リリースの単位で，ユーザ要求視点での大機能（Requirement Sub Group）の開発を完了
 QAチームはリリースの単位でテストを行い，Quality Gateをパスしたらリリース

リリースイテレーション
アーキテクチャ確立
スプリントイテレーション
要スプリント開発
概要要件
件（India）テシ
定義シスス
要ス定スプリント開発トテ Quality
(リリース
計画) 件
ウォーター
フォール
テ
ム
義（Japan）
ム
Release
Buffer
Gate ×3
定テ要スプリント開発
義
開発
ス件（India）テシ
トスス
定スプリント開発トテ
ム
義（Japan）


スプリント内のオーバービュー

 スプリント内開発の特徴
 依存関係の強いフィーチャをまとめたグループ（セル）単位で五月雨式に開発
 各分散拠点は，要件定義後からは結合テストまでは独立並行に開発
セル単位で五月雨開発スプリント
セル
GUI開発フィーチャ機能実装結合テスト
フィーチャA
GUI 仕様内部コーディン
フィーチャB デモテスト準備
開発作成設計グ
JAPAN
セル
インタフェース設計フィーチャ結合テスト
フィーチャC シ
DB I/F テスト
要 CI ス
フィーチャD 設計設計準備テ
件インテグレーム
定セルションテ
義ス
GUI開発フィーチャ機能実装ト
フィーチャE
GUI 仕様内部コーディン
フィーチャF デモ
開発作成設計グ
INDIA
セル結合テスト
フィーチャG
DB I/F テスト
CI
フィーチャH 設計設計準備

分散アジャイル開発プロセスのコンセプト

 コンセプトの特徴
 アジャイル開発コンセプトGDD（GUI Driven Development），分散開発コンセプトDD
（Distributed Development）にTOC（Theory of Constraints：制約理論）を融合したもの

Management As a Service

GDD DD TOC
Inter-
Just Release Quality
SCRUM FDD communi ACM JIT
Enough Buffer Gate
cation

GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development
ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time




GDD DD TOC
アジャイル開発
＝短期開発 Inter-
Enough Buffer Gate
cation





GDD DD
分散開発
TOC
＝グローバル
Exchan-
SCRUM FDD
Just リソース活用
ge
ACM JIT
Release Quality
Enough Communi Buffer Gate
cation





GDD DD TOC
科学的マネジメント
Inter-
＝効率と品質の追求
Enough Buffer Gate
cation


４．分散アジャイル開発プロセス詳細


分散アジャイル開発プロセスのコンセプト～GDD

 分散アジャイル開発プロセスの「アジャイル面」において中心となるコンセプト
 SCRUMの短期タイムボックスマネジメントによって過剰スコープ実現のムリを抑制
 FDDによる小機能単位開発により作業量，変更量のムラを低減
 GUIベースの開発により仕様検討・ドキュメント作成のムダを排除


GDD DD TOC
Inter-
Enough Buffer Gate
cation


分散アジャイル開発プロセスのコンセプト～SCRUM



GDD DD TOC
Inter-
Enough Buffer Gate
cation



 Time-box Management
 1スプリント＝4W
 要件変更・仕様変更は一切禁止
 全権限を開発チームに委任．自律性を重視した自由な開発
 遅延への対策はスコープ調整

スプリント１
GUI開発フィーチャ機能実装

スプリント
要件定義
結合テスト


スプリント2 スプリント3

【ワンポイント】要求変更，仕様変更は丌可避なものと考える．
変更は開発作業を止めると同時に，開発者のモチベーション（生産性）を下げる．


 Onsite Customer Meeting
 顧客が開発メンバーの一員となって，開発メンバーとのやり取りをする仕組み
 3つのMeeting，WebEXとメーリングリスト

• 要件定義フェーズにて要求内容の共有と仕様の確認を行う定期ミーティング（週2回）
要件定義ミーティング • インドVertex社にてスプリント内の最終的な仕様確定を行う（リリース直前スプリント）

• インドVertex社にてアジャイル開発プロセスの振り返りを実施する
振り返りミーティング • 各スプリントの振り返り結果で次スプリントの開発プロセス是正する

アプリケーション • 各スプリント実施中のアプリケーションをWebEXを利用し直接操作して確認
デモミーティング • 直接操作したアプリケーションを元に具体的な要求を次スプリントへ上げる

Customer • 丌明確な要求や仕様の問い合わせで開発が止まらないためのツール
メーリングリスト • 基本はワンデーレスポンス

【ワンポイント】スプリント外で密なコミュニケーションを図る．
スプリント内ではできる限りコミュニケーションを発生させず，開発に集中する．

分散アジャイル開発プロセスのコンセプト～ＦＤＤ



GDD DD TOC
Inter-
Enough Buffer Gate
cation


分散アジャイル開発プロセスのコンセプト～FDD

 Small-size Lot Production（小ロット開発）
 バッチ型開発から小ロット開発へ
 フィーチャの依存性を考慮してグループ化したセル単位をロットサイズとして開発

サブプロジェクト作成
プロジェクト作成
運用管理・・・・・・

タスク一覧表示
タスク報告進捗情報提出フィーチャ
・・・
プロジェクト管理進捗管理
タスク承認・・・
・・・
階層作成
セル
チーム作成リソース定義
チーム管理
要求・・・・・・
・・・
グループ要求サブ
グループ
【ワンポイント】 FDD（フィーチャ駆動開発）では，開発を一貫してフィーチャで管理を行う．
影響分析とバージョン管理，仕様管理が重要．

分散アジャイル開発プロセスのコンセプト～ＪｕｓｔＥｎｏｕｇｈ



GDD DD TOC
Inter-
Enough Buffer Gate
cation


分散アジャイル開発プロセスのコンセプト～Just Enough

 Just Enough Documentation
 GUI（画面）については全く設計書は作成しない
 80%ルール（正常系は固まった，など）による，仕様意思決定スピードの高速化
 要件定義フェーズで決まりきらなかった要求は，次スプリントへフォワード

要件定義スプリント
開発画面プロトを
実装に利用
Product
Owner
GUI GUIプロト
GUI開発
Team 開発

QA ワークフロー GUI ワークフロースプリント
要求
Team 作成
デモ修正計画
共有 (正常系) (異常系）
会議要件定義の主要成果物
Dev は，議事録と画面プロトタ
Team イプ．

【ワンポイント】 Just Enoughとは，できる限り設計書を読まなくてもよい状態.
コードを綺麗に維持するためのコーディング規約を重視．

分散アジャイル開発プロセスのコンセプト～DD

 分散アジャイル開発プロセスの「分散面」において中心となるコンセプト
 アジャイル開発をスケールする可能性が広がる一方で，純粋なアジャイル開発よりも効率面で务る
 時差の壁が大きい分散開発では，非同期化によりコミュニケーションを最小化，効率ロスを少なくする


GDD DD TOC
Inter-
Enough Buffer Gate
cation


分散アジャイル開発プロセスのコンセプト～Exchange Communication



GDD DD TOC
Inter-
Enough Buffer Gate
cation


分散アジャイル開発プロセスのコンセプト～Inter-communication

 Cross Estimation & Review & Testing
 分散開発拠点間のコミュニケーション齟齬の早期発見と品質向上
 お互いの成果物に対して，相互見積り，相互レビュー，相互テスト

要件定義スプリント開発

JAPAN INDIA
JAPAN INDIA
JAPAN GUIプロト各種スプリントスプリント
フィーチャフィーチャレビュー
開発設計結合結合
Cross 見積見積
テストテスト
GUI
レビュー
(Demo) INDIA JAPAN
各種スプリントスプリント
GUIプロト INDIA JAPAN レビュー結合結合
INDIA 設計
開発フィーチャフィーチャテストテスト
見積見積

【ワンポイント】 Cross Testingでは，結合テストにおいて，
自開発拠点のモジュールが問題ないことを相手開発拠点フィーチャの視点で確認する．

分散アジャイル開発プロセスのコンセプト～ＡＣＭ



GDD DD TOC
Inter-
Enough Buffer Gate
cation


分散アジャイル開発プロセスのコンセプト～ACM

 Code Ownership Mode / Code Sharing Mode
 開発を止めないための仕組み
 スプリント期間中＝コード占有型 ⇔ スプリント完了後＝コード共有型
 自拠点開発フィーチャに関係するコードを所有
 フィーチャ（コード）の品質保証責任の明確化

要件定義スプリント開発要件定義
（Code Sharing Mode）（Code Ownership Mode）（Code Sharing Mode）

Code Continuous Code
JAPAN Base Integration Base
Next Sprint
Code Continuous Code
Code
Base Integration Base
Base

Continuous Integration
INDIA Code Code
Base Integration Base

【ワンポイント】楽観モデルに基づき，スプリント開始後はあまりインタフェース変更は起らない，
最終的にインテグレーション時にコンフリクトはあまり発生しないと考える．

分散アジャイル開発プロセスのコンセプト～ACM

 Publish/Subscribe Change Request
 インタフェース所有者を事前に決定
 インタフェースの変更は所有者のみ
 影響範囲の責任は，影響関係者が負うことで負荷分散

PROJECTにデータAを
事前にインタフェースの所有者（Publisher）を定義追加変更なう
A-san
し，影響するクラス所有者は，Subscribeを行う．

Publisher Subscriber
Model
Owner A-san B-san Mr.C Ms.D
Database Schema
PROJECT A-san ○ ○
PROJECT_TASK A-san ○ ○
TASK
TASK_DETAIL
A-san
B-san ○
○
Twitter !
TEMPLATE Ms.D ○
TEMPLATE_TASK Ms.D ○
Web Service
ProjectManagementService Mr.C ○ ○ ○
TaskManagementService Mr.C ○
TemplateManagementService A-san ○ ○ Mr.C B-san

【ワンポイント】基本はスプリント開始後のインタフェース変更はNG．
インタフェース変更が必要な改修はバックログへフィードフォワードする．

分散アジャイル開発プロセスのコンセプト～TOC

 分散アジャイル開発プロセスの「効率追求面」において中心となるコンセプト
 アジャイル開発のプラクティスにTOCの理論をエッセンスとして加えることで，科学的なマネジメントを可
能とし，生産性向上を追求する


GDD DD TOC
Inter-
Enough Buffer Gate
cation


分散アジャイル開発プロセスのコンセプト～ＪＩＴ



GDD DD TOC
Inter-
Enough Buffer Gate
cation


分散アジャイル開発プロセスのコンセプト～JIT

 Just-In-Time Resource Management
 ソフトウェア開発の効率低下の最大の原因は，リソースネック
 開発プロセスの同期性（プロセス停止期間）排除とリソース稼働効率最大化
 ボトルネック工程とボトルネックリソースを可視化

設計設計
設計
プール

設計レビュー設計レビュー
設計レビュー済み
プール
後作業の作業待ち（滞留作業）をモニタリング

コーディング

【ワンポイント】プロセスの流れをスムーズにすることを重視．
マルチプロセスを可能とするリソースで「助け合い」，生産量の変動に対応する．

分散アジャイル開発プロセスのコンセプト～ＲｅｌｅａｓｅＢｕｆｆｅｒ



GDD DD TOC
Inter-
Enough Buffer Gate
cation


分散アジャイル開発プロセスのコンセプト～Release Buffer

 Release Buffer Scope Management
 リリース前にリリースバッファを設置
 サスペンドした作業をバッファ消費に換算
 リリースバッファの消費量をモニタリング
リリースイテレーション
Release Buffer
スプリント１スプリント2 スプリント3

F1 OK
F2 OK
F3 OK F8 Buffer Consumption
F4 Suspend F5 Buffer Consumption
F5 Suspend
New F8 F4 Buffer Consumption

Case: Release Buffer is Yellow
Stack to the next or onward Sprint
Case: Release Buffer is Red
Back to the current Sprint
or Product Back Log Product Case: Release Buffer is Green
Back Log Stack to Release Buffer
【ワンポイント】各スプリントスコープ値はチャレンジ目標で設定．
（チャレンジ：五分五分の可能性で達成できる範囲）

分散アジャイル開発プロセスのコンセプト～ＱｕａｌｉｔｙＧａｔｅ



GDD DD TOC
Inter-
Enough Buffer Gate
cation


分散アジャイル開発プロセスのコンセプト～Quality Gate

 Quality Gate
 品質管理活動の開発プロセスへの組み込み
 品質実測データ分析に基づくチェック観点を重視
リリースイテレーション全てのレベル１バグのFIX
スプリントイテレーション
要件スプリントシステムテストカバレッジチェック
Quality
定義開発テスト Release Gate
要件スプリントシステム Buffer パフォーマンスチェック
定義開発テスト
運用性チェック
フィーチャA 品質実測データ
フィーチャA 品質実測データ品質データ分析からの類似派生
故フィーチャA 品質実測データチェック
障故故
密障障・
・
度密密・
度
テ度スプリント実施回/リリース試験回
ステスプリント実施回/リリース試験回
テスプリント実施回/リリース試験回
トスス
※ バグを3段階に分類して管理
密トト
密レベル１バグ：仕様とソフトウェアとのギャップ
度密スプリント実施回/リリース試験回
度レベル２バグ：仕様のバグ
度スプリント実施回/リリース試験回
スプリント実施回/リリース試験回レベル３バグ：最新ユーザ要求とソフトウェアとのギャップ

【ワンポイント】設計作業の品質評価はあまり重視しない．
テストにおける検証項目の網羅性と検証結果による評価が重要．

分散アジャイル開発プロセスのコンセプト～Management As a Service

 分散アジャイル開発プロセスの「プロジェクトマネジメント」において中心となるコンセプト
 「管理（プロジェクトマネジメント）」から「サポート」へ
 「後だし（フィードバック）」ではなく，「段取り（フィードフォワード）」へ


GDD DD TOC
Inter-
Enough Buffer Gate
cation



 Management As a Service
 「管理（プロジェクトマネジメント）」から「サポート」へ
 「後だし（フィードバック）」ではなく，「段取り（フィードフォワード）」へ
 外部のノイズから開発チームを守る

あれもやって！
これも変更して！
スプリント
GUI開発フィーチャ機能実装
顧客スプリント
段取り
結合テスト
SCRUM Master

今どうなってるんだ？開発チームメンバ
品質は大丈夫なのか？
経営層
上位マネージャ

【ワンポイント】開発プロセスと開発チームはアジャイル成功の重要な要素．
スプリント外における開発サポート活動もアジャイル成功の重要な要素．


 Progress Management
 開発チームへのマイクロマネジメントから脱却
 「要求実現量の変化予測（バーンダウンチャート）」によって「進捗状況」を透明化

【ワンポイント】進捗の透明化とはプロジェクト内の信頼関係を構築すること．


５．分散アジャイル開発プロセスの適用結果


分散アジャイル開発プロセスの適用効果

分散アジャイル開発プロセスの適用の結果は，以下の通り．

△  従来型開発手法と比較して，開発期間は同程度

○  従来型開発手法とほぼ同等の品質レベルを達成

○  当初計画以上の要求スコープカバー率を達成

○  エンドユーザ要望へのほぼ完全な対応を実現

◎  開発メンバーの社員満足度向上

◎  エンドユーザの満足度向上


６．今後の挑戦


今後のTRY！

 お客様案件への適用

 開発スピードアップ（開発期間短縮）

 分散開発拠点のスケールアップ（INDIA – CHINA – JAPAN ・・・）

 アジャイル開発プラクティスの定着化・横展開


Microsoft Projectおよび Microsoft Project Server は、米国 Microsoft CORPORATIONの米国およびその他の国における登録商標または商標です。
その他、記載されている会社名、商品名、サービス名等は、各社の商標または登録商標です。


イノベーションスプリント2011 nttデータにおける制約理論を活用した分散アジャイル開発～アジャイルとtocの融合

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (16)

En vedette

En vedette (20)

Similaire à イノベーションスプリント2011 nttデータにおける制約理論を活用した分散アジャイル開発～アジャイルとtocの融合

Similaire à イノベーションスプリント2011 nttデータにおける制約理論を活用した分散アジャイル開発～アジャイルとtocの融合 (20)

Dernier

Dernier (7)

イノベーションスプリント2011 nttデータにおける制約理論を活用した分散アジャイル開発～アジャイルとtocの融合