狠狠撸

狠狠撸Share a Scribd company logo
アジャイル導入
の本当の価値
Hikaru TANIGUCHI / @tanigon
Who?
谷口 光(Hikaru TANIGUCHI)
こんな人
現在フリュー株式会社でゲーム事業をしています
略歴
某N○TグループでSIerを(~2003)
2003~オムロン,オムロンエンタテインメント,フリュ
ー
プログラマ?リーダー?開発部門?事業部門マネージ
ャ
Who?
現場、開発部門のマネジメント、事業部門のマネジメント
と経験してきたので、それをふまえて多様な視点でお話が
できれば幸いです。
资料は薄くてしゃべりでカバーしたいスタイル(?)
本日のテーマ
アジャイル導入
の本当の価値
なぜアジャイルを導入するのでしょう
か?
企業にとっては
ビジネスを成功させたいか
ら
メンバー個人にとっては
仕事を楽しく、うまくやり
たいから
つまり、いま「アジャイル」ではなく、
なにかがうまくいっていない、
もしくはもっとうまくやれると思っている。
より良くしたいのは皆が同じで、
アジャイルはその手段や候補の1つ。
アジャイルとは一体、
何なのでしょうか?
アジャイルとは開発プロセスです
いいえ、違います
アジャイルとはXPやスクラムのことで
す
いいえ、違います
アジャイルとは...
姿勢?態度です
例えば、XPは...
アジャイルを実践するため
の、
1つの"実装例"です
いまを改善すべく、アジャイルを导入したい。
アジャイルを導入する。
そのために、XPやスクラムといったプロセスを
そのまま闇雲に実践する/させる。
そうすることで、多くの失敗が生まれます。
それは、本来「価値?原則」であるアジャイルを、
XPやスクラムといったテンプレートだけ
コピペしてしまうからです
ではアジャイル
の導入とは何な
のか?
導入すると何が
変わるのか?
あなたはリーダーやマネージャだとして、あなたの部下?
チームにアジャイルを導入する、という視点で見ていきま
しょう。
重要な価値原則の抜粋...プロセスやツールよりも個人と対話を、...
...計画に従うことよりも変化への対応を、...
価値とする。...左記のことがらに価値があることを認めな
がらも、私たちは右記のことがらにより価値をおく。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼しま
す。
最良のアーキテクチャ?要求?設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に
振り返り、それに基づいて自分たちのやり方を最適に調
整します。
これらの項目はなにもXPなどのプラクティスについて語っ
ているわけではありません。 これらの価値?原則は、アジ
ャイルな"組織"が持つ文化や態度について語っています
アジャイルも含め、すべての開発プロセスは万能(銀の弾丸)
にはなりえません。 そういった特定の"プロセス"よりも、
人にフォーカスをおいてみよう、と考える。
プロセスやツールよりも個人と対話を
アジャイルが適しているのは、要件が途中で変化?進化す
るようなプロダクトです(動く標的)。 ???と、よく言わ
れます。ですが、これは組織についても同じことが言える
のではないかと考えます。
計画に従うことよりも変化への対応を
環境とはPCやサーバOSのことではありません。
支援とは、予算枠だけのことではありません。
チームという環境であり、チームがチームとして動けるよ
うにマネジメントが支援することも含みます。
環境と支援を与え仕事が無事終わるま
で彼らを信頼します
自己組織的なチームとは、自ら考え、自らコントロールし
ているチームのことです。
アジャイルなチーム=自己組織的なチーム
最良の「...」は自己組織的なチームか
ら生み出されます
つまり、
「チーム」のあり方を、
まずアジャイルにしなくてはいけないのです。
プロセスだけいじっても、
アジャイルにはならないのです。
にするためには、どうすればいいのでしょうか
自己組織的なチーム
チームがもっと効率を高めることができるかを定期的に
振り返り、それに基づいて自分たちのやり方を最適に調
整します。
チームが、自らを高めるために、チー
ム自身がやり方を調整する。
自己組織化されたチーム
あなたがマネジメントしているチームたちは、
自己組織化されているでしょうか。
そして、なによりマネジメントは
でしょうか?
チームは組織の1つですが、マネージャがトップダウンで
コマンドしているならばそれは自己組織的ではありませ
ん。
自己組織化を許している
自己組織的なチームにとっての
プロセスやプラクティスのセットとは何でしょうか。
XPのような、代表的なアジャイルプロセス(セット)とはつ
まり、
チームにとっては出発点となるテンプレートなのです。
そして、自己組織化を進めていくと、
チーム固有のアジャイルプロセスに最適化されていくので
す。
ひとたび自己組織的となったチームは、
プロセスを常に洗練させます。
マネジメントがすべきことは、標準開発プロセス策定委員
会を運営して毎年全社統一の銀の弾丸を求めることではな
く、 チームが自らを最適化し続ける、
自己組織的チームの実現を「支援」す
ることです
そのためにまず何から始めればいいのでしょうか
アジャイルを導入しようとするマネジメントがするべきこ
と:
プロセスがチームの持ち物であることを許容する
プロセスは絶えず変化することを認識する
その変化は、チームが自ら起こすものだと認識する
「変化すること」をチームに促す
自ら考えることをチームに要求する
そのどれもが、大変難しいことです。
組織マネジメントのバランス(秩序かカオスか)が
そもそも異なるからです。
開発プロセスには文化が反映されてい
て、文化はゆっくりと変化します。 そし
て、文化を変えていくには変化に抵抗す
るものを克服しなければなりません。 変
化するにはスタジオの覚悟が必要です。 -
Clinton Keith
アジャイルの導入を成功させるために必要なのは、
マネジメントの変化です。
チーム(人)、文化が変わることを「受け入れる」ことです。
決して、ペアプログラミングや継続的インテグレーション
の導入ではないのです。 それらは、チームが最適な開発の
ために、手段として用いるもので、手段だけ強いてもそれ
がアジャイルを生むのではないのです
覚悟は、出来た。
次は、どうする?
チームが自己組織化できるように
「ふりかえり」をしましょ
う!!
ふりかえりとは...
です
PDSA (Plan Do Study Action)
自己フィードバック
自分たちが、自分たちを見つめること
改善案を出し、コミットすること
チームがもっと効率を高めることができ
るかを定期的に振り返り、 それに基づい
て自分たちのやり方を最適に調整しま
す。
定期的
定期的=タイムボックス
イテレーション(スプリント)開発でなくとも(仮にウォータ
ーフォールでも) ふりかえりをタイムボックス化することは
可能です
一週間や二週間など
ふりかえりでは何をするのか
これもまた、実は何でもよい。 オススメは
KPT
详细は割爱させていただきます
前回のふりかえりから、今回までの間で、
「よかったこと」(=継続してよいこと)、
「問題」(=改善すべきこと)、
「試す/改善アクション」
を出す
これをチームが定期的にすることで、
自分たちが何をしているのかを知る
自分たちがうまくいってないことを知る
自分たちが何をすべきかを考える
その改善は"自分たちがやる"とコミットする
ができるようになります。
マネジメントが行うべき支援は、
チームがルールを最適化していくことを許容する
チームが自ら考え、答えを出して、アクションすること
を見守る
チームが挫けてきたら、なんとか応援して続けてもらう
ようなこと。
いささか極論に見えるかもしれませんが...
プラクティスセットとして、XPだスクラムだ、というよ
うなこと
ペアプロ、TDD、デイリービルド、CI...
ウォーターフォールか、アジャイルか?
これらのことも、すべてチームが考え、コミットし、アク
ションし、改善最適化すれば良い。 (プラクティスから入る
のではなく、価値原則を満たすプラクティスをチームが選
べば良い)
だからこそ、最初にすべきことは、
であり、
です。
チームの自己組織化
それを受け入れること
XPの"Embrace Changes"とは、 製品への変更だけではな
く、組織やチームや人々の考え方に起こる変化を、エンジ
ニアのみならず、マネジメントや関係者が受け入れるこ
と。
誰もが、(自分自身とも)闘う"変化への抵抗"
「人は変化に必ず抵抗する」
「変わらなくては、と気づいたとき、
変化の半分は終わっている」
「新しく始めるよりも難しいことは、
古くから続けてきたことを止めること
だけだ」
現場にアジャイルを導入するなら、
マネジメントも変わらなくてはならない。
ひとたび自己組織化されたチームは、 XP、スクラム、とい
う話を超えて、 半自動的に最適化されていきます。
これは本質的にマネジメントにとっても有益であるはずで
す。 (仮に、秩序よりはカオスのように见えるとしても)
今日より明日、
この案件より次の案件、
今年より来年。
仕事をより良いものにするためにまずは、
ふりかえりから
始めてみませんか?
ご清聴ありがと
うございました
議論、ツッコミ、質問、などなどなんでもどうぞ
Twitter:@tanigon / mailto:tanigon@tanigon.info
今日しなかった重要な話
「計測」が重要
私の経験してきた数値
(最適な人数とか、改善実績とか)
どこまでを許容するか
監査や社内標準との整合性の確保の方法
責任と権限の関係、捺印ナビリティ
連続的な変化と 非連続的な変化
etc...

More Related Content

XP祭り関西(2015)資料 : アジャイル導入の価値