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

C/C++エンジニアのスキルシートは、CとC++の経験を分けて書き、どの用途で、どの層を扱ったか、使っていた規格の版とコンパイラー、性能改善や不具合の調査で何を担ったかを示すのが基本です。C/C++の案件は用途が広く、読み手は「この人の経験は、うちの案件のどこに当てはまるか」を探しながら読みます。

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

「C/C++ 15年」とまとめず、言語と用途を分ける

C/C++のシートでよく見るのが、「C/C++ 15年」のように言語をまとめる書き方です。これでは、Cが中心なのかC++が中心なのか、どの用途の経験なのかが分かりません。

CとC++は、案件の側では別の経験として見られることが多くあります。スキル一覧の冒頭で、言語ごとの期間と主な用途を一行ずつ書いておくと、読み手が合う案件を判断しやすくなります。

規格の版とコンパイラーを書く

C++の国際規格は版を重ねており、Standard C++ Foundation（isocpp.org）では、2026年10月時点の最新の規格はISO/IEC 14882:2024（C++23）とされています。案件によって使う版は違うため、プロジェクトごとに「C++17」「C++11」のように使っていた版と、コンパイラー（GCC、Clang、Visual C++など）とそのおおよその版を書いておくと、どの時期の書き方に慣れているかが伝わります。版の更新を担当した場合は、その旨も一言添えます。

スキル一覧は「実務で使った深さ」で書き分ける

スキル一覧に道具やライブラリを並べるときは、名前だけでなく、実務での使い方の深さを添えます。たとえば「デバッガー：コアダンプの解析まで自分で行える」「CMake：既存の構成の修正ができる」「プロファイラー：測定結果から原因を絞り込める」のように、何ができるかを一言で書くと、読み手が参画後の姿を思い描きやすくなります。

どの層を扱ったかを書く

C/C++の経験は、同じ用途でも、扱った層によって意味が変わります。プロジェクト欄には、担当した部分がどの層にあたるかを書き添えます。

• アプリケーションの層：業務の処理、画面、ほかのシステムとの連携
• ミドルウェア・ライブラリの層：通信、データの保存、ほかのプログラムから呼ばれる部品
• OSに近い層：プロセスやスレッド、メモリ、入出力を直接扱う部分

あわせて、動いていたOS（Linux、Windows、UNIXなど）と、ほかの言語との境目（C++からCを呼ぶ、PythonやC#から呼ばれるなど）を書いておくと、参画先の環境との近さが伝わります。

性能と不具合の調査は「何をしたか」を順に書く

C/C++の案件では、性能改善と不具合の調査が成果として期待されることが多くあります。「性能改善を担当」「障害対応」だけではほとんど伝わらないため、次の順で書きます。

1. 何が問題だったか：処理の遅れ、遅れのばらつき、メモリの増加、異常終了など
2. どう確かめたか：プロファイラー、デバッガー、コアダンプの解析、メモリやスレッドの検査ツール、負荷試験など
3. 何を変えたか：データ構造、メモリの確保の仕方、スレッドの分け方、処理の順序など
4. どう変わったか：前後の比較

社外に出せない数値は、「処理時間がおおむね3分の1に」「再現しなかった異常終了の原因を特定し、以後の報告がなくなった」のように、相対的な表現で十分です。書いてよい範囲はスキルシートと守秘義務の記事をご覧ください。

古いコードを扱った経験は、遠慮せずに書く

長く使われてきたコードの保守や、古い書き方のコードを段階的に整えた経験は、C/C++の案件ではよく求められます。「保守」と一言で済ませず、次のような内容を書き出すと、慎重さと判断の力が伝わります。

• 設計書の少ないコードを、どう読み解いて影響範囲を見極めたか
• テストのない部分を、どう確かめてから直したか
• 警告や静的解析の指摘を、どの順で減らしたか
• コンパイラーや規格の版を上げるときに、どんな問題に対応したか

プロジェクト欄の記入例（架空）

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

期間：○年○月〜○年○月（2年程度）
案件概要：取引データを受け渡すサーバー処理の改修と性能改善（架空の例）
規模・立場：開発メンバー十数名のうち、性能改善を担当する3名のまとめ役
言語・版：C++17（一部に古い版の書き方のコードが残る）、周辺のツールはPython
環境：Linux、GCC、CMake、ユニットテストの仕組み、静的解析の道具
扱った層：ミドルウェアの層（受信したデータを振り分ける部分）
担当工程：調査、設計、実装、試験、リリース後の監視
工夫・成果：混み合う時間帯に遅れが大きくなる問題について、プロファイラーで原因をメモリの確保の多さに絞り込み、確保の仕方を見直した。遅れのばらつきがおおむね半分になった。変更前後の比較の手順を文書にまとめ、チームの試験の流れに組み込んだ

この例では、言語と版、扱った層、問題から成果までの流れ、チームでの立場が一度に読み取れる形にしてあります。Cが中心の保守の案件であれば、「案件概要」に保守してきた期間と範囲を、「工夫・成果」に影響範囲の見極め方やテストの足し方を書くと、同じ型で経験を示せます。

よくある書き方の失敗

C/C++のシートで、読み手が判断に迷いやすい書き方をまとめます。

特に、同じ製品を長く担当してきた方は、10年分を一つのプロジェクトとして書いてしまいがちです。実装から調査、方針の決定へと役割が変わってきた場合は、時期ごとに分けて書くと、成長の流れが伝わります。

個人の成果物やOSSの扱い

公開しているライブラリや、OSSへの修正の提案は、C/C++のコードを書けることを示す補足になります。載せる場合は、何を解決するものか、取り込まれた修正の内容、テストの有無を添えると判断材料になります。ただし、業務委託の案件では実務の経験が中心に見られるため、後ろの方に置くのが自然です。扱い方はポートフォリオやGitHubの記事で解説しています。

よくある質問

使っていた規格の版が分かりません。どう書けばよいですか？

ビルドの設定にある版の指定（-stdの指定など）やコンパイラーの版から、おおよその版が分かることがあります。はっきりしない場合は無理に書かず、「コンパイラーの版」と「使っていた主な書き方（スマートポインターの有無など）」を書くほうが、誤解を生みにくくなります。

守秘義務が厳しい金融系の案件は、どこまで書けますか？

社名や取引の中身は書かず、「取引系のサーバー処理」「データの受け渡し」のように業務を一般化して書くのが基本です。数値も相対的な表現にとどめます。契約で書けない範囲が決まっている場合は、その決まりを優先してください。

面談で聞かれやすい点に、シートでどう備えればよいですか？

シートに書いた性能改善や不具合の調査は、面談で掘り下げられることが多い部分です。各行について、なぜその方法を選んだかを一言で説明できるか確かめておきましょう。面談全般の準備は面談でよく聞かれる質問の記事をご覧ください。