世界に出て⁠、ビジネスとエンジニアリングの境界を知る

――本日は「Policy as Code（ポリシー・アズ・コード⁠）⁠」をメインテーマに、インフラ運用のモダナイゼーションについてお話を伺います。まずは、これまでの大規模インフラ構築におけるご経験や、そこから見えてきた運用上の課題について教えてください。

泉水: 私が株式会社grasys（以降grasys）に入社したのは2018年の夏頃でした。入社後に関わった非常に印象深い案件として、モバイルゲームのグローバルなインフラ基盤構築があります。このシステムは、日本国内に加えて欧米を含むワールドワイドへ展開するサービスのアーキテクチャでした。

グローバル展開において最もシビアな課題となるのが、ネットワークのレイテンシ（通信遅延）です。モバイルゲームにおいては、数十ミリ秒の遅延がユーザ体験（UX）の致命的な低下に直結します。そのため、「⁠どのリージョンにエッジサーバを配置するか」「⁠データベースのレプリケーションをどう設計するか」や「CDN（Content Delivery Network）をどう組み合わせれば、最もコストパフォーマンス良く、かつ安定したレイテンシを維持できるか」というグローバルネットワークのトラフィックルーティング設計に深くコミットしました。

このインフラ要件とビジネス要件のトレードオフを緻密に設計した経験は、会社としても私自身のエンジニアとしてのキャリアとしても、大きなターニングポイントになったと感じています。このタイミングで、改めてインフラエンジニアリングの重要性を考え、エンジニアリング、とくに設計力を高めることが、ビジネスを広げられると考えるようになりました。

――当時は少数精鋭のチームで運用されていたと伺っています。その後、組織の規模が拡大するにつれて、運用体制はどのように変化していったのでしょうか？

泉水: 私が入社当時は、インフラエンジニアやゲーム開発のバックグラウンドを持つシニア層を中心に10名に満たない、数名の小さな組織でした。その後少しずつ増員し、今は13名程度のチームになっています。

当時は人数が少なかったため、必然的に一人ひとりの裁量が大きくなっていたことを覚えています。もちろん、きちんとクライアントのビジネスを成立させなければいけませんから、メンバー皆、インフラ全般のドメイン知識を深く持ったシニアエンジニアばかりでした。

しかし、組織が成長し、バックグラウンドやスキルセットが多様なメンバーが増えていく中で、次第に「裁量を与えすぎることの壁」や「多様なクライアントへの対応の複雑化」といった課題が顕在化してきました。

具体的には、手動オペレーションによる「Configuration Drift（設定のドリフト：コードで定義された状態と、実際のクラウドリソースの状態が乖離してしまう現象⁠）⁠」のリスクや、エンジニア個々人が持つベストプラクティスが生み出す、作業の属人化です。

また、対応するシステム規模が大きくなると、誰が・いつ・なぜそのリソースを変更したのかという監査証跡（オーディットログ）の追跡可能性も重要になります。少人数チームの「阿吽の呼吸」に依存した運用から、スケール可能な組織的な運用への脱却が急務になっていました。

ボトムアップによるOSS導入⁠、そして⁠、承認フローの仕組み化と厳格化

――属人化を防ぎ、インフラの品質を一定に保つために、具体的にどのような技術的アプローチをとられたのでしょうか。

泉水: まずはIaC（Infrastructure as Code）の徹底と、CI/CDパイプラインを通した「承認フロー」の厳格化です。弊社ではインフラリソースのプロビジョニングに一貫して「Terraform」を利用していますが、その実行環境（State管理とApplyの実行基盤）はフェーズによって大きく変遷しています。

最初期は、管理用の踏み台サーバ（Bastion Host）にログインし、各エンジニアが手動でterraform applyを実行していました。しかしこれでは、ローカル環境との差分管理やシークレット情報（アクセスキーなど）のセキュアな管理に限界が来ます。そこで、SaaS型の「Terraform Cloud（TFC⁠）⁠」を導入し、リモートでのState管理とVCS（バージョン管理システム）連携による自動実行のフローを構築しました。

その後、組織規模の拡大に伴うランニングコストの最適化や、より細やかなRBAC（ロールベースアクセス制御⁠）⁠、そして自社要件に合わせたカスタマイズ性を求め、現在ではOSSのTerraform実行基盤である「Terrakube」を自社でホスティングして利用するアーキテクチャに行き着きました。

