キレイなコードが良いというエンジニアは迷惑千万！？

コードを書くことが目的化しちゃってる人も多いので全否定するつもりはないけど、コードが汚くても「アイツがいれば勝てる」と思わせる人間を素人判断で雇うことが如何に危険かプログラマ視点でまとめてみる。
https://anond.hatelabo.jp/20121201025247

優秀なエンジニアは、いうこと聞かない人が多いし、どっちかというと採算なんて余り考えないし、こんな人ばかり雇ったら、優秀なエンジニアだらけなのに、会社がつぶれますということもあります。

本当かどうか不明だけど、日本の企業は技術力があるけど、いろんな要素で負けて、うまくいかないなんてニュースがＴＶなんかでよく聞くけど、要は技術力が日本以下のところにビジネス上は負けてるということですよね？

ソースがきれい＝技術力がある、でそこからどういう利点があるとかいう以前に、ビジネスで負けてしまえばダメだってことを理解できない人たちは、自分たちの作業が大変になるという小さい視野で物事を判断してるかもしれないのです。

---

極端な話、コードがもうメチャメチャでも、動いて金が回れば正解なんですよ。「アイツの書くコードは汚いけど、アイツが入ったプロジェクトは絶対勝つよね」ってエンジニアは、絶対に呼ばれます。もう間違いない。少なくとも、僕は欲しいですし。
エンジニアよ、ゼネラリストなんて目指すな！―VASILY 金山裕樹のキャリア論［2］│CAREER HACK

速度と設計のトレードオフが発生するような状況で、その場に応じて最適な手法を即座に採用することができるかどうかが恐らく求められているのであって、コードが汚いかどうかを前提にするのが本質じゃないのではないでしょうか。もちろん、開発期間に応じてコードの奇麗さを犠牲にするような状況も多いとは思いますが、「コードが汚くてもいい」と表現せずに、「その場の状況に応じてコードの美しさを犠牲にする柔軟さを備えている」と表現すれば、ここまで反感は買わなかったのかなぁという気もします。

Geekなぺーじ:「汚いコードでいいよ」は夢の環境であると同時に悪魔の囁き

未完成な物や、バグありのものを出してもよいのか？

Windowsのビジネスモデルをどう考えるかですね。バグ修正をサービスパックとかいう名前で提供したりする行為を。でもって、Appleもそういうビジネスモデルを取り入れて成功しているという事実を。

最初から完成度の高いものを出すのでなくて、未完成？なものを出して開発費などを回収しながら次々とビジネスを進めていく行為です。

プログラムというものは、どれもが同じではない

生命（医療系）や金銭（銀行系）に関わるものと、そうでないものが同じ信頼性が必要とされるかです。ここでいうのは品質や信頼性であって、ソースがきれいだとか保守性に優れているとかそういう話ではありません。

キレイなソースをかくエンジニアは迷惑ではないのか？

キレイなソースを書くエンジニアは、周りにとって迷惑ではないのか？という話です。担当部分だけをキレイなソースで書いている限りでは、担当分だけ、影響範囲はそこまでで、担当+アルファ以上の迷惑は掛かりません。

しかし、キレイなソースを書くことを正義としてそれを周りに押し付けだすとなると、その迷惑度は違います。

キレイなソースを書くことが正しいかどうかとかは別の話で、決まったことには従ってもらわないと、また優先順位を考えて作業比重を考えてもらわないと、迷惑することも多々あるでしょう。

保守性の高いソースのほうがエンジニアは幸せになれるという妄想

本当に幸せになれるでしょうか？考え方はいろいろあります。保守にコストがかかろうと、それを回収できることが可能なら、問題にならないことがほとんどでしょう。

ただ、現場で働くエンジニアがひどい目に合うということだけで・・。

しかし、保守性が高いソースで作業が簡単なら、たぶん、作業はスムーズに行われるけど、それに対する報酬は以前よりも格段に安くなるかもしれないってことです。

