ツール導入を超えて──IaCとObservabilityを組織間の共通言語にする
第2ステップの「チーム展開」では、HCP Terraformで複数の環境、例えば開発環境やステージング環境、本番環境といったワークスペースを活用し、加えてバージョン管理システム連携やCI/CDのワークフローと組み合わせて、プルリクエストベースの運用フローを整備していく段階となる。
Observabilityにおいても、リアルユーザーモニタリングや外形監視などユーザー視点での監視を導入、加えてSLO指標の策定を通じて「単なるインフラ監視といったところから、よりユーザー体験を重視した可視化へ進化していく」ことを目指す。
この段階の組織について、小野瀬氏は「複数のチームがIaCやObservabilityツールを使い始め、徐々に組織全体に浸透していっているのがこの状態」と説明する。役割分担も少しずつ明確になり、DevとOpsの連携が自然と生まれてくる時期でもある。
しかし新たな課題も浮上する。小野瀬氏は「チームごとの成熟度の差やルールの差異が、組織上のボトルネックになってくるのもこの時点」と、現実的な問題を指摘する。
「ツールを導入しただけではなく、ツールを通じて会話が生まれているか、ツールを通じてルールやナレッジが組織を超えて共有されているかといった観点で標準化や文化醸成を意識していくことが非常に重要」と、文化面の重要性を強調した。
最終段階の第3ステップ「全社展開・最適化」では、開発者主導でのセルフサービス化を実現する。小野瀬氏は「インフラの利用が開発者主導で行える状態を目指していく。ここではセルフサービス化が進み、誰かに依頼せずとも環境が用意できる、そういった状態を目指している」と理想形を描いた。
この段階では、IaCにおけるポリシーの自動適用、いわゆるPolicy as Codeにより、コードレビュー時に自動でセキュリティチェックが入るような高度な統制も効かせていく。またObservabilityツールから発行されるアラートや障害も自動で処理されるようなワークフローを組んで、例えばSlackと連携するなど、より高度な自動化を目指していく段階となる。
技術的な深掘りとして、小野瀬氏はDatadogの機能についても詳述した。特にAPM（Application Performance Monitoring）のService Map機能については、「アプリケーションが複数のマイクロサービスで構成されているような環境において、その依存関係を自動的に可視化してくれるもの」と説明した。
障害発生時の効果について、「あるサービスでエラーが発生した場合、その上流や下流のサービスへの影響であるとか、ボトルネックなどを即座に確認することができるので、影響範囲の確認や対応の優先度の順付けも非常にスムーズになる」と具体的な価値を示した。
Workflow Automation機能についても、「ノーコードで直感的にインシデント対応や定型作業を自動化することができる機能」と紹介し、「アラートが発生したらSlackに通知し、同時にJiraのチケットを作成し、必要な対応手順をまとめたRunbookなどを実行するみたいなことができる」と実践的な活用例を挙げた。
今回の講演で印象的だったのは、技術導入を組織文化変革の手段として位置づけた点である。小野瀬氏は最後に、IaC・Observability導入の真の目的について明確に語った。
「IaCとObservabilityを導入する目的は、単に構築や監視が便利になるということではない。業務の効率化を超えて、チームそのものの文化が変わり、全社を挙げて横断で最適化を行う一つのきっかけでもある」
具体的な変化として、インフラの透明化・標準化によって属人性が排除され、データに基づいた判断が可能になり、的確な改善活動につながる。最終的にはIaCとObservabilityがチーム内およびチーム間の共通言語となり、組織を超えたコラボレーションの実現が期待できる。
小野瀬氏は「ツールはあくまで手段にすぎないが、文化の変革が最終的に大きな成果につながっていくはず」と締めくくり、技術と組織の両面からアプローチすることの重要性を強調した。
