自分が携わった案件を説明できないエンジニアが多すぎる——キャリアの記憶は、消える前に記録しろ

「前の案件で何をやっていましたか？」この質問にスラスラ答えられるエンジニアは、実は少ない。技術も、環境も、自分が何を担当したかも、驚くほど忘れている。キャリアの記録を残す仕組みの必要性について書く。

---

面談で自分の経歴を喋れないエンジニア

SESエージェントとして3年間、約500人のエンジニアの面談に立ち会ってきた。その中で何度も目にしてきた光景がある。

クライアントから「直近のプロジェクトについて詳しく教えてください」と聞かれて、黙り込むエンジニア。

「えーと、Javaで……APIを……作ってました」

それだけ？ チーム構成は？ どんな課題があった？ 自分はどのフェーズを担当した？ どんなDBを使った？ フレームワークは？ インフラは？

聞けば聞くほど、出てこない。

「DBは何を使いましたか？」「えーと……たぶんPostgreSQLだったと思います」。たぶん？ 自分が半年間使っていた技術をたぶんで答えるのか。「Javaのバージョンは？」「11……いや、17だったかも……」。こうなると、クライアント側の表情が変わるのがわかる。

技術力がないわけじゃない。実際にやってきたはずだ。でも、自分がやったことを説明できない。使った技術の名前すら曖昧になっている。

これは経験1〜2年の若手に限った話じゃない。経験5年、10年、15年のベテランでも起きる。むしろ年数が長いほど、過去の案件が多すぎて記憶が混濁していることもある。「あれ、Dockerを使ったのはこの案件だっけ、前の案件だっけ」と。

---

なぜエンジニアは自分の経歴を忘れるのか

忘れること自体は、人間として自然なことだ。責めたいわけじゃない。

エンジニアの仕事は、目の前のタスクに集中するのが基本だ。今動いているコードに全力で向き合い、課題を解決し、リリースする。それが終わったら次のプロジェクトに移る。振り返っている暇がない。

特にSESやフリーランスの場合、案件が変わるたびに環境もチームも技術スタックもリセットされる。新しい現場に適応するだけで精一杯で、前の案件の記憶は急速に薄れていく。

3ヶ月前の案件ならまだ覚えている。半年前になると怪しくなる。1年前はかなり曖昧。3年前はもうほとんど思い出せない。

具体的に何が消えていくか。まずミドルウェアのバージョンが消える。次にチームの人数が曖昧になる。そのうち自分が担当したフェーズの境界が混ざり始める。最終的には「Javaの案件でした」くらいしか残らない。5年経てば「何かWebシステムを作っていた気がする」になる。

これは記憶力の問題じゃない。記録していないから忘れる。それだけだ。

人間の記憶は、思っている以上に頼りない。プロジェクトの詳細、使ったミドルウェアのバージョン、チームの人数、自分が工夫したポイント。こういった情報は、意識的に書き留めておかないと消えていく。

---

「忘れている人」を信用できるか？

ここでちょっと厳しい話をする。

面談の場で自分の経歴を説明できない人を見て、クライアントはどう思うか。

「この人、本当にやってきたのかな？」

こう思われる。残酷だが、事実だ。

エージェント側の本音も書いておく。自分の経歴をちゃんと説明できないエンジニアは、営業としてクライアントに推しにくい。推薦文を書こうにも、本人から具体的な情報が出てこないから書きようがない。結果、スキルシートの薄い情報だけで提案することになり、書類の段階で落ちる。

技術力がある人だとわかっていても、「この人を面談に送って大丈夫か？」と不安になる。面談でクライアントの質問に答えられなかったら、エンジニア本人の評価が下がるだけじゃない。紹介したエージェント側の信頼にも傷がつく。だから、喋れない人は案件の紹介自体が減っていく。本人は気づいていないことが多いが、裏側ではこういうことが起きている。

経験年数が10年あっても、直近の案件で何をしたか具体的に説明できなければ、「本当に10年分の経験があるのか？」と疑われる。逆に経験3年でも、自分の経歴を具体的かつ論理的に説明できる人は、「この人はちゃんとしている」と信頼される。

