1. www.takumi-businessplace.co.jp
アジャイルコンサルタントの秘密
匠Business Place 牛尾 剛
2010年10月30日＇土（
西日本だけにこっそり教える
The Secrets of Agile Consulting

2. www.takumi-businessplace.co.jp
本日の内容
 自己紹介
 アジャイルの概要
 アジャイルプロセス ベースライン ７つのポイント
 アジャイルの企業導入のポイント＇抜粋（
 E-Agility協議会

3. www.takumi-businessplace.co.jp
自己紹介
牛尾 剛 (Tsuyoshi Ushio)
株式会社匠Business Place チーフコンサルタント
合同会社シンプルアーキテクト 代表
要求開発アライアンス 執行委員
XPJUG関西 初期メンバー
NEC
豆蔵
匠BP
日本電気株式会社で十数年 アーキテクト、SE、PMとして勤務
アジャイル開発／オブジェクト指向の先進的事例を実施
社内コミュニティ eXtreme Ways立ち上げ/ XPJUG関西で活躍
さまざまなアジャイル開発を実践／成功
アジャイル王子等の伝説パフォーマンスを演じる
アジャイルをやるため、オブジェクト脳／ゲーム手法を開発
よりよい開発を求めて、超上流の方法論、要求開発を実施
オブジェクト指向／エンジニアリング／教育レクチャ／Scala
アジャイル導入を実施
会社を立ち上げ、萩本さん、細川さんと企業改革／要求開発／
アジャイルのコンサルタントとして活躍中
特に最近はアジャイルの企業導入にどっぷりと、、、
アジャイル
原理主義者
時代
超上流
エンジニアリング
時代
仕事のモチベーション
プロの仕事をしてお客様に喜んてもらいたい
牛尾さんでよかったわぁ〜と言われたい
現場で役に立ってナンボ／現場最強説論者
経営者の
都合を知った
時代
Twitter : @sandayuu

4. www.takumi-businessplace.co.jp
アジャイルの概要
開発プロセスのざっくりとした歴史と、アジャイル開発の概要について

5. www.takumi-businessplace.co.jp
開発プロセスの歴史
 いいソフトウェアを安く、速くつくるための方法は？
計画主導／先行型設計
カオス型／スクラップ＆ビルド
要求
設計
製造
テスト
ものづくり
納期
・計画は納期から逆算した
・とにかくプログラムをつくる
・プログラムはつくっては捨てる
・作業見込を細分化し見積り計画を立てる
・設計技法を用いてコードの前に設計実施
・製造は設計にしたがってコードを書く
単純作業
・試行錯誤はやりやすい
・低品質、生産性悪い、納期未定
・計画がなく行き当たりばったり
ソフトウェアエンジニアリング技法
・変更が無い場合に向いている
・ソフトウェア開発には向いていない
・計画通りいくことはほとんどない
プログラムを
動かして初めて問題
が発覚！プロジェクトマネジメント技法
最初から全てを予想できないし、変更も多い、動かしてみないとわからない
最初から
予見は難しい
計画立案

6. www.takumi-businessplace.co.jp
開発プロセスの歴史
 いいソフトウェアを安く、速くつくるための方法は？
適応型／進化型設計
・極めて短い時間で計画／実行／評価を実施
・開発中は、要求／設計／製造／テストを行き来する
・動くアプリケーションを短期に作り次の計画の参考にする ・ソフトウェア開発に向いている
・試行錯誤と、生産性／品質確保
の両立
・短期の確実な計画と計測
アジャイルは、適応型の開発プロセス
計画 受入開発 計画 受入開発 計画 開発 ・・・
反復１ 反復２ 反復３
要求
ソフトウェアエンジニアリング技法
進化型プロセスマネジメント技法
設計製造
テスト
進化型設計技法

7. www.takumi-businessplace.co.jp
アジャイル開発とは
 迅速かつ適応的にソフトウェア開発を行う軽量な開発手法の
総称
 次の価値を共有する
 プロセスやツールより、人と人同士の相互作用を重視する
 包括的なドキュメントより動作するアプリケーションを重視する
 契約上の交渉よりも顧客との協調を重視する
 計画に従うよりも変化に対応することを重視する
 代表的な開発手法
 eXtreme Programming
 Scrum
 FDD
 Crystal Family
 DSDM

8. www.takumi-businessplace.co.jp
変更に対するコストカーブ
 通常はフェーズが進むにつれ変更のコストは大きくなる
 先のフェーズでも変更のコストがあまりかからないように出来ないか？
