2012-10-14

Agile Tour Osaka 2012の講演内容が少しずつ明らかに！

Agile Learning Management

というわけで、前回のエントリに引き続いて、Agile Tour Osaka 2012 in Minohに関していくつかのアップデートを。

今年のAgile Tourのマップが更新されました

Agile Tour 2012の公式サイトのトップページのマップが更新されました。

Welcome to Agile Tour 2012! | agiletour.org

このAgile Tourというムーブメント自体がフランスから始まったので、フランスでの開催都市が多いのは当たり前ですが、やはり昨年に引き続いて中国とブラジルが多いのが目立っていますね。

講演タイトルと内容の一部が公表されました

牛尾さんと藤原さんの講演タイトルと内容が公表されています。

「Agileの里、箕面にだけこっそり教える　プロダクトオーナーの秘密　〜大抵の人が出来ない無から有を生み出すちょっとした技術〜」（牛尾さん）

タイトルから、牛尾さん節が炸裂してますね（笑）。

プロダクトオーナーの仕事で多くの人が困難に感じるポイントは、既存の情報を整理すると、ストーリや要求が出てくる訳ではなく、自ら考えて、新しい要求を自ら生み出すところだと思います。本講演では1を100にするテクニックではなく、0から1を生む技術を理解してもらいます。そして、その考え方を皆さんと一緒にリアルに体験してその経験を持ち帰ってもらう為のセッションです。

「地図を捨ててコンパスを頼りに進め！」（藤原さん）

マインドセットの変革とかの話ですかね。楽しみです。

よりソフトウェアを価値のあるものにするために。言うのは簡単ですが、そこにたどり着くまでの道のりは長く険しい。それは、なぜなのでしょうか？このセッションでは、従来の開発方法から離れられないマインドセットや、アジャイルプラクティスを習慣に変えるまで苦悩など、社内アジャイル開発支援活動から見えてきたアジャイル適用の壁を、事例を交えながら紹介させて頂きます。

長瀬さんの講演も楽しみです

そしてまだタイトルも内容も公表されていませんが、このイベントのオーガナイザーの一人として個人的には長瀬さんの講演を楽しみにしています。アジア諸国でのエンジニア教育・アジャイル教育にも携わっておられる長瀬さんの話を聴いて、日本人として我々は何を感じ何を考えるか、参加者の皆さんともディスカッションしてみたいです。

そして主役は参加者のみなさんです

前回のエントリにも書いた通り、カンファレンスの運営についても、いろんな試みをしていきたいと考えています。特に今回は、"Ignorance Backlog"（無知のバックログ、知りたいこと一覧）をもとに参加者自身が講師や他の参加者から必要な情報や知識をPULLできるような仕組みを組み込んでいきます。

申し込みはこちらからお早めに

11月3日 AgileTourOsaka2012 in Minoh　箕面の滝からこんにちは(大阪府)

f:id:tmaegawa:20121014144515j:plain

2012-10-01

今年もやります！Agile Tour Osaka 2012 in 箕面！

Agile Learning Management

今年もAgile Tourの季節がやってまいりました。ゆるく世界とつながりながらやっているこのイベントも大阪での開催が今年で３回目。
オフィシャルページはこちら↓

Agile Tour Osaka (Japan) | agiletour.org

詳細と申込はこちら↓

11月3日 AgileTourOsaka2012 in Minoh　箕面の滝からこんにちは(大阪府)

過去２回をふりかえりたい方は、こちらのエントリもどうぞ。

今年は箕面で！

今年は大阪市内から離れて、箕面市での開催となります。
Why Minoh?
滝があるから？紅葉が見たいから？箕面ビールを飲みたいの？ミスタードーナツの1号店があるから？年中食べ放題の「カーネルカフェ」コーナーのあるケンタッキーフライドチキン小野原店があるから？………？

いえいえ、どれも正しいけど正解ではありません。

実は、（私の知っている）Agilistaたちの中に結構、箕面市に縁のある人が多いことに最近気づいてしまいましてw。
実家が箕面の人や学生時代箕面に住んでた人…。誰がそうなのかは、当日現地で確認してみてくださいね。実は箕面で滝に打たれて育った人が今、その反動でAgilistaになっているのではないかとの仮説もあり、とりあえず箕面！ってなわけです。

