XP祭り2012 〜ソーシャルチェンジ！〜に行ってきたメモ

金曜日まではXP祭り2012 〜ソーシャルチェンジ！〜に参加するか思いあぐねていたが、期待とずれていたら帰ってくればいいさ、と行くことに。行ってよかった。知の共有として得られたお土産がいくつかあったので、メモと合わせて残しておこう。

1.オープニング
“XP仙人であり、XP祭り主席実行委員でもある、小井土さん、福井さんによる毎年恒例のトークライブ(まんざい)”...恒例なんだ。板についていましたが。それと平鍋さんのビデオレター。例のライトウイングとレフトウイングのステマでしたね。

ところで、XPのカードが配られた。これを名刺の後ろに印刷するとXPっぽい人になれるらしいアヤシイカード。

まんざいの様子。

2.A-2 アジャイルコーチ・ラウンドテーブル
第一線のコーチ陣がアヤシイコンサルタントとお堅いSIerに分かれて会場の参加者とトーク。
こんな感じで始まった。

Q1　業界的な問題は？
A1　サービスを提供する企業はビジネスにアジャイルを導入することに積極的だが、SIer古いまま。企業の中でウォーターフォールで成功体験を持っている中堅層の考えが古い。
　　XP＝エンジニアリングだ。

Q2　企業の中から変えたいが、変えられないとき
A2　企業の中から変えられないなら、外から変える(外的な圧力を使えということ)。

Q3　会社でアジャイルやりたいがリジェクトされ、やる気成分がなくなる。
A3　コミュニティに参加すればよい。

Q4　アジャイルを試みたいと上司に言っても「アジャイルはスゴイSEがいないとできないんでしょ？」といわれる
A4　ペアプログラミングを組ませて、習熟度を上げる。いきなり顧客の開発で試さない。開発ツールなどリカバリできることで試す。
　　いきなり、大規模開発に適用するのはダメ、絶対。最初は、必ず成功させることが必要。
　　＃成功しないと二度とトライできないからね。
　　アジャイルはSEをエンジニアとして扱う。(ウォーターフォールのように)駒として扱わない。
　　優秀なSEでも向き不向きある。実際、優秀なエンジニアに退場してもらったことがある。
　　客観的なデータと出す。業界の導入率などとあわせて、“情”で訴える。

Q5　アジャイルを導入しても上手くいかない
A5　危機感がないチームは上手くいかない。
　　火が付かないと動かない。
　　能力より、どうしようか考えている人の方が良い。能力があっても、先を考えていない人はどうなっちゃうんだろう、と思う。

Q6　ペアプロを導入したいと上司に訴えてもリジェクトされる
A6　相手の価値観を聴く。
　　ラポールを使う。
　　瞬きのタイミングに合わせて相打ちを入れる。
　　上司にとって重要なことは何か、と聴くとその人の一番大事なことが聴ける。
　　何かするときには、二人以上で。一人では心が折れる。
　　＃フォロワーが大事、ってやつだね。

Q7　アジャイルを上手にやっている状態とは
A7　スクラムマスターを集めて、毎週ワークショップをしている。

Q8　ペアプロを導入したいがチームにそんな工数はないとリジェクトされる
A8　機会はいつでもある。トラブルのとき、スッと横に座り(ペアプロを)一緒にやってしまうことで成功体験を作る。
　　スプリント計画レビューのときに、チームメンバが助け合うことを考える。その工数を組み込む。
　　
　　助け合うことが目的であって、ペアプロはツール。
　　＃手段と目的が逆転している。

Q9　社内の仕組みが重いとき
A9　社内の品質と顧客の品質は違う。
　　品質保証とネゴれ。
　　社内ネットワークを駆使する。

Q10　企業文化を生かしてアジャイルを導入しなくてはいけなくなった
A10　(物事を導くときにぶつかるのは)人。直接話すしかない。壁と思っているものは自分で作っている。

