アジャイル　マネジメント？

Jurgen Appelo version 2 Translated  by  @hardakiro

始めに、 始まりから...

コンピュータ  プログラミング  

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

アジャイル開発  

1950    

1960    

1970    

1980    

1990    

2000    

2010  

秩序 複雑 カオス

プロジェクトの  伝統的な見方  

スコープ

納期 費用

コスト(リソース)を人とツールに分ける  スコープを機能と品質に分ける(sugges>on:  ScoB  Ambler)  

プロセスの次元を追加する(sugges>on:  Alistair  Cockburn)  

(ビジネス)価値の次元を追加する(sugges>on:  Jim  Highsmith)  

hBp://www.ambysoL.com/essays/brokenTriangle.html  hBp://alistair.cockburn.us/index.php/Process:_the_fourth_dimension  hBp://blog.cuBer.com/2009/08/10/beyond-­‐scope-­‐schedule-­‐and-­‐cost-­‐measuring-­‐agile-­‐performance/  

アジャイルの先駆者が  気がついたこと  

1.  価値  2.  人  3.  機能  4.  品質  5.  ツール  6.  時間  7.  プロセス  

ソフトウェア  プロジェクトの  次元は７つになった  

それで、  アジャイルになる、  ってどういうこと？  

価値  

変化を抱擁する  

フィードバック  

頻繁に届ける  

バリューストリーム  

価値マッピング  優先順位付け  

インクリメント  

例:  フィードバックか

ら  価値を得るために  

ブログを書く  

人  

やりとり  

協働  小さなチーム  

多能工  同室  

自己組織化  信頼  

説明責任  

尊敬  

例:  ソーシャルネットワークを、やりとりをはぐくむのに使う  

機能  

顧客を巻き込む  

バックログ  

ユーザーストーリー  

受け入れ基準  

市場性のある最小の機能  

ユーザーデモ  

“深さ１インチ、幅１マイル”  

例:  本の提案を  トピックのバックログで  

品質  

技術的卓越  

テスト駆動開発  

ペアプログラミング  

完了の定義  

リファクタリング  出現する設計  

シンプルさ  

例:  チェックリストを  

完了の定義として使う  

ツール  

デイリービルド  

継続的統合  

テスト自動化  

オープンオフィス  タスクボード  

バーンチャート  

バージョン管理  

例:  作業者にあったシンプルなツールを使う  

時間  

タイムボックス  

イテレーション  

スプリント  

出荷可能な製品  

段階的詳細化計画  

持続可能なペース  

リリース計画づくり  

例:  締め切りに向けて  タイムボックスで執筆する  

プロセス  

スタンドアップミーティング  

プランニングポーカー  

ベロシティ  

スパイク  

コードの共同所有  

ふりかえり  

スプリントプランニング  

例:  許諾申請のプロセスを理解する  

結果:  (多かれ少なかれ)アジャイルな方法で作られた製品  

世界の他の人たちは、アジャイルをどうあつかってるの？  

hBp://www.versionone.com/state_of_agile_development_survey/10/  

hBp://www.versionone.com/state_of_agile_development_survey/10/  

hBp://www.versionone.com/state_of_agile_development_survey/10/  

hBp://www.versionone.com/state_of_agile_development_survey/10/  

アジャイルになるために、マネージャは何をすればいいの？  

マネジメント  3.0  モデル  

人々を 活性化する

チームに 権限委譲する

制約を きれいに揃える コンピタンスを

開発する

構造を 成長させる

　すべてを 　改善する　

視点  #1:  人々を活性化する  

組織の中で最も重要な要素は人である。マネージャは、人々を活動的で、創造的で、意欲あふれる状態にするためにできることは何でもやる。  

情報イノベーションシステムをマネージする  

人々の本質的欲求を理解せよ  

一対一対面のミーティングを組織せよ  

ギャラップの12の質問を使え  

1.  仕事で自分に何を求められているか知っているか？  

2.  正しく仕事を行うのに必要な材料、機材が利用できる状態か？  

3.  職場では、毎日ベストを尽くせるか？  

4.  過去７日の間に、自分のした良い仕事を認められたか？または褒められたか？  

5.  会社の上司、同僚は、自分を個人として気遣ってくれるか？  

6.  自分の成長を促してくれる人が職場にいるか？  

7.  職場では、自分の意見が尊重してもらえるか？  

8.  会社のミッション・目的によって、自分自身の仕事が大切だと思えるか？  

