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