ソフトウェアエンジニア向けの職務経歴書作成・レビューガイドラインです。
職務経歴書を、過去の経歴や技術経験を網羅する資料ではなく、次の二つを兼ねる文書として設計します。
- 採用側の意思決定を支援する説明資料
- 入社後に会社へ提供するサービスの仕様書
採用側が判断したいのは、単に「何を経験した人か」ではありません。
- どのような人物か
- どの案件に配置できるか
- 何を依頼できるか
- どこまで任せられるか
- どのような品質と進め方を期待できるか
- 問題が起きたときに何を優先するか
- 何を期待してはいけないか
- 価値を発揮するために、会社側は何を用意する必要があるか
- 採用する理由を社内でどう説明できるか
職務経歴書の目的は、能力の最大値を示すことではありません。
採用後に提供できる価値、必要な条件、責任範囲、判断基準を、相手が理解・検証・説明できる状態にすることです。
職務経歴書を書く前に、採用側にどのような判断をしてもらいたいのかを決めます。
主な判断は次のとおりです。
- どの案件に配置するか
- どの業務から任せるか
- 単独で任せるか、他職種と組ませるか
- どの程度のレビューが必要か
- 顧客との調整を任せられるか
- 障害や不確実性の高い案件を任せられるか
- 将来的にどのような役割を期待できるか
「自分には何ができるか」だけでなく、相手にどのような意思決定をしてほしいのかを起点に情報を選びます。
職務経歴書は、面接前の争点設計書です。
相手に聞いてほしい論点、確認してほしい経験、判断材料として使ってほしい事例を先に設計します。
経歴を書く前に、採用側に覚えてもらいたい人物像を一文で定義します。
例：
顧客の業務、既存環境、保守体制を確認し、作るもの、作らないもの、外部サービスに任せるものを整理できるエンジニア。
この一文は、能力の一覧ではなく、判断と行動の一貫性を示すものです。
人物像には、次の要素を含めます。
- どのような問題を扱うか
- 何を確認するか
- どのような判断をするか
- どのような状態を作るか
この人物像と関係しない情報は、削除するか、優先順位を下げます。
すべての経験を載せるのではなく、人物像を裏付ける経験を選びます。
人物像に加えて、採用後に会社へどのようなサービスを提供するのかを定義します。
ここでいうサービスは、特定の作業や成果物だけではありません。
- どのような会社、チーム、案件を対象とするか
- どの問題を軽減するか
- どのような状態を実現するか
- 何を当然の品質として提供するか
- 案件条件に応じて何を調整するか
- 問題発生時に何を優先するか
- 何を責任範囲に含めないか
次の形式で整理します。
私は、［対象となる会社・チーム・案件］に対して、［抱えている問題］を［判断・実装・調整の方法］によって軽減し、［実現する状態］を提供する。
例：
小規模Web制作会社のランディングページやWordPress案件に対して、顧客要望、既存環境、保守体制を確認し、実装範囲、品質基準、検証方法を整理することで、制作担当者が公開可否を判断し、顧客へ説明できる状態を提供する。
人物像は「どのような人か」を示します。
提供サービスは「その人を採用すると、会社にどのような変化が起きるか」を示します。
会社に対するサービスを考えるときは、誰が価値を受け取るのかを分けます。
上司、案件責任者、経営者など、配置や委任を判断する人です。
提供価値の例：
- 案件への配置を判断しやすくする
- 見積もりやスコープを整理する
- 公開可否を判断できるようにする
- 技術的なリスクを経営判断へ変換する
- 顧客へ説明できる材料を用意する
営業、ディレクター、デザイナー、エンジニア、運用担当などです。
提供価値の例：
- 認識差や手戻りを減らす
- 状態や責任範囲を明確にする
- 引き継ぎ可能な記録を残す
- 問題発生時の判断順序を共有する
応募先の顧客や、Webサイト・システムの利用者です。
提供価値の例：
- 安定して利用できる
- 必要な情報へ到達できる
- 問い合わせや購入を完了できる
- 継続的に更新・運用できる
- 障害時に適切な対応を受けられる
技術的な行動が、どの受益者にどのような価値を生むのかを説明します。
サービスの対象を広げすぎると、職務経歴書のメッセージが「何でもできます」に戻ります。
次の三点を整理します。
例：
- 小規模なWeb制作会社
- WordPress案件を多く扱う制作チーム
- 専任の品質管理担当者がいない組織
- 営業、デザイン、実装の境界が曖昧になりやすいチーム
- AI生成コードの採否基準を整備したい組織
例：
- ランディングページ
- 小規模Webサイト
- 既存WordPressサイトの改修
- フォームや外部APIの連携
- 小規模な業務ツール
- 既存システムの調査、再現、修正
例：
- 品質基準が案件ごとに変わる
- 公開条件や受け入れ条件が曖昧
- 顧客への説明が担当者個人に依存している
- 保守範囲が決まっていない
- 障害の再現方法や検証記録が残らない
- 作るべき機能と外部サービスに任せる機能が整理されていない
対象を定義することで、経験や強みの選択基準ができます。
提供価値を再現するには、会社側や案件側の前提条件が必要です。
例：
- 要求や優先順位を決める担当者がいる
- 既存環境や顧客との合意内容を確認できる
- 公開前の検証時間が確保される
- デザイン、広告、法務などの専門判断を担当する人がいる
- 変更範囲や受け入れ条件について合意できる
- 問題を報告した際に、採否を決める責任者がいる
必要な情報、権限、時間、協力体制を明示します。
成果を約束するだけでなく、その成果を実現するために必要な条件も説明します。
例：
- 広告運用の成果責任
- デザイン戦略の最終決定
- 顧客の商品・事業戦略の決定
- 法務やセキュリティ監査の専門判断
- 権限のない状態での公開判断
- 継続契約のないシステムに対する無期限の保守
- 必要な情報や検証時間がない状態での品質保証
対象外を示す目的は、対応を拒否することではありません。
何を別の担当者、別の工程、別の契約、外部サービスへ接続するかを明確にすることです。
職務経歴書は、採用側が入社後の働き方に対して持つ事前期待を形成します。
期待を次の四種類に分けて設計します。
その役割を担当する以上、当然満たすと考えられる品質です。
例：
- 合意した仕様を確認する
- 主要な動作を公開前に検証する
- 問題や遅延を早期に報告する
- 既存環境への影響を確認する
- 自分の担当範囲を明確にする
- 判断と変更内容を記録する
共通的な期待は、差別化ではなく基礎品質です。
「丁寧に対応する」ではなく、確認項目、検査方法、記録方法として説明します。
会社、顧客、案件、運用体制によって異なる期待です。
例：
- WordPressから更新できるようにする
- デザインの再現性を優先する
- 表示性能を優先する
- 広告計測を組み込む
- 営業担当者が顧客に説明できる資料を残す
- 特定のブラウザや端末を優先する
個別条件を確認せず、自分の品質基準を固定的に押しつけないことを示します。
納期、予算、障害、素材不足など、その時点の事情によって変わる期待です。
例：
- 公開日を優先し、改善を段階化する
- 障害時は利用者影響と復旧を優先する
- 予算内に収めるため、外部サービスを利用する
- 素材不足の場合は、公開範囲を縮小する
- 暫定対応と恒久対応を分ける
状況が変わった場合に、何を守り、何を延期し、何を諦めるのかを説明します。
会社や顧客が、依頼時点では言語化していない期待です。
例：
- 担当者が変わっても運用を継続できる
- 次回の案件で成果物を再利用できる
- 公開後に成果を確認できる
- 障害時に原因を追跡できる
- 制作会社が保守責任を抱えすぎない
- 顧客自身が更新できる範囲を増やす
潜在的な課題を見つけても、勝手に責任範囲を広げてはいけません。
次の責任を分けて扱います。
- 課題を発見する
- 課題を説明する
- 改善案を提示する
- 採否を決定する
- 実装する
- 運用を継続する
提案力とは、発見した問題をすべて自分で抱えることではありません。
「何を作ったか」だけでは、仕事の進め方は伝わりません。
各事例は、次の順序で整理します。
- 前提
- 本来の進め方
- 起きた問題や制約
- 優先したこと
- やったこと
- やらなかったこと
- 着地
- 次回も使える判断基準
例：
既存WordPressサイトへの機能追加を求められましたが、更新頻度、データ寿命、障害時の影響を確認した結果、WordPress内部への独自実装ではなく、外部サービスとの連携を選択しました。決済や注文管理の保守責任を制作会社が抱えないことを優先しました。
成果の大きさだけでなく、制約の中で何を優先し、何を捨てたかを示します。
成功談ではなく、別の案件でも使える判断として書きます。
仕事の品質は、作ったものの品質だけでは決まりません。
- 責任境界が曖昧な部分を整理する
- 顧客の要望を業務課題へ置き換える
- 作る範囲、外部に任せる範囲、今回は扱わない範囲を分ける
- 受け入れ条件、検査方法、保守範囲を明確にする
- 問題発生時に優先順位をつける
- 判断内容を関係者が説明できる形で残す
- 潜在的な問題を発見し、選択肢として提示する
- 保守できない機能を安易に自前実装する
- 他職種の専門判断を勝手に代行する
- 決定権を持たない事項を独断で決める
- 問題を発見しただけで実装・運用責任まで抱える
- 他人の作業手順に必要以上に介入する
- 相手が検証できない高度な話だけで能力を証明する
- 品質、納期、費用のすべてを無条件に約束する
「何でもできます」ではなく、何を引き受け、何を分担し、何を引き受けないかを示します。
品質を抽象的な美徳として掲げてはいけません。
案件の目的、利用者、予算、納期、運用体制によって、優先すべき品質は変わります。
- 問い合わせや購入までの導線
- レスポンシブ表示
- 標準APIと対応ブラウザ
- 表示性能
- フォーム送信
- 計測
- 公開前のスモークテスト
- 既存機能への影響範囲
- 更新方法
- テーマやプラグインとの互換性
- バックアップと復旧
- 小さな変更単位
- 保守担当者が理解できる構成
- 決済
- 在庫
- 注文管理
- 個人情報
- 障害時の責任分担
- 外部サービスの利用可能性
- 状態管理
- 権限
- データ整合性
- 入力検証
- 監査ログ
- 移行
- 自動テスト
- 仕様の所在
- 変更可能な範囲
- 実行権限
- 費用上限
- 受け入れ条件
- 人間によるレビュー責任
- 問題発生時の停止・修復方法
「フレームワークを使う」「ライブラリを使わない」といった固定方針ではなく、案件条件によって選択を変えられることを示します。
通常時の進め方だけでは、実務能力を判断できません。
- 前提条件を確認する
- 対象顧客と目的を確認する
- 作るものと作らないものを分ける
- 責任範囲を決める
- 品質基準と受け入れ条件を定義する
- 小さく実装する
- 検証してから範囲を広げる
- 運用・引き継ぎ方法を残す
- 顧客と利用者への影響を確認する
- 公開可否と納期を判断する
- セキュリティ、個人情報、決済などの重大事項を優先する
- 暫定対応と恒久対応を分ける
- スコープ縮小や段階導入を検討する
- 外部サービスへの切り替えを検討する
- 追加費用や納期変更が必要な場合は、決定者へ選択肢を示す
問題が起きたときに、実装量を増やすだけで解決しない姿勢を示します。
「調整しました」「設計しました」だけでは、担当範囲が分かりません。
何と何の境界を整理したのかを書きます。
例：
- フロントエンドとバックエンドのAPI仕様
- デザインと実装の状態定義
- 営業が顧客に約束した範囲と開発範囲
- 顧客運用と制作会社保守の分担
- WordPress側の責務と外部サービス側の責務
- AI生成コードと人間による検査責任
- 問題の発見者と採否の決定者
- 暫定対応の担当者と恒久対応の担当者
責任境界には、作業の分担だけでなく、判断権限も含まれます。
次の区別を明確にします。
- 調査する人
- 提案する人
- 決定する人
- 実装する人
- 検査する人
- 公開を承認する人
- 運用責任を持つ人
責任境界を示すことで、協働できる人と越権する人を区別できます。
技術名を並べるだけでは、採用側の判断材料になりません。
技術を次の要素へ接続して説明します。
- 顧客影響
- 利用者への価値
- 運用負担
- 保守責任
- 障害範囲
- 変更コスト
- 説明可能性
- 再利用性
Cloudflare Workersを使いました。
共有ホスティング上に保守の重いPHPアプリを追加せず、静的サイトとフォーム処理を分離することで、更新範囲と障害時の影響を限定しました。
ShopifyとWordPressを連携しました。
商品紹介と集客導線はWordPressで管理し、決済、在庫、注文管理はShopifyに任せることで、制作会社が抱える保守責任を限定しました。
PlaywrightでE2Eテストを作成しました。
公開後の問い合わせ不能を防ぐため、主要導線とフォーム送信を自動確認し、変更時に公開可否を判断できる状態を作りました。
技術選択そのものではなく、その選択が誰のどの負担を減らしたのかを書きます。
詳しく書くことが、説明の品質ではありません。
職務経歴書では、情報を三層に分けます。
- 採用判断に必要な人物像
- 会社へ提供するサービス
- 対象となる案件や問題
- 仕事の進め方
- 判断基準
- 責任範囲
- 代表的な成果
- 技術選定の比較
- 詳細なアーキテクチャ
- 失敗と改善の過程
- テストや検証方法
- 代替案を採用しなかった理由
- 前提条件が変わった場合の判断
- 応募先の業務に直結しない高度な技術詳細
- 相手が検証できない自己評価
- 知識量の証明だけを目的とした説明
- 人物像と関係しない経歴の羅列
- 判断や成果に接続しないツール名
- 前提説明のない専門用語
情報量ではなく、相手が判断できるかを基準にします。
次のような表現は避けます。
- 高度な設計を担当した
- 複雑な案件を解決した
- 幅広く対応した
- 品質を大幅に向上させた
- チームをリードした
- 顧客満足度を高めた
- 潜在課題を発見した
代わりに、対象、制約、判断、行動、結果を書きます。
例：
APIのエラー形式が未定義だったため、入力エラー、認証切れ、サーバーエラーの扱いを整理し、画面ごとの分岐条件と受け入れテストを定義しました。
公開期限までにすべての改善を完了できなかったため、フォーム、主要導線、計測を公開条件とし、表示性能の追加改善を公開後の作業へ分離しました。
採用側が質問でき、事実を確認できる形にします。
成果を裏付ける資料がある場合は、次のものへ接続します。
- コード
- 設計資料
- テスト
- バグ報告
- 検証記録
- 運用手順
- 公開記事
- OSSへの提案やパッチ
職務経歴書は、一つの完成品ではありません。
応募先によって、対象となる問題、期待される品質、協働する相手が異なります。
小規模Web制作会社であれば、次の情報を優先します。
- WordPressや既存サイトの保守経験
- 顧客要望を業務課題へ変換した経験
- LPやフォームの品質基準
- 小規模チームでの責任境界
- 外部サービスによる自前実装の削減
- 納期や予算に応じた優先順位
- 障害時の調査、再現、暫定対応
- デザイナー、ディレクター、営業、顧客との接続
- 顧客や社内担当者が説明・運用できる資料
プロダクト企業であれば、次の情報が重要になる場合があります。
- 継続的な改善
- データと状態の設計
- 自動テスト
- 監視
- リリース工程
- 複数チーム間のAPIや責任境界
- 技術負債と事業優先順位の調整
応募先に存在しない役割名や、理解されにくい高度な肩書を前面に出しません。
相手の業務で「何を依頼できる人か」に翻訳します。
冒頭は、次の順序で作ります。
- 何をしてきたか
- どのような人物か
- どのような会社や案件で価値を出せるか
- 会社にどのような状態を提供できるか
三つ程度に絞ります。
例：
- 顧客要望を業務課題、実装範囲、責任範囲に分解できる
- 既存WordPressや小規模サイトを壊さず、検証可能な単位で改善できる
- 納期や障害の制約下で優先順位をつけ、公開条件と次の対応を整理できる
例：
- LP、小規模サイト、既存WordPressの改修
- 顧客要望と開発範囲の整理が必要な案件
- 品質基準や検証方法が属人化しているチーム
人物像と提供サービスを最もよく説明する事例を先に置きます。
時系列よりも、採用判断への重要度を優先します。
代表事例は、技術力の最大値ではなく、提供サービスの再現性を示すものを選びます。
良い代表事例には、次の要素があります。
- 対象となる顧客やチームが分かる
- 解決すべき問題が分かる
- 制約条件が分かる
- 自分の判断範囲が分かる
- 他者との分担が分かる
- やらなかったことが分かる
- 結果を確認できる
- 次の案件でも使える基準がある
複数の事例で同じ主張を繰り返す必要はありません。
一つの強い事例で判断基準を示し、別の事例では異なる制約や協働関係を示します。
- どの案件に配置できるか分かるか
- 何を依頼できるか分かるか
- どこまで任せられるか分かるか
- どの程度のレビューや支援が必要か分かるか
- 将来的な役割を想像できるか
- 読後に「どんな人か」を一文で説明できるか
- 経歴全体が同じ人物像を支えているか
- 情報を詰め込みすぎて人物像がぼやけていないか
- 技術名ではなく、判断の特徴が示されているか
- 採用後に会社へ何を提供する人なのか分かるか
- 作業内容ではなく、会社に生じる変化が書かれているか
- 誰が価値を受け取るのか明確か
- 対象となる会社、チーム、案件、問題が明確か
- 提供価値を再現する前提条件が明確か
- 対象外と協働が必要な領域が明確か
- 共通的に守る品質が示されているか
- 応募先や案件に合わせて調整する項目が示されているか
- 制約下での優先順位が示されているか
- 潜在課題への提案と実装責任を区別できているか
- 相手に過剰な期待を持たせる表現がないか
- 何を当然に期待してはいけないか分かるか
- やったことだけでなく、やらなかったことが書かれているか
- 優先順位が見えるか
- 制約条件が示されているか
- 判断理由が顧客、業務、責任に接続しているか
- 次の案件でも使える判断基準があるか
- 誰と何を分担したか明確か
- 誰が決定権を持っていたか分かるか
- 自分の責任範囲を過大に見せていないか
- 他人の成果を自分の成果として書いていないか
- チームへの関与と越権行為を区別できているか
- 発見、提案、決定、実装、運用を分けているか
- たまたま成功した話になっていないか
- 成功条件と必要な前提が示されているか
- 面接官が深掘りできる具体性があるか
- 成果を確認できる資料、コード、記録があるか
- 別の条件では判断が変わることを説明できるか
- 技術用語を業務価値へ翻訳できているか
- 相手の理解範囲を超える説明になっていないか
- 抽象語を具体的な行動へ置き換えているか
- 面接官が社内で説明しやすい文章になっているか
- 主張、理由、具体例の順になっているか
次に該当する情報は削除または圧縮します。
- 応募先の業務と関係しない技術一覧
- 使用経験が浅いツールの羅列
- 自己評価だけで裏付けがない強み
- 同じ主張を繰り返す複数の事例
- 結果だけで判断過程がない成功談
- 他者や前職への批判
- 技術的に正しいが、採用判断には使えない説明
- 相手の理解や検証が難しい低レイヤーの詳細
- 提供サービスと関係しない資格や学習記録
- 前提条件を示さない成果の約束
- 責任範囲を過大に見せる表現
- 「何でもできます」という印象を作る情報
削る基準は、「事実かどうか」だけではありません。
次のいずれかに使えるかで判断します。
- 人物像を説明する
- 提供サービスを説明する
- 採用後の配置を判断する
- 判断基準を裏付ける
- 責任範囲を明確にする
- 面接で確認すべき争点を作る
提出前に、次の質問へ答えます。
この職務経歴書を読んだ面接官は、同僚から「で、どんな人だった？」と聞かれたとき、何と答えるか。
この人を採用した場合、誰が、どのような場面で、何を頼めるのか。
この人に仕事を頼むと、どのような品質と進め方を期待できるのか。
反対に、何を当然に期待してはいけないのか。
この人が価値を発揮するために、会社側はどのような情報、権限、時間、協力体制を用意する必要があるのか。
予定どおりに進まない場合、この人は何を優先し、何を延期し、誰に判断を求めるのか。
理想的な回答例：
LPや既存WordPress案件で、顧客要望をそのまま実装するのではなく、公開条件、品質基準、検証範囲を整理できる人だった。通常時は小さく実装して確認し、納期や障害の制約がある場合は優先順位をつけられる。広告運用やデザイン戦略まで一人で抱えるのではなく、専門担当者との責任分担も明確にできそうだった。必要な情報と決定者が用意されれば、案件責任者が公開可否を判断し、顧客へ説明できる状態を作ってくれそうだった。
職務経歴書の完成基準は、情報を網羅したことではありません。
採用側が次のことを説明できる状態になったことです。
- どのような人物か
- 何を依頼できるか
- どのような価値を期待できるか
- どの条件で価値を発揮できるか
- どこから先は別の責任か
- 問題発生時にどのような判断をするか
- なぜこの人を採用するのか
職務経歴書は、過去の記録ではありません。
採用後の働き方、提供価値、事前期待、責任境界を設計し、採用側の意思決定を支援する文書です。