DevOpsDays2026 Tokyo Cross-border practices to connect "safety" and "DX" in healthcare

by Yutaro Sugai

Embed

Start on current slide

Slide 1

Slide 1 text

共通言語と現場への共感で歩む：医療の「安全」と「DX」を繋ぐための越境の実践株式会社I-Style 取締役CTO 菅井祐太朗

Slide 2

Slide 2 text

What is it? 現場での楽しく泥臭い負債解消で信頼を築き、共通言語を武器に医療業務の核心とセキュリティへ切り込んでいった実践の記録

Slide 3

Slide 3 text

アジェンダ • 自己紹介 • 医療現場の実情とDXの壁 (10分) • 実践：現場の「負」を解消する泥臭い並走 (10分) • 越境の技術：ドメインの言語を習得する (10分) • 汎用化：あらゆる困難なDXへの応用 (5分) • まとめ

Slide 4

Slide 4 text

菅井祐太朗 Yutaro SUGAI id: hokkai7go 株式会社I-Style取締役CTO 一般社団法人LOCAL理事スクラムマスター 2児の父 Rubyが好き

Slide 5

Slide 5 text

キャリアのサマリ • SEからSRE • メーカー系SEからWebインフラエンジニアへ • Chef実践入門を共著で執筆 • 株式会社はてなでSREとして共通基盤インフラの開発、保守、運用 • SREチームでのスクラムの実践 • 技術系経営者 • 2021年4月より現職 • 情シス支援、クラウド移行支援案件で難易度の高い部分を担当 • プログラミングによる自動化、クラウドのインターコネクト等 • 医療情報技師

Slide 6

Slide 6 text

Slide 7

Slide 7 text

医療現場の実情とDXの壁 • 背景 • 情報システム部門を支援していた医療系企業が医療法人を買収 • 都内某所の無床診療所 • 支援依頼があり我々も参加することに • IT理解のある経営層が相手だったため、説明の苦労は少なめで済んだ • 規模感: クリニックで病床なし、NW機器やサーバ合わせて20台以上 • MRIとCTがある • クリニックの情報システム担当が退職することが決まっていた • 現場の調査を行い、リスクアセスメントから開始することに

Slide 8

Slide 8 text

医療現場の実情とDXの壁 • 医療とDX • DX(デジタルトランスフォーメーション) • 「企業が、ビッグデータなどのデータとAIやIoTを始めとするデジタル技術を活用して、業務プロセスを改善していくだけでなく、製品やサービス、ビジネスモデルそのものを変革するとともに、組織、企業文化、風土をも改革し、競争上の優位性を確立すること。」1) • 医療DX • 「医療DXとは、保健・医療・介護の各段階（疾病の発症予防、受診、診察・治療・薬剤処方、診断書等の作成、診療報酬の請求、医療介護の連携によるケア、地域医療連携、研究開発など）において発生する情報やデータを、全体最適された基盤（クラウドなど）を通して、保健・医療や介護関係者の業務やシステム、データ保存の外部化・共通化・標準化を図り、国民自身の予防を促進し、より良質な医療やケアを受けられるように、社会や生活の形を変えることです。」2) 1)野村総合研究所(NRI).用語解説|DX(デジタルトランスフォーメーション). https://www.nri.com/jp/knowledge/glossary/dx.html, (参照 2026-04-01) 2)厚生労働省.医療DXについて.https://www.mhlw.go.jp/stf/iryoudx.html,(参照 2026-04-01)

Slide 9

Slide 9 text

医療現場の実情とDXの壁 • 案件開始時の惨状（リスクアセスメントの結果）

Slide 10

Slide 10 text

医療現場の実情とDXの壁 • 案件開始時の惨状このケーブルは結局どこにも接続されてなかった… 無駄、管理されていない様子を表す象徴

Slide 11

Slide 11 text

医療現場の実情とDXの壁 • 案件開始時の惨状 • リスクアセスメントの結果 • 正確な機器台帳やネットワーク図なし • 詳細不明のPC・端末がある（用途不明、長期未利用） • 保守なしで壊れかかっていても使われ続けるIT機器（PC・NW機器）が多数ある • 踏まれて千切れそうになっているLANケーブルがある • 院内ネットワークは毎日不調の報告あり • 各サーバの監視なし

