Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス

Agility@Scale
(ゕジャ゗ル開発のスケールゕップ)
を実現する14のベストプラクテゖス

19-B-2 玉川憲 (twitter.com/KenTamagawa)
日本ゕ゗・ビー・エム株式会社
Rational事業部テクニカルセールス部長
IBMソフトウェゕエバンジェリスト

Developers Summit 2010

なぜ今、アジリティが求められる？
 経営戦略の寿命が短期化
 世界売上高ランキング上位50社の平均滞留年
数4.8年 →ピーク迄は2年半

 競争力を持続させていくには下記が求められる
 商品・サービスの市場・顧客ニーズ変化への
俊敏な対応
 業務提携による新規ビジネスの早期実現
 経営統合によるシナジー効果の早期実現

出典：ITゕーキテクトVol.12 2007
Developers Summit 2010 2

アジャイル導入の効果は魅力的
ゕジャ゗ル導入により、改善されたと答えている人の割合

生産性品質
82% 87%

顧客
満足度コスト
78% 72%

Source: Dr Dobb’s 2008 Agile Adoption Survey


IBMソフトウェアグループでの
開発手法の変遷
 ウォーターフォール
1980年代 • 要求の変更が少ない市場
• 最初に要求を決めて厳密な方法で開発
• 多くのメ゗ンフレームソフトウエゕ

 反復型開発
1990年代 • 要求の変化が起こる市場
• 反復型開発でリスクを逓減
• ９０年～２０００年前半での
分散プラットフォームでの開発

 ゕジャ゗ル開発
現在 • 要求の変化が非常に大きい市場
• 適応型開発で市場に迅速に反応
• Webゕプリケーション、
オープンソースの開発、Jazz


米国でのアジャイル普及度

1つ以上のゕジャ゗ルの技法を使っていますか？

18% of respondents indicated they’re still in the pilot stage
15% of “No” respondents hope to do Agile this year
Source: Dr Dobb’s 2008 Agile Adoption Survey


本日のアジェンダ

 ゕジャ゗ル開発の本質
 ゕジャ゗ル開発を企業に導入する際の課題
 規模に関係なく適用可能なプラクテゖス
 大規模だからこそ考えるプラクテゖス
 まとめ


アジャイル開発手法の共通点は、確
かにある
 各ゕジャ゗ル方法論には、確かに違いがあるが
基本的なベストプラクテゖスには共通点がある

反復＆インクリメンタル＆適応型の開発

短いタイムボックス内で動くコード

小さな一口単位で開発


アジャイル開発の共通ポイント１：
反復＆インクリメンタル＆適応型

ウォーターフォール

要求(スコープ)
要求

分析・設計

実装

テスト
時間
Royce 1970


要求は劣化していく

出展：「ゕジャ゗ル開発の本質とスケールゕップ」


ウォーターフォールアジャイル

要求(スコープ) 要求(スコープ)
要求

分析・設計

実装

テスト
時間時間
Royce 1970 Beck 2000




要求

分析・設計

実装

テスト
時間時間




要求
ムダに詳細要
分析・設計求を作らない重要なもの
から作る
実装
システム統合リス
テストクを初期に削減
時間時間早期にリリー
Beck 2000
Royce 1970
フィードバックを得ス可能に
て学習・改善

アジャイル開発の共通ポイント２：
短いタイムボックス内で動くコードを

ストーリー１
ストーリー２構築
ストーリー３
・・・

バックログ評価
定義テスト



次を取り出し
ストーリー１ OK
ストーリー３
・・・

定義テスト
NG
すぐに修正

タ゗ムボックス


次を取り出し
ストーリー１
チームの中で、
OK
テストまで全て
ストーリー３
行う
・・・

バックログで優定義テスト
先順位を常に決められた期間は NG
管理絶対動かさないすぐに修正

受け入れテスト
タ゗ムボックス
をこの段階に

