Help us understand the problem. What is going on with this article?

フリーランスエンジニアの面談ってこんな感じ

More than 1 year has passed since last update.

はじめに

今回は自分が知りたかったシリーズ第3弾です。

第1弾:25歳初めてのフリーランスエンジニアの単価について
第2弾:新卒入社後、約3年半で読んできた書籍たち
第3弾:フリーランスエンジニアの面談ってこんな感じ
第4弾:新規参画した現場で1週間で意識したこと、やったこと

フリーランスエンジニアではなくても、転職等ですこしは参考になるのではないのかなと思っています。
自分の数少ない経験と偏見があるのであくまで参考として見て頂ければと思います。(こんな感じで話したり、進めたりしているんだと雰囲気を感じてもらえればです。)
覚えている範囲でそのまま書いていますので、回答や内容について間違いが多いと思います。その点、ご了承下さい。

前提

  • 25歳 男性 東京
  • IT業界3年目(Web経験 1年目)
  • エージェントを利用して面談
  • フリーランスエンジニアとしての面談は初めて

面談準備

エージェントさんが案件を紹介してくれて、面談の日程を決めます。
会社名がこの時点で分かるのでホームページは少し見ています。
特に何かを準備することはないです。

当日面談前

10分前ぐらいにエージェントの担当者さんと会社近くで待ち合わせをします。
担当者さんから軽く会社の説明やプロジェクトの説明を受けます。
ただ、この時が一番緊張するのであまり頭には入ってきません。。

面談

基本的にどこも1〜4の流れで進んでいきます。
※場合によって1と2が入れ替わることはあります。

1. 先方のプロダクトやプロジェクト、技術の説明

僕はできるだけメモしながら話を聞いています。
最後の質問で自分の認識が正しい確認します。
メモは下記を重点に取っています。

プロダクト

  • プロダクトはざっくり簡単な絵でイメージを掴む。
  • 登場人物はだれ?(会社、個人、管理者など)
  • 誰がいつ、どんな時に使う?

プロジェクト

  • 開発チームの人数は?
  • 開発体制は?(ウォータフォール、スクラムなど)

技術

  • 使用している技術とバージョン
  • アーキテクチャー

2. 自分の職務経歴の説明

  • 自分は職務経歴が2つだけなのでどちらも簡単に説明していますが、直近の案件をより詳しく話しています。
    もしこれから増えた場合は直近の2つと先方のプロジェクト近い案件を話すと思います。

  • 主に事前連携している職務経歴書に沿って説明しますが、ここで時間を掛けて全て話す必要はないのかなと思っています。
    質問の対話型で進めたい気持ちがあるので、簡単な説明のみにしています。

  • カギ括弧の中が実際に話している内容のイメージ例です。
    ただ、1で聞いた内容で話す内容は変えていますので、暗記はしていないです。
    ※ニュアンスや語尾に関しては実際に異なっています。

いつから、いつまで?

「2017年12月から10ヶ月間、」

どんなプロジェクトで

「業務システムプロジェクトに携わっていました。この時のシステムは顧客を管理するシステムで営業や分析に利用しています。」

開発チーム

「チーム全体は5人のチームで、1ヶ月で区切ったアジャイルのような開発スタイルでした。」

どのようなシステム構成で

「全体のシステム構成について話すと、インフラはAWSでEC2を立ち上げ、DBはRDSです。フロントはSPAで作成し、バックエンドはAPIを返すような構成にしています。」

どのような担当をしていか

「要件定義〜運用まで全て担当していました。自社開発だったこともあり、まずは何が求められるかを仮説検証して、上長にレビューしていました。そこでOKがもらえれば設計をして、開発〜テストを進める形です。ベンチャーだったこともあり、1機能を一人で進める形でした。」

技術について

「フルスタックでインフラ、フロント、バックエンドを触っていましたが、SPA構成だったこともあり、フロントが一番得意です。フロントは画面カンプがあるのでそれをマークアップしてAngularでロジックを組み込んでいました。バックエンドはPHPでAPI開発していました。」

終わりに

「簡単な説明になっていますが以上です。ありがとうございます。」

3. 質問

自分的にはここが一番重要なのではと感じています!!
先方が興味を持ったことに対して質問するので、回答は自分の考えを自分の言葉で伝えられるかを意識しています。
ただ、あまり話を長く続けずに追加で質問してもらう形も意識しています。

以下は質問された内容を順不同で記載しています。(記載していませんが、他にも回答した内容から派生した質問もあります。)
例では自分が回答した内容を残していますが、自分だったこう答えるなど想像して頂ければです。
※回答内容は間違いもあると思います。すみません。

なんでフリーランスになろうと思ったの?

  • 色々なプロダクトや技術を経験したいと思ったから
  • フリーランスという働き方をやってみたいから
  • 若いうちなら失敗できると思ったから

「もっと色んな技術を触れてみたい思ったからです。そしてそのチャンスが今目の前あるので失敗できる若いうちにやってみようと思ったのがきっかけです。不安も正直ありますが、初めてでワクワクもしています。」