カンファレンスのあり方を変える試み

今回のテーマにも関係ありますが、Agile Tour Osaka 2012 in Minohではカンファレンスのあり方そのものも「チェンジ」してみようかと考えています。
それは、半年ほど前に

カンファレンス再考 - Always All Ways

というエントリを書いてからずっと考えていたことでもあります。
一度に全部は無理だけど、まずは少しずつね。

お申し込みはお早めに！

まだ、サイトでは詳細プログラムなどを掲載できていませんが、これから徐々に更新していく予定です。
まずは忘れないうちに、今すぐお申し込みを♪

2012-07-14

「How to Change the World〜チェンジ・マネジメント3.0〜」が出ました！

Agile Life Learning Book Management

３月末頃からユルユルと翻訳作業を進めてきた"How to Change the World"(Jurgen Appelo著)の日本語版を、昨日（7/13）無事に出版することができました。

本書は電子書籍版（PDF/EPUB）のみで、達人出版会さんのサイトから購入できます。

How to Change the World 〜チェンジ・マネジメント3.0〜 - 達人出版会

この本との出会い

過去の関連記事は、こちら

著者のJurgenは、このブログでも再三取り上げている書籍「Management 3.0」を書いた人で、私が最も影響を受けた人物500人のうちの一人です。ご興味があれば是非、ダウンロードして目を通してみてください。

AgileとChange

アジャイル開発の現場においては、変化を抱擁し変化に適応していくことが求められます。そして、アジャイル開発の導入・適用においては、組織レベルでの変化やトランスフォーメーションが欠かせません。
そこでは、チェンジ・エージェントとして適切に振る舞える人が必要であり、優秀なチェンジ・エージェントになるために必要なことが80ページ足らずのコンパクトな小冊子にまとめられたのが"How to Change the World"です。

Fearless ChangeとHow to Change the World

Changeやチェンジ・エージェントというキーワードから、Linda Risingの"Fearless Change"を思い出された方もいらっしゃるかもしれません。そんな方は是非、無料でダウンロード可能な

"Questions for Change Management 3.0"(pdf)

を併せてお読みになることをおすすめします。
その中にはチェンジ・エージェントが考えるべき問いが、"Fearless Change"のパターンとのリファレンス付きでリストアップされています。

謝辞

今回の翻訳に際しては、原著がそもそもJurgenの自費出版のような形だったこともあり、翻訳の許諾を得るために著者本人に直接コンタクトを取るところから始まりました。日本語版の出版を快諾してくれたJurgenをはじめ、共訳者の川口さん・吉羽さん、レビューをしてくださった原田さん・ナイスビアの永瀬さん・高江洲さん、契約面でお手伝いいただいたアギレルゴコンサルティングの谷口さん、達人出版会の髙橋さん、その他本書の出版に関わってくださったすべての人々に感謝です。

2012-04-15

"How"の質問に答えてはいけない

Agile Life Learning Management

先週は、リーンソフトウェア開発のポッペンディーク夫妻（メアリーとトム）が来日していました。幸運なことに私も、

月曜日はリーダーシップ・ワークショップの一日目に出て〜とんかつ食べに行って〜
火曜日はリーダーシップ・ワークショップの二日目に出て〜しゃぶしゃぶ食べに行って〜
水曜日はSECセミナーでの午前中の講演を聴いて〜
金曜日は夫妻を囲む会でミニレクチャー聴いて懇親会で飲んで〜

という形でいろいろと直接お話をする機会を得ることができました。

本当は、「メアリーから学んだ５つのこと」みたいなタイトルでまとめてみたかったのですが、なかなかうまくまとまりそうにないので、以前のエントリとも絡めて一つだけ書いておきたいと思います。

Don't answer questions