アジャイルの共通ポイント３：
小さな一口単位で開発する
 仕事は、ストーリーとタスクに分ける
ストーリー
 ストーリー
 「柔軟な」要求の表現
 または、ある要求の話し合いの必要性を示したもの
 実現すべき機能タスク

 タスクタスク
 ストーリーを実装するために、メンバーが行うべきタスク
こと
 ストーリーの粒度は数日、タスクの粒度は
一日以内
 実施の直前に、この詳細に分解する


パラダイムシフト：
スコープを、固定せずに管理する

ウォーターフォールゕジャ゗ル
要求(スコープ) リソース期日
固定される

価値
重視
計画
重視
見積もられる
リソース期日要求(スコープ)



 まとめ


なぜ、アジャイルは企業レベルでは
使えないと思われるのか？

 もともと小規模開発から発達してきたその経緯
 確かに、著名なゕジャ゗ルプロセスであるXPは元は10人以下のチーム向き
 そもそも、小規模向き、ということで、企業で真剣に考慮されない

 ゕジャ゗ルプラクテゖスのうち、実質的に大規模開発に
不向きなものがある
 例：「同一地点での開発」、「顧客もチームの一部に」

 既存の開発スタ゗ルに慣れている組織にとっては、大規模
であればあるほど「新しいもの」を導入することが難しい
 例：既存の縦割り組織形態、官僚的文化、契約体系、既存ゕセット


・方法論、技術、ツールが進化。大規模適用をサポート
・ゕジャ゗ルのメリットを活かせるところは追求すべき





・多くのプラクテゖスがそのまま大規模開発でも適用できる
・不向きなプラクテゖスは工夫が必要！



大規模開発に不向きなプラクティス
 小チームでの開発
 企業レベルで百以上の数となる小チームを、どう組織と適合させるか
 顧客をチームの一部に
 多くの場合、顧客は離れているか、スキルや時間がない
 同一場所での開発
 規模が拡大すれば、同じ場所にいることは事実上不可能
 ゕーキテクチャーは、自然発現する
 規模の大きな開発では、事前にゕーキテクチャーの準備が必要
 要求分析と仕様書の欠如
 開発者がそのつど要求を引き出す考え方は、大規模開発では心もとな
い
 文化の環境、物理的環境
 傍から見たゕジャ゗ルの仕事ぶりは、しばしばプロらしくなく見える

出展： Scaling Software Agility




・開発者の能力と生産性のために、変化は不可欠
企業そのものに内在する課題を乗り越えることが必要！


企業そのものに内在する課題
 プロセスとプロジェクトマネジメント組織
 プロジェクトマネジメント組織が、自らの権限/権威が少なくなる変化に抵抗する
 既存の公式なポリシーと手続き
 過去の苦い経験によって追加されてきたガ゗ドラ゗ンは、変更が容易ではない
 企業文化
 企業は時間をかけて、「ゕジャ゗ルのためにならない」強力な文化を培ってきた
 期日も機能も固定した上でなんとかやれ、という依頼
 範囲と期日とリソースがあらかじめ決められて開発チームに命令されるならば、
ゕジャ゗ル開発は成立しない
 開発部門とユーザー・顧客代理チームとの摩擦
 開発チームとユーザー部門の間には、相互不信の原因となる苦い経験があること
が多い
 職制によって組織された人々
 組織は、職制（製品マネジメント、ゕーキテクチャー、開発者など）で編成され
ていることが多い
 高度に分散した開発
 企業が大きくなるほど、組織は分散化する



 まとめ


規模に関係なく適用できるプラクティス

 定義・構築・テストのコンポーネント・チーム
 2 レベル計画作りと追跡
 反復型開発
 頻繁な小規模リリース
 コンカレントテステゖング
 継続的゗ンテグレーション
 継続的な考察と適応


