読者です 読者をやめる 読者になる 読者になる

フリーランスITエンジニアのすすめ

フリーランスITエンジニアの働き方についてのブログです

面接で過大評価されてしまうというリスクとその対応策

エンジニア面接における過大評価

客先常駐フリーランスエンジニアという立場上、常駐先に面接を受けに行くことがぼちぼちあります。

面接では、現場のリーダーであろう面接官が、初っ端から、こちらを見下した態度をとってくるということが、よくあります。これは、エンジニアを提案する側である営業がしばしば見当はずれなエンジニアを連れて来るために、彼らが無駄な面接を多くやらされているせいであって、私のせいではありません。

 

このように面接官は、こちらに対してあまり期待していませんから、「Junitってなんだか知ってますか?」とか「リフレクションって知ってますか?」みたいなひどく初歩的な質問をします。

通常のJavaエンジニアならば、難なく回答できるでしょうし、むしろ「馬鹿にしているのか?」という印象を受けることでしょう。

しかし、考えてみれば、こういう質問をするということは、普段、この問題にすら回答できないエンジニアを面接しているということであって、ある意味、面接官に同情してしまいます。

 

私はこのような質問に対しては、普通にごく一般的な回答します。すると、若干レベルを上げた質問をされるのですが、それに対しても同じように回答します。

 

この時、まるでビズリーチのCMのような感じで、面接官の期待が膨らんでいっているのがわかります。これが面接の恐ろしいところで、当初の期待水準がマイナスであった分、ある程度まともな人間が来ると、超優秀な人材が来たように思うのでしょう。

 

最終的には、いきなり「リーダーとしてこのプロジェクトを仕切ってほしい」とか言われてしまったり、参画早々、かなり重要なアーキテクチャ上のキーテクノロジーの方式を提案させられたりとかします。初対面の野良エンジニアに一体何を言うのかという感じですが、彼らは本気なのです。

 

正直なところ、私は意識の低い人間です。仕事を通して成長しないなどとこれっぽっちも思っていません。だから、このように過大評価されて、いきなり難しい仕事を任されるのが嫌なのです。

これは個人の価値観の問題ですから、私がそう思う以上はそうなのです。

 

考えてみれば、このように面接で過大評価されるということは、それはそれで大きなリスクなんです。面接を落ちるのは大したリスクではありません。結局、案件に参加しないので、実質的な被害はゼロです。少し時間を無駄にするだけです。

一方、面接を通ってしまうと、仕事をしなくてはなりません。そうすると、面接で過大評価されたことがマイナスに響いてきます。

下手に面接を通るくらいなら、素直に落ちた方が幸せです。

 

過大評価されないための面接術

この問題を解決するためには、過大に期待されない程度のレベルで面接を通過する必要があります。

つまりは「ワーカーとしてそこそこ使えそうだが、重要な仕事は任せられそうにない」と相手に思わせることを理想であると思います。

それを踏まえ、私なりの面接術を考えてみました。

「〜については、知っています。ただし、現場で使ったことはありません」と言う

やはり、技術について分からないふりをするのは難しいです。こちらもエンジニアである以上、ついつい聞かれたことには正直に回答してしまいます。これはエンジニアの性ですから、どうしようもありません。

したがって、必ず最後に「ただし、現場で使ったことはありません」とつけることで、こちらのスキルに対する信ぴょう性を少し下げておきましょう。これにより、過剰な期待をされることを防ぐことができます。

 

コミュニケーション下手をアピールする

コミュニケーションが下手な人間には、顧客折衝など重要な仕事を任せることはできません。

したがって、絶えず「上流工程は苦手です」や「エンドユーザーとは話したくありません」などといったように、コミュニケーション下手をアピールしましょう。

これにより、コミュニケーションスキルを要求される仕事をまかされなくなります。

ただし、そもそも面接でハキハキ話してしまうと、いまいち説得力がなくなってしまいますので、演技力が求められます。

 

まとめ

