SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2025 Summer セッションレポート(AD)

「孤軍奮闘するエース」のためのIaC×Observability入門──東京エレクトロンデバイスが示すツール導入にとどまらない可能性

【18-B-8】脱属人化・ブラックボックス化!チーム全体でインフラを理解する IaC × Observability 入門編

  • X ポスト
  • このエントリーをはてなブックマークに追加

 インフラ運用が特定の担当者に依存し、構成や状態がブラックボックス化してしまう──多くの開発組織が直面するこの課題に対し、東京エレクトロンデバイスの中林稔氏と小野瀬つばさ氏が解決策を提示した。IaC(Infrastructure as Code)とObservability(可観測性)ツールを段階的に導入し、「孤軍奮闘する1人のエース」から「チーム全体で理解するインフラ」への転換を図る実践的なアプローチについて、ツール導入の技術論から組織文化の醸成まで説明する。

  • X ポスト
  • このエントリーをはてなブックマークに追加

アジャイル組織に適したインフラ運用とは──複雑化と属人化に立ち向かう

 東京エレクトロンデバイスでHashiCorp製品の技術担当を務める中林稔氏は、現代のインフラ運用が抱える根本的な課題から講演を始めた。「以前は、リリースに1年ぐらいかけてじっくり開発、リリースしていたが、アジャイル開発になって、数週間ごとに新機能をどんどんリリースする形が増えてきた」と現状を分析する。

 こうした開発速度の向上に対し、インフラ側も複雑化が進んでいる。コンテナやサーバーレス、マイクロサービスといったテクノロジーの普及により、システム構成は以前とは比較にならないほど複雑になった。さらに、頻繁なリリースに伴ってシステムが微細に変更され続けるため、対応に日々追われる状況が見られるようになった。

東京エレクトロン デバイス株式会社 コンピュータネットワーク事業部 ソリューションエンジニア 中林 稔氏
東京エレクトロン デバイス株式会社 コンピュータネットワーク事業部 ソリューションエンジニア 中林 稔氏

 中林氏は理想的なインフラ運用の姿として、「クラウド事業者のベストプラクティスにあるように、標準化されて、一貫したインフラ」を挙げる。しかし現実には、知識が特定の人に偏ってしまう場合や、チームごとに使用するツールがバラバラになる状況が頻発する。

 中林氏は「従来のような手作業や勘に頼った運用が続いていると、ビジネス速度が低下するだけではなく、運用コストも増える。そういうジレンマに陥ってしまう」と課題の深刻さを指摘した。

インフラ運用における理想と現実のギャップ
インフラ運用における理想と現実のギャップ

 こうした課題に対し、中林氏は2つの軸からなる解決アプローチを提示した。構築面におけるIaCツールによる自動化と、運用面におけるObservabilityツールによるシステム内部状態の可視化である。

 IaCの導入効果について中林氏は「インフラの変更が多い場合や、開発環境と同じ構成の異なる環境で再現させるには、GUIを使った設定では難しく、IaCが欠かせない」と強調する。さらに、IaCツールを使用することで「ポリシーのチェックもコードで自動化できるようになる。これによって統一性と安全性を両立した、インフラの運用が可能になる」と付け加えた。

 一方、Observabilityの重要性については、マイクロサービスのような複雑に絡み合ったシステムへの対応を理由に挙げた。「従来の死活監視だと何か問題が起こった際に、原因の特定が結構難しい」ため、システム全体をエンドツーエンドで監視する可観測性の考え方が不可欠だという。

 ここで中林氏は、IaCツールとObservabilityツールの具体例として、「HCP Terraform」と「Datadog」の組み合わせを挙げた。これらのツールを併せて利用することで、変化に強いインフラを実現できると紹介する。

 「HCP Terraformであれば、承認フローを導入して属人化を排除することができる。一方でDatadogでは、システムがいつもと違う状況のときに、メトリクスやログ、トレースなど多面的なデータを活用して、チームの意思決定を促進し、適切な対応が迅速に取れるようになる」(中林氏)

自動化と可視化で、理想的なインフラ運用を実現
自動化と可視化で、理想的なインフラ運用を実現

