バックエンド職務経歴書でシステム規模と障害対応をどう書くか

バックエンド職種の求人票は、応募者がどのトラフィック規模でどの指標をどこまで管理していたかを見ています。システム規模は処理量・データ量・レイテンシの百分位といった測定可能な単位で書き、障害対応は検知・緩和・復旧・再発防止の4段階のタイムラインで書きます。そのうえで応募先の求人票の要件と一文ずつ突き合わせると、どの経験を上位に置くべきかが決まります。

私たちrefresh.cvでは、求人票を読み込んで要件とATSキーワードを抽出し、そのキーワードが職務経歴書の表現と実際の経験の裏づけの両方にあるかを突き合わせる作業を扱っています。バックエンドの職務経歴書で最もつまずきやすいのは技術スタックの羅列ではなく、規模と障害を語る単位が定まっていないことです。単位さえ決まれば、同じキャリアでも求人票ごとに違う職務経歴書を作れます。

規模は形容詞ではなく数値で示す

「大規模」「高トラフィック」「安定運用」は検証できない表現です。信頼性エンジニアリングの分野ではすでに共通の単位が使われています。Google SREブックは、サービスレベル指標(SLI)の中心にリクエストのレイテンシを置き、エラー率(全リクエストに対する失敗の割合)とスループット(秒間リクエスト数)を代表的な指標として挙げています。

職務経歴書の一行に落とし込める規模の単位は、おおむね次のとおりです。

軸	使う数値	文例
トラフィック	ピークRPS、DAU、日次呼び出し数	ピーク4,200RPSの決済APIを運用
データ	テーブル行数、日次取込量、保持期間	日次1.2TBのイベントを取込、90日保持
応答性	p95・p99レイテンシ、エラー率	p99を820msから240msに改善
運用範囲	サービス数、インスタンス数、オンコール頻度	マイクロサービス7個、2週に1回オンコール

平均応答時間だけを書く職務経歴書は少なくありません。同じSREブックは、百分位を使えば分布の形が見え、99パーセンタイルや99.9パーセンタイルは現実的な最悪値を示すと説明しています。監視の章の例はより具体的です。平均レイテンシが100msのWebサービスでも、リクエストの1%は5秒かかることがあり、あるバックエンドの99パーセンタイルがフロントエンドの中央値になる場合もあります。面接官がp99を尋ねる理由はここにあります。数値を把握している人ほど、最初から百分位で書いたほうが有利です。

数値が分からない場合は作らないでください。社内ダッシュボードで確認できる値だけを使い、確認が難しければ範囲や構成で代替します。「シャーディング4台、レプリカ2台構成」といった記述も規模の裏づけになります。

障害対応は4段階のタイムラインで分ける

障害経験を「サービス障害に対応した」で終えると、判断材料が残りません。インシデント記録の標準的な型を借りると、自然に4つの欄が埋まります。Google SREブックのポストモーテムの章は、非難のないポストモーテムを、個人やチームを名指しせずに障害の原因を明らかにすることと定義しています。職務経歴書にも同じ姿勢が必要です。原因を組織や前任者のせいにする文章は、技術的な判断力を示しません。

4つの欄は次のように書きます。

1. 検知:何によって気づいたか。アラートのルール、指標の異常、顧客からの問い合わせのどれだったかを書きます。
2. 緩和:ユーザーへの影響を先に減らした対応。ロールバック、トラフィック遮断、キャッシュ回避などです。
3. 復旧:根本原因と修正。コネクションプールの枯渇、インデックスの欠如、リトライの暴走といった具体的な原因が入ります。
4. 再発防止:その後変わったこと。アラートのしきい値、負荷テスト、サーキットブレーカー、ランブックの整備などです。

4つの欄のうち最も空欄になりやすいのが再発防止です。ここに一文を書けるかどうかで、「障害を経験した人」と「障害のあとにシステムを変えた人」の違いが伝わります。

求人票が実際にスキャンする信頼性用語

