TypeScriptエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

TypeScriptエンジニアのスキルシートは、プロジェクトごとに「TypeScriptをどこで使ったか（フロントエンド・バックエンド・両方）」を先に書き、型にかかわる取り組みを「何を防いだか・何が楽になったか」で書くのが基本です。TypeScriptはどの現場でも使われる言語なので、「TypeScript◯年」と書くだけでは、読み手は案件に合うかを判断できません。

この記事では、TypeScriptの経験を読み手に伝わる形に分解する書き方と、記入例を紹介します。主戦場の決め方はTypeScriptエンジニアがフリーランスになるには、案件で見られるスキルの中身はTypeScriptの案件で求められるスキルで扱っています。

「TypeScript 5年」が伝わりにくい理由

TypeScriptの案件の担当者は、スキルシートを読むときに次のように考えています。

• この人は、画面を作る人なのか、APIを作る人なのか
• 型を「使う」側だったのか、型の仕組みを「整える」側だったのか
• 一緒に使っていたフレームワークや実行環境は、こちらの案件と同じか

「TypeScript 5年」という1行は、このどれにも答えていません。同じ5年でも、Reactの画面を作り続けた5年と、Node.jsのAPIと共通基盤を整えた5年では、合う案件がまったく違います。TypeScriptのスキルシートは、年数を場所と役割に分解して書くことから始めます。

スキル一覧は「場所」と「層」で分ける

スキル一覧では、TypeScriptを1行にまとめず、使った場所で分けます。あわせて、型の基盤（設定やビルド）に関わった経験を別の行にすると、読み手は役割の深さを判断しやすくなります。

これは書き方を示すための例です。「型の基盤」の行は、経験がなければ無理に作る必要はありません。経験がある方にとっては、ほかのTypeScriptエンジニアと差がつきやすい行です。

JavaScriptだけの期間は、TypeScriptの年数に含めずに分けて書きます。合算すると、面談で「この時期の型の設計は？」と聞かれたときに答えられなくなります。

型の取り組みは「対象・やったこと・効果」の1行で書く

TypeScriptのスキルシートで一番差がつくのは、型にかかわる取り組みの書き方です。よくあるのは「型安全な設計を心がけた」「TypeScriptで品質を担保」といった書き方ですが、これでは何をしたのか分かりません。

次の3つをそろえて1行にすると、伝わり方が変わります。

書き直しの例を見てみます。

• 書き直す前：TypeScriptで型安全な開発を推進
• 書き直した後：APIの応答をスキーマで検証し、そこから型を生成する形に変えた。フロントとバックエンドで型の定義が食い違う不具合が、レビューの段階で見つかるようになった

効果を数字で示せない場合は、変える前と後の状態を言葉で書けば十分です。

strictやanyについては事実だけを書く

「strict有効」「any禁止」と書くと、型に厳しい現場の経験として目に留まります。ただ、途中からstrictを有効にしたのか、最初から有効だったのか、自分がその判断に関わったのかで意味が変わります。

• 最初から有効だった現場なら「strict有効の環境で開発」
• 自分で有効にしたなら「strictが無効だったプロジェクトで、チェックを段階的に有効にした」
• 例外としてanyを残した箇所があるなら、面談で理由を話せるようにしておく

自分が関わっていない取り組みを、チームの成果としてぼかして書くのは避けましょう。

プロジェクト欄の記入例

ここでは、フルスタックで機能開発と型の整理を担当した場合を想定した記入例を示します。以下は書き方を示すための例で、実在の案件や実績ではありません。業界や規模はぼかしています。

期間：20XX年X月〜20XX年X月（2年）
案件概要：サービス業向け 予約管理のWebサービスの機能開発
使った場所：フロントエンドとバックエンドの両方（比率はおおむね半々）
規模・立場：開発6名（自分はメンバー。型の整理はとりまとめ役）
担当工程：詳細設計、実装、テスト、リリース
使用技術：TypeScript、React、Node.js（NestJS）、PostgreSQL、スキーマ検証ライブラリ、GitHub Actions
担当内容：予約の登録・変更の画面とAPIを担当。APIの型をフロントとバックエンドで共有する仕組みを整え、移行の手順を書いてチームに共有した
工夫・成果：予約の状態を判別できる共用体型で表し、ありえない状態の組み合わせを型で作れないようにした。型チェックとリントをCIで実行し、型エラーのまま取り込まれないようにした

「使った場所」の行を、案件概要のすぐ下に置いているのがポイントです。フロントエンド中心のプロジェクトとバックエンド中心のプロジェクトが混ざる経歴では、この1行があるだけで読み手の判断が早くなります。

基盤やライブラリの仕事を書くとき

TypeScriptでは、画面やAPIの機能ではなく、共通の型、社内ライブラリ、モノレポの設定、ビルドの見直しといった「ほかの開発者が使う土台」を担当することがあります。こうした仕事は、成果が見えにくいためにシートで薄く書かれがちです。

書くときは、誰が、どう楽になったかを主語にすると伝わります。

• 「社内の複数の画面で使う型とユーティリティを整え、使い方の文書を書いた。新しく入ったメンバーが型の書き方で迷う場面が減った」
• 「TypeScriptの版を上げる作業を担当し、出てきた型エラーを分類して影響の範囲を見積もった」

版を上げる作業は、どの版からどの版へ上げたかを書いておくと、同じ作業が控えている案件で目に留まります。

公開リポジトリを載せるとき

TypeScriptの経験を補うために、個人のリポジトリを載せる方もいます。TypeScriptの読み手が見るのは、画面の見た目より、型の書き方と設定です。

• tsconfigでstrictを有効にしているか
• 外から入るデータをunknownで受け、検証してから使っているか
• 型チェックとテストがCIで動いているか

参画先のコードや、参画先の設定ファイルを載せないことは言うまでもありません。仕事で得た知見を個人のリポジトリで再現するときも、参画先の固有の情報が混ざらないように気をつけましょう。書いてよい範囲の考え方はスキルシートに書いてよいこと・いけないことで解説しています。

フレームワーク別のシートとの使い分け

TypeScriptの経験を持つ方の多くは、ReactやVue.js、Node.jsのフレームワークの経験もあわせて持っています。応募する案件の求人票が「TypeScript」を主に挙げているか、フレームワークを主に挙げているかで、シートの見せ方を変えるとよいでしょう。

フレームワークを軸にした書き方は、Reactのスキルシートの書き方やVue.jsのスキルシートの書き方も参考になります。

よくある質問

フロントエンドとバックエンドが混ざった案件はどう書けばよいですか？

1つのプロジェクトとして書き、「使った場所」の行に比率の目安を書くのがおすすめです。担当内容は、画面とAPIで行を分けると、どちらでどれくらい設計に関わったかが伝わります。比率は厳密でなくてよく、「画面が中心でAPIは修正程度」のような書き方でもかまいません。

型の高度な書き方をした経験がない場合、何を書けばよいですか？

高度な書き方をしていなくても、型に沿って機能を作り、型エラーを直してきた経験は実務の経験です。そのうえで、APIのデータに型を付けた、anyを減らした、といった小さな取り組みがあれば、1行添えておきましょう。読み手は、型を意識して開発してきたかを見ています。

TypeScriptの版は書いたほうがよいですか？

主なプロジェクトでは書いておくと親切です。特に、版を上げる作業に関わった場合は、どの版からどの版へ上げたかを書くと、同じ作業を控えた案件で判断材料になります。版を覚えていない古いプロジェクトは、無理に書かなくてかまいません。