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

GCP（Google Cloud）エンジニアのスキルシートは、誰の依頼で、誰が使う環境を作ったかと、組織・フォルダ・プロジェクトのどこに権限や決まりを置いたかを書くのが基本です。Google Cloudの案件は、データ分析のチームやアプリ開発のチームと組んで進むことが多く、読み手は「どのチームの隣で、どこまで任せられるか」をシートから判断しようとするからです。BigQueryの費用の改善のような成果は、金額ではなく、仕組みと変化の割合で書きます。

全体の構成はスキルシートの基本をご覧ください。案件で見られるスキルの中身はGCPエンジニアの案件で求められるスキル、経験の棚卸しと独立の準備はGCPエンジニアがフリーランスになるにはで扱っています。ここでは、シートへの書き方に絞って説明します。

「依頼元」と「利用者」を1行で書く

Google Cloudのプロジェクト欄で、ほかのクラウドより目立って効くのが、依頼元と利用者の1行です。同じBigQueryの環境づくりでも、分析チームのために権限とデータセットを整えたのか、アプリのログを集める仕組みを作ったのかで、合う案件が変わります。

案件概要の次に、次のような行を置きます。

• 「依頼元：分析チーム／利用者：社内の分析担当者 数十名。分析用の環境と権限を整備」
• 「依頼元：アプリ開発チーム／利用者：一般の利用者向けWebサービス。コンテナの実行環境を構築・運用」
• 「依頼元：情報システム部門／利用者：社内の複数部門。プロジェクトの作り方の標準を策定」

チームの名前は役割で書き、部署名や人名は書きません。利用者の数は「数十名」「数千人規模」のように桁でぼかせば十分です。

この1行があると、読み手は「データ基盤寄りの人か、アプリ基盤寄りの人か」をすぐに判断できます。両方の経験がある方は、応募する案件に近いほうのプロジェクトを上に置き、要約の1行目もそちらに合わせて入れ替えましょう。

リソース階層のどこに決まりを置いたかを書く

Google Cloudでは、組織の下にフォルダ、その下にプロジェクトが並び、上で付けた権限やポリシーは配下に引き継がれます。そのため「IAM設計の経験あり」だけでは、どの高さで設計したのかが分かりません。

これは書き方を示すための例です。プロジェクトの数は「数十のプロジェクト」のように書き、プロジェクトIDや組織のドメインは書きません。

サービスアカウントの扱いは、Google Cloudの案件の面談でよく聞かれる点です。鍵のファイルを使っていたのか、鍵を使わない方法へ移したのかなど、扱い方を変えた経験があれば1行で書いておくと、話のきっかけになります。

BigQueryの費用の成果は「仕組み」と「割合」で書く

BigQueryを扱った経験は、Google Cloudの案件で評価されやすい部分です。ただ、費用の改善を「月○万円削減」のように金額で書くと、参画先の利用料という社外に出せない情報になります。費用の成果は、次の3つに分けて書きます。

1. 何を調べたか：請求データやクエリの履歴から、費用がかかっている処理を特定した
2. 何を変えたか：パーティションの設定、処理量の上限、定期実行の見直しなど
3. どのくらい変わったか：「対象の処理の費用が半分程度に」「月ごとの変動が小さくなった」のように割合や傾向で

費用の改善は、権限やネットワークの設計と違って、成果が目に見えやすい経験です。仕組みまで書いておけば、金額を出さなくても十分に伝わります。データの取り込みや加工の経験が中心の方は、データエンジニアのスキルシートの書き方もあわせてご覧ください。

実行環境は「選んだ理由」を1行添える

Google Cloudでアプリを動かす方法は、Cloud Run、GKE、Compute Engineなど複数あります。使用技術の欄に並べるだけでなく、その実行環境を自分で選んだのか、決まっていたのかを書き分けます。

• 自分で選んだ場合：「処理の特性を比べ、運用の手間が少ないCloud Runを選定」
• 決まっていた場合：「既存のGKEクラスタで、新しいサービスの公開設定とデプロイを担当」
• 途中で移した場合：「要件の変化に合わせ、Cloud RunからGKEへ移行。理由と手順を文書化」