以前「エンジニアの自己PRを「STAR法」で構造化する」で書いた通り、「何をしたか」を構造的に語れるかどうかが評価を分ける。でもSTAR法で整理しようにも、そもそも事実を覚えていなければ、整理するための材料がない。

面談で喋れないのは、コミュニケーション力の問題じゃない。記録の問題だ。

喋るための材料がないから喋れない。覚えていないから語れない。技術力があっても、それを証明する言葉を持っていなければ、面談の場では「技術力がない人」と同じに見える。

---

「あとで書こう」は、一生書かない

ここで問いかけたい。

今、あなたが携わっている案件。3ヶ月後に「このプロジェクトで何をやりましたか？」と聞かれて、詳細に答えられる自信はあるか？

チームの人数。使っている技術スタック。DBの種類。自分が担当しているフェーズ。いちばん苦労した課題。自分が工夫したポイント。

今なら全部答えられるだろう。でも3ヶ月後は？ 半年後は？

「案件が終わったら整理しよう」と思っている人は多い。でもこれは「あとでやる」と同じだ。案件が終わったら次の案件が始まる。前の案件の記憶は上書きされていく。

「あとで書こう」は、一生書かない。

だから今、書く。プロジェクトの渦中にいる今、鮮度が高いうちに記録する。完璧じゃなくていい。箇条書きでいい。ざっくりしたメモでいい。あとから整理すればいいが、材料がないと整理すらできない。

最低限メモしておくべきことはこのくらいだ。

• プロジェクトの概要（何のシステムか、業界は、規模は）
• チーム構成（何人チームで、自分の立ち位置は）
• 使った技術（言語、フレームワーク、DB、インフラ、バージョンまで）
• 自分が担当したフェーズと具体的な作業内容
• いちばん苦労した課題と、どう解決したか
• 成果（数字があればなお良い）

これを案件が終わるたびに5分でメモするだけでいい。この5分が、3年後の面談で30分の差になる。

---

キャリアの記録は「仕組み」で残す

記憶力に頼らない。意志の力に頼らない。仕組みで残す。

スキルシートは、本来その仕組みになるべきものだ。でも多くのエンジニアが、スキルシートを「転職するときに慌てて作るもの」だと思っている。だから転職のタイミングで過去を必死に思い出す羽目になる。そして思い出せない。

スキルシートは「作り直すもの」じゃない。**「育てるもの」**だ。

案件が一区切りつくたびに、数行でいいから追記する。使った技術、チーム構成、自分の担当、工夫したこと、成果。これを習慣にするだけで、いつでも「自分が何をしてきたか」を語れる状態が維持できる。

以前「GitHubプロフィールだけでは伝わらないこと」でも書いたが、スキルシートは「お店の看板」だ。看板は常に最新の状態であるべきだし、年に一度だけ書き換えるものじゃない。

「でも、スキルシートの更新ってめんどくさい」。そう思う気持ちもわかる。Excelでフォーマットを揃えて、レイアウトを整えて……となると、億劫になるのは当然だ。

Skillsheet-Port｜スキルシートポート を作ったのは、まさにこの課題を解決するためだ。フォーム入力で体裁は自動で統一される。差分だけ更新すればワンクリックで再出力できる。更新にかかる時間は1〜2分だ。AI構成補助を使えば、自己PRの叩き台も生成できる。

スキルシートの更新を「面倒な作業」から「数分で終わる記録」に変える。それだけで、3年後のあなたは「自分の経歴を語れるエンジニア」になっている。

---

まとめ——記憶は消える。記録は残る。

エンジニアは技術を磨くことには熱心だ。でも自分のキャリアを記録することには、驚くほど無頓着な人が多い。

3年前の案件で使った技術を忘れている。面談で自分の経歴を喋れない。スキルシートを開いたら3年前のまま更新されていない。

これは能力の問題じゃない。仕組みの問題だ。

記憶は消える。でも記録は残る。

**プロジェクトが終わったら、5分でいいからスキルシートに追記する。**この習慣ひとつで、面談での信頼度、案件獲得のスピード、キャリアの見通しが変わる。

「あとで書こう」はもうやめよう。今日から、記録を始めてほしい。