より綺麗なTerraformコードをチームで書き続ける取り組み

Transcript

1. より綺麗なTerraformコードを チームで書き続ける取り組み 木山瑞基 2026/05/29 インフラの「ムリ・ムダ・ムラ」をなくしたい！ 最適化・効率化LT会 1
2. 自己紹介 名前：木山瑞基 所属：シナジーマーケティング株式会社 業務：CRMシステムのインフラ運用 AWS / Mail server 趣味：ボルダリング、旅行、ジョジョ好き Terraform歴：1年半 2
3. 今日話すこと こんな方に向けた話です Terraformを書いているが、チームに明文化されたルールがない方 最近Terraformを書き始めて体系的に知りたい方 話すこと 1. 公式スタイルガイドの読み合わせをやってみた経緯 2. 読み合わせで出てきた "チーム独自ルール" と "誤用" 3. やってみての所感 3
4. 当時抱えていたモヤモヤ Terraformは書けるようになったが、書き方に自信がない 既存のtfコードを確認してある程度真似て書いていた Terraform自体プログラミング言語と異なり書式の自由度が低く気にしなくて もよかった チームには"こうしている"がある コードを書いていて気になる部分など都度聞く形 > 「先輩の書き方を真似てる」だけになっていた 4
5. アプローチ：公式スタイルガイドの読み合わせ HashiCorp公式 Terraform Style Guide をチームで読み合わせ 1. 自分（新人）が叩き台をまとめる a. チームでの運用と公式の見解で異なる(と感じた)部分を記載 2. チームメンバーと読み合わせながらFBをもらう 3. 「公式と違う点」を意図的 / 誤用 に仕分ける ポイント：新人の自分が"分からない"を表明できる立場だった 5
6. 読み合わせで分かったこと ① 個人の気づき編 / ② チーム独自ルール編 / ③ 誤用発見編 6
7. ① 個人の気づき編： 見よう見まねが、ガイドに書かれていた これまで意識せずに書いてた書式がスタイルガイドに明文として書かれていた 命名規則 定義するリソースごとのグルーピング方法 引数の並び方 → チームの書き方は、ガイドに沿った判断の積み重ねだった → 自分の "なんとなくの真似" に、はじめて根拠が付いた 7
8. ② チーム独自ルール編 「公式と違うが、意図的に違う」= 残すべきルール 観点 チームの選択 理由 ファイル分割 terraform.tf → versions.tf に分離 プロバイダ管理が見やすい リソースを main.tf に集約 リソース全集約はしない PoC向け、本運用ではアン チパターン moduleのリポジトリ 構成 モノレポ 公式推奨と異なるがチーム 事情で採用 > 暗黙知だったものを、理由付きで明文化できた 8
9. ③ 誤用発見編 「公式と違い、かつ間違っていた」部分 1. variable を locals で代替できるケースを見落とし -. どちらも変数を扱うための記法 9
10. variable と locals の使い分け variable locals 役割 外部からの入力 内部の計算・再利用 変更タイミング 実行時に上書き可 コード変更時のみ 使いどころ 環境ごとに変えたい値 命名・タグ・派生値 チームの運用フロー上、多くの値は実行時に変えない → 本来は locals で十分なものが variable になっていた 10
11. variable と locals の使い分け 補足 locals は後から追加された記法 ブロック 登場時期 variable Terraform 0.1（2014年）から存在 locals Terraform 0.10.3（2017年9月）で追加 → 最初の約3年間は variable しかなかった → 古くからTerraformを使用していたチームは variable を使用していたため、その癖 が残りやすい 11
12. 成果 チームで一番の若手が構文を体系的に学ぶことで、品質を落とすようなコードを 生成する可能性が無くなった チームの共通言語・コーディングルールが言語化できた クリティカルな問題では無かったが構文の誤用も見つかった 12
13. おまけ：LLMへの指示書・タスク仕様書になる 明文化したルールは、 CLAUDE.md / .cursorrules などにそのまま転用可 # Terraform Coding Rules (抜粋) - providerは versions.tf に分離する - 派生値は locals を使う（variableは外部入力のみ） さらに：読み合わせ資料が、そのままリファクタリング指示書になった 公式との差異を言語化した読み合わせ資料をそのままコーディングエージェント に投入 → 人にもLLMにも効くドキュメントになった 13
14. まとめ 14
15. まとめ ① 新人・若手こそやる価値がある 先入観がないからこそ、素朴な疑問が暗黙知を掘り起こす 体系的に学ぶことで若手自身が綺麗なコードを書けるように ② 綺麗なコードは「チームの共通言語」から生まれる 個人の努力より、揃った言語のほうが効く ③ 公式スタイルガイドは"読み合わせ教材"として最適 > 「動いてるから正しい」は危険、一度立ち止まって読み合わせを 15