バックエンド求人票の運用に関する要件は、業界共通の語彙で書かれていることが多くあります。DORAはソフトウェアデリバリーのパフォーマンス指標として、デプロイ頻度、変更のリードタイム、変更失敗率、サービス障害からの復旧時間を定義しています。これらの用語は、求人票の「障害対応」「デプロイの安定化」「SLO運用」という一文の裏に、そのまま存在しています。

そのため、職務経歴書の表現を求人票の語彙に合わせる作業が必要です。同じ経験でも、求人票が「SLI/SLOに基づく運用」を求めていればレイテンシの目標値と計測期間を併記し、「デプロイの安定性」を求めていればロールバック手順と変更失敗後の復旧時間を先頭に置きます。その会社が使っていない用語を無理に持ち込むと、かえって選考の初期段階で不利になります。

同じ経験を求人票ごとに書き分ける3つの分類

私たちが勧める手順は、求人票を1件貼り付けて要件とATSキーワードを抽出したうえで、現在の職務経歴書の表現と実際の経験の裏づけを3つに分けることです。

• キーワードと経験の裏づけが両方ある項目:文章を求人票の語彙に合わせて上位に置きます。たとえば「メッセージ処理量の改善」を、求人票の表現である「イベントパイプラインの遅延削減、p99基準」に書き換えます。
• 経験の裏づけはあるがキーワードがない項目:表現だけを置き換えます。「夜間に障害対応の当番をしていた」という経験は、オンコールローテーションと一次対応(トリアージ)の経験として書けば、同じ事実が検索されやすい形になります。
• キーワードも裏づけもない項目:空欄のままにします。経験していないKafka運用や存在しない復旧時間を書き足す選択は、書類選考を通過させても技術面接で崩れます。

refresh.cvでは、この突き合わせを求人票を入力してから職務経歴書と比較する流れで進めており、職務経歴書そのものの品質スコア分析(具体性・成果・表現・文法)と求人票ごとのキーワード適合度は別々の結果として表示します。品質スコアが高くても特定の求人票には合わないことがあり、その逆もあります。どちらの結果も、合格の可能性や実際の企業のATSの判定結果ではありません。

無料プランではAIによる作成・修正と職務経歴書のスコア分析を月5回まで利用でき、求人票ごとのカスタマイズとATSキーワード分析・改善提案はProプラン(月額14.99ドル)に含まれます。応募予定の求人が数件であれば、まず無料の範囲で使い方を確認するのが合理的です。

ツールを選ぶ基準を先に整理したい方は、経験の裏づけまで照合するAI職務経歴書ツールの比較記事もあわせてご覧ください。

FAQ

社内の指標を外部に書いても問題ありませんか

絶対値が機密性の高いものであれば、公開できる水準に置き換えます。「日次1.2TB」を「テラバイト級の日次取込」に、「4,200RPS」を「数千RPS規模」に変えるなど、桁数だけを保てば規模の単位は伝わります。改善幅を割合で書く方法もあります。

障害に直接対応せず、関わっただけの場合はどう書けばいいですか

役割をそのまま書きます。ログの収集とタイムラインの整理、再現テスト、事後報告の作成のように、担当した範囲を具体的に書くほうが安全です。原因を明らかにする記録作業そのものが運用経験として読まれます。

新卒で運用障害の経験がありません

負荷テストの結果と障害シナリオの設計で代替します。個人プロジェクトでも、k6やJMeterで測定したRPSとp95レイテンシ、タイムアウトとリトライ方針を決めた根拠を書けば、指標の言葉で語れるという裏づけになります。

職務経歴書と履歴書に同じ内容を繰り返し書いてもいいですか

履歴書には指標入りの一行要約を、職務経歴書には検知から再発防止までの4段階を展開して書きます。同じ出来事を扱いながら、分量と深さを分ける書き方です。

求人票を1件選んで貼り付け、上の3つの分類でご自身の職務経歴書を一度突き合わせてみてください。refresh.cvからすぐに始められます。