どうもこたにんです。
職務経歴書ってあるじゃないですか
転職活動のときに書くじゃないですか、職務経歴書。
前職でどれくらいの期間何やってて、こういうスキル身につけて、みたいな。
企業の採用担当としては、とにかく必須なもので。
その人のある程度のスキルとか職責とか立ち位置とかが文字ベースでわかるので。
飾らずいうと「ふるいにかけるため」に必ず目を通す、かなり細部まで読む書類です。
わたし自身、自社エンジニア採用を担っている身として。
いろんな求職者の方々の職務経歴書を読むことがとても多くて。
これはある程度包めて言うと、1日平均複数名の職務経歴書を読んでます。
かなりの数に目を通してると、だいたいクラスタリングされていくんですよ。
良き人、悩ましい人、よくない人、尖ってる人、など。
それがわりと自身の中で感覚的に判断しているかもしれないので、少し明文化してみます。
どういう職務経歴書だとBadなのか、逆にGoodなのはどういうものなのか。
今回は私こたにんの職務経歴をピックアップして例にして書いてみます。
(あくまでピックアップなのですべて書くわけじゃないですので、時期とか適当です)
個人的な観点なので、自社含め全ての企業がそうとは限りません。
あくまでも自身の職務経歴書をブラッシュアップするためのいちアドバイス、という視点でご覧ください。
それでは。
よくない感じの職務経歴書
時期 | 内容 |
---|---|
現職 | |
2017/06- | |
2016/04- |
ECサイト WEBアプリケーション刷新プロジェクト 要件定義/設計/実装/テスト/リリース/保守 Java(SpringFramework)/JavaScript/TypeScript/HTML/CSS/apache/Linux /Eclipse/IntelliJ IDEA/Jenkins/IDCF |
2015/10- 2016/04 |
ECサイト 社内向けCMSツール保守 設計/実装/テスト/リリース/保守 Java(SpringFramework)/JavaScript/JSP/HTML/CSS/apache/Linux /Eclipse |
前職 | |
2012/04- |
通信事業者向けWEBアプリケーション 要件定義/設計/実装/テスト/リリース(客先)/保守 |
2010/04- 2012/03 |
地図データ変換アプリケーション(社内向け) |
ある程度書きました、ある程度。
しかしこの職務経歴書、よくないポイントはどこでしょうかね。
果たしてあなたはどの立ち位置で仕事してたの?
これ、とにかく多い。
携わっていたプロジェクトとそのディテールが記載されているのはわかる。
そこで自分が担った工程が書かれているんだけど、そこが不明瞭なの。
「詳細設計、実装、テスト」と書かれても、まあそうだよね開発プロジェクトならあるよね。
それで果たしてあなたはどの立ち位置で仕事してたの?ってなる。
詳細設計に工数の大部分を割いてたのか、実装をめちゃくちゃやってたのか、ただのテスターだったのか。
横並びで「詳細設計、実装、テスト」と書かれていても、どの工程に比重を置いていたのかがわからない。
技術スキルはどれがメインなの?
これも非常にわかりづらい。
そのプロジェクトで扱っていた言語やミドルウェアを書くのはわかる、それでだいたいどういうシステムか把握できるから。
ただ、それらのうち自身が担っていたのはどこで、どれが一番得意なの?ってなる。
その業務を通して何を得たの?
立ち位置と技術がわからないので、その業務で何を得たのかがわからない。
その人がどういう立ち回りをして、何をして、得たものが何なのか。
「そこらへんは口頭で説明すればいっかな」と思ってても、書類で落ちてしまうリスクがあるので、それは希望的観測。
どうやったら良い感じの職務経歴書になる?
よくないポイントはいくつかはわかりました。
じゃあ、どうやったら良い感じの職務経歴書になるでしょうか。
答えはシンプルです。
サマるな!伝えたいことは書けるだけ書け!
ただそれだけ。
書類の時点で判定する内容は企業によってまちまちだろうけど。
どの企業も共通して言えるのは「文字だけで判定する」というところ。
その文字を読む人がどう受け取るか、それは完全にひとそれぞれです。
採用担当者全員が同じマインドで同じ性格で同じ目線で書類は見ていないです。
自分が自分の職務経歴書で、何を伝えたいのか。
「こんだけがんばりました!」「こんなことができます!」「ここが得意です!」
自分ではわかって書いてるつもりでも、これを手にとって読む人に伝わらないと意味ない。
だから、サマらず(要約せず)に伝えたいことをきちんと書く。
書き方が文章チックになってもいいし、Boldにするだけでも全然違うんじゃない。
「長ったらしいから読まない」と割り切ってしまう採用担当者がいるかもしれません。
でもそのような文章苦手マンよりも、書かれた文章全部読みたいマンの方が多いよ。
気にせずに、安心してたくさん伝えたいこと書いていいんだよ。
いろんな採用エージェントからどう教わるのかはわかんないけど。
(自分も過去にどう教わってたか忘れたけど)
フォーマットに倣いすぎず、自分の経歴なんだから、自分らしく書こう。
というわけで、それを加味して先程のわたしの職務経歴書を書き直しました。
ちょっと良い感じの職務経歴書
時期 | 内容 |
---|---|
現職 | |
2017/06- |
ECサイト フロントチーム エンジニアリングマネージャー |
2016/04- |
ECサイト WEBアプリケーション刷新プロジェクト 要件定義/設計/実装/テスト/リリース/保守 Java(SpringFramework)/JavaScript/TypeScript/HTML/CSS /apache/Linux/Eclipse/IntelliJ IDEA/Jenkins/IDCF Java(ほげフレームワーク)で構成されていたWEBアプリケーションをSpringBootを基とした新しいWEBフレームワーク環境に刷新するプロジェクトの実装担当を務めた。 既存のWEBアプリケーションの仕様をもとに、刷新後の仕様の再策定から担当し、機能の断捨離、必要仕様の再定義、ソフトウェアアーキテクチャ設計をはじめ、主にサーバサイドレンダリング〜クライアントレンダリング部分の実装(Java, JavaScript)、テストとデプロイ方法の検討、サーバ内ミドルウェア(apache+tomcat)の設定チューニング、リリース初期のリリース作業と運用Tへの引き継ぎ、などを一貫して行った。 サイト全体を一気に刷新するのではなく、部分的に徐々に刷新を進めていくことで、負荷やほげほげ。 |
2015/10- 2016/04 |
ECサイト 社内向けCMSツール保守 設計/実装/テスト/リリース/保守 Java(SpringFramework)/JavaScript/JSP/HTML/CSS/apache/Linux /Eclipse 社内で利用しているCMSツールのカスタマイズ機能の保守および新規実装を担当した。 |
前職 | |
2012/04- |
通信事業者向けWEBアプリケーション 要件定義/設計/実装/テスト/リリース(客先)/保守 |
2010/04- 2012/03 |
地図データ変換アプリケーション(社内向け) CentOS/PostgreSQL/Java |
とまあ、こんな具合に。
あんまりたくさん書いたらわりとガチの職務経歴書になっちゃうから、部分端折ったけど。
たとえばこの厚みのある経歴書を見ると、現職の2行目がやたら長いよね。
ということはこの人は、何かこのときにすごく現場力高まったのかなあとか。
たぶんコーディングするのが好きなのかなとか、すごい仕事持ちたがりなのかなとか。
たくさん伝えたいことを書くことで、書類を見る担当者の頭の中に質問がたくさん生まれます。
「ここなんだろう、面接でもう少し掘り下げて聞きたいな」って思わせたら勝ち。
実際私も、面接で詳しく聞きたいなあって思うケースが多いし。
サマって書いた職務経歴書から察してもらうよりも相当いいと思います。
このように厚み持たせて、書類から伝わる勢いとか人となりとか、そういうのを大事に。
まとめ
職務経歴書はサマるな。
とにかく伝えたいことを自分の言葉で書く。
あとは自己PRなんというものも使いこなせば良い感じだとは思うけども。
結局自己のPRなんて自己のものなのだし、書いてもいいんだけど。
それがどの業務で培われたとかどの業務で活きたとか、そこまで紐付いてるといいよね。
もとい。
まとめでさらに話が発散しそうだった。
とにかく、職務経歴書。
たくさん書いて。
想像以上に、採用担当者は、これを読んでるよ。