仕事とは、プログラミングとは

これは、冒頭の問いから端を発した、各章のつながりが不明瞭なエッセイ、流行りのミームでいうと技術的ポエム、であり、プログラミングをテーマにしていてもプログラミングの記事ではない。(と一番最後まで書き終わった自分が注釈を入れている)

良いコードとは何か

趣味で4年、本腰を入れたは最後の2年なのだが、それから3年間ほど仕事でプログラムを書いてきた。それで、趣味プログラマと業務プログラマの一番の違いは、業務プログラマが要求されるのが「他人にどれだけ意図を伝えることができるか」ということに尽きると思うようになった。

他人にとって良いコードとは、書いた人の意味が読み解けるコードであると思う。どれだけ書いた本人の自意識の中でかっこいい・よいコードを書いたと思っていて、実際にちょっと紐解けばそのポテンシャルがあったとしても、隣に座っている人間に伝わらなかったら意味が無い。正しくコードレビューが行われるならば、理解を得られぬコードはマージされず、誰かに価値が届くこともないだろう。(いや、わかっている、現実は妥協の連続だから、世界は書いた当人でしか理解できぬコードで満ちている)

センター試験の国語の設問のような「作者の気持ちを考えろ」とは文系の代表文句のようだが、僕らプログラマほど同業に対してそれを求め求められる仕事はあんまり無いように感じる(テキストにすると、それはなんだか傲慢な認識かもしれないな、と今は思ったが)。まあ、たとえ部外者から平均的に平均的な人間に対するコミュニケーション障害を持つ集団だと思われようとも、内輪で通じる記号をたくさん持っていて、そしてそれを学び続けている、はずだ。変数命名規則や、ドメインに応じたネームスペースの区切り方や、デザインパターンなどがそれだろう。

勿論、趣味エンジニアでも他人とのコミュニケーションが要求される段階に到達する人はいる。が、敷居は高い。よく使われるOSSのオーナーやそのコミッタでもないとその必然性を感じることは少ない。そして当然のように英語だ。しかし業務だと、メインが英語ではないとしても、それが日常となる。実際は定義のズレが発生しないよう、プログラムに関連するドキュメントは英語を要求する会社も多いだろうと思う。

ウェブ系のエンジニアが学生にOSS活動を推奨するのは、OSSのワークフローが細部は違えどウェブエンジニアのそれとほぼ同じだからと自分は考えている。ウェブエンジニア以外がそうかはあまり自信がない。というか、知らない。少なくとも僕が見てきたコンシューマ出身のゲームエンジニアは完全に別文化だった。

捨てるものは何か

一応予想される反論に対して先手を打っておく。パフォーマンスチューンや高度なアルゴリズムの実装は、可読性を犠牲にすることも許されることもある。が、基本的な方針として両立を目指すべきである。局所的に複雑なコードの実装者は、それを〆日のタイムボックの中で、いけるとこまでいって、そこで辿り着いた地点が当人のその時点での技術力だと思う。

経験上、読みやすかったコードはパフォーマンスも良かった。よく精錬された設計は無駄な処理が少なく、処理ステップの見通しがよくキャッシュコントロールが容易である。逆に言うとインスタンスの生成位置と破棄タイミングが不明瞭なのが悪いコードであると思っている。(これはアプリケーションエンジニアとしての発想であり、一般的かどうかはわからないが…)

もちろんプログラムによって実現したい当該ドメインが複雑であるほど理想を通すのは難しく、そして人間の要求・欲求が複雑なために、プログラムは複雑になってしまう。という認識を、僕は持っている。ならば人間様のために、プログラミングのためのプログラミングは、限りなく透明な入れ物であるべきだ。これはUIエンジニアとして学んだことの一つ。

仕事とは何か

僕は前例がないJavaScriptの仕事を任されることが多い。自分のスキルセットが、今の時代の要求に適していたからだ。それが自分の気性とあっているとも思っているので不満はない。

僕にとって仕事とは、ある一面では「自分がその時に有用だと感じた技術スタックの有用性を示し、説得し、交渉し、運用し、その過程を評価される」ことであったと思う。冒険を始めるときは、新しいことのための共に連れ添うパートナーを、フレームワークやライブラリを選定する。

