「仕事ができないITエンジニア」に共通する5つの特徴 - paiza開発日誌
内容がない記事ではあるのだけれど「多くのエンジニアから話を聞いた上で感じたことをまとめたものですが」という部分を読んで感じた事は、その意見を持ち寄ったエンジニアもさほどのものでは無さそうね。という程度
んー、これ本当にエンジニアが回答してるんかなぁ。
というかCTOというポジションにつける人がこの程度の意見を述べるとか、正直やばい感じがして僕もやる気がおきなくなるなという感じ。
paizaってその程度なんかなぁ。
いろいろ思うけど、幾つか言及してみる。
『「最初から完璧を求めすぎて時間をかけすぎる人」は別に優先順位をはき違えているわけではない』
これなぁ。
これ 本当にCTOというポジションの人がいってるんかなぁ。
まず、100%をいきなり目指してしまう人というのは、優先順位がわからないわけではなくて、単純にタスクの細分化ができていないだけです。
なぜなら、大抵の仕事はそもそも100%を目指すわけで、最初から60%や80%を目指す事などありません。
ただ、結果的に制約条件により60%（その程度でリリースできるんか･･･）や80%という状態でもプロダクトアウトせざるを得ない状況に陥るわけで、その時にどのような状態にプロダクトがあるのか？というだけの事。
で、これができないというのは、まずはプロダクトアウトするという工程全体が鳥瞰できていないというケースが大半です。
プロダクトアウトするという工程全体を理解できると、まずはプロダクトアウトするための充足条件というものが理解でき、工程を分割する際にはその充足条件に対してわけて考える事ができます。
この時、何を優先すべきなのかというものが発生しますね、はい、ここで初めて優先順位というものがでてくるわけです。
が、そもそも100%のものを作る（目指す）という意味では、実はこれもそれほど重要ではありません。
むしろ依存関係について整理し、自分の工程と自分以外の工程の関係性が整理できれば、別に優先順位なんてものは理解しなくても問題ありません。
とどのつまり、相手が求めているタイミングにちゃんとしたものを提供できればいいわけで、つまりは工程を適切に細分化し、細分化したタスクを順次処理できればあとはどのようにでも仕事をしていただいてかまいません。
結局、ゴール設定がガバガバで、その原因は工程の細分化ができないという事であって、その理由をちゃんと伝えてあげれば大抵の場合は解決します。
エンジニアが優先順位などというものと戦うのは、大抵の場合は本人よりも本人以外の事情による場合が大きいのですよ。
この程度の事をCTOともあろうものが理解していないというのは正直驚愕です。
「疑問や課題感に鈍感な人」は単純にそのサービスやプロダクトに興味がないだけ
いやもうこれだけですよ。
なんかエンジニアをエスパーか何かと勘違いしているようですが、エンジニアもただの人です。
プログラムを書くからといって、あらゆるサービスに興味があり、あらゆるジャンルのプロダクトにワクワクするわけでもありません。
仕事である以上、糞みたいなプロダクトでも作らないといけないし、くだらないサイトでも金の為であれば作ります。
別にこんな事はエンジニアに限らず、普通の事務職でも同じです。その仕事が夢でいつもワクワク過ごせる人もいれば、就活の結果としてその仕事に就いたに過ぎず、ごくごく普通のモチベーションで仕事として対応している人もいます。
それはどちらも「普通」でどちらが良いという事はありません。
あえていえば、もしもその人が『企画職』として業務を担うのであれば、まぁ、ワクワクしない仕事の企画はムリなのでプロジェクトを変えるべきと助言します。
あと、エンジニアに幻想を持ちすぎです。
別にエンジニアの全てがあらゆる技術にあらゆるサービスに興味があり、新しいライブラリや言語はまずは動かしちゃうぞ！という人だけではありません。
そういった人は所謂ハッカー的な人であって、そのレベルが当たり前にゴロゴロいるわけではありません。
その部分をもって『仕事ができるエンジニア』とかいっちゃうのは「paizaだいじょうぶかな？」としか思えない内容ですが。
そもそも「共有されて価値のあるミス」以外はただの愚痴でしかない
これも幻想見過ぎだと思うんですけど、エンジニアの失敗事例が全て宝の山だなんておもってるなら、それは夢の中なので早く覚めてください。
エンジニアが共有して生かす事ができるレベルの有用なミスなんてものは、多くの場合で年に数回程度しかなく、それらは大抵の場合、チャレンジや大事故のような、非常に特殊なケースで生まれているものが大半です。
例えば、スケールアウトさせる時の失敗事例などというのは記事で読む分には非常に楽しいものですが、あんなものは日常的に発生するわけもありません。
あるあるネタは確かにごまんとありますが、それをもって価値あるミスで、その共有をする事をもって「仕事のできるエンジニア」とかいわれちゃうとまじつれぇわ。
それも実際に共有するタイミングも誰かが「やべー、××が○○になったわ！どうしよう」的なシチュエーションが起きたとき初めて「あー、それは△△するといいよ」みたいな会話になるわけで。
つまりは「求めよ、さらば与えられん」という事。
そして求めても与えられないのは、職場の問題か本人の人間性の問題に過ぎず、別に仕事ができるできないとはまったく関係ない。
「過信は良くない」、が、無駄な投資をしない事も良いエンジニアの適正ですが？
現場を知る人間であれば、昨今の技術的にカバーする事が求められる領域は、多くの場合で昔と比べて非常に広く、それも異なる分野にまたがり、非常につらいという事はもういうまでもない。
このような時代の中で、常に、全ての新しい事にチャレンジするなどというのは、あまりにもオーバーヘッドが大きすぎ、正直暇が相当あるエンジニアでなければやれない。
我々がこの時代で生き残るためには、何を学び、そして何を捨てるかという事を常に考えなければならないし、それができないエンジニアは技術の物量作戦により敗北する事となる。
その時もっとも良い方法は、代替手段がある事については、マストでないなら「今はやらない」という事を決断する事である。
新しい技術は確かに試したくなるし、投入してウェイウェイしたくもなる。
が、それ、お前の自己満足ではないのか？と自問自答し、あらゆるコストを考え、その上で検討に値するものだけを選択するという事が重要となる。
ベストとは何に対してベストなのか？
チーム適正に対する最適化なのか？それともコスト？コストの場合はイニシャルコストなのか、それともランニングコストなのか？
工期の短縮は、保守性についても考慮すべきだし、そういった全てがみれもしないのに「新しい技術いっきまーす」なんて人がCTOにいるなら、僕は確実にその会社の経営陣には「人選間違えてね？」というだろうね。
「IT技術やプログラミングが嫌い・興味が持てない」なんてのはもはや「仕事ができる・できない」には何も関係ない
これね。
もう極めつけ。
確かに「好きこそものの上手なれ」とはいうし、実際好きな人の方が成長しやすくはあると思う。
が、ちょっと待って欲しい。
本当にそうか？
僕が知る限り、昨今は、もう全然プログラムなんて好きでもないのに、バリバリの理系脳で複雑なアルゴリズムもさっくり実装できちゃう人なんてのは沢山いる。
かれらは仕事ができないのか？イヤそんな事はない。
むかしむかしは、プログラムやコンピューターを仕事とするというのは、それこそが専門職であって、そういった道を志すものだけが選べる、ある意味本当の専門職であった。
しかし時代は流れ、コンピューターなんてものが特別なものではなく、プログラム言語も視認性が高く高級言語しか存在しない、そして環境についてもさっくり準備できるこの世の中で、プログラムやコンピューターに関わる仕事に従事するという事はそれほど特別なことなのだろうか？
なぜこの仕事選んだ･･･といいたくなる人はいるが、それはそれ。
「メールの設定とかITの事は難しくてわからんよ」と、スマホを片手に言い放つおっさんと同じぐらい「じゃーおまえまずスマホかち割れよ」といいたくなる。
好きな方がいい、とは思うが、好きでないからといって転職をする必要はない。
ただ、プログラムを組む場合や、データの構造のようなものを思考すると頭が痛くなるような方は、流石にストレスが高すぎて健康面で不安もあるので、そのレベルであれば転職すべきだが、そのような事情でもないなら、好き・嫌いなんてのはどうでもいい。
野菜農家の息子が全員野菜好きなわけでもないし、養豚業者がみんな牛肉よりも豚肉を欲するわけでもない。
仕事は仕事、それ以上のものを会社にもたらす場合は、それはその人の個性としてプラスアルファーで会社が評価すべきで、プログラミングにそれほど思い入れがない人や、プライベートでもプログラミングに時間を割けない人の評価を「仕事のできないエンジニア」とする事なんてのはもう狂ってる。
本当に気持ち悪いね。