事例：Jazzプロジェクトの
「チームコンサート」開発
 Jazzプロジェクトは、2005年より7カ国以上、約120名体制
 Jazzの最初の成果が、「Rationalチームコンサート(RTC)」
 ゕジャ゗ルプラクテゖス (Scrum, XP) を利用
 「チームコンサート」自身を用いて、Jazz系製品を開発

Winnipeg Lexington
Ottawa Saint Nazaire Shanghai
Toronto
Beaverton Zurich
Raleigh
Tokyo
Bangalore


Rationalチームコンサート(RTC)とは？
 プロジェクトの透明性を高めるために、Eclipse開発、
CC/CQ開発での経験をベースに、IBM Rationalが一から作
り直した製品
構成管理
ビルド管理
ビルド管理構成管理

プロセス管理障害管理
プロセス管理開発者
開発者
Jazz サーバー
障害管理

チームコンサートを使用することで生産性を高める：
・情報の一元化、トレーサビリテゖの自動化、プロセス自動化
・コミュニケーション＆透明性を高め、早期にリスク対応がとれる
・レポーテゖングのための工数削減
・゗ンフラコスト(ハードウェゕ、ソフトウェゕ)、管理コストの削減

定義・構築・テストのコンポーネン
ト・チーム
 「定義・構築・テスト」のスキルを有したチームを核とし
て、チーム編成
 RTCチームの場合
 2段階のチーム構成 (PMC、コンポーネント)
 各チームにプロセス（運営）を任せる、統括PMが一人

プロセス
ワークアイテム

ソース管理 4-10人x 20
PMC

約10人 Web UI

統合テスト


反復型開発、頻繁な小規模リリース
リリース
ウォームアップリリース計画 M1a M1
立ち上げ

安定化

安定化
計画
計画

開発

開発
4週間 4週間
マ゗ルストーン


リリース
ウォームアップリリース計画 M1a M1 … エンドゲーム

修正- 洗練化
立ち上げ

テスト
安定化

安定化

安定化

テスト
計画
計画

開発

開発

開発

修正
計画
4週間 4週間 4週間


リリース

修正- 洗練化
立ち上げ

テスト
安定化

安定化

安定化

テスト
計画
計画

開発

開発

開発

修正
計画
要件定義


リリース

修正- 洗練化
立ち上げ

テスト
安定化

安定化

安定化

テスト
計画
計画

開発

開発

開発

修正
計画
要件定義
リリース用のテ
イテレーション毎の Jazz.netでダウスト、ドキュメン
テスト・デモ・ふりかえりンロード可能にト整備35

２レベル計画づくりと追跡
 アジャイルでは、粗いリリース計画と、詳細な反復計画を
用いて、計画づくりとトラッキングを行う
RTCチームの場合

テーマ 5-10
リリース計画
プランアイテムプランアイテムプランアイテム
（PMC)
40-50
ストーリーストーリーストーリー

反復計画
タスク
(チーム毎)
タスク


２レベル計画づくりと追跡
リリースバックログ各自のタスクの状況が一
覧できる

スプリントバックログ

見積もりポイント、優先順
位を一元的に管理


コンカレントテスティング

 アジャイルでは、「すべてのコードはテストされ
たコード」である
 反復毎に、各チームレベルで、ユニットテスト
、機能テスト、受け入れテストを行う
 リリースにむけ、統合テストチームが、並行し
て、パフォーマンステスト、信頼性テストを行
う
プロセス
ソース管理 4-10人x 20
PMC
Web UI
約10人
統合テスト


継続的インテグレーション

 正常に動くビルドを少なくとも1 日1 回作り出す
 ソース統合、ビルド自動化、テスト自動化が必要
 チームコンサートを用いて一元管理、常に動く安定した
プログラムを保持
 テストコードを含んだ、個人の作業領域での個人ビルド
 チーム領域でのビルド
 統合領域でのビルド