Slide 12

Slide 12 text

医療現場の実情とDXの壁どうしてここまで放置されていたのだろうか

Slide 13

Slide 13 text

医療現場の実情とDXの壁 • ガイドライン遵守と、独自の予算形成・業務プロセスの理解 • 医療機関の収入は国が定める点数で決まるため（診療報酬制度）、IT 活用で売上を伸ばすのが難しい構造となっている • そのためIT投資というより、ITのコストと捉えられる

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

医療現場の実情とDXの壁 • ガイドライン遵守と、独自の予算形成・業務プロセスの理解 • 3省2ガイドラインへの準拠は必須だが、それ自体が収益を生むわけではないため、後回しにされやすい • 補足: 3省2ガイドライン: 厚生労働省・経済産業省・総務省が策定した「医療情報システムの安全管理に関するガイドライン」の総称のこと。これに基づき立入検査が行われる。違反があれば改善指導が行われ、違反自体に罰則はないものの、情報漏洩などの事故発生時には問題視される。 https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html • 医療情報システムへの2要素認証など技術的な要求も盛り込まれている • ガイドライン等の理想を実現するためのコストは普通に医療機関を経営していると確保しにくい • 継ぎ足して場当たり的に補修(IT投資)していると中身の伴わないハリボテとなる →ガイドラインへの準拠に取り組む前に惨状の改善を最優先（業務停止を防ぐため）することとなった

Slide 16

Slide 16 text

日本医師会.「第24回医療経済実態調査報告ー令和５年度実施ー」について. https://www.med.or.jp/dl-med/teireikaiken/20231220b.pdf, (参照 2026-04-01)

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

医療情報システムの安全管理に関するガイドライン • 概説編 13ページ • 経営管理編 26ページ • 企画管理編 65ページ • システム運用編 58ページ

Slide 20

Slide 20 text

医療情報システムの安全管理に関するガイドライン • 第6.0版 • サマリ • 経営層の責任の明確化 • ゼロトラストの考え方を導入 • 非常時の診療継続性（BCP） • 技術的安全管理策（例） • 医療情報システムに多要素認証導入 • 特権ID管理 • EDR等エンドポイント対策 • ログの収集と監視 • オフラインバックアップ

Slide 21

Slide 21 text

医療現場の実情とDXの壁 • ガイドライン遵守と、独自の予算形成・業務プロセスの理解 • 場当たり的に継ぎ足しのIT投資が行われていた • 開院時（10年以上前）に導入した機器（保守切れ）が現役で利用されていた • 場当たり的にシステムや機器が継ぎ足し購入されていた • 電子カルテが2システム並行運用されていた（旧カルテは患者ID採番用として残り続けている • バックアップ用NASが2つあるがリストア手順は見当たらない • 家庭用Wi-Fiルータが複数存在し、SSIDはバラバラ

Slide 22

Slide 22 text

医療現場の実情とDXの壁 • ガイドライン遵守と、独自の予算形成・業務プロセスの理解 • IT機器だけでなく、業務プロセスも複雑に入り組んでおり整理が難しい • 現場のプロセス理解はITの現状理解よりも難しく、時間がかかる • 全体を把握している人がいなかった • 各職種（ドクター、医事課、技師、看護師等）の動きや他院とのやり取りや、各業務のタイムラインも把握する必要があり理解が難しい • データの分断 • 医師による所見は電子カルテではなくFileMakerにあり、データが分断されている • 電子カルテは2システム並行運用 • 現場ヒアリングの限界 • 電話の外線と内線の管理をしているPBXの利用実態把握に苦労した。誰も全体像と管理について理解していなかったため長い間手探り状態が続いた

Slide 23

Slide 23 text

Slide 24

Slide 24 text

実践：現場の「負」を解消する泥臭い並走 • 三本立て • LANケーブル整理とネットワーク図の作成 • ネットワーク不調とパケットキャプチャによる調査 • 停電後のサーバ障害とMWM連携停止、起動不可となったサーバのディスクからのデータ救出

Slide 25

Slide 25 text

実践：現場の「負」を解消する泥臭い並走現場作業は楽しい現場に行かないとわからないことがたくさんある

Slide 26

Slide 26 text