孤軍奮闘する時こそ、「とりあえず触ってみる」が大事

 具体的な導入方法については、同社でObservability製品を担当する小野瀬つばさ氏が解説した。小野瀬氏はまず、CNCF(Cloud Native Computing Foundation)が提唱するクラウドネイティブ成熟モデルについて言及。

 この成熟モデルは、「1.Build(まずは触ってみる)」、「2.Operate(小さく投入し始める)」、「3.Scale(チーム間で広がる)」、「4.Improve(自動化とガバナンスを整える)」、「5.Adapt(全社展開・自律最適化)」の5段階で構成されている。しかし小野瀬氏は、「この成熟モデルは導入指針としては非常に重要だが、現実には並行して行うべき組織改革が後回しになってしまう」と指摘した。

 そこで、現場に落とし込みやすく、各チームが横断的に理解しやすく、共通の視点を持てるようにするために、3つのステップ(導入の第一歩、チーム展開、全社展開・最適化)に再構成した実践的なアプローチを提示した。

CNCFの成熟モデル実現を3つのステップに変換
CNCFの成熟モデル実現を3つのステップに変換

 第1ステップは「導入の第一歩」で、小野瀬氏は「とりあえず触ってみるということを強く推奨している」と述べる。HCP Terraformについては、ローカル環境を構築してAmazon VPCやAmazon EC2をIaCで構築する基本的な内容からスタートする。

 「この段階ではterraform fmt(コードフォーマッター)やterraform validate(構文検証コマンド)を使って、まずはコードの整形であるとか、検証の習慣を身につけると、チームでの読みやすさや保守性が大きく向上する」と小野瀬氏は「やってみること」の重要性を説いた。

 Observabilityについても同様に、「1台のインスタンスにDatadogのエージェントをインストールし、CPUやメモリなどの標準的なメトリクスを取得する。初めは本当にシンプルなダッシュボードでも構わない。可視化できたというような実感を得られることが大切だと思っている」とシンプルなスタートを推奨する。

 一方で、この段階でのチームの状態について、小野瀬氏は現実的な課題を率直に語った。

 「このステップではインフラ管理は一部の個人や少人数に依存しているケースが多く見られる。1人のエースが孤軍奮闘して、一番辛いのはこの時期」としながらも、「この時点で1人で頑張ってる状況でも諦めないでいただきたい」と述べる。

 小野瀬氏は孤軍奮闘の状態を否定的に捉えるのではなく、「決して悪い状態ではなくて、誰かが一歩踏み出してるからこそ、そこからチームの展開が可能になる」と前向きに位置づけた。「このステージではとりあえず作ってみた、やってみたみたいなところの環境を使って、他のメンバーに見せたり、定例で少し共有するだけでも、次のステップの種まきになる」として、小さな共有活動の重要性を説いた。

一人または少人数でつらい時期だが、次のステップにつながる
一人または少人数でつらい時期だが、次のステップにつながる

ツール導入を超えて──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などを実行するみたいなことができる」と実践的な活用例を挙げた。

JiraやSlackなど外部ツールと連携したインシデント対応の自動化も可能
JiraやSlackなど外部ツールと連携したインシデント対応の自動化も可能

 今回の講演で印象的だったのは、技術導入を組織文化変革の手段として位置づけた点である。小野瀬氏は最後に、IaC・Observability導入の真の目的について明確に語った。

 「IaCとObservabilityを導入する目的は、単に構築や監視が便利になるということではない。業務の効率化を超えて、チームそのものの文化が変わり、全社を挙げて横断で最適化を行う一つのきっかけでもある」

 具体的な変化として、インフラの透明化・標準化によって属人性が排除され、データに基づいた判断が可能になり、的確な改善活動につながる。最終的にはIaCとObservabilityがチーム内およびチーム間の共通言語となり、組織を超えたコラボレーションの実現が期待できる。

 小野瀬氏は「ツールはあくまで手段にすぎないが、文化の変革が最終的に大きな成果につながっていくはず」と締めくくり、技術と組織の両面からアプローチすることの重要性を強調した。

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加

提供:東京エレクトロンデバイス株式会社

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/22034 2025/09/25 12:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング