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

www.takumi-businessplace.co.jp

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

匠Business Place　牛尾　剛2011年4月15日（金）

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

The Secrets of Agile Consulting

Agile Japan 2011


本日の内容

  自己紹介   アジャイルの概要   アジャイルの企業導入のポイント   E-Agility協議会   アジャイルプロセス　ベースライン　７つのポイント（付録）


自己紹介

牛尾　剛　(Tsuyoshi Ushio)

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

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

NEC

豆蔵

匠BP

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

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

 会社を立ち上げ、萩本さん、細川さんと企業改革／要求開発／  アジャイルのコンサルタントとして活躍中  CSM, CSPOの取得

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

超上流エンジニアリング

時代

仕事のモチベーション

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

経営者の都合を知った時代

Twitter : @sandayuu


アジャイルの概要

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


開発プロセスの歴史

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

計画主導／先行型設計

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

要求

設計

製造

テスト

ものづくり

納期

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

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

　単純作業

・試行錯誤はやりやすい

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

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

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

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

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

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

プログラムを

動かして初めて問題が発覚！プロジェクトマネジメント技法

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

最初から

予見は難しい計画立案


開発プロセスの歴史

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

適応型／進化型設計

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

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

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

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

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

反復１反復２反復３

要求

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

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

テスト

進化型設計技法


アジャイル開発とは

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

  次の価値を共有する   プロセスやツールより、人と人同士の相互作用を重視する   包括的なドキュメントより動作するアプリケーションを重視する   契約上の交渉よりも顧客との協調を重視する   計画に従うよりも変化に対応することを重視する

  代表的な開発手法   eXtreme Programming   Scrum   FDD   Crystal Family   DSDM


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

  通常はフェーズが進むにつれ変更のコストは大きくなる   先のフェーズでも変更のコストがあまりかからないように出来ないか？

コストコスト

時間時間

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

先のフェーズでも変更のコストを平準化できないか？

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


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

  1~4週間毎に、動作するアプリケーションを作る   1~4週間毎に、計画／実施／評価し、改善する

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

1~4週間程度

スプリント計画

開発実施

レビュー振り返り

初日最終日

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

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

を繰り返す

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

が作成される

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

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

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

リリース計画

Product Owner

Team


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

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


アジャイル組織導入の難しさ

自分がやるわけではない

やれ！

嫌や！


アジャイル導入の秘密

不安を取り除くこと

LEVEL 5


アジャイル導入の大秘密

「できる」と思えること

LEVEL 6


アジャイル導入のゴール

「やりたい」と思えること T D D

T D D

T D D

LEVEL 7


マービンの医学的秘密

 関係者が「やりたい」と思うことができればこの状態が訪れる

すべての病気の９０％までは自然になおる医者による手当などまったくなしに

By コンサルタントの秘密 G.M. ワインバーグ


誰にとっての不安を取り除くか？

  アジャイル導入はチームのみではない

開発チーム

オーナー

マネージャ

導入チーム

お金いくらかかるやろ？

効果あるかなぁ？

マネージャはチームに口だすな。って私は何をすれば、、

私は不要？！

言ってる事がわからんから判断できん

失敗はさけたい

本当に上手くいくの？

自分たちにできるかな？

何でやらんとあかんねや！

判断しろと言われてもな

今の何が悪いねん！

どうやってやるの？

今の仕事にどう影響するの？

ohters

アジャイルこたつモデル


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

ソフトウェア開発チーム

ユーザ部門

経営層

人事評価部門

標準化/品質管理部門

開発パートナー

ユーザ部門ユーザ部門

マネジメント

マーケティング

顧客開発

他開発チーム

HW/ネットワーク／展開

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

ソフトウェア開発

チーム以外


「やりたい」にたどり着くための具体的方法

Step 1 心作り

Step 2 相手の理解

Step 3 レクチャ＆カスタマイズ

Step 4 導入計画/準備

Step 5 導入／評価／展開

アジャイル導入チームメンバーの心構え

戦略／目的／課題の理解相手の要求、価値観、利害関係の理解

プロジェクトの進め方のレクチャ企業の文化／組織／目的／チームに合わせたカスタマイズ

アジャイル導入計画の立案ロケットダッシュのための準備

プロジェクトの実施／レビュー進捗／課題の報告及びプロジェクトの評価展開資料／他の人がやりたくなる仕掛けづくり


Step1 心づくり

 アジャイルではなく導入目的を目指しているか？  自分のためでなく相手のために仕事をしているか？  導入チームは「アジャイル」では無い

そして・・・

相手を心から信頼すること

アジャイルに最もこだわっているのは自分である。


Step2 相手を理解する

相手を心から信頼する

相手の都合、知りたい事、価値観を理解する

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

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

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

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


Step2 相手（会社）を理解する

  アジャイルを導入する目的を理解／整理する   現状の組織／レポートライン／役割分担を理解する   利害関係者を分析する

問題・課題エリア

解決策エリア

要求エリア

利益向上

３年後利益５億達成

売上増

コスト削減

３年後売り上げ１００億

顧客サービスの向上

魅力的な商品開発強化

魅力的な商品の提供

マーケティング強化

販売業務プロセス改善

顧客のニーズが多様化しており過去の売れ筋商品が売れなくなっている

販売業務の品質向上

顧客ニーズの把握

顧客への営業強化

CRMシステム導入

販売システム再構築

新規参入者が多く競争が激化しているので、

ここ数年売上が低迷している

販売業務の効率化


（参考）アジャイル導入チームの必要スキル

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

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

コミュニケーション力

アジャイル知識／経験

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

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

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

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

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

翻訳家

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


Step3 レクチャ＆カスタマイズ

  相手の知りたい内容を、相手の言葉で説明する   相手の聞きたい事に答える、不安を解消する、観察する   神髄まで教えようと思わない、本当のポイントのみ

オーナー

開発チーム

マネージャ

アジャイルの導入メリット導入目的達成状況３カ年計画とリソース

予算

アジャイル導入理由具体的なやり方と理由開発チームへのメリット

チームのマネジメント方法具体的なやり方とトレードオフ通常のマネジメントとの差分マネージャへのメリット


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

期間評価コメント

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

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

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

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

カンバンバーンダウンチャート


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

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

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

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

スプリント実施スプリント計画

レビュー

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

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

スプリント実施

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

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

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

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

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

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

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

実現

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

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

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

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


Step3 レクチャ＆カスタマイズ

  アジャイル導入目的を満たせば他の方法でもいい   アジャイルではこうしますけど、このチームではどうします？   このプラクティスをやればこれが達成できます

極力チームがアジャイルな状態をつくりだせるようにファイアーウォールを作る

チーム顧客

ユーザ

ユーザ

ユーザ

マネジメント品質管理人事部門

オーナー

マーケティング

アジャイルチームが仕事に集中できるようマネジメント分野をフォローする


参考（顧客は大変）

アジャイルチーム

顧客開発者

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

…など

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

戦略／業務分析利害関係者や関連部署との調整や合意形成

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

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

：

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

テスト駆動開発

共同所有

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

シンプルな設計


参考（顧客を支援するもの）

アジャイルチーム

顧客開発者

テスト駆動開発

共同所有

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

シンプルな設計

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

…など

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

プロジェクト定義書

コタツモデル

要求分析ツリー

ゴール記述書

…など全体PM


Step4 導入計画／準備

  導入計画はみんなの安心と納得感をつくるために   チームが何をしているのかを透明化する   ざっくりとしたものでよい（３年／１年計画）

コアメンバ教育３プロジェクト支援資料まとめ

社外ブランディングメニュー化

支援部門立ち上げ

人事改訂／品質管理技術教育説明会実施

初年度ノウハウ獲得

二年目展開

三年目メニュー化

シンプルすぎる　３ヶ年計画の例


Step4 導入計画／準備

  開発環境、構成管理、ツール、看板等の運用   体制と役割分担、メンバーとスキルの調査   顧客側、開発側でのリソースとスキルに応じた体制づくり   開発の進め方、進捗報告方式、品質管理方式、コミュニケーション計画、リリース計画、マイルストン、リスク対応策

  ソフトウェア開発部分以外の作業（契約、HW、企画、予算取り、業務改善等、、、）   達成できる見込みの事と、できない事の共有

チームがロケットスタートできて「やれる」と思えるように

日本人は教わってできると思ったら自然と工夫しはじめる

考え始める


Step5 導入／評価／展開

  最初の数イテレーションで改善する   変化に強くなりたかったらテスト駆動／リファクタリング／CI   オブジェクト指向の基礎が無いとき、オブジェクトゲームは有効   出来る人を入れる事（これはアジャイル関係なし）   チームのムードと事実を観察する   チーム外をないがしろにしない事（進捗、中間報告等）   チームに不要な負荷をかけない事   早めに失敗して最終的に成功する、それを事前に広めておく

透明性とムードとプロジェクトの成功に注力する


Step5 導入／評価／展開

  評価を計画しておくこと（チーム／マネジメント／オーナー）   成功すること   「成功」を会社で、評価、プッシュすること   チームやマネージャ等に関心と感謝と励ましの言葉を   導入の振り返り

アジャイル導入を「したくなる」状態を作り出す

俺たちのやり方上手く行ったよ！

がんばってくれてありがとう！

マネージャさんいつも助けてくれてありがとう

あのチームは本当に上手く行った。

よくやってくれたよ！

しかも楽しいよね

あいつら上手くいってるなぁ~いいなぁ~


E-AGILITY協議会

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


E-Agility協議会

  2010年11月19日（金）設立セミナー実施   2011年5月31日（火）　設立記念講演予定

長沢智治（マイクロソフト株式会社）林衛（株式会社アイ・ティ・イノベーション）三井伸行（株式会社戦略スタッフサービス）中山嘉之（協和発酵キリン株式会社）松本聰（データインパクト/DAMA日本支部）細川馨（日本アイ・ビー・エム株式会社）永瀬美穂（株式会社ディアイスクエア）上田雅美（株式会社匠BusinessPlace/株式会社アネゴ企画）

［幹事］依田智夫（株式会社シナジー研究所）牛尾剛（株式会社匠BusinessPlace）長瀬嘉秀（株式会社テクノロジックアート）


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

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


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

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



開発実施

レビュー振り返り

リリース計画

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 ストーリ検討

チーム

プロダクトオーナー



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

重要度

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


３. タイムボックス

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

タイムボックス開発


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

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

重要度


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

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

Technology