優秀なエンジニアは「コードが汚いから読めない」なんて言わない【ひろゆき×安野たかひろ】

コードを書けることと、会社が儲かることは違いますか？

コードを書けることと、会社が上手く儲かることは結構違いますか？それは予測可能な範囲内ですか？

コードを書けることと、会社が上手く儲かることはかなり違うと思っています。

例えば、誰もが使うような有名なサービスであっても裏側のコードはとんでもなく汚くてツギハギだったりしますし、めちゃくちゃコードが綺麗でも誰も使ってないソフトもたくさんあります。

なので、コーディングの能力だけから会社が上手くいく可能性を予測するのはかなり難しいという感覚です。

ただ、コードが書けると、特に事業の立ち上げ期などに開発工数を自分で負担できるので、コスト面で有利になる面はあると思いますね。

ひろゆきさんは2chやニコニコなど、いくつもの成功サービスを立ち上げていますが、ひろゆきさん自身がコードを書けたことはプラスに働いていますか？

やっぱり「こういうサービスがあれば」と思いついた時すぐにプロトタイプを作れるのはコードができる人の特権じゃないですかね。

そこは大きいですよね。ちなみに、2chやニコニコのコードって綺麗だったんですか？

ニコニコは、コーディング部分には関わっていませんが、2chではエンジニア泣かせなコードばかり書いていましたね。

え、そうなんですか？

おいらの場合、1980年代からプログラムを書いてたので、forには$iとかの1文字変数使っちゃうんですよね。$piyoとか書いちゃうので、2chの初期コードはかなり読みづらいものでした。

forループの中で作られた変数$aが有用だと後で気付いて、グローバル変数として使っちゃうとか。

一文字のグローバル変数が重要になっているのはアツいですね（笑）しかも$aって……！ そこまでではないですが、私も雑に書くときは一文字変数が多いです。

でも、おいらが知ってる優秀なエンジニアで「コードが汚いから読めない」って言う人は見たことがないんですよね。

優秀な人で「コード汚いから読みたなくない」って言う人はたくさんいますが、「頼む！」と頭を下げると皆ちゃんと読みこなせますよね。

時々、「汚いコードを読み解くことが好き」というレアな方も居ますが、そういう方はどんな現場でも重宝されている気がします。

まあ、他人のコードを読む事になるエンジニアは、同僚に綺麗なコードを要求するのは当然ではありますけどね。

サービスが流行るにつれて、想定と違うボトルネックが発生して、アルゴリズム自体を変える必要が出てきた時などにコードを綺麗にするのはアリだと思いますが、コードを読むのが下手なエンジニアのためにコードを綺麗にするのは時間の無駄かな、、と。

ただ、エンジニアからは「コードは綺麗に書け」という圧力が出てくるのは当然なので、上位の人が「どんなコードでも動くコードを作るのが正しい」「done is better than perfect（完璧を目指すよりも、まずは終わらせることが重要） 」のスタンスが効率的だろうなぁ、、と思うおいらです。

私もスタートアップの経営をやっている時にエンジニアチームから何度も新機能開発ではなくリファクタリングに時間を使わせてくれと要求されていました。

結果、お客さんに「この機能のリリース遅れます」と頭を下げ、エンジニアチームには「ここまでは耐えてくれ」とお願いし、経営陣に「リファクタリングやらないとマズイっす」と強弁し、ほうぼうで調整をかけていた覚えがあります。

そういう意味ではひろゆきさん推奨の「done is better than perfect」を貫き切れなかった側の経営でした。。。

なるほど。

ただ、リファクタリング工数を経営的なロジックで正当化するのは本当にしんどいと思います。

例えば、
1）短期的に売上を産まない
2）長期的にもどれくらいペイするのかよく分からない
3）何をどれだけ整理すべきかエンジニアごとに色々な意見がある
4）決して終わらないし、成果も定量的に測定できない
と、やりづらさが勢ぞろいです。

ひろゆきさんが言うようにデグレしてお客さんからブチ切れられるリスクもあるわけですからね。

実際は、どう乗り切っていたんですか？

経営的な理屈として「これはエンジニアのための福利厚生であり、採用費に効果のある施策だ」と割り切っていました。採用時に「リファクタに時間を取っているよ」と言えるようになるし、実際、従業員エクスペリエンスが良ければ定着もしてくれやすいと感じています。人にこそ投資をすべきではないか、という理屈は経営陣も納得しやすい。

ただ、汚いコードって、「必ず解けるパズル」と認識してやってみたりすると面白かったりするんですよね。デバッグも時には楽しかったりするので、、、

ミステリーナイトという、会場で役者さんが事件の演劇をして、観客が探偵として解くという老舗イベントがあるんですけど、デバッグに似てる気がしています。

目の前で起きた出来事の情報から、裏で何が起きているのかとか、その原因がバグとして出てきてるんじゃないかとか、どこに原因があるのか推測していく点が、デバッグと推理小説の楽しみ方に似てるなと思うんですよね。

ミステリーナイトはすごく興味があります。エンジニア界隈で脱出ゲームやマーダーミステリーが流行っていたりするのも同じような感じですよね。

はい、論理パズル的な要素があるものはエンジニアに向いていると思います。人間関係と違って、正しいコードは必ず動きますからね。正義感が強い人もエンジニアに向いてる気がするんですよね。

正義感が強すぎると、文系営業の清濁併せ呑む感じとか、嘘をついても結果オーライみたいなスタンスは受け入れづらいですし。。

推理小説といえば、昔同じ会社で働いていたエンジニアが最近、なぜか連続で推理小説の賞を取っていたりします。昨年の「このミステリーがすごい」大賞の白川さんと、今年の江戸川乱歩賞大賞の日野さんという方です。

スパゲッティコードに長く接しているエンジニアは実は推理小説を書けるスキルを知らず知らずのうちに獲得しているのではないか、という仮説が自分の中でホットです。

毎日論理構成の中に浸ってる人は、推理小説は向いてるかもしれないですね。初期にちょろっと設定したグローバル変数が、最終的な結果に大きく影響してくるとか、「ここで使われてるのかー」みたいな感慨とか。

東野圭吾さんも森博嗣さんも理系ですし、理系の推理作家は多いですね。

結果として、恋愛小説とかは全く向いてない気もしますが、、

ははは。理系の恋愛小説家はぱっと思い浮かばないです（笑）

私も自分で小説を書き始めて分かったのですが、良い小説を書く技術と汚いコードを書く技術って結構似てるんですよね。

良い小説って最初から終わりまで全ての段落（モジュール）がお互いに無秩序に密結合しているなと思います。張り巡らされた伏線（依存関係）が思わぬところで回収される、みたいな。疎結合高凝集が良いとされるソフトウエア開発とは真逆です。

確かに。ごちゃごちゃしていて、最初の頃のことを忘れて読み進めるうちに伏線回収されて気持ちいいみたいなのって、綺麗なコードと真逆ですよね。コードと小説構造の類似性は考えたことなかったですけど、相関は高そうっすね。。。

ほんとそうで、たぶん、綺麗なコードみたいな小説読んだら全然味気なくてつまんないと思います。ソフトウェア工学の手法で統計的に小説の文章を解析してみたらどうなるか、みたいなテーマは面白いかもしれません。