初めての現場で知らない人たちと働くというのは、参画する側も受け入れる側もストレスがかかります。これは仕方のないことです。エンジニアの力量を定量的に測る方法があれば、このように過大評価されるリスクもなくなりそうですが、それはできません。よって、最終的には忍耐と諦めが必要になります。

 

ちなみに私は、最近はBy Nameのアサインがほとんどですので、そもそも面接を受けていません。

 

 

 

 

 

 

 

 

 

 

 

考えてみれば、自分がフリーランスになったのも逃げだった

shinya-sheep.hatenablog.com

辛かったら逃げてもいいと思います。逃げることも戦略の一つですし、今の場所に噛り付いて、頑張っても問題が解決するとは限りません。

「逃げ」というと後ろ向きなイメージがありますが、つまりは、これって「選択」なんですよね。学校をやめたり、会社を辞めたりなんてことは、一般的にマイナスなイメージがありますが、それで自分の人生がよい方向に進むならば、躊躇する必要はないと思います。

 

振り返ってみれば、自分のこれまでの人生も「逃げ」ならぬ「選択」の連続でした。

 新卒入社した会社を半年でやめる

一番最初の「選択」は、これです。

金融系のユーザ系システム子会社に入社した私は、仕事のつまらなさと、人間関係のストレスにより、半年という短期間で辞めました。

そこそこ大きい会社のシステム子会社ということで、安定性を求めて入社したのですが、ただただHTMLを修正するという仕事に飽き飽きしたのと、指導担当の先輩と折り合いがよくなく、あっという間に嫌気がさしてしまいました。

さすがに半年で辞めるということには抵抗がありましたが、気まぐれで、独立系ソフトハウスの転職面接を受けたところ通ってしまい、転職することにしました。

転職先のソフトハウスを7年で辞めフリーランス

転職先 では、そこそこ満足できる仕事をさせてもらっていたと思います。

ただ、案件の選択権がないことは不満でした。客が明らかな人格破綻者で、それによってこちら側が多大な精神的ストレスをこうむっている場合でも、逃げさせてもらえませんでした。ちょうど、リーマンショックによる不景気とも重なっていて、敵前逃亡など許されることではなかったのです。

 

職場環境を考えるうえで、お客さんとの相性というものは一番大きい要素です。

それを踏まえると、お客さんを選択できないというのは、会社員の大きいデメリットであると感じました。

まぁ、これは結局は嫌いな人間から「逃げたい」ということなのですが。でも、「逃げたい」のだからしょうがないんです。自分はそんなにタフじゃないですから。

だから、私は「選択」ができるフリーランスになることにしました。

 

フリーランスになってからは、どうしても性格が合わない人がいる場合など、人間関係上のストレスがある場合には躊躇せず現場から抜けるようにしています。職場環境は結局は人間関係ですからね。変な人間とは関わらないことが正解です。

誰に何と言われようと自分の幸せが第一ですからね。

まとめ

元の記事にもありますが、結局は「人運」です。ですので、サイコロの出目が悪ければ、サイコロを振りなおせばいいんです。

そして、もっと気軽にサイコロを振りなおすにはどうしたらよいかを考えた結果、私はフリーランスという働き方を選択しました。

 

サイコロの出目が悪くても我慢するのが大人という人もいますが、たまにはサイコロを振りなおしてみてもよいのではないでしょうか。

 

 

 

 

 

「プログラマ35歳定年説」は、高齢プログラマはうるさいから使いたくないというマネジメント側の好みの問題

 

www.smartstyle-blog.net

プログラマ35歳定年説」って、定期的に議論されるんですが、何なんですかねこれ。どこでこんな言葉が生まれたんですかね。昔は、やっぱりそのあたりで定年してたんでしょうか。

35超えると、体力的に厳しくなってくるとか、新しい技術にキャッチアップできなくなってくるとか色々といいますが、正直なところよく分かりません。

この手のエントリは、たいがい、「35超えてもまだまだいける。つまり35歳定年説は嘘。」か、「やっぱり少しずつ衰えてくるから、ちゃんと勉強しよう。」のどちらかに落ち着くパターンが殆どですが、今年35になる私なりに少し考察してみたいと思います。

 

