6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

この記事は「転職活動して気づいたこれをやっていれば/やってよかった をシェアする Advent Calendar 2024」に参加した記事です。

自分の転職活動で感じた職務経歴書の表現の難しさ

私は今年に転職したため、転職活動の中で職務経歴書を通じて自分のスキルや経験を適切に伝える難しさを改めて実感しました。

特に技術力が高まると、技術言語やフレームワークの知識を持っていることだけが強みではなく、その「技術をどのように活用して広く影響を与えることができるか」を表現する必要が出てきます。

現在のエンジニア向けの職務経歴書フォーマットはメンバークラスのエンジニアのフォーマットになっているケースが多くあり、そのフォーマットに従っても表現に不足が出てしまうため工夫が必要に感じました。

転職後の採用を通して感じたきっかけ

転職後は引き続きエンジニア採用に関わる立場になったため、職務経歴書の確認や面接を担当しています。その中で、実力を持ちながらも職務経歴書で表現ができていない人が多いと感じる場面が多々あり、非常にもったいないと感じます。

自身の転職経験と採用側の視点を通じて感じたことを活かして、今回はテックリード級のエンジニアが職務経歴書で実力を上手く表現するための要素を書いてみたいと考えました。

テックリードはメンバーエンジニアと職務経歴書の表現の仕方を変える必要がある

以前に職務経歴書について記事を書いたことがありますが、基本はこちらの内容は前提に、テックリードだからこその要素で何を書くべきかをまとめてみたいと思います。

エンジニアとして経験を積み、中級以上のエンジニアになってくるとテックリードを経験することがあります。
テックリードを経験した職務経歴書はメンバーエンジニアの職務経歴書とは全く別の観点で記載する必要があります。


しかし、多くの場合、職務経歴上で上手く表現できている人は少ないです。なぜでしょうか。
それは、エンジニアの多くは転職を多く経験しておらず、プロのエージェントはエンジニアリングのプロではありません。しかし、良い職務経歴書を書くにはエンジニアリングの知識と転職の選考の知識の両方が必要です。

そのギャップによって、自分の実力を十分に伝える職務経歴書にすることが難しく、それを改善するチャンスもなく、残念ながらマッチする会社と出会う機会を失っているかもしれません。

この記事の職務経歴書の書き方で、自分の実力が正しく伝わる職務経歴書をつくってもらえると嬉しいと思っています。

メンバークラスとは違うテックリードの役割

テックリードは技術的な方針を決める役割です。そのためには、技術的リーダーシップを取り、技術的なチームの支援、そして、システムの品質の担保を行うことに責任を持ちます。

つまり、システムをどう作るかの中心の役割となり、チームを推進し、システムの品質維持のための仕組みを作る必要があります。

テックリードに必要な職務経歴書の表現

表現方法にはいくつもの切り口がありますが、今回は5つの観点に注目しました。

  • 技術的意思決定 - リーダーシップ
  • 技術を広く捉える - システムに閉じない技術
  • チームに変化を起こす - 主体的行動
  • 仕組みで解決する - 馬力でない解決
  • 技術的探究心 - エナジージェネレーター

技術的意思決定 - リーダーシップ

技術名を書くときに、既に決まっていた技術を使ったのか、自分でいくつかの選択肢の中から導入を決めたのかで技術に対する理解度の深さが変わります。
技術名を書くだけでなく、技術の導入にどのように貢献したか、意思決定の背景を記載すると良いです。
その際に、この技術をなぜ選んだのかが伝わるとよりベストです。

技術を広く捉える - システムに閉じない技術

技術を書くときにシステムを作るだけの観点になっていますが、テックリードは事業で実現したいことをシステムで作り上げる観点が必要です。
つまり、技術とは事業などの背景があって、最適なものは変わります。
それぞれの技術には特性があるだけであり、メリット・デメリットが存在します。

技術のエピソードには事業やチームの背景があって調整した技術の進め方があるはずです。
これらを言語化して表現できるとより良いです。

チームに変化を起こす - 主体的行動

主体的な行動力はエンジニアにも期待されることが多いですが、テックリードは主体的に行動した結果、自分自身のシステム実装の活動だけでなく、チームへの良い変化を与えることが当たり前に期待されます。
システム実装は1人でつくるものではなく、技術はテックリード1人で解決するものではないです。チーム全員の総合力がシステムの品質に繋がります。

つまりシステムの品質を高めるためには、チームへの何かしらの変化を与えなければ、単純に技術を使っているチームになるだけで、品質を高める文化は作り出せません。
技術を高める文化をリードする役割もテックリードに期待される主体性の1つです。
チームに変化を起こす文化づくりでもチームのフォロワーではなく、リードする主体性が必要です。

自分がいることで起こしたチームの変化を書いておくと良いです。

仕組みで解決する - 馬力でない解決

テックリードはチームで一番技術力が高いです。しかし、ずっとレビューマシーンや設計マシーンとしてチームのパーツになっていてはテックリードのレベルもチームのレベルも上がっていきません。

仕組みの代表としてCI/CDは基本的に導入しますが、仕組みによって品質を維持できるようなことを促すことで、テックリードがチームのパーツとしての負担を減らし、新しい技術課題の解決へ向き合える状態にできることが必要です。

どのような仕組みをチームに導入したのかを書いておくと良いです。

技術的探究心 - エナジージェネレーター

これら4つの行動を起こすためには、そもそも技術が好き、良いシステムを作ることを目指したいという思いが必要です。それらは周りの誰かから与えられるものではなく、自分の内から生まれるエネルギーです。このエネルギーが行動力の源泉です。この根源的な思いが技術への思いです。

なぜ技術が好きで、これまでその思いがあることで、技術的な理解や貢献につながった行動を書いておくと良いです。

まとめ

どの観点でもメンバーに期待するときよりレベル感が高いということです。
同じ技術を表現するときに、理解のレベル感の高さを表現できているかに気をつける必要があります。

技術力はレバレッジが効く、大きな力があるものだと思っています。
その中心に立つテックリードへの期待は大きいですが、チームをリードしていたという事実だけでは十分にその実力が伝わりません。

多くの書類選考が問題なく通る人であっても、面接の時に自分の実力を伝えやすくなる練習として、職務経歴書をブラッシュアップして損はしません。

ぜひ自分の実力を正しく伝えられるように考える機会になればと思います。

6
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?