去年ぐらいから、学習を日常の開発に取り込むことについて考えている。学習は何か特別なことがあるときにだけ実行するものではなく、開発チームの中に常にあるべきものだという気がしているから。だけど、それを周りの色んな考えを持った人たちに伝えられるほどには整理できていない。ので考えている。
そんなときにRSGT2019に参加したのだけど、今落ち着いて思い返してみればChrisの基調講演がまさにそれだった。ので彼の「Learning to Experiment」を思い出しつつ、この辺を参考にしたりしながら自分の中で整理をすることにした。
## 変化のための実験
変化してなくてもしばらくはうまくいってるように見えるけど、気づいたときにはもう手遅れ。世界は変わり続けてるし、競合は変化に適応し続けてるから。
でも、緊急事態に陥ったときには、これまでのやり方を変えてでも対応しなければならないので、変化することができる。
緊急事態じゃなくてもそういう風に変化できると良さそう。それを可能にする方法としての「実験」。そして、競争のためにはサイクルタイムがアドバンテージになる。
## 実験のためにやること
### ラーニングセッション
学習のための時間が必要。そうじゃないと、チームは今持っている知識の中だけで仕事をしてしまうことになる。Chrisのチームは、今は毎朝1時間と金曜日は午後にも2時間の計7時間を学習のために割り当てていて、過去にはTDDやCIなどをチームとして学習して導入したと言っていたと思う。
### レトロスペクティブ
レトロスペクティブ（振り返り）は、１つだけのアクションアイテムを持つ。実験をして振り返って、次のアクションを決める。そんな振り返りを継続して行う。
## 実験のためのポイント
### 安全性
例えば
- 実験を提案することができるか？
- 実験のための時間を取ることができるか？
- 批判を伝えることができるか？
- 批判を個人に対する攻撃と見なさずに受け止めることができるか？
### 失敗
失敗するリスクが高いことにも挑戦する。もし実験に全く失敗していないとしたら、それは自己満足に陥っている。
### 良くなかったプラクティスをやめること
始めるのは簡単だけど、やめるのは難しい。良くなかったプラクティスをやめることは大切。
## 実験のために必要なもの
とても高い目標（Lofty Goals）をチームで作って、それをチームの方向性にする。この目標自体も継続して改善する。Chrisのチームは今の時点ではこういうゴール：
- どんな交流をするか？
- 親切・思いやり・敬意
- 弱みを見せる・信頼する・感謝を示す
- 心理的安全
- どういうコードを書くか？
- コードと本番環境の間に人が入らないこと
- クリーンコード
- ザロボーグス（ゼロバグをもじったもの。バグトラッカーにバグがない状態を目指すけど、それでバグがなくなったというわけではなくて、まだ見つかってないバグはあるから）
- どういうビジネスをするか？
- 価値のある動くソフトウェアを毎日届ける
- 誰もがいつでも長期休暇を取ることができる：ゼロサイロ
- 部署内の効果的なコミュニケーション
- どうやって変化するか？
- Lofty Goalsやプラクティスを継続して改善する
- たくさん実験する
- ソフトウェアコミュニティを育てる
## 変化のために気をつけること
- 他の会社のことを羨ましがらない
- 一気に変えない
- チームで実験をして一歩ずつ改善するのを継続する
## 実験を妨げるもの
見積もり。
見積もりは、新しいアイデアを抑制してしまう。
## まとめ
ラーニングセッションとレトロスペクティブを始めて、実験することを始めよう。
## ということで
自分を振り返ってみると、見積もり、というか長めの計画や約束がチームを「（計画を立てたときではなく）現在の」ベストな選択肢から遠ざけてしまっているのは確かにそうだなぁと思う。それから、トラブルの対応をしているときは、確かに全員がそこに取り組んで全員がその場で決断をしながら対応をしてるよなぁとも思う。
チームが、自分たちが今できるベストな動きを自分たちで考えて実行している状況というのは、目指す形だとは思いつつ、さて、今のチームにできる1つ目のアクションとしての実験は何だろうか？と考えてみたりしている。
ひとつ実験をしてみてから、Lofty Goalを全員で話し合ってみようかな。それから、学習の日常化についてチームに聞いてみたいと思う。そろそろ一旦スクラムのことを忘れてみてもいいかなと思い始めている。
