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

これからの
DX時代のエンジニアに
求められること
医療業界へのアプローチを通じて
2022年2⽉18⽇
株式会社メドレー
取締役CTO 平⼭宗介
Developers Summit 2022

View Slide

アジェンダ
2
Copyright © Medley, Inc. All rights reserved.
• ⾃⼰紹介
• 会社概要 / 事業概要
• 医療業界の特徴
• 医療業界への開発アプローチ
• 考察〜 DX時代のエンジニアに求められること
• まとめ

View Slide

⾃⼰紹介

View Slide

⾃⼰紹介
4
平⼭宗介
ü 2005 - ⽇⽴系⼤⼿SIer
ü 2007 - 未踏ソフトウェア創造事業
ü 2009 - グリー株式会社
ü 2011 - フリーランス
ü 2012 - 株式会社リブセンス
ü 2015 - 株式会社メドレー
株式会社メドレー
取締役CTO 医療プラットフォーム本部⻑

View Slide

会社概要 / 事業概要

View Slide

会社概要
6
会社名株式会社メドレー
ミッション医療ヘルスケアの未来をつくる
本社所在地東京都港区六本⽊3-2-1
住友不動産六本⽊グランドタワー22F
設⽴⽇ 2009年6⽉5⽇
事業内容⼈材プラットフォーム事業
医療プラットフォーム事業
代表者代表取締役社⻑瀧⼝浩平
従業員数 680名 (2021年3⽉末時点)
グループ会社株式会社オーティーオー (東京)
株式会社パシフィックメディカル (⾼知等)
株式会社メディパス (東京等)

View Slide

事業概要
7
⼈材プラットフォーム事業医療プラットフォーム事業
“医療ヘルスケアの未来をつくる” 事業
医療現場におけるデジタル活⽤を駆使した業務効率化のため、「⼈材プラットフォーム事業」と「医療プラットフォーム事業」を展開しています。
[ミッション：医療デジタル化の推進]
[ミッション：⼈材不⾜/地域偏在課題]

View Slide

ױऀͱͭͳ͕Δ
Ϋϥ΢υ਍ྍ
ࢧԉγεςϜ
CLINICS (クリニクス) は、予約からオンラ
イン診療、電⼦カルテ、レセコンといった
独⽴したシステムをすべて内包し、⼀貫性
のある操作性を実現できるシステムです。

View Slide

View Slide

ױऀͱͭͳ͕Δ
͔͔Γ͚ͭༀہ
ࢧԉγεςϜ
Pharms (ファームス) は「患者」「地域」
「業務」3つのつながりを実現することで、
⾨前薬局からかかりつけ薬局への転換を⽀
援します。

View Slide

View Slide

ױऀͱͭͳ͕Δ
ࣃՊۀ຿ࢧԉγεςϜ
Dentis (デンティス) は患者と⻭科医院をオンライ
ンでつなげ、あたらしい患者体験と業務効率の向上
を⽬指した、これからのかかりつけ医のための⻭科
医院向けシステムです。

View Slide

View Slide

“医療システムと連携する” 患者向けプロダクト群
患者向けのプロダクトとして社内外の医師監修による医療メディア「MEDLEY」、オンライン
診療・服薬指導アプリ「CLINICSアプリ」を提供しています。これらの患者向けプロダクトを緊
密に連携させ、患者が医療を使いこなすことができる世界を⽬指しています。

View Slide

これからのDX時代の
エンジニアに求められること
〜医療業界へのアプローチを通じて〜
メドレーは医療業界に特化した様々なプロダクトを開発している会社です。医療業界は歴
史のある業界であり、いわゆるレガシーシステムが多く存在しています。法令や規制、商
慣習、医師とベンダーの関係性など、多様な課題が複合して、今の状態を作り出している
ため、アプローチが難しい状態となっています。そのような業界に対して、メドレーはど
のような開発チームで、どのようなプロダクトを展開し、アプローチしているかをお話し
ます。DXという⾔葉に注⽬が集まる中で、Web系かSI系かのいずれかではなく、その両
者の壁をこえる存在が求められているように思います。これからの10年に向けてのキャリ
アを考える上で、本セッションが参考になれば幸いです。

