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

DevOpsエンジニアのスキルシートは、ツールの名前を並べるより、パイプラインのどの工程を自分で作ったか、IaCで新しく作ったのか既存の環境を取り込んだのか、何チームに使われたか、前と後で何が変わったかを書くのが基本です。発注側は、同じ「CI/CD構築」の経験でも、範囲と深さで任せられる仕事を判断します。

この記事では、DevOpsの経験を伝わる形に書き分けるコツと、プロジェクト欄の記入例を紹介します。スキルシート全体の基本の構成はスキルシートの書き方の基本をご覧ください。

ツール名の羅列では伝わらないこと

DevOpsのスキルシートでよく見られるのが、「GitHub Actions、Jenkins、Terraform、Docker、AWS」のように、使ったツールを並べただけの書き方です。これでは、次のような違いが読み手に伝わりません。

• 既存のパイプラインに手を入れたのか、流れを一から設計したのか
• 自分のチームのためだけに作ったのか、複数のチームが使う共通の仕組みを作ったのか
• 作ったあと、ほかの人が保守できる形で引き継いだのか

面談でこれらを一つずつ確かめられると、限られた時間で強みを伝えきれません。範囲・深さ・使われ方を最初から書いておくことで、面談では判断の中身の話に時間を使えます。

職務要約は「役割の型」から書き出す

スキルシートの冒頭の職務要約は、読み手が最初に目を通す部分です。DevOpsの経験は範囲が広いため、最初の一文で、自分がどの役割を中心に担ってきたかを示します。

• 一つのサービスのCI/CDとIaCを、設計から運用の引き継ぎまで担ってきた
• 手作業の構築や古いCIからの移行を中心に担ってきた
• 複数のチームが使う雛形や社内の基盤を整えてきた

そのうえで、得意な分野と、関わったサービスの種類、チームでの立場を2〜3文で続けます。職務要約で役割の型が伝わると、後に続くプロジェクト欄を、読み手がその前提で読めるようになります。

スキル一覧は「関わり方」を添える

スキル一覧の欄では、ツールごとに関わり方を短く添えます。

「設計から」「既存の修正」「取り込み」「保守」のような短い言葉で十分です。読み手が、どの段階の仕事を任せられるかを想像できるようにします。担当者・中心メンバー・設計の段階ごとに求められる水準はDevOpsエンジニアのスキルの記事で整理しています。

成果は「前と後」で書く

DevOpsの成果は、ツールを入れたことではなく、開発の進め方が変わったことです。比べられる指標で書くと伝わりやすくなります。

DORAは、ソフトウェアの届け方を測る指標として、変更のリードタイム、デプロイの頻度、失敗したデプロイからの復旧時間、変更の失敗率、デプロイのやり直し率の5つを挙げています（2026年10月時点の案内による）。これらを正確に測っていなくても、次のような書き方ができます。

数字は、守秘義務の範囲で割合や傾向に置き換えます。実数を出せない場合でも、「何を測り、どちらに動いたか」は書けます。書いてよいことの線引きはスキルシートと守秘義務の記事をご覧ください。

IaCの経験は書き分ける

IaCの経験は、関わり方で評価が大きく変わる分野です。次の4つを分けて書きます。

• 新規作成：モジュールの構成から自分で決めて作った
• 既存環境の取り込み：管理画面などで作られていた環境を、コードの管理下に移した
• 既存コードの修正：すでにあるコードの値やリソースを追加・変更した
• 運用の流れづくり：stateの置き場所、差分の確認、適用の承認の流れを決めた

特に、既存環境の取り込みと、運用の流れづくりは、チームでIaCを回した経験として読まれます。書いておくと、面談で深く聞かれる準備にもなります。

プロジェクト欄の記入例

以下は、書き方を示すための架空の記入例です。実在の案件や人物をもとにしたものではありません。

期間：20XX年X月〜20XX年X月（1年程度）
案件概要：小売業向け 会員向けWebサービスの開発基盤の整備
規模・立場：開発チーム数チーム、基盤担当2名（自分はリード。方針の提案と実装を担当）
担当範囲：CI/CDの設計・構築、IaCへの移行、共通の雛形づくり、利用の手引きの作成
使用技術：GitHub Actions（設計から）、Terraform（既存環境の取り込み・モジュールの設計）、コンテナ、OIDC、Python
担当内容：手順書で行っていた反映を、テストと承認を挟むパイプラインに置き換えた。管理画面で作られていた検証と本番の環境をTerraformに取り込み、環境ごとにstateを分けた。パイプラインの認証をOIDCに切り替え、長く有効な鍵を廃止した
工夫・成果：反映のたびに必要だった夜間の手作業がなくなった。雛形を用意し、新しいサービスの立ち上げを各チームが手順どおりに進められるようにした。最後の2か月で社員の担当者に運用を引き継いだ

ポイントは、担当範囲の行と、引き継ぎの一文です。DevOpsのフリーランスは、外から入って仕組みを残す役割のため、引き継いだ経験があると、契約の終わり方まで想像してもらえます。

資格の書き方

資格欄には、正式名称、取得年月、有効期限を書きます。試験に版がある場合は、版も添えます。たとえばHashiCorpのTerraform Associateは、2026年10月時点の公式ページでは現行の試験が004で、有効期間は2年とされています。

例：HashiCorp Certified: Terraform Associate（004）20XX年X月取得、有効期限20XX年X月

資格が効きやすい場面と準備の進め方はTerraform Associateの記事で解説しています。

SREやクラウドの経験と並べるとき

DevOpsとSRE、クラウドの構築の経験が混ざっている人は、案件ごとに「どの役割が中心だったか」を一行目に書くと読みやすくなります。障害対応やオンコールの経験の書き方はSREのスキルシートの記事、クラウドの構成の書き方はAWSのスキルシートの記事が参考になります。応募する案件に合わせて、中心の役割に近い経験を上に置き換えると、読み手が迷いません。

よくある質問

個人の検証環境で作ったパイプラインも書いてよいですか？

書いてかまいませんが、実務の経験とは分けて、「個人の検証」と明記しましょう。実務で触れていない分野を学んでいることは伝わりますが、混ぜて書くと面談で確かめられたときに信頼を損ねることがあります。

成果を示す数字がまったく手元にありません。どう書けばよいですか？

数字がなくても、手作業の手順がなくなった、夜間の作業が不要になった、雛形を使うチームが増えたといった、起きた変化を書けます。次の案件からは、参画した時点の状態を一度記録しておくと、成果を説明しやすくなります。

使ったツールが古いものばかりでも不利になりませんか？

古いツールの経験は、移行の案件で役に立つことがあります。古い仕組みの動きを調べ、新しい仕組みへ移した経験があれば、むしろ強みとして書けます。移行の経験がない場合も、何を自動にし、どう引き継いだかを書けば、考え方は伝わります。