コスト コスト
時間 時間
通常の開発方法 アジャイル開発フェーズが進むと
１つの変更のコスト
は急激に多くなる
先のフェーズでも
変更のコストを平準化
できないか？
エクストリーム・プログラミング入門より

9. www.takumi-businessplace.co.jp
アジャイル開発の実施イメージ
 1〜4週間毎に、動作するアプリケーションを作る
 1〜4週間毎に、計画／実施／評価し、改善する
スプリント #1 スプリント #2 スプリント #3 ・・・
1〜4週間程度
スプリント
計画
開発実施
レビュー
振り返り
初日 最終日
スプリントとは、チームが作業を実施する
一定の期間のこと
スプリントの間に、一定期間分の
計画-開発実施-評価＇レビュー、振り返り（
を繰り返す
スプリント毎に
動作するアプリケーション
が作成される
スプリント毎にメンバが
改善を実施する
スプリント毎に実施する
内容を決める
アジャイル開発の実施イメージ
リリース計画
Product
Owner
Team

10. www.takumi-businessplace.co.jp
アジャイルプロセス ベースライン
〜運営に失敗しないための７つのポイント〜
アジャイルプロセスを導入して、失敗しないための７つのポイント

11. www.takumi-businessplace.co.jp
アジャイル開発プロセス 運営の基本
 アジャイル開発をうまく運営するための７つの基本ポイント
スプリント #1 スプリント #2 スプリント #3
・・・
スプリント
計画
開発実施
レビュー
振り返り
リリース計画
1. 全体像の共有
2. ストーリ供給力
3. タイムボックス
4. 開発生産性の
向上
5. 変更の吸収
6. 早期の失敗
と改善
7. 見える化
Iteration
Overview

12. www.takumi-businessplace.co.jp
1. 全体像の共有
 プロジェクトの全体像が存在するか？
 プロジェクトの全体像が共有されているか？
リリース計画
どのスプリントで、いつ、ざっくりどういう
事をやるか？
マイルストンはいつ、どういうものが予定
されているか？
なぜ必要か？ チェックポイント
6/15 中間報告会 7/30 リリース
サブシステム
A
サブシステム
B
サブシステム
C
Sprint#1 Sprint#2 Sprint#3 Sprint#4 Sprint#5
スプリントをまたがるざっくりとした計画
チーム、マネージャ、利害関係者への道しるべ
チーム、マネージャ、利害関係者との情報共有
全体マネジメント＇ex.要員計画)に必要
細かすぎる計画を立てていないか？
計画は変更されることが前提か？
利害関係者が見て理解できるものか？
全体像がないと
無限開発になる
ことも、、、
重要度

13. www.takumi-businessplace.co.jp
1. 全体像の共有
 プロジェクトの目的やビジョンが共有されているか？
 プロジェクトのゴールは明確か？
なぜ必要か？ チェックポイント
チーム、マネージャ、利害関係者への道しるべ
ディスカッションや考えることのよりどころ
モチベーションアップに必須
目的、ビジョン、ゴールが明確か？
目的、ビジョン、ゴールが、共有されているか？
キックオフミーティングが実施されているか？
目的
見ている方向がバラバラ
何でこんな
ことやってるの？
目的の共有あり目的の共有なし
議論に
ならない
目的
目的がこうだから
こうしようよし、がんばろう
同じ方向を見ている
ビジョンは？
何を狙ってプロジェクトを
やっているか？
どうなってほしいか？
アジャイル導入目的は？
＇アジャイル導入が初めてのとき（
重要度

14. www.takumi-businessplace.co.jp
2. ストーリ供給／検証力
 スプリント計画で、スプリントで実施できるだけのストーリを出
せて、検証できる能力があるか？
なぜ必要か？ チェックポイント
スプリントが機能しなくなるから
ストーリ間の整合性確保にも時間がかかる
随時チームの質問対応やレビューも存在する
プロダクトオーナを支援する体制は十分か？
ストーリを出す人の時間は確保できているか？
ストーリを出すために事前準備は必要か？
スプリント #1 スプリント #2 スプリント #3 ・・・
スプリント #1
ストーリ検討
チーム
プロダクトオーナー
スプリント #2
ストーリ検討
スプリント #3
ストーリ検討
最後のスプリント
は基本変更なし
重要度
注：ストーリの検証のためには、受入テスト能力も重要です

15. www.takumi-businessplace.co.jp
３. タイムボックス
 タイムボックス期間中は、基本的にストーリの変更が無く、
