インフラ担当者がプロダクトチームの一員として認められるには
村山氏が所属する東京ガスiネットは、東京ガスグループのインハウスエンジニアとして、東京ガスグループにおける「安心」「安全」「信頼」のブランドを、ITの側面から支えている。
今回の舞台となったのは、東京ガスの受付システムのリニューアルプロジェクトだ。多岐にわたるサービスの中でも、特に重要な「ガス・電気の開始や停止の手続き」を行うシステムを2025年1月に刷新したのだ。
このプロジェクトにインフラ担当として約2年前から本格的に関わることになった村山氏。新しいシステムでは電話やWebといった複数の受付手段と受付内容を統合的に管理・連携する仕組みを集約することになった。万が一トラブルが発生した場合、顧客に多大な影響がありうるため、信頼性の確保が急務であった。
こうしてプロジェクトチームは、システムオーナーである東京ガスと、アプリ開発を担当するパートナー企業、そしてインフラを担当する東京ガスiネットの3社体制となった。
だが、システムの信頼性を高めるために、インフラ担当者ができることとは何なのか。そもそも従来の守備範囲であるVM周辺（仮想マシンやOSレベルのリソース管理など）しか把握できていない状況で、できることはあるのだろうか。遅れてプロジェクトに参画した身として、プロダクトチームの一員として認めてもらい、会社の壁を越えた仲間になるには、何かしらの貢献を示す必要があるとも考えた。
そこで村山氏は、システムの信頼性向上に加え、オーナーやアプリ開発担当者の認知負荷を軽減するために、インフラチームの守備範囲を広げていくことを、チームの内外に対して宣言した。
また、逃げない覚悟を見せ、チームの関係性や信頼性を築くために、「解散しない専任チームとしてやらせてほしい」と要望した。さらには、プロダクトチームの一員として、継続的に学習しながら楽しんで貢献できる環境をつくるため、「インフラチームでもアジャイルを採用したい」とスクラムでの関与を提案し、実行に移していったという。
アジャイルでは「何に価値を置くのか」、チームで価値基準の優先順位を明確にしておくことが重要だ。村山氏は、インフラチームとしてではなく「プロダクトチームとしての健全性」を最優先にすると決めた。この土台がなければ、ビジョンや理想の追求はできないと考えたからだ。さらに、この方針を行動レベルに落とし込み、次の2つの禁止を決めた。
-
他者に対する「べき」の禁止
自身の主張に対する根拠説明をサボっているときに、人は「〜すべきだ」という発言になりがちだ。なぜそう思うのか理由をしっかりと説明して、共感してもらえるように努める。
-
「よろしいですか？」の禁止
「よろしいですか？」と確認することで、相手に責任と権限を渡すことになり、自らの貢献を減らすことにつながる。その代わり、「〜します。気になる点があれば指摘してください」と伝えるようにする。
「これらを守ることで、強引でもオーナーシップ不足でもなく、ちょうど良い塩梅のコミュニケーションを狙っている」（村山氏）
インフラチームの貢献範囲を広げるために何ができる？
「インフラチームの貢献範囲を広げていく」と宣言した村山氏だったが、まず最初にシステムの構成要素や動作を理解し、技術的にも情報的にも、受け身ではなく“主体的”に貢献できる土台づくりから始めた。
そこで村山氏は「1．構成の理解（静的な構造の可視化）」と「2．動作の理解（リアルタイムの挙動の可視化）」という2つのアプローチを取ることにした。
「1．構成の理解（静的な構造の可視化）」については、リバースエンジニアリング的な発想で、以下のような方法で既存リソースを可視化して理解を深めていった。
- 既存のAzureのリソースをTerraformのコードにインポートして構成を把握する。
- Azure Resource Graphでクエリを実行して、リソース情報を一覧で取得する。
- JSONで出力されたリソース構成情報を図示して、構成の全体像を可視化する。
「2．動作の理解（リアルタイムの挙動の可視化）」については、クラウドやサービスも含めたシステム全体を横断的に見られるフルスタックなオブザーバビリティツールがほしいと考え、「New Relic」の導入を決定。オブザーバビリティとは、「システムの全容をリアルタイムに把握して、改善できる状態にある能力」を指し、監視を進化させた考え方として昨今注目されている。
いくつかあるオブザーバビリティツールの中で、New Relicを採用した理由について、村山氏は次のように述べた。
「New Relicは必要な機能を必要なタイミングで段階的に追加していける柔軟性がある。New Relicの主な課金要素は『フル機能のユーザー数』と『投入するデータ量』の2つ。我々は当初システムの全容が見えていない状況だったので、最初から厳密に決めなくても始められる手軽さが魅力だった」。
New Relicを導入した当初は、教科書通りに外形監視から始めた。その後、ある程度モニターやアラートを定義したことで、サービスの異常にも気づけるようにはなったものの、不具合の解消に貢献できるようになるまでには、さまざまな試行錯誤があったという。その具体例として、村山氏は次の2点を挙げた。
-
障害時には自ら首を突っ込む
率先してTeamsで会議部屋を立ち上げ、関係者を巻き込む。会議ではNew Relicのデータをもとに、現状の可視化と事実共有を必ず行うようにした。「状況把握→対策検討→対策決定→実行」のプロセスを通じて、関係者の視点や意思決定基準を学んでいった。
-
復旧後はポストモーテム（障害後の振り返りレポート）を書く
不具合を学びの機会とするために、HRT（謙虚・尊敬・信頼）を意識しながら、ポストモーテムを書いた。チーム内で課題認識を共有できる上、インフラの領域外に関するデータの解釈があやしくても、プロダクトチーム内で共有すれば、自然にフィードバックをもらえて勉強になる。また、ポストモーテムは上層への報告時にも流用できるため、チームメンバーからも喜ばれた。
インフラ担当がNew Relicで実現した3つの貢献
次に、New Relicを用いて村山氏が実際に不具合の解消、引越しシーズンのアクセス負荷過多をスムーズに乗り切ることに貢献した3つの例を見ていこう。
1つ目は、New Relicの「APM（Application Performance Monitoring）機能から付与されたTraceIDによるエラーログ調査」だ。New Relicのダッシュボードを開き、エラーが発生したアプリ名や発生したエラーのメッセージを入力して絞り込み、該当する条件のTraceIDを見つける。そのTraceIDをキーにして、再びログを検索することで、エラーに関連する一連のログを抽出することができる。これにより、エラーの調査効率が上がり、アプリ開発の担当者からは「5倍は速くなった」との声が上がったほか、アプリの実装をわかっていないインフラエンジニアでも、エラーの前後でいつ何が起きたのかある程度理解することができ、切り分けに役立てることができたという。「簡単なクエリを書くだけなので、すぐに始められる。New Relicの導入直後から効果を感じられたところだ」（村山氏）
2つ目は、「遅延テーブルや問題クエリの特定」だ。New RelicのAPMでは、アプリから外部APIを呼び出した回数や、データベースに対するクエリの実行状況も詳細に観測できるようになる。たとえばデータベースであれば、「どのテーブルに、何回クエリが発行され、どれくらい時間がかかっているか」といった情報をテーブル単位で出力することができる。実際、処理遅延が発生した際に、APMのデータをもとに疑わしいテーブルを特定し、そこで使われているクエリを抽出して、アプリ開発の担当者に相談。該当クエリについて改善してもらったところ、データベースのアクセスの平均時間が激減したケースもあった。「パフォーマンスが改善されると、コスト削減にもつなげられる。インフラしかやってこなかった自分にもこのような貢献ができるのは、新鮮な経験だった」（村山氏）
3つ目は「ピーク時に向けた適切な対応」である。ガス・電気の受付システムは、引越しが集中する3〜4月に5〜9倍にまで負荷が増える。公共性の高い東京ガスでは、万一、障害によって受付が停止するような事態になると、経済産業省への報告や是正措置が必要になる。このような大惨事を避けるため、「止まるくらいなら増やせ」というのが定石だった。しかし、New Relicの観測データを活用することで、ピークを見極めたうえで根拠を持ちながら処理能力を拡張し、ピーク後にはスムーズに縮小することができた。「サービスの停止が許されない状況で、データなしにサイズ調整をするのは極めて困難。New Relicがあったからこそ、過度に怯えることなく、最適化を図ることができた」（村山氏）
New Relic導入後のインフラチームの変化について、村山氏は以下のようにまとめた。
「今回のプロジェクトで学んだことを受け、現在は東京ガスグループ全体にNew Relicの活用を広げようと奮闘している」と明かす村山氏。「オブザーバビリティツールは自分たちから見える範囲を、より広く・深くしてくれるもの。関係者間での共通認識を増やし、協力し合いながら課題を解決するための土台となる。データをもとに組織全体の意識・行動・文化を変えられるよう、インフラチームから働きかけていきたい」と語り、セッションを締め括った。
