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

Rustエンジニアのスキルシートは、Rustでの実務期間をほかの言語と分けて書き、どの分野で何をRustで書いたか、なぜRustを選んだか、unsafeや他言語との境界にどう関わったかを示すのが基本です。Rustの案件は、ほかの言語を経験してからRustに移った方が多く、読み手は「Rustで担った部分」と「それ以前の経験」の両方を見ようとします。

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

Rustの期間と、分野の経験を分けて書く

Rustのシートでよく見るのが、「システム開発12年（C++、Rust）」のように言語をまとめる書き方です。これでは、Rustの実務が何年なのか、どの分野の経験が長いのかが分かりません。

Rustの案件は、分野によって前提の経験が大きく違います。スキル一覧の冒頭に「Webのバックエンド」「基盤のツール」「組込み」「WebAssembly」のどれの経験かを書いておくと、読み手がどの案件に合う人かを判断しやすくなります。

エディションと、使っていたRustの版

Rustには、言語の変更をまとめた「エディション」があります。公式のエディションガイドでは、エディションはクレートごとにCargo.tomlで選び、異なるエディションのクレートどうしも問題なく組み合わせられると説明されています。シートでは、担当したプロジェクトのエディション（2021、2024など）と、おおよそのRustの版を書いておくと、どの時期の書き方に慣れているかが伝わります。版の更新を担当した場合は、その旨も一言添えます。

「なぜRustか」と「何をRustで書いたか」を書く

Rustが使われる案件では、発注側がRustを選んだ理由がはっきりしていることが多くあります。シートのプロジェクト欄にも、その理由を一行で書くと、経験の意味が伝わりやすくなります。

• 選んだ理由：速さと資源の節約、メモリ安全性、単体で配りやすいこと、小さな資源で動くことなど
• Rustで書いたもの：API、データ処理、CLI、ライブラリ、制御部品、WebAssemblyのモジュールなど
• Rust以外で書かれていた部分：周辺のシステムの言語と、自分がどこまで触ったか

他の言語からの置き換えに関わった場合は、どの部分をどの順で移したか、移行中に古い部品と新しい部品をどう並べて動かしたかを書くと、計画を担える人かどうかが伝わります。

unsafeと他言語との境界は「関わり方」を正確に書く

Rustのシートで、読み手が特に注意して見るのがunsafeとFFI（他言語との連携）の行です。ここは経験の深さが評価を大きく左右するため、関わり方を正確に書き分けます。

1. 自分で設計した：unsafeの範囲を決め、安全な部品で包む形を設計した
2. 実装した：決まった方針に沿って、C/C++のライブラリを呼ぶ部分を書いた
3. レビューした：unsafeを含む変更のレビューを担当した
4. 使っただけ：既存の安全な部品を通して使った

どの深さでも経験として書いてかまいません。チームで設計したものを、自分が設計したように読める書き方は、面談で設計の判断を聞かれたときに説明できず、ほかの記載まで疑われる原因になります。

開発の進め方と保守の経験を行として書く

Rustの案件では、コードを書いた経験に加えて、チームの開発をどう回していたかも見られます。プロジェクト欄の「環境」に技術名を並べるだけでなく、次のような内容を一行ずつ書き出すと伝わります。

• Clippyやrustfmt、テストを自動の仕組みで回していたか、その設定に関わったか
• Rustの版や依存するクレートの更新を、誰がどの間隔で行っていたか
• 対応する最低のRustの版（MSRV）を決めて管理していたか
• コードレビューで、unsafeやエラー処理の方針を点検する役割を担ったか

Rustは安定版が短い間隔で出るため、更新を継続して回してきた経験は、長く保守を任せられる人であることを示す材料になります。

性能と安全性の成果は、測り方と一緒に書く

Rustの案件では、性能改善や不具合の削減が成果として期待されることが多くあります。「高速化を担当」だけではほとんど伝わらないため、次の順で書きます。

1. 何が問題だったか：応答の遅れ、メモリの増加、異常終了、メモリ関連の不具合など
2. どう確かめたか：プロファイラー、ベンチマーク、負荷試験、ファジングなど
3. 何を変えたか：データの持ち方、処理の分け方、非同期処理の構成、Rustへの置き換えなど
4. どう変わったか：前後の比較

社外に出せない数値は、「メモリの使用量がおおむね半分に」「異常終了の報告がほぼなくなった」のように、相対的な表現で十分です。書いてよい範囲はスキルシートと守秘義務の記事をご覧ください。求められる知識そのものはRustエンジニアに求められるスキルにまとめています。

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

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

期間：○年○月〜○年○月（1年半程度）
案件概要：データ処理基盤の一部をC++からRustへ置き換える開発と保守（架空の例）
規模・立場：開発メンバー数名のうち、Rustの部分を担当する2名の1人
Rustを選んだ理由：C++で書かれた解析部品で、メモリ関連の不具合が繰り返し起きていたため
担当工程：移行計画の一部、設計、実装、テスト、リリース後の保守
Rustで書いたもの：入力データの解析部品、既存のC++から呼び出すための境界の層
unsafe・FFI：C++との境界の層を実装（unsafeの範囲を境界の層に限る方針はチームで決定）
環境：Rust 2021エディション。Cargoのワークスペース、Clippy、自動テスト
工夫・成果：古い部品と新しい部品の出力を並べて比べる仕組みを作り、段階的に切り替えた。切り替え後、解析部品に起因する異常終了の報告がほぼなくなった

この例では、Rustを選んだ理由、Rustで書いた範囲、unsafeへの関わり方、成果と確かめ方が一度に読み取れる形にしてあります。

OSSや公開したクレートの扱い

Rustでは、ライブラリ（クレート）を公開したり、OSSに修正を提案したりしている方も多くいます。シートに載せる場合は、何を解決するものか、誰が使っているか、テストが整っているか、取り込まれた修正の内容を添えると判断材料になります。ただし、業務委託の案件では実務の経験が中心に見られるため、公開の成果は補足として後ろの方に置くのが自然です。扱い方はポートフォリオやGitHubの記事で解説しています。

よくある質問

Rustの実務が1年未満です。ほかの言語の経験と混ぜて書いたほうがよいですか？

混ぜずに分けて書くほうが、結果として伝わりやすくなります。Rustの期間が短くても、分野の経験が長ければ、その強みは別の行で示せます。Rustで担当した範囲を具体的に書くことで、短い期間でも中身が伝わります。

社内でRustを試験的に導入した経験は書けますか？

書いてかまいません。何のためにRustを選び、どこまで進め、どんな結果になったかを書けば、導入を判断した経験として読み手に伝わります。導入を見送った場合も、その理由を書いておくと、技術を選ぶ力を示す材料になります。

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

シートに書いた成果やunsafeへの関わり方は、面談で掘り下げられることが多い部分です。各行について、なぜそうしたかを一言で説明できるか確かめておきましょう。面談全般の準備は面談でよく聞かれる質問の記事をご覧ください。