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

C#エンジニアのスキルシートは、最初に「どの領域のC#か」と「.NET Frameworkか新しい.NETか」を示し、プロジェクトごとに担当した工程と作った設計書を書くのが基本です。C#は業務Webシステム、Windowsのデスクトップアプリ、製造・制御系、ゲームと領域が分かれており、同じ言語でも求められる経験が違います。読み手が領域と環境を見誤らないように書くことが、最初の関門です。

全体の構成はスキルシートの基本で解説しています。この記事では、C#のエンジニアが書くときに迷いやすい部分に絞って説明します。

要約で領域を先に書く

C#の案件の担当者は、まず自分の案件と同じ領域の経験があるかを確かめます。領域が違うと、使うフレームワークも進め方も変わるためです。

要約の1行目には、軸の領域と経験の長さを書きます。複数の領域を経験している方は、応募する案件の領域を上に持ってきます。領域ごとの案件の違いはC#エンジニアの独立の記事で扱っています。

.NETの表記をそろえる

C#のシートで特に注意したいのが、.NETの表記です。「.NET」とだけ書くと、古い.NET Frameworkなのか、新しい.NET（以前の.NET Coreの流れをくむもの）なのかが分かりません。両者は動く環境もサポートの考え方も違い、読み手はここを重く見ます。

版の数字は、自分が担当した期間のものを書きます。サポートの期限やそれぞれの違いはC#の案件で求められるスキルの記事にまとめていますが、シートでは版を正確に書くことと、移行に関わった場合は前後を書くことだけで、十分に伝わります。

あわせて、開発環境（Visual Studioの版、Windows Server、Azureなど）とDB（SQL Server、Oracleなど）も書いておきます。業務系の案件では、既存の環境に合わせて入る形が多いため、環境の一致が判断材料になります。デスクトップアプリの経験がある方は、配布の方法（インストーラーの作成、自動更新の仕組みなど）に関わったかも書いておくと、運用まで見ていたことが伝わります。

工程と設計書の種類を書く

C#の業務系の案件は、要件定義から運用までの工程がはっきり分かれた進め方が多く、読み手は「どの工程から入れるか」をよく見ます。工程の名前に加えて、自分で作った設計書の種類を書くと、上流の経験の深さが伝わります。

• 基本設計書（画面設計、帳票設計、外部インターフェースの設計など）
• 詳細設計書（クラス設計、処理の流れ、DBの設計など）
• テスト仕様書（単体・結合・総合のどこまでか）
• 移行計画書、操作マニュアル

「基本設計を担当」と書くより、「画面と帳票の基本設計書を作成し、お客さまのレビューに対応」と書くほうが、任せられる範囲が具体的に分かります。上流の経験を広げたい方は上流工程の案件に入るために必要な経験も参考になります。

現地作業や装置との連携も書いておく

製造・制御系や、お客さまの拠点に設置する業務システムでは、現地での作業が発生することがあります。導入作業、装置との接続試験、利用者への操作説明などを担当した経験は、工程の欄とは別に「現地での導入と接続試験を担当」のように書いておくと、同じような体制の案件で判断材料になります。シリアル通信やPLCなど、外部の機器とやり取りした経験も、通信の方式とあわせて書きます。

規模は体制の全体と自分の位置で書く

業務系のプロジェクトは関わる人数が多いことがあります。規模は「全体○十名、うち自分のチーム数名でサブリーダー」のように、全体の規模と自分の位置を両方書きます。全体の人数だけだと、自分の責任の範囲が伝わりません。

移行と改善の経験の書き方

C#の現場では、.NET Frameworkから新しい.NETへの移行や、古いWinFormsのアプリの改修がよく発生します。こうした経験は、次の3点で書くと伝わります。

1. 何を調べたか：使えなくなる機能やライブラリの洗い出し、影響範囲の調査
2. どう進めたか：段階的な切り替え、並行稼働、テストの追加など
3. 何が変わったか：保守のしやすさ、動作の速さ、運用の手間など

性能の改善も同じ型で書けます。「画面が固まる原因だった同期処理を非同期に直した」「Entity Frameworkが出していた大量の問い合わせをまとめた」のように、原因と変えたことが分かれば、具体的な秒数がなくても十分です。数値を書く場合は、社外に出してよいものかを確かめてください。考え方はスキルシートと守秘義務の記事で解説しています。

プロジェクト欄の記入例

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

期間：○年○月〜○年○月（1年半程度）
案件概要：製造業向け 生産管理システムの刷新（業務Web）
規模・立場：全体○十名、うち開発チーム数名（サブリーダー）
担当工程：基本設計、詳細設計、開発、結合テスト、移行
使用技術：C#、.NET Framework 4.x→.NET 8、ASP.NET MVC→ASP.NET Core、Entity Framework Core、SQL Server、Azure
作成した設計書：画面と帳票の基本設計書、詳細設計書、結合テスト仕様書、移行計画書の一部
担当内容：在庫と工程の画面の設計と実装。旧システムで使っていた機能のうち、新しい環境で使えないものの洗い出しと置き換え
工夫・成果：移行を機能のまとまりごとに分けて進め、旧システムと並行で動かしながら切り替えた

この例では、領域、.NETの版と移行、作った設計書、全体の中での位置が読み取れる形にしてあります。

GitHubがなくても示せるもの

C#の業務系の案件では、業務のコードを公開できないことが多く、GitHubのリポジトリを持っていない方も少なくありません。その場合でも、シートで示せるものはあります。

• 作成した設計書の種類と、レビューへの対応
• 社内で整えた共通部品や、コーディング規約・テストの仕組み
• 後から入る人のために作った手順書やドキュメント

公開できる個人の成果がある場合は、補足として載せてかまいません。ゲームの領域でUnityの作品を公開している方は、業務系の案件に応募するときは、業務系の経験を先に、Unityの経験は別の欄にまとめると、読み手が混同しません。

よくある質問

VB.NETの経験も書いたほうがよいですか？

書いておくと判断材料になります。VB.NETで作られた既存のシステムの保守や、C#への移行を扱う案件もあるためです。スキル一覧ではC#と分けて、期間と使い方の深さを書いてください。

設計書を作った経験がほとんどありません。不利になりますか？

開発とテストが中心の経験でも、案件はあります。その場合は、実装した機能の範囲、単体テストの書き方、レビューでの指摘への対応など、開発の工程の中身を具体的に書きます。詳細設計の一部を手伝った経験があれば、その範囲も書いておきましょう。

製造・制御系の経験は、業務Webの案件でも評価されますか？

C#の言語の力や、外部とのやり取りを設計した経験は、業務Webでも生かせる部分があります。ただし、領域が違うことは読み手にも分かるので、共通して使える経験（DBの設計、非同期の処理、テストなど）を行として書き出しておくと、つながりが伝わりやすくなります。