外部からの妨害がはいらないか？
タイムボックス開発
スプリント
計画
開発実施
レビュー
振り返り
Sprint#1
なぜ必要か？ チェックポイント
変更を混乱せず、受け入れるため
現場が混乱して、生産性を低下させないため
開発リズムのキープと集中のため
開発実施の間は仕様変更を受け付けない
開発実施の間は、割り込み仕事を基本しない
開発実施の間は、体制変更をしない
タイムボックスは一定の時間の区切りのこと
スプリント
計画
開発実施
レビュー
振り返り
Sprint#2
Sprint#2以降の
ストーリ検討
変更 変更は次のスプリント
で対応する
この期間はスプリント
計画で決めた事のみ
実施する。基本的に変更しない
変更対応
次回の
計画に含める
スプリント単位で
変更する
重要度

16. www.takumi-businessplace.co.jp
3. タイムボックス＇適切な計画（
 タイムボックス期間のための、スプリントの計画はムダ、ムリ、
ムラはないか？
なぜ必要か？ チェックポイント
進捗管理の精度向上
開発効率の向上＇過度な労働は効率を下げる（
チームの見積り能力の向上
スプリントで実施できなかったストーリは多いか
恒常的な休出や残業はないか？
見積りを改善するために、振り返っているか？
チームがスプリントでこなせる程度の
ストーリが選択されている
チームが実施するストーリの量は、
前回のスプリントを参考に決める
見積りは一般的に、楽観的になりやすい
ので、実績値を用いると良い
スプリント #1 スプリント #2 スプリント #3
適切な計画
消化したストーリ実績
Story 見積
機能1 3
機能2 8
機能3 21
Story 見積
機能4 13
機能5 8
機能6 13
消化したストーリ実績
見積り32だけ
のStoryを選択
31 34
こなせる以上の計画や
余裕のありすぎる計画に
なっていないか？
重要度

17. www.takumi-businessplace.co.jp
3. タイムボックス＇一本化（
 タイムボックスで使われる、プロダクトバックログや、コードベー
スは、共有され、一本化されているか？
なぜ必要か？ チェックポイント
チームが混乱は、過負荷状況を隠蔽する
チーム内外が誰に相談したらいいのか丌明
チームが混乱せず、集中力を発揮するため
チームへのリクエストが一本化されているか？
バックログはチーム作業のすべてか？
リクエスト情報は、共有されているか？
一本化あり一本化なし
バックログ
リクエスト
別の作業リスト
別の指示
リクエスト
まずPOや、
プロデューサに相談
混乱が生じる 情報を一元化し、共有するのが大切
重要度

18. www.takumi-businessplace.co.jp
４. 開発生産性の向上
 ２週間のスプリントで成果を出すためにムダが排除されているか
 生産性が向上するようなプラクティスを実践しているか？
なぜ必要か？ チェックポイント
スプリントを機能させるため
プロジェクトの成功率の向上
生産性の向上
スプリントが機能しているか？
スプリント毎に成果＇ビルド（を出せているか？
リクエスト情報は、共有されているか？
開発生産性プラクティス
導入あり
開発生産性プラクティス
導入なし
スプリントが機能しない場合あり できるところから実施する
Sprint#1 Sprint#2 Sprint#3 ・・・
ドキュメントのムダ 小さいウォータフォールの実施
待ち時間のムダ
Sprint#1 Sprint#2 Sprint#3
２週間では
ムリ
ドキュメントの精査 ペアプログラミング
ペアプロは
特にお勧め
同じ場所での作業進化型設計
重要度
スキルを満たして
いないメンバ構成
プロ意識ある
チーム

19. www.takumi-businessplace.co.jp
５. 変更の吸収
 開発で必ず発生する変更に耐えられるメカニズムが存在するか？
重要度
なぜ必要か？ チェックポイント
スプリントを機能させるため
試行錯誤効率／プロジェクト成功率の向上
動くものを見ながら要件を決めるため
スプリントが機能しているか？
変更に耐えられそうか？
リクエスト情報は、共有されているか？
変更吸収プラクティス
導入あり
変更吸収プラクティス
導入なし
変更に耐えられず破綻する できるところから実施する
Sprint#1 Sprint#2 Sprint#3 ・・・
大量ドキュメント
Sprint#1 Sprint#2 Sprint#3
ドキュメントの精査 共同所有
継続的インテグレーションテスト駆動/オブジェクト指向コピー＆ペーストプログラミング
ドキュメントの修正が間に合わない
プログラムが変更に耐えられない
シンプルさ

