文化の狭間で、組織の「現実」を書き換える試行錯誤

村山：今回は、「文化の狭間で組織の現実を書き換える試行錯誤」というテーマでお話しします。

私は2009年に東京ガスｉネット株式会社へ入社し、以来インフラ系のエンジニアとして仕事をしてきました。得意な領域はアジャイルや可観測性で、最近は生成AIの領域もキャッチアップしています。アジャイルやDevOps、プロダクト思考のアプローチが好きで、課題にこだわって価値を出したいと考えています。

東京ガスｉネット株式会社は、2024年からグループ本社の1部門という位置付けになりました。以前よりも、グループ全体のITを引っ張っていく役割が明確になったと感じています。ただし、組織図を変えただけで文化や慣習が急に変わるわけではありません。まだまだ逆境の最中にあるというのが正直なところです。

私にとって技術選定とは、解決したい課題とチームの状況を踏まえ、価値に向かうための意思決定です。価値を起点にしなければ、どれほど優れた技術でも価値につながらないことがあります。エンタープライズ企業の中では、価値を軸に意思決定をすること自体が難しい場合もあります。それでも、価値を軸に意思決定できるチームを作ることは諦めたくありません。

今日は、そのために現場で何を考え、どう動いてきたのかをお話しします。

価値を軸にした技術選定はなぜ難しいのか

まず、価値という言葉の定義をお伝えします。私は、「価値とは誰かの課題を解決すること」だと考えています。

誰かの痛みや困りごとがあり、それに対して解決策がある。その重なった部分が価値です。だからこそ、課題を正しく捉え、その課題に解決策を適用していくことが重要になります。

では、その価値を軸にすることがなぜ難しいのか。根底にあるのは、権限、責任、能力の不一致だと考えています。エンタープライズのITでは、ビジネス上の権限や最終的な責任は事業会社側にあります。しかし、技術的な判断能力が事業会社側に十分に蓄積されていないケースは珍しくありません。IT専門人材ではない方も多く、責任も重く、学習の余力も確保しづらい。さらに急な異動もあるので、構造的に難しい状況が生まれやすいのだと思います。

権限・責任・能力の不一致が生むもの

こうした構造の中では、発注側は技術判断の負荷を避けたいと考えやすくなります。その結果、技術的な妥当性よりも、社内説明のしやすさや監査耐性が優先されやすくなります。契約でそれを担保したいので、役割や成果物を厳密に定義したくなる。さらにフェーズ分割をして、リスクを管理しやすくしたくなるわけです。

受注側もまた、技術的能力があっても仕様決定権や事業責任を持てないので、どうしても相手に合わせる方向へ寄りやすくなります。契約遵守が最優先になり、スコープ外を明確にしないと仕事が回らない。不確実性を含む価値追求型の提案が、合理的ではなくなってしまいます。

このような状況では、現場でいびつなことが起こります。たとえば開発側がCIパイプラインや自動テストを整備しても、維持管理担当から不要だと言われることがあります。インフラ側がTerraformで環境整備をしても、運用へ渡す段階で手順書を求められ、コード自体は使われないこともあります。

採用した技術が悪いのかというと、そうではありません。問題は、フェーズや契約を超えて価値を出すことに対する全体的なオーナーシップが、実質的に存在しないことです。

双方がそれぞれ合理的に行動していても、価値から分断されてしまう。この構造問題こそが、技術選定を難しくしていると捉えています。

どのようにチームをつくったか

理想は、価値提供に必要な権限、責任、能力をできるだけ1カ所に揃えることです。ただし、ビジネス上の権限や最終責任そのものを動かすのは簡単ではありません。だからこそ、技術者がそこへ近づいていく必要があると考えています。物理的な組織をすぐ変えられなくても、論理的にはワンチームになって仲間として動く、という姿勢です。

そのために、私は技術的な判断や責任を取りに行くことを重視してきました。自分の専門領域について、責任回避的に確認を求めるのではなく、自分たちで判断することが重要です。また、企画、構築、運用といったフェーズ単位で分けないことも大切です。受け渡しの間でロスが生まれますし、技術的なフィードバックも返ってこなくなります。さらに、静的な役割分担に固執せず、価値提供に貢献できるかどうかで動くべきだと考えています。

こうした柔軟な動き方をしようとすると、請負契約はかなり厳しくなるので、それを避けることも大事です。契約に縛られると、価値を軸に優先順位を変え続けることが難しくなるからです。契約遵守やスコープ外の切り分けを優先する働き方ではなく、どうすれば価値提供できるかをシンプルに考えられる構造へ寄せていく必要があります。

ただし、これをいきなり全社に広げるのは現実的ではありません。自分たちが責任と権限を確保できそうな領域に着目して始めるべきです。その際、ビジネス上の重要なプロダクトを選び、課題を軸に据えると、インパクトも出しやすく、投資の合理性も説明しやすくなります。チームを維持しやすい領域を選ぶことが大切です。

