業務経歴書（スキルシート）はこう書いてほしい
Tweet
派遣でメンバを募集しているときに、
業務経歴書を見てスキルマッチしているかを確認するのですが、会社によって業務経歴書のフォーマットが違うので、見るのが大変です。
その中には見る気が起きなくなるようなものもあるので、今回は業務経歴書はこう書いてほしいというのを紹介したいと思います。
ワイヤーフレーム
まずはざっくりワイヤーフレームを共有します。
私が採用するワイヤーフレームとしては上記です。
多分、ワイヤーフレームとしてはブレはそこまでないんじゃないかなぁと思います。
スキル情報や自己PRが業務経歴（業務内容概要など）の下にある会社もありますが、まずはその人の情報サマリを見たいので、上にあってほしいです。
こういうものはストーリーで考えてもらいたく、その人の表部分として「基本情報」その人の内容として「スキル情報」や「自己PR」、そのうえで、今まで何をやってきたかということで「業務経歴」があるべきと考えます。
基本情報
- 氏名
- 年齢
- 性別
- 学歴
- 最寄り駅
さて、この中で一番重要なのはなんでしょう？
正解は
最寄り駅
です。次点で年齢、そこから先はもうほぼ気にしません。
年齢も、若すぎるのを嫌がられるのと、年を取ってるのを嫌がられるのがあるくらいですね。
若すぎるのは、経験が少ないから、年を取っている人は、PM、PLが若いとその人が働きづらいからくらいなので、そこまで気にされません。
気にされるのは最寄り駅です。
遠いと通うのが嫌になるんじゃないかという所で、職場と離れすぎている人は敬遠されます
まぁでも、スキルよりも優先度は低いので、さほど気にすることはないでしょう。
サンプルとしてはこんな感じ。
まぁ基本情報についてはどうでもいいですねｗ
スキル情報
が、これを書いてほしい
採用する側は、このドキュメントを読んで、スキルマッチしているかを最初に確認したいのです。
全くなかったりすると、業務内容の方からサルベージする必要があり、スキルマッチしているにも関わらず、書類で落とされる可能性があります。
スキルマッチしてるかを隠したいならしょうがないですが、お互いに不幸になるだけなのでちゃんと出したほうがいいでしょう。
スキル情報には以下を書きます。
- IT業界の経験年数
- 知識として保有している言語
- 知識として保有している技術
- 経験している開発工程
- 保有しているIT系の資格
これらを具体的に何がどれくらいできるかを書いてほしいです。
- 保有言語：Javaなどの言語やフレームワークなどをどれくらいできるのか
- 保有技術：言語にない他サービス（AWSとかGitとか）をどれくらいできるのか
- 経験工程：要件定義～保守・運用まで、何をどこまでどれくらいしてきたのか
- 資格：いつ、何を取っているのか
上記のことが分かるようにしてほしいです。
勘違いしないでほしいのが、「どれくらいできるか」について、勝手な数値化をしてほしいわけではないです。
「Javaの評価が5です！」と書かれても、何を基準に？としか思いません。
アナタの会社ではそうなのでしょうが、基準も何もないものを出されても信じられません。
なので、業務での経験年数を書いてもらえばよいです。
大体、業務経験が何年ということで、あれば、基準としては年数なので、決まっているものなので、これくらいやっているのであれば、「会ってみようかな」と思えます。
もちろん。経験の中で、濃い経験なのか、うっすい経験なのかがあると思います。
それは面談の時に具体的なことを聞きますので、会うきっかけとしては経験年数で問題ありません。
なお、資格については、スキルマッチするための資格やすごい資格でなければ、あまり意味を成しません。もちろん新人レベルの人であれば、資格を持っていることが採用につながると思いますが、そうでなければ、基本的には経験を見ます。
仕事するうえで、勉強だけできる人は要らないんですよね。。。
テストの点数より、実践と経験のほうが重要だということです。
サンプルの言語、技術、工程は適当に書きました。
経験年数
これは、単純にIT業界の経験年数を書いてもらえれば良いです。
保有言語・保有技術
保有言語・保有技術は、二列で書いてますが、もうちょっと工夫して、行を減らしてもいいかもしれません。
また、経験年数は毎年変わってしまうので、以下のような凡例でもいいかもしれません。
◎：業務経験5年以上、○：業務経験3年以上、●：業務経験１年以上
▲：業務経験1年未満、△：知識あり
私は、工程について、それぞれ細かい作業工程を書いてほしいと考えておりますが、スキル情報を書いている会社さんでも、ここはなかったです。
なぜないのだろう。。。
最近はアジャイル開発も増えてきたので、開発工程の経験があってもいいかもしれません。
アジャイル開発は経験がないとちょっと戸惑うこともあると思います。
資格
資格は何でも書けばいいわけではないです。
IT業界の資格を書いてほしいです。簿記、自動車免許、書かなくていいです。。
一般資格書かれてもねぇ。。
自己PR
これは大抵、メンバが書くもので、何書いていいかわからず、
「不明点は自己解決できます。また勤怠・コミュニケーション共に問題ありません」
みたいなことが書かれたりしますが、これ要らないです。
勤怠に問題がある時に書いてくれれば良いです。自己PRで上記のようなこと書かれても何のPRにもなってません。
そんなもの書いてもしょうがないです。
逆に、書く気ないのかな？とか思っちゃいます。
あと、たまに勘違いしてる人？会社？が居て、容姿のこととか書いてあったりすることもありますが、要らないです。むしろなぜ書く・・・
自己PRを「自分の特別なことを書くのだ」と、とらえるから難しいのです。
自分に対する概要を書いてもらえれば良いです。
必死に良いことを書くのは辞めれば、結構簡単に書けるかなと思います。
社員に書かせるために、会社側は「自己PR」という題目にしないことで工夫は出来ると思います。
例えば「特記事項」とか「コメント」とか
また、ポートフォリオなどがあれば、ここに記載してほしいです。
ポートフォリオはあればそれを出してもらうのはとてもいいことですので、ぜひ出してほしいです。
ただ、見ても、ログインできない画面とか、ソースがひどいものとか、マイナスになることもありますので、出すときには注意しましょう。
サンプルとしてはこんな感じ
サンプルでは「備考」も一応用意しました。こちらには、例えば「残業が出来ない」とか「0.5人月契約」とかを書いてもらうという風に考えました。
即日契約可、8月一日からの契約みたいな営業からの一言みたいな感覚ですね。
まぁなくてもいいですｗ
業務経歴
ここが本当にフォーマットがバラバラです。毎回違うので、情報取得に時間がかかるんですよね。。。
なので、ぱっと見でわかるようにしてほしいです。
確認するところとしては以下
- プロジェクトの参画期間
- プロジェクトの規模
- プロジェクトの概要
- 使用言語・技術
- 作業環境
- 作業工程
これらをパッとわかるようにしてほしいわけです。
特に作業工程は瞬間で分かりたいです。開発者がほしいのに、ずっとテスタやってる人はスキルマッチしてないわけですからね。
業務経歴を昇順（古い順）に書くのも辞めてほしいです。
ほしい情報としては新しい情報なので、10年前とかのプロジェクトなんて見たくないです。そんな昔のプロジェクトのことなんて覚えてないでしょうからねｗ
こちらは、正解がまだ見えてないのですが、私が見やすいものとして上記サンプルを上げさせていただきました。ほかにいいものがある場合は意見頂きたいです。
基本情報
基本情報として、「期間」「ポジション」「規模」を書くようにしました。
参画プロジェクトの外部情報ですね。
結構の場合、期間だけ書かれていて、ポジションを別で書いていたり、規模がなかったりしていますが、ここで良いんじゃないかと思います。
プロジェクト内容
次に、プロジェクト内容で「参画プロジェクトの概要」と「自分が何をしてきたか」を書きます。
ここでも、参画プロジェクトの概要しか書いてくれない人が多いですが、そういう人はちょっとどうかなって思っちゃいます。
自分が何してきたかを書けないのかな？と疑問が湧いてきちゃうんですよね。。。
面談するときは基本的にこのプロジェクト内容をもとに質問するわけで、内容が薄いと質問することも減ってきてしまいます。
なので、以下の項目に分けて、プロジェクト内容を書いていただきたいと思います
- プロジェクト名
- 開発モデル
- プロジェクトの概要
- 担当業務
- コメント
最初の行にプロジェクトの名のようなもの。本当のプロジェクト名ではなく、一行でわかるプロジェクトの概要みたいなものを書いてください。
開発モデルは前述もしましたが、最近はアジャイル開発も増えているので、合ったほうがいいと思います。
アジャイル開発しているプロジェクトはアジャイル開発経験者を望みます。
次にプロジェクトの概要として参画するときの立場と、プロジェクトがどのようなものを開発したのかを記述します。
さらに、担当業務として、箇条書きで、やっていたことを記載します。製造などでも、具体的なことを書いてよいと思います。
最後にコメントは、そのプロジェクトに対して、どのような工夫をしたか、どのようなことがあったかを簡単に記載します。
作業環境
ここは、嘘偽りなく、作業環境を書くだけです。
「OS」「DB」「IDE」「Version管理」「エディタ」「PJ管理」「スケジュール管理」「その他」を例で挙げてます。
こちらについては、ないものは省いても良いですし、逆にあるものは別でまとめて出したほうがいいと思います。
例えば「コミュニケーションツール」「グループウェアツール」としてMattermostとGsuiteを上げてますが、それらをカテゴリにするのも悪くはないと思います。
使用技術・言語
こちらは開発に使った技術や言語をあげます。
基本的には「言語」 「FW・ライブラリなど」で良いと思います。
ちょっと私の畑ではないのですが、インフラの場合も書いています。
「クラウドサービス」「サーバ」「ミドルウェア」くらいかなと思ってますが、他にも色々あると思うので、工夫していただければと思います。
作業工程
最後に作業工程です。
こちらもどれくらい細分化するかは、その会社次第かと思いますが、私はとりあえず、ウォーターフォールとしての、要件定義,基本設計,詳細設計,製造,単体テスト,結合テスト,品質テストに加えて、管理と運用・保守を追加しました。
さらに、テストについては設計と実施も分けました。完全テスターであるかを分けるためです。
サンプル続き
最初のサンプルは管理者としてだったので、続きとして開発者版も書いてみました。
基本的には一緒ですね。
開発なので、所々少なくなってるくらいです。
担当業務の製造はもうちょっと細かいことを書いてもいいかもしれません。
例えば、サンプルの場合、「HTMLパーサを利用し、特有文字を抽出する機能を実装」とか
まとめ
今回は業務経歴書（スキルシート）はこう書いてほしいという私の意見を記述させていただきました。
この業務経歴書がすべての会社でフォーマット決めてくれたら本当に幸せになれると思いますｗ
IBMさんとかマイクロソフトさんとかIPAさんとかどっかでかい会社がやってくれたら広がるんだろうけどなぁ～～～
Tweet
コメント
コメントを投稿