20. www.takumi-businessplace.co.jp
６. 早期の失敗と改善
 失敗はあるものとして、吸収できるメカニズムが機能しているか？
 失敗するかもしれないことを早期に計画しているか？
なぜ必要か？ チェックポイント
プロジェクトの成功
失敗のリスクヘッジと改善
会社や文化に合わせたカスタマイズ
振り返りをしっかりしているか？
失敗しそうなものは早めに検証しているか？
動作するアプリケーションをつくっているか？
早期の失敗
アプローチ
失敗しない
アプローチ
失敗しない事を目指すと失敗する 失敗はあって当然、最後に成功させる
計画を立てて設計したら
失敗しないか？
教育や本で完全に理解できるか？自社に合うか？
あとは本当にやるだけ？
Sprint#1 Sprint#2 Sprint#3
早期に問題が
発覚すると対応できる
誤解やムダがあっても
振り返りで吸収できる
振り返りで会社の文化に
合わせることができる
振り返りで改善できる
重要度

21. www.takumi-businessplace.co.jp
７. 見える化
 チーム内／チーム外にチームの状況が見える化されているか？
 チームのやっていることが、伝わるべき人に伝わっているか？
なぜ必要か？ チェックポイント
情報の共有化
問題の早期発見、気づき
意思決定の材料＇トップマネジメント（
張り出されており、「見えてしまう」か？
相手に合わせた方法か？＇上位マネジメント等（
相手に伝わっているか？理解できているか？
進捗
課題
報告
ビジョン
目的
報告で忙殺される
ことは無いように
自動ビルドの報告
タスクカンバン、バーンダウン張出し
バックログ、速度チャート
体制
会議体
報告ルート
リリース計画／マイルストン チーム
マネジメント
PO
重要度

22. www.takumi-businessplace.co.jp
アジャイル開発 企業導入のポイント
アジャイル開発を成功裏に企業導入するためのポイント

23. www.takumi-businessplace.co.jp
代表的なアジャイル開発の比較
 XP(eXtreme Programming), Scrumの相違点の比較
 そしてそれに足りないもの
名称 導入に対する
考え方
なぜそういう
考え方か？
顧客役の
支援
チーム管理 経営管理 エンジニア
リング
XP まずプラク
ティスに
従ってみる
守破離
の考え
丌十分 丌十分 サポート
なし
TDD/リファ
クタリング
/CI等ある
が、基礎知
識は必要
Scrum 基本的な枠
組の提供。
チームが考
え自己組織
する
方法論は現
場に合わず
うまくいか
ないから
丌十分 自己管理 丌十分 サポートなし
＇XPのプラクティ
スの一部などを
推奨している（
アジャイル開発をうまくいかせるために、カバーされていない範囲に着目する

24. www.takumi-businessplace.co.jp
例えば、顧客を支援するものは？
アジャイルチーム
顧客 開発者
ワンチーム計画ゲーム全員同席
…など
企画立ち上げ／
企画の承認
課題分析
戦略／業務分析
利害関係者や
関連部署との調整
や合意形成
費用対効果の算出
ビジネス価値を出す
業務改革
意思決定権限獲徔
要求を決定する
：
「顧客」の役割を果たすことは大変である
テスト駆動開発
共同所有
継続的インテグレーション
シンプルな設計

25. www.takumi-businessplace.co.jp
顧客を支援するもの
アジャイルチーム
顧客 開発者
テスト駆動開発
共同所有
継続的インテグレーション
シンプルな設計
ワンチーム計画ゲーム全員同席
…など
「顧客」の役割に、要求開発と全体PMという武器を不える
プロジェクト定義書
コタツモデル
要求分析ツリー
ゴール記述書
…など全体PM

26. www.takumi-businessplace.co.jp
アジャイル開発 導入のポイント
アジャイル開発導入のポイントを３つの視点から整理します
今日は時間がないので、いくつか抜粋してご紹介いたします
心構え
導入手順
スキル
•アジャイル開発導入を企業に推進する人の心構え
•アジャイル開発を導入する手順とそのポイント
•アジャイル導入を推進するチームに必要なスキルセット
26

27. www.takumi-businessplace.co.jp
導入手順
 標準的なアジャイル開発の組織導入全体像
 今日は時間がないので、割愛します
