これからのDX時代のエンジニアに求められること ～医療業界へのアプローチを通じて～

Developers Summit 2022
https://event.shoeisha.jp/devsumi/20220217/session/3729/

これからのDX時代のエンジニアに求められること ～医療業界へのアプローチを通じて～
平山 宗介（株式会社メドレー 取締役CTO）

Transcript

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