これは、以前のエントリ（Scrumを教えるのに最適なフレームワークはScrum - Always All Ways）で紹介したTobiasのブログに出てくる５つの「やってはいけない」の４番目の項目です。
今からふりかえってみれば、メアリーのワークショップではまさにこの５箇条がしっかり守られていたように感じます。そしてその中でも、この４番目の「質問には答えてはいけない」というのは非常に強く意識されているように思いました。（意識されているというよりは、むしろ身体に染み付いて無意識の習慣になっているのかもしれません。）

Especially don't answer "How" questions

もちろん、彼女は質問も受け付けずに突き放していたというわけではないですよ。誤解を避けるために、Tobiasのブログから該当部分を抜粋しておきたいと思います。

Especially don't answer "How" questions [ref]. These are usually asked as challenges, and attempting to answer them will likely lead to positioning and entrenchment. Instead of offering answers, whether from intuition or experience, seek instead a better question—there is almost always one or more of those lurking below the surface. A classic example is the "How do we manage bugs in Scrum?" question. This is not a useful question, a better one being "Why do we have bugs?" [ref].
Top 5 Scrum Workshop Dont's

ここでのポイントは、

特に"How"を問う質問には答えるな。
代わりに、よりよい質問を探しなさい。

ということですね。
古典的な例として挙がっているのは、「Scrumではバグをどう管理するのか？」という問いに答えるのではなく「なぜバグが発生するのか？」と問いかけなさい、というやつです。

信念と自信に裏付けられた質問

こういう話をすると、たまに「質問をはぐらかしている」とか「問題をすりかえている」と思う人もいるかもしれませんが、今回のメアリーの話で少しもそういう印象にはならなかったのは、やはり彼女の言葉が信念と自信に裏付けられていて、彼女が質問を言い換えてくれることで我々自身が本当に考えて取り組むべき課題に目を向けさせてくれたからだと思います。
懇親会の席でとある参加者の質問を通訳してメアリーに投げかけたのですが、そこへのメアリーの回答を聞いたその方がtwitterで「涙が出てきた」「魂が震えた」と書かれていたのが印象的でした。

2012-04-10

Scrumを教えるのに最適なフレームワークはScrum

Agile Learning Requirements Development

Tobias Mayer氏が、「スクラムのワークショップにおける５つの『やってはいけない』」みたいなブログ・エントリを書いています。せっかくなので、その５つを見出しのみ抜粋してみると、

Don't plan the whole workshop.

Don't ask questions you already know the answer to.

Don't play games with predefined outcomes.

Don't answer questions.

Don't talk about yourself.

Top 5 Scrum Workshop Dont's

それぞれの内容については原文を見てくださいね。

Scrumを教えるためのフレームワーク

これらの５つのポイントはそれぞれ重要な示唆を含んでいるのですが、私自身は、この記事の中で最も重要なのは、"Scrumを教えるのに最適なフレームワークはScrumである"という点ではないかと思っています。

There is a great framework for teaching people about Scrum. It is called Scrum.
Top 5 Scrum Workshop Dont's

その根底にあるのは、Scrum（に限らずアジャイル開発全般的にそうだと思うのですが）が、複雑適応系（Complex Adaptive System）を扱うものであるということ。それを忘れると、本来ワークショップの中で気づき・考えるべき「不確実性にどう対応していくのか？」ということを体験できず、参加者はチグハグな印象を受けるだけでなく、場合によってはワークショップで最も気づいてほしいことに気づかずに間違った理解をしてしまいかねません。

フレームワークとワークショップのメタな関係

同じように考えると、要求開発を教えるためには要求開発的なファシリテーションでワークショップを進めるのが適しているように思いますし、その他同じようなことはいろいろなフレームワークや方法論に対しても言えるのではないでしょうか。
実際、例えば私自身は残念ながら参加できませんでしたが、Jeff Patton氏のCSPO研修ではセッションの進行自体をユーザーストーリーマッピングの手法を使ってやったような話も聞いています。
参考： Jeff Patton氏の “情熱プロダクトオーナーシップ” に参加しました #sgt2011 #CSPO | 世界のdaipresents

本質を理解すること

