学習するためには1度失敗してみるのが大事なんだ、という考え方がこれまで支配的だった。
たとえばエンジニア育成の観点でいうと、どうしても実務だったらソースレビューNGしてしまうから自分が書いたコードで負債化してしまうみたいな経験を得にくく、学習効果が薄くなると思うので、個人開発で負債を作ってしまう経験をやるのが良いよねということをよく話したりしていたし、これは個人的な実体験とも凄く一致するので腹落ちしていた。
これはこれで真として、逆に、成功することも学習効果があるんだということを、昨日弊社メンバーとランチしていて思った。
どういうことかというと、
たとえば僕は要求定義、要件定義の段階から関わってより良い施策にしようという考え方が染み付いていて、これはずっと自分が事業への主体性が高いからだとか、より上流から意思決定していくことが本質的な課題解決だからとか、色々理由があると思って納得していた。また、元の思想の話でいうと、要件が変だったらどんだけ実装頑張ってもその企画はポシャってしまうので、創業以来のピボットの経験などからそういう風に上流から関わることが思想として染み付いているのかなと思っていた。
ただ、成功体験という観点で考えることもできて、ここ数年間のCTO経験のなかで、自分が上流から関わった施策と、言われたとおりに作った施策で、それぞれユーザーさんから好評を頂いたとき、正直どう考えても前者のほうが嬉しかっただろうから、それを通して、自分がより嬉しくなるような選択肢を取りに行っているのではないか、と思うこともできた。
教師あり学習とかの文脈では、正しい判定をするものと間違った判定をするものそれぞれ学習させることで精度を上げるのは当たり前の話だし、そう思うと人間も成功体験によって行動変容が起きることは失敗経験によって起きるそれと同等以上あってもおかしくない。
いや、なんというか、表題の通り「学習には失敗だけじゃなくて成功体験も必要」っていう文言にしちゃえば、そりゃそうだろうという感じなんだけれども、ついつい実務では最終的にメンバーがやることのセーフティネットは自分だぜみたいなスタンスだし、そもそもエンジニアという仕事自体がどちらかというと大成功しにいくより大失敗を防ぐ寄りの職能であることから、仕事に寄せていくと失敗体験を主にした学習体験をイメージしがちなのかもしれないと思いました。
ということで、まだ解像度高くないけれども、成功体験をメンバー自身の判断を介した状態で起こさせる、そういった仕掛けとか工夫みたいなものをぼちぼち考えてみたいなーと思ったランチタイムでした。