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

Node.jsエンジニアのスキルシートは、担った層（サービスの中心となるAPI、BFF、サーバーレスなど）と画面側との境目、Node.jsの版とフレームワーク、運用で起きたことへの対応を書き分けるのが基本です。Node.jsは画面の開発者もサーバーの開発者も使うため、読み手は「この人はサーバーとして何を任されていたのか」を最初に知りたがります。

全体の構成はスキルシートの基本で解説しています。この記事では、Node.jsのエンジニアが書くときに押さえたい点に絞って説明します。

「JavaScript／TypeScript」と「Node.js」を分けて書く

Node.jsのシートでよく見るのが、「JavaScript/TypeScript 6年（React、Node.js）」のように、画面とサーバーの経験を一つにまとめる形です。これだと、サーバー側の経験が6年なのか、画面の開発の合間に少し触ったのかが分かりません。

スキル一覧には、Node.jsでの実務期間と、担当した期間の主な版も書いておきます。版の数字から、どの時期のサービスに関わり、版上げを経験しているかが読み取れます。Node.jsの公式の案内では、本番にはActive LTSかMaintenance LTSの版を使うよう示されています。サポートが終わった版で動くサービスを保守していた場合も、そのまま書いて構いません。そのうえで、版上げに関わったかどうかを添えると評価の材料になります。

担った層と、画面側との境目を書く

Node.jsの経験は、どの層を担ったかで重みが変わります。プロジェクト欄の冒頭に、次のどれに当たるかを書いておくと伝わりやすくなります。

• サービスの中心となるAPI：業務のデータを扱い、データベースの設計まで担った
• BFF：画面のために既存のAPIをまとめた。GraphQLの層を作った
• サーバーレスの処理：クラウドの関数でAPIやイベント処理を作った
• リアルタイムの機能：WebSocketなどで通知や配信を作った

フルスタックの案件では、画面とサーバーの作業の割合をおおよそで書くと、読み手が役割を判断しやすくなります。「画面3割、API7割」のような書き方で十分です。画面側の書き方はReactエンジニアのスキルシートの記事、型の設計の書き方はTypeScriptエンジニアのスキルシートの記事で扱っています。

技術の欄は「自分で決めたもの」と「使ったもの」を分ける

Node.jsのプロジェクトは、フレームワーク、ORM、テストのツール、クラウドのサービスなど技術の名前が長く並びがちです。構成を自分で選んだものと、決まった構成の中で使ったものを分けて書くと、設計の経験がどこにあるかが伝わります。

性能の改善は「何を測ったか」と一緒に書く

「APIの性能を改善」とだけ書くと、何をしたかが伝わりません。Node.jsの性能の改善は、次の順で書くと読み手が判断しやすくなります。

1. 起きていたこと：特定のAPIの応答が遅い、メモリが増え続けて再起動が必要だった
2. 測った方法：ログやトレース、プロファイラで何を見たか
3. 原因：イベントループを止める同期処理、繰り返し発行されるクエリ、解放されないオブジェクトなど
4. 直したこと：処理をワーカーやキューに移した、クエリをまとめた、キャッシュを入れた
5. 結果：応答時間や再起動の回数がどう変わったか（おおよその幅で構わない）

数字を書けない場合も、「再起動が日常的に必要だった状態を、必要のない状態にした」のように、変化の向きと大きさを言葉で書くことはできます。社名や具体的な数字の扱いはスキルシートの守秘義務の記事を参考にしてください。

運用と版上げは独立した欄にする

Node.jsのサービスを運用してきた経験は、プロジェクトの説明に埋もれがちです。次のような内容は、「運用」として独立した行にしておくと伝わります。

• 監視の指標やアラートを決めた、ログの形をそろえた
• 障害の当番に入った、原因を調べて再発を防ぐ対策を入れた
• Node.js本体の版上げを担当した（どの版からどの版へ、何を確かめたか）
• 依存パッケージの更新や脆弱性への対応を定期的に進めた

版上げは、影響の調べ方、テストの範囲、本番への出し方まで書くと、保守を任せられる人であることが伝わります。

プロジェクト欄の記入例

次は書き方の型を示すための架空の記入例です。実在の案件ではなく、業種や規模もぼかしてあります。ご自身の経験に置き換えてください。

期間：○年○月〜○年○月（2年程度）
案件概要：（架空）会員制のWebサービス向け 予約・決済まわりのAPIとBFFの開発・運用
規模・立場：バックエンド数名のチームで、予約APIと画面向けのBFFを担当
担当工程：設計、開発、テスト、運用（障害対応の当番を含む）
担った層：サービスの中心となるAPI（7割）、BFF（3割）
構成：Node.js（LTSの版で運用。期間中に一度版上げ）、TypeScript、NestJS、PostgreSQL、コンテナで稼働
自分で決めたもの：APIのエラーの形とログの項目、BFFでのタイムアウトと部分的な失敗の扱い
工夫・成果：予約一覧のAPIで、ループの中で繰り返し発行されていたクエリをまとめ、応答の遅さを解消した。外部の決済サービスが遅いときにBFF全体が待たされないよう、タイムアウトと代わりの表示を設けた
運用：Node.js本体の版上げを担当し、依存パッケージの更新の順番を決めて段階的に進めた

この例では、担った層と割合、自分で決めた範囲、性能の改善と運用の行が読み取れる形にしてあります。

スキル一覧の欄で気をつけたいこと

スキル一覧の表では、技術ごとに経験の期間と深さを書く形が多く使われます。Node.jsのまわりは技術の数が多いため、次の点に気をつけると読みやすくなります。

• フレームワークは使った期間と役割を添える：「NestJS 2年（構成の設計から）」「Express 3年（既存アプリの保守）」のように書くと、同じ名前でも深さの違いが分かる
• データベースはORMと分ける：ORMの名前だけだと、SQLを自分で書けるかが分からない。SQLのチューニングの経験があれば別の行にする
• クラウドは使ったサービスを絞る：触ったものを全部並べるより、自分で設定し運用したものに絞るほうが信頼されやすい
• テストは種類を書く：単体テストか、APIのテストか、外部サービスを差し替えたテストかで、品質への関わり方が伝わる

個人の開発やOSSの扱い

個人で作ったAPIやnpmパッケージは、コードの書き方を示す材料になります。ただし、案件では実務での経験が重視されるため、プロジェクト欄とは分けて「その他の活動」として添えるのがよい使い方です。公開しているものがあれば、何を作り、どう保守しているかを一行で書きます。

よくある質問

Node.jsの版を覚えていない場合はどう書けばよいですか？

正確な版が分からない場合は、「当時のLTSの版」「期間中に一度版上げ」のように、分かる範囲で書けば十分です。面談で聞かれたときに、版上げで何を確かめたかを話せるようにしておくほうが大切です。

フロントエンドの経験が中心ですが、Node.jsの経験はどこに書けばよいですか？

プロジェクトごとに、画面とサーバーの作業の割合を書き、Node.jsで担った部分を一行で切り出します。BFFを作った、APIの一部を担当したなど、サーバー側の作業がはっきり分かる書き方にすると、両方を見る案件で評価されやすくなります。

社内向けのツールやバッチをNode.jsで作った経験も書いてよいですか？

書いて構いません。社内向けでも、何のデータを扱い、どのくらいの頻度で動き、止まったときにどう対応したかを書けば、運用の経験として伝わります。規模が小さくても、自分で決めた範囲をはっきり書くことが大切です。