システム、アプリケーションに興味を持ってもらうこと
今回はもやっと思っていることを書いただけの短い文章になる予定。あまりまとまりもないかもしれない。
最近、システムに興味を持ってもらうということを考えるようになった。
これまでサービスの中心に開発したシステムがあり、サービスを提供・運営することは、システムを提供・運用することとは切り離せないプロジェクトに所属してきたのだが、最近サービスの一部にシステムがあり、サービスの運営をサポートし、そして高付加価値を提供するためにシステムがあるというプロジェクトに変わった。これにより、システム上でどう達成するかということを社内のプロジェクトに関わる全員が考えることが当たり前という文化がなくなり、現状のネガティブな問題以外の部分に対して声が挙がりにくいということをひしひしと感じるようになった。
これは単にシステムに目が向いていないというだけでなく、そういう方法があるということを思いつかないであったり、現状明らかな問題でないことに不透明なコストを掛けていいのかわかりにくいというのもあるかもしれない。もしかしたら、過去に改善案を提案したものの、何らかで失敗や実装に至らなかったということがあるのかもしれない。しかしながら視野を広げて、サービス全体の中にあるシステムの改善というところにも目を向け、サービスの改善の選択肢としてシステムを改善することも考えてもらえるようになることは、サービスの一部としてシステムを提供している以上は重要なことだと思う。
もちろん、全員が向いていないわけではないのだけど、やはりそうでない人も多いのかなと言う印象がある。改善のための提案の受け入れ口を設けるだけでなく、やはりサービスに関わる人同士で振り返りをすることが求められるのかもしれない。文化的な違いで難しい部分もあるかもしれないが、やり方を考えてみたいと思う。
開発するシステムが持つ性質やプロジェクトの置かれた文化が変われば、基本はあれど、プロジェクトでの進め方やエンジニアとして考えるべき事柄を柔軟に変えなければならないということを今感じている。
【個人的】エンジニアが転職のときのためにやっておくと良いことリスト
雑なエンジニアの転職したいと思っているなら、転職活動とは関係なくやってるほうが良いよねっていうことをピックアップしてみることにしました。
転職活動開始よりも前の、「転職考えているけれど、今すぐ転職活動開始するつもりじゃない」くらいのときにやっておくと良いことと捉えてください。とはいっても、このあたりは転職考えなくてもやっておくと良いかも〜ということもあると思います。
こちらは個人的な備忘録に近いものになりますので、読まれる方も参考程度にとどめてください。
あと、スーパーエンジニアであったり、海外でやってくぜ！といった人には不要なこともあると思いますので、そのあたりはそういうもんだと思って読んでください。
1. 自分の技術スタック、長所、短所を整理しよう
まずは自分の技術スタックを整理しましょう。全くやったことのないことへの挑戦はやらせてもらえる会社もありますが、給与が大きく下がるであったり、業務を望んだ形で選択できない場合もあるでしょう。特に業務でやったことのないことについては、第三者視点でできることを示せる必要があります。単純に表彰されたとかではなく、こういうふうにやっていますと説明できたり、面接官に示すことができるといったレベルの話です。
また自身の長所、短所を整理しましょう。こちらは、「自分で考えていること」と「他人に言われたことがあるもの」を切り分けて洗い出しておくと良いでしょう。業務にどのような影響があるか、どのように活用、克服しようとした、しているかも重要です。特に短所は人に暴力を振るうといった社会人的に問題がある内容でなければ基本的には問題ないので、むしろ問題にならないようにどうしようとしているかといったことを考えましょう。逆に長所や得意なこととして話したのに、少し深掘りすると話せないといったことはマイナスになるのでその点も注意したほうがよいです。
技術スタックを整理する際には以下に注意しましょう。
- 業務でやったことと個人でやったことは分類しておく
- 職務経歴書を書くときにわかるようにしておく（プロジェクト単位で）
- 個人でやったことは武器になるのでこちらもきちんと説明できるのがよい
- プログラミング言語、開発環境、OS、ツール、クラウド、プラットフォーム、CI/CD、語学経験、対外対応など、とにかく限定せずに書きだす
- どこからどこまでの範囲で関わったのかを説明できるようにしておく
- 技術選定からやったのか、導入からやったのか、すでに導入済みのところで対応したかなどで大きく違うため
- ついでに「なぜそうしたか」や「どの程度」をきちんと数字や事実をもとに説明できることも重要
- 資格、表彰などの第三者視点でわかる評価は特に大事にする
2. 転職先の業界、技術スタックの方向性をざっくりと考える
転職するんだから当たり前と思うかもしれませんが、これを定めないとやることが変わってきます。ただ、これらを組み合わせで考える必要があります。近い技術を利用していても、業界が違うと求められる内容はガラッと変わります。また、複数の業界、複数の技術スタックを考えている場合はある程度幅広く考える必要が出てくるので注意です。もちろんですが、必須のベースはありますので、そちらは後ほど記載します。
例えば技術スタックがJavaだった場合でも、ゲーム業界と受諾開発の業種とでは求められるものが全然違ってきます。ゲーム業界では、少なからず「個人で開発したゲーム」の提出が求められる場合があります。これは「ゲームが好きであり、ゲーム開発に情熱を持って取り組めるか」という趣向まで求められていることがあります。これはゲームは誰でもできるものであり、ただ単にある程度開発できる以上の理解を求められやすい傾向にあるのが大きいと思います。一方で、受諾の開発をしている会社では、そうしたなにか特定の方向性のものを作っていることよりも、単純な技術力やコミュニケーション力の方が重視されやすい傾向にあると思います。一概には言えないので、もし「行きたい会社」が明確なら、その会社の方向性に合わせてしまったほうが早いでしょう。
前述の例のように、転職活動を開始してからでは遅いような内容（個人で開発したゲームの提出など）は早めに対応する必要があるので、行きたい業界や会社が決まっていたりする人は注意です。
3. 一般的に多いパターンに合わせられるようにしておく
最後に転職時に求められるけど、準備できている人とそうでない人で大きな差になってしまうものをリストアップしてみます。
- Paiza のようなオンラインのコーディングで問題を解く系のものに少しでよいので慣れておく
- 最近はこのような形式のオンラインのコーディングテストを求められることが増えているため、慣れておくといきなり求められてもやりやすい
- デザインパターン、ソフトウェアテストの基礎知識、アルゴリズムの計算量・概要など、エンジニアとして基礎知識と思われていることを説明できるようにしておく
- 面接中に突然聞かれることもあり、意外と普段に比べるとぱっと答えられなかったりするので注意する
- 業界や会社によっても内容が異なってくるので、どんなことが基礎知識となっているか考えておく
- 成功体験、失敗談をその後の対応や結果も含めて話せるようにしておく
- 中途の場合、何らかの事柄から「学び、活かせる」人を求められます
- その企業にピッタリ合っている方がいいのですが、実際はそこを見られているわけではなく上述のことを多くの場合見られていると思いましょう
- 一応、SPIなどの適性試験に対応することになってもできるようにしておく
- たまたまそういう企業に当たることもあるので不安な人は対応しておくとよいが、必要になったときに勉強するでもある程度は対応可能ではあると思う（ただ一度でも模擬試験などで勉強しているかどうかで結構変わるので、必要なら絶対やったほうが良い）
- 適性試験も種類がいくつかあり、ものによって差異があるので、どうしても不安という人以外は受けることが決まってからのほうがよいかも
まとめ
大体、中途の転職で言われてることを書き出した感じになっちゃいましたが、個人的にはこういうのやっとくと良いよねと思います。特に転職活動直前に始めると間に合わないような事柄は早めに対応しておくと良いと思います。
転職しない人も今回書いた内容を試してみると、「こんなことやったなぁ」であったり、「こういうところがウィークポイントかな」や「やっていきたい方向性ならこういうことをやったほうがいいかも」だったり、「こういうこと忘れてるからやり直そう」とかそういうのを認識でき、今後につなげることができるのではないかと思います。
