安全な砂場で大量に良い失敗をしてみせる
私は、ソフトウェアエンジニアリングを他者に伝授する際に、ドキュメントやマニュアルを用意したり、あるいは手取り足取り教えるのは、あまり良くないアプローチかもしれないと考えるようになった
時間が限られている場合はなおさらだが、時間が充分にある場合でもあまり良くないかもしれない
では他にどのようなアプローチが考えられるかというと、ひとつは、このページのタイトルのように、
まず、安全な砂場となる環境を作って
そこで、自分自身が大量に試行錯誤=良い失敗(と成功)をしてみせる
次に、相手にも大量に試行錯誤=良い失敗(と成功)を経験させる
のが良いのではないかと考えている
安全な砂場という考え方は、ソフトウェアエンジニアリングの実務のなかで、必然的に実現されてきたものだ
ソフトウェアテストは、ソフトウェアを誤って変更した際に、破壊してしまったことを検知できる、ということを実現した
バージョン管理システムは、ソフトウェアを誤って変更して破壊してしまっても、確実に元に戻せる、ということを実現した
システム仮想化やDockerは、OSを誤って変更して破壊してしまっても、確実に元に戻せる、ということを実現した
ソフトウェア分野に限らず、エンジニアリング(工学)においては、損失が最小に抑えられていて、それでいて得られる情報が最大となるような、効率的・効果的な失敗をすることは、とても重要である
これを良い失敗と呼ぶ
良い失敗
失敗が起きた際の損失が最小化されている
信頼性工学
影響範囲が限定されている
完全ではなくても失敗前の状態に戻せる
失敗から得られる情報が最大化されている
情報工学、情報理論
情報のノイズが最小化されている
仮説が明確で、反証可能である
発生条件がコントロールされている
平均情報量 / 情報エントロピー / シャノンのエントロピー
失敗から得た情報を元に失敗の再発を防止し、さらに改善できる
制御工学
フィードバック
参考:失敗学
安全な砂場は、実務に限らず、ソフトウェアエンジニアリングの学習過程においても、とても重要だ
なぜなら、一度、安全な砂場ができあがれば、安心して、大量に試行錯誤することが可能となるからだ
試行錯誤とは、失敗のみではなく、もっと単純な弄くりまわしをも含む
つまり、「ここをこうしたらこうなるはずだ」「ここをこうしてもこうならなかった」という、仮説-検証サイクルを大量に実行し、結果を確認するという過程を、試行錯誤と呼んでいる
学習とは本質的に、この仮説-検証サイクルを、大量に経験することでしかないと考えている
その砂場が本当に安全であるということ、あなたは失敗すればするほど良いということを、信じてもらう必要がある
そのためにまず、自分自身で失敗してみせて、それでも何も問題ない、ということをやってみせることが、重要である
さらに、あなたがそのとき一度だけ成功ができることよりも、むしろあなたが繰り返し良い失敗ができるようになるほうが価値がある、ということを理解させることが、重要である
なぜなら、ドキュメントやマニュアルに載っていない状況で、手取り足取り教えてくれる人もいない時に、その人ができないと困るのは、良い失敗のはずだからである
時間が極めて限られている場合、具体的には以下のような時間配分を提案する
安全な砂場の構築(二人分)に3分の1
無限に破壊して元に戻せる状況を事前に用意できている場合、以下に時間を割く
自分が試行錯誤しまくるのに3分の1
相手に試行錯誤させまくるのに3分の1