9.  同僚は、良い仕事をすることにコミットしているか？  

10. 職場に親友はいるか？  

11. 過去６ヶ月間に、職場で自分の成長について話してくれた人がいるか？  

12. 過去１年間に、職場で学び、成長する機会があったか？  

360  度 評価 ミーティングを組織せよ  

視点  #2:  チームに権限委譲する  

チームは自己組織化できる。そのためには、マネジメントからの権限委譲、承認、信頼が必要である。  

庭師のようにマネージせよ  

“見えない電気柵”  に人々がひっかからないように  

重要な判断エリア  を定義せよ  

1.  指示する:  マネージャとして判断を下す  

2.  売り込む:  判断について人々を説得する  

3.  相談する:  判断する前にチームに意見を求める  

4.  参加する:  チームと一緒に判断する  

5.  助言する:  チームの判断に影響を与える  

6.  確認する:  チームが判断をした後にフィードバックを求める  

7.  委譲する:  影響を与えない。チームが自分でやる  

権限の７つレベルを使う  

権限ボードを作る  

視点  #3:  制約をきれいに揃える  

自己組織化した結果は、どこに転ぶかわからない。それゆえ、人々と共有リソースを守り、明確な目的と、適切なゴールを示す必要がある  

コモンズの悲劇に対処する  

制度  共有ルールを受け入れる信頼を作る  情報  状況の理解を深める  固有性  チーム間の帰属を深める  動機  個人の改善の必要性に対応する  

http://www.newscientist.com/article/mg20327225.700-­‐triumph-­‐of-­‐the-­‐commons-­‐helping-­‐the-­‐world-­‐to-­‐share.html  

出現するより高いゴールをマネージする  

数値目標-­‐お金などの外部誘因  は使うな    

視点  #4:  コンピタンスを開発する  

チームメンバーに能力が欠けていたら、チームがゴールを達成できることはない。そのため、マネージャは、コンピタンスの開発に貢献しなければならない。  

スキルと規律を区別せよ  

1.  自己啓発    

2.  コーチング＆メンタリング    

3.  トレーニング＆認定    

4.  文化＆社会化    

5.  ツール＆インフラ    

6.  監督＆統制    

7.  マネジメント  

コンピテンシーへの７つのアプローチを使え  

1.  時間  2.  人  3.  ツール  4.  機能  5.  品質  6.  プロセス  7.  価値  

1. 個人

 

2. チーム

 

3. 部門

 

4. ビジネスユ

ニット

5. 組織

 

メトリクスを使って、部分最適を避ける  

視点  #5:  構造を成長させる  

チームは、複雑な組織のコンテキスト内で働くことが多い。そのため、コミュニケーションを促進する構造が重要である。  

仕事場をネットワークとしてマネージせよ。  

人々の仕事をダイナミックに  

価値ユニットに基づいてビジネスを設計する  

視点  #6:  すべてを改善  

人々、チーム、組織は継続的に改善を続け、可能な限り長く失敗を避けなければならない。  

改善の３つのエンジン  

第二のループ

第一のループ

ふりかえり

イテレーション

適応 探索 予測

非線形な改善を  

1,  3,  5  Kaizen  漸進的な改善  

2,  4  Kaikaku  急進的な改善  

プラクティス同士を強く結びつけない  

マネジメント  3.0  モデル  

人々を 活性化する

チームに 権限委譲する

制約を きれいに揃える コンピタンスを

開発する

構造を 成長させる

　すべてを 　改善する　

OK,  ちょっと    多すぎ...  

次の２つだけ  忘れないで...  

ソフトウェア開発チームは、  自己組織化システムだ。  サポートせよ。邪魔するな。  

アジャイルマネージャは、チームの周りのシステムに対して仕事をする。チームの中の人々に対してではない。  

@jurgenappelo  (twitter)  

slideshare.net/jurgenappelo  

jurgenappelo.com  (site)  

noop.nl  (blog)  

management30.com  (book)  

http://creativecommons.org/licenses/by-nd/3.0/

This  presenta>on  was  inspired  by  the  works  of  many  people,  and  I  cannot  possibly  list  them  all.  Though  I  did  my  very  best  to  aBribute  all  authors  of  texts  and  images,  and  to  recognize  any  copyrights,  if  you  think  that  anything  in  this  presenta>on  should  be  changed,  added  or  removed,  please  contact  me  at  jurgen@noop.nl.