ラブレターは読まれてなんぼ――“読ませる”エンジニアの職務経歴書を書く：きのこる先生のエンジニア転職指南（2）（2/2 ページ）

職務経歴＝過去の実績を効果的にアピールすべし

（a）開発の範囲

　「範囲」とは、「開発行程」と「担当分野」のことです。

　ウォーターフォール開発では、開発工程は「要件定義」「設計」「開発」「試験」「運用」に分類できます。メインで担当した部分を強調しつつ、どこからどこまでに携わったかを記入しましょう。

　担当分野については、「プログラミング」のみならず「ネットワーク設計」や「サーバ構築」、「アーキテクチャ選定」など、開発のどのレイヤに携わったかを書きます。担当した経験はできるだけ書き、選考のための情報を増やしましょう。

（b）開発の規模

　「規模」とは、アプリケーションの規模のことです。

　Webサービスを運用する企業は、慢性的に負荷の問題に悩まされています。当然負荷を考慮した開発をしてほしいので、ある程度規模の大きい（＝負荷の高い）開発経験を持っているかどうかが、選考のポイントになります。

　規模の指針を具体的な数字（サーバ台数、PV数、トランザクション数など）で書くと説得力が増します（もちろん守秘義務に触れない範囲で！）。

（c）アーキテクチャ

　「Rubyでの開発経験」と「Ruby on Railsでの開発経験」は、似ているようで結構違います。RDBMSでもOracleとMySQLとPostgreSQLでは気をつけるポイントがかなり違いますし、LinuxでもRedHat系とDebian系では「常識」が違います。

　スキルの本質はフレームワークやディストリビューションに左右されるものではありませんが、利用経験がマッチしていれば選考に有利に働く場合があります。利用した技術はできるだけ具体的に書きましょう。

書類の“体裁”もそれなりに大事

　さて、ここまでのお話は書く「内容」についてのお話でした。ここからは「体裁」のお話に入ります。

　応募書類を読むのは、採用担当だけに限りません。エンジニアの選考を行うのであれば当然、選考のどこかのフェイズでエンジニアが書類審査に参加してきます。つまり、応募書類は「同業であるエンジニアに読まれる」ことを意識する必要があるのです。

　エンジニアが書類を見るとき、最も気にするのは職務経歴ですが、他にも意外と気になるポイントがあります。細かいけれど重要なポイントを、2つほど挙げてみましょう。

◎PDF1枚にまとめる

　エージェントから送られてくる書類は、結構フォーマットがまちまちです。一番多いのはPDFですが、WordやExcelのドキュメントも相変わらず根強い人気を誇ります。

　エンジニアは、MS Officeがインストールされた環境で仕事をしているとは限りません。私自身「開発するならMac」と決めていますし、人によってはUbuntuなどデスクトップLinuxを使っている場合もあるでしょう。そうすると、WordやExcelのドキュメントを開くというだけでも結構な負担になるのです。

　また、「推薦書」「履歴書」「職務経歴書」がそれぞれ別のファイルになっていると、閲覧と整理にも手間がかかります。

　最悪な（でもよくある）ケースは

というコンビネーションです。ここまでくると「もしかしてこれは、“読まないでもいいんだからね！”という婉曲表現なのか？」と思ってしまいます。PDFなら、異なるフォーマットの書類を1つのファイルにまとめられます。エージェントと相談して、「書類は1枚のPDFにまとめて応募すること」を強くお勧めします。

◎技術用語は正確に

　第1回の「ズッコケスキルシート」でも書いたとおり、エンジニアは技術用語を厳密に使いたがります。用語に間違いがあると、それだけで若干スキルが低く見えてしまいます。

　用語の間違いは、きちんとチェックすればほとんど防げます。スペルの間違いはもちろん、大文字／小文字の使い分けにも敏感ですので、書き終わった書類は慎重に見直しを行いましょう。間違いとしてよくあるパターンには、こんなものがあります。

• スペルミス

　タイプミスなのか勘違いなのか、結構スペル間違いを見掛けます。古くは「pearl」に始まり、定番の「Apach」「Strats」。最近大流行している「Android」も見逃せません。これではただの安藤さんです。しっかり読み直しましょう。

• 大文字／小文字

　大文字 / 小文字の使い分けが間違っているパターンで、「JAVA」「php」あたりが代表選手です。最近は「ios」というものを見て、一瞬首をかしげました。

※余談ですが、「SmallTalk」という誤用があまりにも多かったので、ついカッとなって本当に「SmallTalk」というジョーク言語を実装してしまったSmalltalkプログラマがいたそうです。

• いわゆる「全角」文字

　技術用語としての文脈では、英数字や記号をASCIIで記述するべきです。ここでも「ＪＡＶＡ」は根強い人気を誇っています。「Ｒｕｂｙ　ｏｎ　Ｒａｉｌｓ」という貴重なサンプルがありましたが、残念ながら保護したいタイプのサンプルではありません。

　いかがでしょうか。エンジニアとして、同業者に読まれて恥ずかしくない書類を目指しましょう。

そろそろまとめ。そして次回予告

　今回のまとめです。

　今回は「過去の資産」をアピールするポイントについて書きました。次回は「未来への希望」をアピールするポイントを説明します。

　きのこにとって未来への希望は「おいしく料理してもらうこと」ですが、企業がエンジニアに求める未来への希望は「適応して成長すること」です。秋の味覚を楽しみながら、お待ちください。