Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.

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

2026/2/26開催『技術選定を突き詰める Online Conferenc​​e 2026』(https://findy.connpass.com/event/380974/)の登壇資料です

■東京ガスiネット株式会社 DXスペシャリスト部 兼 オープンインフラユニット 村山 領さん

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

Other Decks in Technology

Transcript

  1. 自己紹介 : 村山 領 2009 年に東京ガスi ネットに入社して以来、インフラ系エンジニア としてキャリアを積んできた。 サーバ仮想化、BCP 、クラウド(主にAzure

    ) 、可観測性の取り組み を経て、直近は生成AI 活用をリード。 怠け者気質ゆえ「楽できる技術」が大好物で、それを生み出すソフ トウェアエンジニアにリスペクトを抱く。 アジャイル、DevOps 、プロダクト志向のアプローチを好み、課題 にこだわり、楽しみながら価値を生み出すことを大切にしている。 © 2026 TOKYO GAS i NET CORP 2
  2. 権限・責任・能力の不一致が生むもの 発注側 技術判断の不確実性を回避する 実行責任を外部に委ねる 技術的妥当性よりも社内での説明可 能性/ 容易性・監査耐性が優先される 契約によって役割・責任・成果物を 厳密に定義する フェーズを分割し、段階的に合意・

    確認(検収)する 受注側 技術的能力はあるが、仕様決定権も 事業責任も持てない 契約順守を最優先とする、スコープ 外を明確化する 不確実性を伴う価値追求型提案は合 理性を失う © 2026 TOKYO GAS i NET CORP 10
  3. 基本方針 権限・責任・能力を極力一か所に揃える。 ビジネス上の権限と最終的な責任は動かせないので、技術者がそこに近寄る。 1 チームの仲間になることを目指す。 (BizDevOps ) 技術的判断の権限・責任は引き取りに行く。責任回避的なお伺いは禁止。 ▸ 企画・構築・運用といったフェーズ単位で、チームや責任を分断しない。

    技術選定・設計判断に伴う運用負債や学習コストは、全て自分たちで引き受ける。 ▸ 静的な役割分担ではなく「貢献できるか?」で動く。 従来の役割分担は、価値提供に向けては機能的でないことが多い。固執しない。 ▸ 請負契約は避ける。 (準委任や派遣などを選ぶ) ▸ © 2026 TOKYO GAS i NET CORP 15
  4. 事業‧業務 ITシステム 顧客 課題 解決 (価値) ITの能⼒ 受注側 責任‧権限 発注側

    契約 ITの能⼒ 受注側 契約 契約順守 スコープ外は断る 契約順守 スコープ外は断る © 2026 TOKYO GAS i NET CORP 16
  5. 受付システムの概要 80 種以上の受付、ガス・電気の受付に限ると15 種 ピーク時のコールセンターでは 約600 ブース稼働 数時間停止すると、経済産業省への報告・是正が必要になる重要業務 ガス‧電気の開始や停⽌ 25年1⽉に切り替え済

    旧受付システム (約25年稼働) 新受付システム (約5年稼働、徐々に成⻑) お客さま コールセンター お客さま Web受付 電話受付 電話受付 © 2026 TOKYO GAS i NET CORP 23
  6. 適用範囲 Q: 任せて貰えそうな領域? A: オーナーがシステム経験者で現場感ある Q: ビジネス上の重要なプロダクトや課題? A: システムに高い信頼性が必要(現在進行形)  20

    年続いていた旧システムからの移行PJ が本格化(参画時、3 年ほど前の状況) Q: 相対的に優位? A: 社内の共通基盤やクラウドインフラの知見で優位 © 2026 TOKYO GAS i NET CORP 24
  7. 3 社協働体制での価値貢献 事業‧業務 ITシステム 責任‧権限‧能⼒ 顧客 課題 解決 (価値) POチーム

    ※東京ガス アプリチーム ※パートナー企業 インフラチーム ※東京ガスiネット どうしたら 貢献できるか? © 2026 TOKYO GAS i NET CORP 30
  8. 価値提供 = ①技術ケイパ × ②能力発揮度 × ③課題適合度 × ④到達・浸透度 ①技術ケイパ

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

    ④到達・浸透度   使われなければ価値ゼロ フルサイクルで①~④すべてを主体的にコントロールする意識を持たないと、価値提 供に繋がらない。 © 2026 TOKYO GAS i NET CORP 32
  10. ①課題を探る POチーム アプリチーム インフラチーム ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度 ‧システムの稼働実態を知りたがっていそう。 (Azureポータルでメトリック⾒てた)

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

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

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

    ⇒APMを導⼊して情報を収集する ‧APM導⼊時にサービスの⼀時停⽌がある。 ⇒業務調整も頂きながら、段階導⼊(結構⾯倒) ‧アプリ運⽤の勘所が無い。 ⇒APMのデータを⾒てダッシュボー ド作りながら学習 © 2026 TOKYO GAS i NET CORP 37
  14. ⑤更に次の課題 POチーム アプリチーム インフラチーム ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度 ‧APMを導⼊してみたが、VM上に10以上のアプリが混在している状況では切り分け困難。 ⇒アプリ実⾏環境の分割と、APM導⼊を並⾏して進める

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

    ⇒ダッシュボード提供 全体概要を把握できるものが好評 ‧New Relicのクエリ書いてもらうのは敷居⾼い ⇒ダッシュボード提供 アプリ横断でログをTrace出来るものが好評 © 2026 TOKYO GAS i NET CORP 39
  16. 当初からの変化 観点 Before After チーム組成 プロジェクトチーム(有期) プロダクトチーム(解散しない) 業務範囲 サーバ設計・構築 貢献できるなら、なんでも

    (ただし優先順には拘る) IaC 範囲 構築のみ自動化 全てコードで恒久的に管理(原則) アプリ実行環境 VM 上にゴチャっと 1 アプリ1 環境(コンテナ化) 観測範囲 サーバOS 上の情報のみ システム全体(概ね) 不具合時 サーバ動作確認 全体を見て被疑箇所絞り込み キャパシティ 増やして/ 減らしてと言われたら対応 業務的な処理量を見ながら随時調整 © 2026 TOKYO GAS i NET CORP 40
  17. 価値 約 1/5 アプリ実行環境整備・ 変更のリードタイム アーキテクチャのパターン 化・IaC に加え、案件化・ システム変更レビューのリ ードタイム短縮

    約 2/5 定型運用コスト アーキテクチャのパターン 化・IaC 前提運用 約 1/5 不具合発生 → 改善アク ション開始までの時間 New Relic を軸にした OODA の加速 © 2026 TOKYO GAS i NET CORP 41
  18. 標準化は価値に繋がるのか? 標準化? 事業‧業務 ITシステム 顧客 課題 解決 (価値) どの要素に、 どのように貢献する?

    どう繋がる? ナレッジの 提供元 標準の適⽤先 となるチーム ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度 © 2026 TOKYO GAS i NET CORP 46
  19. そもそも、価値提供と接続されているのか? 標準化? 事業‧業務 ITシステム 顧客 課題 解決 (価値) 誰でも出来る⼿順? すぐに使えるIaC?

    ⇒⼿段だけの更新になってしまわないか? ナレッジ 提供元 標準の適⽤先 となるチーム (アウトプット思考) ①技術ケイパ ②能⼒発揮度 ③契約順守 本当に価値に繋がっているのか? これまで提供してきた解決策は、今も有効なのか? © 2026 TOKYO GAS i NET CORP 47
  20. アウトプット思考の組織に技術標準を提供する? 作業者思考の⼈ 上⼿く動きません。 どうしたらいいですか。 設計根拠は 「標準通り」です。 それはスコープ外です。 ⾔われなかったので。 この進め⽅で 承認頂けますか。

    上⼿く動きません。 どうしたらいいですか。 設計根拠は 「標準通り」です。 それはスコープ外です。 ⾔われなかったので。 この進め⽅で 承認頂けますか。 Coding Agent AI やってもらう方がよっぽど健全。 (知識豊富、スケール、指示に即応、観測容易) © 2026 TOKYO GAS i NET CORP 48
  21. 横展開したいのは、価値提供の文化 新組織 (アウトカム思考) ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度 ①技術ケイパ ②能⼒発揮度 ③契約順守

    従来組織 (アウトプット思考) ⽣成AI ここでAIと 争わない ナレッジ 提供元 このモデルのまま 強化しない 価値提供の⽂化 に更新したい これにナレッジを活かす © 2026 TOKYO GAS i NET CORP 49
  22. 自組織に展開中 ②~④の大枠は比較的マネジメントが介入しやすい。 新組織 (アウトカム思考) ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度 ナレッジ 展開元

    ‧受け⾝、都度相談 ⇒ポータル整備 ⇒全社周知 ‧ 「サーバ構築」と「サーバ運⽤」をやる組織 ⇒貢献⽅針‧契約‧業務範囲‧⽬標などの更新 ‧体制の分断と受け渡しによるロス ⇒体制変更(合流、フルサイクル化) ‧運⽤は⼿オペ⽂化 ⇒環境整備や初期学習の⽀援 (WSL2, Git, Terraform, LLM...) © 2026 TOKYO GAS i NET CORP 50
  23. 技術ケイパがネックになる ①技術ケイパ の向上が一番ムズイ。 「理解」は本人しかできない。 (介入しにくい) 生成AI 以前は、決まったアウトプットを出せるだけでも価値があった。 今後、人間には「原理原則の理解」 「判断」 「結果責任を負う覚悟」が求められる。

    新組織 (アウトカム思考) ①技術ケイパ ②能⼒発揮度 ③課題適合度 ④到達‧浸透度 ナレッジ 提供元 ‧作業者レベルからの引き上げ ⇒短期的なスピードより理解優先 ⇒判断の根拠を聞く、フィードバックする ⇒推奨は出すが、判断はチームに委ねる ⇒学習⽤途でのAI利⽤を推奨する ⇒どうせ2極化するので、 早々にAgent Skillsを育てる 枠組みを作ったほうが良い説 (保留中) © 2026 TOKYO GAS i NET CORP 51
  24. まとめ 構造問題に挑む 権限・責任・能力を1 チームに集約し、契約の枠を超えて「価値」に向き合う。 技術選定の軸 価値提供 = ①技術ケイパ × ②能力発揮度

    × ③課題適合度 × ④到達・浸透度 フルサイクルで①~④すべてを主体的にコントロールする意識を持つ。 今後の展望 安易な「技術標準」ではなく「価値創出の文化」を広げる。 「理解のための時間」と「判断&答え合わせの経験」を増やすことで技術ケイパを磨く。 (とはいえ、おそらく2 極化の進行は避けられない。 ) AI 前提でアンラーンしながら、価値提供に向けた試行錯誤を楽しみたい! © 2026 TOKYO GAS i NET CORP 53