失敗から学ぶために本当に必要な"失敗"とは何なのか

失敗から学ぶ、つまり「経験をもとに得た知識や教訓を自身に定着させる」ためには、失敗を経験することが必要だし、それをふりかえることが必要だろう。

ふりかえりの具体的な方法論については本で学んだり実践したりして知見を溜めてきたけれど、どんな経験をふりかえれば良いのかについては考えたことがまだなかった。なので今日ここでチャレンジしてみる。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

ちなみにふりかえりの方法論はこの本にびっしりと載っている。チームのふりかえりをレベルアップさせるにはもってこいの一冊だと思う。

＊ ＊ ＊

さて、学びの獲得に経験がどんな影響を及ぼすのかについては、コルブの経験学習理論が参考になりそうだ。

経験学習理論とは、新たな「具体的な経験」をした際に自分の中で意味付け・価値付けといった「抽象的な概念化」をする、という学習サイクルを指す。

そしてこの具体的経験⇔抽象的概念の変換に必要なことが「内省的なふりかえり」と「能動的な実験」だ。

経験→ふりかえり→概念化→実験→... のサイクルを回しながら知識の獲得・拡張をしていくことを経験学習と表現している。

この理論は自分の体感にもすごく近い。
とは言え実際のふりかえりの場では、上図のようにふりかえりと実験が明確に分離されることはなく、実験のための計画もふりかえりの中で行うだろうし、実験のふりかえりを行う(上図の学習サイクルの中で小さな学習サイクルが生まれネストしていく)こともある。それでも、学びの根本的な構造はこの理論に概ね賛成できる。

＊ ＊ ＊

では、この経験学習理論のサイクルの起点にもなっている「具体的な経験」とは誰のどんな経験だろうか。

誰の経験か

1. 自分自身の経験
2. 自分以外のチームメンバーの経験

身の回りにあるものだとこんなところ。
自身の経験をふりかえるのは簡単だ。何かを経験(失敗)したときは、その場その場でふりかえりをし行動を改善しながら経過を見ていくような即興的なアプローチを取れる。また何らかの期待結果を見定めた上で、そこに至る選択肢を計画的に踏んでいくアプローチも取れる。
注意すべきことは結果や判断を自分の都合の良いように解釈しがちなこと、自分では経験しきれない可能性があること、あたりだろうか。体験から得るものは多いが、もしその中に「正解」があるのだとしたらそこに最速でたどり着けるとは限らない、それが自分自身の体験から学ぶということになりそうだ。

対して、ふりかえり対象がチームメンバーの経験のような身近なものであれば、「経験を客観的に観測する」ことになる。
分かりやすい原因があったり、分かりやすい罰を受けたりした経験であれば、自ら経験せずとも学び取りやすい。またリスクの高い失敗は何度も経験するわけにはいかないので、身近に経験している人がいれば貴重な事例となるだろう。
ただし、自分で経験していないだけに危機感や切実感が不足しふりかえりの濃度が薄まったり、その時何かを学び取ったとしても記憶として定着しなかったりといったデメリットも考えられる。

大事なことは、どちらの経験からも学習でき、経験の内容によって使い分けられるということ。チームの学習機会を設計してきた先人たちは、この2つ(もしくは僕が考慮しきれていない第3の選択肢)を上手く利用しているのだろう。

どんな経験か

誰しもが毎日何かを経験しているけれど、その中の何に焦点を当ててふりかえれば良いのかは難しい問題だ。人によって問題の感じ方は違うし、解像度の差もある。たとえばミーティングに1分遅れたことを失敗(問題)と捉える人もいれば、気にも留めない人もいる。

ふりかえりやすい経験の一つは「いつもと違うこと」だ。
特にいつもと同じように振る舞ったつもりなのにいつもと違う結果が出た場合は、それが失敗であっても成功であってもふりかえりやすい題材になる。原因をふりかえることはもちろんだが、それが回避できない問題である場合は「今後似た問題が起きたときにどう行動するのが最善か」に焦点を当てると良い。そうすることで「運が悪かった」「自分たちにはどうにも出来なかった」から一歩先に進めると思う。

もうひとつは「これまでに何度も繰り返していること」。
当たり前のように繰り返していることは、手癖になっている行動かもしれない。もしくは、最適化し定着した行動なのかもしれない。どちらかは分からないので定期的に棚卸しして見つめ直すことに価値が出てくる。
よくあるケースは、最適化した行動を繰り返しているうちに変な手癖がついてしまって、最適化した当時の意図とズレが出てきてしまっている状態だ。定例ミーティングの形骸化などがよく当てはまる。
他にも、最適化した当初と同じ行動をきちんと繰り返しているものの、環境の変化によってその行動が最適ではなくなってしまうパターンもある。育成目的でコードレビュー始めたところ、チームの技術レベルが上がっていき、育成目的のレビューではもの足りなくなってしまう症状などが考えられる。

他にもふりかえりたい経験が山のようにある場合はどこにウェイトを置くかを考えておくといいだろうし、ウエイトの認識がチーム内で揃っていてば尚良いはずだ。

＊ ＊ ＊

抽象論ばかりになってしまって考えがまとまらなくなってきたので今日はここまで。

一応現時点での思うところを整理すると

・自分の経験とチームメンバーの経験の両方から学びたい
・学びの質が違うので両方を活かして学び分けていきたい
・ふりかえる経験が見つからないときは「いつもと違うこと」と「何度も繰り返していること」に目を向けたい
・ふりかえる経験で溢れているときは、何を重点的にふりかえるかの優先順位を考えたい

こんなところだ。
いつかもう少し体系的に整理したいのと、もう少し人の役に立つ形にしたい。