MAGAZINE
Terraform案件で評価されるのは、リソース定義を書いた量だけではありません。チームで安全に変更できる構成、state管理、レビュー、テスト、既存環境の移行まで扱った経験が、実務で再現できる力として伝わります。
Terraform案件で評価される経験
| 領域 | 伝えたい実績 |
|---|---|
| 設計 | ディレクトリ構成、環境分離、モジュール境界 |
| state | リモート管理、ロック、権限、復旧方針 |
| 変更管理 | planレビュー、CI/CD、承認、適用手順 |
| 品質 | lint、静的解析、テスト、ポリシーチェック |
| 移行 | import、既存リソースのコード化、段階移行 |
職務経歴書の書き方
「TerraformでAWSを構築」ではなく、対象規模、課題、設計方針、チーム運用、成果を書きます。
記載例の考え方複数環境で重複していた定義をモジュール化し、planをPull Requestで確認するフローを整備。変更時のレビュー漏れを減らし、新規環境の準備時間を短縮した。
具体的な数値を出せない場合も、何がどう変わったかを説明すると役割が伝わります。
公開ポートフォリオに入れるもの
- 小さくても動く構成とREADME
- 前提条件と設計判断
- 変数、出力、モジュールの分け方
- planまで行うCI
- 破棄手順と費用への注意
実案件のコードを持ち出してはいけません。公開情報だけで作った最小構成を使い、守秘義務を守りながら設計の考え方を見せます。
面談で聞かれやすいこと
- stateが壊れた場合にどう調査するか
- モジュールをどの単位で分けるか
- 手動変更をどう検知・解消するか
- 複数環境・複数アカウントをどう管理するか
- 既存環境をどう段階的に移行するか
唯一の正解を答えるより、チーム規模や変更頻度などの前提を置いて判断理由を説明することが重要です。
よくある質問
Terraformの資格は必要ですか？
必須ではない案件も多くあります。資格より、state管理やレビューを含むチーム運用の実績が重視されやすいです。
個人のGitHubは必要ですか？
必須とは限りませんが、実案件のコードを公開できない場合に、設計意図を示す安全なサンプルとして役立ちます。
参考・一次情報
制度・仕様は変更される場合があります。最新情報はリンク先の公式情報をご確認ください。
