システム開発ってプレッシャーすごそうだよね～
そう？そんなことないよ。
だってお客様の業務に影響あるんだよ？利益に左右するかもしれないじゃん。
いや、うちはお客様のこと知らないし、そんな実感ないから適当だよ。
そうなんです。
実は「責任感」や「使命感」が強いエンジニアは少ないのです。
ようするに適当なんです。
適当なプログラマの思考回路
ITエンジニアって頭が良くて、几帳面で、努力家、そんなイメージを持っている方も多いと思います。
実はそんなことありません。
ズボラで適当で、与えられた仕事を期限までにこなせればそれでいいというエンジニアも非常に多いです。
以下の記事でもテストの適当さについては触れましたが、
テストに限らず、ほかの作業でも適当です。
例えばプログラミングを例にしてお話します。
以下の記事で説明した通り、技術力のあるプログラマなんてそうそういません。
現場ではこんな発想をするプログラマばかりです。
コピペしてきたけど、意味が分からない。でも動くからいいか。
プログラマは「パクる」ことは一流です。
必要なものを探し出してコピペすることが大得意です。
でもパクっているだけなので、理屈がわからないことも多いです。
だって目的は設計書通りにプログラムを書くことが仕事ですもん。
ここはこうした方が良いと思うけど…設計書に書いてないからいいか。
基本的には設計書が正の世界です。
いくらもっといい案があったとしても、それを口に出すプログラマは多くありません。
だって、自分の仕事が増えるだけですもん。
え？バグが見つかりました？違いますよ、それは仕様です。
「仕様です。」
ITエンジニアの口癖のひとつではないでしょうか（笑）
バグが見つかると、
「仕様です」 vs 「バグだろ」の戦いが起きることもよくあります。
プライドが高いエンジニアはとても多いです。
自分の非を認めたくないことも多々あります。
「気づいてたけど設計書に書いてなかったからやらなかった。自分は設計書通りにやったよ。」
と豪語する人もいます。
いや、気づいてたなら言ってよ、と言いたくなりますが、こういう人もいるのが事実です。
昨日までエラーになってたのに今日はエラーにならないな、まあ動いてるんだからOKOK!
「エラーが再現できない」ということはよくあります。
何か手順が違うのか、それとも状況が違うのかわかりませんが、同じことをしているつもりでも同じエラーを起こそうと思っても、なぜかもう二度と起きないことが度々あります。
不思議ですよね。
一度エラーになっているのですから、何かしらの不具合は必ずあるのに、起こそうとすると起きない。
これでは直すための調査をすることができません。
こんなときエンジニアの思想はどうなると思いますか？
「よし、もう直ったのか、じゃあ、いいか！」
です。
そんなわけありませんよね、バグは勝手に直るものではありません（笑）
でもたった１つの謎の現象に時間を使っていては、期限までに完成させることができなくなってしまいます。
ＱＣＤというという言葉があります。品質、コスト、納期を英語で言った場合の略語です。
この中で一番大事なのはどれだろう？と議論されることがあります。
コストはいったん置いておいて、注文する側からすると品質と納期どちらを優先しますか？
例えば、あなたが家を買ったとします。
「予定日より遅くなりそうだけど完璧な家」と「予定日に出来上がるけど、柱が足りない家」
どちらが良いですか？
例えば、あなたがレストランに行くとします。
「時間がかかるけど、美味しい料理」と「早く出来るけど、味がしない料理」
どちらが良いですか？
そうです。一番優先されるべきは「品質」であると私は思います。
システムでも同じことが言えると思います。
でも実際に現場で最優先されるのは品質より納期である傾向が強いのです。
以下の記事でもエンジニアに必要なのは「妥協力」であると述べていますが、そういった意味では「妥協力」のあるエンジニアは多いです。
お金を出しているお客さんからすると「おいおい、勘弁してくれよ」ですよね。
このバグの原因わからない！！そうだ、そういう仕様だということにしよう。
いやいやいや！と思いますよね
でもよくあります（笑）
「バグは夜更け過ぎに仕様へと変わるだろう」という有名なジョーク格言があります。
ゴロ的に聞いたことあるかもしれませんね。山下達郎さんのクリスマスイブのオマージュですね。
実際に全然わからないことがあれば「そういう仕様にしよう」のひとことで片づけてしまうことがあります。
本来、設計書通りに作るはずのプログラムですが、プログラムに合わせて設計書を直してしまうという禁断の技を使います。
1つのバグに苦しんで苦しんで、気づけば夜遅くに。
そんな時は「よし、仕様だな」でクリアです。
「仕様です」は本当にエンジニアの魔法の言葉です。
なぜこんなにも責任感がないのか？
「責任感」の意味が違うからです。
以下の記事でも書きましたが、ITエンジニアの大半は「下請け企業」です。
下請け企業の「責任」とは
「実際にシステムを使うお金を出したお客様に完璧なシステムを納品する」ことではありません。
実際には
「大手から発注してもらった仕事を時間をかけずに期限までに納品する」ことです。
大手のエンジニアは実際にシステムを使うお客さんと折衝し、いい関係を築くためや顧客満足度をあげるために切磋琢磨していますが、下請け企業には正直そんなことどうでもよいのです。
下請け企業のお客さんは発注元の企業です。お金を出している人、使う人のことなんてどうでもいいのです。
誰が使うかもわからないシステムですし、意識なんてほとんどしません。
「お客様第一」なんて無理
「お客様のことを第一に考え」と掲げている企業は多いです。
でも実際に下請けのエンジニアにそんな余裕はございません。
そのときそのときのプロジェクトのことでいっぱいいっぱいです（笑）
「お客様」より「終わらせることが第一」になってしまっています。
これがプライム案件（システムを使うお客さんから直接仕事をもらう案件）だとだいぶ意識は違ってくるとは思います。
多重下請け構造ゆえの闇ですね。
「まあいいや」が増えました。
私の大好きなバンドである10-FEETの「太陽の月」に収録されている「太陽4号」という曲がありますが、その中のフレーズです。
10-FEETの本来の意図とは意味は全くちがうのでが、このフレーズだけ聞くと「エンジニアの曲だ～」とうれしくなってしまうことがあります（笑）
すみません、余談でしたね。
とにかくエンジニアは「まあいいや」で成り立っているということです。
締めが蛇足で申し訳ないですが、以上となります。
最後までご覧いただきありがとうございました。