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

文化の狭間で、組織の「現実」を書き換える試行錯誤技術選定を突き詰める〜 Online Conference 2026 〜 (2026-02-26) 東京ガスｉネット株式会社
DX スペシャリスト部兼オープンインフラユニット村山　領（[email protected] ） © 2026 TOKYO GAS i NET CORP 1

自己紹介 : 村山領 2009 年に東京ガスi ネットに入社して以来、インフラ系エンジニアとしてキャリアを積んできた。サーバ仮想化、BCP 、クラウド（主にAzure
）、可観測性の取り組みを経て、直近は生成AI 活用をリード。怠け者気質ゆえ「楽できる技術」が大好物で、それを生み出すソフトウェアエンジニアにリスペクトを抱く。アジャイル、DevOps 、プロダクト志向のアプローチを好み、課題にこだわり、楽しみながら価値を生み出すことを大切にしている。 © 2026 TOKYO GAS i NET CORP 2

2024 年度より東京ガスi ネットは、グループ本社の一部門となりました。 © 2026 TOKYO GAS i
NET CORP 3

概要「技術選定」とは、解決したい課題とチームの状況を踏まえ、価値に向かうための意思決定だと考えています。価値を起点にしない技術選定では、優れた技術を採用しても、チームが価値貢献できないリスクがあります。エンタープライズ企業では、フェーズ分割や役割分断、短命なプロジェクト体制によって、価値を軸に技術選定すること自体が難しい場面があります。それでも、価値を軸に自律的に意思決定できるチームを作ることを諦めたくありません。本セッションでは、そうした制約の中で「価値につながる技術選定」をどう現場で成
立させようとしてきたか、その試行錯誤と学びを共有します。技術の力を、価値創出につながる形で発揮したい技術者のヒントになれば幸いです。 © 2026 TOKYO GAS i NET CORP 4

目次なぜ「価値を軸にした技術選定」が難しいのか 1 どうやって価値を軸に意思決定するチームを作ろうとしたか 2 どうやって価値を軸に技術を選定しようとしたか 3 最近やっていること・考えていること 4 まとめ
5 © 2026 TOKYO GAS i NET CORP 5

価値 = 誰かの課題を解決すること。（面積）課題解決策価値 © 2026 TOKYO
GAS i NET CORP 7

根底にあるもの：権限・責任・能力の不一致エンタープライズIT ではビジネス上の「権限」と最終的な「責任」は事業会社側にあるしかし、技術的判断能力は事業会社側に十分に蓄積されにくい非IT 専門人材への責任集中学習の余裕不足急な異動・ローテーション ©
2026 TOKYO GAS i NET CORP 9

権限・責任・能力の不一致が生むもの発注側技術判断の不確実性を回避する実行責任を外部に委ねる技術的妥当性よりも社内での説明可能性/ 容易性・監査耐性が優先される契約によって役割・責任・成果物を厳密に定義するフェーズを分割し、段階的に合意・
確認（検収）する受注側技術的能力はあるが、仕様決定権も事業責任も持てない契約順守を最優先とする、スコープ外を明確化する不確実性を伴う価値追求型提案は合理性を失う © 2026 TOKYO GAS i NET CORP 10

組織の現実：成果責任重視・フェーズ分割の結果 ✗ 開発担当者がCI パイプラインと自動テストを整備したが、維持管理担当から「複雑で運用できない」として破棄された ✗ インフラ構築担当がTerraform で環境を定義・実装したが、運用担当から「IaC では運用できないので手順書が必要」と受け入れを拒否された
🤔これらは「技術選定」の誤りなのか？問題は、フェーズや契約を超えた「価値」のオーナー不在 © 2026 TOKYO GAS i NET CORP 11

ジレンマ発注側ビジネス上の「権限」と最終的な「責任」を持つしかし、技術的判断の「能力」と「実感」は空洞化しやすい受注側技術的「能力」は持つしかし、仕様決定の「権限」も、事業結果への「責任」も持てない
双方とも合理的に行動している。しかし、価値からは分断されている。根本原因は権限・責任・能力の不一致にある。 © 2026 TOKYO GAS i NET CORP 12

2. どうやって価値を軸に意思決定するチームを作ろうとしたか権限・責任・能力の分断の辛さを味わった後のお話 © 2026 TOKYO GAS i NET CORP
13