コードを書く時に1番重要視しているところは?

  • コメントを残すこと
  • プロダクトに参画して、コードを読み取る際に苦労したから(なんでここでif文が??なんでここでflagが??)
  • コードとドキュメントをがあるときは実際に動いているコードを信用するから
  • 読んで処理がわからないコードには背景や今後修正したい旨などを記載することで、新しく入る人がキャッチアップしやすいと思うから

「一番重要視しているのはコメントをしっかり残すことです。コメントに関しては書籍やネットをみると賛否があると思いますが、僕自身、プロジェクトに最初に関わった時、コードを読み解くのにかなり苦労しました。何でかなと考えたのですが、コードの意図が読み解けないのが一番な理由だと思っています。なぜここでこの分岐がここに!?このフラグは何!?こういうのがあるとどうしても読み解くのに時間が掛かります。ただ、僕自身も、時間がない、また影響を少なくするためなどの理由で、分岐、フラグを安易追加することもあります。。ただなぜそうしたか?そして今後どうしたいかはコメントを書くようにしてます。そして次に自分を含め、コードを読む人が詰まらないようしたいと思っています。。コード以外のドキュメントもありますが、僕の中では最終的に動くコードが絶対的に信用があるのでコードにコメントを記載しています。昔、ドキュメントとコード内容が全然違くて苦労した記憶もあるので。。」

テスト仕様書を作成する時に気をつけていることは?

  • 自分以外の人が見ても分かりやすく書くこと
  • 常にテスト仕様書は更新すること

「正直、テスト仕様書をしっかり書くようになったのはこの頃です。経験は浅いですが、常にテスト仕様書を更新していくことを意識しています。もちろん作成時に正常系、異常系、パターン網羅は意識して、また自分以外の人が見てもテストできるような書き方は意識していますが、やはり実際にテストしているときに仕様書にはないテストエラーが出てきます。このときは必ず、仕様書にも追加して、次回確認できるようにしています。すみません。もしかするとテスト仕様書作成後の話になってしまったかもしれません。。」

git flowを使用した開発経験は?

  • git flowについて知っているが使ったことはない

Git-flowって何?

git flowに沿った経験はありません。今の現場ではmasterとbranchでの運用をしています。各開発者がmasterからbranchを切り、開発が終わったらmasertへマージしています。今の規模とリリース頻度だと大丈夫ですが、もう少し大きくなるとこの運用だと厳しいかなと思ったりしています。

ブラウザで画面が表示される一連の仕組みは説明できますか?

  • サーバとブラウザの関係は知っている。
  • ブラウザのレンダリングも少しは知っている。

実際のところ「ブラウザを立ち上げてページが表示されるまで」には何が起きるのか
表示の遅いWebページは何も価値がない

「ブラウザからサーバへリクエストして、サーバはDBなどからデータを取得して、ファイルをレスポンスします。ブラウザでも返ってきたファイルを解析して画面をレンダリングします。」

細い粒度までは話さなかったです。

将来どんなキャリアプランを考えていますか?

  • 5年後は30歳まで技術をやっていきたいと考えている
  • 30歳以降に関しては正直どうなりたいまではイメージできていない

「正直10年後、20年後のキャリアについては想像できていませんが、5年後の30歳までは色々なプロダクト、技術に触れて、手を動かすエンジニアをしたいと思っています。新卒で就活したときもキャリアプラン聞かれて、既に3年経っていますが、経験を積むと考え方も変わることに気づきました。今を頑張ることが重要なのかとこの頃、思うようになっています。」

自分でサービスとかを作りたいと思っていますか?

  • 自分でサービスを作りたい思いはそこまで強くない
  • 技術的な興味のほうが強い

「今の所、自分のサービスを作りたい思いはそこまで強くないです。もし、サービスへの思いが強かったら、自分の興味のあるサービスに正社員入社を目指すかもしれません。今は技術思考が強いので色々なプロダクトや技術に触れたいと思っています。」

最近、気になったニュースとかありますか?

一番最初の面談で聞かれて、どういう意図なのか分からなくて、思考がフリーズして答えられなかったです。。
技術的なことなのか、それとも本当に気になったニュースでよかったのか。。

次回聞かれたら、技術関係なしに回答しようとは思っています。

「・・・・・・・すみません。ぱっと思い浮かばないです。。。」

なんでこの技術を選択したのですか?

  • 自分は技術選定に関わっていない

「自分は技術選定には携わったことないです。ただ、PHPの得意なエンジニアがいたから決めたと聞いています。」

フロントとバックエンドどちらに興味がありますか?

  • 正直まだ、決めきれていない所もあり、自分でも定まっていないです。。

「正直、どちらも興味があり、やってみたい気持ちが強いです。ただ、フロントから入る方が最初はキャッチアップしやすいと思っています。」

オブジェクト指向とは何ですか?

オブジェクト指向と10年戦ってわかったこと

