仕事でとある機能を設計して実装していた。ある非同期な処理の状況を画面に表示するというだけのタスクだ。ちょっと様子を見に行って、そのステータスを表示すればいいだろう。そう高を括って設計を始める。
のだけれど、一向に進まない。頑張ってちょっとずつ作ってPull-Reqにするのだが、コードレビューでどんどんrejectされる。登山に出たらどんどん霧が出てくるようなありさま。なんかおかしいぞ。目の奥がチリチリしてくる。
ウームどうしたもんか、と思って頭をひねるのだが驚くべきほどに何も進まなくて、俺の頭が悪すぎるのではないかと益々不安になってしまった。
にっちもさっちも行かなくなってしまったので、同僚に助けを求めることにした。
実は難しかった
同僚と相談したときは、なんて俺はアホなんだ、寝不足かなんかで頭回ってないのかな？と思っていたけれど、同僚と話しているうちに、これ普通に難しいっスよ、という感じになってきた。
というのも、例の非同期な処理は、再実行したり、実行までにキューイングされるといった要素を含んでいるのだ。これにより、考えることはずっと増えていた。
一般論として、タスクには考慮しなければならないパラメータがある。少なければ簡単で、多ければ多項式的に難しくなる。Twitterで有名企業のバグが取り沙汰され、槍玉に上げられているときに、たいてい考慮されていないのがこうしたパラメータだ。
こいつら――――リトライ処理やキューイング――――は、最初から問題のパラメータとして確かにそこに存在していた。しかしながら自分はそのパラメータを認識できていなかったし、一見パラメータが少なかったので簡単だろうという目論見を立て、危険な予兆に気付けなかった。
もともとこのタスクは難しかったのだ。
なぜ気付けないのか
同僚がふと、「ちゃんと難しいということを認知するのにも訓練が必要」と言った。まさしくそうだ。難しい概念は、それ自体の認知が困難なのだ。その認知の困難さも含めて「難しい」のだ。その視点がとても新鮮だった。
ふと、よく古典的RPGとかではIntelligenceとWisdomとが別のパラメータに割り振られていることを思い出す。どちらも叡智といえば叡智だが、後者のWisdomはこうした認知困難な不可知の難しさに対する鋭さ、なのかもしれないと思った。多くの場合それは長年の経験から蓄積されるもので、明文化が容易ではない領域だ。
人間楽をしたがるもので、簡単にいなせるタスクか、実は困難なタスクなのかと問われると、簡単だろうと考えてしまいやすい。こういうときにうまいことムムッと気付けるようになりたいものですな(オチなし)。 自分にできることとしては、途中で「これ難しいやん」と気持ちを改める度量を持つべき、といったところだろう。
タイトルに難という漢字が4つも入っている。まさに四難の業ってね・・・(これがオチ)