Q11　設計力を向上させたい
A11　目的を持った設計(とはリファクタリング)できる勉強が必要だ。
　　勉強する気がない人が居る。
　　“やらない理由”＝“不安”!=“出来ると変わる”＝“オレでもわかる”　
　　テストを書く文化が大事。テストを書くために知らなければならないことがたくさんあるから勉強する。
　　安定は、チームの衰退のはじまり。
　　ケントベックとペアプロ＝１、その弟子とペアプロ＝２...
　　お膳立てをする。
　　＃スクラムマスターはサーバントだし。
　　社内のお友達から設計のスゴイ人を紹介をしてもらう。

Q12　チームのアジャイルを続けていくために
A12　(スクラムマスターが)離れるタイミングが早すぎる。離れるタイミングを見込みして準備する。それができなければ、大変だろうけど両方面倒を見る。
　　チーム全員がスクラムマスターになるように育てる。
　　スクラムマスター会のコミュニティを作る。今週、何を変えたかを聞く。一人が話すとき他のスクラムマスターはコーチとしてdisる。
　　先駆者はあとから来る人に見せる。

Q13　失敗することに対する企業の寛容
A13　上司には責任だけを取ってもらう。アジャイルを導入すると決めたら結果を出す。必死でやる。一つ目は必ず成功させるし、成功する確率が高い。必死だから。2つ目以降はあぶない。
　　顧客のプロジェクトでアジャイルを初めて導入することは間違い。オカシイ。練習してから。
　　ファシリテーション＝ロジック×納得度

3.D-3 ワークショップで学ぶScrumの基本【ワークショップ】
スクラム道のワークショップ。講師はいつものメンバ。100円カンパ制。

導入でのスクラムの解説
　スクラムは問題を解決しない。
　優先順位を付ける。優先度ではない。
　4つの会議のうち、バックロググルーミング(次スプリントのSBIの準備)は、最初はやらなくてもそのうち必要になる。
　バーンダウンチャートに、他の指標も書き込むことが多い。最終退室時間、追加要件、コミット数...。

ワークショップは、西早稲田キャンパスを潰して、動物園にするという想定外のテーマ。

5人で1グループをつくり、最初にプロダクトオーナを決める。西早稲田キャンパスを潰して、動物園にするというお題。ターゲットとする顧客のセグメントをグループで設定して、ストーリを作り、優先順位をつける。人は頭の中でストーリシーンを考えるが、それを言葉にするとものすごく情報量が落ちる。
その結果、思ったより『不明瞭』な状態で表現される。
＃だから気軽にインタビュー出来る関係にならないといけない。

ストーリを見たグループメンバは、その文字から情報を拾うのでギャップがでる。
＃ストーリポイントで差が出るのはこれのせい。

ここで、プロダクトオーナだけ席替え！というトラップが。この席替えで、サービスを作りたいプロダクトオーナとそれを実装する開発チームとの情報の較差を生じさせる。プロダクトオーナは、そのプロダクトの全体像、そのプロダクトの優先順位、具体的なスプリントバックログアイテムの仕様を開発チームに
になっているかを話すけど、時間が制限されるから最初のスプリントバックログを決めたときのチームのように情報の連携ができない。これを解消させるには、開発チームからそれをしなければならいけれど、慣れていないとそれができない。

少なからずはインタビューされるので、より具体的にプロダクトオーナは話してくれる。動物園を作る時間は限られているから、作る動物の数も無制限とはいかない。トランプを使って、プランニングポーカーでストーリポイントを決めていくが、人それぞれがスプリントバックログアイテムを考えるとき、ばらけるものだ。

折り紙には、折り方に難易度の★印がついており、易しいものをスプリントバックログアイテムの要求事項から選択しても、その★で想定した時間通りに作れない。2−3倍かかる。

折り紙難しい。

最後にプロダクトオーナ全員がアピールするが、フィーチャーを説明してしまうと時間切れに。これ、絶対、エレベータピッチをつかうことを暗黙で要求していたに違いない。

4.C-4 マチコ先生の白熱風教室 in Waseda.univ 〜45分で分かるBABOK：序章〜【ディスカッション】
遅れて入室したが、開始に間に合うも、BABOKは言葉だけしか知らないせいなのか、ワークショップの主旨とディスカッションの運営が理解できなかった。選択ミスったきがする。でもチートシートもらったので、少し、BABOKわかるかも。

昼？のゲリラLTでの説明は期待できたんだけど...。