重要な領域に踏み込むのを怖いと感じる方もいると思います。しかし、自分たちの能力が相対的に優位なら、思い切って入っていった方がよいと考えています。学習は実践の中でしか進みません。できるようになるまで待っていたら、その日は来ないことが多いからです。

実例：東京ガス 受付システムへの参画

私が実際に踏み込んだのは、東京ガスの受付システムでした。ガスや電気の利用開始や停止などの手続きを受け付けるシステムです。

Web受付だけでなく電話受付もあり、全体では80種類以上の受付があると聞いています。電話受付はピーク時に600ブース程度が稼働する規模で、数時間止まるだけでも大きな影響があります。重要業務であり、高い信頼性が求められるシステムでした。

結果的には、この領域ではかなり任せてもらえました。システムオーナーが現場感のある方で、受付を数種類から始めて徐々に育ててきた背景もあり、プロダクト的な感覚を持っていたからです。さらに、当時は20年ほど続いた旧システムからの移行プロジェクトが本格化していた時期で、タイミングとしても大きかったと思います。私たちには社内共通基盤やAzureの知見があり、相対的な優位性もありました。

最初に行ったのは、専任チーム化の提案です。ビジョンを書き、活動を言語化し、スクラムの準備も進めました。やっていること自体は教科書的ですが、フェーズ分割のないフルサイクルの体制を社内で実現するのは、実はかなり逆風の中での取り組みでした。私はインフラ組織の中でもサーバー構築側にいましたが、運用まで引き受ける前提でチームを作っていきました。

契約を混在させた失敗

ここでは、過去の失敗も1つ共有しておきます。以前、請負契約と準委任契約をワンチームの中で併用したことがありました。見通しやすいタスクは請負にし、不確実性の高いものは準委任にする、という意図でした。

しかし実際には、請負タスクの納期が近づくと、それが問答無用で最優先になります。すると、スプリント計画や日々の判断が、チームのビジョンから少しずつ離れていきます。ビジョンが意思決定の拠り所ではなくなり、優先順位が価値より契約に引っ張られてしまうのです。

この経験から、価値を軸に優先順位を変え続けたいチームでは、少なくとも請負と準委任の併用は避けるべきだと考えるようになりました。

チームをつくった後の技術の取り組み

体制としては、論理的にはワンチームですが、実態としては3社共同体制でした。もともと東京ガス側と外部のアプリ開発パートナーで育ててきた仕組みに、私たちが後から入る形です。その中で、会社をまたいでいても、どうすれば価値に貢献できるかを基準に動いていました。

このとき私が整理していた価値の軸は4つあります。

①課題解決に必要な技術的ケイパビリティを持っているか
②課題解決に必要なケイパビリティを摩擦なく発揮できているか
③課題と解決策の因果が正しいか
④解決策を受け取る人が認知し、採用してくれるか

重要なのは、この4つが掛け算だということです。どれかがゼロに近ければ、他を伸ばしても価値にはつながりません。良い課題を見つけても実装できなければ意味がないですし、高い技術力があっても課題とずれたことをしていては価値になりません。誰の課題も解決しないものを作っても駄目ですし、良いものでも使われなければ価値は出ません。だからこそ、フルサイクルで4つすべてを主体的にコントロールする意識が必要だと考えています。

可観測性の改善に取り組む

受付システムで、私たちが大きく期待され、自分たちも貢献したいと考えていたのは「信頼性の向上」でした。その中でも、可観測性の改善を重点的に進めました。

最初に見えてきたのは、システムオーナー（POチーム）が稼働状況を知りたがっている一方で、十分な情報を持てていないことでした。障害報告は役に立っていたものの、詳細情報が足りていませんでした。アプリチームもログ調査に時間をかけており、サーバーに入ってログを集めて確認するような運用が残っていました。データベースやゲートウェイのメトリクスまで含めて見ている人も多くありませんでした。私たちインフラチームも、信頼性を高めると言いながら、最初は情報がなくて何もできない状態でした。

そこで、フルスタックの可観測性ツールを導入しようと考えました。選定にあたっては、機能差よりもコストコントロールのしやすさを重視しました。予算や購買の調整に時間をかけ過ぎると、学習が犠牲になるからです。最終的にNew Relicを選んだのは、課金要素が比較的見通しやすく、段階的に始めやすかったからです。学習しながら優先度の高い課題から試していくには、この性質が合っていました。

アプリ側には、購入前から実機検証への協力をお願いし、ベンダー説明の場も用意しました。オーナーには製品特性や費用感を伝え、社内のセキュリティ審査は私たちで進めました。単にツールを入れるだけではなく、導入を成立させるための周辺業務まで引き受けました。