このOSS導入の背景には、エンジニア自身がTerraformに精通し、各々の理解が深かったこと、その流れから自分たちでホスティングし、実行基盤を構築したほうがコスト面に加えて、業務に合わせた柔軟性が高まるからと考え、ボトムアップでの提案があったからです。

冒頭でも話したようにgrasysはエンジニアの裁量が大きいことが特徴で、その結果として一人ひとりが良いと思ったことは気軽に提案し、自分を含めたリーダーを交え、フラットに議論して検討できる環境があります。これは、私が入社した当時から変わらない雰囲気、もっと言えば、grasysのエンジニア文化と言えます。

話を戻して、現在の運用では、エンジニアがGitHubなどのリポジトリにコードをプッシュすると、Terrakube上で自動的にterraform planが走り、その実行計画の差分結果がレビュアーに通知されます。権限を持った承認者が確認し、承認（Approve）して初めてクラウドリソースに変更が適用される、という統制のとれたデプロイメントパイプラインが完成しています。

Policy as Codeで心理的安全性というエンジニアのガードレールを整備

――承認フローをシステムに組み込んだことで、統制は取れるようになった反面、新たな課題などは生まれましたか？

泉水: 課題というほどではないですが、承認フローの仕組み化と厳格化を進めた結果、「⁠承認者（承認権限を持つシニアエンジニア）を捕まえないと、次の作業に進めない」という人的なボトルネック（待ち時間）が発生するようになりました。

たとえば、大規模アップデートのリリース前夜など、非常にタイムセンシティブな時期に、休前日の夜間や休日にインフラ構成を一気に組み上げたい場面があります。しかし、承認待ちのキューが溜まってしまい、CI/CDのパイプライン上でリードタイムが極端に長くなるという「見えない壁」が開発スピードに影響が出るようになりました。

これは統制を強めた結果、アジリティ（俊敏性）が犠牲になってしまったとも言えますね。

――その「アジリティとガバナンスの両立」という難題を解決するためのアプローチが、「⁠Policy as Code（PaC⁠）⁠」の導入だったのですね。

泉水: はい、そのとおりです。Terrakubeへの移行を進めるタイミングで、この課題に直面していた有志のエンジニアが旗を振り、PaCの概念を積極的にCI/CDパイプラインに組み込む取り組みに動き出しました。

PaCとは、インフラのセキュリティ要件や社内の運用ルールを「コード（ポリシー⁠）⁠」として定義し、Terraformの実行計画に対して自動的にテスト・評価を行う仕組みです。Open Policy Agent（OPA）のRego言語などのポリシーエンジンを利用することで、仕組み化を実現できます。

PaC導入のおもな目的は、弊社が定義しているTerraformの標準モジュールから逸脱した書き方や、セキュリティインシデントに直結するような危険な設定を、人間の目視レビューに頼る前に、システム側で自動検知して弾く（Denyする）ことです。

そうすれば、先ほどの承認フローにおいて余計なチェックをしなくて済むようになります。

また、承認フローの徹底によりアジリティが犠牲になっていることが課題だとは言いましたが、PaCの導入とは別に、リーダーや現場のエンジニアそれぞれが、全体のスケジュールをしっかりと見直すようになり、余裕を持ったスケジューリング設計をする意識が高まるという良い効果も出ています。

――実際にPaCをCI/CDパイプラインに導入してみて、現場のエンジニアの反応や、定量・定性的な効果はいかがでしたか？

泉水: インフラ定義の明らかなアンチパターンや、致命的なセキュリティホールになり得るコードを、パイプラインの早い段階（シフトレフト）で確実にブロックできるようになったのは、インフラ運用における心理的安全性という意味で絶大な効果がありました。承認者側にとっても、「⁠最低限のセキュリティ要件はシステムが担保してくれている」という安心感があるため、レビューにかかる認知的負荷が大幅に軽減されました。

一方で、技術的な難易度とは別の次元で「ポリシーの線引き（閾値の設計⁠）⁠」の難しさにも直面しています。

ルールをガチガチに固めて例外を一切許容しない設定にしてしまうと、インフラ運用に不可欠な「特例対応」が回らなくなります。クラウドプロバイダ側のAPI仕様変更に追従するためのイレギュラーな設定や、クリティカルな障害発生時のBreak-Glass（緊急時のガラス割り）的な作業が必要なシーンにおいて、静的なポリシーチェックでterraform applyが強制終了させられてしまうと、システムの復旧遅延を招き、現場エンジニアの強いフラストレーションにつながってしまいます。

