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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

Slide 53

Slide 53 text

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