準備／計画 実施 評価
アジャイル導入目的
戦略／ゴール／課題
利害関係者
現状調査／文化／ルール
FIT&GAP
導入スケジュール／企画
キックオフミーティング
教育／レクチャ
・オブジェクト指向
・Agile
・テスト駆動／進化型設計
・ペアプログラミング
・マネジメント
・BA
プラクティス実践
振り返り／改善
自ら考える
＇自己組織度／多能工度UP（
利害関係者調整／支援
人事評価／標準化支援
ドキュメント整備
アジャイル導入進捗状況
中間評価、最終評価
導入価値状況表
アジャイルを実施する以外の部分に注目！

28. www.takumi-businessplace.co.jp
アジャイル導入の成績表 (Agile Value Chart)
分類 想定効果 プラクティス 実現
期間
評価 コメント
管理力 全体計画に対する遅れの
早期発見
リリース計画
速度チャート
短期 実施ずみ。適切に実施されて
いる
スプリント内の正確な
進捗把握
カンバン
バーンダウンチャート
スプリント計画
短期 スプリント計画は実施されてい
るが、計画の精度がよくない
チーム生産性の可視化 見積り
ベロシティの測定
短期 見積り精度が十分でない
改善が必要
開発力 スプリントによる
開発生産性の向上
スプリント実施
スプリント計画
レビュー
短期 スプリントの実施により達成さ
れている
変化対応力の強化 継続インテグレーション
テスト駆動開発
スプリント実施
中期 テスト駆動開発のみ、十分着
手できていない。他は実施済
み
継続的な改善による
チーム力向上
振り返り 短期 振り返りが適切に実施されてい
る
人材力 徒弟制度による
スキル向上と知識共有
ペアプログラミング
共同所有
短期 ペアプログラミングは同じメン
バーばかりになっている
自己組織化チーム運営に
よる「自ら考えるチーム」の
実現
自己組織化の考え導入
権限委譲
長期 チーム内で理解が十分ではな
い。長期的に取り組む予定
多能工による要員アサイン
の柔軟化
多能工役割分担の導入 長期 ペアプログラミングでできる範
囲を拡大中

29. www.takumi-businessplace.co.jp
スキル
 アジャイル導入プロジェクトチームが備えていると望ましいスキル
技術力 マネジメント力 経営者対応力
コミュニケーション力
アジャイル
知識／経験
ソフトウェア
エンジニアリング プロジェクト管理
経営管理
上位マネジメント
報告／説明力／折衝力
プロジェクト
周辺整備
理解されるまえに
理解する
理解していただく
相手のLanguageを使う
翻訳家
一人で全領域をカバーするのは難しい。例えばPM+Agilerの組み合わせにする

30. www.takumi-businessplace.co.jp
アジャイル導入時の典型的な関係部門／利害関係者
ソフトウェア開発チーム
ユーザ部門
経営層
人事評価部門
標準化/品質管理部門
開発パートナー
ユーザ部門
ユーザ部門
マネジメント
マーケティング
顧客 開発
他開発チーム
HW/ネットワーク／展開
アジャイル導入推進グループ
オーバービュー意識

31. www.takumi-businessplace.co.jp
最適化症候群とその解決策
 コンサルタントの職業病
 最適化症候群＇それは最善の方法でやらないと（
 １０％の改善
 トレードオフ療法 G.M.Weinberg コンサルタントの秘密より
トレードオフ意識

32. www.takumi-businessplace.co.jp
ワンチーム
 チームと顧客はワンチーム
 マネージャも、経営者も、品質管理グループもワンチーム
 プロジェクトの成功を願う仲間
ワンチーム意識
顧客 チーム
経営者
マネージャ
人事
品質管理
その他
ワンチーム

33. www.takumi-businessplace.co.jp
大切なこと
 最後にみんなに伝えたいこと
相手を心から信頼する
相手を理解する
相手の興味のあることについて
相手のLanguageで語る
相手を心から信頼するために、相手にとっての「もっともな理由」を理解する
自分の心は相手には丸見えになっていることを理解する。相手を脅威と思っていないか？
人は、自分の興味あること以外に興味がない。あなたの興味のあることについて語ってないか？

34. www.takumi-businessplace.co.jp
E-AGILITY協議会
〜現場とユーザ企業をアジリティでつなぐコミュニティ〜

35. www.takumi-businessplace.co.jp
E-Agility協議会
 2010年11月19日＇金（設立セミナー

36. www.takumi-businessplace.co.jp
匠には誰もがなれるわけではない
匠を目指そうとするものだけに、その権利は与えられる