外形監視、APM、コンテナ化を進める

New Relic導入後、最初の課題は、サービスの稼働状態そのものが十分に見えていないことでした。アプリケーションエラーのアラートが来なければ正常だろう、という状態だったので、まずは外形監視（Synthetic）から始めました。ただ、監視対象の一覧すら整っておらず、ゲートウェイの設定情報やログを見ながらURLを洗い出すところからのスタートでした。

対象URLは100個以上あり、手作業で管理するのは現実的ではありませんでした。そこで、最初からTerraformで構造的に管理する方針を取りました。監視対象をIaCで管理し、可観測性の基盤そのものをコードで扱うようにしていきました。

その後、外形監視でサービス異常には気付きやすくなりましたが、アプリの不具合になると改善に貢献しづらい状況が残りました。そこでAPMの導入を本格的に進めました。ただ、導入時に一時的にサービスが止まることもあり、浸透は簡単ではありませんでした。業務調整をお願いしながら進める必要がありましたし、私たち自身もアプリの解像度が低かったので、まずはデータを見ながら理解し、ダッシュボードを作りながら学習していく形を取りました。

さらに、障害時にVM単位で何とかならないかと相談されても、APMを導入しただけでは切り分けが難しい状況でした。1台のVM上に10個以上のアプリが乗っている状況では、あるアプリの高負荷が原因でも、どこで何が起きているかを十分に分離できません。そこで、アプリ実行環境の分割を並行して進めました。

具体的には、ルーティングを分割し、アプリごとに段階移行できる構成へ準備しました。加えて、APMが最初から入ったコンテナのベースイメージを作り、それを利用してもらう形に変えていきました。アプリ側にとっても、デプロイ不具合やミドルウェアのバージョン管理といった課題があったため、コンテナ化は観測性だけでなく運用面の改善にもつながる判断でした。

私たち自身も、コンテナを配布可能な形で整備するには学習が必要でした。最初は慣れたRed Hat系の実装から始め、後から軽量でセキュアなDistrolessへ寄せていきました。

一気に広げるのではなく、小さく試して問題がなければ広げる方針で進め、デプロイ手順の変更についてもガイドを作りながら浸透を支援しました。

届け方まで含めて価値にする

コンテナ化とAPM導入が進み、ようやく情報が取れるようになってからは、次にそれをどう届けるかが課題になりました。New Relicのクエリ言語であるNRQLを各チームに直接書いてもらうのは敷居が高いため、ダッシュボードを提供する形を基本にしました。

オーナーには、ログインのエラー率など全体の健全性がひと目で分かるダッシュボードが好評でした。アプリ側には、ログを横断してトレースできる仕組みが好評で、調査が10倍ほど速くなったというコメントもいただきました。可観測性を高めるだけでなく、それが実際に使われる形で届いて初めて価値になる。その点でも、4つ目の軸はやはり重要だと感じています。

変化を振り返ると、プロダクト型のチームになり、貢献できることは自分たちで引き受けるようになりました。管理対象は基本的にIaCになり、コンテナ化も進み、可観測性も改善しました。インフラ観点での貢献が中心ではありますが、アプリの実行環境整備や変更のリードタイムは5分の1程度になり、定常運用のコストも下がりました。不具合発生時の改善アクションも、以前は組織の壁を越えて何時間もかかっていたものが、今では関係者がすぐ集まり、New Relicを見ながらその場で判断し、すぐ動けるようになっています。

オーナーから見た総合的な評価としては、信頼性向上だけでなく、結果的にビジネスアジリティにも貢献していると言っていただきました。象徴的だったのは、新システムへの大規模な切り替えです。関係者が100人以上いるような体制で、もしリスケになれば大きなコストが発生する状況でした。その中で問題を切り分けながら進められたこと自体が、十分な価値になったと評価してもらえています。

私自身の学びとしては、権限、責任、能力を集約したチームを作ることで、価値提供に直接つながりやすくなると実感しました。また、4つの価値軸を意識すると、どこがボトルネックかが見えやすくなります。そこへ集中していけばよい。結果として、従来とは違う価値を出せましたし、課題解決に向けた技術的な試行錯誤を楽しく続けられたと感じています。

最近考えていることと横展開の取り組み

最近は、この事例をどう横展開するか、生成AIが実務レベルで使える前提で何をアップデートすべきかを考えています。

横展開というと、どうしても標準化の話になりがちです。私も4つの価値軸に照らして、標準化がどこかを改善し、それが価値につながれば意味があると考えていました。しかし、私の所属組織に関して言えば、そこがほとんどつながっていませんでした。もともとサーバー構築と運用を担う組織であり、課題自体が変わっているのに、契約や文化は物理サーバー時代の延長線上にあるものが残っていたからです。技術標準を持ち込んでも、手段だけが先行し、価値への寄与は限定的になりやすいと感じました。

