FDEの証拠の作り方——職務経歴書に残る本稼働の痕跡(シリーズ3/5)

Alex Ishiguro • • • 読了目安:4分
FDEの証拠の作り方——職務経歴書に残る本稼働の痕跡(シリーズ3/5)
目次▼
  1. 1結論を先に
  2. 2まず用語の地図
  3. 3具体例:証拠の最小単位(1本の話)
  4. 4秘密を守りながら書く
  5. 5ポートフォリオの置き場
  6. 6弱い証拠を強く見せようとして失敗する型
  7. 7いま証拠が無い人の作り方(90日プランの骨格)
  8. 8職務経歴書の見出し例
  9. 9いまの一手

第2回でスキルを三層に分けた。第3回は、それを他人が検証できる痕跡に変える話だ。

履歴書(学歴・職歴の表)だけでは足りない。日本の中途採用で効くのは、多くの場合職務経歴書——「何を、誰のために、どこまで通したか」を書く書類——の側だ。

この記事の使い方

  • 決めること: 今ある経験のうち、FDEの証拠として使える話が何本あるか
  • 決めないこと: まだ「どのテンプレの見た目が美しいか」
  • 前提: 秘密情報は出せない。出せる粒度で「通しきった」を示す

結論を先に

良い証拠弱い証拠
特定ユーザー/部署が本稼働で使った「AIを勉強した」
権限・審査・障害対応まで触れたデモ動画だけ
自分が抜けたあとも回った/回す設計をした個人の趣味リポジトリのスター
数字か、検証可能な前後比較がある「チームで貢献した」だけ

FDE採用が見たいのは、かっこよさより通しきった責任の輪郭だ。

まず用語の地図

用語かみ砕いた意味
職務経歴書中途向けの「実績の説明書」。履歴書より中身が問われる
本稼働毎日の業務で使われている状態
機密/NDA顧客名や内部データを外に出せない約束。出せる形に抽象化する
定量/定性数字で言える成果/言葉でしか言えない成果。どちらも使える
貢献の範囲チーム成果のうち、自分が手を動かした部分
成果物残ったもの——設計図、手順書、プルリクエスト、ダッシュボード、研修資料など

具体例:証拠の最小単位(1本の話)

職務経歴書に載せるFDE向けのエピソードは、次の型に収めると面接官が追いやすい。

  1. 誰の、どの業務か(部署名は伏せても「何をする人たちか」は書く)
  2. 何が止まっていたか(PoC止まり、権限、データ、決裁など)
  3. 自分が通した縦スライスは何か
  4. 本稼働の定義は何か(週次でN人が使う、など)
  5. 自分が居なくなったあとの状態(運用移管したか)
  6. 学べた失敗(成功談だけは信用されにくい)

例(架空・抽象化済み):

営業事務10名の見積もり照会が、メールとExcelで止まりがちだった。照会APIと薄い画面を本番相当に通し、情シス審査のあと本稼働。手順書と権限申請のルートを残し、自分が他案件に移ったあとも問い合わせは運用窓口へ流れる設計にした。最初の月は照会の往復が平均2日から半日に短縮(社内計測)。

ここにモデル名の羅列は要らない。必要なら「生成AIで下書き→人間が承認」程度でよい。

秘密を守りながら書く

客先案件は、社名も数字も出せないことが多い。それでも証拠は残せる。

出せない代わりに出す
顧客名業種・規模感(「国内メーカーの情シス」など)
正確な売上相対比較(「週次の手作業が半減」)や幅
内部画面のスクショ構成図の抽象版、責任分界の図
生ログ「どんな種類のログを残したか」の説明

面接では「詳細はNDAで話せないが、構造はこうです」と先に言えると、信頼が上がる。

ポートフォリオの置き場

「GitHubに全部」は必須ではない。FDEは顧客コードを公開できないことが多い。

置き場向くもの注意
職務経歴書本文通しきった話 2–4本1本が長すぎない
非公開の補足PDF図・時系列面接前にだけ共有
公開GitHub個人で再現した縦スライス顧客コードを混ぜない
社内評価・推薦本稼働の証言転職活動で使えるか先に確認

公開の「AIアプリ」は加点になるが、本稼働と運用移管の話がゼロなら主証拠にはならない。

弱い証拠を強く見せようとして失敗する型

  1. 講座の修了証を並べる — 学習意欲は伝わるが、通しきった証拠ではない
  2. ベンチ上位を強調する — 研究職なら効く。FDEの主戦場は客先の泥
  3. 「リードしました」だけ — 何をリードし、何が本稼働したかが無い
  4. チーム成果を全部自分の手柄にする — 範囲が曖昧だと、かえって疑われる
  5. 秘密を破りそうな具体性 — 採用側もリスクを感じる

いま証拠が無い人の作り方(90日プランの骨格)

転職前でも、社内でFDE的な痕跡は作れることがある。

  1. 社内の小さい本稼働を狙う(別部署の手作業を一本化する、など)
  2. 最初から運用移管を完了条件に入れる
  3. 週次で「通った経路」「止まった理由(権限/データ/決裁)」をメモする
  4. 終了時に、上記の6点エピソード型で1枚書く

社外に出せる個人プロジェクトでもよいが、実際のユーザー(友人でも可)が繰り返し使うところまで持っていく。一度のデモで止めない。

職務経歴書の見出し例

  • 「客先に相当する社内ユーザー向けに、○○を本稼働まで導入」
  • 「PoC止まりだった△△を、情シス審査と権限設計ごと通した」
  • 「運用移管後も独力で回る手順と責任分界を残した」

「AI活用に携わった」より、動詞を**通した/移管した/止めた(スコープ)**に寄せる。

いまの一手

本気で狙う人

  1. エピソード型でいま書ける話を2本下書きする(秘密は抽象化)
  2. 第2回で薄かった層に対応する話が無ければ、90日で1本作る計画を立てる
  3. 公開GitHubを整える前に、職務経歴書の動詞を直す

まだ様子見の人

  1. 直近の案件をエピソード型に当てはめ、「本稼働まで行ったか」だけ判定する
  2. 行っていないなら、組織のどこで止まるかをメモする(自分を責めない)
  3. 証言できる同僚がいるかだけ確認する(将来の推薦用)

次の 第4回(選考の回し方) では、ケース面接とロールプレイで見られる観点を書く。シリーズ一覧は FDEハブ。

※この記事の内容についてご意見・ご指摘がある場合は、お問い合わせよりご連絡ください。確認の上、必要に応じて追記・訂正します。

A

Alex Ishiguro

編集長

MakuakeやCAMPFIREで話題になった商品の「その後」を追うメディアを運営。約束されたものが実際に届いたのか、消えてしまったのかを記録する。

この記事に追加情報や訂正がある場合は、お問い合わせよりご連絡ください。