LANケーブル整理とネットワーク図の作成 • 着手した理由 • 業務停止リスクが高く、不調により現場の困り度が大きいネットワークの整理から着手することになった • Before • 当初機器台帳が無く、情報量が足りないネットワーク図だけがあった • ファンが壊れているサポート切れのL3スイッチがあった • ケーブルに付与されているタグに記載された文字列のルールが不明だった • LANケーブルは一部断線の可能性があり、配線は複雑かつ不要なものも多数あった

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

LANケーブル整理とネットワーク図の作成 • After • 複数のサーバーラックと床下を調査し、各LANケーブルと機器接続の現状を確認し、タグに記載された文字列のルールを解明した • 不要なLANケーブルやL2スイッチ、無線LANルーターを撤去した • ファンが壊れているサポート切れのL3スイッチを入れ替えた。コンフィグレベルで院内ネットワークを把握、コントロールすることに成功した • ネットワークを図示し、NetBoxによる機器構成管理を開始した

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

ネットワーク不調とパケットキャプチャによる調査 • Before • 当初から院内ネットワークの不調が頻発すると聞いていた • PCから電子カルテやORCA（医事会計システム）が見えたり見えなかったり • Pingを打てば治ることもある • しかし原因は謎

Slide 32

Slide 32 text

ネットワーク不調とパケットキャプチャによる調査 • After • LANケーブル整理をする中でネットワーク不調の領域が絞り込めた • 各サブネットへ接続する調査用Linuxサーバを稼働開始したことで、任意のサブネット内でパケットキャプチャ可能となった • 接続関係の調査と図示、パケットキャプチャによる原因調査を経て問題の機器を特定し撤去した。5ヶ月で大きな問題は改善された • 意図せずセグメント間をブリッジしていたWi-Fiルータを特定 • セグメントAのARPリクエストに対し、このWi-Fiルータが「そのIPのMACアドレスは私だ」と嘘の応答を返してしまっていた • 常駐であればもっと早く原因調査から対処まで完了できたであろう（休診日のたびに訪問し楽しい現地調査を繰り返していたので時間がかかった）

Slide 33

Slide 33 text

