Goエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方
公開 2026-10-29 監修：株式会社エージェントベスト
Goエンジニアのスキルシートは、Goでの実務期間をほかの言語と分けて書き、どのサービスのどの部分をGoで書いたか、運用で何が起きてどう対応したかを示すのが基本です。Goの案件は、ほかの言語でバックエンドを経験してからGoに移った方が多く、読み手は「Goで何をどこまでやったか」を見極めようとします。経験の総量より、Goで担った部分の輪郭がはっきりしているシートが読みやすくなります。
全体の構成はスキルシートの基本で解説しています。この記事では、Goのエンジニアが書くときに押さえたい点に絞って説明します。
Goの経験年数とバックエンド全体の年数を分ける
Goのシートでよく見るのが、「バックエンド開発10年（Go、Java、PHP）」のように、言語をまとめて書く形です。これだと、Goの実務が10年なのか1年なのかが分かりません。読み手が知りたいのは、両方の数字です。
| 書き方 | 読み手の受け取り方 |
|---|---|
| バックエンド開発10年（Go、Java） | Goの経験の長さが分からない |
| バックエンド開発10年。うちGoは直近2年（APIとバッチの開発・運用） | 設計の経験は長く、Goは比較的新しいと分かる |
スキル一覧の言語の欄には、Goの実務期間に加えて、担当した期間の主な版も書いておきます。Goはおおむね半年ごとに新しい版が出るため、版の数字から「どの時期に、どれくらい追従してきたか」が読み取れます。ジェネリクスなど、比較的新しい言語機能を実務で使ったかどうかも、版と合わせて一言添えると判断材料になります。
Goの期間が短くても、ほかの言語での設計や運用の経験は評価の対象になります。分けて書くことで、「Goは2年だが、APIの設計と運用は長い」という強みがそのまま伝わります。Goへの移り方や準備はGoエンジニアの独立の記事で扱っています。
「Goで書いた部分」と「周辺の基盤」を書き分ける
Goはマイクロサービスやクラウドの基盤と一緒に使われることが多く、プロジェクト欄の技術が長い列になりがちです。Go、gRPC、Kubernetes、Terraform、各種のクラウドサービスが並ぶと、読み手は「この人はアプリケーションを書いたのか、基盤を作ったのか」を判断できません。
プロジェクト欄の技術を、次の2つに分けて書くと読みやすくなります。
- 自分がGoで書いたもの：API、バッチ、ワーカー、CLIツール、内部のライブラリなど
- 関わった周辺の基盤：コンテナ、Kubernetesの設定、CI/CD、監視の仕組みなど。どこまで自分で触ったかを括弧で添える
マイクロサービスの構成では、全体のサービス数と、自分が担当したサービスを書くのも効果的です。「十数個のサービスのうち、決済と通知の2つを担当」と書けば、全体の規模と自分の責任の範囲が一度に伝わります。
サービス間の通信も、方式と自分の関わり方を書き分けます。gRPCであれば「Protocol Buffersの定義を設計した」のか「決まった定義に沿って実装した」のかで、経験の重さが違います。定義を変えるときに、古い呼び出し元を残したまま段階的に移した経験があれば、それも1行にしておくと伝わります。
フレームワーク欄が空になるとき
Goは標準ライブラリを中心に書く現場が多く、フレームワークの欄に書くものがないことがあります。その場合は空欄にせず、「標準ライブラリのnet/httpを中心に構成。ルーターにchi」のように、何を選び、どう組み立てたかを書きます。使ったライブラリの名前を増やすより、構成を一言で示すほうが判断材料になります。
性能改善はどう測ったかと一緒に書く
Goの案件では、並行処理や応答の速さが期待されて採用されることが多く、性能改善の経験は評価されやすい部分です。ただし、「高速化を担当」だけではほとんど伝わりません。次の順で書きます。
- 何が問題だったか：応答の遅れ、メモリの増加、goroutineが残り続ける、など
- どう特定したか：pprofなどのプロファイラー、トレース、メトリクスの確認
- 何を変えたか：同時実行数の上限、コネクションの使い回し、割り当ての削減、処理の分割など
- どう変わったか：前後の比較
前後の比較は、応答時間の上位の値（遅いほうのリクエストの時間）やメモリの使用量など、測った指標の種類を書くと具体的になります。具体的な数値が社外に出せない場合は「遅いリクエストの応答時間がおおむね半分に」「メモリの増え続ける現象が止まった」のように、相対的な表現で十分です。書いてよい範囲はスキルシートと守秘義務の記事をご覧ください。
なお、どんな知識が求められるかはGoの案件で求められるスキルの記事にまとめています。シートでは、それを「どの場面で使ったか」として書くのが役割です。
運用の経験を独立した欄にする
Goの案件は、作ったサービスをそのまま運用する体制のものが多く、運用の経験はシートの中でも重く見られます。プロジェクト欄の中で「運用」と一言書くより、次のような内容を行として書き出すと伝わります。
- 監視やアラートの設計に関わったか
- 障害が起きたときの対応（一次対応、原因の調査、再発防止）を担ったか
- 当番制の障害対応の体制に入っていたか
- ログ・メトリクス・トレースのどれを使って調べていたか
Goのバージョンの更新を担当した場合も、この欄に書きます。「Goの版の更新と、依存するモジュールの更新を定期的に担当」と書くと、継続して運用を回していたことが伝わります。運用の比重が大きい方は、SREのスキルシートの記事も参考になります。
プロジェクト欄の記入例
次は書き方の型を示す例です。業種や規模はぼかしてあり、実在の案件ではありません。ご自身の経験に置き換えてください。
期間：○年○月〜○年○月（2年程度）
案件概要：Webサービス事業者向け 決済まわりのマイクロサービスの開発・運用
規模・立場：十数個のサービスのうち、決済と通知の2サービスを担当（バックエンドのメンバー）
担当工程：設計、開発、テスト、運用（障害対応の当番を含む）
Goで書いたもの：決済APIとgRPCの内部API、通知を送るワーカー
周辺の基盤：Kubernetes（マニフェストの修正まで）、GitHub Actions、監視ツールでのダッシュボード作成
工夫・成果：外部の決済サービスを並列に呼ぶ処理に同時実行数の上限とタイムアウトを設け、遅いリクエストを減らした。pprofでgoroutineが残る原因を見つけて直した
この例では、全体の中での担当範囲、Goで書いた部分と基盤の書き分け、性能と運用の行が読み取れる形にしてあります。
OSSや個人のツールの扱い
Goは、CLIツールや小さなライブラリを作りやすい言語で、個人の成果を公開している方も多くいます。シートに載せる場合は、次の点を添えると判断材料になります。
- 何を解決するツールか、誰が使っているか（自分だけか、チームか、公開して使われているか）
- テストやCIが整っているか
- 既存のOSSへの修正の提案であれば、どんな修正で、取り込まれたか
ただし、業務委託の案件では実務の経験が中心に見られます。公開の成果はあくまで補足として、シートの後ろの方に置くのが自然です。
よくある質問
Goの実務が1年未満です。ほかの言語の経験と混ぜて書いたほうがよいですか？
混ぜずに分けて書くほうが、結果として伝わりやすくなります。Goの期間が短くても、ほかの言語での設計・運用の経験が長ければ、その強みは別の行で示せます。Goで担当した範囲を具体的に書くことで、短い期間でも中身が伝わります。
社内ツールをGoで作った経験も書いてよいですか？
書いてかまいません。誰が使い、どんな問題を解決したかを書けば、実務の経験として判断材料になります。配布の方法や、ほかの人が保守できるようにした工夫があれば、あわせて書いておきましょう。
性能の数値を一切書けない場合はどうすればよいですか？
数値の代わりに、測った指標の種類と、特定に使った方法、変化の方向を書きます。「遅いリクエストの応答時間を指標に、プロファイラーで原因を特定して改善した」と書けば、数値がなくても手順と深さは伝わります。