株式会社JMDC開発本部データ基盤開発部の中村と申します。
私が所属する医療機関基盤グループでは、昨年から今年にかけて基幹システムをオンプレからクラウド（AWS）へ刷新しました。

この移行プロジェクトは、JMDC史上トップを争うくらい難易度の高いプロジェクトだったと個人的に感じています。マネージャーの立場から今回のシステム刷新のきっかけや、プロジェクトのハードな道のり、そしてクラウド化で得られた成果などを振り返っていきます。

プロフィール
中村竜甫（https://twitter.com/rh1011_）
株式会社JMDC 開発本部 データ基盤開発部 医療機関データ基盤グループ マネージャー
SIerにて広告配信システムの企画・開発・運用を経験。その後2015年9月から現職。 基幹システムの刷新リーダーを担当後、Webプロダクト開発のマネージメントを経験。現在は医療機関基盤Gマネージャとしてデータ基盤の構築やプロダクト開発、組織強化などを担当。

医療機関データベースをJMDCの成長事業へ

私が所属する医療機関データ基盤グループについてお伝えする前に、JMDCのビッグデータ事業の全体像を俯瞰してみます。

JMDCが扱う主なビッグデータとして

① 保険者データベース
② 医療機関データベース

の2つがあります（下図参照）。

①の保険者データベース事業は、JMDCの祖業でもあり、現在も他社にはない優位性を確保しています。1000万人を超えるレセプトデータを保有し、独自の解析技術を発展させてきました。
（レセプト：医療機関が健康保険組合に医療費を請求するために、行った処置や使用した薬剤等を記載した診療報酬明細書）

一方、②の医療機関データベースは、約5年前にスタートした事業です。医療機関（総合病院、クリニック）からレセプトとDPC調査データ、そして検査値データを収集、データベース化して、医療機関向けの解析サービスやコンサルティングサービス、製薬・保険業界向け解析サービスなどに活用しています。当社では、この医療機関データベース事業を伸ばしていこうと注力しているところです。

そして、この医療機関データベースを構築・整備するのが、私がマネージャーを務める医療機関基盤グループの役割です。医療機関から収集したデータをクレンジングし、データレイク化して格納。これらのデータを社内のデータ解析部門やプロダクト開発部門へ連携しています。

医療機関データベースのCSVファイルの総量は約5.2テラバイトあり、40億レコードあるテーブルもあります。当社のデータ総量としては、保険者データに次ぐボリュームです。

AWS S3にデータレイクを構築

医療機関データ基盤は、オンプレで運用してきたのですが、2020年、クラウドへの移行を提案し、刷新プロジェクトがスタート。紆余曲折を経て、2021年10月に無事リリースしました。以下の構成図のように、AWS S3にデータレイクを構築しています。

今回、なぜクラウド化を進めることになったのか。 そのきっかけとなった、オンプレ運用を続けることで見えてきた限界についてお伝えしていきます。

従来のオンプレシステムが抱えていた3つの負債

オンプレ時代は、以下のようなシステムで構成されていました。

オンプレでのシステム運用を数年ほど運用していくうちに出てきた負債は、主に３つあります。

• 医療機関データベース事業は当初スモールスタートで始まったため、スケールアウトをあまり考慮しておらず、データ量が増加していった結果、データ処理性能が限界に近づいていたこと。
• 医療機関データの毎月の加工、構築処理に3週間かかっていたため、運用工数も膨れ上がっていた。理由として、Oracle基盤とIBM社製のNetezza基盤の2つのオンプレシステムで運用していたためシステム間のデータ転送にも時間がかかっていたこと、さらにデータ加工の一部はオンプレとクラウドが複雑に絡み合っていたため、更に無駄な処理フローが発生していたこと。
• 機能改修によりソースコードに手を入れていった結果、より難解なシステムとなり、調査や改修に非常に時間がかかるようになってしまったこと。

ソースコードに関しては、無駄な工程を増やす要因にもなっていました。既に複雑なシステムに対して、本来修正すべき途中の処理に手を入れると、膨大なデータに対して影響を確認する必要があるため、処理フローの最後の工程でパッチ処理を当て、特定のデータのみを補完するという悪循環を何度も行っていました。
本来あるべき開発とはほど遠いやり方になってしまっていたのです。

上記のような現場課題に加えて、医療機関向けサービス事業をより強化することになったのもクラウド化を決定した背景にあります。処理性能が追い付かないシステムのままでは、事業リスクにつながりかねません。

