Developers Summit 2022 https://event.shoeisha.jp/devsumi/20220217/session/3729/
これからのDX時代のエンジニアに求められること ～医療業界へのアプローチを通じて～ 平山 宗介（株式会社メドレー 取締役CTO）
これからのDX時代のエンジニアに求められること医 療 業 界 へ の ア プ ロ ー チ を 通 じ て2022年2⽉18⽇株式会社メドレー取締役CTO 平⼭宗介Developers Summit 2022
View Slide
アジェンダ2Copyright © Medley, Inc. All rights reserved.• ⾃⼰紹介• 会社概要 / 事業概要• 医療業界の特徴• 医療業界への開発アプローチ• 考察 〜 DX時代のエンジニアに求められること• まとめ
⾃ ⼰ 紹 介
⾃⼰紹介4Copyright © Medley, Inc. All rights reserved.平⼭ 宗介ü 2005 - ⽇⽴系⼤⼿SIerü 2007 - 未踏ソフトウェア創造事業ü 2009 - グリー株式会社ü 2011 - フリーランスü 2012 - 株式会社リブセンスü 2015 - 株式会社メドレー株式会社メドレー取締役CTO 医療プラットフォーム本部⻑
会 社 概 要 / 事 業 概 要
会社概要6Copyright © Medley, Inc. All rights reserved.会社名 株式会社メドレーミッション 医療ヘルスケアの未来をつくる本社所在地 東京都港区六本⽊3-2-1住友不動産六本⽊グランドタワー22F設⽴⽇ 2009年6⽉5⽇事業内容 ⼈材プラットフォーム事業医療プラットフォーム事業代表者 代表取締役社⻑ 瀧⼝ 浩平従業員数 680名 (2021年3⽉末時点)グループ会社 株式会社オーティーオー (東京)株式会社パシフィックメディカル (⾼知等)株式会社メディパス (東京等)
事業概要7Copyright © Medley, Inc. All rights reserved.⼈材プラットフォーム事業 医療プラットフォーム事業“医療ヘルスケアの未来をつくる” 事業医療現場におけるデジタル活⽤を駆使した業務効率化のため、「⼈材プラットフォーム事業」と「医療プラットフォーム事業」を展開しています。[ミッション：医療デジタル化の推進][ミッション：⼈材不⾜/地域偏在課題]
ױऀͱͭͳ͕ΔΫϥυྍࢧԉγεςϜCLINICS (クリニクス) は、予約からオンライン診療、電⼦カルテ、レセコンといった独⽴したシステムをすべて内包し、⼀貫性のある操作性を実現できるシステムです。
ױऀͱͭͳ͕Δ͔͔Γ͚ͭༀہࢧԉγεςϜPharms (ファームス) は「患者」「地域」「業務」3つのつながりを実現することで、⾨前薬局からかかりつけ薬局への転換を⽀援します。
ױऀͱͭͳ͕ΔࣃՊۀࢧԉγεςϜDentis (デンティス) は患者と⻭科医院をオンラインでつなげ、あたらしい患者体験と業務効率の向上を⽬指した、これからのかかりつけ医のための⻭科医院向けシステムです。
“医療システムと連携する” 患者向けプロダクト群患者向けのプロダクトとして社内外の医師監修による医療メディア「MEDLEY」、オンライン診療・服薬指導アプリ「CLINICSアプリ」を提供しています。これらの患者向けプロダクトを緊密に連携させ、患者が医療を使いこなすことができる世界を⽬指しています。
これからのDX時代のエンジニアに求められること〜 医 療 業界 へ のア プロー チ を 通じ て〜メドレーは医療業界に特化した様々なプロダクトを開発している会社です。医療業界は歴史のある業界であり、いわゆるレガシーシステムが多く存在しています。法令や規制、商慣習、医師とベンダーの関係性など、多様な課題が複合して、今の状態を作り出しているため、アプローチが難しい状態となっています。そのような業界に対して、メドレーはどのような開発チームで、どのようなプロダクトを展開し、アプローチしているかをお話します。DXという⾔葉に注⽬が集まる中で、Web系かSI系かのいずれかではなく、その両者の壁をこえる存在が求められているように思います。これからの10年に向けてのキャリアを考える上で、本セッションが参考になれば幸いです。
医 療 業 界 の 特 徴
医療業界の特徴17Copyright © Medley, Inc. All rights reserved.「 計 画 経 済 」 の 世 界 に い る 医 療 業 界多 く の 規 制 や レ ギ ュ レ ー シ ョ ン の 存 在2. 受診窓⼝負担3. 診療・投薬⼊院・⼿術4. 請求 / ⽀払い1. 保険料 / 保険証患 者( 被 保 険 者 )診 療 所 / 病 院調 剤 薬 局保 険 者計画経済（けいかくけいざい）とは、経済の資源配分を市場の価格調整メカニズムに任せるのではなく、国家の物財バランスに基づいた計画によって配分される体制。対⽴概念は市場経済。また、計画経済と市場経済の利点を共に備えた混合経済や参加型経済がある。計画経済 - Wikipedia より
規制やレギュレーションの存在18Copyright © Medley, Inc. All rights reserved.法律• 医療法• 医薬品医療機器等法• 医師法 等• 健康保険法 等政令 • 医療法施⾏令省令・告⽰• 保険医療機関及び保険医療養担当規則• 診療報酬制度通知・通達• 医療広告ガイドライン• 3省2ガイドライン医 療 業 界 に お け る 各 種 レ ギ ュ レ ー シ ョ ン ( 抜 粋 )
規制やレギュレーションの存在 | 診療報酬制度19Copyright © Medley, Inc. All rights reserved.A 0 0 0 初 診 料 2 8 8 点保険医療機関において初診を⾏った場合に算定する。６歳未満の乳幼児に対して初診を⾏った場合は、乳幼児加算として、75点を所定点数に加算する。ただし、注７⼜は注８に規定する加算を算定する場合は算定しない。別に厚⽣労働⼤⾂が定める施設基準を満たす保険医療機関（診療所に限る。）が、午後６時（⼟曜⽇にあっては正午）から午前８時までの間（深夜及び休⽇を除く。）、休⽇⼜は深夜であって、当該保険医療機関が表⽰する診療時間内の時間において初診を⾏った場合は、夜間・早朝等加算として、50点を所定点数に加算する。ただし、注７のただし書⼜は注８に規定する加算を算定する場合にあっては、この限りでない。[ 診 療 報 酬 制 度 ]※ 細かいレギュレーションとあわせて、⽇本語という曖昧な⾔語で記述されているため「解釈」が必要なケースも存在する令和２年度診療報酬改定について | 厚⽣労働省https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000188411_00027.html
規制やレギュレーションの存在 | 療養担当規則20Copyright © Medley, Inc. All rights reserved.第⼆⼗⼆条 保険医は、患者の診療を⾏つた場合には、遅滞なく、様式第⼀号⼜はこれに準ずる様式の診療録に、当該診療に関し必要な事項を記載しなければならない。第⼆⼗三条 保険医は、処⽅箋を交付する場合には、様式第⼆号若しくは第⼆号の⼆⼜はこれらに準ずる様式の処⽅箋に必要な事項を記載しなければならない。[様式第⼀号] [様式第⼆号][ 療 養 担 当 規 則 ]保険医療機関及び保険医療養担当規則 | e-govhttps://elaws.e-gov.go.jp/document?lawid=332M50000100015
ドメイン理解のハードル21Copyright © Medley, Inc. All rights reserved.医療情報システムにおける標準類オーバービューチャート (JAHIS作成) よりhttps://www.jahis.jp/topics_list10/sections/id=578ド メ イ ン 理 解 の 難 し さ( 病 名 、 薬 剤 、 放射線、病理臨床細胞、⽣理検査 etc)
医療業界アプローチの難しさ22Copyright © Medley, Inc. All rights reserved.医 療 業 界 ア プ ロ ー チ の 難 し さ法令や規制、古くからある商慣習、医師とベンダーの関係なども含め、すべてが絡み合って複雑化している。そのため全体を俯瞰して⾒ることがとても難しい。ҩࢣͱϕϯμʔߦҩࢣձֶձݹ͍श׳๏ྩن੍ ࣾձอোઐͷࡉԽ
23Copyright © Medley, Inc. All rights reserved.結 果 と し て の 「 レ ガ シ ー の 発 ⽣ 」結果としてのレガシーの発⽣医療業界にアプローチすることは難しい。そのため、新規参⼊も難しく、結果として業界で使われるプロダクトはレガシーになる。そして、それにより業界へのアプローチが更に難しくなるという悪循環が発⽣する。• 習熟が求められるプロダクト• 使⽤技術の陳腐化• 移⾏できないデータ• 後継者不⾜• etcレガシーによる影響
医 療 業 界 へ の開 発 ア プ ロ ー チ
開発チーム紹介 | サマリCONFIDENTIAL 25Copyright © Medley, Inc. All rights reserved.メドレーは以下のような開発チームで、医療業界にアプローチしています (2022年2⽉時点)。70名ü プロダクト開発：9チーム- チーム平均 7.1名ü プロダクト横断：1チーム- チーム平均 6.0名33.6歳ü 20歳〜25歳：14名ü 25歳〜30歳：17名ü 30歳〜35歳：17名ü 35歳〜40歳：19名ü 40歳〜45歳：10名ü 45歳〜50歳：3名開発⼈員数※1 平均年齢年齢分布バックグラウンド※1: グループ会社在籍者は除く52%複数企業経験⽐率※2経験社分布チーム分布ü 事業会社のみ：30%- Webサービス提供 等ü 受託会社のみ：18%- SIer/制作会社 等※2: 事業会社での勤務と受託会社での勤務を両⽅経験している⼈員の割合年齢⼈員数
開発チーム紹介 | 構成メンバー26Copyright © Medley, Inc. All rights reserved.#エンジニア#SI #Web#エンジニア#SI #Web#エンジニア#SI #Web#エンジニア#Web#エンジニア#Web#デザイナー#制作会社 #Web#デザイナー#制作会社 #Web#デザイナー#制作会社#デザイナー#制作会社 #Web#デザイナー#制作会社 #Webメドレー⼊社前のキャリアとしては、エンジニア・デザイナー共に、クライアントワークの経験 (SI/制作会社) と事業会社での業務経験(Webサービス提供企業等) の双⽅を経験しているメンバーが多く在籍しています。
医療業界アプローチの3つのポイント27Copyright © Medley, Inc. All rights reserved.複雑で膨⼤な要件への迅速な対応[Complexity]セキュリティと品質の効率的な確保[Quality]レガシー化の⼒学への対応[Agility]複雑な業界事情とそれによるレガシーへの⼒学、加えてベンチャーの場合はスピーディーな製品展開の必要性を踏まえて、医療業界にアプローチするために、以下3点に対して適切に向き合う必要があると考えています。業界独特の規制やレギュレーションが多く存在しており、かつ解読が難解で複雑な要件も多い。リソースが潤沢でない中で、それらに対して迅速に対応していく必要がある医療情報というセンシティブな情報を取り扱う必要があるため、適切な情報管理体制の構築や、ソフトウェアに対する⾼い品質が要求される。これらの要求に対して効率的に取り組む必要がある現在のレガシーに対応できたとしても、そのシステムも将来のレガシーになりうる。それに対応するためにもレガシー化への⼒学についても適切に取り組んでいく必要がある1 2 3
医療業界アプローチの3つのポイント | 複雑で膨⼤な要件への迅速な対応28Copyright © Medley, Inc. All rights reserved.複雑で膨⼤な要件への迅速な対応[Complexity]セキュリティと品質の効率的な確保[Quality]レガシー化の⼒学への対応[Agility]複雑な業界事情とそれによるレガシーへの⼒学、加えてベンチャーの場合はスピーディーな製品展開の必要性を踏まえて、医療業界にアプローチするために、以下3点に対して適切に向き合う必要があると考えています。業界独特の規制やレギュレーションが多く存在しており、かつ解読が難解で複雑な要件も多い。リソースが潤沢でない中で、それらに対して迅速に対応していく必要がある医療情報というセンシティブな情報を取り扱う必要があるため、適切な情報管理体制の構築や、ソフトウェアに対する⾼い品質が要求される。これらの要求に対して効率的に取り組む必要がある現在のレガシーに対応できたとしても、そのシステムも将来のレガシーになりうる。それに対応するためにもレガシー化への⼒学についても適切に取り組んでいく必要がある1 2 3
#01. 複雑で膨⼤な要件への迅速な対応 | 深いドメイン理解CONFIDENTIAL 29Copyright © Medley, Inc. All rights reserved.「 深 いド メ イン 理解」難解で複雑な要件が多いため、要件定義に関わるコスト (コミュニケーションコスト) は膨らみがちです。開発者⾃らドメインについて深く理解することで、開発スピードを担保しています。⼀⽅、医療ドメインに関する情報については、検索上の情報は少なく、詳細を把握することがなかなか難しい状況があります (書籍、⼝頭 等)# 0 1 - A
#01. 複雑で膨⼤な要件への迅速な対応 | 要件設計における具体化/抽象化31Copyright © Medley, Inc. All rights reserved.具体抽 象[ A ]具体 具体「 要件 設 計 に おけ る具 体化/抽象 化」具体抽 象[ A ` ]具体 具体ドメインを深く理解した上で、顧客からの声をすいあげ、どのように要件設計を⾏うか。レガシーが発⽣している業界の前提をふまえ、要件は膨⼤で複雑化する傾向がある。そのため、具体と抽象を⾏き来し、要件を適切にコントロールすることが重要である (≒デザイン思考)。また、プロダクトデザインにおいては、機能を少しずつずらしながら、段階的に未来に誘導させていくことが望ましいと考える。ずらす# 0 1 - B
#01. 複雑で膨⼤な要件への迅速な対応 | 要件設計における具体化/抽象化32Copyright © Medley, Inc. All rights reserved.⽣の声(Voice)〇〇機能がほしい〇〇機能にバグがある〇〇に対応してほしい〇〇を効率化させたい〇〇の課題に対応したい〇〇機能がほしい〇〇機能にバグがある〇〇に対応してほしい〇〇を効率化させたい〇〇の課題に対応したい〇〇を効率化させたい〇〇機能がほしい〇〇の新規開発〇〇機能の改善〇〇オペレーションの変更N/A - 対応しない思考整理(Why)機能デザイン(Solution)顕在化している課題をそのまま実装に落とし込むのではなく、適切にインサイトを整理した上で機能デザインに落とし込むことを徹底しています。その整理の結果によっては「開発しない」ということも有⼒な選択肢となります。
#01. 複雑で膨⼤な要件への迅速な対応 | 要件設計における具体化/抽象化33Copyright © Medley, Inc. All rights reserved.[⻭科診療録の記載業務]現状の運⽤ (⽣の声)
#01. 複雑で膨⼤な要件への迅速な対応 | 要件設計における具体化/抽象化34Copyright © Medley, Inc. All rights reserved.[⻭科診療録の記載業務]⽣の声をそのまま反映
#01. 複雑で膨⼤な要件への迅速な対応 | 要件設計における具体化/抽象化35Copyright © Medley, Inc. All rights reserved.[⻭科診療録の記載業務]インサイトをふまえた機能デザイン
医療業界アプローチの3つのポイント | セキュリティと品質の効率的な確保36Copyright © Medley, Inc. All rights reserved.複雑で膨⼤な要件への迅速な対応[Complexity]セキュリティと品質の効率的な確保[Quality]レガシー化の⼒学への対応[Agility]複雑な業界事情とそれによるレガシーへの⼒学、加えてベンチャーの場合はスピーディーな製品展開の必要性を踏まえて、医療業界にアプローチするために、以下3点に対して適切に向き合う必要があると考えています。業界独特の規制やレギュレーションが多く存在しており、かつ解読が難解で複雑な要件も多い。リソースが潤沢でない中で、それらに対して迅速に対応していく必要がある医療情報という機微性の⾼い情報を取り扱う必要があるため、適切な情報管理体制の構築や、ソフトウェアに対する⾼い品質が要求される。これらの要求に対して効率的に取り組む必要がある現在のレガシーに対応できたとしても、そのシステムも将来のレガシーになりうる。それに対応するためにもレガシー化への⼒学についても適切に取り組んでいく必要がある1 2 3
#02. セキュリティと品質の効率的な確保 | リーンな情報管理体制の構築37Copyright © Medley, Inc. All rights reserved.「 リ ーン な 情報 管理体 制 の 構築 」医療情報を取り扱うシステムを構築するにあたっては、情報の機微性をふまえ、3省2ガイドライン※1のような各種ガイドラインへの準拠や適切な情報管理体制の構築が求められます。⼀⽅で複雑で冗⻑なプロセスを構築すると、プロダクト開発以外の⼯数がとられ、⾝動きが取りずらくなってしまいます。適切な情報管理体制を構築する必要があります。※1 ：医療情報を取り扱う事業者が準拠すべき医療情報の保護に関するガイドライン。厚⽣労働省、経済産業省、総務省の3省が発⾏する2つのガイドラインを指す# 0 2 - A
#02. セキュリティと品質の効率的な確保 | リーンな情報管理体制の構築38Copyright © Medley, Inc. All rights reserved.ISMSについてご存知の⽅は、ISMS認証取得について少々ネガティブなイメージを持たれている⽅も少なくないかもしれません。例えば、「分厚い規程類がたくさん出来上がる」、「ガチガチのルール作りを強いられる」、「やたらと⼿間のかかる台帳を使わないといけない」といったような、「はぁ、昔はラクで良かった…。」というイメージです。今回のISMS取得プロジェクトにおいて初志貫徹したコンセプトがあります。それは、「ムダを削ぎ落としたリーンな仕組みを作る」ということです。多くの組織は、認証取得⽀援コンサル会社などから⼊⼿した雛型をバコッとはめて、結果として⼤量の社内⽂書ができあがったりしてしまいがちですが、今回は本来要求されているISO規格の要求事項を本質的に実現するにはどうすればよいかという事に注⼒しました。全社で本気になってリーンにISMSの仕組みをつくった話https://developer.medley.jp/entry/2019/02/01/172457情 報 セ キ ュ リ テ ィ 管 理 プ ロ セ ス の 構 築I S M S ク ラ ウ ド セ キ ュ リ テ ィ 認 証 の 取 得
#02. セキュリティと品質の効率的な確保 | QAプロセスの効率化39Copyright © Medley, Inc. All rights reserved.「QA プ ロ セスの 効率 化」医療業界の複雑さをふまえ、機能要件は膨⼤で複雑化する傾向があります。それに伴い、QAプロセスも肥⼤化し、品質確保のコストが⼤きく膨らみがちです。品質とスピードのバランスを適切にとるためにも、ソフトウェア開発の全フェーズにおけるQAプロセスの介⼊⽅法は深く検討する必要があります。# 0 2 - B要件定義基本設計詳細設計製造単体ﾃｽﾄ結合テストシステムテスト受⼊テスト
#02. セキュリティと品質の効率的な確保 | QAプロセスの効率化40Copyright © Medley, Inc. All rights reserved.UIテストの⾃動化にMagic Podを導⼊した話https://developer.medley.jp/entry/2021/01/15/180126例えば1〜2年後やその先を考えて、リグレッションテストが⾃動化されているべきか否かで⾔うとやはりYesです。また、別の観点として、現在はわずか2⼈のQAエンジニアに対して、複数のプロダクトが存在している状況で、QAエンジニアがアサインされていないプロダクトも多くあります。そんな状況下では、仮にUIテストを⾃動化した環境を⽤意できたとして、その後に担当者が不在になった場合も考慮しておく必要があります。そのため、仮に実装者が不在となった後でも誰かに引き継ぎやすく、またエンジニア以外でも運⽤できる環境が望ましいと考えました。そういった観点でツールとしては基本ノーコードでもメンテできるMagic Podは有⼒な候補となりました。持 続 可 能 性 の ⾼ い テ ス ト ⾃ 動 化 へ の 取 組 みリ グ レ ッ シ ョ ン テ ス ト の ⾃ 動 化 + α⼀⽅、レセコンのような複雑であいまいな要件の上に成り⽴っているソフトウェアに対する、QAプロセスの構築にはまだ課題がある。今後の取組みの中で改善していきたい (参考：P19の初診料の例)
#02. セキュリティと品質の効率的な確保 | 開発者モラリティの維持41Copyright © Medley, Inc. All rights reserved.「 開発 者 モ ラ リテ ィの 維持 」情報管理体制やQAプロセスの構築のみで品質の担保を⽬指すと膨⼤なコストがかかってしまう。最低限の体制やプロセスは構築した上で、その上で働く開発者のモラリティを⼀定以上に保つことも重要な要素であると考えます。そのためにも、「担当業務を細分化しすぎない」「会議体の緻密な設計」等の対応もあわせて検討する必要があると考えます。# 0 2 - C
医療業界アプローチの3つのポイント | レガシー化の⼒学への対応42Copyright © Medley, Inc. All rights reserved.複雑で膨⼤な要件への迅速な対応[Complexity]セキュリティと品質の効率的な確保[Quality]レガシー化の⼒学への対応[Agility]複雑な業界事情とそれによるレガシーへの⼒学、加えてベンチャーの場合はスピーディーな製品展開の必要性を踏まえて、医療業界にアプローチするために、以下3点に対して適切に向き合う必要があると考えています。業界独特の規制やレギュレーションが多く存在しており、かつ解読が難解で複雑な要件も多い。リソースが潤沢でない中で、それらに対して迅速に対応していく必要がある医療情報というセンシティブな情報を取り扱う必要があるため、適切な情報管理体制の構築や、ソフトウェアに対する⾼い品質が要求される。これらの要求に対して効率的に取り組む必要がある現在のレガシーに対応できたとしても、そのシステムも将来のレガシーになりうる。それに対応するためにもレガシー化への⼒学についても適切に取り組んでいく必要がある1 2 3
#03. レガシー化の⼒学への対応 | 原則3ヶ⽉単位の開発計画43Copyright © Medley, Inc. All rights reserved.「 原 則3ヶ ⽉ 単位の 開発 計画 」⻑期で動くプロジェクトや短期で動くプロジェクトなど、様々なプロジェクトが存在していますが、全チーム原則として3ヶ⽉の開発を基本単位としています。その原則の中で、ウォーターフォール型に近い⽅式での開発、アジャイル型に近い⽅式での開発、それぞれのチームの判断で動いています。# 0 3 - A
#03. レガシー化の⼒学への対応 | 原則3ヶ⽉単位の開発計画44Copyright © Medley, Inc. All rights reserved.チームAチームBチームCチームD1⽉ 2⽉ 3⽉ 4⽉ 5⽉ 6⽉ 7⽉ 8⽉ 9⽉ 10⽉ 11⽉ 12⽉C01-01C03-01C02-01D01-01D03-01D02-01B01-01B03-01B02-01B05-01C04-01C02-02C03-02A01-01A03-01A02-01A03-02A02-02D01-02D04-01D02-02D01-03D05-01D04-02D01-04D05-02D04-03B01-01B03-02B04-01A01-02A03-03A02-03A01-03A03-04A05-01A04-01B04-02B03-03C04-02C02-03C05-01B05-02B04-03B03-04C04-03C02-04C05-02原則3ヶ⽉単位でのフェーズ分割を⾏うことで、クオーター単位での開発計画もしくは⼈員配置の調整を可能にします。加えて、細かくリリースすることによる品質の確保や、精度の⾼い開発計画の⽴案も担保します。1Q 2Q 3Q 4Q
#03. レガシー化の⼒学への対応 | 新旧様々な技術スタックへの対応45Copyright © Medley, Inc. All rights reserved.「新 旧 様々 な技 術 スタ ッ クへ の 対応 」医療業界において開発業務を推進していくにあたり、歴史のあるシステムとの連携が必要になるシーンも多く、新旧様々な技術スタックに柔軟に対応する必要があります。加えて、⻑期で利⽤頂くシステムを開発していることもふまえ、開発体制の持続可能性は常に考慮し、使⽤技術の陳腐化を避けるためにも、技術トレンドとの整合性を意識しながら、開発に取り組んでいます。# 0 3 - B
Ruby / Ruby on Rails /Go / PHP / COBOLJavaScript /TypeScript /GraphQL / React.js / Next.jsSwift / Objective-C / Kotlin#03. レガシー化の⼒学への対応 | 新旧様々な技術スタックへの対応46Copyright © Medley, Inc. All rights reserved.Language/FrameworkMySQL / MongoDB /Elasticsearch / BigQueryAWS / Docker /Docker ComposeGithub / Circle CI / Bitrise /DeployGate / Sentry /New RelicSlack /Atlassian ConfluenceStorageInfrastructure Workflow Communication
医療業界アプローチの3つのポイント47Copyright © Medley, Inc. All rights reserved.複雑で膨⼤な要件への迅速な対応[Complexity]セキュリティと品質の効率的な確保[Quality]レガシー化の⼒学への対応[Agility]複雑な業界事情とそれによるレガシーへの⼒学、加えてベンチャーの場合はスピーディーな製品展開の必要性を踏まえて、医療業界にアプローチするために、以下3点に対して適切に向き合う必要があると考えています。業界独特の規制やレギュレーションが多く存在しており、かつ解読が難解で複雑な要件も多い。リソースが潤沢でない中で、それらに対して迅速に対応していく必要がある医療情報というセンシティブな情報を取り扱う必要があるため、適切な情報管理体制の構築や、ソフトウェアに対する⾼い品質が要求される。これらの要求に対して効率的に取り組む必要がある現在のレガシーに対応できたとしても、そのシステムも将来のレガシーになりうる。それに対応するためにもレガシー化への⼒学についても適切に取り組んでいく必要がある1 2 3
考 察〜DX時代のエンジニアに求められること〜※ 株式会社⼀休のCTOである伊藤直也さんとの対話をふまえてまとめています
IT業界の歴史の変遷49[1990年代以前]業務システムを実現するためのIT[1990年代後半]インターネット勃興期[2000年代前半]Googleの台頭[2000年代後半]Web2.0とガラケーの時代[2010年代前半]スマートフォン普及期Copyright © Medley, Inc. All rights reserved.現在[2010年代後半]B2B SaaSの台頭[2020年代前半]「DX時代」の突⼊1990 20102000 2020 2030デジタルトランスフォーメーションD i g i t a l T r a n s f o r m a t i o n ( D X )各種業務のデジタル化の結果として社会的な影響を⽣み出すこと
IT業界の歴史の変遷 | マクロな社会環境の変化50[1990年代以前]業務システムを実現するためのIT[1990年代後半]インターネット勃興期[2000年代前半]Googleの台頭[2000年代後半]Web2.0とガラケーの時代[2010年代前半]スマートフォン普及期Copyright © Medley, Inc. All rights reserved.[2010年代後半]B2B SaaSの台頭[2020年代前半]「DX時代」の突⼊1990 20102000 2020 2030現在技術進化による⼀定の担保IT分野における2025年問題2. 業界の複雑度の推移1. (課題の⾼度化と複雑化)1. 出⽣数の推移1. (少⼦⾼齢化の加速)
51Copyright © Medley, Inc. All rights reserved.これからのDX時代のエンジニアに求められることIT業界の歴史の変遷 | エンジニアに求められること
SoR と SoE52Copyright © Medley, Inc. All rights reserved.特徴(性向 / 適合)システム領域開発⼿法プロダクトマネジメントケイパビリティSoR：System of Record1990年代 / 2000年代の主流SoE：System of Engagement2000年代 / 2010年代の主流・安定性重視・予測可能業務・リスクを抑えて安全運転・要件を事前に明確化・バックエンド・認証、在庫管理、決済、個⼈情報保護・⽐較的ウォーターフォール寄り・開発前に要件を明確に定義・品質の確保を優先・トップダウン寄り・「正しい仕様」に基づいたプロジェクト管理・経営や開発部⾨が主導することが多い・要件定義⼒、調整⼒、プロジェクトマネジメント・SIの皆さんが得意そうSystem of Record と System of Engagement - Speaker Deck よりhttps://speakerdeck.com/naoya/system-of-record-to-system-of-engagement・ユーザインタフェース品質、開発速度重視・探索型業務・スピード重視で運転・トライ&エラー、プロトタイピング・フロントエンド、スマートフォンアプリ・UI、CRM、ダイレクトメール・⽐較的アジャイル、リーン寄り・トライ&エラーで正しい問題、論点を探り当てる・迅速なリリースを優先・ボトムアップ寄り・「正しい仕様」は存在しない・マーケティング、デザインが主導することも・ユーザ視点、デザイン思考、アナリティクス・Web系が得意そう
SoR と SoE | 医療業界アプローチを踏まえての考察53Copyright © Medley, Inc. All rights reserved.特徴(性向 / 適合)システム領域開発⼿法プロダクトマネジメントケイパビリティSoR：System of Record1990年代 / 2000年代の主流SoE：System of Engagement2000年代 / 2010年代の主流・安定性重視・予測可能業務・リスクを抑えて安全運転・要件を事前に明確化・バックエンド・認証、在庫管理、決済、個⼈情報保護・⽐較的ウォーターフォール寄り・開発前に要件を明確に定義・品質の確保を優先・トップダウン寄り・「正しい仕様」に基づいたプロジェクト管理・経営や開発部⾨が主導することが多い・要件定義⼒、調整⼒、プロジェクトマネジメント・SIの皆さんが得意そう・ユーザインタフェース品質、開発速度重視・探索型業務・スピード重視で運転・トライ&エラー、プロトタイピング・フロントエンド、スマートフォンアプリ・UI、CRM、ダイレクトメール・⽐較的アジャイル、リーン寄り・トライ&エラーで正しい問題、論点を探り当てる・迅速なリリースを優先・ボトムアップ寄り・「正しい仕様」は存在しない・マーケティング、デザインが主導することも・ユーザ視点、デザイン思考、アナリティクス・Web系が得意そう⾊塗：当社開発における重視ポイント当社のアプローチ (医療DX) をSoRとSoEにマッピングすると以下のとおり。SoRに軸⾜を置きながらもSoEの⼿法を積極的に組み込んでいます。
SoR と SoE | IT業界の歴史の変遷へのマッピングCONFIDENTIAL 54[1990年代以前]業務システムを実現するためのIT[1990年代後半]インターネット勃興期[2000年代前半]Googleの台頭[2000年代後半]Web2.0とガラケーの時代[2010年代前半]スマートフォン普及期Copyright © Medley, Inc. All rights reserved.[2010年代後半]B2B SaaSの台頭[2020年代前半]「DX時代」の突⼊1990 20102000 2020 2030SoRの開発が得意な⼈材が活躍した時代SoEの開発が得意な⼈材が活躍した時代SoEの⼿法をSoRの分野に適応できる⼈材が活躍する (だろう)時代
DX時代のエンジニアに求められること55Copyright © Medley, Inc. All rights reserved.#01 : SoEの⼿法をSoRの分野に適応できるスキルü コモディティ化した技術を、基礎理解も含め安定して扱えるスキルセットü UI/UXを重視したプロダクトをチームで作り上げた経験ü 対象ドメインを深く理解し、技術的な⽂脈を考慮したディスカッションをビジネスパートナーと共に⾏えること#02: 開発者ひとりあたりの⽣産性の向上ü セキュリティ要件含めた、複雑で膨⼤な要件に対して効率的にアプローチできることü また既存のプロセスにとらわれずに、効率的にアプローチするための新たな仕組みや組織を構築できること
DX時代のエンジニアに求められること | 原点回帰56Copyright © Medley, Inc. All rights reserved.2010年付近までの凄腕のエンジニアがひとりでなんとかやれるような時代は終わり、あらためて⼈⽉の神話で話されているようなソフトウェア開発の本質に向き合う必要がでてきているように思います。単に⼈が⾜りない、は思考停⽌している。⽇本が課題先進国ともいわれるなかで、開発者ひとりあたりの⽣産性を強化しないことには⽇本のソフトウェア産業に未来はないと思っています。これからの10年、開発者は開発者であることに誇りをもって取り組んでいってほしいなと考えています。“エンジニア (技術者) とは、“⾃然科学や⼈⽂社会科学の知⾒を⽤いて“安⼼安全な社会を実現する、“という学術領域において、“専⾨性を持った実践者である”
メドレー平⼭の中央突破https://toppa.medley.jp/
ま と め
まとめ60Copyright © Medley, Inc. All rights reserved.ü 医療業界では様々な課題が複雑に絡まっているためアプローチが難しく、その結果としてレガシーが発⽣しがちであるü そのような背景をふまえ、メドレーは以下3点に重きをおき、開発を進めているØ #01. 複雑で膨⼤な要件への迅速な対応• 深いドメイン理解 / 要件設計における具体化・抽象化Ø #02. セキュリティと品質の効率的な確保• リーンな情報管理体制の構築 / QAプロセスの効率化 / 開発者モラリティの維持Ø #03. レガシー化の⼒学への対応• 原則3ヶ⽉単位の開発計画 /新旧様々な技術スタックへの対応• IT業界の進化の歴史をふまえると、DXの潮流が進むことは必須• そのような時代の中では、SoRとSoEのハイブリッドな開発⼈材が求められてくると考える。加えて、ひとりあたりの⽣産性については「より強く」求められてくると考える• 開発者は原点に⽴ち戻り頑張っていきたい
さ い ご に
“医 療 ヘル ス ケア の未 来 をつく る”プロダクトをつくるひと絶 賛 募 集 中メドレーはプロダクトをつくることに誇りを持ち社会や周囲の⼈たちに対して貢献しようとするホスピタリティをもったPdM・エンジニア・デザイナーの⽅を募集してます株式会社メドレー 次世代に⽣きる⼈の医療のために
「動画で⾒るメドレー 」(株式会社メドレー コーポレートサイト)h t t p s : / / w w w . m e d l e y . j p / m o v i e /
医 療 ヘ ル ス ケ ア の 未 来 を つ く る
medley
mii3king
motok1
abenben
safie_recruit
hirosatogamo
mizunohiroaki
makamaka
foursue
sumiren
ad5jp
onk
yutaro527
ammeep
ufuk
dougneiner
ddemaree
keavy
jennybc
holman
tmm1
kastner
kneath
jonyablonski
matthewcrist