どうすればいいのか？理想は？ ✨価値提供 ↑ 集中 🏢 ビジネス上の権限・責任・能力 💪 © 2026 TOKYO
GAS i NET CORP 14

基本方針権限・責任・能力を極力一か所に揃える。ビジネス上の権限と最終的な責任は動かせないので、技術者がそこに近寄る。 1 チームの仲間になることを目指す。（BizDevOps ）技術的判断の権限・責任は引き取りに行く。責任回避的なお伺いは禁止。 ▸ 企画・構築・運用といったフェーズ単位で、チームや責任を分断しない。
技術選定・設計判断に伴う運用負債や学習コストは、全て自分たちで引き受ける。 ▸ 静的な役割分担ではなく「貢献できるか？」で動く。従来の役割分担は、価値提供に向けては機能的でないことが多い。固執しない。 ▸ 請負契約は避ける。（準委任や派遣などを選ぶ） ▸ © 2026 TOKYO GAS i NET CORP 15

事業‧業務 ITシステム顧客課題解決（価値） ITの能⼒受注側責任‧権限発注側
契約 ITの能⼒受注側契約契約順守スコープ外は断る契約順守スコープ外は断る © 2026 TOKYO GAS i NET CORP 16

事業‧業務 ITシステム責任‧権限‧能⼒顧客課題解決（価値）どうしたら価値提供できるか？ ©

適用範囲最初から組織全体を変えようとはしない ▸ 自分たちが責任と権限を現実的に確保できる任せて貰えそうな領域に着目する ▸ ビジネス上の重要なプロダクトや課題を軸にすると、チームを維持しやすい ▸ 自分達の能力が相対的に優位だったら、思い切って取りに行く（学習は常にするもの。完璧になるまで待たない。そんな日は来ない。）
▸ © 2026 TOKYO GAS i NET CORP 18

実例：東京ガス受付システムへの参画 → 受付システムとは（例：ガス・電気の開始や停止のお手続き） © 2026 TOKYO GAS i
NET CORP 19

※2025 年6 ⽉時点の内容です © 2026 TOKYO GAS i NET CORP
20

21

22

受付システムの概要 80 種以上の受付、ガス・電気の受付に限ると15 種ピーク時のコールセンターでは約600 ブース稼働数時間停止すると、経済産業省への報告・是正が必要になる重要業務ガス‧電気の開始や停⽌ 25年1⽉に切り替え済
旧受付システム（約25年稼働）新受付システム（約5年稼働、徐々に成⻑）お客さまコールセンターお客さま Web受付電話受付電話受付 © 2026 TOKYO GAS i NET CORP 23

適用範囲 Q: 任せて貰えそうな領域？ A: オーナーがシステム経験者で現場感ある Q: ビジネス上の重要なプロダクトや課題？ A: システムに高い信頼性が必要（現在進行形）　20
年続いていた旧システムからの移行PJ が本格化（参画時、3 年ほど前の状況） Q: 相対的に優位？ A: 社内の共通基盤やクラウドインフラの知見で優位 © 2026 TOKYO GAS i NET CORP 24

最初にやったこと専任チーム（準委任契約）の提案をした。チームの存在意義やビジョン書いた。（インセプションデッキ）価値提供に向けた活動案を書いた。（PBL/PBI 、優先順位付け、楽観/ 悲観見積）スクラムを採用した。フェーズ分断の無いフルサイクル化。言ってしまえば割と教科書通り
© 2026 TOKYO GAS i NET CORP 25

過去の失敗談：請負と準委任の混在過去担当したプロダクトで、請負契約と準委任契約を同一チーム内で併用した。意図は、タスクや成果が予想できる部分は請負不確実性が高い部分は準委任という、理屈としてはよくある構成だった。 © 2026 TOKYO GAS
i NET CORP 26

実際に起きたこと 1 チーム内で両契約を使い分けすると、価値提供に向けたビジョンが形骸化する請負タスクは、納期が近づくと最優先になる 1 日々の判断がビジョンと乖離していく 2 ビジョンが意思決定の拠り所ではなくなる 3 ©