「カプセル化という考えで、1つの役割をオブジェクトに分けて責務を切り離します。例えばリモコンを考えた時、うんぬんかんぬん。。」

正直、?正しい説明ができたか分かっていないです。
知っていると、伝えるは違うのだと痛感しました。

コードレビューはしたことありますか?その際に注意していることは?

  • 自分の知らない機能をレビューする際は、そこでキャッチアップしたい
  • 書き方に関しても確認していますが、処理がわかりやすいかを重点に見ています
  • リスペクトの気持ちを忘れないこと

「今の現場ではレビューの文化はあります。必ずレビューを通しての本番環境へのデプロイとなります。自分もレビューをお願いされることがありますが主に2つの立場があります。1つ目は自分の知らない箇所のレビューです。ここでは自分がその箇所をキャッチアップすることも意識を置いています。なので少しでも不明点があれば積極的に確認するようにしています。2つ目は自分の知っている箇所のレビューです。こちらは処理自体をすばやく追えるので、書き方や処理を入れる箇所を確認しています。また、追加処理の場合、背景などをコメントに記載しているかを確認しています。」

本番環境へのデプロイ経験はありますか?

  • 自動デプロイではないですが、手動デプロイの経験はあります。

「本番サーバにログインして、git hubからfeachして差分確認してマージするような形でデプロイ作業をしています。ここは本当に自動化をしたいんです。。毎回ドキドキします。。」

4. 自分からの質問

  • 一問一答形式ではなく対話形式を意識しています。
  • 参画した場合のイメージに沿って確認していきます。

プロジェクトの内容確認

  • 1で聞いた内容が自分の理解であっているかを確認します。

「すみません。先程教えていただいたのですがプロジェクトはこのような認識で宜しいでしょうか?(メモを見せれる状況で図とかを残している場合は直接見せて確認します。説明もしやすいので。)」

参画した場合のイメージ確認

  • 端末の確認
  • エディターの確認
  • 開発スタイルの確認
  • コミュニケーションツール
  • テストコードやレビュー体制
  • 役割の確認(特にフロントはマークアップを誰がするのか?)

「参画した際のイメージを持つために幾つか確認させて下さい。自分が初めに参画した場合、環境構築から始めると思うのですが、 端末の指定はあるのでしょうか? macなら慣れているのでありがたいです。そうしたら次はエディタ等を入れると思うのですが、 エディターの指定はありますか? vscodeは今も使用して、使いやすいです。環境面に関してはイメージつきました。コミュニケーションツールはなにか導入していますか? そうしましたら、 開発はどのような形で進めていくのでしょうか?(テストコードやレビュー体制も) ありがとうございます。フロントですが、画面のマークアップはデザイナーさんが担当ですか。それともエンジニアが担当するのでしょうか?

参画する場合、事前に勉強したほうが良いこと

「色々ご回答ありがとうございます。だいぶイメージが湧きました。最後にもし参画が決まった場合、少し時間があるのですが、 どういった事を事前に勉強とかしておけば宜しいでしょうか? もしくは、業務知識を得るために、このサイトとかをみたほうが良いなどがあれば教えて欲しいです。

面談後

エージェントさんから簡単なフィードバックを頂いて終了です。
社交辞令もあると思いますが、基本ポジティブフィードバックのみでした。

その他

  • 条件面や勤怠に関しては証跡が残るようにエージェントさんに確認してもらいメールでもらってます。
  • 結果が出てから、参画するを決める猶予は長くて1週間です。転職も経験していますが、スピード感はかなり早いです。

次の面談の前までしたいこと

  • 面談前にエージェントさんに面談中に見てもらい内容を伝えてフィードバックをもらえるようにする

    • 話の流れは悪くないか?
    • 伝わりづらい内容になっていないか?
    • 答え方でイマイチな所はなかったか?
    • 声は小さくなかったか?
  • 見せれる成果物を準備しておくこと

まとめ

  • メモを取りながら聞いて、認識が正しいかを確認する
  • 業務経歴はウソを付かず、あまり長く説明しすぎないようにする
  • 質問に関しては、時と場合によりますが自分の経験したことを入れて回答する
  • 自分からの質問はできるだけ対話形式で確認している
  • 一回の面談でだいたい決まる
  • 自分が知っていたと思っても、相手に伝えることは難しいこと

最後に

自分の少ない経験なので、これを正解だと思わず、参考程度にして頂ければです。
おそらく、回答内容も間違いているものがたくさんあると思います。
また、面談する側からみると全然ダメな内容かもしれません。。

自分自身、最初の面談では緊張もあり全然うまく話せなかったです。試行錯誤でとりあえず、今の形ですが、もっと経験を積んで分かりやすく自分をアピールできるように頑張っていきたいと思います。

思った以上に長くなってしました、最後まで見て頂いてありがとうございます。

turmericN
中小SIer(2年7ヶ月) → Web系ベンチャー(10ヶ月) → フリーランスエンジニア(2018/10〜) 最近はVue、Node.js、Laravel、AWSを触っています。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした