企業で開発作業をしているエンジニアと話をすると、大体みなさん疲弊しています。
もちろん、全てのエンジニアの方がそういう訳ではなく、会社の環境がとても嫌だという匂いがプンプンするエンジニアの人は、間違いなく疲弊しています。
もちろん、周囲の人や職場環境により、楽しい楽しくないという感情は大きく変わると思いますが、エンジニアってプログラムを書くことが好きな人が多い反面、
製品のクオリティをどのくらい素晴らしいプログラムを書いたかに終始しているエンジニアの人と話をすると、こっちが疲弊しそうになるぐらいつまらないので、
今回はそうしたエンジニアの人を少しでも気付きを知ってもらい、誰もがハッピーになる法則を伝えられればと思い記事を書きます。
仕事がつまらないのではなく、ゴールが見えていないだけ
仕事は必ずゴールがあるはずですが、WEBプログラムを作っていると、常に修正や機能追加を行なう日々が続いてゴールなんて皆無に感じる時があります。
そうした環境はもはや地獄であると言っても良いのですが、こうした事態はエンジニアが作っているという一面もあります。
もちろん、エンジニアと言っても、立場もあれば、役割も様々なので、全てのエンジニアというわけではないが、楽しく仕事をするエンジニアの特徴の一つに「タスク管理がうまい」という点があります。
自分でしっかりと、いまやっている仕事の何がどうなれば完了になるかを明確に設定できるという事です。
新人エンジニアや、若手のエンジニアの場合、上司や先輩の言うとおりに動くことが仕事になってしまい、自分でゴールがセットできないという状況もあります。
でも、人から頼まれた事をプログラム作業して、納品して、「あれが違う」「これが違う」という意見をもらい、さらにそれを修正するという堂々巡りにうんざりしているエンジニアは、間違いなくタスク管理が出来ないタイプです。
納品した先に、どういう反応が返ってくるかを予測できなければ、間違いなく言われるがままに仕事を振り回される事は誰が考えても明確です。
プロの自覚があれば、確実に仕事を完了するために、どういうプログラムをコーディングすればいいかは、自ずと見つかってくるものです。
疲弊するレベルが低いという点も、第三者視点を持って自分で測ってみよう。
プログラムを書くことが目的のエンジニア
プログラミングは好きで、言語オタクと言ってもいいぐらいのこだわりっぷりのエンジニアは、一見、優秀なエンジニアに思われがちですが、
企業においてのプログラミングは、ほとんどが製品開発かサービス開発です。
この点を二の次にして、プログラミングにこだわるのは単なる道楽でしかありません。
ちゃんとした管理者がついていれば、そうしたエンジニアを野放しにするはずが無いのですが、プログラム能力の低い上司がこうしたエンジニアの上に就いたとしたら、かなりの確率で言いくるめられてしまう事は間違いないでしょう。
何故なら彼らは非常に口が達者という特徴も持っています。
そして、こうしたエンジニアは、人の言う事を聞かないという特徴もあり、本来使いづらい部下としてカテゴライズされるのですが、キレイなコードと、技術理論という縦で、完全武装してしまうので、中々やっかいな人材でもあります。
そもそも、こうしたエンジニアは、仕事の進め方が早ければ何にも問題はないのですが、こだわりが強くて仕事進行が遅い場合は、ゴールを明確に設定して上げる必要があります。
色々な障壁はあるが、プロジェクト進行が遅いが、拘っているエンジニアがいる環境に困っている企業の人は、人員構成変更をしてみるといいでしょう。
こだわりを捨てるがプロジェクトのクオリティを上げるには
エンジニアがもっともこだわるのは、以下の３つが多いでしょう。
1. いかにしてキレイなコードを書くか
2. 手戻りの少ないという理由におけるより複雑になった設計図
3. 統一という言葉が正論化される環境構築
コーディングは汚いよりもキレイな方がいいし、整理整頓されている方がいいに違いありません。
しかし、匠レベルにこだわる必要などは全く無く、どちらかというと、「悪」とされる程度のコーディングでなければ、すべて良しとするぐらいでも十分です。
よほど汚いのであれば、後ほどリファクタリングすればいいだけなのです。
「手戻りを少なく」という理由で、より複雑になってしまう環境も、あまり経験のないエンジニアが構築した際に陥りやすい結末です。
結果手戻りが増えるぐらいなら、シンプル構成にした方が誰が考えてもいいのは明確です。
そして、もっとも危険なのは「統一感がある」とか「整理されている」という、普通に聞くと、ソッチのほうがいいという印象を与えられた、システム構築の方向性。
これは、システム構築の序盤でも発生しますが、エンジニアは仕様を決める時にしばしばAとBのどちらが良いかを、仕様決定権限の有る人に聞きます。
その時に、「明らかに手戻りが少ないのがAで、後ほど苦労するのがB」というような言い方をします。
これは、非エンジニアの返答を誘導する最も効果的で確実な選択肢のない分岐質問なのです。
わかりますか？もう答えは見えているんです。
そして、その結果、プロジェクトが失敗した時に、「だってAって言ったじゃないですか！」と強い口調で、言われた非エンジニアは、時既に遅し・・・です。
巧妙な罠が張り巡らされていることに、後から気がつくでしょう。
製品構築とその後の売り上げに目線が行っているエンジニア
企業にとって、一番優先すべきエンジニアは、間違いなく、売り上げ貢献できるエンジニアです。
営業部門でもないのに開発者が売り上げ数値に興味を持つなんて違和感があると感じる人は、とんでもなく駄目な環境に身をおいているかもしれません。
自分の作ったモノが世の中に出て誰かの役に立つというのは、売上につながるし、エンジニア事態のモチベーションも上がります。
もちろん、売り上げが大きくなるものであれば、企業も潤い、役に立つ商品なのであれば、ユーザーも大喜び大絶賛です。
創造してみると分かりますが、こうした状態になると、誰も損をせずに得をしている状態です。
これが「winwinの状態」で成功の法則なのです。
この状態を作るのが、エンジニアの仕事という認識を、エンジニアが持てていなければ、その企業はこの先大きく失敗することは目に見えているかもしれませんね。
今回僕が言いたかった事は、エンジニア評価をするポイントは、企業にとってプラスになるエンジニアかどうかを見極める必要があり、毒になるエンジニアも稀にいるので要注意せよという事です。
少し毒の入った内容になりましたが、winwinの環境を作れるエンジニアは決してコーディングがキレイなエンジニアとイコールではないという事です。
