アジャイルツアー2010 アジャイルコンサルタントの秘密

www.takumi-businessplace.co.jp

アジャイルコンサルタントの秘密

匠Business Place 牛尾剛2010年10月30日＇土（

西日本だけにこっそり教える

The Secrets of Agile Consulting


本日の内容

自己紹介

アジャイルの概要

アジャイルプロセスベースライン７つのポイント

アジャイルの企業導入のポイント＇抜粋（

E-Agility協議会


自己紹介

牛尾剛 (Tsuyoshi Ushio)

株式会社匠Business Place チーフコンサルタント合同会社シンプルアーキテクト代表

要求開発アライアンス執行委員XPJUG関西初期メンバー

NEC

豆蔵

匠BP

日本電気株式会社で十数年アーキテクト、SE、PMとして勤務アジャイル開発／オブジェクト指向の先進的事例を実施社内コミュニティ eXtreme Ways立ち上げ/ XPJUG関西で活躍さまざまなアジャイル開発を実践／成功アジャイル王子等の伝説パフォーマンスを演じるアジャイルをやるため、オブジェクト脳／ゲーム手法を開発

よりよい開発を求めて、超上流の方法論、要求開発を実施オブジェクト指向／エンジニアリング／教育レクチャ／Scalaアジャイル導入を実施

会社を立ち上げ、萩本さん、細川さんと企業改革／要求開発／アジャイルのコンサルタントとして活躍中特に最近はアジャイルの企業導入にどっぷりと、、、

アジャイル原理主義者時代

超上流エンジニアリング

時代

仕事のモチベーション

プロの仕事をしてお客様に喜んてもらいたい牛尾さんでよかったわぁ〜と言われたい現場で役に立ってナンボ／現場最強説論者

経営者の都合を知った

時代

Twitter : @sandayuu


アジャイルの概要

開発プロセスのざっくりとした歴史と、アジャイル開発の概要について


開発プロセスの歴史

いいソフトウェアを安く、速くつくるための方法は？

計画主導／先行型設計

カオス型／スクラップ＆ビルド

要求

設計

製造

テスト

ものづくり

納期

・計画は納期から逆算した・とにかくプログラムをつくる・プログラムはつくっては捨てる

・作業見込を細分化し見積り計画を立てる・設計技法を用いてコードの前に設計実施・製造は設計にしたがってコードを書く単純作業

・試行錯誤はやりやすい

・低品質、生産性悪い、納期未定

・計画がなく行き当たりばったり

ソフトウェアエンジニアリング技法

・変更が無い場合に向いている

・ソフトウェア開発には向いていない

・計画通りいくことはほとんどない

プログラムを動かして初めて問題

が発覚！プロジェクトマネジメント技法

最初から全てを予想できないし、変更も多い、動かしてみないとわからない

最初から予見は難しい

計画立案


開発プロセスの歴史

いいソフトウェアを安く、速くつくるための方法は？

適応型／進化型設計

・極めて短い時間で計画／実行／評価を実施・開発中は、要求／設計／製造／テストを行き来する・動くアプリケーションを短期に作り次の計画の参考にする・ソフトウェア開発に向いている

・試行錯誤と、生産性／品質確保の両立

・短期の確実な計画と計測

アジャイルは、適応型の開発プロセス

計画受入開発計画受入開発計画開発・・・

反復１反復２反復３

要求

ソフトウェアエンジニアリング技法

進化型プロセスマネジメント技法設計製造

テスト

進化型設計技法


アジャイル開発とは

迅速かつ適応的にソフトウェア開発を行う軽量な開発手法の総称

次の価値を共有するプロセスやツールより、人と人同士の相互作用を重視する

包括的なドキュメントより動作するアプリケーションを重視する

契約上の交渉よりも顧客との協調を重視する

計画に従うよりも変化に対応することを重視する

代表的な開発手法 eXtreme Programming

Scrum

FDD

Crystal Family

DSDM


変更に対するコストカーブ

通常はフェーズが進むにつれ変更のコストは大きくなる

先のフェーズでも変更のコストがあまりかからないように出来ないか？

コストコスト

時間時間

通常の開発方法アジャイル開発フェーズが進むと１つの変更のコストは急激に多くなる

先のフェーズでも変更のコストを平準化

できないか？

エクストリーム・プログラミング入門より


アジャイル開発の実施イメージ

1〜4週間毎に、動作するアプリケーションを作る

1〜4週間毎に、計画／実施／評価し、改善する

スプリント #1 スプリント #2 スプリント #3 ・・・

1〜4週間程度

スプリント計画

開発実施

レビュー振り返り

初日最終日

スプリントとは、チームが作業を実施する一定の期間のこと

スプリントの間に、一定期間分の計画-開発実施-評価＇レビュー、振り返り（

を繰り返す

スプリント毎に動作するアプリケーション

