職務経歴書は、転職のたびに書き方を変えてきました。
今回はSEからコンサル寄りの職種に移るので、見せ方もそれに合わせています。
結果として、全体で12ページになりました。
前回は7ページだったので、5ページ増えた計算です。
中身は出せないので、型と考え方だけ書いていきます。
職務経歴書の書き方で迷っている人
案件が多くて、まとめ方が分からない人
未経験の職種に応募しようとしている人
先に、テンプレートを置いておきます
私が使っている型を、中身を空にしたWordファイルにしました。
書き方のメモもグレーの文字で入れてあるので、不要なら消してください。
そもそもこの形は、最初の転職のときに担当してくれたエージェントの方がくれたものです。
以来ずっと、この項目立てを使い続けています。
自分で1から考えたものではありません。
もらった型をそのまま使い続けているだけです。
ただ、6年ほど使ってみて、項目としてはこれで足りると思っているんですよね。
会社ごとに区切って、中に案件を入れる
まとめ方は、ずっと迷っていました。
会社ごとに書くのか、案件ごとに書くのか。
最終的には、会社という区切りの中に、案件を入れ子にする形にしました。
ただ、それだけだと読みにくい
会社ごとに並べると、時系列や全体像が見えにくくなります。
とくに私のように転職が複数回あって、1社の中に案件が何本もあると厳しいです。
読み手は、いきなり細かい案件の説明から読まされることになります。
逆に案件ごとに並べると、今度は所属がどこだったのか分かりにくくなります。
SESだと、自社と客先の区別もつかなくなるんですよね。
だから、先頭に目次を作った
そこで、いちばん最初に職歴タイムラインの表を置きました。
書くのは3つだけです。
- 期間
- 在籍企業
- 担当した案件の概要
そして、この表からWordの内部リンクで各案件へ飛べるようにしました。
クリックすると、その会社の詳細までジャンプします。
読み手が全体像をつかんでから、気になるところだけ読めるようにしたかったんですよね。
12ページもあると、順番に読んでもらえる前提では書けません。
ちなみにこの表は、面接のときにも役立ちました。
画面共有で経歴を説明するとき、ここを開いておけば流れを一度で説明できます。
開発の案件も、素直に全部書いた
コンサル寄りの職種に応募するので、開発の話は減らそうかとも思いました。
ただ、今の会社では開発案件しか入っていません。
隠しても仕方がないので、そのまま書いています。
ただし、書き方は変えた
工程名を並べるだけにはしませんでした。
「詳細設計をした」「単体テストをした」だけだと、誰が書いても同じ文章になります。
なので、業務内容のところにこういう行を混ぜました。
- 対応する案件の優先度づけを行った
- 課題が発生したときに、チーム内で認識を合わせることを率先して行った
- 業務運用を踏まえた観点で仕様を確認し、修正案を提案した
どれも、言われたからやったことではありません。
メンバークラスの役割としては、やらなくても怒られない範囲の話です。
未経験の職種に応募するなら、ここを書けるかどうかがかなり大きいと思っています。
技術力では専業の人に勝てないので、それ以外で何をやったかを出すしかありません。
チーム体制は、最初から書いていた
項目の中に【チーム体制】があります。
これは、もらったフォーマットの記入例に最初から入っていました。
なので特に意識せず書いていたのですが、これがかなり効きます。
「何人の中の、どの立場で」は必ず聞かれる
面接では、ほぼ毎回この質問が来ます。
前の年に受けた会社の最終面接では、こう聞かれました。
「なんの業務を、どれくらいの規模でやったんですか」
このとき、私は規模を即答できませんでした。
書いてはいたのですが、自分の中で整理しきれていなかったんですよね。
それ以来、人数と期間だけは全案件ぶん書き出すようにしています。
書き出してみると、自分でも忘れていることがけっこうありました。
「あの案件って、結局何人だったっけ」となるんですよね。
面接の直前に思い出そうとしても、まず出てきません。
自己PRは3つ書く
これは前回の転職からずっと続けている方法です。
1つだけだと、応募先の求めるものとズレたときに拾ってもらえません。
3つあれば、どれか1つは引っかかるんですよね。
今回書いた3つ
中身そのものは書けないので、テーマだけ紹介しますね。
① 間に立ってスケジュールを引いた話
ある決済サービスの切り替え案件で、リリース時期を動かせない状況でした。
こちらの都合ではどうにもならない期限だったので、間に合わせるしかありません。
追加要望が出る中で、タスクを分解して優先順位をつけて、本番に最低限必要な機能を見極めました。
② 効果を最大にするために調整した話
RPA化のときに「全部を自動化してほしい」という要望が来ました。
全部やると数か月から1年かかります。
一方、効果の高い7割だけなら、短い期間で大きな削減が出せます。
そこを切り分けて提案した話です。
③ 業務の目的を確認して、不要な改修を避けた話
海外の売上管理システムを入れたとき、カスタマイズなしが前提でした。
ところが、ある項目が標準では500文字までなのに「業務では1000文字必要」という要望が出ます。
何のために必要なのかを聞いていくと、実際は300文字で足りることが分かりました。
10年ほど前の運用がそのまま残っていただけで、数年前から必要なくなっていたんですよね。
3つの役割を分けておく
私の場合、1つ目はどの職種でも通じる内容にしています。
残り2つは、応募する職種に寄せた内容です。
全部を志望職種に寄せると、逆に幅が無いように見えます。
それに、面接官が必ずしも志望職種の人とは限りません。
人事の方が読むことも、役員の方が読むこともあります。
開発経験は、強みとしては書かなかった
ここは少し悩みました。
せっかく3年やったので、強みとして押し出すこともできます。
ただ、やめました。
3年では、専業の人には勝てない
社会人経験が10年以上ある中で、開発は3年です。
同じ土俵で戦えば、10年開発をやってきた人には確実に負けます。
なので、開発経験は「技術力」としては売っていません。
代わりに売ったのはこの2つです。
- ITの全体を広く分かっていること
- 業務側にも理解があること
開発経験は、この2つを支える土台として置いています。
テクニカルスキルの表は、一番下に移した
以前は、テクニカルスキルの一覧を経歴書の先頭に置いていました。
今回は、それを一番下に移動しています。
参考情報という扱いです。
先頭に技術の表があると、技術で勝負する人に見えてしまうからです。
応募する職種によって、この位置は変えたほうがいいと思います。
開発の求人に出すなら、たぶん先頭のままにします。
同じ内容でも、置く場所で伝わり方が変わるというのが今回の実感でした。
待機期間は、そのまま書いた
SESなので、案件と案件の間に待機が1か月ほどありました。
これも隠さず、そのまま書いています。
結果として、触れられなかった
面接で突っ込まれることを想定して、説明は準備していました。
参画予定が1か月後ろにずれた、という事実の話です。
ただ、実際には聞かれませんでした。
12ページの中の1か月なので、気づかれていないか、気にされていないかのどちらかだと思います。
隠して後から出てくるほうがリスクが高いので、書いておいて良かったです。
まとめ：読み手が拾いやすい形にする
正直に書くと、今回は1社しか受けていません。
なので、この書き方が効いたのかどうかは分かりません。
ただ、コンサルファームに応募するにあたって、分かりやすい構成にしようと考えたのは事実です。
やったことをまとめると、この4つでした。
- 先頭に職歴タイムラインを置いて、そこから各案件へリンクする
- 工程名の羅列にせず、指示されなくてもやったことを書く
- 自己PRは3つ、役割を分けて書く
- 応募する職種に合わせて、項目の順番を入れ替える
12ページを頭から読んでもらえる前提では書かない。
読み手が、必要なところだけ拾える形にしておく。
今回いちばん意識したのは、そこだけだったかもしれません。
