失敗と創造性とプログラマー

仕事で失敗をするということは、損失を出すということです。プログラマーに限った話だと、必要でない機能を実装したり、バグ を生み出したりすることも、「失敗」に入ります。

失敗は、一般的に、避けなければならないものと考えられています。しかし、Ken RobinsonさんのTEDトーク、『学校教育は創造性を殺してしまっている』でも言われているように、失敗を恐れていると、創造性が失われてしまいます。プログラマーが失敗を恐れ、創造性を失うと、どうなってしまうのでしょうか。

ソフトウェアは、とても柔軟なものです。ある目的を達成するのに、10人のプログラマーがコードを書いたとすれば、10通りの、全く異なるコードが生まれるでしょう。全てのコードが正しく動作したとしても、あるコードは他より効率的で、あるコードは他より短期間で仕上がり、あるコードは他よりきれいかもしれません。

その柔軟さゆえに、それぞれの問題に対する効果的な解決策を導き出すには、創造性が必要になります。また、その解決策をコードとして形にする場合にも、コードをきちんとデザインするために、創造性が必要になります。きちんとデザインされていないコードは、難解で、変更をするのが困難になり、維持費が高くなってしまいます。つまり、プログラマーが創造性を失うと、問題に対する効果的な解決策が導き出されなくなる上に、維持費の高いコードが生まれてしまいます。

このように、創造性は大切ですが、営利団体として、失敗をしない、つまり損失を出さないことも大切です。この二つを両立させるためには、どうすればいいのでしょうか。

同じ失敗でも、発見が遅れれば遅れるほど、失敗に失敗を重ねたり、失敗の取り返し方が不鮮明になったりして、損失が大きくなります。逆に言えば、失敗に気づくのが早ければ早いほど、損失は小さくなります。つまり、創造性を豊かに保ちつつ、損失を抑えるためには、失敗を早期発見できる環境を整えることが重要になります。

例えば、顧客が必要としない機能を実装してしまっている場合、その機能が必要でないことに早めに気づけたら、多くの時間を費やす前に、その機能を実装することを止めることができます。この失敗は、顧客側と開発側の認識のずれから生じています。そのため、頻繁に顧客と調整を重ね、どの機能が必要かを再評価することで、早期発見することができるでしょう(関連記事)。この認識のずれを早期発見できる環境が整っていない場合、開発側は、本当に顧客はその機能を必要としているのか、また、なぜ必要としているのか、半信半疑で開発に取り組むため、効果的な解決策を導き出すことが難しくなってしまいます。

また、バグの発見も、時間が経てば経つほど、どの変更でバグが生じたのか、どのように直せばいいのかが分かりにくくなるため、直すのに時間がかかるようになり、損失が大きくなります。バグは、コードの変更から発生します。つまり、バグを恐れるということは、コードの変更を恐れるということです。コードの変更を恐れていると、コードを綺麗に保つことを怠ったり、必要なコードを書くのに時間がかかったりして、コードの維持費が高くなってしまいます。失敗を恐れずにコードを変更できるようにするには、テストを自動化し、いち早くバグを発見する環境を整えることが必要になります。

仕事で失敗をするということは、損失を出すということです。損失を出すことは、避けなければなりません。しかし、失敗を恐れていては、創造性が失われてしまします。失敗は、発見が遅れれば遅れるほど、損失も大きくなります。つまり、早めに失敗を発見することで、損失を小さく抑えることができます。創造性を保ちつつ、失敗による損失を最小限に抑えるには、失敗を早期発見できる環境を整えることが必要になります。

Shogo Wada

楽しさと実用性の両立が好き。プログラマー。