でも、実際に転職する際には、どういった書類を準備をすればいいんでしょうか？
記事の内容
この記事では、こういった疑問にお答えするために、転職に関する流れをお伝えします。
職務経歴書について
まずは、下記の3点を揃えましょう。
- 整理された職務経歴書
- 自分の長所を3つと短所を1つ
- 仕事に関係する以外の成果物
整理された職務経歴書
整理されているというのは、項目ごとにスキルを分けられているということです。
大別すれば、以下の4つです。
- OS
- プログラミング言語
- データベース
- フレームワーク
もう少し詳細に書く場合は、転職グリーンのフォーマットがよくできていたので、参考にするといいと思います。
自分の長所
次に自分の長所を3つ以上は書き出してみましょう。
その中から、よさそうな3つを職務経歴書に書いて下さい。
最初は難しいと思いますが、頑張って前職の経験を思い出して書いてみましょう。
別の記事で書きましたが、前職での「お母さん経験」なんかも、本人が気付いていないだけで、実は素晴らしい長所です。
以下に例を書いておきますが、自分なりに工夫した経験があれば何でも大丈夫です。
1、多くの国籍の人と一緒に仕事をして、プロジェクトを成功させた実績
フィリピンで働いていた時に、フィリピン人、中国人、台湾人、日本人、アメリカ人と多くの国籍の人と英語で相談しながらプロジェクトを進めました。
拠点も日本、中国、フィリピンと分かれていましたが、丁寧なコミニケーションをして綿密にプロジェクトを進めることによって、遅れることなくプロジェクトを成功させました。
2、プロジェクトリーダー、プログラミング、インフラができる幅広いスキルセット
ベンチャーで働いてきたせいか、チーム内で人員不足に悩まされることが多く、幅広く仕事をすることが多くありました。
そのため、プロジェクトリーダーをやりながら、プログラム、インフラの運用・保守などをやってきた経験があります。
幅広い知識があると、プログラマやインフラエンジニアとも技術の話ができるので、プロジェクトを進めやすくなると自負しています。
3、エンジニアの採用やエンジニアの教育の実績
フィリピンにいる時にチーム作りを任されていたので、英語での面接からエンジニア教育を手掛けました。
フィリピン人の場合は、真面目な日本人とは違って一筋縄にはいきませんでしたが、根気よくやり続けることによって、数年掛かりでチーム力を底上げをしました。
4、プログラミングに対する情熱
私は30代でプログラミングを始めたので、人よりは随分と遅いスタートだと思います。
ただ、そんな中でも、仕事をしながら独学でプログラムの勉強を始めて、プロダクトを作りきりました。
情熱を持って、最後までプログラムを作りきれるところが自分の強みです。
5、前職は営業事務をしていて、「お母さん」と呼ばれていました
前職では、営業事務をしていて、男性社員のサポート業務をしていました。
そこでは、男性が気持ちよく仕事をできるように、愛想良く、気遣いができ、サポートする事が求められていました。
その経験は、チーム開発の時でも必ず役に立つと自負しています。
自分の短所
次に「短所 + それを補った工夫」というストーリーも作っておきましょう。
これは職務経歴書に書く必要はありません。
ただ、「苦労した点」や「苦手だったこと」を面接で聞かれることがあるので、準備しておきましょう。
以下に具体例を挙げておきます。
マイナス面とプラス面をセットで話せるようにしておきましょう。
ただ、それでは駄目だと思ってslackで通知機能を使ってMTGの5分前には通知を送るようにしました。
結果として、自分だけでなくMTGに遅れがちな同僚も合わせて、MTGに遅れないようにしました。
成果物
成果物で私がお勧めするのはGithubとQiitaです。
Githubにソースコードをあげたり、Qiitaに日頃から自分がやっているメモをまとめておきましょう。
両方ともやれたら、それがベストです。
ただ、最初は自分でプロジェクトを作るのは難しいので、まずはQiitaに仕事の要点をまとめておく癖をつけるといいと思います。
面接における注意点
面接における注意点を伝えておきます。
まず、心構えとして、面接は評価をされるところではなくて、コミュニケーションをとる場であるということです。
あまり受け身になりすぎないようにしましょう。
転職時の一番のリスクは、あなたのスキルと職場で求められているリスクのミスマッチです。
それを避けるために、できるだけ自分の情報は出すようにしましょう。
そして面接官からは、職場の雰囲気を聞くようにしましょう。
具体的な質問リストをあげておきます。
御社は、どうしてその言語とフレームワークを選んだのですか？
これによって、リーダーの考え方がわかります。
もし、10年も前のフレームワークだったら、「どうして、それを使っているんですか？」と深堀りしていきましょう。
深掘りしていくことで社内の様子がわかってきます。
コミュニケーションツールは何ですか？
slack、skype、chatworkなどの一般的だとは思いますが、もしかしたら、メールかもしれないし、何も使ってないかもしれません。
使ってない時は理由も聞きましょう。
社内のガバナンスがわかってきます。
サーバーはAWS、Azureなどのクラウド系を使っているか、それともオンプレミスか？
回答が得られたら、理由も合わせて聞くといいです。
また、誰がサーバーを管理しているのかも大事なポイントです。
インフラ部隊がいるのか、もしくはエンジニアが管理しているのか。
システムに障害があった時は、誰がどういった手順で、いつ復旧しているのかなども聞きましょう。
サーバーの監視体制を聞くと尚よいです。
ソースコードのレビュー方法はどうしているか？
どれぐらいの頻度で、ソースコードをリリースして、誰がレビューをしているのか。
これを知ることで、そのチームの体制が見えてきます。
もし、レビューはしてないとかだと怖いチームであることがわかります。
テストコードを書いているかどうか？また、どれぐらいの量を書いているか？
これを知ることで、チーム体制がわかってきます。スピード優先、リリース優先なのか、慎重にコードを書くチームといったことがわかります。
ER図やUMLなどは書いていますか？
ER図やUMLは、プロダクトの大事な成果物です。
そういった成果物を書くかどうかで、どういったチームなのかがわかります。
質問事項はたくさんありますが、コミュニケーションの一貫だと思って積極的に質問をしましょう。
ただ、注意点としては、もし自分の思想と違っても決して否定をしないということです。
ただ、理由を聞いて自分がそのチームでやっていけるかどうかを確認しましょう。
Good luck for your engineer life!
この記事が面白かった人は、こちらの記事も読んでみて下さい。