医療業界向けの開発におけるメドレー流のポイントとは
メドレーが提供する医療プラットフォーム事業はSaaSを中心としたサービスの提供であり、同社事業の中核をなす。そのSaaSの1つである「CLINICS」は、病院の予約やオンライン診療、電子カルテ、レセコン（保険診療の点数を入力し診療報酬明細書を作成する）など、それまで独立して提供されることが多かった機能を1つにまとめて一括管理を可能にする。また調剤薬局向けには、オンラインによる服薬指導を行える「Pharms」といったサービスや、歯科向けのクラウド業務支援システムである「Dentis」も提供している。
平山氏は「歴史もレガシーも多数存在している医療業界において、私たちの開発チームが取り組んできた姿から、これからのエンジニアはどうあるべきか、見えてきたことがあります」とし、医療業界の特徴について説明した。
医療業界の一番の特徴は「計画経済」だ。需要と供給で価格が決まる「市場経済」と異なり、計画経済は国のコントロールで物流や価格が決まる。経済的に余裕のある人でも、そうでない人でも治療の機会を提供し、国民に不公平にならない配慮がなされている。このため法律や規制が多数存在している。
また、業界内を行き交うデータの理解が難しい点を挙げた。「病名、薬剤、病理臨床細胞、生理検査等々、そもそも単語がわからない」と平山氏は話す。このほか、歴史ゆえの古い商慣習や医師とベンダーの関係性など、学ばなければならないことがとても多い。その結果、新規参入が難しく、業界で使われるプロダクトはレガシーになりがちだ。
このような難しい業界に、同社サービスの開発陣はどう対応したか。平山氏は3つのポイントにまとめた。
- 複雑で膨大な要件への迅速な対応
- セキュリティと品質の効率的な確保
- レガシー化の力学への対応
1.複雑で膨大な要件への迅速な対応
医療業界には業界独特の遵守すべき法令・ガイドラインやレギュレーションが多い上に、解読が難解であることも少なくない。加えてリソースも潤沢ではない状況では、迅速な対応を優先することが大切だ。
ただし複雑で膨大な要件を理解する努力は惜しまず、医療分野に関する深い知識を大切にしている。医療業界は、そもそも言葉から難解で複雑な案件が多いので、要件定義に必要なコミュニケーションコストが膨らみがちだ。ここを抑えるには開発者自らが深い専門知識を持つことが重要である。
また迅速に対応するべく、ユーザーからの希望をそのまま受けるのではなく、ユーザーの業務フローを理解した上で、既存機能の改善か新機能の開発かなど対応方法を整理し、そこから新規開発・機能改善の実施を判断する。このときに「対応せず」という選択肢もありうる。いつまでもできる・できないで悩むことは避けたいからだ。
2.セキュリティと品質の効率的な確保
医療ではセンシティブな情報を扱う。そのため適切な情報管理体制やソフトウェア自身にも高い品質が要求される。要求に対して効率的に行う必要があるし、さらに何が効率的かを忘れないようにすることも重要だ。
例えば先のCLINICS開発では、同社はISMSクラウドセキュリティ認証、ISO227017を取得している。これらの認証取得を支援するサービスがあり、その雛形に合わせて手間をかければ取得することはできる。しかし同社では、手間が増えるような手法では本当の効率は目指せないとし、ISO規格の要求事項を本質的に満たすための方法を徹底的に考え、ゼロベースで取得を目指した。
そのため、一般には設置が必須とされる社内の情報セキュリティ委員会なども、「それは本当に必要か？」と検討し、あえて設置せずといった判断を下し、余分な贅肉を削ぎ落としたISO取得を達成した。他にも効率を目指すためにQAプロセスでのテスト自動化の取り組みや、開発者の業務をあまり細分化せずに「セキュリティは自分の担当じゃないから」という意識に陥らないようなモラルの育成も目指した。
3.レガシー化の力学への対応
システムは作った時は最新でも、時の経過によって実情に合わなくなる。これを「レガシー化の力学」と呼び、同社ではこれを避ける開発の工夫を行っている。その1つは、3カ月単位の開発だ。長期のプロジェクトも短期の場合でも、すべて開発は3カ月を区切りとし、その区切りの中でチーム毎にウォーターフォール型に近い方式、アジャイル型に近い方式どちらが良いか判断して開発している。例えば長期に渡るプロジェクトであっても3ヶ月の区切りでマイルストーンを置き開発をしていく。区切りを保つことで、区切りの単位ごとに開発計画や人員配置の調整を可能にできる。そのためチームや技術が固定化しすぎない、良い塩梅の配置が取れるので、レガシー化しにくい開発が目指せる。
とはいえ、メドレーの提供するSaaSプロダクトと院内の医療機器との接続をするため、既存技術との連携についても常に意識している。こうした従来技術も含めて技術トレンドとの整合性なども考慮し、技術が陳腐化しないようにプロダクト開発をしている。
これからは過去の遺産を、最新のUIやUXの技法で活性化できるエンジニアが求められる
平山氏は、同社開発陣の対応についてまとめる中で、これからのエンジニアのあり方について見えてきたものがあるとし、その説明を行った。
2000年以前のITでは、メインフレームなどオープン系が中心で、インターネットが始まったばかりとして、この時代を「SoR（System of Record、記録を重視）」と説明した。対して2000年以降はインターネットが爆発し、スマートフォンの台頭で世界がネットでつながった時代として、「SoE（System of Engagement、システムとユーザーとのつながりを重視）」とした。
ITのトレンドをSoRとSoEという2つに分けた上で、SoRの特徴は、安全性重視、領域としてはバックエンドや決済系、開発はウォーターフォール、プロジェクトマネージメントとしてはトップダウン、正しい仕様に基づくもの、要件定義、プロジェクトマネジメントとした。
一方でSoEの特徴は、ユーザーインターフェース重視と、トライアンドエラー、システム領域としてはフロントエンド、開発方式としてはアジャイル、プロダクトマネジメントはボトムアップ、正しい仕様は作って探る、ケイパビリティとしてはデザイン思考とユーザー志向とした。
平山氏は、ITの発展を振り返り、それを同社の開発チームの特徴に当てはめると、多くの特徴がSoEとSoRの両方に見られたと語った。電子カルテを扱うため「安全性を重視」しながら、プロダクトマネジメントでは医療業界のニーズという「トップダウン」で動く部分はSoR、迅速な開発で現場のデジタル化を目指し「ユーザーインターフェースや開発速度を重視」する点や、要件定義では「デザイン」を優先し時には「対応しない」といった部分はSoEと、両方のポイントを持っていると説明した。
2000年以降、インターネットが先進諸国だけでなく世界的に普及してきたころ、ITの主戦場はSoRからSoE主流になってきたと言える。Record（資産）を保管・整理することより、どう使うかが重視され、必要なエンジニアもSoRからSoEタイプになってきた。しかし、Engagementもある程度の成熟を達成した中で、次に求められるのは、大切に築き上げたSoRの世界にSoEを加えることではないかと平山氏は示した。
「1990年頃は、SoRの開発人材が活躍しました。それが2000年代ぐらいになると、いわゆるSoEの開発人材が活用した時代になったと思います。そして、これからはSoEの手法をSoRの分野に適応できる人材が活躍する時代ではと思います」（平山氏）
平山氏は、SoEの手法をSoRの分野に適応できる人材を明確にするために、必要なスキルを挙げた。
- コモディティ化した技術を、基礎理解も含めて安定して扱えるスキル。
- UI/UXを重視したプロダクトをチームで作り上げた経験。
- 対象ドメインを深く理解し、技術的な文脈を考慮し、ビジネスパートナーと共に議論できる。
加えて、少子高齢化による働き手の減少を考えると、エンジニアは1人あたりの生産性をもっと向上させるアプローチや組織作りが必要だとした。
このような状況を平山氏は、人月の縛りを捨ててソフトウェア開発の本質に向き合う時期であるとし、「"エンジニア、技術者とは、自然科学や人文社会科学の知見を用いて安心安全な社会を実現するという学術領域において専門性を持った実践者である"と、普通のことですが改めてこの原点に従って、ソースコードの1行1行に向き合うなど頑張っていければと思います」と述べ、講演を締めくくった。
