paiza開発日誌

IT/Webエンジニア向け総合求人・学習サービス「paiza」(https://paiza.jp ギノ株式会社)の開発者が開発の事、プログラミングネタ、ITエンジニアの転職などについて書いています。

「エンジニア採用したい」と言う割には面接が下手な企業が多すぎるという話

f:id:paiza:20190307134227j:plain
Photo by Simon Cunningham
f:id:paiza:20140916135428p:plainこんにちは。谷口です。

paizaはITエンジニアの転職・就職サービスなので、エンジニアを募集している企業の採用担当の方から「エンジニアがほしいのに全然採用できない」「採用したいと思った人に辞退されてしまう」といったご相談を受けることもよくあります。

残念ながら応募者からの辞退が続くような場合は、採用する側が「面接でエンジニアに嫌われるようなこと」を知らずにやらかしている可能性が非常に高いです。

たとえば

  • 人事担当者だけでエンジニアを面接したら辞退されてしまった
  • 面接が始まってすぐに志望動機などを聞いたら「は?」という顔をされた
  • 面接の最後に会社説明をしたが、あまり興味を持ってもらえなかった

といったことはありませんか?

面接でのこういった行為は応募者の志望度を下げ、辞退を招く原因となってしまいます。本当に優秀なエンジニアを採用したいのであれば、面接の進め方の改善が必要です。

今回は、エンジニア募集企業の採用担当者の方に向けて、エンジニアの面接で話すべき内容や、面接の進め方などについてお話しします。

エンジニア採用がうまくいかない、途中で辞退されてしまう、よい面接の進め方がわからない…といった方の参考になればと思います。

そもそもエンジニアの採用面接ってどんな場なの?

エンジニア採用を担当されているみなさんは、面接をどのような場だと思っていますか?

面接とは、採用する側が一方的に応募者を選ぶ場ではありません。

特に超売り手市場が続いているIT業界では、むしろその逆で「優秀なエンジニアに自社のことを紹介し、興味を持ってもらい、選んでもらう場」であると言っても過言ではありません。

この意識が抜けていると、まず優秀なエンジニアを採用することはできません。

エンジニアの採用面接では何を目指すべきか

上記の続きでもありますが、面接官がエンジニアの面接で目指すべきは

  • 応募者に自社への興味を持ってもらうこと
  • 採用したい応募者に、とりあえずでも「次の選考に進んでみるか」と思ってもらうこと
  • 不採用の応募者にも「悪くない企業だったな」と思ってもらうこと

です。

なぜか。さっきも言いましたが、優秀なエンジニアは、今や引く手あまたの超売り手市場で、転職先などいつでも選び放題です。

パーソルキャリアの転職求人倍率レポートによると、2019年1月時点で全体2.13倍に対し、IT/通信は5.63倍と、依然高い水準を維持し続けています。(※転職求人倍率=求人数(採用予定人員)÷転職希望者数)
www.persol-career.co.jp

気が向いて自社の面接に来てくれた優秀なエンジニアは、ほかにもたくさんの企業から「ぜひうちに来てください」と言われていると思って間違いありません。

ですから、面接を通して嫌な印象を受けた企業や、説明が不十分だった企業は、その時点で「ここはやめとこう」と容赦なく辞退されてしまいます。

それだけならまだしも、周りのエンジニアたちに「あの企業はやめておいたほうがいいんじゃないかな」という口コミを流される可能性もあります。エンジニアは常に情報交換をしあっていますので。

これは、たとえ選考段階で「スキルが足りない、うちにはマッチしない」などと判断した応募者でも同じことです。落とした人にも「残念だけど、あの企業いい感じだったな」と思ってもらえるような面接ができないといけません。

ですから、おおげさではなく「この人には自社のファンになってもらうぞ」ぐらいの気持ちで面接に臨んでください。

途中辞退を減らすための面接手順と注意点

では具体的に、エンジニアを面接するときの手順です。

1.まず自社紹介から始めよ

自己紹介を求める前に、自社紹介をしましょう。

ここで言う自社紹介とは、事業内容や開発環境、今回の求人ではどんなポジションにどんな人を採用したいと思っているのか、入社したらどんなチーム構成でどんな仕事をしてもらうことになるのか、自社や開発チームが抱えている課題点…などなどです。

何度も言いますが、優秀なエンジニアは、転職先に困ってはいませんし、「ぜひ御社に入社したい!」などとは思っていません。「どこを選ぼうかな〜」とか「知ってるサービスの中のエンジニアとしゃべってみたいな〜」ぐらいの気持ちで面接に来ている人も多くいます。

ですから、まず自社紹介をすることで、自社に興味を持ってもらうことから始めましょう。説明用の資料などもあらかじめ用意しておき、説明が終わったら質問タイムは必須です。

ちなみに、よく「会社の課題点を明確に話さないことで自社をよく見せよう」とする採用担当者の方がいますが、これは逆効果なので絶対にやめてください。

優秀な応募者ほど、「課題がない企業なんてこの世に存在しない」「課題がなかったら求人募集する必要なんかない」「入社したらすぐバレるようなことを選考段階で隠す企業は、ろくな企業ではない」ということを知っています。

2.エンジニア同士で技術的な話をしよう

まず、応募者は「応募先のエンジニアと技術的な話ができる」と思って面接に来てくれています。

逆に言うと、技術の話ができないような面接は、「無駄な時間だった」「辞退待ったなし」と思われても仕方ありません。

ですから、自社紹介の後は、自社のエンジニアに技術的な話をしてもらいましょう。

たとえば

  • スキルチェックはRubyで受けられているんですね、ふだんからRubyを使われているんですか?
  • 弊社の開発環境はこんな感じなんですが、現職ではどのような環境で開発されているんですか?
  • 最近勉強されている技術とか、これから使ってみたい技術とかってありますか?

などといったことですね。

当然ですが、面接官にエンジニアが一人もいない企業は話になりません。現場のエンジニアを巻き込んで応募者と話してもらわない限り、いつまでたってもエンジニアを増やすことは難しいでしょう。

どうしても面接にエンジニアが参加できない場合

とはいえ、一次面接は人事担当者だけで面接をしなければならない仕組みになっている企業もあるでしょうし、急な障害対応などでエンジニアが面接に参加できなくなってしまった…といったやむを得ないケースもあるかと思います。

エンジニアが面接に参加できない場合は、せめて事前に応募者の情報を見てもらい、当日は「本日はエンジニアがどうしても参加できないのですが、応募者さんの提出されたコードやプロフィールを見て『こういうところを評価していて、こういうところがうちの開発チームに合いそうだと感じたので、ぜひ次の面接でお話ししてみたい』と言っていました」といったことを伝えましょう。

「それならとりあえず次の選考に進んで、エンジニアの人たちと話してみようかなー」と思ってもらえるかもしれません。

一番避けたいのは、エンジニアの面接なのに、技術的なことを知らない人事担当者だけの判断で、優秀な応募者を落としてしまうことです。基本的には、一緒に働くことになるエンジニアの判断を仰ぎましょう。

スカウトした人が来てくれた場合

今や多くの求人サービスに、企業側からスカウトメールを送れる機能がありますよね。

スカウトを受けて面接に来てくれた人は、「スカウトが来たからとりあえず行ってみるか」ぐらいの気持ちでいることがほとんどです。

事業内容もよく知りませんし、志望動機なんかまったくありません。(というかまだ志望していません)

スカウトを受けた人が気になっているのは、「どうして自分にスカウトをくれたのだろう?」ということです。

ですからこの場合も、その人の提出コードやプロフィールをきちんと見た上で『こういうところを評価していて、こういうところがうちの開発チームに合いそうだと感じたので、ぜひお会いしたいと思って、スカウトを送りました』という話をする必要があります。

これがあると、「自分の経歴やスキルをそんなふうに評価してくれたんだ」とよい印象を持ってもらいやすいです。

3.上記の1と2があって、初めて採用面接的な質問ができる

ここまでの話ができて初めて、いわゆる面接然とした転職やキャリアについての質問ができると思ってください。

間違ってもいきなり「弊社を志望していただいた志望動機を教えてください」などと言わないでください。(何度も言いますがまだ志望していません)

1と2をしっかり話した上で、改めて

  • なぜ現職からの転職を考えているのですか?今回の転職でかなえたい課題ってどんなことですか?

(※ただしこの段階ではまだ転職の意志が固まっていない人も多くいます)

  • 今後はどのようなキャリアや開発分野に進みたいと考えていますか?
  • これまでの仕事で苦労したことってどんなことですか?達成感を感じたときってどんなときですか?

などといった質問をすれば、緊張もある程度はほぐれていますし、場もあたたまっていますから、少なくとも面接開始直後にいきなり聞くよりは、応募者もスムーズに話しやすいはずです。

スムーズに話せた面接は、応募者にとって「いい感じの面接だったな」という印象が残りますから、ぜひやってみてください。

まとめ

というわけで、エンジニアの面接がどういう場なのか、面接の進め方や話す内容についてお話ししました。

まとめると

  • 自己紹介を求める前に自社紹介をして、自社に興味を持ってもらう
  • エンジニアの面接なんだから、エンジニア同士で技術の話をしてもらう
  • 応募者の情報を事前に見て「こんなところを評価している」ということを伝える
  • いわゆる面接っぽい質問をするなら、上記を終えてから

ということですね。

これらを実践するだけでも、選考途中で辞退されてしまうようなケースは減らせるはずです。

paizaでは、採用基準の定め方や面接の進め方などについてもサポートを実施しております。

「求人票の書き方がわからない」「どんなふうに面接するとよいのかわからない」「応募があって面接をしても辞退されてしまう」「積極的に採用活動しているつもりだけどなかなかエンジニアを採用できない」といったご相談にものらせていただいておりますので、ぜひご活用ください。

今後エンジニアの採用にpaizaを導入してみようかなと検討されている担当者の方は、こちらからお問い合わせください。(※既にpaizaとご契約いただいております企業様は、直接担当者へご連絡ください)


paiza転職について詳しくはこちら
paiza転職





paizaラーニング」では、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。

詳しくはこちら

paizaラーニング

そしてpaizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。

スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。

詳しくはこちら

paizaのスキルチェック

プロジェクトの炎上を防ぐためにSEが「要件定義」で気をつけたい4つのこと

f:id:paiza:20190305123728j:plain
Photo by Amtec Photos
f:id:paiza:20180910132940p:plainこんにちは。倉内です。

システム開発の上流工程の1つに要件定義という工程があります。

要件定義はプロジェクトの成功・失敗を左右すると言われるほど重要な工程で、炎上したプロジェクトをあとで振り返ってみると「要件定義が甘かった……」と思い当たることが多いです。

要件定義が難しいのは、ユーザーの漠然とした課題や要望を引き出してシステム要件として定義するという性質上、プロジェクトごとの違いが大きく、明確な正解というものが存在しないことにあると思います。

しかし、要件定義をおろそかにするとシステムで何を実現しなければならないかがはっきりしないままプロジェクトを進めることになり、設計・開発・テスト…あとのすべての工程で困ることになります。

そこで今回は、なんとなくでやる要件定義はやめて、プロジェクトを炎上させない要件定義を実施するために気をつけたいことをお伝えしたいと思います。

そもそも「要件定義」とは

要件定義は、下図のとおりエンジニア(SE)が関わるもっとも上流の工程です。

ただし、企業やチームによっては役割が分担されており、開発者が要件定義に関わらない場合があったり、SEが保守・運用を担当する場合もあったりさまざまなので一例だと思ってください。

f:id:paiza:20190304192507p:plain

要件定義の目的を簡単に言うと、ユーザーの要望をシステム要件として整理し、お互いの合意をとるために実施します。受託開発では、この「お互いの合意をとる」ことが非常に重要になってきます。それについてはのちほど説明します。

自社開発の場合、ユーザーから要件が提示されるわけではないので、合意をとるというよりはユーザーニーズを調査し、それに応えるという形になるかと思います。

要件定義のあとは基本設計を実施するため、要件定義での成果物は基本設計のインプットになると考えてください。つまり設計時に「全然情報が足りない…これではシステム設計できない…」となるような要件定義は既に失敗しています。

要件定義の進め方

受託開発を例に要件定義の進め方を簡易的な図に示しました。

f:id:paiza:20190304190508p:plain

図にしてみるととってもあっさりしていますが、「合意して完了」までの道のりは本当に大変です…。

それはユーザーが最初に持っているイメージは多くの場合、「システムで実現したいこと」ではなく「こういうことやりたいなぁ」とか「今のやり方だとこういうことに困ってるからどうにかしたいんだよな~」といった要望や課題だからです。

そのためユーザーの要望をスケジュールと予算を考慮し、現実的なシステム仕様として提示するというのがSEの重要な役割です。何らかの要因で実現が難しいものは代替案と根拠を示す必要があります。それらを提案したり、ユーザーから意見をいただいて再考したり…というのを繰り返して合意を目指します。

「受託開発はお客様から言われたまま作ればいいから楽だよね」と言われて、「は?」と思った方は要件定義におけるSEの役割を分かっている方だと思います。

要件定義で気をつけたいこと

1.ユーザー自身「システムで何を実現したいのか」は分からない

先ほども書きましたが、はっきりと「これこれこういう機能をシステムに実装したい!」と言えるユーザーなんてまずいません。よってユーザーが抱えているぼんやりした要望・課題・問題をいかに多く引き出せるかが重要です。

受託開発では業界特有の常識もあるので、ユーザーは当たり前だと思っているけど一般的には知られてないこと(開発側は知っておかないといけないこと)も要件定義で引き出しておく必要があります。

また、ヒアリングさせていただくユーザー側のメンバーのスケジュールや場所の確保も欠かせません。実際始まってみたら忙しすぎて誰も要件定義のための打ち合わせに出席してくれない…なんてことになったら大変です。契約時に「要件定義にご協力いただけない場合は成果物は保証できない」とはっきり決めておきます。

もう1つよくあるのが、要件定義はIT部門とだけ合意してもうまくいかないということです。実際にシステムを使うユーザーとの食い違いは最後の最後に大幅な手戻りを発生させる危険性があります。

「誰が使うシステムか?」をはじめに確認しておき、できる限り実際の利用ユーザーにも要件定義の内容について合意をとるように(直接打ち合わせの場に出てもらうことが難しくても、利用ユーザーの責任者には随時内容を確認してもらう約束する、など)しましょう。

2.技術を知らないと要件定義の質が落ちる

当たり前ですが、要件定義はシステム開発をするために必要な情報を集めて整理する工程なので、技術的知見がある人とない人では精度がだいぶ変わってきます

いくら業務知識があって要件定義の経験が豊富でも、開発したことがない人が「いくつかやり方はあるが一番いいのはこの方法だ」とか「これは実装に現実的じゃない工数がかかる」とか見通しを立てることはできません。

また、要件定義のミス(ユーザーとの認識違い、機能の考慮不足や検討漏れなど)はコードの修正はもちろん、テストのやり直し、設計書をはじめ各種ドキュメントの修正など大幅な工数増加・スケジュール遅延を引き起こす原因となってしまいます。

なのでいくら上流工程メインのSEになると言っても、基本設計・詳細設計・開発を見据えた要件定義ができる、機能実装に必要な開発工数を見積もることができる技術力はあったほうがいいと思います。

paizaラーニングでは、プログラミング言語の基礎からLaravelやDjangoといった、人気のフレームワークを使ったWebアプリケーション開発まで動画講座で学ぶことができます。

詳しくはこちら

paizaラーニング

3.曖昧な部分をできるだけ残さない

100%曖昧さをなくすことが理想であり、それができたら何も言うことはありません。

しかし、特に新規システム(既存システムの改修やパッケージカスタマイズではない)は要件定義段階で完璧に決めることはかなり難しいです。

もしスケジュールの都合などで議論しきれず、曖昧な部分が残りそうなときは「○日までにこちらからA・B案を出して、×日までに回答いただけなければA案でいきます」など対策が必要になってきます。

システムにとってクリティカルな部分じゃなければ(例えば表示色・文言など)後回しにすることもありますが、それも含めて「じゃあ最終確定日はいつにしますか?」というのは決めておく必要があります。期日までに決まらないと、あとの工程に影響が出ることをユーザーにも必ず認識してもらってください。

また、やりがちなのが「○○機能は既存システムと同じ」という要件定義です。既存システムも自分たちが開発したなら(100歩譲って)まだいいのですが、他社システムのリプレースでそれをやると完全に死亡フラグです。

画面1つとっても表示する項目・色・文字サイズ、レイアウト、遷移…などなど要素はたくさんあります。「ボタンをクリックしたら次のページに移るというのは既存システムと一緒だけど、送信するデータ項目は増えていた。でも要件定義で漏れていた…」といった事態を避けるためにも手を抜いてはいけません。

少なくともシステムの必須機能については完璧にユーザーの要求を顕在化できたかをしっかり確認してください。


(参考)準委任契約と請負契約

受託開発では、業務委託契約の形態として、準委任契約と請負契約というものがあります。それぞれの詳細はこちらの記事が分かりやすいのでご参考ください。

準委任契約は作業した期間に対して報酬が支払われ、瑕疵担保責任がありません。あくまで主体はユーザーにあり、開発側はサポートをしますよということで要件定義は準委任契約で実施することが多いです。

とは言え、多くの場合成果物として要件定義書を納品するでしょうし、善管注意義務といって委任された業務をまっとうする義務も発生します。

4.要件定義では「現実的」かどうかを常に考える

システムにはそれがないとユーザーが業務を遂行できない(目的を達成できない)「必須機能」と、あると便利・役立つが「なくても問題ない機能」とがあります。

要件定義でユーザーからヒアリングをすると、「なくても問題ない機能」に分類できる要望がたくさん挙がってきますが、すべて聞き入れていると予算もスケジュールも合わなくなるため、必須かそうでないかを切り分け現実的に実装する・しないを判断することが大切です。

また、性能やセキュリティといった「非機能要件」は定義が難しく、特に性能については「テストデータでは3秒で応答していたが、本番データが膨大すぎて1分経っても処理が終わらず性能要件を満たせない…」などのちのち問題になることがあります。現実的な目標値を慎重に検討しましょう。

大規模プロジェクトで開発SEだけでは検討しきれない場合、インフラ専門のSEに協力してもらうこともあります。

なぜこれほど「現実的」を連呼するのかと言うと、要件定義で理想を語りすぎるとあとで苦しむからです…。要件定義だけしてプロジェクト完了ならいいのですが、実際に開発をして本番稼働・安定運用までを見据える必要があります。

要件定義工程でのアウトプット

実際に要件定義工程では何を決めて、成果物として何をアウトプットすればいいのかについても少し触れておきます。

ここでは「既存のシステムが古くなってサポートが切れるので、新システムの開発・導入をユーザー企業がシステム開発会社に依頼した」という状況で考えてみましょう。

要件定義のためのインプット情報

はじめに前提として知っておかなければならない情報を挙げておきます。

ユーザーから出されたRFP(提案依頼書)、プロジェクト開始時に作成したプロジェクト計画書に記載されている内容もあれば、ヒアリングや資料提供の依頼を必要とする場合もあります。

  • システムを導入する背景と目的
  • 予算とスケジュール
  • システムの全体構成
  • 既存システムの情報(仕様書や設計書が望ましい)
  • 現行の業務フロー
  • 何をもって要件定義完了となるか:要件定義のゴール

これらの情報が不足していると要件定義がスムーズにいかない確率が上がります。

特に既存システムや現行業務の調査が甘いと手戻りが発生する原因になるため、確実に実施したいところです。また、要件定義のゴールはユーザーとよく認識合わせをしておきましょう。完了条件を決めておかないとあとで何度も変更されたり、言った・言わないの泥沼の議論になります。

要件定義で決めるべきもの

システムで何がしたいかにあたる「機能要件」はもちろん、画面の応答時間やデータ処理速度といった性能のこと、将来データが増えた場合の拡張性、セキュリティなど「非機能要件」も定義する必要があります。

機能要件:

  • UI(システムに必要な画面(画面遷移・レイアウト)、帳票類)
  • 機能(機能一覧表や機能階層図、システム間インタフェース)
  • データ(データ項目一覧、データ量一覧)
  • システム導入後の業務フロー
  • ソフトウェアアーキテクチャと実装技術*1
  • パッケージ製品を活用する場合は既存システムとのFit&Gap

非機能要件:

  • システム移行(移行対象システム、手順やスケジュール)
  • システム運用・操作(手順、ユーザー教育などスケジュール)
  • 性能要件(応答時間など性能目標設定)
  • セキュリティ要件


実際の成果物はIPAがサンプルつきでまとめているページが参考になります。
超上流から攻めるIT化の事例集:要件定義:IPA 独立行政法人 情報処理推進機構

また、非機能要件について網羅的に理解するなら同じくIPAの「非機能要求グレード」に目を通すとよいかと思います。
システム構築の上流工程強化(非機能要求グレード):IPA 独立行政法人 情報処理推進機構

要件定義を学べるオススメ本

はじめよう! 要件定義 ~ビギナーからベテランまで

はじめよう! 要件定義 ~ビギナーからベテランまで

はじめよう! 要件定義 ~ビギナーからベテランまで

何はともあれこれをまず読みましょう。要件定義の基本から実際どうやって手を動かすかまで、非常にシンプルにまとまっていて分かりやすいです。


演習で身につく要件定義の実践テクニック

演習で身につく要件定義の実践テクニック

演習で身につく要件定義の実践テクニック

要件定義を訓練するというのは難しいのですが、この本はいい感じに網羅していて実務でも役立ちそうな内容になっています。


2冊ご紹介しましたが、要件定義に関する本はあまり多くないので、研修を受けるのもありかなと思います。SIerなら若手SEは必須研修になっているかもしれませんね。

もしくは要件定義がうまい人というのは社内に必ずいるはずなので、探してみて実務を通して学んでみるというのも一つの方法でしょう。

大変だけど面白いのが「要件定義」

ここまで読んで「要件定義ってこんなに大変なの…」と思った方もいるかもしれません。

確かに冒頭に書いたとおり、プロジェクトの成否に関わってくるので気楽な工程ではありません。ただ、あらかじめ決められた仕様に沿って開発をするより、自分でお客様といろいろ議論しながら仕様を決めるというのはとても楽しいです。

お客様はシステム開発にあたってどうしたらいいか分からない場合が多いと書きましたが、当たり前ですが業務についてはプロフェッショナルです。課題解決のためにこちらから提案した内容についてもたくさん意見や指摘をいただくこともあります。

その後、検討を経て採用していただき、本番稼働後に「あの案にしてよかった!」「業務効率がすごく上がった!」と言われたときは本当にうれしいですし、やりがいがあります。

これは個人的な意見ですが、逆に「要件定義だけ」やるのも少し退屈かもしれません。SEはコンサルタントではないので、やっぱりお客様と要件決めて、実際作って、テストして、納品して…という工程を経たからこそ面白いんだと思います。

お客様の要望をしっかり仕様に落とし込み、あとの工程を燃やさない要件定義を心がけたいですね。

まとめ

「要件定義とは何か?」から始まり、要件定義で気をつけたいこと、アウトプットするものなどをお伝えしてきました。

要件定義は受託開発だけに関係するイメージがあるかもしれませんが、ユーザーがシステムに期待すること、システムに必要な機能や性能、それらをどのような技術で実現するか…などは自社開発・受託開発に関わらず、あらかじめ定めておいたほうがよいと言えます。

エンジニアとして、システム化にあたりユーザーニーズを踏まえた要件整理・定義ができることは1つの強みになるでしょう。

要件定義スキルはプログラミングスキルのように可視化することは難しいですが、紹介した書籍も参考にしながら、炎上せずにプロジェクトを完遂できる要件定義を極めていってください。





paizaラーニング」では、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。

詳しくはこちら

paizaラーニング

そしてpaizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。

スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。

詳しくはこちら

paizaのスキルチェック

*1:要件定義前に方針を決めておくべきだという考え方もあります。

フリーランス経験者が教える「会社員エンジニア」のほうがおトクな5つの理由

f:id:paiza:20190306152857j:plain
Photo by Oregon State University

長田です。

3年くらいフリーランスのエンジニアをやっていたのですが、一年ちょっと前からpaiza(ギノ) に入社し、会社員エンジニアの道に戻ってきました。

フリーランスをやっていると「自由な働き方ができてうらやましい」と言われたり、会社員に戻るときには「なぜわざわざ…」と言われたりしたもんです。が、私自身「やっぱ会社員に戻ったほうがメリットがあるな」と考えての転職でしたし、今もその選択は間違っていなかったと思っています。

というわけで今回は、フリーランス時代と比較した、会社員エンジニアのメリットについて書いていきます。

会社員だけをやっていると気づけなかったことや、実際にフリーランスをやってみて初めて体感したこともあるので、会社員からフリーランスに転向するか迷っている人や、今後のキャリアの方向性について悩んでいる人にとって、少しでも参考になるポイントがあれば幸いです。

私の簡単な経歴

地方の情報系大学・大学院→都内のベンチャー企業で会社員エンジニア1年半→神奈川でフリーランスエンジニア3年弱→paiza(ギノ)で会社員エンジニア1年ちょっと

今は主にpaiza新卒の開発を担当しています。あと「エンジニアが死滅シタ世界 アンドロイドとふたりぼっちで生きろ。」の開発もしました。遊んでみてね。

会社員の前に…フリーランスのメリットとは

フリーランスだったときは

  • 働く場所や日時が自由なんでしょ
  • やろうと思えば単価の高い仕事ができて稼げるんでしょ
  • 人間関係で苦労しないですむんでしょ

みたいに思われて、うらやましがられることもありました。たしかに数年前まで、これらはフリーランスならではのメリットだったかもしれません。

でも、最近はどうですかね。今やリモートOK、裁量労働(名ばかりではなくて実質的な)OK、時短OK…などなど、自由度の高い企業はそれほど珍しくありません。

実際にpaiza転職でも、そういった条件で求人検索ができるようになっています。

paiza転職での求人検索について、詳しくはこちら

単価の高い仕事を増やして稼ぐというのも…もちろん実力のあるフリーランスになって高単価の仕事を受けまくれば、上限なく稼ぐことができないわけではありません。ただ、私みたいな普通にどこにでもいるレベル感のエンジニアが「ある程度プライベートを確保しつつ、それなりに年収をアップさせたい」なら、そういった求人を探して転職する…というほうが現実的です。今のIT業界は空前の売り手市場ですし…。

人間関係は…これよく勘違いされがちなんですが、会社員でもフリーランスでも、結局は人を相手に仕事するんだから、どっちにしろ人間関係の問題を避けて通ることはできません。

というわけで、エンジニアに対して自由度の高い労働環境を準備している企業が増えてきた昨今、フリーランスでしか享受できないメリットというのは、ほとんどないんじゃないかな?と思います。

いや、ほとんどないは言い過ぎか…。さきほど言った、年収の上限がないのは、めちゃくちゃ実力がある人にとってはメリットですね。日本で会社員エンジニアとして何千万もの年収を得るって、現実的には結構難しいと思いますので…(でもそういう人は海外で転職したほうがいいかも…)。

あとは、フリーランスなら好きなときに長期休暇をとろうと思えばとれるというのが、メリットといえばメリットかもしれないです。会社員の有給とは違ってその期間は無給ですが。

会社員エンジニアとして働くメリット

では具体的に、会社員として享受できるメリットの話です。

ひとまず毎月安定した収入が得られる

とりあえず仕事をしていれば、毎月一定のお給料がもらえます。極端に言うと、やる気が出なくてあんまりやってないときも、病気や私用で休んだ日があっても、成果がふるわなかったときも、もらえます。

会社員の人は「そんなん当たり前やん」と思うかもしれませんが、フリーランスだと、自分で受注して、ちゃんと成果物を出したぶんのお金しか入ってきません。

もちろんさっきも言った通り、ものすごい実力あるフリーランスエンジニアの場合、一人で一千万・二千万稼ぐみたいなのも不可能ではないですから、そういった人はフリーランスをやっていたほうが収入を増やせるのかもしれません。

ただ、私ぐらいの別にすごくないエンジニアだと、すでに受注実績がある企業を相手に、単価を上げてもらうこと自体がめちゃくちゃ大変です。「あの〜単価を上げてほしいんですが…」っていう交渉も、自分一人で会社相手にやらないといけないですし、「え〜、じゃあもう君には頼まんわ…」と言われてしまう可能性だってあるので、実際できるかっていうと…うぅん…。

で、単価が上げられないとなると、収入を上げる(≒生活基盤をある程度整える、貯金を増やす、不測の事態に備える)には、仕事量を増やすか、もっと高い単価で発注してくれそうなお客さんを探すしかないですし、やっぱりそれはそれで大変です。

仕事を通して自分のできる範囲を広げられる

私の場合、ここにメリットを感じて会社員に戻ってきた、みたいなところがあります。

というのも、フリーランスの場合、基本的には「今できること」をベースにした依頼しか来ません。

私の経歴で言うと、大学~一社目で身につけたスキルでできる内容、やったことがある内容の仕事しか来ないって感じですね。そのため、私はフリーランスになったことで、仕事を通して「挑戦」や「新しい経験」をするのが難しくなっていました。

もちろん自分で勉強したり、勉強会に参加したりもしますけど、肝心の仕事では実績が作りづらい、という話ですね。

あと、一人でやってると当然ながら同僚や上司と「ここはこうしたほうがよくない?」とか「最近こういう勉強してるんだよね」みたいな話をする機会はありません。コードレビューもないし。

自分の作ったもの、書いているコード、使っている技術がベストなのかもわからないというのは、結構きついもんです。「自分はこの仕事を通して成長できているのだろうか…できてないだろうな…だって一社目までの貯金でできる仕事しかしてないもんね…」って感じでした。

もちろん、会社員エンジニアをやってさえいれば世界が広がるというわけではありません。大事なのは、今の自分のレベル感や伸ばしたい方向を把握した上での企業選びですね。

私も転職活動をしていたときはそのあたりと、あとは「エンジニアチームに自分よりレベルが高いエンジニアが多いか?」を重視していました。

実際会社員に戻って、仕事を通して「自分のできる範囲」がものすごーく広がりましたし(それなりに大変ではありますが)、勉強になることも多いです。

開発に適した環境を会社が用意してくれる

PCとかディスプレイとか有料ツールとか…会社が用意してくれますから、これは最高ですね。あと椅子、みんな大好き高い椅子。

弊社ではこれ買ってもらっています。

(まぁ私はスタンディングデスク使って立って開発している時間が多くて、あんまり椅子使ってないんですが…。立って開発している理由はこの記事に書いています)
paiza.hatenablog.com

あと、先日私のMacが故障してしまったときも、代替機がすぐに登場して、会社の金で修理に出せたので、業務にはほとんど支障が出ませんでした。

会社員の人は「そんなん当たり前やん」と思うかもしれませんが、フリーランスだと、マシンも代替機も有料ツールも椅子もその他もろもろも全部自分で用意しないといけませんので…。

税金や年金や健康保険など、お金の手続きをしなくていい

会社員の人は「そんなん当たり前やん」と思うかもしれませんが、フリーランスになったら、自分で納めないといけません。自分で確定申告もしないといけません。

その点、経理専門の部門があって、全部いい感じにやってもらえる会社員は最高だなと思います。フリーランス時代の確定申告は超大変だったので、私はもう二度とやりたくないです…。(お金を払って税理士さんに丸投げできるぐらい売り上げがある人になれれば気にしなくていいのかもしれませんが…)

お金の話が出たからついでに言うと、フリーランスには失業保険などもありませんから、ずっと定期的に受注できていた仕事がなくなったとしても、失業手当などはもらえません。

IT健保、健康診断、書籍代・勉強会参加費補助などの福利厚生や有給休暇などの制度

会社員の人は「そんなん当たり前やん」と思うかもしれませんが、フリーランスになると、こういうのが一気になくなります。

あと、私はpaiza(ギノ) に入社してからすぐにフリーランス時代の不摂生がたたって謎の奇病で入院したのですが、このときも「あ、あの仕事をしないと…来月の収入ゼロやんけ…」といった心配をする必要がなく、とってもありがたみがありました。倒れたのが会社員になってからでよかった。(よくない)

(ちなみに、謎の奇病で入院したのをきっかけに健康オタクになった話をこの記事に書いています)
paiza.hatenablog.com

有給の話が出たのでついでに言うと、労働基準法というのは基本的に会社員向けの法律でして、フリーランスは適用外です。フリーランスは法律的に労働者ではないという扱いなんですね。そのへんをちゃんと勉強して自衛しておかないと、発注元の企業にいいように搾取されてしまう可能性がありますから、注意しましょう…。自分のために「No」と言えない人は、特に注意です。

まとめ

まとめると

  • 今は働く場所や日時などに縛りが少なく、自由度の高い企業も増えてきているから、そういった企業に入社できれば、フリーランスという立場にこだわる必要はないのでは?
  • ものすごく実力があれば別だけど、フリーランスで手取り年収を上げるのは結構大変なので、会社員としての転職を狙ったほうが手堅く年収アップさせられる可能性が高いのでは?

みたいな感じですね。

もちろん今回書いたのは私個人の経験に基づく話で、当然ですがどんなエンジニアにも当てはまるわけではありません。私は総合的に会社勤めの方にメリットを感じて転職した人間なので、かなり会社員寄りの内容になってしまいましたし…。

ただ、憧れだけで会社を辞めてフリーランスになっても、おそらくは想定していなかった壁にぶち当たってしまうと思いますし、「そもそもなぜなりたいのか?」を突き詰めて考えると、「それって別にフリーランスじゃなくてもできるんじゃない?」となるかもしれないですから、しっかり考えてから決めたほうがいいと思います。

実際、私は転職活動をしていたときに「新卒のときに比べたら、自由な企業の求人がいっぱいあるな…」と感じましたし、今も就職・転職に関するサービスを作りながら「自由な企業の求人が増えてきてるな…」と感じているので…。

一度そういった企業を探してみて、そこで満足できればそれはそれでいいし、やっぱり「いや自分がやりたいことはフリーランスでしか実現できない」「フリーランスになったほうが(税金などを差し引いても)よっぽど稼げるわい」と思うのであれば、そこで改めてフリーランスになるのもいいんじゃないでしょうか。

フリーランスになるにしろ、会社員になるにしろ、そこで「何がしたいか、どうなりたいか」という目的が大事なんだと思います。


paiza転職について詳しくはこちら
paiza転職





paizaラーニング」では、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。

詳しくはこちら

paizaラーニング

そしてpaizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。

スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。

詳しくはこちら

paizaのスキルチェック





※このブログで紹介しているキャンペーンやイベント、およびサイト内の情報については、すべて記事公開時の情報となります。閲覧されたタイミングによっては状況が変わっている場合もございますのでご了承ください。

ITプログラマー・エンジニア転職・就活・学習のpaiza

プログラミング入門講座|paizaラーニング

PHP入門編Ruby入門編Python入門編Java入門編JavaScript入門編C言語入門編C#入門編アルゴリズム入門編AI機械学習入門

エンジニアのためのプログラミング転職サイト|paiza転職

プログラミング スキルチェックエンジニア求人一覧

未経験からエンジニアを目指す人の転職サイト|EN:TRY

プログラミング スキルチェックエンジニア未経験可求人一覧

エンジニアを目指す学生の就活サイト|paiza新卒

プログラミング スキルチェックエンジニア求人一覧

ブラウザを開くだけで エディタ、Webサーバ、DB等の開発環境が整う|PaizaCloud