イケてる業務経歴書を書くために

業務経歴書もしくはスキルシートとはその要員がどのようなお仕事・案件に参画してきたかを記したものです。
技術者の方々も伝わりゃ良いんだとあんまり真剣には書いて貰えない場合もありますよね。
しかし、この業務経歴書は案件参画可否の半分以上を占めていると言っても過言ではありません。
SES営業さんと技術者の方にとっては業務経歴書こそが戦う武器になるのです。
業務経歴書がきちんと書けているだけで面談へ進む確立も採用の確立もアップする事は間違いありません。
以下に記載するときのポイントを上げてみます。

案件内容、案件詳細と参画期間

どんな案件にいつからいつまで参画していたか、の情報になります。
一番根本の情報ですね。
どんなお客様のどんなシステムについて、どんな作業をしたのか、またそこで何を学べたのかを書きましょう。

ここでのポイントは同じ期間としてまとめられる物は出来るだけまとめるという点です。
よく、同じお客様で違う案件に参加した場合に期間を分けて記載する人がいます。
気持ちは分かりますが一つ一つの案件が短いのは「すぐに追い出されるタイプ」という印象を持たれるため避けた方が良いでしょう。

案件に参加したことで何を学べたかも記載するとポイントアップに繋がります。
これを書く事で『この人はこれについてはしっかり理解しているんだな』と受け側にもわかりやすく伝わります。

また新しい案件から降順に書くか、古い案件から昇順に書くか、は議論される点ですね。
個人的には新しい物から記載し、顔合わせの場で上3つくらいを説明するのが良いかと思っています。

プロジェクトの人数、チーム人数、ポジション(役割)

次にプロジェクト全体としての人数と、自分が所属していたチームの人数、そして自分のポジションを明記しましょう。

ポジションはメンバー、サブリーダー、リーダー、マネージャーなどになりますが、ちょっと管理したからといって『PMやってました！』みたいな書き方はやめたほうが無難です。
あ、この会社はマネジメントを理解していないな、と思われます。
マネージャーはBPさんのアサイン権限をもっている人以上の人を指すと思った方が良いです。
何人か下についている場合はリーダーといったほうがピッタリくるでしょう。

使用言語、OS、ミドルウエア、フレームワーク、ツール

使っていた開発言語など技術環境は自分が使っていたかどうかに関わらず全て記載しましょう。
ポイントとしてはバージョンなども記載すると先方へのアピールになります。
自分の参画している案件で使っていたバージョンを答えられないのは先方が技術者さんだった場合にかなりの減点になります。
言語だったらJavaいくつだったのか、ミドルウェアやDBのバージョンは何だったのかは、自分にそれほど関係無くても案件参画時にしっかり把握するようにしましょう。
また、自分自身がその環境でどんな技術を使って何していたか、は案件詳細に記載する方が良いでしょう。

参画フェーズ

要件定義、外部設計、内部設計…などどのフェーズに参画していたかを記載します。
ここで注意すべきポイントはフェーズとしては参画していたけど作業をしていたのかを分かるようにする点です。

例えば上流からテストまで参画していたとしても実装は行っていなかったとしましょう。
その場合、フェーズとしては参画していたので『実装・UT』フェーズに●とか記載すると思いますが実装はしていませんよね？
この場合経歴書を見る側は●がついていれば実装もいけるかな、と期待してしまいます。
●と○を使い分けるなど見分けがつく何らかの区別があると良いかもしれません。

セールスポイントなど

案件一覧以外にセールスポイントや、得意業務／技術などを記載する欄がある経歴書もありますよね。
そこって皆さんあんまり書いていませんが、経験したことがあることと得意なのは違いますから必ず記載するようにしましょう。
どんなポジションのどんな作業が得意か、などを書いておくと良いでしょう。

おわりに

以上、業務経歴書を書く際のポイントをまとめてみました。
これくらい書けていれば、少なくとも業務経歴書で損をする事はない…と思います。
格好良い業務経歴書を書いて合格率アップを目指してくださいね！