途中で移した経験は、両方の仕組みの違いを理解していないとできない仕事です。シートでは1行でも、面談で話を広げやすい項目になります。信頼性の改善や監視が中心の方は、SREのスキルシートの書き方も参考になります。

認定資格は有効期限まで書く

Google Cloudの認定は、正式名称と取得年月に加えて有効期限を書きます。2026年10月時点のGoogle Cloudの案内では、有効期間は認定と更新の方法によって違います。

更新の方法によって次の期限までの長さが変わるため、取得年月から期限を推測して書くと、ずれることがあります。受け取った認定の情報で実際の期限を確かめ、その日付を書いてください。

例：Professional Cloud Architect（Google Cloud）　20XX年X月取得（有効期限20XX年X月）

分野ごとのProfessionalの認定の位置づけはGCPの案件で求められるスキルで紹介しています。期限が切れた認定は、有効なものと分けて「取得歴」として書きます。

プロジェクト欄の記入例

ここでは、分析用の環境の整備と費用の見直しを担当した場合を想定しています。以下は書き方を示すための例で、実在の案件や実績ではありません。業界や規模はぼかしています。

期間：20XX年X月〜20XX年X月（1年程度）
案件概要：サービス業向け 分析用データ環境の整備と運用
依頼元・利用者：依頼元は分析チーム。利用者は社内の分析担当者 数十名
規模・立場：基盤担当2名（自分は主担当）。分析チームと週次で要望を確認
担当工程：設計、構築、運用
使用技術：BigQuery、Cloud Storage、Cloud Run、IAM、Terraform（新規作成）、Cloud Monitoring
担当内容：部門ごとのフォルダとプロジェクトの切り方を設計し、グループ単位でロールを付ける構成をTerraformで作成。分析者が使うデータセットの権限を整理した
工夫・成果：費用の大きいクエリを特定し、パーティションの設定と定期実行の見直しを提案。対象の処理の費用が大きく下がった。処理量の上限を設け、想定外の費用が出にくい仕組みにした

この例では、依頼元と利用者、階層のどこに決まりを置いたか、費用の成果を金額でなく仕組みで書いています。

AWSの経験が長い方の書き方

AWSからGoogle Cloudへ広げている方は、AWSでの経験をGoogle Cloudのサービス名に置き換えて書かないようにします。名前を読み替えただけでは、権限の継承やプロジェクトの切り方など、Google Cloudに特有の部分の経験が伝わらず、面談で食い違いが出ます。クラウドごとに行を分け、Google Cloudで実際に触れた範囲だけをGoogle Cloudの行に書きましょう。AWSの書き方はAWSのスキルシートの書き方、AzureはAzureのスキルシートの書き方で紹介しています。

よくある質問

Google Cloudの経験が1案件だけです。どう書けばよいですか？

1案件でも、依頼元と利用者、担当した工程、階層のどこで作業したかを書けば、経験の中身は伝わります。ほかのクラウドやオンプレミスの経験は別の行で書き、Google Cloudの行には実際に触れた範囲だけを書きます。個人の検証環境で試したことがあれば、実務とは分けて添えると補いになります。

分析のSQLを書いた経験は、インフラの案件でも書いたほうがよいですか？

書いておくと判断材料になります。分析の担当者がどう使うかが分かる人は、権限や費用の設計で利用者の事情を考えられると読まれるためです。ただし、インフラの案件であれば、スキル一覧では「関連する経験」の扱いにとどめ、軸の経験より上には置かないほうが読みやすくなります。

費用の改善で、数字を一切出せない場合はどうすればよいですか？

割合も出せない場合は、何を調べ、何を変え、その後どんな運用になったかを書きます。「費用の大きい処理を毎月確認する仕組みを作った」「処理量の上限で想定外の費用が出ないようにした」のように、仕組みが残ったことを書けば、成果として十分に伝わります。