こうしたアウトプット思考の組織に技術標準を入れると何が起きるでしょうか。設計の根拠を聞くと、「標準通りにやりました」と言われたり、改善提案をすると「言われなかったので」と返ってくる場面が少なくありません。以前であれば、それでも人間の仕事として成立していたかもしれません。しかし、同じことをAIが言うなら、ストレスが少なくむしろその方が自然です。標準通り作る、スコープ外を勝手にやらない、といった役割はAIの方がうまくこなせる可能性があります。

だからこそ、横展開したいのは単なる技術How toではなく、価値提供の文化だと整理しています。契約を守ってアウトプットを出すだけの組織であれば、そこはAIとの競争で不利になります。そこで争うのではなく、価値提供側の文化へ更新していくべきです。その中でAIを活かした方が、はるかに建設的だと思っています。

組織文化の変革に向けた取り組み

実際に、私の組織でも図中の「②能力発揮度、③課題適合度、④ 到達・浸透度」に相当する部分には、マネジメントとして比較的介入しやすいと感じています。

たとえば、サーバー構築と運用をする組織から、信頼性に貢献するSRE的な方向へ全体方針を見直す。契約も、タスクをこなした量に応じたものから考え方ごと改める。受け身で仕事を待つのではなく、情報を公開し、自分たちから関与する。

構築と運用の間にある運用移管の儀式をなくし、体制を一体化してフルサイクル化する。手作業中心だった文化を改め、コードを前提とした環境整備と初期学習支援を進める。こうしたことには、組織として手を打ちやすい面があります。

技術的ケイパビリティの引き上げという難題

一方で、最も難しいのは1つ目の技術的ケイパビリティです。理解は本人にしかできないので、介入には限界があります。しかも生成AI以前は、オペレーター的に決まったアウトプットを出せる人にも価値がありました。しかし今後は、その前提が崩れていくはずです。求められる水準は上がり、人間には原理原則を理解し、自分で判断し、結果から学ぶことがより強く求められます。

ただ、これまでオペレーターとして育ってきた人の中には、自分で判断せずエスカレーションするよう訓練されてきた人もいます。そこは人によって痛みを伴う変化になると思います。だからこそ、作業者レベルにとどめないよう引き上げていく必要があります。短期的なスピードより理解を優先する。根拠を聞き、フィードバックする。指示を出し過ぎず、チームとして判断してもらう。AIも使えるようにしつつ、安直に答えを出させるのではなく、学習用途で活用してもらう。そうした運用を試しながら、組織として前に進めようとしています。

それでも、二極化はさらに進むと見ています。だからこそ、できる人のスキルをAgentにも適用できるようナレッジとして体系化し、組織の進歩につなげるかまで考えておく必要があります。そこを両にらみで進めるのが、今の課題です。

まとめ

改めて振り返ると、最初に向き合うべきは構造問題です。権限、責任、能力をワンチームにできるだけ集約し、契約やフェーズの枠を超えて価値に向き合える状態を作ることが土台になります。そのうえで、技術の観点では、技術的ケイパビリティ、摩擦なく発揮できる状態、課題と解決策の因果、採用される届け方という4つの軸を、主体的にコントロールしていく必要があります。

関係者との間で、価値の捉え方が合わない場面は実際にあります。計画を動かさないこと自体が価値になっている人もいます。そうしたときは、なるべく権限を持つ人に近い場所に入り、信頼を得て任せてもらうことが根本的な解決になると考えています。多重下請けの深い位置に入ってしまうと、正直かなり難しくなります。本当に価値にこだわりたいなら、自分が立つポジションを見直すことも選択肢だと思います。

4つの価値軸にたどり着いたのも、そうした現場経験の積み重ねからでした。特に4つ目の、相手に届いて採用されるかという観点は、社内プラットフォームのような仕事で、作っても使ってもらえない経験を重ねる中で意識するようになりました。社内であっても、マーケティングに近い発想がないと届きません。また、1つ目と2つ目を分けたのは、高い技術力があっても、置かれた環境に適合できなければ価値を出しづらい一方で、社内にいる人間はその環境理解を強みにできるはずだと考えているからです。

今後は、安直な技術標準を人間向けに広げるのではなく、価値提供の考え方そのものを広げることが大事になると思っています。AIによって少しでも時間が生まれるなら、その時間を理解のために使い、一歩踏み込んで判断し、答え合わせをする経験を増やしていきたいです。AIを前提にアンラーンしながら、価値提供に向けた試行錯誤の余地が大きく広がっている時代だと思うので、私はその変化を楽しみながら進んでいきたいと考えています。

最後に、価値提供に向けて一緒に試行錯誤してくれる仲間を募集しています！

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら

※動画の視聴にはFindyへのログインが必要です。