善のめんどうくせ、悪のめんどうくせ

僕もプログラマーとしてのキャリアが今年でたしか12年目だか13年目だかになる。決して有能なプログラマーというわけではないがそんだけの期間特にマネージメントとかの脇にそれることもなく基本的にずっとサーバーサイドのプログラムしかしてないのでそれなりに知見もたまってきた。

最近仕事でコードを書いていて変わってきたな、と思うのが、「めんどうくさい」にたいする対処の違いだった。「あーAという書き方でやってたけどよくよく考えてみたら絶対Bの書き方のほうがあとあと手直しが楽だなー」ということがよくあり、こういう状況はまず「あーめんどくせ」と思う。何しろたいてい良い方法を考えつくのはAという書き方でほとんどやってしまった時で、Bの方向にうつるならかなりの部分書き直さないといけない。

書き直して検証もしなさないといけないからそれ相応に時間がかかる。だから面倒くさいししかも今のままでも動いているならなおさらだ。もっと前はとにかくスピードが欲しかったから「ま、動くからええやろ。あとで直したかったらリファクタリング（動作を保証した上での書き直し）すればいいし」と「めんどくせ」を全部「あとでリファクタリングしますわ」ですっとばしていたのだけどまあだいたいリファクタリングなんてしないし、リファクタリングしようと思ったときには別の作業も絡み合ってきていてその作業量は膨大なものになっている。

だから、「あーBのほうがよかったーーーめんどうくせーーー」と思った時、本当にBの方がいいのなら、最初にめんどうくさいと思ったところで書き直したほうが最終的なスピード的には絶対に特になる。だから最近は「めんどくせ」と思ったら「ラッキィ」と思うようにしている。なぜならそれは改善できることの証だからだ。

同じことは文章にもいえるだろうか？　たぶんある程度の長さみたいな大規模プロジェクトだったら同じことが起こるんじゃないかな。8、９割ぐらい書いたところで「あーもっとこっちのほうがよかった」と気がつく、みたいな。長篇小説は僕は書いたことがないから想像になってしまう。

ただ『SF超入門』を書いていた時は２０万文字以上書いた原稿を一回完全にボツにしているから、まあ小説以外でもほぼ同じことにはなっているか。書評原稿、解説原稿のような文章はショートスパンだから事前に頭の中で構成ができあがっていることも多くあまりそういうことは起こらない。

長期プロジェクトでこれが起こるのは、一つには長期プロジェクトの場合、開発・執筆にはいる前の構想期間がだいたいにして開発・執筆期間より短いから、というのがあるだろう。たとえばこういうサービスが作りたい、こういうふうに実装したい、というのを数日かけて考えたとして、実装は確実にそれよりも時間がかかる。実装中は基本的にずっとそれについて考えているわけだから、実装・執筆にかかった時間がながければながいほどそれについて考えることになり、事前の構想時よりよいものを思いつくのである。

だから、これは構造的必然的な「めんどうくせ」だと思うのだ。

しかしこれを仮に「善のめんどうくせ」だとするならば、おそらく「悪のめんどうくせ」も存在するだろう。本当にただただ手間なだけで、やらないですむ、短縮できるのならその方がいい作業は「悪のめんどうくせ」だ。たとえばそれこそコードを書いて自動化するとか、金を払って人にやってもらうとか、（できるなら）そういう形で対処したほうがよい。

善のめんどうくせと悪のめんどうくせはしかしどうやってよりわけられるのだろうか？　その判別手段はあるのか──？　といえば……仕事の昼休みで考えながら書いているのでまた次回（多分書かない）