――非常にリアルな運用課題ですね。そうした「ガバナンスの厳格さ」と「運用の柔軟性」のジレンマに対しては、現在どのようにバランスをとっているのでしょうか。

泉水: 運用の中でチューニングを重ね、現在はポリシーの評価レベルを多段階に設定しています。

絶対にシステムに混入させてはならない致命的になりうる設定については「完全にブロック」しますが、ベストプラクティスからの逸脱や非推奨な設定（Soft Mandatory）に関しては、デプロイ自体は許可しつつもCIツール上で「ワーニング（警告⁠）⁠」を出すだけにとどめるなど、柔軟性を持たせた運用に切り替えました。

「会社として絶対に死守すべきグローバルなセキュリティポリシー」と「各案件の要件やフェーズによって許容されるべきローカルルール」の境界線をどう設計し、コードとして表現していくかが、この先PaCを成熟させるための継続的な課題だと認識しています。

AIとの向き合い方⁠、grasysが求めるエンジニア像

――インフラ運用領域の最新トレンドとして、AI（生成AIやLLM）の技術進化も著しいですが、AIOps的な観点での今後の展望はいかがでしょうか？

泉水: AI技術、とくにLLM（大規模言語モデル）のインフラ領域への応用には、非常に大きなポテンシャルを感じています。例えば、複雑に絡み合ったTerraformコードの依存関係をAIに解析させてリファクタリング案を出させたり、インフラ構成図からIaCのコードベースを自動生成させたり、あるいは前述のPaCのポリシーファイル自体を自然言語から生成・レビューさせるといったユースケースは十分に実用段階に入りつつあります。

ただ、エンタープライズのインフラを預かる立場としては、セキュリティ面とデータガバナンス（機密情報の取り扱い）の観点で慎重にならざるを得ません。自社のインフラの根幹に関わるアーキテクチャ情報やシークレットを含むコードを、安易にパブリックなAIのAPIに投げるわけにはいかないからです。

そのため現状では、「⁠どのAIツール（たとえばクローズドな環境で動くAIアシスタントなど）を、どの業務プロセスに、どのようなガードレールを設けて組み込むか」というPoC（概念実証）を進めているフェーズです。クラウドやLLMの進化サイクルは尋常ではない速さですので、セキュリティ要件をクリアしたものから、エンジニアの開発者体験（DX）を向上させるツールとして積極的に組み込んでいきたいと考えています。

――grasysのエンジニアリングを担う立場としては、悩ましくも非常にエキサイティングなフェーズのように感じました。最後に、そうした技術的変革期において、今後どのようなエンジニアと一緒に働きたいか、御社が求める人物像を教えてください。

泉水: これまでも話してきたように、弊社のインフラエンジニアリング組織は、クラウドネイティブなアプローチや新しいOSS、概念を積極的に検証し、プロダクション環境に取り入れていく文化が根付いています。

現代のインフラエンジニアには、単なるLinuxやネットワークレイヤの知識に加えて、各種SaaS、クラウドプロバイダのマネージドサービス、IaC、CI/CDパイプラインなどを組み合わせてシステムをデザインする「ソフトウェアエンジニアリング」の能力が強く求められます。

そのような時代において、grasysは一人ひとりの裁量を大きくし、チーム全体で課題解決、クライアントのビジネス成長を支えるエンジニア組織を意識し、ビジネスを遂行しています。

ですから、決められた手順書をこなすだけの運用オペレータではなく、自らアーキテクチャの課題を発見し、技術的な解決策をプロトタイピングして推進できるような自己駆動型のエンジニアには、非常にやりがいのある環境だと胸を張って言えますね。

TerraformやPaCはもちろん、今後のトレンドとなるインフラ運用のAI化といった新しい波を脅威と捉えるのではなく、「⁠技術のレバレッジを効かせるための強力なツール」としておもしろがり、ともに泥臭く実装して新しい価値を生み出せるような、知的好奇心旺盛な方とぜひ一緒に働けたら嬉しいです。

――現場のリアルな課題と、それを技術で乗り越えていく力強いビジョンをお伺いできました。本日は貴重なお話をありがとうございました。