そもそも年取るとプログラム組めなくなるのか?

やっぱり、35超えるとプログラムが組めなくなるとか、パフォーマンスが落ちるとかいうのは完全に嘘だと思いますね

ってか、周りを見ると50近い人でも普通にプログラミングしてますからね。技術的なところだけでいえば、経験がある分、若い人よりも信頼できるんじゃないんですかね。

年連別のパフォーマンスを定量的に測定したわけではないので、なんとも言えないのですが、若ければ有利というのはなんか違うような気がします。

まぁ、この辺の話は、今まで散々議論されてきたところで、一般的にもこのような認識なんじゃないですかね。

 

とはいえ求人面では厳しくなってくる

フリーランスエンジニアの募集要項を見ると「40歳以下」とか、年齢に制限が付いているところが多いです。

なんでこんな制限つけるのかということなんですが、どうやら、使う側が高齢の人を嫌がるから、らしいのです。要は、我が強くて、言うことを聞いてくれないということなんでしょうね。

言ったことを、反論せずに素直にやってくれる人を好むリーダーって多いので、そういうところでリスクの高い高齢プログラマは敬遠されるのでしょう。

 

このように、高齢プログラマを敢えて採用しない案件があることで、結果として、肩身が狭くなり、ある一定の年齢を超えたら仕事が取れなくなってしまうという背景はありそうです。まぁ、それにしても35歳は早すぎると思いますが。

 

まとめ

結局は、うるさいジジイは使いたくないという、スキル面の問題ではなく、使う側の気持ちの問題があるのではないかと思います。

とはいえ、IT業界は人材不足傾向はどんどん強まってますからね。高齢であろうと何だろうと優秀なら仕事はあると思います。

 

ちなみに、年齢でフィルタリングされるのって、飽くまでも公募の場合ですからね。独自のコネ経由でのオファーなら、お客さんもプログラマの人間が分かっているので、年齢なんて関係ありませんから。

このブログでは、度々、エージェント経由で仕事とるよりも、コネを重要視したほうがいいと主張していますが、この問題にもつながってきますね。

 

 

 

 

 

 

 

難易度の高い仕事を頭数で解決しようとするバカな上層部

ITの仕事の中には一定以上のスキルがないと解決できない問題があります。

たとえば、アプリケーションフレームワークの設計実装がそれにあたります。インターフェースの策定とか、難しい仕組みの実装は、いわゆる量産型プログラマにはできません。

これらの仕事を成し遂げるには、一定以上のスキルが必要なので、頭数では解決できないのです。0をいくら足しても0の状態です。

 

ですが、SIの上層部にこの問題が分かっていない連中が多いです。プロジェクトの遅延に対して、必ず、要員の追加で対応しようとします。しかし、追加される要因もまた、スキルの低い量産型プログラマであるので、いつまでたっても成果は0のままです。

これは、プロジェクトが泥沼にはまっていく一つのパターンですが、上層部の技術に対する無知が原因です。

これは完全に工数という言葉の落とし穴ですね。工数が足りなければ要員を追加すればいいという考え方なのです。

それより、技術が分かる優秀な人間を単価を高くしてでもいれればいいのですが、そういう発想が全くないのです。単価は技術力ではなく会社のランクによって決まりますからね。そもそも、優秀な人を高い単価で現場に入れることができない。

っていうか、優秀な人ってそういう案件を選ばないですけどね・・・。

 

まぁ、そのような様々な要因があって、プロジェクトがどんどんクソ化していくのですが、これはプログラマのスキルの問題というか、スキルの低いプログラマの使い方の問題のような気もします。

以前、以下のエントリでも書きましたが、スキルの低いプログラマを雇うこと自体は問題じゃないんですよね。ただ、その使い方はちゃんと考えないといけません。

freelance-it.hatenablog.com

マンパワーでどうにかなる仕事と、そうでないものがあるわけですからね。

