スキルシートで自分のスキルを伝えたい
スキルシートはエンジニアの商売道具の一つです。
実際のスキルはもちろん大切なのですが、そのスキルを過不足・誤解なく伝えるためにはスキルシートの書き方がとても重要になります。
今回はスキルシートの書き方や相手はどんなところを見ているのかを考えてみましょう。
スキルシートの使われ方
スキルシートとは?
そもそもスキルシートって何でしょう??
実は呼び方もスキルシートって言う場合と『業務経歴書』という場合もあります。
総じて『今までエンジニアとしてどんな仕事をしてきたか』をわかり安くまとめた資料と考えれば良いでしょう。
どんな時に使うの?
使われ方としては転職時や案件参画を提案する際の提案資料の一つになります。
つまり受け入れ側はこのスキルシートを見てこの人なら参画して活躍できるかをチェックしているわけですね。
ここで注意したいポイントとしてはあなたが「Javaが出来るか」を見ているのではなく「プロジェクトにマッチするか」を見ているという点です。
以前noteでも書きましたがエンジニアの仕事はプログラムを書くことではなくシステムを作る事です。
プロジェクトとはシステムを作るチームであり段取りです。
つまりスキルシートはこのシステムを作るのに必要な人間であることをアピールするものと言えます。
フォーマットについて
昔から使われているのはExcelを使ったスキルシートのフォームですね。
最近はパワポで作ったりマークダウンのサイトで記述される方もいらっしゃいます。
個人的には必要な事が記載されていればどのやり方でも構わないと思いますが、使いどころの要件としてはPC、モニタ等が使える環境とは限らないという点がありますので紙で出力出来る必要があるかな、と感じます。
まぁそういう会社は選ばない、というのであればそこは除外してもw
また、スキルシートに案件を記載していくのですが、その際に最新から書くか過去から書くか問題はずーっと言われ続けている話になります。
個人的には若手は古い方から、ベテランは新しい方からがオススメです。
理由は若手は何を積み上げてきたかを知りたくて、ベテランは全部見るのが面倒だからw
書き方のポイントは?
1行1案件
スキルシートに書くべき事は色々ありますが
・氏名(イニシャル)、年齢、居住地域などの情報
・スキルのサマリー
・案件毎にどんな仕事をしてきたか
は少なくとも記載する必要があるでしょう。
案件毎に1行、と聞いてほとんどの人は疑問を抱かずに書き進めようとしますが、書き上げて貰うと『案件』の単位が人によって違ってて面白いです。
参画した顧客単位に書く人、顧客の中で複数のシステム(サブシステム)に関わったときそれ毎に1行書く人もいます。
私は顧客毎に1行、その中の個別案件はその内訳として記載することをオススメしています。
理由はこの1行の期間が短いと「すぐにNGだされて追い出された人」と見えてしまうから。
1顧客で複数案件任される頼りになる人と短期間でコロコロ仕事が変わる人では印象が180度違いますね。
どんなシステム?
開発に関わったのはどんなシステムなのかが分かるようにしましょう。
顧客名を出すのは御法度なので、どんな業界のどんな部分のシステムなのか、それは新規開発なのか追加開発なのか、保守開発なのか運用保守か。
この説明が出来ない人が実は結構多いんですよね。
自分が作ったプログラムは分かりますがシステムはどんな物か知りませんって言われてもそれを見た人も困ってしまいますね。
実装に必要ないと思うかもしれませんが、自分の作るプログラムが全体のどこでどのように貢献しているか、知ることってワクワクしませんか?
バージョン意識してますか?
案件毎にどんな技術要素を使ったか書くと思いますが、通常だとJavaですReactですと記載すると思うのですが、ここで私が強く勧めたいのがバージョンまでしっかり記載するという事です。
これは技術力のあるリーダー(一般的に技術側のリーダーはマネジメントと分離される)がとっても気にするポイントと思っています。
何故かというとそういう点まで理解した上で仕事に取り組む人は物事を丁寧に理解してくれる事を期待できるからです。
「Javaはざーっと書けますよ」という人と「Java1.2をメインでやってきしたが1.4の○○は便利でした」って言う人でこの違いは理解出来ると思います。
またバージョンに関しては言語だけでなくミドルウェア、DB、サーバーなど書けることが多ければ多いほど良いでしょう。
※試しに身の回りの仕事出来る人と出来ないと思う人にバージョンの質問してみましょう。出来ないと感じる人は大抵答えられませんw
フェーズと担当作業
案件毎に記載する内容として技術要素と同じレベルで必要なのが担当したフェーズと担当した作業です。
一見するとフェーズと担当作業って重複したようにも感じますし、世のIT関係者が一律に同じ認識を持っていれば良いのですが、実はそこを見極めたいから書いて欲しいというのが本音です。
例えば基本設計からやっています、と言っても基本設計書、という中には数十のドキュメントがあります。それを全て対応していたのであれば素晴らしいのですがその中で画面設計をしたのかテーブル設計をしたのかを担当作業に記載すれば誤解なく伝えることが出来ます。
またここでは実装力もアピールしたい所ですね。新規の画面をイチから作った、担当した画面数は○○あった、などどれくらい手を動かしたのかをアピールしましょう。
やっちゃいけない書き方
細切れにしすぎ
上でも書きましたが案件を短期間で変わっている人は使えずに移動させられた、と見られる傾向があります。
そのため『同じ元請けなんだけど別顧客のシステム開発にスライドした』という場合などどう記載するか迷うと思うのですがこの場合一つ一つが年単位であれば2行でも構いませんが数ヶ月の場合などは1行にして内訳として2顧客を書くという手もあります。
技術要素や担当フェーズが変わってしまった場合は難しいかもしれませんが上手く表現するのもアピールの一つです。
説明が足りない
スキルシート書いたからってスキルが上がるわけじゃ無いし何度も使うわけじゃ無いし書くのも面倒ですよね。
だからかもしれませんが記載がすっごく少ない人がいます。
見ている側としては、書く事が少ない=仕事を少ししかしていない、なので参画出来る確率はガタッと落ちます。
弊社では面倒をできるだけ回避するため年に2回の評価面談の際にスキルシートの更新をお願いしています。
半年くらいであればまだ記憶に新しいですから書きやすいと思っています。
他にも、新しく案件に参画したとき、異動したとき、ポジションが明確になったときなど節目節目で更新すると筆も進みますw
誤字、脱字、てにをは
一番やっちゃいけないのがこちらです。
やっぱり面倒だからテキトーに記載している人が一定数います。
誤字脱字は自分が感じている以上に人間の評価を落とします。
誤字脱字→見直しをしない→実装でもバグを垂れ流す、というイメージでしょうか。
また個人的に「てにをは」が出来てない人は頭の中も整理されていないイメージがあります。○○を、と○○が、では全く意味が違うのでそれを識別せずに思考している人は理論整然とした思考ができないという考えです。ですが、全て英語で思考されている人には当てはまらないですねw
おわりに
今回はスキルシートについて考えてみました。
全体的に「これを見た相手はどのように理解するか」を意識して書けば大外しすることはあんまりないのかな、と感じています。
せっかくの自分の武器ですから面倒でも一歩進んだ格好の良いものに仕上げてみませんか?
きっとひと味違う結果が待っていると思いますよ!
この記事が気に入ったらサポートをしてみませんか?