View Slide

医療業界の特徴

View Slide

医療業界の特徴
17
「計画経済」の世界にいる医療業界
多くの規制やレギュレーションの存在
2. 受診窓⼝負担
3. 診療・投薬
⼊院・⼿術
4. 請求 / ⽀払い
1. 保険料 / 保険証
患者
( 被保険者 )
診療所 / 病院
調剤薬局
保険者
計画経済（けいかくけいざい）とは、経済の資源配分を市場の価格調整メカニズムに任せるのではな
く、国家の物財バランスに基づいた計画によって配分される体制。対⽴概念は市場経済。また、計画
経済と市場経済の利点を共に備えた混合経済や参加型経済がある。
計画経済 - Wikipedia より

View Slide

規制やレギュレーションの存在
18
法律
• 医療法
• 医薬品医療機器等法
• 医師法等
• 健康保険法等
政令 • 医療法施⾏令
省令・告⽰
• 保険医療機関及び保険医療養担当規則
• 診療報酬制度
通知・通達
• 医療広告ガイドライン
• 3省2ガイドライン
医療業界における各種レギュレーション ( 抜粋 )

View Slide

規制やレギュレーションの存在 | 診療報酬制度
19
A 0 0 0 初診料 2 8 8 点
保険医療機関において初診を⾏った場合に算定する。
６歳未満の乳幼児に対して初診を⾏った場合は、乳幼児
加算として、75点を所定点数に加算する。ただし、注７
⼜は注８に規定する加算を算定する場合は算定しない。
別に厚⽣労働⼤⾂が定める施設基準を満たす保険医療機
関（診療所に限る。）が、午後６時（⼟曜⽇にあっては
正午）から午前８時までの間（深夜及び休⽇を除く。）、
休⽇⼜は深夜であって、当該保険医療機関が表⽰する診
療時間内の時間において初診を⾏った場合は、夜間・早
朝等加算として、50点を所定点数に加算する。ただし、
注７のただし書⼜は注８に規定する加算を算定する場合
にあっては、この限りでない。
[ 診療報酬制度 ]
※ 細かいレギュレーションとあわせて、⽇本語という曖昧な⾔語で
記述されているため「解釈」が必要なケースも存在する
令和２年度診療報酬改定について | 厚⽣労働省
https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000188411_00027.html

View Slide

規制やレギュレーションの存在 | 療養担当規則
20
第⼆⼗⼆条保険医は、患者の診療を⾏つた場合には、遅
滞なく、様式第⼀号⼜はこれに準ずる様式の診療録に、当
該診療に関し必要な事項を記載しなければならない。
第⼆⼗三条保険医は、処⽅箋を交付する場合には、様式
第⼆号若しくは第⼆号の⼆⼜はこれらに準ずる様式の処⽅
箋に必要な事項を記載しなければならない。
[様式第⼀号] [様式第⼆号]
[ 療養担当規則 ]
保険医療機関及び保険医療養担当規則 | e-gov
https://elaws.e-gov.go.jp/document?lawid=332M50000100015

View Slide

ドメイン理解のハードル
21
医療情報システムにおける標準類オーバービューチャート (JAHIS作成) より
https://www.jahis.jp/topics_list10/sections/id=578
ドメイン理解の難しさ
( 病名、薬剤、放射線、病理臨床細胞、⽣理検査 etc)

View Slide

医療業界アプローチの難しさ
22
医療業界アプローチの難しさ
法令や規制、古くからある商慣習、医師とベンダーの関係なども含め、
すべてが絡み合って複雑化している。そのため全体を俯瞰して⾒ることがとても難しい。
ҩࢣͱ
ϕϯμʔ
ߦ੓
ҩࢣձ
ֶձ
ݹ͍঎श׳
๏ྩ
ن੍ ࣾձอো
ઐ໳෼໺ͷ
ࡉ෼Խ