報酬でひどい目にあうか、作業でひどい目にあうかの違いにしかすぎない可能性があります。でもって、簡単にできる作業は、優秀な人には回ってきませんので、楽できるのはソースをきれいにかけるエンジニアではないかもしれないということです。


技術力に対して、お金を支払われない可能性があるわけです。また、顧客にとっては技術力よりも、きちんと実現されたか、要望を満たしてるかのほうが重要なわけで、直接、技術力にお金を払っていません。

WindowsにしてもiPhoneにしても、直接技術力にたいして顧客がお金を払てるわけではありません。他に技術力が高いところがあり、よりよい性能なものがあったとしても、そっちに乗り換えるかどうかさえ不明です。

そもそも技術力は、ソースをきれいに書く力でなくて、問題を解決する力です。それがスーマートでない泥臭い方法で、汚いコードのオンパレードであったとしてもです。

まあ、汚いコードかどうかはわかりませんが、そこそこ知名度のあるWEBやネットワークゲーム系で負荷のかかる処理に対して泥臭い方法で問題解決をしてる場合は多々あります。

ソースがきれいを求める人は、スマートを求めがちで、その結果、ある人達から見たら迷惑千万な人だということです。

人間というのは身勝手でワガママなんです

経営者やプロマネなどは、直接汚いコードでつらい目に合うことがないので、最終的には収益が上がる方法を選ぶわけですね。

汚いコードはトラブルを生むとしても、そのことで間接的にひどい目にあうとしても、金と力で解決できるわけですから、問題ないと考えるわけですね。

エンジニアができることは、きれいなコードを書こうという啓発でなくて、汚いコードに対するメンテナンスをみんなでボイコットすることです。

おまけ

いや～Microsoftだって、できればサービスパックなんて出したくないと思うぞ？(笑)バグを減らそうとあらゆる努力をして、それでも出てしまうバグをサービスパックで対処しているわけで、「バグが出ても後からサービスパックで対処すればいいや」と考えているわけではない。つーか、この人ソフト開発なんてしたことがなくて、全部想像で書いてるだけだな。
http://mechag.asks.jp/503057.html
https://web.archive.org/web/20130212114125/http://mechag.asks.jp/503057.html

努力をどこでやめて、出荷するかという観点が抜けています。

あらゆる努力をするのは、ビジネスではありません。テスト方法と品質基準を決める作業があり、品質基準をクリアすればOKと考える企業がほとんどです。品質基準の設定の仕方により、品質が変わるのは当然です。

人と金と時間の制限がある限り、「あらゆる努力」というのは、「出来る範囲の努力」と同じです。

「本当にあらゆる努力をされては、迷惑だ」というのがわからない一部のエンジニアが迷惑だといってるわけですよ。

「バグが出ても後からサービスパックで対処すればいいや」と考えるほうが、エンジニアとしては失格（ダメ）でも、商売人(ビジネスセンス）としては筋が良いんですよ。

コントロールの利かない（自称）優秀なエンジニアにはこういうことがありがち

　一方、今回のデータ消失事故の原因となった担当者は、配布システムが導入される以前から、自ら作成した更新プログラムを利用するなど独自の方法でシステム変更を行なっており、6月20日のメンテナンス時にも過去の更新プログラムを改変して利用したが、過去に記述していた「対象外サーバー群についてファイルの削除を行う」旨のコマンドを消し忘れていたという。
ファーストサーバ、データ消失事故について第三者委員会の調査報告書を公表 -INTERNET Watch

キレイ＝効率が良い、汚い＝効率が悪いと置き換えてみると良いかもしれない。

周りは技術力では太刀打ちできないから、迷惑だと思っても黙認するしかないパターンもあり得るということ。また、こういうタイプは聞く耳持たない傾向にある人が多いと思います。

キレイなコードが悪いというのは発端の人をはじめ、誰も思っていないと私は思います。ただ、他の要素もいろいろ絡む問題においてはその重要度が違いますという話と、それとは別にこの記事では、こういうエンジニアは迷惑ということを書いてあるだけです。汚いコードを意味なく書くエンジニアもそれなりに迷惑ですよ。