学んだこと ✗ チームの優先順は、掲げた価値よりも「契約違反」に強く引っ張られる ✗ 請負契約の範囲は「必達」、ビジョンに書いた価値提供は「余裕次第」になる ✓ 価値を軸に優先順を変え続けたいチームでは、請負契約は避ける必要がある ※チームで決めたビジョンより、会社間の契約の方が強かった。　言われてみれば当たり前だが、実害を経験したことでリアリティを持って語れるようになった。
　請負契約を避けるために、成果責任なし（善管注意義務のみ）でも安心してもらえる信頼関係を醸成しましょう。 © 2026 TOKYO GAS i NET CORP 28

3. どうやって価値を軸に技術を選定しようとしたか「成果物責任に縛られないチーム」を立ち上げた後のお話 © 2026 TOKYO GAS i NET CORP
29

3 社協働体制での価値貢献事業‧業務 ITシステム責任‧権限‧能⼒顧客課題解決（価値） POチーム
※東京ガスアプリチーム ※パートナー企業インフラチーム ※東京ガスｉネットどうしたら貢献できるか？ © 2026 TOKYO GAS i NET CORP 30

価値提供 = ①技術ケイパ × ②能力発揮度 × ③課題適合度 × ④到達・浸透度 ①技術ケイパ
課題解決に必要な能力を持っているか。・IT/ ドメイン知識・経験、抽象化・構造化、技術・ツール習熟等 ②能力発揮度課題解決に必要なケイパビリティを摩擦なく発揮できているか。・社内ルール、承認プロセス、技術・ツール導入、心理的安全性等 ③課題適合度課題と解決策の因果が正しいか。・誰のどんな痛みか（解像度）、なぜ発生するか（構造）の理解等 ④到達・浸透度解決策を受け取る人が認知し、採用してくれるか。・チームの信頼貯金、導入・運用時の判断・説明コストの低さ等補足: 本来は「③課題適合」や「④到達・浸透」に向けた能力もケイパビリティ。　　　しかしエンプラでは技術ケイパビリティのみが切り離され評価・調達がちなので、あえて①として独立。 © 2026 TOKYO GAS i NET CORP 31

価値は4 要素の掛け算どれかが0 に近いと、他を伸ばしても無意味。 ①技術ケイパ　　解決策を実装できなければ価値ゼロ ②能力発揮度　　雑務ばかりしていたら価値ゼロ ③課題適合度　　誰の課題も解決しないモノを作っても価値ゼロ
④到達・浸透度　使われなければ価値ゼロフルサイクルで①～④すべてを主体的にコントロールする意識を持たないと、価値提供に繋がらない。 © 2026 TOKYO GAS i NET CORP 32

①課題を探る POチームアプリチームインフラチーム ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度 ‧システムの稼働実態を知りたがっていそう。（Azureポータルでメトリック⾒てた）
‧障害が起きたときの報告に苦慮していそう。（説明はしてくれているが、詳細情報が⾜りてない） ‧アプリログ調査に時間がかかっていそう（サーバにログインしてログ収集→調査してた） ‧アプリ以外（ブラウザ、DB、ゲートウェイなど）のメトリックやログを読めてる⼈は少なそう（調査時、インフラチーム側で⾒ることが多い） ‧システムの信頼性を⾼めたいが、あまりにも情報が⾜りない。 ‧どんなサービス、アプリがあるのかわからない。エラーやパフォーマンスの状況も把握しようが無い。 ‧アプリチームに聞きまくるのも申し訳ない。 ⇒フルスタックなオブザーバビリティツールが欲しい © 2026 TOKYO GAS i NET CORP 34

②解決策の検討 POチームアプリチームインフラチーム ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度 ‧オブザーバビリティツールを導⼊したいが、予算‧購買など費⽤⾯に時間を掛けると、技術⾯の学習が進まない。 ⇒New
Relicなら過剰コストを回避でき、費⽤も予測しやすい ‧APMやRUM系ツールの導⼊には、アプリチームの協⼒が不可⽋。 ⇒購⼊前の実機検証を協⼒頂く ⇒製品ベンダからの説明の場を⽤意 ‧インフラ監視の知⾒しかないので、フルスタックツールの価値を引き出すには習熟に時間を取る必要がある。 ⇒New Relic なら優先課題に適したものから、段階的に学習しやすい ‧費⽤対効果や製品選定の妥当性を説明するための情報が必要なはず。 ⇒製品のマーケットポジションや概算⾒積を共有 ‧社内のセキュリティチェックが⼤変 ⇒資料はインフラチームで作成 © 2026 TOKYO GAS i NET CORP 35

