無能者の戦い方

Posted by Hiraku on 2015-11-30

いいのか悪いのか分からないけれど、いつからか私は「無能者の発想」みたいなものが染み付いていて、その姿勢で仕事をしていることが多いです。

私はプログラマなのでその文脈で書きますが、たぶん普遍的な話。

エンジニア体力

エンジニアの能力を数値化するとしたら、その一つに体力があると思います。肉体的な体力もそうですが、特に精神的な体力。ガッツや根性と言い換えてもいいかも。

例えば稼働中のシステムが上手く動かないとき。システムが複雑で、どこが原因なのかよく分からない。実は最近開発に加わったばかりで、全貌も知らない。でも問題は現実に起きていてアラートメールは止まらないし、先輩エンジニアは捕まらない。どうしよう?

体力のあるエンジニアは、こういうとき自分のスキルを駆使して、丹念に原因を調べていきます。もちろん持っているスキルによって効率の良し悪しはありますが、体力はそれとは違うものです。printデバッグだけですごく根の深い原因を特定しちゃう人、いませんか?

あるいは、自分の知らないプラットフォームや言語で初めて開発を行うとき。SDKをインストールすると何故だかいきなりエラーが。調べながら修正を繰り返して、いつの間にか今日1日が終わっている。あれ?オレは何をしようとしてたんだっけ…?

体力のある人は、こういうYak shaving(ヤクの毛刈り)と揶揄される不毛な作業を苦にせずにこなし、いつの間にか枯れていない技術でも確実に習得して乗りこなします。

スキルがあれば体力を補うことができますが、力押しで何でもこなせる力というのはどうしても必要で、体力値でエンジニアの能力の大部分が決まるのは間違いないでしょう。

体力のない人

体力がない人は、複雑さや面倒くさいものに立ち向かえません。すぐ心が折れます。Yak shavingや泥臭い作業がいっぱい必要になると、そこで先へ進めなくなります。一部の人は「オレ、エンジニア向いてないのかなあ」とか悩んで、違う職種にジョブチェンジしたりします。

私はたぶん体力値が低い方のエンジニアです。今でも面倒くさい部分を作るのは億劫だし、不毛な作業が続くと飽きてしまいます。

ソースを読んでいくうちに鍛えられて体力値が伸びる人もいますが、私の場合は、「じゃあ体力値が低くても何とかなるように作ろう」という発想で仕事をしてきました。これをちょっと卑屈に表現したのが「無能者の戦い方」です。

無能者の戦い方

無能者は難しいコードが読めません。それを補うため、コードは分かりやすく書きます。よくインデントや変数名などのコーディングスタイルにすごくこだわる人がいますが、一貫性がないと読めないからではないでしょうか。

無能者はコードが書けません。それを補うため、既にある枯れた実装を探して使い、できる限り自分では書かないようにします。自分で書く時もコピペをせず行数を減らします。

無能者は記憶力に欠けています。それを補うため、学んだことや使ったコマンドなどをメモしておきます。私がブログやQiitaに書いているのは吐き出しておかないと忘れるからです。

無能者は難しいマニュアルが読めません。たぶん自分で書いた手順書すら分からなくなります。それを補うため、極力分かりやすく書きますし、可能であれば手順書よりも仕組みを作ります。自動化し、外部化して、自分で面倒見なくてもいいようにします。

無能者は難しいアルゴリズムが書けません。それを補うため、複雑な部分は分割して小さくし、テスト駆動でパーツごとに少しずつ書いていきます。

…こうして見るとプログラマの三大美徳、「怠惰・短気・傲慢」に通じるところがあるかもしれませんね。

無能のメリット

無能者向けの作り方は少なからずコストがかかります。一気にがーっと作るのに比べて回りくどい作業が多いですし、変数名やらを丁寧に考えていればコードを書くスピードも落ちてしまいます。

一方で、無能はスケールします。

凡人であれば、一気に作れる範囲には限界があります。「無能者の戦い方」でコストを払っていれば、更に難しい問題への対処や、変化に強くなります。自分の認識能力を超えた複雑なものだって作り上げられるようになります。

そもそも問題を小さく分割し着実に積み上げて解決するというのは、人類が繰り返してきたことでもあります。先人が組み上げた理論や仕組みを土台にして子孫が発展したものを作り、人類は進歩してきました。

体力と能力を駆使して一気に最適解を作り上げるような発想は「全能的」「神的」なやり方であり、単純な部品を組み合わせて作っていく発想は「無能的」「人間的」なやり方だ、と言ってみるのはどうでしょうか。カッコつけすぎですかね。

無能なクラス vs 全能なクラス

ちょっと話はそれますが、ソースコードを語る上でも無能性というのは重要な観点です。

ここに、メソッドを一切持っていない無能なクラスと、メソッドを200個持っている有能なクラスがあるとします。どっちがより優れた書き方でしょうか?

class Nothing {
}

class Everything {
 function a() { … }
 function b() { … }
…
}

ユースケース次第なので比較できるようなものでもないですが、少なくとも、メソッドもプロパティも持たないクラスなんて何の役にも立ちませんね。

しかしながら、NothingクラスにはEverythingクラスにはない優れた能力を一つだけ持っています。何だかお判りでしょうか?

それは拡張性です。

Everythingクラスは大量にメソッドを持っているがゆえに、新たにメソッドを追加するのが大変です。追加したいメソッド名と同名のメソッドが既にあって、しかも全然機能が異なるかもしれないし、依存している他のクラスとの関係で実装が難しいかもしれない。

なので、大量にメソッドを抱え込んだ巨大なクラスは、あまりよろしくない、変更しづらくなる、といったことを言われます。

ソフトウェアの各パーツをいかに無能な状態に保つか。設計者の腕の見せ所の一つだと思っています。

この「何者でもないがゆえに何者にもなれる」というのは本当に面白いと思っていて、無能性というのは、よく私が考えているテーマの一つです。

何故エモいことを書いているのかと言うと

そういうことを考えながら7年8ヶ月勤めた、ヤフー株式会社を退職したので、まあ何というかその記念です。2015年11月30日退職でした。

なぜ辞めるのかは、タイミングとしか言えないです。会社への批判や感謝は社内にフィードバックしたつもりなので、ここで語るべきではないでしょう。

現在29歳、初転職。未だ代表作と言えるものもなく。まあ環境も変わるし、この辺で「で、誰?」に答えられるようになりたいなあ…。



etcの最新記事