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