ソフトウェア開発には大きな不確実性がつきものであることはすでに現代では広く知られている。
この不確実性とどのように向き合っていくか、ということも多く語られていて、いわゆるスクラム開発というフレームワークは、不確実性に対して「適応性」を高めていくために用いられるフレームワークだったりする。また、「不確実性の高い部分と低い部分があるなら、高い部分を先にやっつけてしまう」というようなテクニックも当然有用だろう。あるいは、高度な技術力のある人間の高度な設計力によって、不確実性を軽減するアーキテクチャを導入できることもある。
このように不確実性に立ち向かいコントロールしていくことが重要なのはいうまでもないけれど、一方で、不確実性のコーンを引用するまでもなく、結局のところ、リリースするまで不確実性は「なくならない」ということに眼を向ける必要も同時にあると思う。どれだけ適切に不確実性に立ち向かっても、必ず、どこかで「不確実性を不確実性のまま飲み込む必要」が出てくる。これはまさに判断と決断の話でいうところの「決断」のことだ(c.f. 判断と決断の違いと決断のコツ - そーだいなるらくがき帳 )。わたしはいろんなところで「適切な判断をしたい」と「不確実性がなくならない」の間でデッドロックになってしまう、というシチュエーションを結構多く見かけることがある。「不確実性が多いから、判断ができない」「決定がなされないから変数が増えてしまい不確実性がいつまでたっても小さくならない」というデッドロックだ。
このとき必要なのは結局「不確実性を不確実性として飲み込んで決断することで変数を減らしてものごとを前に進めること」だ。これは「十分に不確実性が少なくなった時点での判断」よりも失敗の可能性は当然高い。なので、決断したら「その決断を成功にするためにできること」に対しても努力しないといけない。このふたつを担う、というのは結構大変なことだし、「自分がそんな博打やっていいのかな」と思うことも多い。だけど、もし「あなたの現場」でその決断をするひとがおらず、「あなたは」決断をするべきだと考えているのであれば、多分それが「その場で」できるひとはあなたしかいない。あるいは、たまたま、その現場でのリーダーという立場があなたなのであれば、それは「あなたしかそれをやるひとがいない」のだから、腹をくくってやるしかない。そして、そういうことをやった場合にもし失敗しても、その失敗はあなたの経験となるので、あなたにとっては無駄にはならない。「けど事業や会社や仲間にとっては無駄になるじゃん」、という考え方は大変に正しいし、わたしもそれで足がすくんだり悲しくなったりすることが結構あるのだけれど、そういうときには同僚が以前いってくれた、「その場で、その決断をする人間、あるいは別の決断をする人間が他にいなかったのであれば、どういう結果になったとしてもそれがこの組織にとってのベストであって、なのであればそのベストが失敗したところでもう他の誰がやったところでダメってこと。"もっとうまくやるひと"が仮にどこか別の組織や別の世界にいたとしても、そのひとはいまここにいないのだから、あなたがベストなのだ」という言葉を思い出している。
