JMDC TECH BLOG

JMDCのエンジニアブログです

ヘルスビッグデータ分析サービスの複数のプロダクトを統合した話

みなさん、こんにちは!株式会社JMDC プロダクト開発部 製薬システム開発グループの関田です。

現在、当社が製薬会社様向けに提供しているヘルスビッグデータ分析サービス JMDC Data Mart のバックエンド開発を担当しています。

今年、JMDCではアドベントカレンダーに参加しています。

qiita.com

本記事は、JMDC Advent Calendar 2025 17日目の記事です。

はじめに

私が所属しているチームでは、冒頭でお伝えした製薬会社様向けヘルスビッグデータ分析サービス JMDC Data Mart(以降、JDM)の開発・運用を行っています。
JDM は、ローンチから18年目を迎え、今も当社の売り上げに大きく貢献しているサービスの一つです。

本年度、長年の課題であった、JDM の複数のプロダクトの統合が完了し、無事リリースを迎えることができました。
この記事では、この複数のプロダクトを統合した際のお話をしたいと思います。

「複数のプロダクト」とは

当社は、健康保険組合由来の「保険者データ」、病院・診療所など医療機関由来の「医療機関データ」、調剤薬局由来の「調剤データ」を保有しております。
これらのデータの運用を開始する都度、専用の分析サービスを開発してきたため、

  • 保険者データ版 JDM
  • 医療機関データ版 JDM
  • 調剤データ版 JDM

と、取り扱うデータベースごとに、複数のプロダクトが独立している状態でした。

プロダクトが独立していることの課題

お客様の中には、複数のデータベースにご契約いただいている企業様もいらっしゃるのですが、プロダクトが独立しているために、ご利用いただく上でご不便をおかけしている状態でした。
例えば、プロダクトごとにアカウントを使い分ける必要があるため、保険者データと医療機関データの分析結果を比較したい場合、各プロダクトに個別にログインし、同じ分析条件を入力した上で分析を実行していただく必要があるなど、データベースの横断的な分析をシームレスに行うことができない状態でした。

これでは、保険者・医療機関・調剤の3つのデータベースを保有している利点を生かし切れているとは言えません。
また、共通の変更を行う際にも、各プロダクトに対し変更・リリースを行う必要があり、メンテナンス性の面でも課題のある状態でした。

そのため、データベースごとに独立している複数のプロダクトの統合が急務な課題となっていました。

いざ、統合

そして 2024 年、プロダクト統合のプロジェクトがスタートしました。
まず取り掛かったのは、統合の開発をスムーズに進めるため、バックエンドの開発環境を最新の技術スタックへ移行することでした。

技術スタックを刷新

現行のシステムは、開発言語は C# ですが、フレームワークが .NET Framework、ORM は iBatis とレガシーな環境かつ、自動テストを導入していなかったため、開発効率やメンテナンス性の面で大きな課題がありました。

統合プロジェクトでは、開発言語に Go、ORM には Bun を採用し、Docker・テストライブラリも導入しました。モダンな開発環境と自動テストの導入により、一気に開発効率とメンテナンス面の課題をクリアすることができました。

Go は文法がシンプルかつ、特定の書き方を推奨する設計思想のため、チーム内でコードを書く人や時期が変わっても、可読性と保守性の高い、一貫したコードベースを維持しやすくなったと思います。(あとはシンプルにモダンな言語に触れることで気持ちが上がるという効果も...)

Bun の採用により、SQL を直接記述するのに近い感覚で Go で記述することができ、言語コードとは別に XML ファイルで SQL を定義する形式だった現行システムと比べ、直感的に SQL をコーディングできるようになりました。

Docker や自動テストの導入は、いつでもどこでもユニットテストが行える環境を実現するとともに、技術的・心理的な安全性を確保し、日常的に躊躇なくリファクタリングを実施できる体制が取れるようになったことで、その面でも持続可能なコードベースを維持しやすい環境が整いました。

なお、自分も含め既存メンバーの技術スタックに Go はなかったのですが、Go のテックリードや習熟度の高いメンバーの加入、及び丁寧なオンボーディングにより、徐々に理解を深めていくことができました。
また、加入メンバーに不足しているドメイン情報は既存メンバーがキャッチアップを支援し、お互いに不足している部分を補いつつ進められていたので、チーム一丸となってプロジェクトを進行できていることを実感しました。

リプレースにおいて重視したこと

プロダクト統合の開発自体は、後発プロダクトで UI 刷新済みの調剤データ版 JDM のバックエンドを、C# から Go へリプレースし統合基盤とすることから開始しました。
そのリプレースの際に特に重視したのは、「闇雲な共通化をやめる」という点です。

現行のシステムでは、たまたま姿が同じだったり似通っているという理由で共通化されている箇所が散見されていました。こういった共通化は、使用箇所の目的や役割が異なることも多く、意図せず処理同士の結合が密となり、時とともに引数の追加や分岐による複雑性を生み出すことで、メンテナンス性や可読性を下げる要因になっていました。

統合プロジェクトでは、チームで同期のコードリーディングを実施し現行システムの仕組みへの理解を深めつつ、目的や役割を一とする箇所のみ共通化するように努め、それ以外の箇所については冗長とは見なさず、敢えてそれぞれの処理の中に見た目上同じだったり類似するコードを記述する方針としました。

この方針により、現行システムに比べコードの見通しは格段に上がり、かつ各処理の結合度が下がり、変更に伴う意図せぬ副作用も発生しづらい構造にすることができました。


このように1プロダクトずつリプレースしつつ基盤への統合を進めていき、ついに 2025年7月、統合版 JDM のリリースを迎えることができました!

www.jmdc.co.jp

統合を終えて

こうしてプロダクトの統合を終え、1プロダクトで複数データベースの分析を可能にする、という積年の大きな目標を達成することができました。
お客様からのフィードバックも好印象で、運用改善にも繋がるなど、ひとまず統合プロジェクトは成功という形で完遂されました。

とはいえまだまだ残された課題は多く、この先も、お客様をはじめ、ステークホルダーにより愛されるプロダクトを目指し、日々精進して参りたいと思います!


最後まで読んでいただきありがとうございました!

明日18日目は、古橋さんによる「AWS ConfigとSlack連携によるS3バケットポリシー変更監視」です。お楽しみに!

JMDCでは、ヘルスケア領域の課題解決に一緒に取り組んでいただける方を積極採用中です!フロントエンド /バックエンド/ データベースエンジニア等、様々なポジションで募集をしています。詳細は下記の募集一覧からご確認ください。 hrmos.co

まずはカジュアルにJMDCメンバーと話してみたい/経験が活かせそうなポジションの話を聞いてみたい等ございましたら、下記よりエントリーいただけますと幸いです。 hrmos.co

★最新記事のお知らせはぜひ X(Twitter)、またはBlueskyをご覧ください! twitter.com bsky.app