Regional Scrum Gathering® Tokyo 2014 2日目基調講演 by Jutta Eckstein氏 #sgt2014
二日目の基調講演は、Jutta Eckstein（ユッタ・エクスタイン）さんによる、「組織にアジリティを取り入れる – どうすればアジャイルになれる？」でした。
「アジリティを取り入れる」というタイトルではありましたが、アジャイルはもちろん、組織内に何か新しい事を取り入れる際に、どのようにしたらいいか、というお話で、非常に参考になりました。
私は現在、チーム内でのTDDの普及率を高めたいと考えており、そのためのアプローチとして、非常に参考になるお話が聞けました。
「変化」があるときの人の心の動き
何かが変化する際、どのような心理的変化が人にあるか、ということについて、著名な2つのモデルが有るそうです。
一つが、Elisabeth Kübler-Rossによるもので、もうひとつが、Virginia Satirによるものとのことです。
どちらも、パワーポイント2010（多分、「リボン」のことだと思う）を例に説明されていました。
※この辺までは英語で聞いてたんだけど、「難しくなってきた」＆「これは聞き逃しちゃいけない話だ」と判断したので、このへんで諦めて、翻訳機装着。
Elisabeth Kübler-Rossのモデル
- 新しいパワポが発売される。
「何このUI、使いたくねー。なるべく古いバージョンで粘ってやる」 - 「仕方ない、そろそろ最新の使うか…」
- 慣れたのでなんとも思わなくなる。
Virginia Satirのモデル
- 快適な状態。「パワポ2003使いやすくて好き！」
- カオス。2010を使ってみる。「新しいUI、使いやすくていい！」という時と、「なんでこんな使いにくいUIにしたんや！ 元の出せ！」という時がある。
- 「あー ここを変えたのはこういう意図が… 確かに使いやすい。」と腑に落ちる
- Integration & Practice. 新しいバージョンを練習して修得する。
大事なことは、誰かが組織に新しい手法（アジャイルとかね！）を持ち込もうとした場合、他の人にはこうした変化が起こっていることを理解することだそうです。
カオス期にいるような人も中にはいるので、きちんとそれをわかりましょうと。
さらに、こうした変化は一度に一つだけ起こるわけではなく、社内に同時に何本も走っているもので、周囲の人達はそういった変化を、同時にいくつも受け入れているのだということでした。
変化を導入する方法
そういうわけで、「変化をもたらす」ことはとても大変なのですが、
効果的なアプローチ手順が紹介されていました。
- Preparation （今から導入したいことを説明する）
- Retrospective （これまでの自分たちを振り返る）
- Readiness/Enabling Workshop
- (Customized) Training
- Monitoring / Coaching
- Sustaining Change
- Leassons Learned
2. と 3. は、チームレベルならこの順、部門レベルくらいだと逆のほうがいいかも…？とのことでした。
この中でも特に、おお！と思ったものをご紹介させていただきます。
Readiness/Enabling Workshop
「今から導入しようとしているもの」を以下の4つに分類するそうです。
- 既に行われていること
名前が違うだけで導入するまでもなくやっていることがあるかも。
例えばScrumを始めようとするときに「デイリースクラム」って名前ではやってないけど、オレ達もともと朝礼はやってるね。という感じ。 - 導入が簡単そうなこと
- 導入が難しそうなこと
- 会社の文化的に、どうしても導入できないこと
また、3, 4については、どうして導入できないのか、何が障害なのかということを洗い出すことも大事だそうです。
私達のプロセスにTDDを導入する場合であれば、「既に行われていること」は、「テストコードを書くこと」になりそうです。
（順番はおいておいて、テストコードを書くこと自体はされているので）
(Customized) Training
実際に新しいことを導入することが決まったあとは、練習することになります。
ただしここで陥りやすい点として、練習用の課題を設定して、それで練習すること。
それでは実際に仕事で導入しようとした時に、「あれ、練習と違う」「この場合はどうやるんだろう？」となってしまうとのこと。
そうではなく、実際の課題に合わせた、「Customized」されたTrainingを実施する必要があるとのことでした。
3つの役割
順番が前後しますが、新しいことを導入するにあたって、3人の協力が不可欠、という話がありました。
- Passinate change agent
→ 変えようというパッションを持っている人。この人がいなくては始まらない。 - Project Leader
→ プロジェクトのリーダー。かつ、管理職とも関係が築ける人。 - Architect / Technical leader
→ チームのプロダクト、技術に最も詳しい人。アジャイル（導入しようとしているもの）に詳しい必要は必ずしもない。
なるほど、と思う反面、この3つ全部、ないしは2つを誰か一人が兼任してしまうことが、実際の現場ではあるのではないかと感じました。
テクニカルリードが新しい手法を持ってきたりとか。
そこで、そういった場合、一人に負担がかかるけどどうすればいい？ という質問をさせてもらいました。
すると、
「上記の意図は、普通はこういったロールの人（プロジェクトリーダやアーキテクト）が組織内にいるものなので、その人達をどう巻き込んでいくかが重要である、ということ。」
「一方、一人が兼任しなければならないケースの場合、はじめはそれでもいいと思う。まずはやってみることが大切。
ただし、仲間はいた方がいい。」
「ちなみに、時間がないからできない！と言ってる人は、何かに余計な時間を使ってるはず。
例えばテストコードを書かずにコーディングしてるからデバッグに時間がかかってません？
そういうのを見つけてあげましょう」
という回答を頂きました。
セッションが終わってからもう一度思い返してみると、自分のチームでは、上司も、技術力がある人も、非常に協力的で（そして自分じゃなくて）、だからこそうまくいってるんだなぁ、ありがたいことだなぁ と思いました。
ということで、なにか新しいことを導入するときのアプローチの、具体的なヒントを貰うことができました。
是非トライしてみたいと思います。
