アジャイル界隈研修の感想まとめ

自社会場で開催したりして、それなりの回数を参加したり聴講したりした経験があるので、なんとなくまとめていきます。

Jeff Patton, 認定スクラムプロダクトオーナー研修

VOYAGE GROUP会場で4-5回くらいは開催してる。会場係としてお手伝いしつつ、内容をなんとなく聞いている。

印象に残ってるのは、プロダクトオーナーは開発者に対して、いろんな手段を使って実現したいもののことを伝えるのが仕事だということ。ドキュメントだけ書きゃいいってもんじゃないし、かと言って会話すりゃいいってわけじゃない。やり方はそれぞれの関係性によるが、とにかく、伝えるというのが大事らしいぞっていう。

研修の進め方も面白くて、毎回ちょっとずつ違いがあって、改善してるんだなーっていう印象がある。

手法の一例として彼はユーザストーリーマッピングというものを提唱していて、そのトレーニングもある。いろんな人に感想を聞くと、手法自体は賛否ある。著書「ユーザストーリーマッピング」がちょっと前に日本語化されてたらしいので、興味のある方はどうぞ。

Jim Coplien, 認定スクラムマスタ研修

こちらもたまに、会場を提供している。参加者になったことはない。

ワークショップが多く、わりとみなさん楽しんでいるっぽい。発言はちょっと過激で、JIRAはダメだ、TDDなんてムダだ、みたいなことで盛り上がるのは毎回のことなのであった。記憶に残る発言は “It depends on your team!” 。

質疑の中で「開発が上手く進まないとき、スクラムマスタとしてどうする?」みたいな議論があり、参加者の1人が「開発チームを入れかえる」と答えたが、対して氏曰く、「クビになるのは大抵、スクラムマスタの方だよ」というのが面白かった。スクラムマスタっていう新しい存在に対し、その役割と責任が気になる人は多いらしい(個人的にはくだらないと思う)。

Jim Coplien, 組織パターン研修

題目は「組織パターンを用いてスクラムをチューニングする」みたいなのがついてたような気がする(調べてない)。Cope先生の著書「組織パターン」について解説しつつワークショップで議論したりする内容。感想は咳さんのブログにもあるので、そちらもご参考にしてください。ちなみに、会場からのツッコミ、会場からの質問というのは両方とも私です!

この回では、自分たちの組織を評価するときに、客観的に見れるようになった気がする。それまでは「改善の余地があるならやりゃいいじゃん、なんでやらねーんだよ」くらいにしか思ってなかったんだけど(ひどいな…)、状況=contextは重要らしいぞっていうことに注視できるきっかけになった。

またこれは、パターン・ランゲージについて理解を深める回になった。それぞれのパターンは、まぁ、読めばいいんじゃないかな…。個々のパターンよりも、パターンをつなげた遷移図みたいなやつから入るのが、個人的にはおすすめである。

「“Community Of Trust” が出発点だよ」みたいなことは書籍にも書いてあり、そこ難しいよねーって参加者同士が愚痴ってたのが面白かった。弊チームではわりと上手くいってるのかなって思った次第です。

角 征典, レゴスクラム研修

数々の訳書で有名な角さんの研修である。英文に細かく散りばめられた映画、特にスターウォーズのネタをちゃんと拾えることに関しては、おそらく彼以外にはいないだろう。たまに募集している翻訳本のレビューも面白いので、機会があれば参加してみることをおすすめする。

研修の内容は、それほど長くはない講義と、ワークショップ。みんな、レゴで何かを作るのが大好きなので、大抵、最初は凝ったものを作ろうとがんばる。だがしかし、思ったようには完成しない。完成度に調整が入る。求めているいい感じのものが作れるようになる。…みたいな流れが体験できる、貴重な研修である。作りすぎのムダは、みなさん覚えがないとは言わせない。

“Complex vs Complicated” の話は角研修では定番で、個人的には「組織目標をブレイクダウンして個人目標にする」みたいな手法に対する反論として、たまに使わせていただいている。要素に分割できるとは限んないじゃん!

Paolo Perrotta, アジャイルコーチへの道

メタプログラミングRuby」著者による、アジャイルコーチについての研修。ここでいうアジャイルコーチは、スクラムマスタみたいな存在だと思えば大丈夫そう。ワークショップと質疑が特に多い研修でもあった。

研修の冒頭、「みなさんのアジャイルのイメージを図にしてみよう」みたいなワークがあって、ユーザに提供する価値を図に入れたグループは一つしかなく、それが私が参加したグループではなかったが正直悔しかった。その後、「価値を提供するのは大事だし、そこに向かっているかを確認するのはアジャイルコーチの重要な役割なんだ」みたいなことが議論されていたのが良かった。「組織内部への価値アピールに走ってしまうことはよくあって、そうなったときは軌道を修正するんだ」みたいな話も。チームビルディングや開発プロセスだけを頑張りすぎちゃうのは、アジャイルピープルがたまに批判される箇所であるので、各位、忘れないようにしたほうがいいと思う。

アジャイルコーチにもいろいろあって、コーチやティーチャーもあるし、課題発見もあるし、コラボレーションの推進(よーするに人と人とをつなぐ的な)ものもあるという話の中で、私の立ち位置はこの辺だなーと認識できたのも収穫だった。

Jurgen Appelo, Management3.0

同名書籍(日本語未訳)や「How to Change the World」の著者。トップダウンマネジメントは過去のもの、組織をコミュニティとしていい感じにしていく、みたいな内容の解説である。

冒頭にアイスブレイクとして、自己紹介と研修に参加した理由をグループで話し合う、みたいなことをやった。私のモチベーションは「マネジメントなんて大抵クソなので、そいつらに対抗するためのネタを持つ」であることを認識したのであった。

内容はいろいろあったが、印象に残ったのは「KPIは、関心をもつ人が収集すべきである」。

例えば、ソフトウェア資産計上のために、開発者がチケットに書けた工数をトラッキングしたいという話があったとする。だがしかし、我々はそんな純粋に時間を区切れるものでもない。そんな面倒なことはしたくないし、しゃーなしで、適当に時間をでっち上げることが多い(と友達から聞いた)。この状況に対して、「工数に感心があるのはファイナンス担当だから、開発者を巻き込まずに、お前らでまとめるべきだ」と要求したり、「開発者を巻き込みたかったら、メリットがあり関心を持つべきだということを説得しろ」みたいな議論をしやすくなった。

かくして、武器を持つという目的は達成したのであった。

Mary Lynn Manns, Fearless Change

同名書籍の内容。パターン言語については、上述の組織パターン研修でなれることができた後だったので、それ以外のことで。

重要なパターンは「エバンジェリスト」であって、何かを変えるという場面では、それをすると良くなると確信している人が中心になる必要があるらしい。

組織変革というと大げさだが、変革は身近に存在している。例えば、ソースコードのコミットも変革である。あなたは、そのコミットにより状況が良くなると確信している?この答えがNOであれば、おそらく、マージすべきではない。There is no try.

まとめのまとめ

なんとなく思い出せる範囲で、だらだらとまとめてみました。いかがだったでしょうか?

このような研修が気になるかたは、↓などをチェックしてみてください(いつもお世話になっています!)。

アジャイル界隈の研修は参加者同士の議論が大事だったりして、認定の看板がついていないほうが良い議論ができたりします。なので、各位狙うといいと思います。会社的な予算はつきにくいけどね!