そのあたりについて、上の人たちには、ちゃんと認識して欲しいです。ハイスキルの人材は、高い金を払っても手元に置いておいたほうがいいと思うんですけどね。 

 

 

SIプログラマ(特にフリーランス)のアタリショック化が始まってるのでは

uxlayman.hatenablog.com

SI下請けプログラマのレベルが低いという話です。

たしかにこのレベルはひどすぎますね。一発退場レベルです。

同じチームにいたら絶対何もやらせませんね。寝ててもらいますw

 

とはいえ、現在のIT業界はとても好景気で、なかなかまともな人は集まりません。普通にJavaプログラミングができるひとですら貴重ですね。

 

なぜクソプログラマが現場に入ってくるか

この業界ってとっても間口が広いのです。人をいっぱい集めないといけませんから、大きい会社から小さい会社まで色々な規模の会社が人をいっぱい集めてきます。

そのなかから、使える人を探さないといけないのですが、それがとっても難しいのです。フリーランスのエージェントやSESの営業がいい感じにフィルタリングしてくれればいいのですが、彼らも使えないエンジニアを売らないといけないので、適当に人を持ってきます。

で、一番問題なのが、面接でスキルを見抜くのがほぼ不可能ということです。ITの仕事って、実際にやらせてみないとスキルがわからないんです。あと、スキルを見抜くための資格・免許もないですし。何かしら客観的な指標があればいいんですが、そういうものが全くないので、蓋を開けてみないとわからないんですよね。

 

この業界は、中抜き派遣業界ですからね。売る側は売れればいいので、買う側が品質を見抜けないのをいいことに、なんでもかんでも売りつけているってのが今の状況かなと思います。買う側もフィルタを厳しくすればいいのですが、頭数をそろえないといけませんからね。なかなかうまくいかないのです。結果として、使えないプログラマが現場に大量に投入されてしまうのですね。

 

今まで以上にアタリショック化する労働市場

以前よりフリーランスプログラマが増えてきています。背景のわからない野良プログラマがどんどん現場に入ってくるようになっている状態です。エージェントが品質を保証してるのならいいのですが、エージェント側もそのプログラマの過去の経歴について真偽を確認しているわけではありませんからね。正直なところ、そのプログラマがどんだけまともな人なのかというのは、本人以外の誰にもわからないでしょう。会社員プログラマなら、そのプログラマの負の歴史は少なくとも、所属会社には記録されますが、フリーランスだと完全なヒット&アウェイできますからね。

 

この状態を許しておくと、いつかアタリショックに近い感じになってしまうのではないかと思ってます。このブログでは以前よりこの問題について危惧していましたが、手配師の方々もそろそろ自重しないとフリーランスエンジニア労働市場そのものが崩壊しちゃうのではとか思ったりします。

今は景気がいいのですけど、需給バランスが崩れた瞬間に単価が崩壊しそうで怖いですね。

 

まとめ

プログラマのスキルをうまい具合に外から見えるようにする仕組みを作るというのと、プログラマ労働市場にある程度の参入障壁を作らないとまずいんじゃないですかね。

フリーランスの大手エージェント各社は広告打ちまくって、頭数を集めたいみたいですけど、いい加減その辺を考えないといけない時期なんじゃないですかね。

 

 

 

抽象度をどこまで上げればいいのかということと、オブジェクト指向的アプローチがSIで流行しない理由

以下のブログを読んでみて、自分もポエムを書いてみたくなりました。

watanabek.cocolog-nifty.com

blog.hidenorigoto.com

 

プログラムって、機械と人間の両方が読むものなんですよね。ですので、そこには表現の抽象度という概念があります。機械よりのものは抽象度が低いとし、人間よりのものは抽象度が高いとされています。

 

で、この抽象度というものを、どのレベルに持っていけば、みんなが幸せになれるのでしょうか。

抽象度を極端に下げていくと、機械語とかアセンブリになるんですが、それはあまりにも人間側に都合が悪すぎて生産性が低くなってしまいます。なので、一般的な業務システムなんかはJavaとかで作るのが普通ですね。