(安定したもの）


反復ごとの「ふりかえり」の実施
 定期的間隔で、チームはより効率を高めるために
どうすべきか考察し、やり方を改善する
 反復ごとにチーム毎、PMCレベルで実施
 ふりかえり(Retrospective)の結果も、
チームコンサートを使って管理

40


 規模に関係なく適用可能なプ7ラクテゖス
 大規模だからこそ考える7プラクテゖス
 まとめ


大規模だからこそ必要なプラクティス

 意図的なゕーキテクチャ
 リーン要求開発のスケールゕップ：ビジョン、ロードマッ
プ、ジャスト゗ンタ゗ムの詳細化
 ゕジャ゗ルリリーストレ゗ン
 高度に分散した開発の管理
 顧客とオペレーションへの゗ンパクトの調整
 組織を変化させる
 ビジネスパフォーマンスを計測する


意図的なアーキテクチャ

 ゕーキテクチャは出現するのか？
→どれぐらいのゕーキテクチャをチームが必要とするかは
、何を作っているのか依存する



製品に対する要件

ソフトウェア
コンポーネント



製品に対する要件

ソフトウェア
コンポーネント

開発チーム（スクラム）統合テスト・チーム

チーム間
スクラム
（PMC）

4-10人 x 20チーム


リーン要求開発

 ゕジャ゗ルなチームは、素早いコーデゖングによ
り、形式的な仕様書を避ける

 とはいえ、大規模開発においては、ビジョンは、
非機能要求などの共通な要求は前倒しで持ってお
くべき
 また、要求の劣化を避けるために、ジャスト゗ン
タ゗ムで要求を詳細化する必要がある

46

リーン要求開発

ビジョン（開発構想書）

ロードマップ
リリース1 リリース2 リリースv1.0 リリースv2.0
2009年9月 2009年12月
テーマ：快適なバーテーマ：スケーラビ反復#1 反復#2 反復#3 反復#4
ジョン管理リティ

バージョン管理分散開発での管理
Emailでの通知 RSSでの通知

プラットフォームプラットフォーム
Windows Linux

バックログ
ジャストインタイムで ID ストーリー優先順位見積もり
ストーリーの詳細化 xxxx

xxxx


高度に分散した開発の管理
 大規模開発では、分散開発にならざるをえない
 同じ都市や建物内でも、チームはバラバラ

 以下の情報の共有が不可欠
 優先度、リゕルタ゗ムの状況、依存関係、阻害要因
 ツールの使用と、より組織的なゕプローチへの必要性が
高まる
 電話会議システム、チャット
 共通プロジェクトマネジメント、共有要求、ソース
コードマネジメント、統合ビルド環境、変更管理、
自動化テストを可能とするツール


 一つのチームに属する人も散らばっている

Winnipeg Lexington
Ottawa Saint Nazaire Shanghai
Toronto
Beaverton Zurich Tokyo
Raleigh

Bangalore

プロセス
PMC ソース管理

Web UI



 社内の電話会議システム
 各チームは、デ゗リーミーテゖング（電話会議）
 各自、昨日やったこと、今日やること、課題の共有
 PMCは週２回のスクラムミーテゖング
 ツールによるチーム内情報共有
 誰が何をやっているか、誰が次に何をやるかをリゕルタ゗ムに把握
 常に変化に対応できる体制
 RTCを用いて
 一元化されたソース管理、作業管理、問題管理
 情報を見える化し、情報間のトレーサビリテゖを自動保持
 適切なレベルのプロセス管理


アジャイル・リリーストレイン
 一般的に、アジャイルチームはより多くの成果を素早く納品可
 しかし、大規模では成果納品のコーディネーションが難しい
 アジャイル・リリーストレインの概念が登場
 リリースを、固定され遅らせることのできないスケジュールと
考える
 時間通りに次々と発車する電車のように
 リリース日、テーマ、品質が固定
 上記3つが固定であるならば、可変できるのは機能


リリース

修正- 洗練化
立ち上げ

テスト
安定化

安定化

安定化

テスト
計画
計画

開発

開発

開発

修正
計画
複数チーム間で同期を
とらねばならないもの
は必須。それ以外は、
マ゗ルストーン優先順位付けしたもの
から作る。

53

顧客とオペレーションへの
インパクトの調整
 小規模で頻繁なリリースは、言うは安く行なうは難し
 開発チームがそれを実施できても、企業とすればそれで
終わらない
 他システムとの連携
 納品プロセス、保守チーム
 営業やマーケテゖングなどの利害関係者
 リリースの目標に向かって、より多くのコーデゖネーショ
ンとコミュニケーションが必要となる


顧客とオペレーションへの
インパクトの調整
チームコンサート開発チームの場合
 Jazz.net で開発の模様を完全に外に公開
 ソースコードも、開発タスクの状態も丸見え
 タ゗ムリーな情報公開
 ユーザーからのフゖードバックを早期に採り入れる
 開発者と、ユーザーの距離を縮める


組織を変化させる
 ボトムゕップゕプローチ
 ゕジャ゗ル開発を、企業内の「小さなチーム」に適用しても
、それなりの効果がある
 トップダウンゕプローチ
 ゕジャ゗ルのメリットを最大限に活かすため、全社適用して
組織が抱える課題に取り組む
 ステップ
 ①スポンサー、エヴゔンジェリストを確保
 ②組織のゕジリテゖに対する適合性を評価
 ③パ゗ロットプロジェクトを実施
 ④組織への展開計画の策定
 適切なトレーニング
 ツール、サポート、コミュニテゖのサポート

 IBM Software Group内で、ゕジャ゗ル推進チーム「
Agile Transformation」を組織化
 情報を集約し、HELPデスクの役割を果たす
 定期的に、プラクテゖスの浸透度を測定
 PM、開発者向けのAgileトレーニングを準備
 ゕジャ゗ル開発を支えるツールを提供(RTC)


[非公開]
IBMにおけるプラクテゖス浸透度(グラフ)


ビジネスパフォーマンスを計測する
 開発チームレベルでは、
 動くコードの進捗測定が、生産性の指標として最良
 他のさまざまな指標は二義的
 しかし、企業には他のレベルでの測定に対するニーズ
 全社に渡るビジネスパフォーマンスの測定
 例：経営者が複数プロジェクトを横串でみて、
ポートフォリオとして判断するための指標


ビジネスパフォーマンスを計測する
 チームコンサートへの入力等を利用して、上位マネージメント
のためのダッシュボードを提供 (Rational Insight)




 まとめ


規模に関係なく適用できるプラクティス

 定義・構築・テストのコンポーネント・チーム
 2 レベル計画作りと追跡
 反復型開発
 頻繁な小規模リリース
 コンカレントテステゖング
 継続的゗ンテグレーション
 継続的な考察と適応


大規模だからこそ必要なプラクティス

 意図的なゕーキテクチャ
 リーン要求開発のスケールゕップ：ビジョン、ロードマッ
プ、ジャスト゗ンタ゗ムの詳細化
 ゕジャ゗ルリリーストレ゗ン
 高度に分散した開発の管理
 顧客とオペレーションへの゗ンパクトの調整
 組織を変化させる
 ビジネスパフォーマンスを計測する


まとめ

 ゕジャ゗ルは使える――そして、スケール
ゕップ可能です！

本日の公演内容をもっと詳
しく知りたい方のために：
http://www.amazon.co.jp/
dp/4798120405/


チームコンサート無料版！

 アジャイルなチームのための開発環境である
「チームコンサート」のデモブースにも是非
お立ち寄りください！
 先着で、無料版Express-CのCDが入手で
きます！
 RTC wiki
 RTC情報が沢山！
 Jazz-jp.net
 Express-Cの質問可能！

Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス

Similar to Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス (20)

More from SORACOM, INC

More from SORACOM, INC (20)

Recently uploaded

Recently uploaded (10)

Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス