Agile Tour Osaka 2012の講演内容が少しずつ明らかに！
というわけで、前回のエントリに引き続いて、Agile Tour Osaka 2012 in Minohに関していくつかのアップデートを。
今年のAgile Tourのマップが更新されました
Agile Tour 2012の公式サイトのトップページのマップが更新されました。
このAgile Tourというムーブメント自体がフランスから始まったので、フランスでの開催都市が多いのは当たり前ですが、やはり昨年に引き続いて中国とブラジルが多いのが目立っていますね。
講演タイトルと内容の一部が公表されました
牛尾さんと藤原さんの講演タイトルと内容が公表されています。
「Agileの里、箕面にだけこっそり教える プロダクトオーナーの秘密 〜大抵の人が出来ない無から有を生み出すちょっとした技術〜」（牛尾さん）
タイトルから、牛尾さん節が炸裂してますね（笑）。
プロダクトオーナーの仕事で多くの人が困難に感じるポイントは、既存の情報を整理すると、ストーリや要求が出てくる訳ではなく、自ら考えて、新しい要求を自ら生み出すところだと思います。本講演では1を100にするテクニックではなく、0から1を生む技術を理解してもらいます。そして、その考え方を皆さんと一緒にリアルに体験してその経験を持ち帰ってもらう為のセッションです。
「地図を捨ててコンパスを頼りに進め！」（藤原さん）
マインドセットの変革とかの話ですかね。楽しみです。
よりソフトウェアを価値のあるものにするために。言うのは簡単ですが、そこにたどり着くまでの道のりは長く険しい。それは、なぜなのでしょうか？このセッションでは、従来の開発方法から離れられないマインドセットや、アジャイルプラクティスを習慣に変えるまで苦悩など、社内アジャイル開発支援活動から見えてきたアジャイル適用の壁を、事例を交えながら紹介させて頂きます。
長瀬さんの講演も楽しみです
そしてまだタイトルも内容も公表されていませんが、このイベントのオーガナイザーの一人として個人的には長瀬さんの講演を楽しみにしています。アジア諸国でのエンジニア教育・アジャイル教育にも携わっておられる長瀬さんの話を聴いて、日本人として我々は何を感じ何を考えるか、参加者の皆さんともディスカッションしてみたいです。
そして主役は参加者のみなさんです
前回のエントリにも書いた通り、カンファレンスの運営についても、いろんな試みをしていきたいと考えています。特に今回は、"Ignorance Backlog"（無知のバックログ、知りたいこと一覧）をもとに参加者自身が講師や他の参加者から必要な情報や知識をPULLできるような仕組みを組み込んでいきます。
今年もやります！Agile Tour Osaka 2012 in 箕面！
今年もAgile Tourの季節がやってまいりました。ゆるく世界とつながりながらやっているこのイベントも大阪での開催が今年で３回目。
オフィシャルページはこちら↓
詳細と申込はこちら↓
過去２回をふりかえりたい方は、こちらのエントリもどうぞ。
- Always All Ways: [IT] Agile Tour Osaka 2010の見どころ解説
- Always All Ways: [IT] Agile Tour Osaka 2010 予習ガイド
- Always All Ways: [IT] Agile Tour Osaka 2011開催にあたって
- Always All Ways: [IT] Agile Tour Osaka 2011の思い出
今年は箕面で！
今年は大阪市内から離れて、箕面市での開催となります。
Why Minoh?
滝があるから？紅葉が見たいから？箕面ビールを飲みたいの？ミスタードーナツの1号店があるから？年中食べ放題の「カーネルカフェ」コーナーのあるケンタッキーフライドチキン小野原店があるから？………？
いえいえ、どれも正しいけど正解ではありません。
実は、（私の知っている）Agilistaたちの中に結構、箕面市に縁のある人が多いことに最近気づいてしまいましてw。
実家が箕面の人や学生時代箕面に住んでた人…。誰がそうなのかは、当日現地で確認してみてくださいね。実は箕面で滝に打たれて育った人が今、その反動でAgilistaになっているのではないかとの仮説もあり、とりあえず箕面！ってなわけです。
カンファレンスのあり方を変える試み
今回のテーマにも関係ありますが、Agile Tour Osaka 2012 in Minohではカンファレンスのあり方そのものも「チェンジ」してみようかと考えています。
それは、半年ほど前に
というエントリを書いてからずっと考えていたことでもあります。
一度に全部は無理だけど、まずは少しずつね。
お申し込みはお早めに！
まだ、サイトでは詳細プログラムなどを掲載できていませんが、これから徐々に更新していく予定です。
まずは忘れないうちに、今すぐお申し込みを♪
XP祭り2012で感じたこと、考えたこと
9月15日に開催されたXP祭り2012に参加してきました。
今年は縁あって、「アジャイルコーチラウンドテーブル」というセッションにも（アジャイルコーチじゃないけど）登壇させていただきました。現在の立場的なものもあり、直接回答できるような内容があまりなかったですが、みなさんの悩みや現場での取り組みをいろいろ聴くことができました。
チームを育てるという視点は大事
ラウンドテーブルでの質問の中でも「アジャイルって、優秀なスーパープログラマーを集めないと無理なのか？」というようなお題があり、そこでの回答でも「アジャイル開発に取り組む中でメンバーのレベルを引き上げていく」という話がありました。それはまさにその通りだと思います。
優秀なメンバーがいるからアジャイル開発ができる、ではなくて、アジャイル開発に取り組む中で優秀なメンバーが育ち、すばらしいチームができるということだと思います。逆に言えば、このメンバー育成の視点やチームの成長の視点を持たなければアジャイルではないと言ってもいいくらいかと思います。
今は、直接アジャイル開発チームとは関わっていませんが、それでも、アジャイルの「育てる」という考え方はいつも忘れないようにしていることの一つです。
（参考） Always All Ways: [IT] 継続的改善フレームワークとしてのScrum
組織の壁は人の壁
もう一つは、アジャイル開発の導入・展開における「壁」の話。
この話は、いつも出てきますね。確かに、大きな組織になればなるほど「組織」という壁にぶつかったり、なんとも説明しがたいが抗うこともできない「空気」に流されることはよくあります。しかし、私自身はその実態の掴めない「組織」や「空気」と戦うのはあまり賢明ではないかな、と思っています。そうではなく、それを人との壁であったり、自分自身が勝手に作っている（思い込んでいる）壁として捉えて対処していきたいな、と。
そんなことを考えていたら、2年ちょっと前に書いたブログを思い出しました。
これは、要求開発アライアンスの定例会のUstream中継を観ながらつぶやいた内容について補足する形で自分の考えを綴ったものです。XPだろうがアジャイルだろうが要求開発だろうが、組織の中で何かやろうとした時の話には共通点があるなー、と改めて思いながら読み返した次第。
選択理論心理学もかじっておくといいよ
上で挙げたブログの最後にも書いていますが、組織の中での人との問題に対処するには、ウィリアム・グラッサー博士の「選択理論心理学」も少しかじっておくといいかもしれません。（少なくとも私はこれに少なからず影響を受けています。何年か前にDevLove関西の初回でこの話もした記憶がありますが、残念ながらスライドは公開していません。）
あとは、"How to Change the World"ですね。
これは、ナイスビアの人が今回のXP祭り2012のLTで紹介してくださっていますので、以下のスライドをご参照ください。
- 作者: ウイリアムグラッサー,William Glasser,柿谷正期
- 出版社/メーカー: アチーブメント出版
- 発売日: 2003/07
- メディア: 単行本
- 購入: 1人 クリック: 6回
- この商品を含むブログ (7件) を見る
経営にとってのアジャイルその２（Steve Denning on Business Agility）
４月に書いた
というエントリの続編です。
とは言っても、まぁ、Steve Denningのインタビューが昨日公開されていたのでそれを貼り付けてご紹介したかっただけですが（笑）。
ちなみに、上のビデオの前にはこんなのもありました。流れから言うとこちらから観る方がいいかもしれませんが、どちらか片方だけ観るなら上の新しい方がイチオシ。
DADとCBP: アジャイルと規律と能力ベースの計画と
アジャイルと規律（Discipline）および制度化（Institutionalization）については、以前少しこのブログでも記事を書きました。
今日は、たまたまScott W. AmblerのDADに関する記事から辿ってCBPという考え方を知ることができたので、少しメモ書きしておきたいと思います。
インセプション・フェーズを短くする方法
最初に読んだ記事が、
です。これは、Scottによる「アジャイルプロジェクトでインセプション・フェーズに時間をかけすぎてWater-Scrum-Fallに陥らないためのコツ」みたいな記事。それはそれで、ふむふむという感じではあるのですが、注目したいのは、そこにGlen B. Allemanがつけているコメントです。
ここで彼は、「これは防衛や航空産業で"Capabilities Based Planning (CBP)"と呼ばれているものと同じだ。」と言っています。
Capabilities Based Planning (CBP)
CBPについては、そのコメントの中でも背景や歴史含めて簡潔に説明されていますが、Glenのブログの方を見るともう少し情報を得ることができます。
- Herding Cats: The Basis of Capabilities Based Planning
- Herding Cats: End-to-End Delivery of Business Solutions
CBPは、不確実性の中での計画を扱う概念であり、アジャイル開発におけるインセプション・フェーズでCapabilityに着目して柔軟で適応可能な計画づくりをするという面では、ちゃんと勉強すれば結構「使える」のではないかという気がしています。（気がしているだけですけど。）
ScrumMasterの存在は本質的な変化の妨げになっているのか？
私自身が、アジャイルなシステム開発やアジャイルな組織についての考えを深める上で、最も影響を受けた人物を５人挙げるとしたら、Tobias Mayer氏は間違いなくそのうちの一人です。
そんな彼が今月から新しいブログを始めました。
単にアジャイル開発がやりたいとかじゃなく、組織やビジネス環境を変えたいと思ってアジャイルに取り組んでいる人たちにはオススメです。
できればブログを読む前に、その背景などを綴った
にも目を通しておくとよいでしょう。
そして、昨日公開された最新記事が、
です。
世の中で"ScrumMaster"を名乗っている人たち（「認定」であろうがなかろうが）には、是非読んでほしい記事です。
ScrumMasterは組織の変化にとって邪魔な存在なのか？
彼の観察によると、ScrumMasterは以下の４つのタイプのいずれかになりがちであるということです。
- プロジェクト管理のよりよい方法を探し求めているPM
- 人々をよりうまく管理しようとしているマネージャ
- わけのわからないロールに投げ込まれたTech Lead
- ごくまれにコーチングやカウンセリングのスキルをもった人
最初の３タイプはたとえ短期的にも役には立たないし、最後のタイプの人は別にScrumMasterという名称にはこだわらないでしょう。
そして彼はこう書いています。
I believe the concept of ScrumMaster has done more damage to our industry than it has aided in change.
自らに常に投げかけ続けるべき問い
まぁ、ScrumMasterという名称自体がどうこうというのはさておき、それに類する役割を担っている（と思っている人）は常に自分の存在意義や価値を問うことが求められます。
If you are a ScrumMaster, evaluate your worth. Dig deeper into why you do what you do. Are you truly serving the goal of profound change? Are you rocking the system, making yourself vulnerable, or are you just putting on a new, cool hat while continuing to comply with the status quo? Yes, it's a confrontational question. We need more of those.
大切にしているもの
9月になりました。9月と言えば、XP祭りですね。
今年は、縁あってプログラムの一部であるアジャイルコーチ・ラウンドテーブルというセッションに登壇させていただくことになりました。ありがたいことです。
どこかから「え？おまえ、アジャイル・コーチとちゃうやんけ！」というツッコミが聞こえてきそうですが、いわゆるユーザー企業のマネージャーの立場でアジャイルな開発組織（そしてそうじゃない組織も）に関わってきた経験から、何かしらの発信・貢献ができたらいいなと思っています。
で、そのセッションでご一緒させていただく安藤さんが自身のブログに
という記事を書かれていたので、私も見習ってXP祭りに向けて何か書いておこうと思い立った次第です。
とは言え、過去の職歴やそれぞれの会社でやってきた具体的なことをどこまで書いてよいかわからないので、まずは自分が組織の中でアジャイルの導入・展開をする上で大切にしているもの・ことを過去のブログ記事をふりかえる形で書いておきます。（過去記事の再利用とも言うw）
アジャイル導入はアジャイルにやるのだ
Scrumとは、組織の機能不全を表面化させることで、それへの対処を促すフレームワークとしての特性だけでなく、またその実効性を担保するための、人間の行動・振る舞いを規制・規定するアーキテクチャとしての特性をも持っていると言えるのではないでしょうか。
"Transformation is incremental and iterative"
"Run Change Like an Agile Project"
つまり、アジャイルな組織への転換というものはリニアに進めるものではなく、それこそアジャイル開発そのものと同じように進めるべきであるということです。
その根底にあるのは、Scrum（に限らずアジャイル開発全般的にそうだと思うのですが）が、複雑適応系（Complex Adaptive System）を扱うものであるということ。それを忘れると、本来ワークショップの中で気づき・考えるべき「不確実性にどう対応していくのか？」ということを体験できず、参加者はチグハグな印象を受けるだけでなく、場合によってはワークショップで最も気づいてほしいことに気づかずに間違った理解をしてしまいかねません。
この中でも彼が言っていますが、「Scrumをチェンジ・マネジメントのアプローチとして使う」ということが一つのポイントです。以前のエントリでも何回か書いていますが、「アジャイルの導入はアジャイルにやれ」と言うことですね。それを形にしたのが、上の図のEnterprise Transition Teamであり、具体的には、Transition Backlogにユーザーストーリーの形でバックログをぶっ込んでTransitionの戦略をScrumで回していくということです。
Cherry Pickingに関しては現実的な解釈をするのだ
これは必ずしも「トップダウンでビッグバン的に導入する」ことを意味するわけではありません。ミーム複合体としてのScrumを導入するからといって、それが「全てのミーム（プラクティス）を同時に」導入しなくてはならないというわけではないということです。概念として大きな固まりで捉えること、そしてそれを伝えていくことは重要ですが、個々のプラクティスの導入時期や順序などは、それこそその組織のコンテキストに応じて、というのが正しいアプローチではないかと思います。
ここでのキーは、「コンテキストに合わせたり、相手に合わせたり」と「一体となってあるべき方向に」でしょう。逆に言えば、成果を出している現場では、この２つのポイントをしっかり守った上で現場に合ったやり方をしているのであり、それは単に興味や取っ付きやすさなどに基づく「つまみ食い」としてのCherry Pickingではないということでしょう。
その他
「パイロットの成功がアジャイルな組織をダメにすることもある」- これは我々がアジャイルやリーンの導入をする際にパイロットプロジェクトを実施し、またその結果を考察するにあたって念頭においておくべきことだと思います。
この２つに共通することはいくつかありますが、最も重要なのは「学習」だと思います。フィーチャーチームを作ったり、またコンポーネントチームからフィーチャーチームに移行したりするときも、チーム内におけるSpecializatiionとGeneralizationのバランスを取ったりするときも、そこではある意味個人としてあるいは組織としての「学習」が要求されます。その意味では、Scrumは改善のフレームワークであるとともに、組織の学習を強制するフレームワークとも言えるかもしれません。
