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

Pythonエンジニアのスキルシートは、冒頭で「どの分野のPythonエンジニアか」を示し、プロジェクトごとに「試作で終わったもの」と「本番で動き続けたもの」を分けて書くのが基本です。Pythonの案件はWeb開発・データ基盤・機械学習・業務の自動化と分野が広く、同じ「Python 5年」でも中身がまったく違います。読み手が自分の案件の分野に合うかをすぐ判断できる形にすることが、何より大切です。

全体の構成はスキルシートの基本で解説しています。この記事では、Pythonのエンジニアならではの書き方に絞って説明します。

要約の1行目で分野を宣言する

Pythonのシートで最も避けたいのは、Web開発もデータ分析も機械学習も同じ重さで並んでいて、「結局何が得意な人か」が分からない状態です。読み手は複数のシートを短時間で比べるため、分野が読み取れないシートは後回しになりがちです。

要約は、次のような順で書きます。

1. 軸の分野と経験の長さ（例：PythonでのWeb API開発 ○年）
2. 軸の分野での立場と工程（例：設計から運用まで担当）
3. ほかに対応できる分野（例：データ連携のバッチ開発の経験あり）

分野の選び方そのものはPythonエンジニアの独立の記事で扱っています。複数の分野に経験がある方は、応募する分野ごとにシートの要約と並び順を入れ替えると、同じ経歴でも伝わり方が変わります。

ライブラリ欄は分野ごとに区切る

Pythonは使うライブラリが多く、技術欄が名前の羅列になりやすい言語です。分野ごとに区切って並べると、読み手が案件に関係する部分を見つけやすくなります。

ここでのポイントは、言語の欄に「保守できるコードを書くための道具」を添えることです。型ヒント、テスト、依存関係の固定などは、分野を問わず読み手が気にする点です。何が求められるかはPythonの案件で求められるスキルの記事にまとめているので、ここでは「書いてあるかどうか」で差がつくことだけ押さえておいてください。

非同期処理や並列処理を使った経験も、言語の欄で示せる部分です。「asyncioで外部APIを並行して呼び出す処理を実装」「マルチプロセスで重い集計を分割」のように、何のために使ったかを添えると、名前だけを並べた技術欄と差がつきます。

版の書き方も大切です。Pythonの本体だけでなく、DjangoやPyTorchなど中心になったライブラリの主な版を書いておくと、古い環境の保守なのか、新しい環境での開発なのかが伝わります。

「試作」と「本番運用」を分けて書く

Pythonは検証や分析に使われることが多いため、プロジェクトの中身が「ノートブックで試して終わった」のか「本番で毎日動いている」のかが、シートからは見分けにくくなります。読み手、とくに開発の案件の担当者は、ここを強く気にします。

プロジェクト欄の「担当内容」に、次のどちらかが分かる一言を入れます。

• 試作・検証：仮説の検証、精度の比較、PoC（概念実証）として作ったもの
• 本番運用：定期的に実行されている、利用者が使っている、監視や再実行の仕組みがある

試作の経験も価値があります。ただし、試作を本番運用のように書くと、面談で「運用で何が起きたか」を聞かれて答えに詰まります。試作から本番に移した経験があれば、それは独立した行として書きましょう。「ノートブックの処理を、再実行できるパッケージに作り直してジョブとして定期実行した」のような行は、データや機械学習の案件で特に評価されやすい部分です。

データの規模と成果の書き方

データを扱うプロジェクトでは、規模を書かないと難しさが伝わりません。ただし、件数や金額をそのまま書くと守秘義務に触れることがあります。規模は桁や頻度でぼかして書けば十分です。

• 「日次で数百万件規模のログを集計」
• 「数十のテーブルを持つ業務DBから、分析用のデータを毎時連携」
• 「数GB単位のファイルを分割して並列に処理」

機械学習の成果も同じです。モデルの精度の数値や、それによる売上の変化は、社外に出せないことが多い情報です。その場合は、評価の方法と、業務で何が変わったかを書きます。「既存のルールと比べる評価の仕組みを作り、置き換えの判断材料にした」「人手の確認作業の対象を絞り込めるようになった」のような書き方です。書いてよい範囲の判断はスキルシートと守秘義務の記事をご覧ください。

プロジェクト欄の記入例

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

期間：○年○月〜○年○月（1年半程度）
案件概要：物流業向け 配送データの集計基盤と社内向けAPIの開発（本番運用）
規模・立場：データチーム数名（データ連携と社内APIの担当）
担当工程：設計、開発、テスト、運用（障害時の再実行を含む）
使用技術：Python 3.x、FastAPI、pandas、Airflow、PostgreSQL、pytest、Docker、GitHub Actions
担当内容：日次で数百万件規模の配送ログを集計するワークフローの設計と実装。集計結果を返す社内向けAPIの開発
工夫・成果：失敗したタスクだけを再実行できるように処理を分割し、件数のチェックを入れた。検証用のノートブックにあった集計処理を、テスト付きのパッケージに移した

この例では、本番運用であること、データの規模（桁でぼかしたもの）、試作から本番に移した作業が読み取れる形にしてあります。データ基盤や機械学習を軸にする方は、データエンジニアのスキルシートの記事や機械学習エンジニアのスキルシートの記事もあわせてご覧ください。

GitHub・Kaggle・技術記事の扱い

業務のコードやデータは公開できないため、Pythonでも公開の成果は補足として扱われます。分野によって、見られ方が少し違います。

• Web・自動化：小さなアプリやツールに、型ヒント・テスト・READMEがそろっているか
• データ・機械学習：Kaggleなどのコンペの結果は、手法の理解を示す材料になる。ただし、実務での運用の経験とは別のものとして見られる
• 技術記事：ライブラリの更新で起きた問題の解決など、実務に近いテーマだと伝わりやすい

シートに載せるときは、URLだけでなく「何を見てほしいか」を一言添えます。ノートブックだけのリポジトリを載せる場合は、それが検証用であることが分かるようにしておくと、本番のコードと混同されません。

よくある質問

分析の業務が中心で、開発の経験はほとんどありません。どう書けばよいですか？

分析の経験として、扱ったデータの種類、使った手法、結果がどう業務の判断に使われたかを書きます。開発の経験が少ないことを隠す必要はありません。スクリプトの自動化や、ほかの人が再実行できる形に整えた作業があれば、それを独立した行にすると、開発寄りの案件でも判断材料になります。

生成AIを使った開発の経験はどう書けばよいですか？

使ったモデルやサービスの名前だけでなく、自分が作った部分（データの準備、検索の仕組み、評価の方法、業務への組み込みなど）を分けて書きます。試作で終わったのか、利用者が使う形で動いたのかも明記してください。

Pythonの版を覚えていない古いプロジェクトはどうすればよいですか？

正確に分からない場合は「Python 3系」のように、確かな範囲で書きます。推測で細かい版を書くと、面談で食い違いが起きることがあります。直近のプロジェクトは、版を確かめて書いておくと安心です。