ネットワーク不調とパケットキャプチャによる調査 A系セグメントの医療画像システムARPリクエストに対し、 Wi-Fiルータが「そのIPのMACアドレスは私だ」と応答を返してしまっていた (実際はWi-FiルータはセグメントB

Slide 34

Slide 34 text

ネットワーク不調とパケットキャプチャによる調査 • 原因不明でもきちんと一つずつ調べると徐々に理解度が上がり解決できる • 不要なものを撤去し、調査で全体と詳細を把握することで見通しが良くなった • 不調のタイミングや領域にパターンがあることがわかり、機器や設定と照らし合わせることができた • 図示することで現場やステークホルダーとの会話もしやすくなった • パケットキャプチャのおかげで不調の根本原因までたどり着けた

Slide 35

Slide 35 text

ネットワーク不調とパケットキャプチャによる調査 • 振り返り • ネットワークやPC管理のアンチパターンが複数判明 • 院内のフロア間でループしていたがL3スイッチでブロックしてることが判明した • USBでNIC増設しているPCが複数ありドライバの問題で他のPCに移設できないし、そもそもなぜノートPCが複数NICもっているのか不明… • セグメント間をブリッジしているスイッチが複数存在していたとみられ、スイッチに接続すると意図していたセグメント以外につながってしまう問題があった • 作業責任を持ってくれるステークホルダーの存在が大きかった • 調査を重ねても機器交換や回線を抜く作業は怖さがあった • 俺が責任持つから、その作業やってくれと常に言ってもらえていた

Slide 36

Slide 36 text

停電後のサーバ障害とMWM連携停止、起動不可となったサーバのディスクからのデータ救出 • 法定停電後いくつかのサーバが起動不可となった • 原因が電源と判明し、電源の入れ替えなどを試すも起動させることはできなかった • FileMaker（院内DB） • このクリニックではFileMakerに医師による所見が入っており、これが停止すると患者に検査結果説明ができない • RIS（放射線科システム） • MWM (Modality Worklist Management): 電子カルテ上の患者情報を、検査機器（CTやMRIなど）へ自動転送する仕組みのこと。これが停止すると手入力による取り違えリスクが発生するため、医療安全における極めて重要な連携ポイントとなる。

Slide 37

Slide 37 text

停電後のサーバ障害とMWM連携停止、起動不可となったサーバのディスクからのデータ救出 • データ救出の試み • FileMaker（院内DB） • 電源ユニット交換試したがサーバ復旧せず • バックアップサーバから無事にデータ復旧できた • RIS（放射線科システム） • USBブートのLinuxからディスク(SAS)のデータ救出を試したがデバイス認識されず断念 • 後述のMWMサーバ構築PoCへ続く

Slide 38

Slide 38 text

停電後のサーバ障害とMWM連携停止、起動不可となったサーバのディスクからのデータ救出

Slide 39

Slide 39 text

停電後のサーバ障害とMWM連携停止、起動不可となったサーバのディスクからのデータ救出 • MWMサーバ構築PoC • コンテナ用仮想マシンを構築 • 検証用にMWMサーバの仕組み（コンテナ）を構築 • 予約カレンダーから当日撮影のある患者IDを取得（未実装） • RubyスクリプトでORCA（医事会計システム）から患者情報を取得して、DICOM Worklistファイルの元ファイルを生成し共有Volumeに配置 • 補足: • DICOM:（国際標準規格の医用画像・転送プロトコル） • DICOM Worklistファイル: テキストファイルからdump2dcmコマンド(DCMTK)でバイナリのDICOMファイル(.wl)に変換でき、後述のOrthancが利用 • OrthancというオープンソースのDICOMサーバが共有VolumeからDICOMワークリストファイルを読み込みモダリティ（MRIやCTのこと）からのワークリスト取得に応答できるようになる • https://www.orthanc-server.com/ • 補足: 2025/11でOrthancのSample Modality Worklists pluginがlegacyとなり、Worklists pluginが新登場した。REST APIでworklist作れるようで2025/8にPoCしていたときよりも便利になっている

Slide 40

Slide 40 text

停電後のサーバ障害とMWM連携停止、起動不可となったサーバのディスクからのデータ救出

Slide 41

Slide 41 text

停電後のサーバ障害とMWM連携停止、起動不可となったサーバのディスクからのデータ救出

Slide 42

Slide 42 text

停電後のサーバ障害とMWM連携停止、起動不可となったサーバのディスクからのデータ救出 • 何が大変だったのか • 相談相手がいない • ORCA（医事会計システム）の画面操作が難しくテスト用データ準備に時間がかかった • モダリティ（MRIやCTのこと）の接続先変更に多額の費用が発生するため断念することとなった • プログラムの動作を確認するために実環境で試して判明した • 技術だけではどうにもならないときがある。医療分野ならではの壁とぶつかった。ハードウェアとソフトウェアの境界で制約が多いとわかった • ORCA（医事会計システム）のAPIから情報取得するコードは後日、請求情報の集計・分析に生かされた。遠回りではあったが、トライした価値は高いと評価してもらえた

Slide 43

Slide 43 text

停電後のサーバ障害とMWM連携停止、起動不可となったサーバのディスクからのデータ救出 • 振り返り • 調査検証用にミニPC購入したのがよかった • NW調査、MWM用など仮想マシン上で複数役割で活躍 • DICOMの一部詳細や、MWMについての知識と実装理解が得られた • DICOMについてドキュメントを読解し社内に知見をまとめられた • DICOMのデータ構造や各ヘッダーについては事前に知っていたが、具体的にソフトウェアで処理する経験を積むことができた • ORCA（医事会計システム）の運用やAPIについての知識が得られた • 検証用ORCAを事前に作っておいて良かった • 医療情報システムをプログラムから操作できると実感できた • サーバの監視を導入できた

Slide 44

Slide 44 text

実践：現場の「負」を解消する泥臭い並走 • まとめ • 問題について一つずつ泥臭く丁寧に調査を続けた • 医療の現場でもSREスキルが活きた • ネットワークやサーバの基本的な知識が活きた • 医療情報システムやDICOMをプログラムで扱うことができた • 医療の現場で必要な知識のキャッチアップについては後述する • 当たり前だが機器の保守は大事 • ここまでで紹介した泥臭い並走は保守があればすべて発生していないはず • ITの当たり前（機器は保守あり、壊れた機器はすぐに入れ替える）をもたらすだけでマイナスを1くらいにレベルアップできる • 地方の中小クリニックも似たような状況になっているところが多いのではないかと推測される

Slide 45

Slide 45 text

Slide 46

Slide 46 text

越境 • 越境とは “何らかの意味で定められている境界を越えて移動すること。” • ここでの越境は、”元SREの技術系経営者による医療の現場への越境” と定義します

Slide 47

Slide 47 text

医療情報技師取得医療情報技師とは補足: 日本医療情報学会が認定する民間資格であり「医学・医療」「情報処理技術」「医療情報システム」の3領域の知識を問われる専門資格で合格率は約35-40%前後。取得には3ヶ月程度の学習を要した。受験記 https://blog.hokkai7go.jp/entry/2023/10/05/163330

Slide 48

Slide 48 text

医療情報技師取得なぜ取得したか • IT技術を社会に適用していくことに元々興味があり、その中でも医療に対して興味があった • 会社として新規事業展開を考えるためお役立ちポイント • 現場の医療情報システムの概要を素早く細部まで把握するための基礎知識として役立った

Slide 49

Slide 49 text

NCIP修了 NCIPとは名古屋医療情報学プログラム “医療情報ならびにそのシステム開発に関する人材育成を目的としたリスキリング/リカレント教育のプログラムです。すでに愛知県と行っている専攻医教育のプログラムである「東海医療情報学社会医学系専門医研修プログラム」を拡充する形で、有料のプログラムを追加し、医療IT教育のリスキリング教育を充実させることを目的としています。 NCIPは、全てWebの講義を予定しており、国内の専門家集団による医療情報に関する体系的・網羅的な知識の習得を目指し、「概要」と「実践」の2つからなる講義体系を形成しています。”

Slide 50

Slide 50 text

NCIP修了なぜ受講したか • 医療情報関係の案件を開始したが、現場で使える知識と技術が不足していたためお役立ちポイント • 実は現在発表中のクリニック支援案件には直接役立っていない • しかしこの案件でぶつかった課題について議論できる人々との人脈ができたことが一番良かった点 • 学んだ内容は広くて深い。今の現場ですぐに使える内容を学んだわけではない • 周囲にはこの分野に興味関心のある人は少なく、自分は興味関心が尽きないことがわかった。今後もこの分野での情報収集と発信を続けていこうと思えた • 自己学習が仕事の機会をつくる

Slide 51

Slide 51 text

越境の技術：ドメインの言語を習得する • 医療情報技師取得とNCIP受講どちらも目的は資格や修了証ではなく共通言語を得ること • 医療分野の参入障壁は高いが、このハードルを超えるために利用した • 相手のドメイン（医学・医療管理）を尊重した議論ができるようになった • 医療現場や経営層の苦しみが以前より理解できるようになった • ITコンサルティング案件での動き方「顧客の課題感を理解して、先回りして情報提供や問題提起を行う」と大きく変わらない

Slide 52

Slide 52 text

越境の技術組織は意思決定しない、意思決定は人がする。

Slide 53

Slide 53 text

越境の技術 https://soudai.hatenablog.com/entry/2025/11/20/152139

Slide 54

Slide 54 text

越境の技術壁や境界を強く意識せず、人を意識する。あちら側と線を引くと精神的に越境しにくくなる

Slide 55

Slide 55 text

越境の技術知りたいという気持ちは枠からはみだし、壁を壊して、越境を促進する（自分事にすること）

Slide 56

Slide 56 text

越境の技術信頼を勝ち取り、ステークホルダーとの良好な関係性の維持発展を継続的に考え実践する

Slide 57

Slide 57 text

Slide 58

Slide 58 text

汎用化：あらゆる困難なDXへの応用 • 医療現場への越境は楽しく、ITエンジニアとしてのやりがいが多かった。ITの技術を武器にして他の領域に越境していくことをおすすめする • SRE経験が越境のやり方を教えてくれた • class SRE implements DevOps • 運用と開発の壁を壊し、共通の目標に向かって協力するというDevOpsの思想がまずベースにあり、 • サイト信頼性制御のために部門や職種を超えて対話(越境)が必要なSREingを経験することで越境の技術が身についていった • 越境を恐れない • 境界線を跨いで仕事することで困難を乗り越えることができる。境界線の中にこもると仕事のレベルが下がる可能性がある

Slide 59

Slide 59 text

汎用化：あらゆる困難なDXへの応用 • 「全体像を知ること」と、「技術的な詳細の深堀り」両方やることが大事 • マクロとミクロ • POWERS OF TEN https://youtu.be/mUSGjAm6XkA?si=Oi-HzCNq8wEGZKQt • （今回の例）経営者やスクラムマスターとしての全体像を持ちつつ、 SRE経験を活かして現場でパケットまで追う • なぜ両方やるのが大事なのか？ • 現場で実際に起きている問題の全体像と具体的な解決策を同時に把握することができるため、両者のズレをなくすことができる • 経営的な意思決定（投資）のための会話に他の人を挟む必要がなくなる

Slide 60

Slide 60 text

チャールズ&レイ・イームズ事務所. ”Powers of Ten”. YouTube, May 27, 2009. https://www.youtube.com/watch?v=mUSGjAm6XkA, (参照 2026-04-06)

Slide 61

Slide 61 text

チャールズ&レイ・イームズ事務所. ”Powers of Ten”. YouTube, May 27, 2009. https://www.youtube.com/watch?v=mUSGjAm6XkA, (参照 2026-04-06)

Slide 62

Slide 62 text

汎用化：あらゆる困難なDXへの応用 • 学び続けることで共通言語を増やし、現場や経営層と近い視点で物事を見られるようにする • 自分の専門性の外にある領域について興味を持ち、調べ、学ぶ • 自分の専門性の領域についての研鑽は行っている前提 • キャリアパス上、次に見えている職責について学ぶことは有用 • エンジニアならマネージャー、VPoE、CTOなど

Slide 63

Slide 63 text

汎用化：あらゆる困難なDXへの応用 • 「小さく始める」ことの戦略的価値と、他業界への転用可能性について • 今回の例では、大きく投資せずとも改善できた • 調査用のミニPCやLANケーブル購入程度 • 小さな成功が大きな投資への後押しになる • あとからコードや技術的トライが生きることがある • プログラムの再利用性、あとから続く人に情報を残せる • システムの内部的な構造や仕様についての深い理解につながる • 現場に行くことや、手を動かすの大事 • 他業界（工場等）のネットワークでも似たことができそう • ドキュメントは古くなるため、現場での現物確認が大事

Slide 64

Slide 64 text

汎用化：あらゆる困難なDXへの応用医療現場で行ったこと他業界への転用本質的な価値パケット解析での不調原因特定工場のセンサー通信等の安定化事実に基づく現状把握医療情報技師の資格取得業界特有の法規制・商習慣の学習共通言語獲得による信頼構築 Ruby/コンテナでのPoC断念既存設備のAPI連携の可否検討投資判断のリードタイム短縮踏まれた配線の整理現場の整理整頓とITの統合物理層からの信頼性向上

Slide 65

Slide 65 text

汎用化：あらゆる困難なDXへの応用 • 泥臭い仕事が現場のDXを推進する。また、現場や経営層からの信頼につながる

Slide 66

Slide 66 text

Slide 67

Slide 67 text

まとめ • まとめの前に現在の状況 • Wi-Fiアクセスポイント入れ替え • PACS導入 • PACS (Picture Archiving and Communication System): CT、MRI、レントゲンなどの撮影画像を保存、管理するシステムのこと。これまでは保守の切れたワークステーションを使い続けていた • 惨状の改善が終わり、ようやくガイドラインへの準拠に取り組む準備ができたところ • 自分不在でも現場で改善サイクルが回り始めた • 属人化から解放された？そもそも改善する担当がいなかった

Slide 68

Slide 68 text

まとめ • 現場作業は楽しい。現場でしかわからないことがたくさんある • 問題について一つずつ泥臭く丁寧に調査を続けるとよい • 当たり前だが機器の保守は大事なので、ケチらないで • 共通言語は越境の武器なので知識習得への投資を惜しまない • 「全体像を知ること」と、「技術的な詳細の深堀り」両方大事 • 越境の技術：知りたいという気持ちは枠からはみだし、壁を壊して、越境を促進する（自分事にすること） • 自分のIT技術をどのドメインのために使うのか。その現場への好奇心が越境やDXの源泉になる