が作成される

スプリント毎にメンバが改善を実施する

スプリント毎に実施する内容を決める

アジャイル開発の実施イメージ

リリース計画

ProductOwner

Team


アジャイルプロセスベースライン〜運営に失敗しないための７つのポイント〜

アジャイルプロセスを導入して、失敗しないための７つのポイント


アジャイル開発プロセス運営の基本

アジャイル開発をうまく運営するための７つの基本ポイント

スプリント #1 スプリント #2 スプリント #3・・・


開発実施

レビュー振り返り

リリース計画

1. 全体像の共有

2. ストーリ供給力

3. タイムボックス

4. 開発生産性の向上

5. 変更の吸収

6. 早期の失敗と改善

7. 見える化

Iteration

Overview



プロジェクトの全体像が存在するか？

プロジェクトの全体像が共有されているか？

リリース計画

どのスプリントで、いつ、ざっくりどういう事をやるか？

マイルストンはいつ、どういうものが予定されているか？

なぜ必要か？チェックポイント

6/15 中間報告会 7/30 リリース

サブシステムA

サブシステムB

サブシステムC

Sprint#1 Sprint#2 Sprint#3 Sprint#4 Sprint#5スプリントをまたがるざっくりとした計画

チーム、マネージャ、利害関係者への道しるべ

チーム、マネージャ、利害関係者との情報共有

全体マネジメント＇ex.要員計画)に必要

細かすぎる計画を立てていないか？

計画は変更されることが前提か？

利害関係者が見て理解できるものか？

全体像がないと無限開発になることも、、、

重要度



プロジェクトの目的やビジョンが共有されているか？

プロジェクトのゴールは明確か？


チーム、マネージャ、利害関係者への道しるべ

ディスカッションや考えることのよりどころ

モチベーションアップに必須

目的、ビジョン、ゴールが明確か？

目的、ビジョン、ゴールが、共有されているか？

キックオフミーティングが実施されているか？

目的

見ている方向がバラバラ

何でこんなことやってるの？

目的の共有あり目的の共有なし

議論にならない

目的

目的がこうだからこうしようよし、がんばろう

同じ方向を見ている

ビジョンは？

何を狙ってプロジェクトをやっているか？どうなってほしいか？

アジャイル導入目的は？＇アジャイル導入が初めてのとき（

重要度


2. ストーリ供給／検証力

スプリント計画で、スプリントで実施できるだけのストーリを出せて、検証できる能力があるか？


スプリントが機能しなくなるから

ストーリ間の整合性確保にも時間がかかる

随時チームの質問対応やレビューも存在する

プロダクトオーナを支援する体制は十分か？

ストーリを出す人の時間は確保できているか？

ストーリを出すために事前準備は必要か？

スプリント #1 スプリント #2 スプリント #3 ・・・

スプリント #1ストーリ検討

チーム

プロダクトオーナー



最後のスプリントは基本変更なし

重要度

注：ストーリの検証のためには、受入テスト能力も重要です


３. タイムボックス

タイムボックス期間中は、基本的にストーリの変更が無く、外部からの妨害がはいらないか？

タイムボックス開発


開発実施レビュー振り返り

Sprint#1


変更を混乱せず、受け入れるため

現場が混乱して、生産性を低下させないため

開発リズムのキープと集中のため

開発実施の間は仕様変更を受け付けない

開発実施の間は、割り込み仕事を基本しない

開発実施の間は、体制変更をしない

タイムボックスは一定の時間の区切りのこと


開発実施レビュー振り返り

Sprint#2

Sprint#2以降のストーリ検討

変更変更は次のスプリントで対応する

この期間はスプリント計画で決めた事のみ

実施する。基本的に変更しない

変更対応

次回の計画に含める

スプリント単位で変更する

重要度


3. タイムボックス＇適切な計画（

タイムボックス期間のための、スプリントの計画はムダ、ムリ、ムラはないか？


進捗管理の精度向上

開発効率の向上＇過度な労働は効率を下げる（

チームの見積り能力の向上

スプリントで実施できなかったストーリは多いか

恒常的な休出や残業はないか？

見積りを改善するために、振り返っているか？

チームがスプリントでこなせる程度のストーリが選択されている

チームが実施するストーリの量は、前回のスプリントを参考に決める

見積りは一般的に、楽観的になりやすいので、実績値を用いると良い

スプリント #1 スプリント #2 スプリント #3

適切な計画

消化したストーリ実績

Story 見積

機能1 3

機能2 8

機能3 21

Story 見積

機能4 13

機能5 8

機能6 13

消化したストーリ実績

見積り32だけのStoryを選択

31 34こなせる以上の計画や余裕のありすぎる計画になっていないか？

重要度


3. タイムボックス＇一本化（

タイムボックスで使われる、プロダクトバックログや、コードベースは、共有され、一本化されているか？