これらのことは、Scrumや要求開発（およびその他世の中のフレームワークや方法論、プロセスなどなんでも）を教えるにはまずなによりも、単なる表面的な知識や具体的なプラクティスだけでなく、その本質を理解していなければならないことを示しています。そして、それをワークショップの中で体現していくこと。これはしっかりと心に留めておきたいです。

参考（関連記事）

2012-04-05

アジャイル開発に組織が興味を持ったならどうすればいいか？

Agile Learning Management

タイトルはそのままパクりです。
id:kaji_3さんが興味深いブログ記事をアップされていたので、自分だったらどう考えるだろうか？ということでコメント代わりに簡単に思うところを書いてみます。
元記事は、こちら↓
アジャイル開発に組織が興味を持ったならどうすればいいか？ - kaji_3's blog

当然のことながら、id:kaji_3さんの組織のカルチャーや業務特性など含め、コンテキストを把握していないので、一般的な話や的外れな話になってしまうかもしれませんがご容赦ください。

組織がアジャイル開発のどこに興味を持っているのか？

まず、組織が興味を持ち始めているという状況とのことですが、その後の進め方を考えるにあたっては組織がアジャイル開発のどういうところに興味を持っているのか、どんな期待を持っているのかを把握することが重要かと思います。
それを知っていれば、その期待に寄り添う形でスムーズに組織展開できるかもしれません。そしてもっと重要なことは、もしアジャイルに対して間違った考えや過剰な期待を持っているようであれば、早い段階でその「幻想」を叩いておくということです。リスクを共有し、その中で一緒に大変なチャレンジに取り組むのだという理解を深めておきたいものです。
書かれている中では、「4. 組織に対して勉強会を設けて、理解を深めてもらう。」というステップがこれに関連するかと思いますが、タイミング的にはもっと早い段階から、目的と状況に応じて継続的にやるのがいいと思います。アジャイル開発に取り組むということは、チームメンバーだけでなく組織全体のマインドセットの変革を促していくことが成功のカギとなるはずです。

順序と優先度

これはちょうど昨日の私のブログエントリ（エンタープライズ・アジリティについて考える (2) - Always All Ways）に書いたことと重なるのですが、「アジャイルの導入・展開そのものもアジャイルな方法でやる」という意識が大事なのかなと思います。言うは易し、行うは難しではありますけれども。
そしてその過程においても、状況や小さな成功体験を見える化しつつ、タイムボックスの中でふりかえりを行って状況を把握し、改善を進めていくことが大切かと思います。また、どうしても中だるみが起きてきたりもしますので、適度な緊張感を持ってリズムよく進める工夫も必要です。
あと、id:kaji_3さんが書かれている順序、優先度のあたりを見ていて気になった点としては、いわゆるプロダクトオーナーの選任と育成をどうするかという点です。

コーチをどうするか？

先日もとあるアジャイル・コーチの方とお話をしていた時に出てきたのですが、その方のところに依頼が来る典型的なパターンとして、

本や勉強会、CSM研修などで勉強して、自分たちでできると思って始める

でもやってみたらうまく行かない

助けてくださいと依頼がくる

みたいなのがあるようです。
日本の会社に限った話ではないのかもしれませんが、コーチやメンターあるいはコンサルタントにお金を払って依頼するということに対する意識があまり高くなく、予算も取りにくいというのも背景にあるのかもしれません。また、会社としても「一人20万円も払って何人かCSM研修に行かせたのだから、自分たちでなんとかできるんじゃないの？その上コーチを頼むなんて、なんのためにCSM研修に行かせたのかわからん。」というような言い分もあるのでしょう。
しかしながら、CSM研修を受けた人はわかると思いますが、2日やそこらの研修を受けただけで、現実に起こるさまざまな事象に適切に対処できるようなものではありません。自分たちで失敗を繰り返しながら学んでいくというのもアリですけれども、下手をすると「やっぱりアジャイルなんてダメじゃん！」と言われてしまいかねません。
id:kaji_3さんは、「社内にアジャイルコーチなどいるはずもなく、…」と書かれていますが、もし予算その他が許すようであれば、優秀なコーチを外部から来てもらってうまく活用することをおすすめしたいと思います。