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

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

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

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

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



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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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


関連記事

コードがかける若手SEに依存しないことが目標だから
プログラミングが好きな少年が幸せになれる会社は日本にはないと思え



おまけ

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

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

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

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

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

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


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

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

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

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

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



関連記事

グローバル変数、スパゲッティコードと聞いて、ダメだろうと思うのは素人?!
【再度、考える】綺麗なコードをかくエンジニアは、なぜ迷惑なのか?

スポンサーリンク

『キレイなコードが良いというエンジニアは迷惑千万!?』へのコメント

  1. 名前:匿名 : 投稿日:2012/12/06 00:19

    ブログ記事にしてくれてありがとう!

    賛同できる所できないところあります。綺麗なコードが顧客の収益にどう影響するかって所に違いがあるみたいです。あと仕事の理解に差があるので社内のエンジニアと請負でも差がありそうですね、私は前者ですが。以下少し詳しめに・・

    > 優秀なエンジニアは、いうこと聞かない人が多いし、どっちかというと採算なんて余り考えないし、
    優秀なエンジニアにもいろいろ種類があるけど採算考えないエンジニアはその点では優秀とは言えないです。どちらかというと邪魔者です。こういう人もコントロールしつつ能力を生かせる部分で有効に活用していければと思うんだけど・・・

    > ソースがきれい=技術力がある、でそこからどういう利点があるとかいう以前に、ビジネスで負けてしまえばダメだってことを理解できない人たちは、自分たちの作業が大変になるという小さい視野で物事を判断してるかもしれないのです。
    ずっと使って行く前にプロジェクトが採算割れで潰れてしまえば本末転倒なのでそうならないことを前提にしつつ、それでもどう作って行くか自由度はあるのでコードが後々混乱する程度をできるだけ少なくする、その舵取りが難しいです。ソースが綺麗なんてのがほとんど意味をなさない分野はあるけど、コードをずっと使っていく予定の所でもコードの質に起因するビジネス上のアドバンテージディスアドバンテージはかなり過小評価されてると思います。3年で捨てる計画のプロジェクトなら気にしなくていいと思います。

    > Windowsのビジネスモデルをどう考えるかですね。バグ修正をサービスパックとかいう名前で提供したりする行為を。でもって、Appleもそういうビジネスモデルを取り入れて成功しているという事実を。
    未完成な物や、バグありのものを出すけど後でサービスパックで修正するよという設計思想をあの規模のソフトウェアで貫くのは簡単なことではありません。コードがメチャメチャでも良いという考えとは別物だと思います。

    > 生命(医療系)や金銭(銀行系)に関わるものと、そうでないものが同じ信頼性が必要とされるかです。ここで、いうのは品質や信頼性であって、ソースがきれいだとか保守性に優れているとかそういいう話ではありません。
    賛成です。綺麗なコードは少ないらしいですがいろんなレベルの人が挙動が変更しないことを絶対視しながら大人数で長期間作っていったものなのでそうなるのは理解できます。保守費用に関わるのでコードの保守性が無関係、ではないです。

    > キレイなソースをかくエンジニアは迷惑ではないのか?
    > キレイなソースを書くことが正しいかどうかとかは別の話で、決まったことには従ってもらわないと、また優先順位を考えて作業比重を考えてもらわないと、迷惑することも多々あるでしょう。
    たまにいますが期日等を無視して綺麗なコードを書こうとする人は大迷惑、問題外です。普通はそういう人をクリティカルな所につけないですが必ずそうなる訳ではないのがつらいところ。ソースが綺麗かどうか気にしない人もそれに劣らず迷惑です。理想を追いつつ現実から目を背けないバランス感覚のある人がいいですね。ビジネスの観点からは汚いコードはリスクと捉えるのが妥当だと思います。

    > 保守性の高いソースのほうがエンジニアは幸せになれるという妄想
    個人レベルではなんとも言えません。糞コードと格闘して対応できる自分にプライドを持っているエンジニアを見た事もあります。人によります。

    > 技術力に対して、お金を支払われない可能性があるわけです。また、顧客にとっては技術力よりも、きちんと実現されたか、要望を満たしてるかのほうが重要なわけで、直接、技術力にお金を払っていません。
    きちんと実現されたか、顧客は自分の本当の要望を満たしてるかなかなか判断できないのが難しい。顧客自身は知らなくても高収益など自分が本当に求めてることを実現する手段の一つが綺麗なコードであることは多いと思いますが、顧客の本当の要望を見抜け専門的な意見を意図を含め正しく伝えられるエンジニアが少ないのも難しい・・・

    > 人間というのは身勝手でワガママなんです
    > 経営者やプロマネなどは、直接汚いコードでつらい目に合うことがないので、最終的には収益が上がる方法を選ぶわけですね。
    多くのエンジニアも身勝手でワガママです。会社が損をするのがわかっていても自分にとって収益が上がる方法を選びます。気付かれずにやるのは簡単です。エンジニアのビジネスと考えると手抜きエンジニアが悪いとも言えないですが。

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

  2. 名前:管理人 : 投稿日:2012/12/06 00:37

    >未完成な物や、バグありのものを出すけど後でサービスパックで修正するよという設計思想をあの規模のソフトウェアで貫くのは簡単なことではありません。コードがメチャメチャでも良いという考えとは別物だと思います。

    そうだと思います。

コメントを残す

メールアドレスは公開されません。
また、コメント欄には、必ず日本語を含めてください(スパム対策)。