チームが混乱は、過負荷状況を隠蔽する

チーム内外が誰に相談したらいいのか丌明

チームが混乱せず、集中力を発揮するため

チームへのリクエストが一本化されているか？

バックログはチーム作業のすべてか？

リクエスト情報は、共有されているか？

一本化あり一本化なし

バックログ

リクエスト

別の作業リスト

別の指示

リクエスト

まずPOや、プロデューサに相談

混乱が生じる情報を一元化し、共有するのが大切

重要度


４. 開発生産性の向上

２週間のスプリントで成果を出すためにムダが排除されているか

生産性が向上するようなプラクティスを実践しているか？


スプリントを機能させるため

プロジェクトの成功率の向上

生産性の向上

スプリントが機能しているか？

スプリント毎に成果＇ビルド（を出せているか？


開発生産性プラクティス導入あり

開発生産性プラクティス導入なし

スプリントが機能しない場合ありできるところから実施する

Sprint#1 Sprint#2 Sprint#3 ・・・

ドキュメントのムダ小さいウォータフォールの実施

待ち時間のムダ

Sprint#1 Sprint#2 Sprint#3

２週間ではムリ

ドキュメントの精査ペアプログラミング

ペアプロは特にお勧め

同じ場所での作業進化型設計

重要度

スキルを満たしていないメンバ構成

プロ意識あるチーム


５. 変更の吸収

開発で必ず発生する変更に耐えられるメカニズムが存在するか？

重要度


スプリントを機能させるため

試行錯誤効率／プロジェクト成功率の向上

動くものを見ながら要件を決めるため

スプリントが機能しているか？

変更に耐えられそうか？


変更吸収プラクティス導入あり

変更吸収プラクティス導入なし

変更に耐えられず破綻するできるところから実施する

Sprint#1 Sprint#2 Sprint#3 ・・・

大量ドキュメント


ドキュメントの精査共同所有

継続的インテグレーションテスト駆動/オブジェクト指向コピー＆ペーストプログラミング

ドキュメントの修正が間に合わない

プログラムが変更に耐えられない

シンプルさ


６. 早期の失敗と改善

失敗はあるものとして、吸収できるメカニズムが機能しているか？

失敗するかもしれないことを早期に計画しているか？


プロジェクトの成功

失敗のリスクヘッジと改善

会社や文化に合わせたカスタマイズ

振り返りをしっかりしているか？

失敗しそうなものは早めに検証しているか？

動作するアプリケーションをつくっているか？

早期の失敗アプローチ

失敗しないアプローチ

失敗しない事を目指すと失敗する失敗はあって当然、最後に成功させる

計画を立てて設計したら失敗しないか？

教育や本で完全に理解できるか？自社に合うか？

あとは本当にやるだけ？


早期に問題が発覚すると対応できる

誤解やムダがあっても振り返りで吸収できる

振り返りで会社の文化に合わせることができる

振り返りで改善できる

重要度


７. 見える化

チーム内／チーム外にチームの状況が見える化されているか？

チームのやっていることが、伝わるべき人に伝わっているか？


情報の共有化

問題の早期発見、気づき

意思決定の材料＇トップマネジメント（

張り出されており、「見えてしまう」か？

相手に合わせた方法か？＇上位マネジメント等（

相手に伝わっているか？理解できているか？

進捗課題報告

ビジョン目的

報告で忙殺されることは無いように

自動ビルドの報告

タスクカンバン、バーンダウン張出し

バックログ、速度チャート

体制

会議体報告ルート

リリース計画／マイルストンチーム

マネジメント

PO

重要度


アジャイル開発企業導入のポイント

アジャイル開発を成功裏に企業導入するためのポイント


代表的なアジャイル開発の比較

XP(eXtreme Programming), Scrumの相違点の比較

そしてそれに足りないもの

名称導入に対する考え方

なぜそういう考え方か？

顧客役の支援

チーム管理経営管理エンジニアリング

XP まずプラクティスに従ってみる

守破離の考え

丌十分丌十分サポートなし

TDD/リファクタリング/CI等あるが、基礎知識は必要

Scrum 基本的な枠組の提供。チームが考え自己組織する

方法論は現場に合わずうまくいかないから

丌十分自己管理丌十分サポートなし＇XPのプラクティスの一部などを推奨している（

アジャイル開発をうまくいかせるために、カバーされていない範囲に着目する


例えば、顧客を支援するものは？

アジャイルチーム

顧客開発者

ワンチーム計画ゲーム全員同席

…など

企画立ち上げ／企画の承認課題分析

戦略／業務分析利害関係者や

関連部署との調整や合意形成

費用対効果の算出ビジネス価値を出す

業務改革意思決定権限獲徔要求を決定する

：

「顧客」の役割を果たすことは大変である

テスト駆動開発

