言われた通りに動いて何が悪い。作業員の失敗は誰の責任か？

休日に自宅で技術の勉強をしていると、「この技術、仕事のあの箇所で使えないかな？」と思う部分が良くある。

アイデアから実現に向けて

もちろん、そんな時は、会社で提案、プレゼンして、採用されれば、社内ツールや製品として、世に出られるわけだが、 僕はCTOという立場なので、実は、こんな手間な事をするのは滅多になく、休み時間などで、チョイチョイと作って社内環境で「もう使ってます」という事で、本番までをかなり最短でやってしまう術を知っています。 はっきり言って、立場は関係なく、チョチョいと出来る人であれば、おそらく誰でもどの会社でもこんな感じだと思います。

できない人の言い訳

でも、チョチョイとできない人は、どうすればいいかと言うと、 「出来るように頑張る」 しかないと思います。 その人が、エンジニアを職業にしているのであれば、頑張っていない証拠である。 はっきり言って、エンジニアで技術を探求していない人は、ただの作業員ですよね。 もちろん世の中で作業員は必要です。 労働集約的な作業は、無くならないわけですから。 ただ、それが、サラリーマンに成り下がったエンジニアほど、タチが悪いというのが現状です。

「忙しい」が魔法の呪文

とにかく彼らは、「忙しい」というキーワードを言いたがります。 聞いてもいないのに、呪いをかけるかのように、浴びせてきます。 自分の技術不足でスキルが無い事を前提としているのに、時間が無いという言い訳が成り立つと思っています。 とても残念なのは、同じチームの他のメンバーです。 それによって、スケジュールは必ず遅延し、クオリティは、イマイチ。

決まっていうセリフが給料が安いから

この人種は、給料が安い事を言い訳の筆頭にします。 とにかく、モットーは、 「言われた仕事は、範囲内で確実にこなす」 という、生産性を無視した考えで、それに携わる会社内のメンバーやプロジェクトチームは、かなりの確率で踊らされます。 プロジェクトリーダーがしっかりしていれば、そんな事にはならないのですが、多くのプロジェクトは、開発経験者が求められ、彼らがリーダーという最悪環境も珍しくないのです。

本人は自覚が有るのか？無いのか？

ある時耳にしたのは、あるプロジェクトが遅延するとミーティングで決まった直後に、 「少し伸びて助かった」と、悪気もなく言っていたのを聞いたときに、本心が見えた気がした。 なんと、自覚はあるっぽいのだ。 信じられないが、これは事実で、こう言った人をエンジニアとしていても良いのだろうか？ CTOとしては、人事権限はないので、そういった人種の撲滅運動に努めることを考えました。

言われた仕事をこなす姿勢

エンジニアにとっての姿勢で、僕のオススメは、言われた事を噛み砕く姿勢です。 日本の企業にありがちなのが、 「クライアント絶対服従型」 で、とにかく言われた通りの出来上がりを目指すのが多くの開発現場になっているが、 ここでの会話でのあるあるネタが、 「この仕様、問題ありそうだけど大丈夫かな？」 「クライアントが問題ないと言ってるので大丈夫でしょう」 これで仕様が決定してしまいます。 お金を出している人が良いと言っているので、問題視しない。という事実は、サンノゼでは通用しないでしょうね。 どうやら、アジア圏には今考え方の人種が多いらしく、世界に出ていけない思想はここにあると思われます。

開発員一個人のやるべき事

言われた事を噛み砕くとは、仕上がりが自分の考える一番サイコーのモノになるかどうかにポイントを置いて欲しい。 1.時間がなくて、仕様を大幅に変えられない。 2.難しいコードが並ぶので出来るだけ簡潔なプログラムにしたい。 3.完成後の運用が大変になるので、今回はここまでの仕様にしたい。 とにかく、全ての言い訳が、自分がスキルがないことが前提になっている。 出来るのであれば、出来る人をその場でアサインしたり、最低限の遅延で、出来上がる計画を立てる、という努力をすべきである。 よく見る、シチュエーションとして、出来ないことを前提に、エンジニアでない人に、仕様を決めてもらっている場面です。 クライアントの場合もあるし、クライアントとのはしご役の人が多いですが、 残念ながら、このチームからは、先進的な商品は生まれないと、残念に思います。

あるべき姿

エンジニアは、全てのプロジェクトが成功するわけでもなく。 アイデアは別の人だが、実現するのがエンジニアというパターンが多く、製造担当責任を担うという事を理解しなければならない。 携わったプロジェクトは、開発したエンジニアの実績であり、成功と失敗は、後に自分に降りかかってくることを忘れてはいけない。 現実に常に成功しているエンジニアも存在しますよ。 そうなる為に、勉強してみてはいかがでしょうか？