③New Relic 導入初期 POチームアプリチームインフラチーム ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度
‧規模が⼤きいので⼿作業ではNew Relic設定を管理しきれない。 ⇒Terraformで構造的に管理するために試⾏錯誤の時間を確保 ‧サービスの稼働状況を把握できていない。（アプリログにエラーが出⼒されず、アラートが来なければ正常？） ⇒外形監視（Synthetic）から導⼊ ‧サービスやアプリの⼀覧が無いので、ヘルスチェックしようにも、宛先がわからない。 ⇒ヘルスチェック先の候補を、Gatewayの構成情報やログなどから収集 © 2026 TOKYO GAS i NET CORP 36

④次の課題 POチームアプリチームインフラチーム ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度 ‧サービスの異常には気付けるようになったが、その後の調査や改善に貢献できていない。 ⇒システムの信頼性向上に貢献するには、アプリに関する情報が⾜りてない
⇒APMを導⼊して情報を収集する ‧APM導⼊時にサービスの⼀時停⽌がある。 ⇒業務調整も頂きながら、段階導⼊（結構⾯倒） ‧アプリ運⽤の勘所が無い。 ⇒APMのデータを⾒てダッシュボード作りながら学習 © 2026 TOKYO GAS i NET CORP 37

⑤更に次の課題 POチームアプリチームインフラチーム ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度 ‧APMを導⼊してみたが、VM上に10以上のアプリが混在している状況では切り分け困難。 ⇒アプリ実⾏環境の分割と、APM導⼊を並⾏して進める
⇒ルーティング分割（/* → VMだった。アプリ毎に段階移⾏できるように変更） ⇒APM導⼊済みコンテナベースイメージの提供 ‧デプロイ時の不具合がしばしば発⽣。 ‧ミドルウェアバージョンアップが困難。（環境分割やコンテナ化の需要はあった） ‧いきなりのアーキ変更は⼼配。 ⇒新規モノでお試し、段階適⽤ ‧デプロイ⼿順が変わる。 ⇒開発者向けガイド整備‧公開 ‧ベースイメージ提供にあたり、学習が必要。 ⇒まずは慣れてるRedHat系で実装 ⇒その後Distrolessへ © 2026 TOKYO GAS i NET CORP 38

⑥アプリの情報取れるようになった後 POチームアプリチームインフラチーム ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度 ‧New Relicのクエリ書いてもらうのは敷居⾼い
⇒ダッシュボード提供全体概要を把握できるものが好評 ‧New Relicのクエリ書いてもらうのは敷居⾼い ⇒ダッシュボード提供アプリ横断でログをTrace出来るものが好評 © 2026 TOKYO GAS i NET CORP 39

当初からの変化観点 Before After チーム組成プロジェクトチーム（有期）プロダクトチーム（解散しない）業務範囲サーバ設計・構築貢献できるなら、なんでも
（ただし優先順には拘る） IaC 範囲構築のみ自動化全てコードで恒久的に管理（原則）アプリ実行環境 VM 上にゴチャっと 1 アプリ1 環境（コンテナ化）観測範囲サーバOS 上の情報のみシステム全体（概ね）不具合時サーバ動作確認全体を見て被疑箇所絞り込みキャパシティ増やして/ 減らしてと言われたら対応業務的な処理量を見ながら随時調整 © 2026 TOKYO GAS i NET CORP 40

価値約 1/5 アプリ実行環境整備・変更のリードタイムアーキテクチャのパターン化・IaC に加え、案件化・システム変更レビューのリードタイム短縮
約 2/5 定型運用コストアーキテクチャのパターン化・IaC 前提運用約 1/5 不具合発生 → 改善アクション開始までの時間 New Relic を軸にした OODA の加速 © 2026 TOKYO GAS i NET CORP 41

追加の価値提供 - リモートでの開発・維持管理環境の整備 - プロダクト横断的なモニタリング、スケーリング・障害対応・恒久対策のリード - ライフサイクル管理、バージョンアップ計画の立案、モダナイズ推進総合評価（オーナーより）システムの信頼性が高まり、ビジネスアジリティの向上にも寄与軽微なエラーは発生するものの、迅速に検知して影響をコントロールできており、信頼を損
なわずに施策を推進できている。 © 2026 TOKYO GAS i NET CORP 42

学び権限・責任・能力を集約したチームを作ることで、価値提供に向けて協働できる。価値を軸に思考すると、自然にネックが見えてくる。そこに集中すれば良い。結果として、契約順守に最適化していた頃とは比較にならない価値を出せた。課題解決に向けた技術的な試行錯誤は学習効率が高い。なにより楽しい！！ © 2026 TOKYO GAS i
NET CORP 43

標準化は価値に繋がるのか？標準化？事業‧業務 ITシステム顧客課題解決（価値）どの要素に、どのように貢献する？
どう繋がる？ナレッジの提供元標準の適⽤先となるチーム ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度 © 2026 TOKYO GAS i NET CORP 46

そもそも、価値提供と接続されているのか？標準化？事業‧業務 ITシステム顧客課題解決（価値）誰でも出来る⼿順？すぐに使えるIaC？
⇒⼿段だけの更新になってしまわないか？ナレッジ提供元標準の適⽤先となるチーム（アウトプット思考） ①技術ケイパ ②能⼒発揮度 ③契約順守本当に価値に繋がっているのか？これまで提供してきた解決策は、今も有効なのか？ © 2026 TOKYO GAS i NET CORP 47

アウトプット思考の組織に技術標準を提供する？作業者思考の⼈上⼿く動きません。どうしたらいいですか。設計根拠は「標準通り」です。それはスコープ外です。⾔われなかったので。この進め⽅で承認頂けますか。
上⼿く動きません。どうしたらいいですか。設計根拠は「標準通り」です。それはスコープ外です。⾔われなかったので。この進め⽅で承認頂けますか。 Coding Agent AI やってもらう方がよっぽど健全。（知識豊富、スケール、指示に即応、観測容易） © 2026 TOKYO GAS i NET CORP 48

横展開したいのは、価値提供の文化新組織（アウトカム思考） ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度 ①技術ケイパ ②能⼒発揮度 ③契約順守
従来組織（アウトプット思考）⽣成AI ここでAIと争わないナレッジ提供元このモデルのまま強化しない価値提供の⽂化に更新したいこれにナレッジを活かす © 2026 TOKYO GAS i NET CORP 49

自組織に展開中 ②～④の大枠は比較的マネジメントが介入しやすい。新組織（アウトカム思考） ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度ナレッジ展開元
‧受け⾝、都度相談 ⇒ポータル整備 ⇒全社周知 ‧ 「サーバ構築」と「サーバ運⽤」をやる組織 ⇒貢献⽅針‧契約‧業務範囲‧⽬標などの更新 ‧体制の分断と受け渡しによるロス ⇒体制変更（合流、フルサイクル化） ‧運⽤は⼿オペ⽂化 ⇒環境整備や初期学習の⽀援（WSL2, Git, Terraform, LLM...） © 2026 TOKYO GAS i NET CORP 50

技術ケイパがネックになる ①技術ケイパの向上が一番ムズイ。「理解」は本人しかできない。（介入しにくい）生成AI 以前は、決まったアウトプットを出せるだけでも価値があった。今後、人間には「原理原則の理解」「判断」「結果責任を負う覚悟」が求められる。
新組織（アウトカム思考） ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度ナレッジ提供元 ‧作業者レベルからの引き上げ ⇒短期的なスピードより理解優先 ⇒判断の根拠を聞く、フィードバックする ⇒推奨は出すが、判断はチームに委ねる ⇒学習⽤途でのAI利⽤を推奨する ⇒どうせ2極化するので、早々にAgent Skillsを育てる枠組みを作ったほうが良い説（保留中） © 2026 TOKYO GAS i NET CORP 51

まとめ構造問題に挑む権限・責任・能力を1 チームに集約し、契約の枠を超えて「価値」に向き合う。技術選定の軸価値提供 = ①技術ケイパ × ②能力発揮度
× ③課題適合度 × ④到達・浸透度フルサイクルで①～④すべてを主体的にコントロールする意識を持つ。今後の展望安易な「技術標準」ではなく「価値創出の文化」を広げる。「理解のための時間」と「判断＆答え合わせの経験」を増やすことで技術ケイパを磨く。（とはいえ、おそらく2 極化の進行は避けられない。） AI 前提でアンラーンしながら、価値提供に向けた試行錯誤を楽しみたい！ © 2026 TOKYO GAS i NET CORP 53

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

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

More Decks by ファインディ株式会社（イベント資料アップ用）

Other Decks in Technology

Featured

Transcript