View Slide

23
結果としての「レガシーの発⽣」
結果としてのレガシーの発⽣
医療業界にアプローチすることは難しい。そのため、
新規参⼊も難しく、結果として業界で使われるプロダクトはレガシーになる。
そして、それにより業界へのアプローチが更に難しくなるという悪循環が発⽣する。
• 習熟が求められるプロダクト
• 使⽤技術の陳腐化
• 移⾏できないデータ
• 後継者不⾜
• etc
レガシーによる影響

View Slide

医療業界への
開発アプローチ

View Slide

開発チーム紹介 | サマリ
CONFIDENTIAL 25
メドレーは以下のような開発チームで、医療業界にアプローチしています (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: 事業会社での勤務と受託会社での勤務を
両⽅経験している⼈員の割合
年齢
⼈員数

View Slide

開発チーム紹介 | 構成メンバー
26
#エンジニア
#SI #Web
#エンジニア
#SI #Web
#エンジニア
#SI #Web
#エンジニア
#Web
#エンジニア
#Web
#デザイナー
#制作会社 #Web
#デザイナー
#制作会社 #Web
#デザイナー
#制作会社
#デザイナー
#制作会社 #Web
#デザイナー
#制作会社 #Web
メドレー⼊社前のキャリアとしては、エンジニア・デザイナー共に、クライアントワークの経験 (SI/制作会社) と事業会社での業務経験
(Webサービス提供企業等) の双⽅を経験しているメンバーが多く在籍しています。

View Slide

医療業界アプローチの3つのポイント
27
複雑で膨⼤な
要件への迅速な対応
[Complexity]
セキュリティと
品質の効率的な確保
[Quality]
レガシー化の
⼒学への対応
[Agility]
複雑な業界事情とそれによるレガシーへの⼒学、
加えてベンチャーの場合はスピーディーな製品展開の必要性を踏まえて、
医療業界にアプローチするために、以下3点に対して適切に向き合う必要があると考えています。
業界独特の規制やレギュレーションが
多く存在しており、かつ解読が難解で
複雑な要件も多い。リソースが潤沢で
ない中で、それらに対して迅速に対応
していく必要がある
医療情報というセンシティブな情報を
取り扱う必要があるため、適切な情報
管理体制の構築や、ソフトウェアに対
する⾼い品質が要求される。これらの
要求に対して効率的に取り組む必要が
ある
現在のレガシーに対応できたとしても、
そのシステムも将来のレガシーになり
うる。それに対応するためにもレガ
シー化への⼒学についても適切に取り
組んでいく必要がある
1 2 3

View Slide

医療業界アプローチの3つのポイント | 複雑で膨⼤な要件への迅速な対応
28
複雑で膨⼤な
[Complexity]
[Quality]
レガシー化の
⼒学への対応
[Agility]
ある
1 2 3

View Slide

#01. 複雑で膨⼤な要件への迅速な対応 | 深いドメイン理解
CONFIDENTIAL 29
「深いドメイン理解」
難解で複雑な要件が多いため、要件定義に関わるコスト (コミュニケーションコスト) は膨ら
みがちです。開発者⾃らドメインについて深く理解することで、開発スピードを担保してい
ます。⼀⽅、医療ドメインに関する情報については、検索上の情報は少なく、詳細を把握す
ることがなかなか難しい状況があります (書籍、⼝頭等)
# 0 1 - A

View Slide

View Slide

#01. 複雑で膨⼤な要件への迅速な対応 | 要件設計における具体化/抽象化
31
具体
抽象
[ A ]
具体具体
「要件設計における具体化/抽象化」
具体
抽象
[ A ` ]
具体具体
ドメインを深く理解した上で、顧客からの声をすいあげ、どのように要件設計を⾏うか。レガ
シーが発⽣している業界の前提をふまえ、要件は膨⼤で複雑化する傾向がある。そのため、具体
と抽象を⾏き来し、要件を適切にコントロールすることが重要である (≒デザイン思考)。また、
プロダクトデザインにおいては、機能を少しずつずらしながら、段階的に未来に誘導させていく
ことが望ましいと考える。
ずらす
# 0 1 - B

View Slide

32
⽣の声
(Voice)
〇〇機能がほしい
〇〇機能にバグがある
〇〇に対応してほしい
〇〇を効率化させたい
〇〇の課題に対応したい
〇〇機能にバグがある
〇〇に対応してほしい
〇〇の課題に対応したい
〇〇の新規開発
〇〇機能の改善
〇〇オペレーションの変更
N/A - 対応しない
思考整理
(Why)
機能デザイン
(Solution)
顕在化している課題をそのまま実装に落とし込むのではなく、適切にインサイトを整理した上で機能デザインに落とし込むことを徹底して
います。その整理の結果によっては「開発しない」ということも有⼒な選択肢となります。

View Slide

33
[⻭科診療録の記載業務]
現状の運⽤ (⽣の声)

View Slide

34
⽣の声をそのまま反映

View Slide

35
インサイトをふまえた機能デザイン

View Slide

医療業界アプローチの3つのポイント | セキュリティと品質の効率的な確保
36
複雑で膨⼤な
[Complexity]
[Quality]
レガシー化の
⼒学への対応
[Agility]
医療情報という機微性の⾼い情報を取
り扱う必要があるため、適切な情報管
理体制の構築や、ソフトウェアに対す
る⾼い品質が要求される。これらの要
求に対して効率的に取り組む必要があ
る
1 2 3

View Slide

#02. セキュリティと品質の効率的な確保 | リーンな情報管理体制の構築
37
「リーンな情報管理体制の構築」
医療情報を取り扱うシステムを構築するにあたっては、情報の機微性をふまえ、3省2ガイドライ
ン※1のような各種ガイドラインへの準拠や適切な情報管理体制の構築が求められます。⼀⽅で複
雑で冗⻑なプロセスを構築すると、プロダクト開発以外の⼯数がとられ、⾝動きが取りずらく
なってしまいます。適切な情報管理体制を構築する必要があります。
※1 ：医療情報を取り扱う事業者が準拠すべき医療情報の保護に関するガイドライン。厚⽣労働省、経済産業省、総務省の3省が発⾏
する2つのガイドラインを指す
# 0 2 - A

View Slide

#02. セキュリティと品質の効率的な確保 | リーンな情報管理体制の構築
38
ISMSについてご存知の⽅は、ISMS認証取得について少々ネガ
ティブなイメージを持たれている⽅も少なくないかもしれませ
ん。例えば、「分厚い規程類がたくさん出来上がる」、「ガチ
ガチのルール作りを強いられる」、「やたらと⼿間のかかる台
帳を使わないといけない」といったような、「はぁ、昔はラク
で良かった…。」というイメージです。
今回のISMS取得プロジェクトにおいて初志貫徹したコンセプ
トがあります。それは、「ムダを削ぎ落としたリーンな仕組み
を作る」ということです。多くの組織は、認証取得⽀援コンサ
ル会社などから⼊⼿した雛型をバコッとはめて、結果として⼤
量の社内⽂書ができあがったりしてしまいがちですが、今回は
本来要求されているISO規格の要求事項を本質的に実現するに
はどうすればよいかという事に注⼒しました。
全社で本気になってリーンにISMSの仕組みをつくった話
https://developer.medley.jp/entry/2019/02/01/172457
情報セキュリティ管理プロセスの構築
I S M S クラウドセキュリティ認証の取得

View Slide

#02. セキュリティと品質の効率的な確保 | QAプロセスの効率化
39
「QA プロセスの効率化」
医療業界の複雑さをふまえ、機能要件は膨⼤で複雑化する傾向があります。それに伴い、QAプ
ロセスも肥⼤化し、品質確保のコストが⼤きく膨らみがちです。品質とスピードのバランスを適
切にとるためにも、ソフトウェア開発の全フェーズにおけるQAプロセスの介⼊⽅法は深く検討
する必要があります。
# 0 2 - B
要件定義
基本設計
詳細
設計
製造
単体ﾃｽﾄ
結合
テスト
システム
テスト
受⼊
テスト

View Slide

#02. セキュリティと品質の効率的な確保 | QAプロセスの効率化
40
UIテストの⾃動化にMagic Podを導⼊した話
https://developer.medley.jp/entry/2021/01/15/180126
例えば1〜2年後やその先を考えて、リグレッションテストが⾃
動化されているべきか否かで⾔うとやはりYesです。また、別
の観点として、現在はわずか2⼈のQAエンジニアに対して、複
数のプロダクトが存在している状況で、QAエンジニアがアサ
インされていないプロダクトも多くあります。
そんな状況下では、仮にUIテストを⾃動化した環境を⽤意でき
たとして、その後に担当者が不在になった場合も考慮しておく
必要があります。
そのため、仮に実装者が不在となった後でも誰かに引き継ぎや
すく、またエンジニア以外でも運⽤できる環境が望ましいと考
えました。そういった観点でツールとしては基本ノーコードで
もメンテできるMagic Podは有⼒な候補となりました。
持続可能性の⾼いテスト⾃動化への取組み
リグレッションテストの⾃動化 + α
⼀⽅、レセコンのような複雑であいまいな要件の上に成り⽴っているソフ
トウェアに対する、QAプロセスの構築にはまだ課題がある。今後の取組
みの中で改善していきたい (参考：P19の初診料の例)

View Slide

#02. セキュリティと品質の効率的な確保 | 開発者モラリティの維持
41
「開発者モラリティの維持」
情報管理体制やQAプロセスの構築のみで品質の担保を⽬指すと膨⼤なコストがかかってしまう。
最低限の体制やプロセスは構築した上で、その上で働く開発者のモラリティを⼀定以上に保つこ
とも重要な要素であると考えます。そのためにも、「担当業務を細分化しすぎない」「会議体の
緻密な設計」等の対応もあわせて検討する必要があると考えます。
# 0 2 - C

View Slide

医療業界アプローチの3つのポイント | レガシー化の⼒学への対応
42
複雑で膨⼤な
[Complexity]
[Quality]
レガシー化の
⼒学への対応
[Agility]
ある
1 2 3

View Slide

#03. レガシー化の⼒学への対応 | 原則3ヶ⽉単位の開発計画
43
「原則3ヶ⽉単位の開発計画」
⻑期で動くプロジェクトや短期で動くプロジェクトなど、様々なプロジェクトが存在しています
が、全チーム原則として3ヶ⽉の開発を基本単位としています。その原則の中で、ウォーター
フォール型に近い⽅式での開発、アジャイル型に近い⽅式での開発、それぞれのチームの判断で
動いています。
# 0 3 - A

View Slide

#03. レガシー化の⼒学への対応 | 原則3ヶ⽉単位の開発計画
44
チーム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

View Slide

#03. レガシー化の⼒学への対応 | 新旧様々な技術スタックへの対応
45
「新旧様々な技術スタックへの対応」
医療業界において開発業務を推進していくにあたり、歴史のあるシステムとの連携が必要になるシー
ンも多く、新旧様々な技術スタックに柔軟に対応する必要があります。加えて、⻑期で利⽤頂くシス
テムを開発していることもふまえ、開発体制の持続可能性は常に考慮し、使⽤技術の陳腐化を避ける
ためにも、技術トレンドとの整合性を意識しながら、開発に取り組んでいます。
# 0 3 - B

View Slide

Ruby / Ruby on Rails /
Go / PHP / COBOL
JavaScript /TypeScript /
GraphQL / React.js / Next.js
Swift / Objective-C / Kotlin
#03. レガシー化の⼒学への対応 | 新旧様々な技術スタックへの対応
46
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

View Slide

医療業界アプローチの3つのポイント
47
複雑で膨⼤な
[Complexity]
[Quality]
レガシー化の
⼒学への対応
[Agility]
ある
1 2 3

View Slide

考察
〜DX時代のエンジニアに求められること〜
※ 株式会社⼀休のCTOである伊藤直也さんとの対話をふまえてまとめています

View Slide

IT業界の歴史の変遷
49
[1990年代以前]
業務システムを
実現するためのIT
[1990年代後半]
インターネット勃興期
[2000年代前半]
Googleの台頭
[2000年代後半]
Web2.0とガラケーの時代
[2010年代前半]
スマートフォン普及期
現在
[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 )
各種業務のデジタル化の結果として
社会的な影響を⽣み出すこと

View Slide

IT業界の歴史の変遷 | マクロな社会環境の変化
50
[1990年代以前]
[1990年代後半]
[2000年代前半]
Googleの台頭
[2000年代後半]
[2010年代前半]
[2010年代後半]
B2B SaaSの台頭
[2020年代前半]
1990 2010
2000 2020 2030
現在
技術進化による
⼀定の担保
IT分野における
2025年問題
2. 業界の複雑度の推移
1. (課題の⾼度化と複雑化)
1. 出⽣数の推移
1. (少⼦⾼齢化の加速)

View Slide

51
IT業界の歴史の変遷 | エンジニアに求められること

View Slide

SoR と SoE
52
特徴
(性向 / 適合)
システム領域
開発⼿法
プロダクト
マネジメント
ケイパビリティ
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系が得意そう

View Slide

SoR と SoE | 医療業界アプローチを踏まえての考察
53
特徴
(性向 / 適合)
システム領域
開発⼿法
プロダクト
マネジメント
ケイパビリティ
SoR：System of Record
1990年代 / 2000年代の主流
SoE：System of Engagement
2000年代 / 2010年代の主流
・安定性重視
・予測可能業務
・リスクを抑えて安全運転
・要件を事前に明確化
・バックエンド
・認証、在庫管理、決済、個⼈情報保護
・⽐較的ウォーターフォール寄り
・開発前に要件を明確に定義
・品質の確保を優先
・トップダウン寄り
・「正しい仕様」に基づいたプロジェクト管理
・経営や開発部⾨が主導することが多い
・要件定義⼒、調整⼒、プロジェクトマネジメント
・SIの皆さんが得意そう
・ユーザインタフェース品質、開発速度重視
・探索型業務
・スピード重視で運転
・トライ&エラー、プロトタイピング
・フロントエンド、スマートフォンアプリ
・UI、CRM、ダイレクトメール
・⽐較的アジャイル、リーン寄り
・トライ&エラーで正しい問題、論点を探り当てる
・迅速なリリースを優先
・ボトムアップ寄り
・「正しい仕様」は存在しない
・マーケティング、デザインが主導することも
・ユーザ視点、デザイン思考、アナリティクス
・Web系が得意そう
⾊塗：当社開発における重視ポイント
当社のアプローチ (医療DX) をSoRとSoEにマッピングすると以下のとおり。SoRに軸⾜を置きながらもSoEの⼿法を積極的に組み込んでいます。

View Slide

SoR と SoE | IT業界の歴史の変遷へのマッピング
CONFIDENTIAL 54
[1990年代以前]
[1990年代後半]
[2000年代前半]
Googleの台頭
[2000年代後半]
[2010年代前半]
[2010年代後半]
B2B SaaSの台頭
[2020年代前半]
1990 2010
2000 2020 2030
SoRの開発が
得意な⼈材が
活躍した時代
SoEの開発が
得意な⼈材が
活躍した時代
SoEの⼿法を
SoRの分野に
適応できる⼈材が
活躍する (だろう)
時代

View Slide

DX時代のエンジニアに求められること
55
#01 : SoEの⼿法をSoRの分野に適応できるスキル
ü コモディティ化した技術を、基礎理解も含め安定して扱えるスキルセット
ü UI/UXを重視したプロダクトをチームで作り上げた経験
ü 対象ドメインを深く理解し、技術的な⽂脈を考慮したディスカッションをビジネスパ
ートナーと共に⾏えること
#02: 開発者ひとりあたりの⽣産性の向上
ü セキュリティ要件含めた、複雑で膨⼤な要件に対して効率的にアプローチできること
ü また既存のプロセスにとらわれずに、効率的にアプローチするための新たな仕組みや
組織を構築できること

View Slide

DX時代のエンジニアに求められること | 原点回帰
56
2010年付近までの凄腕のエンジニアが
ひとりでなんとかやれるような時代は終わり、
あらためて⼈⽉の神話で話されているような
ソフトウェア開発の本質に
向き合う必要がでてきているように思います。
単に⼈が⾜りない、は思考停⽌している。
⽇本が課題先進国ともいわれるなかで、
開発者ひとりあたりの⽣産性を強化しないことには
⽇本のソフトウェア産業に未来はないと思っています。
これからの10年、開発者は開発者であることに
誇りをもって取り組んでいってほしいなと考えています。
“エンジニア (技術者) とは、
“⾃然科学や⼈⽂社会科学の知⾒を⽤いて
“安⼼安全な社会を実現する、
“という学術領域において、
“専⾨性を持った実践者である”

View Slide

メドレー平⼭の中央突破
https://toppa.medley.jp/

View Slide

まとめ

View Slide

〜医療業界へのアプローチを通じて〜
メドレーは医療業界に特化した様々なプロダクトを開発している会社です。医療業界は歴
史のある業界であり、いわゆるレガシーシステムが多く存在しています。法令や規制、商
慣習、医師とベンダーの関係性など、多様な課題が複合して、今の状態を作り出している
ため、アプローチが難しい状態となっています。そのような業界に対して、メドレーはど
のような開発チームで、どのようなプロダクトを展開し、アプローチしているかをお話し
ます。DXという⾔葉に注⽬が集まる中で、Web系かSI系かのいずれかではなく、その両
者の壁をこえる存在が求められているように思います。これからの10年に向けてのキャリ
アを考える上で、本セッションが参考になれば幸いです。

View Slide

まとめ
60
ü 医療業界では様々な課題が複雑に絡まっているためアプローチが難しく、その結果としてレガシー
が発⽣しがちである
ü そのような背景をふまえ、メドレーは以下3点に重きをおき、開発を進めている
Ø #01. 複雑で膨⼤な要件への迅速な対応
• 深いドメイン理解 / 要件設計における具体化・抽象化
Ø #02. セキュリティと品質の効率的な確保
• リーンな情報管理体制の構築 / QAプロセスの効率化 / 開発者モラリティの維持
Ø #03. レガシー化の⼒学への対応
• 原則3ヶ⽉単位の開発計画 /新旧様々な技術スタックへの対応
• IT業界の進化の歴史をふまえると、DXの潮流が進むことは必須
• そのような時代の中では、SoRとSoEのハイブリッドな開発⼈材が求められてくると考える。加え
て、ひとりあたりの⽣産性については「より強く」求められてくると考える
• 開発者は原点に⽴ち戻り頑張っていきたい

View Slide

さいごに

View Slide

“医療ヘルスケアの未来をつくる”
プロダクトをつくるひと
絶賛募集中
メドレーはプロダクトをつくることに誇りを持ち
社会や周囲の⼈たちに対して貢献しようとするホスピタリティをもった
PdM・エンジニア・デザイナーの⽅を募集してます
株式会社メドレー次世代に⽣きる⼈の医療のために

View Slide

「動画で⾒るメドレー」
(株式会社メドレーコーポレートサイト)
h t t p s : / / w w w . m e d l e y . j p / m o v i e /

View Slide

医療ヘルスケアの未来をつくる

View Slide

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

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

Medley Inc.

More Decks by Medley Inc.

Other Decks in Technology

Featured

Transcript

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

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

Medley Inc.

More Decks by Medley Inc.

Other Decks in Technology

Featured

Transcript

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

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