「面倒くさがる人」は2種類いる。片方はエンジニアとして最高、もう片方は最低。

誰でも「面倒な仕事」をするのは嫌なものだ。

だが、目の前に仕事がある以上、「面倒なこと」をやらないでおくことは、通常許されない。

面倒だからこそ、依頼者はあなたに頼んでいるのだし、面倒だからこそ、仕事にはお金が出る。

プログラマーは面倒くさがりがいい？

だが、ことプログラマーに関しては「面倒くさがり」の方がいいという通説もある。

プログラミング言語Perlの開発者であるLarry Wall氏が提唱したプログラマの三大美徳、

「怠慢（Laziness）」
「短気（Impatience）」
「傲慢（Hubris）」

を聞いたことがある人も多いだろう。

今回で言えば怠慢=面倒くさがりとなる。

まあ、わからなくもない。

「面倒くさがり」だからこそ、短時間で仕事を仕上げようと効率良くやる。

「面倒くさがり」だからこそ、コードの量を減らす工夫をする。

「面倒くさがり」だからこそ、テストが少なくて済むような書き方を心がける。

なかなか含蓄のある話である。

だが、本当にそうだろうか？

正直に言うと、おそらくこの話をした人は、「真の面倒くさがり」を見たことがないのではないかと推測する。

真の面倒くさがりは、そんなにヌルい事は言わない。

「面倒くさいから、何もしたくない」というのが、真の面倒くさがりである。

そこまでひどくなくても、「面倒くさがり」が致命的となるシーンはたくさんある。

特に、エンジニアの場合、実は「面倒くさがる人」は2種類いる。片方はエンジニアとして最高、もう片方は最低だ。

最高のエンジニアは、前述したとおりのエンジニアだ。

「面倒くさいから、考えて作ろう」

というのが良いエンジニアであることは、皆の意見が一致するところであろう。

だが、最低のエンジニアは全く逆の発想をする。

「考えるのが、面倒くさい」

この「面倒くさがり」が致命的であることもまた、皆の意見が一致するところだろう。

要するに「面倒くさがり」には2種類いる。

一方は、「手を動かすのが面倒くさい」という人々。

もう一方は、「考えるのが面倒くさい」という人々。

もちろん、自分たちが仕事を依頼するなら、どちらの側のエンジニアが望ましいのか、言うまでもないだろう。

しかし、決して「考えるのが面倒くさい」というエンジニアを私達が笑ってよいわけではない。

仕事の中で、「考えるのが面倒くさいから、とにかくやってみよう」というシーンはよくある。そして多くの仕事において、その方法が一定の成果をあげる場合が往々にしてあるのも事実だ。

これは、管理職や経営者ですら例外ではない。

実際、人間は「直感」を「思考」よりも遥かに好むという、研究もある。

本当のプログラマ三大美徳

プログラマは「面倒くさがり」がいい。

この通説はおそらく先に挙げた三大美徳の影響が大きいのだろう。

だがこの説をあなたが口にする前に、プログラマ三大美徳についてもう少し知っておいても損はない。

Larry Wall氏は実は以下のように三大美徳を定義している。
（出典：arry Wall,Tom Christiansen,Jon Orwant（2000）Programming Perl
日本語訳出典：https://moneyforward.com/engineers_blog/2016/02/08/engineers-virtue/）

1.怠慢（Laziness）

全体の労力を減らすために手間を惜しまない気質。
この気質の持ち主は、役立つプログラムを書いてみんなの苦労を減らしたり、
同じ質問に何度も答えなくてもいいように文書を書いたりする。
よって、プログラマーの第一の美徳である。

2.短気（Impatience）

コンピューターが怠慢な時に感じる怒り。
この怒りの持ち主は、今ある問題に対応するプログラムにとどまらず、
今後起こりうる問題を想定したプログラムを書く。
少なくともそうしようとする。
よって、プログラマーの第二の美徳である。

3.傲慢（Hubris）

神罰が下るほどの過剰な自尊心。
または人様に対して恥ずかしくないプログラムを書き、
また保守しようとする気質。
よって、プログラマーの第三の美徳である。

どうだろうか？

この説明を見て、何の予備知識もなく「プログラマーの三大美徳は「怠慢」「短気」「傲慢」だよ」と聞いた時とずいぶん印象が変わる人も多いはずだ。

今回のテーマである面倒くさがり＝怠惰の説明分には一見正反対とも思える言葉がある。

「全体の労力を減らすために手間を惜しまない気質」

なんと怠惰とは（ある観点から）「手間を惜しまない気質」だという。
もちろん続く言葉を読めば、これが矛盾しない説明だということはすぐにわかる。

プログラマが「面倒だ」と考えるべき部分。怠惰の権化となるべき部分。
それは「本来不要だったはずの業務」「意味なく繰り返される作業」に対してだ。

ドキュメント・マニュアルを残さなかったばかりに同僚・顧客から来る大量の問い合わせ、
本来自動化できた部分をしそこねたために延々繰り返される単純作業、そういったものを心の底から「面倒だ」と思った時、そしてそれを改善しようとする時「よいプログラマー」は生まれる。

HRTと三大美徳

三大美徳を尊重して、正しく「面倒くさがり」なプログラマーになろうと決心したあなたにもう一つ知っておいてほしいことがある。

それは「HRTの原則」。

HRTの原則は「Team Geek ―Googleのギークたちはいかにしてチームを作るのか」という本に出てくる、優れた開発チームで重視される価値観の頭文字をとったものだ。

その中身は以下の通り。

1. 謙虚(Humility)
2. 尊敬(Respect)
3. 信頼(Trust)

もしかしたら混乱した人もいるかもしれない。
三大美徳に挙げられた言葉とは全く正反対の言葉が並んでいるからだ。

プログラマーとは傲慢でありながら謙虚である、というような矛盾する人格を手に入れなければならないのだろうか。

もちろんそうではない。

プログラマーの三大美徳とHRTの原則は矛盾することなく、優れたプログラマーの中に共存する概念だ。

その理由を理解するために、これら2つのルールが誰に（何に）適用されるべきものなのかを考えてほしい。

三大美徳はいうまでもなく自身の書いたコードに適用すべきだ。

コードがエレガントでないばかりに生み出される余計な仕事を徹底的に面倒くさがり、繰り返される仕様変更に怒りをもち＝最初から将来発生しうる問題を想定したコードを書き、そして神のごとく傲慢に「自分には完璧なコードがかけるはずだ」と信じそのための努力を惜しまない。

そしてHRTの原則はもちろん人、すなわち開発チーム、組織そして顧客に対して適用すべきものだ。

もっとも理解しやすいのはコードレビューやペアプログラミングの時に相手にどういった態度で接するかということだろう。

忙しさやあなたにイライラをもたらす要素が積み重なった時、つい（たとえ内容がまちがっていなかったとしても）相手を尊重しない、きつい物言いをしてしまうかもしれない。

しかしその行為は長期的に見て相手との関係にとって、そしてチームにとって、更に大きな視点で言えば成果物にとっていい結果をもたらさない。

つい棘のある言葉が喉元まで来てしまった時、HRTの原則を思い出してぐっとこらえてみよう。そしてよりHRTの精神に沿うことばをさがしてみよう。

この習慣はきっとあなたがエンジニアとして生きていくのにいい効果をもたらすだろう。

ながながと書いてしまったが、ここにかいたことを理解してもらえたのならぜひ、意思決定の前には、「面倒くさがり」になろう。

もちろん、「後で面倒なことをしたくないから考える」という、「面倒くさがり」の方で。

[2019年5月31日アップデート]