共同所有

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

シンプルな設計


顧客を支援するもの

アジャイルチーム

顧客開発者

テスト駆動開発

共同所有

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

シンプルな設計

ワンチーム計画ゲーム全員同席

…など

「顧客」の役割に、要求開発と全体PMという武器を不える

プロジェクト定義書

コタツモデル

要求分析ツリー

ゴール記述書

…など全体PM


アジャイル開発導入のポイント

アジャイル開発導入のポイントを３つの視点から整理します

今日は時間がないので、いくつか抜粋してご紹介いたします

心構え

導入手順

スキル

•アジャイル開発導入を企業に推進する人の心構え

•アジャイル開発を導入する手順とそのポイント

•アジャイル導入を推進するチームに必要なスキルセット

26


導入手順

標準的なアジャイル開発の組織導入全体像

今日は時間がないので、割愛します

準備／計画実施評価

アジャイル導入目的戦略／ゴール／課題利害関係者現状調査／文化／ルールFIT&GAP導入スケジュール／企画キックオフミーティング

教育／レクチャ・オブジェクト指向・Agile・テスト駆動／進化型設計・ペアプログラミング・マネジメント・BA

プラクティス実践振り返り／改善自ら考える＇自己組織度／多能工度UP（

利害関係者調整／支援人事評価／標準化支援ドキュメント整備

アジャイル導入進捗状況中間評価、最終評価導入価値状況表

アジャイルを実施する以外の部分に注目！


アジャイル導入の成績表 (Agile Value Chart)分類想定効果プラクティス実現

期間評価コメント

管理力全体計画に対する遅れの早期発見

リリース計画速度チャート

短期実施ずみ。適切に実施されている

スプリント内の正確な進捗把握

カンバンバーンダウンチャートスプリント計画

短期スプリント計画は実施されているが、計画の精度がよくない

チーム生産性の可視化見積りベロシティの測定

短期見積り精度が十分でない改善が必要

開発力スプリントによる開発生産性の向上

スプリント実施スプリント計画レビュー

短期スプリントの実施により達成されている

変化対応力の強化継続インテグレーションテスト駆動開発スプリント実施

中期テスト駆動開発のみ、十分着手できていない。他は実施済み

継続的な改善によるチーム力向上

振り返り短期振り返りが適切に実施されている

人材力徒弟制度によるスキル向上と知識共有

ペアプログラミング共同所有

短期ペアプログラミングは同じメンバーばかりになっている

自己組織化チーム運営による「自ら考えるチーム」の実現

自己組織化の考え導入権限委譲

長期チーム内で理解が十分ではない。長期的に取り組む予定

多能工による要員アサインの柔軟化

多能工役割分担の導入長期ペアプログラミングでできる範囲を拡大中


スキル

アジャイル導入プロジェクトチームが備えていると望ましいスキル

技術力マネジメント力経営者対応力

コミュニケーション力

アジャイル知識／経験

ソフトウェアエンジニアリングプロジェクト管理

経営管理上位マネジメント

報告／説明力／折衝力プロジェクト周辺整備

理解されるまえに理解する

理解していただく相手のLanguageを使う

翻訳家

一人で全領域をカバーするのは難しい。例えばPM+Agilerの組み合わせにする


アジャイル導入時の典型的な関係部門／利害関係者

ソフトウェア開発チーム

ユーザ部門

経営層

人事評価部門

標準化/品質管理部門

開発パートナー

ユーザ部門ユーザ部門

マネジメント

マーケティング

顧客開発

他開発チーム

HW/ネットワーク／展開

アジャイル導入推進グループ

オーバービュー意識


最適化症候群とその解決策

コンサルタントの職業病最適化症候群＇それは最善の方法でやらないと（

１０％の改善

トレードオフ療法 G.M.Weinberg コンサルタントの秘密より

トレードオフ意識


ワンチーム

チームと顧客はワンチーム

マネージャも、経営者も、品質管理グループもワンチーム

プロジェクトの成功を願う仲間

ワンチーム意識

顧客チーム

経営者

マネージャ

人事

品質管理

その他

ワンチーム


大切なこと

最後にみんなに伝えたいこと

相手を心から信頼する

相手を理解する

相手の興味のあることについて相手のLanguageで語る

相手を心から信頼するために、相手にとっての「もっともな理由」を理解する

自分の心は相手には丸見えになっていることを理解する。相手を脅威と思っていないか？

人は、自分の興味あること以外に興味がない。あなたの興味のあることについて語ってないか？


E-AGILITY協議会

〜現場とユーザ企業をアジリティでつなぐコミュニティ〜


E-Agility協議会

2010年11月19日＇金（設立セミナー


匠には誰もがなれるわけではない匠を目指そうとするものだけに、その権利は与えられる

アジャイルツアー2010 アジャイルコンサルタントの秘密

Technology