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

https://confengine.com/conferences/devopsdays-tokyo-2026/proposal/49597/dx
の発表資料です

Transcript

1. 共通言語と現場への共感で歩む： 医療の「安全」と「DX」を 繋ぐための越境の実践 株式会社I-Style 取締役CTO 菅井祐太朗
2. What is it? 現場での楽しく泥臭い負債解消で信頼を築き、共通言語を武器に 医療業務の核心とセキュリティへ切り込んでいった実践の記録
3. アジェンダ • 自己紹介 • 医療現場の実情とDXの壁 (10分) • 実践：現場の「負」を解消する泥臭い並走 (10分) • 越境の技術：ドメインの言語を習得する (10分) • 汎用化：あらゆる困難なDXへの応用 (5分) • まとめ
4. 菅井 祐太朗 Yutaro SUGAI id: hokkai7go 株式会社I-Style取締役CTO 一般社団法人LOCAL理事 スクラムマスター 2児の父 Rubyが好き
5. キャリアのサマリ • SEからSRE • メーカー系SEからWebインフラエンジニアへ • Chef実践入門を共著で執筆 • 株式会社はてなでSREとして共通基盤インフラの開発、保守、運用 • SREチームでのスクラムの実践 • 技術系経営者 • 2021年4月より現職 • 情シス支援、クラウド移行支援案件で難易度の高い部分を担当 • プログラミングによる自動化、クラウドのインターコネクト等 • 医療情報技師
6. アジェンダ • 自己紹介 • 医療現場の実情とDXの壁 (10分) • 実践：現場の「負」を解消する泥臭い並走 (10分) • 越境の技術：ドメインの言語を習得する (10分) • 汎用化：あらゆる困難なDXへの応用 (5分) • まとめ
7. 医療現場の実情とDXの壁 • 背景 • 情報システム部門を支援していた医療系企業が医療法人を買収 • 都内某所の無床診療所 • 支援依頼があり我々も参加することに • IT理解のある経営層が相手だったため、説明の苦労は少なめで済んだ • 規模感: クリニックで病床なし、NW機器やサーバ合わせて20台以上 • MRIとCTがある • クリニックの情報システム担当が退職することが決まっていた • 現場の調査を行い、リスクアセスメントから開始することに
8. 医療現場の実情と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)
9. 医療現場の実情とDXの壁 • 案件開始時の惨状（リスクアセスメントの結果）
10. 医療現場の実情とDXの壁 • 案件開始時の惨状 このケーブルは結局 どこにも接続されてなかった… 無駄、管理されていない様子を表す象徴
11. 医療現場の実情とDXの壁 • 案件開始時の惨状 • リスクアセスメントの結果 • 正確な機器台帳やネットワーク図なし • 詳細不明のPC・端末がある（用途不明、長期未利用） • 保守なしで壊れかかっていても使われ続けるIT機器（PC・NW機器）が多数ある • 踏まれて千切れそうになっているLANケーブルがある • 院内ネットワークは毎日不調の報告あり • 各サーバの監視なし
12. 医療現場の実情とDXの壁 どうしてここまで放置されていたのだろうか
13. 医療現場の実情とDXの壁 • ガイドライン遵守と、独自の予算形成・業務プロセスの理解 • 医療機関の収入は国が定める点数で決まるため（診療報酬制度）、IT 活用で売上を伸ばすのが難しい構造となっている • そのためIT投資というより、ITのコストと捉えられる
15. 医療現場の実情とDXの壁 • ガイドライン遵守と、独自の予算形成・業務プロセスの理解 • 3省2ガイドラインへの準拠は必須だが、それ自体が収益を生むわけではない ため、後回しにされやすい • 補足: 3省2ガイドライン: 厚生労働省・経済産業省・総務省が策定した「医療情報シ ステムの安全管理に関するガイドライン」の総称のこと。これに基づき立入検査が行 われる。違反があれば改善指導が行われ、違反自体に罰則はないものの、情報漏洩な どの事故発生時には問題視される。 https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html • 医療情報システムへの2要素認証など技術的な要求も盛り込まれている • ガイドライン等の理想を実現するためのコストは普通に医療機関を経営して いると確保しにくい • 継ぎ足して場当たり的に補修(IT投資)していると中身の伴わないハリボテとなる →ガイドラインへの準拠に取り組む前に惨状の改善を最優先（業務停止を防ぐ ため）することとなった
16. 日本医師会.「第24回医療経済実態調査報告ー令和５年度実施ー」について. https://www.med.or.jp/dl-med/teireikaiken/20231220b.pdf, (参照 2026-04-01)
19. 医療情報システムの安全管理に関するガイドライン • 概説編 13ページ • 経営管理編 26ページ • 企画管理編 65ページ • システム運用編 58ページ
20. 医療情報システムの安全管理に関するガイドライン • 第6.0版 • サマリ • 経営層の責任の明確化 • ゼロトラストの考え方を導入 • 非常時の診療継続性（BCP） • 技術的安全管理策（例） • 医療情報システムに多要素認証導入 • 特権ID管理 • EDR等エンドポイント対策 • ログの収集と監視 • オフラインバックアップ
21. 医療現場の実情とDXの壁 • ガイドライン遵守と、独自の予算形成・業務プロセスの理解 • 場当たり的に継ぎ足しのIT投資が行われていた • 開院時（10年以上前）に導入した機器（保守切れ）が現役で利用されていた • 場当たり的にシステムや機器が継ぎ足し購入されていた • 電子カルテが2システム並行運用されていた（旧カルテは患者ID採番用として残り続 けている • バックアップ用NASが2つあるがリストア手順は見当たらない • 家庭用Wi-Fiルータが複数存在し、SSIDはバラバラ
22. 医療現場の実情とDXの壁 • ガイドライン遵守と、独自の予算形成・業務プロセスの理解 • IT機器だけでなく、業務プロセスも複雑に入り組んでおり整理が難し い • 現場のプロセス理解はITの現状理解よりも難しく、時間がかかる • 全体を把握している人がいなかった • 各職種（ドクター、医事課、技師、看護師等）の動きや他院とのやり取りや、各業務 のタイムラインも把握する必要があり理解が難しい • データの分断 • 医師による所見は電子カルテではなくFileMakerにあり、データが分断されている • 電子カルテは2システム並行運用 • 現場ヒアリングの限界 • 電話の外線と内線の管理をしているPBXの利用実態把握に苦労した。誰も全体像と管 理について理解していなかったため長い間手探り状態が続いた
23. アジェンダ • 自己紹介 • 医療現場の実情とDXの壁 (10分) • 実践：現場の「負」を解消する泥臭い並走 (10分) • 越境の技術：ドメインの言語を習得する (10分) • 汎用化：あらゆる困難なDXへの応用 (5分) • まとめ
24. 実践：現場の「負」を解消する泥臭い並走 • 三本立て • LANケーブル整理とネットワーク図の作成 • ネットワーク不調とパケットキャプチャによる調査 • 停電後のサーバ障害とMWM連携停止、起動不可となったサーバの ディスクからのデータ救出
25. 実践：現場の「負」を解消する泥臭い並走 現場作業は楽しい 現場に行かないとわからない ことがたくさんある
26. LANケーブル整理とネットワーク図の作成 • 着手した理由 • 業務停止リスクが高く、不調により現場の困り度が大きいネットワー クの整理から着手することになった • Before • 当初機器台帳が無く、情報量が足りないネットワーク図だけがあった • ファンが壊れているサポート切れのL3スイッチがあった • ケーブルに付与されているタグに記載された文字列のルールが不明 だった • LANケーブルは一部断線の可能性があり、配線は複雑かつ不要なもの も多数あった
28. LANケーブル整理とネットワーク図の作成 • After • 複数のサーバーラックと床下を調査し、各LANケーブルと機器接続の 現状を確認し、タグに記載された文字列のルールを解明した • 不要なLANケーブルやL2スイッチ、無線LANルーターを撤去した • ファンが壊れているサポート切れのL3スイッチを入れ替えた。コン フィグレベルで院内ネットワークを把握、コントロールすることに成 功した • ネットワークを図示し、NetBoxによる機器構成管理を開始した
31. ネットワーク不調とパケットキャプチャによる調査 • Before • 当初から院内ネットワークの不調が頻発すると聞いていた • PCから電子カルテやORCA（医事会計システム）が見えたり見えなかったり • Pingを打てば治ることもある • しかし原因は謎
32. ネットワーク不調とパケットキャプチャによる調査 • After • LANケーブル整理をする中でネットワーク不調の領域が絞り込めた • 各サブネットへ接続する調査用Linuxサーバを稼働開始したことで、任 意のサブネット内でパケットキャプチャ可能となった • 接続関係の調査と図示、パケットキャプチャによる原因調査を経て問 題の機器を特定し撤去した。5ヶ月で大きな問題は改善された • 意図せずセグメント間をブリッジしていたWi-Fiルータを特定 • セグメントAのARPリクエストに対し、このWi-Fiルータが「そのIPのMACアド レスは私だ」と嘘の応答を返してしまっていた • 常駐であればもっと早く原因調査から対処まで完了できたであろう（休診日のた びに訪問し楽しい現地調査を繰り返していたので時間がかかった）
33. ネットワーク不調とパケットキャプチャによる調査 A系セグメントの医療画像システムARPリクエストに対し、 Wi-Fiルータが「そのIPのMACアドレスは私だ」と応答を返してしまっていた (実際はWi-FiルータはセグメントB
34. ネットワーク不調とパケットキャプチャによる調査 • 原因不明でもきちんと一つずつ調べると徐々に理解度が上がり 解決できる • 不要なものを撤去し、調査で全体と詳細を把握することで見通しが良 くなった • 不調のタイミングや領域にパターンがあることがわかり、機器や設定 と照らし合わせることができた • 図示することで現場やステークホルダーとの会話もしやすくなった • パケットキャプチャのおかげで不調の根本原因までたどり着けた
35. ネットワーク不調とパケットキャプチャによる調査 • 振り返り • ネットワークやPC管理のアンチパターンが複数判明 • 院内のフロア間でループしていたがL3スイッチでブロックしてることが判明した • USBでNIC増設しているPCが複数ありドライバの問題で他のPCに移設できない し、そもそもなぜノートPCが複数NICもっているのか不明… • セグメント間をブリッジしているスイッチが複数存在していたとみられ、スイッ チに接続すると意図していたセグメント以外につながってしまう問題があった • 作業責任を持ってくれるステークホルダーの存在が大きかった • 調査を重ねても機器交換や回線を抜く作業は怖さがあった • 俺が責任持つから、その作業やってくれと常に言ってもらえていた
36. 停電後のサーバ障害とMWM連携停止、起動不可となっ たサーバのディスクからのデータ救出 • 法定停電後いくつかのサーバが起動不可となった • 原因が電源と判明し、電源の入れ替えなどを試すも起動させる ことはできなかった • FileMaker（院内DB） • このクリニックではFileMakerに医師による所見が入っており、これが停止する と患者に検査結果説明ができない • RIS（放射線科システム） • MWM (Modality Worklist Management): 電子カルテ上の患者情報を、検査機器 （CTやMRIなど）へ自動転送する仕組みのこと。これが停止すると手入力によ る取り違えリスクが発生するため、医療安全における極めて重要な連携ポイント となる。
37. 停電後のサーバ障害とMWM連携停止、起動不可となっ たサーバのディスクからのデータ救出 • データ救出の試み • FileMaker（院内DB） • 電源ユニット交換試したがサーバ復旧せず • バックアップサーバから無事にデータ復旧できた • RIS（放射線科システム） • USBブートのLinuxからディスク(SAS)のデータ救出を試したがデバイス認識さ れず断念 • 後述のMWMサーバ構築PoCへ続く
38. 停電後のサーバ障害とMWM連携停止、起動不可となっ たサーバのディスクからのデータ救出
39. 停電後のサーバ障害と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していたときよりも 便利になっている
40. 停電後のサーバ障害とMWM連携停止、起動不可となっ たサーバのディスクからのデータ救出
41. 停電後のサーバ障害とMWM連携停止、起動不可となっ たサーバのディスクからのデータ救出
42. 停電後のサーバ障害とMWM連携停止、起動不可となっ たサーバのディスクからのデータ救出 • 何が大変だったのか • 相談相手がいない • ORCA（医事会計システム）の画面操作が難しくテスト用データ準備 に時間がかかった • モダリティ（MRIやCTのこと）の接続先変更に多額の費用が発生する ため断念することとなった • プログラムの動作を確認するために実環境で試して判明した • 技術だけではどうにもならないときがある。医療分野ならではの壁とぶつかった。 ハードウェアとソフトウェアの境界で制約が多いとわかった • ORCA（医事会計システム）のAPIから情報取得するコードは後日、請求情報の 集計・分析に生かされた。遠回りではあったが、トライした価値は高いと評価し てもらえた
43. 停電後のサーバ障害とMWM連携停止、起動不可となっ たサーバのディスクからのデータ救出 • 振り返り • 調査検証用にミニPC購入したのがよかった • NW調査、MWM用など仮想マシン上で複数役割で活躍 • DICOMの一部詳細や、MWMについての知識と実装理解が得られた • DICOMについてドキュメントを読解し社内に知見をまとめられた • DICOMのデータ構造や各ヘッダーについては事前に知っていたが、具体的にソ フトウェアで処理する経験を積むことができた • ORCA（医事会計システム）の運用やAPIについての知識が得られた • 検証用ORCAを事前に作っておいて良かった • 医療情報システムをプログラムから操作できると実感できた • サーバの監視を導入できた
44. 実践：現場の「負」を解消する泥臭い並走 • まとめ • 問題について一つずつ泥臭く丁寧に調査を続けた • 医療の現場でもSREスキルが活きた • ネットワークやサーバの基本的な知識が活きた • 医療情報システムやDICOMをプログラムで扱うことができた • 医療の現場で必要な知識のキャッチアップについては後述する • 当たり前だが機器の保守は大事 • ここまでで紹介した泥臭い並走は保守があればすべて発生していないはず • ITの当たり前（機器は保守あり、壊れた機器はすぐに入れ替える）を もたらすだけでマイナスを1くらいにレベルアップできる • 地方の中小クリニックも似たような状況になっているところが多いのではないか と推測される
45. アジェンダ • 自己紹介 • 医療現場の実情とDXの壁 (10分) • 実践：現場の「負」を解消する泥臭い並走 (10分) • 越境の技術：ドメインの言語を習得する (10分) • 汎用化：あらゆる困難なDXへの応用 (5分) • まとめ
46. 越境 • 越境とは “何らかの意味で定められている境界を越えて移動すること。” • ここでの越境は、”元SREの技術系経営者による医療の現場への 越境” と定義します
47. 医療情報技師取得 医療情報技師とは 補足: 日本医療情報学会が認定する民間資格であり「医学・医療」「情報処 理技術」「医療情報システム」の3領域の知識を問われる専門資格で合格率 は約35-40%前後。取得には3ヶ月程度の学習を要した。 受験記 https://blog.hokkai7go.jp/entry/2023/10/05/163330
48. 医療情報技師取得 なぜ取得したか • IT技術を社会に適用していくことに元々興味があり、その中で も医療に対して興味があった • 会社として新規事業展開を考えるため お役立ちポイント • 現場の医療情報システムの概要を素早く細部まで把握するため の基礎知識として役立った
49. NCIP修了 NCIPとは 名古屋医療情報学プログラム “医療情報ならびにそのシステム開発に関する人材育成を目的としたリスキリング/リ カレント教育のプログラムです。 すでに愛知県と行っている専攻医教育のプログラム である「東海医療情報学社会医学系専門医研修プログラム」を拡充する形で、有料の プログラムを追加し、医療IT教育のリスキリング教育を充実させることを目的として います。 NCIPは、全てWebの講義を予定しており、国内の専門家集団による医療情報 に関する体系的・網羅的な知識の習得を目指し、「概要」と「実践」の2つからなる講 義体系を形成しています。”
50. NCIP修了 なぜ受講したか • 医療情報関係の案件を開始したが、現場で使える知識と技術が不足してい たため お役立ちポイント • 実は現在発表中のクリニック支援案件には直接役立っていない • しかしこの案件でぶつかった課題について議論できる人々との人脈ができたことが 一番良かった点 • 学んだ内容は広くて深い。今の現場ですぐに使える内容を学んだわけではない • 周囲にはこの分野に興味関心のある人は少なく、自分は興味関心が尽きな いことがわかった。今後もこの分野での情報収集と発信を続けていこうと 思えた • 自己学習が仕事の機会をつくる
51. 越境の技術：ドメインの言語を習得する • 医療情報技師取得とNCIP受講どちらも目的は資格や修了証では なく共通言語を得ること • 医療分野の参入障壁は高いが、このハードルを超えるために利用した • 相手のドメイン（医学・医療管理）を尊重した議論ができるように なった • 医療現場や経営層の苦しみが以前より理解できるようになった • ITコンサルティング案件での動き方「顧客の課題感を理解して、 先回りして情報提供や問題提起を行う」と大きく変わらない
52. 越境の技術 組織は意思決定しない、意思決定は人がする。
53. 越境の技術 https://soudai.hatenablog.com/entry/2025/11/20/152139
54. 越境の技術 壁や境界を強く意識せず、人を意識する。 あちら側と線を引くと精神的に越境しにくく なる
55. 越境の技術 知りたいという気持ちは枠からはみだし、 壁を壊して、越境を促進する （自分事にすること）
56. 越境の技術 信頼を勝ち取り、ステークホルダーとの良好 な関係性の維持発展を継続的に考え実践する
57. アジェンダ • 自己紹介 • 医療現場の実情とDXの壁 (10分) • 実践：現場の「負」を解消する泥臭い並走 (10分) • 越境の技術：ドメインの言語を習得する (10分) • 汎用化：あらゆる困難なDXへの応用 (5分) • まとめ
58. 汎用化：あらゆる困難なDXへの応用 • 医療現場への越境は楽しく、ITエンジニアとしてのやりがいが多 かった。ITの技術を武器にして他の領域に越境していくことをおす すめする • SRE経験が越境のやり方を教えてくれた • class SRE implements DevOps • 運用と開発の壁を壊し、共通の目標に向かって協力するというDevOpsの思 想がまずベースにあり、 • サイト信頼性制御のために部門や職種を超えて対話(越境)が必要なSREingを 経験することで越境の技術が身についていった • 越境を恐れない • 境界線を跨いで仕事することで困難を乗り越えることができる。境界線の中 にこもると仕事のレベルが下がる可能性がある
59. 汎用化：あらゆる困難なDXへの応用 • 「全体像を知ること」と、「技術的な詳細の深堀り」両方やる ことが大事 • マクロとミクロ • POWERS OF TEN https://youtu.be/mUSGjAm6XkA?si=Oi-HzCNq8wEGZKQt • （今回の例）経営者やスクラムマスターとしての全体像を持ちつつ、 SRE経験を活かして現場でパケットまで追う • なぜ両方やるのが大事なのか？ • 現場で実際に起きている問題の全体像と具体的な解決策を同時に把握することが できるため、両者のズレをなくすことができる • 経営的な意思決定（投資）のための会話に他の人を挟む必要がなくなる
60. チャールズ&レイ・イームズ事務所. ”Powers of Ten”. YouTube, May 27, 2009. https://www.youtube.com/watch?v=mUSGjAm6XkA, (参照 2026-04-06)
61. チャールズ&レイ・イームズ事務所. ”Powers of Ten”. YouTube, May 27, 2009. https://www.youtube.com/watch?v=mUSGjAm6XkA, (参照 2026-04-06)
62. 汎用化：あらゆる困難なDXへの応用 • 学び続けることで共通言語を増やし、現場や経営層と近い視点 で物事を見られるようにする • 自分の専門性の外にある領域について興味を持ち、調べ、学ぶ • 自分の専門性の領域についての研鑽は行っている前提 • キャリアパス上、次に見えている職責について学ぶことは有用 • エンジニアならマネージャー、VPoE、CTOなど
63. 汎用化：あらゆる困難なDXへの応用 • 「小さく始める」ことの戦略的価値と、他業界への転用可能性 について • 今回の例では、大きく投資せずとも改善できた • 調査用のミニPCやLANケーブル購入程度 • 小さな成功が大きな投資への後押しになる • あとからコードや技術的トライが生きることがある • プログラムの再利用性、あとから続く人に情報を残せる • システムの内部的な構造や仕様についての深い理解につながる • 現場に行くことや、手を動かすの大事 • 他業界（工場等）のネットワークでも似たことができそう • ドキュメントは古くなるため、現場での現物確認が大事
64. 汎用化：あらゆる困難なDXへの応用 医療現場で行ったこと 他業界への転用 本質的な価値 パケット解析での不調原因特定 工場のセンサー通信等の安定化 事実に基づく現状把握 医療情報技師の資格取得 業界特有の法規制・商習慣の学 習 共通言語獲得による信頼構築 Ruby/コンテナでのPoC断念 既存設備のAPI連携の可否検討 投資判断のリードタイム短縮 踏まれた配線の整理 現場の整理整頓とITの統合 物理層からの信頼性向上
65. 汎用化：あらゆる困難なDXへの応用 • 泥臭い仕事が現場のDXを推進する。また、現場や経営層からの 信頼につながる
66. アジェンダ • 自己紹介 • 医療現場の実情とDXの壁 (10分) • 実践：現場の「負」を解消する泥臭い並走 (10分) • 越境の技術：ドメインの言語を習得する (10分) • 汎用化：あらゆる困難なDXへの応用 (5分) • まとめ
67. まとめ • まとめの前に現在の状況 • Wi-Fiアクセスポイント入れ替え • PACS導入 • PACS (Picture Archiving and Communication System): CT、MRI、レントゲン などの撮影画像を保存、管理するシステムのこと。これまでは保守の切れたワー クステーションを使い続けていた • 惨状の改善が終わり、ようやくガイドラインへの準拠に取り組む準備 ができたところ • 自分不在でも現場で改善サイクルが回り始めた • 属人化から解放された？そもそも改善する担当がいなかった
68. まとめ • 現場作業は楽しい。現場でしかわからないことがたくさんある • 問題について一つずつ泥臭く丁寧に調査を続けるとよい • 当たり前だが機器の保守は大事なので、ケチらないで • 共通言語は越境の武器なので知識習得への投資を惜しまない • 「全体像を知ること」と、「技術的な詳細の深堀り」両方大事 • 越境の技術：知りたいという気持ちは枠からはみだし、壁を壊 して、越境を促進する（自分事にすること） • 自分のIT技術をどのドメインのために使うのか。その現場への好奇心 が越境やDXの源泉になる