これはプログラミング言語レベルの抽象度の話ですが、プログラムの構造自体を工夫して抽象度を上げていこうという考え方もあります。

オブジェクト指向分析設計とか、今流行のドメイン駆動設計がそれにあたります。業務の言葉を使ってプログラムを書いていったり、プログラムの作りを業務のモデルと繋がるようにしようとする考え方ですね。

 

一般的に、この抽象度というものは高くなればなるほどいいと思われています。たしかに、プログラム自体が実際の業務の構造を表現していた方が、わかりやすいと思います。

 

しかし、SIの文脈でいうと、これは微妙かなと思うんですよね。どこまでも抽象度を上げていけば、プログラマがハッピーになるかというと、そうでもないような気がします。

だって、そもそもの話ですが、プログラマって業務わかっていないですからね。

SIのプログラマが読む詳細設計書は、完全なシステムの処理ベースで書かれていますし、業務色が完全に抜けてしまっています。要はトランザクションスクリプトです。

その状態でプログラマが、やれドメイン駆動でやるとか言っても、まず、インプットの詳細設計書が抽象度が低すぎちゃって、そこから抽象度を上げる方向に逆翻訳をしなきゃならなりません。

プログラマって、SIプロジェクトの中でも、抽象度が低いレベルの仕事を担当する人たちなので、一概に、抽象度を高めて、かっこいいプログラムを書く方法を教えても、彼らにとって豚に真珠のような気がしてなりません。

 

オブジェクト指向分析設計が全く流行しなかったのって、このあたりが原因じゃないかと思うんですよね。

まぁ、今は、オブジェクト指向分析設計は完全に死語となってしまって、ドメイン駆動設計の時代ですが、10年後、それがどういう文脈で語られるものになるのか、すごく興味がありますね。

 

 

 

 

 

 

フリーランス準備のために会社員をやることの是非

ネタ(決めつけ煽り)にマジレスです。

www.ikedahayato.com

フリーランスになるための準備として、会社に入ることが有効かどうかということについてです。イケハヤ氏の主張としては、「会社に入っても力つかなくね?」ということみたいですが、まぁこれは完全に煽りでしょう。会社員としてやってても、もちろん力つきます。人それぞれでしょうが。

まぁ、イケハヤ氏は、生き馬の目を抜く世界に入るっぽいので、会社員なんかでぬるぬるやってたのでは、ぜんぜんだめってことなんでしょうねぇ。

 

それはともあれ、これを踏まえたうえでですが、わたしはやはり、「初めは会社員からがいいと思うよ」ってのが本音ですね。もちろん、SIのエンジニアという文脈に限定した話ですが。

まず、新人研修という制度がおいしすぎます。お金をもらいながら、プロの研修講師に教えてもらえるわけですから。企業向けの研修ってお金かけてますからね。それを業務時間中にお金をもらいながら享受できるってのはすごいことですよね。

あと、未経験の人間が仕事を取るってのはすごく難しいことですが、会社員なら会社が勝手に仕事をくれます。言われたとおりにやっていれば、職歴が自動的に作られていくわけです。これもすごいことです。

新卒でフリーランスでやろうと思ったら結構大変ですからね。営業のカモにされるかもしれませんし、最初はすごくグダグダになりそうです。それをふまえると、ある程度社会人経験を積んでから独立したほうが効率がいいと思います。

 

ってか、フリーランスであること自体にもこだわらないのが本当にフリーランスだと思いますけどね。どういう雇用形態ではたらくかなんていうのは、結局その場その場で最適なものを選択すればよいのです。

会社員になった方がいいと思うのだったら、会社員になる。それが本当の自由な働き方だと思いますけど。

 

似たような話は以前のエントリでもしていますが、会社員のほうがコネが作りやすい場合があるんですよね。それを踏まえたうえで、初めからフリーランスでやるか、会社員でスタートすべきなのかは、個人の評価関数で決めればよいと思います。

freelance-it.hatenablog.com