JMDCでは、以前より他のシステムでもクラウド化を進めてきました。そこで蓄積してきた知見を活かして、医療機関データ基盤もクラウド化を推進していくことにしました。

根気のいる作業に追われたクラウドへの刷新

クラウドへの移行プロジェクトは、2020年夏に5名体制でスタートしました。

私自身、プロジェクトのスタート時は別の部署でプロダクトの刷新を担当していましたが、2021年4月にプロジェクト責任者だった小森谷さんがCTOになったのを機に、後任としてプロジェクトのマネジメントを引き継ぎました。

引き継ぐ前から、このプロジェクトは相当ハードだと感じていました。今振り返っても「トップ3に入るくらい難易度の高いプロジェクトだったのではないか」と思っています。

その理由は先程のシステム負債でもご説明したものに加え、不足している医療知識のキャッチアップと根気のいる作業を両立させていく必要があったためです。

そもそも取り扱っている医療データ（レセプトデータ、DPCデータ(※）、検査データ等）は複雑で、かつそのままではデータの集計や解析は難しい。
このプロジェクトに新しくアサインされたメンバーも多く、全員が医療データに詳しいわけではなかったため、プロジェクト開始直後は、医療データのドメイン知識を習得していくところから始まりました。
(※）DPCデータ：患者の性別や生年月日、入退院年月日、病名・手術情報などのさまざまな診療録情報が記載されているデータ。

同時並行で、チーム内でPoCを実施。日々、クラウド上に格納されていく大量のファイルを処理するため、AWSのAthena、Glue、EMRを使ってのパフォーマンス検証と運用効率性の処理実験を行い、方針を確定しました。

その後、目の前にあるデータがなぜこのような状態になったのかをひも解いていく作業を進めました。これはオンプレシステムのソースコードを遡り、ひとつひとつ見ていかなければならないのですが、先程お伝えした通り過去のコードの解読が難しく、非常に骨の折れる作業でした。

なんとかコード解読を終えたのちに、あるべき処理フローをチーム内で設計し分担しながら少しずつコーディングとテストを行っていきました。

改めて、医療機関データは、特に品質に配慮が必要なデータです。

信頼性の高いデータと適切な解析結果があって初めて正しい評価結果を得る第一歩となるため、JMDCでは以下の観点で厳しくデータ品質の確保を行っています。

① データの信頼性
　データ匿名化、標準化後のデータと件数、内容を比較し信頼性を担保する

② 標準化の信頼性
　マッピング表やマスタを参照して正しい標準コードが付与されているかを担保する
　（例：傷病、医薬品、診療行為、用法、検体検査など）

③ 抽出機能の信頼性
　抽出/統計処理それぞれでダブルプログラミングを行い、信頼性を担保する

そのため、現行のロジックや品質チェック機能を念入りに調べて、従来のデータと一致させつつ、更に細かいチェックを追加実装し、より信頼性のあるデータを作り上げる必要がありました。

よってあらかたのテストが完了した後に、精度比較プログラムを作成し、差分原因を詳しく調査し、改修を施したのち再度このプログラムを使って検証するというサイクルを長い時間をかけて行いました。
この大量な新旧データの全件比較を短時間で完了させる比較プログラム自体の作成もかなり難易度の高い仕事でした。

このような難易度の高いプロジェクトを進めている最中も、既存システムの運用も当たり前ですが引き続き行っていたため、システムのトラブル対応も時折発生。メンバーにとっては、負荷が高く非常にタフな日々が続いている状況でした。

フリーランスエンジニアを採用し、チーム体制を強化

プロジェクトの状況を鑑みて私が最も意識したのが、メンバーが刷新PJに最大限集中できる環境をつくること（運用と刷新PJを両立しているメンバーの負荷を下げること）でした。そのために重視したのがチーム編成とステークホルダーとの調整です。

当時、私がマネージャーとして着任してからリリースまでの期限が6ヶ月ほどとタイトスケジュールだったこともあり、即戦力となるエンジニアを補完したいと考えました。

そこで、AWSとサーバーサイドに強いフリーランスのエンジニアをアサインしてチーム体制を強化することに。もともとJMDCでは、フリーランスのエージェント2社ほどとお付き合いがあったのですが、とにかく一刻も早くプロジェクトにマッチしたエンジニアとご縁を作りたかったので、ありとあらゆるエージェントにアプローチしていきました。2週間ほど採用活動に注力した結果、3名の優秀なエンジニアにジョインしてもらえることになりました。

また、周辺システム側とのI/O調整や、提供先システムでのデータ検証の協力依頼、刷新後の運用フローの説明、営業部署との質疑応答などのやり取りは私が巻き取ることができたため、もともと担当していたチームリーダーの負荷を少し下げることができました。私自身５年ほどJMDCに在籍し、色々な部署に異動した経緯もあり、信頼関係を築けている方々とのやり取りが多く、スムーズにこれらを進めることができたので、私の存在意義も少しは出せたかなと思います。（笑）

紆余曲折はあったものの、既存メンバーと新しく入ったメンバーの力のおかげで、2021年10月に、クラウド版をリリースさせることができました。
サービスインできたときの、メンバー全員の喜び様やあの時感じた安堵感は今も忘れられないですし、協力していただいた他部署の方々にも感謝しかないです。

そして何より、私が入る前からも苦労しながら刷新を推進してくれていたチームリーダがいなければ絶対に達成できなかったことなので、尊敬の念を本当に頂き、感謝でいっぱいです。

オンプレ→ クラウド移行で生産性が6倍以上アップ

とても難易度の高いプロジェクトではありましたが、AWSを利用することで大きな効果を発揮しています。

最も大きな成果は、スケールアウトや分散処理により、オンプレ時代、月次加工処理にかかっていた3週間（160時間）が1日程度（25時間）へ短縮できたことでしょう。実に生産性が6倍以上アップした計算になります。一方、金額面でのコストは従来より3分の1程度に抑えることができました。

将来的に、対象の病院数が数倍に増えても2〜3日で処理が終わるため、事業成長にも大きく貢献できる基盤ができあがりました。

また、本来あるべき処理フローに整理できたおかげで、改修もストレスなくスムーズに行えるようになったのもうれしい成果です。難解なソースコードに振り回されることがなくなり、業務の負荷がぐっと抑えられるようになったのはありがたいですね。

今回、Amazon S3でデータレイクを使ってみて改めて感じたのは、データを大量にため込めるうえに、運用がシンプルでスピードが速い非常に優秀なアーキテクチャであるということ。

例えば、S3にデータを置いたら、そこからAWS Glueを使ってAthenaでS3をもとにしたデータベースを即座に作ることができます。Athenaの処理性能が高いため、加工データを迅速に解析やプロダクト開発部門に展開できるようになりました。

今後、取り扱うデータが拡大しても、S3を使うことで理論上はデータを無限大に増やすことが可能です。データが拡大するにつれ、エンジニアの業務としては、AWS上でパフォーマンスチューニングに注力できるのが面白い点だと思います。

PoCにより、現在はAthenaを使っていますが、もし限界が来れば、Glue Sparkやレイクハウスアーキテクチャなど他のソリューションに切り替える選択肢も持てるようになりました。こうした技術選定に携われると思うと、ワクワクしますね。

難しい仕事をやり切ったからこそ、成長が加速した

今回のプロジェクトをやり遂げて、私やチームリーダー含め、全員がものすごく成長し、自信を付けたと感じます。クラウドの知識を習得し、スキルアップしたことはもちろん、何より精神的にタフになりました。このプロジェクトを乗り越えられたんだから、他にやってやれないことはないんじゃないかと本気で思います。それくらい強くなった。

きっと彼らは、今後、データレイクを使ったプロダクト開発や、他のクラウド移行でもリードメンバーとして活躍していけることでしょう。JMDCでは、他にもオンプレからクラウドへの刷新を進めている真っ只中にあります。だからこそ、成長につながる機会が多々あると改めて実感した次第です。

今後、医療機関データベース事業がさらに拡大していけば、これまでにない未知のデータを扱うようになる可能性もあるでしょう。病院で使われていないデータを掘り起こして、取り扱えるスケール性を持たせていければと考えています。まだまだ開拓できることはたくさんあります。成長著しい医療機関データベース事業に関われることに技術者として大きなやりがいを感じています。

最後までご覧いただきありがとうございました。
もし少しでも弊社にご興味をお持ちいただけましたら、こちらの採用ピッチ資料に詳しいことが記載してありますので、ぜひ一度ご覧ください。

https://drive.google.com/file/d/1nU_SwoUiGUvb7ZhPASNsjen1Xpp9GocP/view