エンジニアキャリアの歩き方
評価される職務経歴書・履歴書の書き方
書類で落ちる理由は、たいてい技術が足りないからではありません。書いてあることから、その人がどう考えて仕事をしているのかが読み取れないからです。
「担当しました」は、誰が書いても同じになる
「決済機能の開発を担当しました」「チームリーダーとしてマネジメント業務を行いました」。どちらも嘘ではありませんが、同じプロジェクトにいた 5 人が全員この文章を書けます。読む側からすると、この人に会いたい理由が見つかりません。
採用担当者は 1 通に何十秒しかかけられません。その短い時間で読み取ろうとしているのは、技術の一覧ではなく「うちの現場に入ったとき、この人はどう判断するのか」です。作業の記録をいくら丁寧に並べても、その問いには答えられません。
言語やフレームワークの名前を増やすことでこれを埋めようとする人は多いのですが、名前が増えるほど「広く浅く触った人」に見えてしまうこともあります。書く量ではなく、書く中身の種類を変える必要があります。
書くのは、何を選んで、なぜそうしたか
同じ経験でも、選んだことと理由を足すだけで別の文章になります。
避けたい書き方は次のとおりです。
プレーンテキスト
決済処理のリファクタリングを担当しました。書き換えると、次のようになります。
プレーンテキスト
決済処理の分岐が 1 つの関数に集中していて、修正のたびに別の箇所が壊れていました。
まずテストを足してから分割する順で進め、リリースは 3 回に分けています。
全部を一度に書き換える案もありましたが、障害が出たときに原因を切り分けられなくなるため見送りました。長さはほとんど変わりません。違うのは、選択肢が 2 つ以上あったこと、そのうち 1 つを選んだこと、選んだ理由が書いてあることです。捨てたほうの案を 1 行足すと、判断の重さが伝わります。
派手な意思決定である必要はありません。ライブラリを入れずに自前で書いた、既存の書き方に合わせて我慢した、といった地味な判断でも、理由が書いてあれば読み手には十分伝わります。むしろ、制約の中で折り合いをつけた話のほうが、現場で一緒に働く姿を想像しやすくなります。
数字は、選択の結果として置く
「レスポンスを 30 パーセント改善」とだけ書かれていると、読む側は何をしたのかが分からないまま数字を眺めることになります。何が問題で、どう決めて、結果どうなったか。この順で並べたとき、数字はようやく裏付けとして働きます。
数字が出せない仕事もあります。測っていないものを書くと、面接で必ず「どうやって測りましたか」と聞かれて詰まります。無理に作らず、問い合わせが減った、レビューの往復が減ったといった、自分が観測した範囲の事実を書けば十分です。書けない数字を空欄のままにしておくほうが、根拠のない数字を置くより安全です。
半年前の判断は、思い出せない
この書き方をしようとすると、たいてい書く材料が足りないことに気づきます。技術名は思い出せても、なぜその設計にしたのかは忘れているからです。
転職の予定がなくても、判断したことをその週のうちに 1 行残しておくと、あとで書くときの材料になります。プルリクエストの説明文に理由を書く習慣がある人は、それがそのまま材料になります。棚卸しは、辞めると決めてから始めるものではありません。
復習ミニクイズ
エンジニアの職務経歴書において、自身の「実績」を最も効果的に伝える記述方法はどれですか?