20歳のエンジニアが15社（くらい）カジュアル面談受けてみての所感

# はじめに
フロントエンジニアとして活動させていただいております。
ふぁると申します！

TypeScript、Vue.js、Reactを主に使って、会社員やりつつ、趣味で個人開発を行っております。
**サービス公開時の技術記事リンク**
[学生エンジニアのためのチャットサービスをNext.js + TypeScript + AtomicDesign + Firebase9 + Dockerで作った](https://qiita.com/Itamaster/items/9e2c1772596ebc4415ce)

[【個人開発】（Nuxt.js + Rails）OSSやプロジェクトの、ソースコードを管理するGitHubのように、web上で結合テストをチームで同時に管理・実行・記録出来るプラットフォームを開発しました！](https://qiita.com/Itamaster/items/f821be4c33caab640a93)

**Remixについて**
[Reactベースの新フルスタックフレームワーク「Remix」を読み解いてみた](https://qiita.com/Itamaster/items/5f44dc785f3faf268fb6)

良ければフォロー、starお願いします！
**Twitter**
[@fal_engineer](https://twitter.com/fal_engineer)

**GitHub**
https://github.com/FAL-coffee

# この記事について
## 概要
高卒三年目、20歳（この四月で四年目に突入し、また1月時点で21歳となってしまいましたが）の私が、**2021/11 - 2022/2**の期間中行った転職活動の中で、カジュアル面談を15社程受けさせていただいたので、お話させていただいた中で有難かった情報を記事にしたいと思います。
私のスキルセットとしましては、
- 実務経験あり
  - JavaScript  (二年ちょい)
  - Vue.js  (一年弱)
  - React  (九か月くらい)
  - TypeScript  (九か月くらい)
  - PHP  (半年くらい)
  - Java  (三か月くらい)
  - Git  (一年くらい)
  - SVN （一年くらい）
- 趣味でのみ
  - Ruby  (三か月くらい)
  - Ruby on Rails  (三か月くらい)
  - Firebase,Firestore (三か月くらい)
  - AWS  (EC2, RDS, Route53とかをちょっとずつ)
  - Docker  (開発環境にのみ)
  - GitHub Actions  (CIに利用しているのみ)

## この記事の対象とする読者
未経験者からジュニア層、ミドル層まで

## 書くこと
- カジュアル面談とは
- 受けるうえで
- 私がカジュアル面談を受けた方法
- カジュアル面談の面白さ
- 学ぶことの出来たノウハウ
- ジュニア、ミドルクラスのエンジニアとして市場価値を高めるうえで重要な要素

## 書かないこと
- カジュアル面談を受けさせていただいた企業様の具体的な社名
- また企業、個人の特定につながりかねない情報

# エンジニアたちよ、転職活動をしろ
<strong><font color="red">※転職を推奨するものではありません。</font></strong>

何言ってんだおめえって話ですが、
転職活動を定期的に行いながら、エンジニア市場の把握や需要の高い技術に対してアンテナを張ろうな、って事が言いたいのです。
また、自分の市場価値、伸ばしたいスキル、キャリアパスなどを見直す機会として非常に有効かと思います。

**（カジュアル面談はあくまで転職活動の場として存在していますので、冷やかしや情報収集だけのためと明言して行うことは企業様方に対して非常に迷惑となります。読んでいただいた皆様には、企業様に対しては誠意ある行動をお願いします。）**

## カジュアル面談とは？
さて本題ですが、カジュアル面談についてです。
カジュアル面談とは最近の転職エージェントサイトで盛り上がっている文化で、元々はPaiza転職というサービス発祥（だったはず）です。
具体的には、面接とは違い、「気軽にお互い情報交換でもしましょうや」って感じです。

お互いラフに自己紹介を行った後、
企業様はおおよそ、「事業内容、開発言語や手法、チーム文化等」の説明を行います。
説明された内容について気になった事があれば気軽に質問して構いませんし、
志望動機等聞かれることは有りませんので、事前準備が無くても問題は有りません。
（稀にカジュアル面談を謳いつつ、受けてみれば一次面接だったなんて話もありますが、アレは本当に特殊なケースです。）

雑談や開発についてお話を楽しみつつ、30分～1時間でお疲れ様でしたーといった流れが多いです。

趣旨としては、情報交換のほか、選考過程に進んでからのミスマッチを避けるといった目的があります。
とりあえずカジュアル面談を受けてみて、興味のある技術や事業内容、体制であれば選考過程に進んでみようかな、くらいのマインドで受ける方が多い印象です。

## カジュアル面談を受けるうえで
履歴書、職歴所等の準備は必要ありません。
しかし話題のタネとして、利用する転職エージェントサービスのプロフィールは充実させておきましょう。

コロナ禍ということもあり、zoomやGoogleMeetなどで行います。
zoomは環境構築が必要なので、指定された場合はいつでもミーティングが出来るようにしておきましょう。
またGoogleMeetではデフォルトでは、Googleアカウントの表示名が相手に表示されるため、しっかりと確認したうえで不味い名前であれば変更ないし、別のアカウントを準備しておきましょう。
<font color="orange">私は恥をかきました。</font>

カメラが必須ですので、webカメラを揃えておきましょう。
服装は常識の範囲内でカジュアルな服装で結構です。
私はYシャツにパーカーを着ていました。
またサウンド機器についてですが、基本的にヘッドフォンは推奨されません。
イヤホンマイクや、カメラ内蔵のマイクを使うのが良いです。

事前に相手企業様についての情報収集を軽くでも行っておくと、価値のある質問がしやすくなると思います。
また、募集要項はきちんと読み込んでおきましょう。

## 私がカジュアル面談を受けた方法
Paiza転職、ファインディを使用しました。

Paiza転職ではスキルチェックを元に応募出来る企業が表示されます。
BランクやAランクあたりから応募出来る数が多くなるので、上げておくとよいでしょう。

ファインディでは、GitHubアカウントを連携することでスキル偏差値や各言語のレベルが算出されます。
初期状態が44とかで、<font color="red">外部の</font>OSSにコミットを行うことで偏差値が向上します。
※ 2022/2時点

ファインディではエージェント様にヒアリングを行っていただける他、希望条件を伝えるとオススメの求人を共有していただいたり、サポートが強力でした。
またフルリモート、フレックス等を掲げている求人はPaizaよりもファインディが多い印象です。

双方のカジュアル面談までの大まかな流れは、
1. プロフィールを充実させる
2. いいねをする、スカウトを受ける等の、どちらかからのアプローチ
3. チャット、企業の指定するスケジューリングサービスによって、カジュアル面談の日程を決定する

のみです。
非常に気軽には行えるのではないかと思います。

また例外として私の場合、Twitter経由でもカジュアル面談を受けさせていただいた経験もあります。
エンジニアとしての情報収集、発信のために運用していたアカウントでしたが、昨今はTwitter転職も盛んですし、エンジニアとして活動する上ではアカウントを運用しておくのも非常に有効化と思われます。
**駆け出しエンジニアさんを狙った情報商材の売り付けも非常に盛んですので、リテラシーを持って取り組みましょう。**

## カジュアル面談の面白さ
ダントツで、他のIT企業の文化やアーキテクチャの質問が出来ることだと思います。
私は主にフロントエンドで活動しているため、コンポーネントの設計や工数見積もり、デザインパターン、マイクロフロントエンドを目指しているような企業様では、具体的にどのような方法を用いているかといった話を聞くことが出来ました。
エンジニアの方とお話させていただく事自体は、エンジニアの方が多いコミュニティ等に所属することで可能かと思いますが、**企業として、チームとしてどのような方針か**、については情報を得るのが難しいと思います。

<font color="red"><strong>多くの企業とカジュアル面談を行うことで、市場価値の高い技術（どのようなスキルセットのエンジニアが求められているか）についての情報を得ることも出来、目標設定を行うことが出来るという面でも非常に有効です。</strong></font>

また、フルリモートの求人では、コミュニケーションコストの削減や円滑化、社内での人間関係の構築にどのような方法を採用しているか、またその効果についても情報を頂けるため、文化作りといった面での知見を深めることが出来ます。

転職の意志が面談時点で無かったとしても、人脈を広げるという面にフォーカスを当て、継続的にコミュニケーションを取り合う事で将来的な転職先になったり、ビジネスに広がる事も可能性としてあります。

## 学ぶことの出来たノウハウ
以下に、私が聞くことの出来た情報を、企業様方の特定に繋がらない範囲で共有したいと思います。

### コミュニケーション文化について
またコロナ禍でリモートワークがスタンダードとなっている現在において、エンジニア同士がコミュニケーションを容易に取るためにどのような文化を採用しているのか、ということについてです。

#### times文化
Slackをコミュニケーションツールとして用いている企業ではこちらを採用している企業様が多く見られました。
一人一つ、```#times_〇〇（人名、ハンドルネーム等）```というチャンネルを受け持ち、メンバーは全員参加します。
Twitterのように思ったことや疑問点を書き込んだり、他のメンバーとの雑談に使ったりすることで、会った事のないメンバー同士のアイスブレイクに使ったり、情報共有や疑問の速やかな解消に役立てます。
私が所属しているQiita Organizationの[運営者ギルド](https://qiita.com/organizations/admin-guild)でもtimes文化があり、私も沢山助けていただいております。

#### Gatherの採用
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1869061/0f9a2358-0645-2be5-55f3-c07c5cfa1cdf.png)
こちらいわゆるメタバースで、最近ちょっと話題のコミュニケーションツールです。
バーチャルワールドの中で会議室や執務室があり、他のメンバーのアバターに近づいたら会話が出来るようになったり、逆に離れると声が遠ざかったりします。
メタバース上で会議室に集まって会議を行い、終われば各々が好きな場所に帰っていきます。

ソフトウェア自体について詳細に調べていないので、コミュニケーション自体の円滑化に有効であるのかはわかりかねますが、**めちゃくちゃ楽しそうです**。
会話をするために歩み寄ったり、集まったりというのは現実空間と似たものがありますし、リモートワークならではの違和感の解消には有効かもしれません。

### チーム作り、エンジニアの育成について
ジュニア、ミドルクラスのエンジニアを育てるために、どのような体制を取られているのか、という質問を幾ばくかの企業様に行いました。

#### 案件のローテーション
受託、請負、SES等の契約形態を取っている企業様でしたが、数年おきに必ず案件をシフトさせるという決まりを作り、実行しているようでした。
案件に対するディレクションコスト、新メンバー受け入れのための工数はかかってしまいますが、様々なプロジェクトを短いスパンで経験させることで、エンジニア一人一人のスキルスタックを増やすことを目的としていらっしゃるようです。
本人の市場価値を企業として上げさせ、その上で留まってもらえるように条件を上げ、全体としてのレベルを上げるほか、
プロジェクトに急な欠員が出たとしても過去に当該プロジェクトに居たメンバーを移動させ、効率の悪化を防ぐといったことに役立っているそうです。

#### 担当分野を特定せず、挙手制にする
例えば、フロントエンジニアがフロントエンドだけでなく、「やりたいです」と言えばバックエンドや、インフラ、営業さえも任せるという決まりです。
最終的にはチーム全員がほかのメンバーをカバー可能なチームを目指すためとのことでした。
[バス係数](http://yamada.daiji.ro/blog/?p=478#:~:text=%E3%83%90%E3%82%B9%E4%BF%82%E6%95%B0%E3%81%A8%E3%81%AF%E3%80%8C%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88,%E3%81%A8%E8%80%83%E3%81%88%E3%82%89%E3%82%8C%E3%82%8B%E3%81%A7%E3%81%97%E3%82%87%E3%81%86%E3%80%82)をチームの人数と同じにすることで、それぞれが自走可能となります。

#### フラットコミュニケーション
コミュニケーションコストの分野にも被るかもですが、先輩や後輩、役職の上下に関わらず、ハッキリとした上下関係を作らないというものです。
若手社員が既存のルールや仕様に対して意見をし易い環境を整えることで、より良い成果物を全体の意見を統一しながら作成することを目的としていらっしゃるようでした。
発言者が最も強く、誰も決定的な反対意見を出さない場合は誰が発言したものであっても、意見を通し変革を行うそうです。
最も大きな決定では、事務所の住所が変わったとのことで、とても衝撃を受けました。

## ジュニア、ミドルクラスのエンジニアとして市場価値を高めるうえで重要な要素

### 情報に対してアンテナを張り、技術について敏感になること
既に何度か書かせていただきましたが、やはり一番は**アンテナを張り、情報、市場に対して敏感になること**だと思います。

私はQiitaやZennといった技術記事投稿サイトの他、Twitterで有益な発信をされている方々をフォローさせていただいたり、GitHubでインフルエンサーや所謂つよつよエンジニアさんの活動をチェックしたりしています。

技術だけであれば記事によってキャッチアップが可能なものも多いかと思いますが、ディレクトリ構成や、実際の導入、デザインパターンやブランチ運用手法は、実際のリポジトリを見た方がわかりやすい場合が多いです。

特に地方住だと、そのようなSNSを使ったキャッチアップの有用性は高いと感じます。
私は広島に住んでいますが、首都圏のエンジニアの方のお話を聞いていると、普段から周囲のエンジニアによって耳に入ってくる情報自体に差が大きいように感じました。
地方での仕事にも大変やりがいがあったり、勉強になるものも多いと思いますが、市場価値の高い所謂モダン技術の求人や業務はやはり首都圏が多いように感じます。

### 活動履歴を残し、技術や自走力の証明を行うこと
OSS活動や個人開発も市場価値を上げることに繋がりやすいのではないかと感じています。

GitHubでの活動にはスポンサーが付く場合もありますし、支援という形で金銭が発生しているリポジトリも多いです。
OSSにコミットしている、自分でサービスを公開して運用している、というような実績は、ジュニア・ミドルクラスの転職市場においてはとても重視される傾向にあるように感じました。
ジュニア・ミドルクラスでは自走してキャッチアップを行えること、進んで意見を行えることを求められることが多いです。
**特に自社サービスの企業様では、「自分のサービスで収益化の経験がある」事を非常に評価していただける**ようにも感じます。

<font color="red"><strong>ポートフォリオや継続的なGitHubでの活動履歴は、それらを自発的に行えるメンバーであること</strong></font>を保証してくれます。

### デファクトスタンダードとなっている技術のキャッチアップを随時行うこと
AWS、Docker、CircleCI、GitHub等の、「案件によっては採用されない事が多くも、開発において主要アーキテクチャの中ではデファクトスタンダードとなっている技術」は、業務の中で経験出来ていなくても個人的にキャッチアップを行っておきましょう。

自走力の保証としては勿論、別の分野の知識は視点を上げることに非常に役立つと感じます。
さわりだけでも触れておく事で、開発においても非常に選択肢を広げることが出来ます。

# さいごに
エンジニアとして成長、市場価値を上げるためには、やはり情報収集が大事だと感じたので記事にさせていただきました。
お目汚し失礼致しました。