この仕事に対する姿勢は、マニアによるマニアの為の技術選定ではなく、継続して価値を届ける為のものであり、高い頻度の仕様変更に耐えるための可用性を手に入れるためである。僕は自分の選んだ技術によってそれらを提供できると思っていて、そのついでにちょっとした知的興奮を味わえればよい。そのようなものだ。そして叶うならば金のなる木に育ってくれと願っている。

技術記事を書く理由は何か

同僚を納得させる役割を負った僕は、戦略として、自分が使いたいと思う技術やプログラムに対して、自分で有用な(少なくとも有用であることを目指した)記事を提供し、盛り上げ、賛同者を集め、外堀を埋めた上で同僚を攻め落とす(もしくは賛同者として取り込む)という戦略をとってきた。これは成功することもあるし、失敗することもあった。僕にとって働き始めてからの技術記事とは、常にともに働く同僚への説得材料でもあった。

だからいつだって外に出すドキュメントは一定以上の、社内ドキュメント相応の品質を求めたし、仮想読者が適切に設定されていたので記事が書きやすかったという側面もあった。逆にいうと仮想読者が設定できないと上滑りすることがあるのだが。(そういえばこの前のドワンゴでの勉強会は悪い発表ではなかったとは思うが泥酔したまま30分しゃべっていてスマンという気持ちがある。これだ)

とはいえ、これらの行為は、僕が文章を書き慣れており、公開するのに抵抗がないという属性に由来して、ロールモデルの一つとして他人に提供するのは酷だと思っている。ある意味ではプログラミング力の不足を言葉によって補っている、ある意味では騙しているのかもしれない。申し訳ないことに。

なので今は、あけすけに語ることで、できるだけ誠実になろうとしているのだ。

何が成功したか

Reactの件で、僕は壮大にいろんな人を巻き込んだと思う。意図してそうした。現代のフロントエンドの支配的な概念、jQueryという対立軸に抵抗するには、フロントエンドはサーバーから貰ったHTMLをレタッチを繰り返し汚すものだというパラダイムを変えるには、それぐらいする必要があったと思っている。とはいえjQueryを全否定するものではない。一定以上の複雑さを持つものには、jQueryのようなアプローチは破綻するということだ。特に現代的な、この言葉は好きではないが、いわゆるHTML5では。

そこには公共、というか僕が属していたであろう日本のプログラム界隈への貢献の気持ちがあったし、仮想DOM技術に対して僕が感じた未来を、どうにかして伝えようとした。いや、正確には、HackerNewsやEcho.jsから流れてくる海外の情報を自分なりに噛み砕いて、そのポテンシャルによって、日本におけるあるべき位置を是正しようとした。

うん、これは政治的で危険な発想かもしれない。僕が間違った方向に全力になり、それを正してくれる人が十分にいないと、僕が影響を及ぼせる範囲は暴走しうるからだ。というのは、驕り昂った発言だが、僕は…まあ見ての通り、あまり謙虚な人間ではないのだけど、実際僕が昔推奨したライブラリを、それによって採用し、現在不利益を被っている会社があるのを知っている。本当に申し訳ない。ただそれはその当時の僕の限界でもあったのだ。

僕はReact、というか仮想DOMの技術でフロントエンドの技術一歩先にいけると思ったし、実際にそういう気配を感じている。この件に関しては、一山越えてやりきったという気持ちがある。

とはいえ、他人のフンドシで偉そうなことを言い続けるのは恥ずかしいという思いもあったわけで、自分が作ったものでもないものを、まるで自分が第一人者であるかのように褒めそやし続けるのは抵抗がある。正直なところ。だからReactじゃなくてVirtualDOMという概念を標的にしていたのだが。

オーバーエンジニアリングとは何か

僕らみたいないつでもプログラミングをしている人間(やや大きめの主語だ)の常として、常に業務の必要性の枠を超えたオーバーエンジニアリングに片足突っ込んで時間を浪費する危険がある。重々承知している。

だから、最近は「趣味はオーバーエンジニアリングです」と言ったりするようにしている。つまり、会社の業務としてリスクを負えないチャレンジングな部分は、趣味時間に解決することを、趣味の一環として行っている。そういう時間配分。

最近だと mizchi/md2react がそうだし、まだドッグフーディング中で紹介していないが mizchi/stone-skin がそうだ。

mizchi/arda も元々仕事で作ってたアプリケーションコア部分に、ある程度の抽象性を与えたやつだ。次の仕事でも使えるように、という名目であり、実際そうなのだが。

これは人によっては、とんでもないことだというだろう。余暇で仕事をしているのか、と。これに対しての反論は、そもそも僕の転職動機や職の選択からして、趣味と仕事の一致という色が強かったということを付言しておく。

ここからはとても個人的な話なのだが(これは個人の日記である)、そもそも自分は興味が無いことは一切手に付かないタチであり、この仕事以外では人格破綻だと認識されても仕方ないと思っている。コンビニのバイトは2週間しか続かなかったし、大学の諸事情で都合上どうしても出る必要があった就活セミナーでは、営業の人間の、客への奉仕の精神を語るのを聞くと(それが建前だとわかっていても)実家の宗教のことを思い出して吐きそうになり逃げ出してしまった。そもそも自分は就活ができる人格ではないと思っていて、実際に普通の、エントリーシートを提出するような就活はしなかった。

たぶん、僕みたいなのは、誰かのもとで働くのではなく、将来的には独立すべきなのだろう。今はまだぼんやりとしか考えていないが、そのうち。

趣味プログラマは幸せになれるのか

この記事は、書き始めは元々はとあるエントリへのアンサーだったのだけど、全然関係ない部分に話が飛躍し続け、元の主張が薄れたので、元記事には触れないで置く。

このエントリに結論はない。ただ飛躍に飛躍が連鎖してつながっているようにみえる雑文である。この流れなら、こういうテーマに対するオチが用意されてしかるべきだとそれっぽい章題を思いついたが、実際は何も見えていない。あとそういうメタな文章が書きたかった。ので書いて満足した。

それでもまあなんとか意味をひねり出すなら、再び「仕事とは、プログラミングとは」という主題について考えよう。趣味のエンジニアが業務のそれと一致すると、それ自体で生きる目的を達成してしまい、目の前の金・ビジネスという現実を軽視する傾向はあると思う。仮に自分が携わるプロジェクトが失敗しても、技術的に成功していたなら満足する。きっとそんな人種だ。

僕もそういう時期はあった。いや、正直に言おう。今でもそうだ。色々と都合を付けて、僕は本来なら成立しないものを成立させたのだ、そう思ってプライドを保っていた。実際には手ひどい敗退であったとしても。

ビジネスとは何か

(さっきの章で終わるつもりだったのだけど、長くなったのでまた分割してしまった)

僕からみて、ビジネスというのはブラックボックス化された一種の博打だ。理解が及ばないし正直そこまで興味もない。経営者という人種(極端に抽象化した分類)が、そのブラックボックスを覗きこんで、コレが必要だ、アレが必要だとひねり出してくる。僕らはそれに可能な限り応える。

僕にわかるのは、貧すれば鈍する、ということだけで、失敗し続けると、そこは居心地が悪くなるということだ。しかし成功・失敗の変数が、わかりづらいし、僕がそれを仮託する経営者も、博打であることを否定したことはない。というか当たればでかいが当たる確率は低い博打をしている山師がほとんどだ。とくにこの界隈では。

個人としてとれる行動は、できるだけ当たりそうな博打に参加する。あるいは博打の過程そのものを楽しむ。

良いモノを作りたい、それはわかる。ただし僕が考えている良いモノと、世間のそれは一致しないだろうし、カネになるものは両者の予想を超えて歪な形をしていたりする。とは言え、できるだけ理解できるものの側で、自分が書いたプログラムを育てたい。それがプログラマを相手にする今の会社に入社した理由だったと思う。

と書いてしまうと、まるでオチにwe are hiringと書いてある限りなく情報量が低いスライドみたいだ、と思って、ちょっとダサいなーという気持ちになった。まあ、求人は出ているが誘導は出さない。勝手に探してくれ。

技術を人に提供するには、お互いが納得できるwin-winな立ち位置で、出目がいい博打をしよう。っていう雑な結論。あーコレでいいのか。こんだけ書いといて。

まあいいか。今は朝五時なので、起きたら投稿しよう。


朝起きたらなんだこのクソと思ったが、書いた分量がもったいないので出す。