医療DXのヘンリーの開発トップにインタビュー。モノリスからマイクロサービスに回帰する背景とは？

クラウドベースの電子カルテ＆レセプトソリューションを開発提供する株式会社ヘンリーの開発部門のトップ（VP of Product、執行役員 製品部門長）である縣直道氏にインタビューを行った。このインタビューのきっかけは筆者が審査員を務めるCloud Native Operator Days Tokyo 2025のオフラインイベントが2025年9月5日に開かれた際に、ヘンリーがブースを出展していたことである。他のツールベンダーやインテグレーターとは異なり、医療関係のアプリケーションベンダーがクラウド系のカンファレンスに参加して展示を行っていたその背景やシステム開発の状況を聞きたいというのがこのインタビューの趣旨だ。

私が審査員をやっていたイベントで、いかにも暇そうなブースを出していたのがヘンリーさんなんですが、あの展示の目的は？

縣：あれはそもそもSREのリクルーティングのための出展だったんですが、ちょっと他のブースとは異なっていましたね。でも盛り上がっている時間もあったので、ずっと暇だったんじゃなくてちゃんと盛り上がっていた時間もあったって書いといてください（笑）。

ヘンリーの開発部門のトップである縣直道氏

縣さんは製品開発のトップということですが、今のヘンリーのシステムについて伺う前にそもそもどうして電子カルテのシステムをやろうと思ったのかを教えてください。医療系システムというレガシーな会社が寡占している分野に、ベンチャーであるヘンリーが切り込んだのは、かなりチャレンジングに見えるのですが。

縣：前職のウォンテッドリーで一緒に仕事をしていた創業者が、社会に良いことをしたい、社会に価値を提供したいと考えて、その具体的な形が医療DXだったということですね。私もヘンリーに入るまでは、医療関係のシステムの知識はゼロだったんですが、開発部門には医療ドメインの知識と経験を持っている人がいるので、彼らから学んでいるという感じです。

オンプレミスではなくクラウドベースであるというのは、医療関係のシステムでは珍しいと思うんですが、その意図は？

縣：前職での開発の経験から、システムを作るならWebベースのSaaSでやるというのが当然の発想だったので、自然とそういう選択になったというのが正直なところです。またオンプレミスのシステムだと、世の中に続々出てくる良い発明や新しくて使いやすいツールと連携するようなことはかなり困難で、そこと切り離されてしまうので進化に取り残されてしまうというのもクラウドを選択した理由の一つですね。

我々のシステムは電子カルテとレセプトシステムを機能として備えていますが、実際にはコミュニケーションのためのツール、例えば病院のスタッフ同士のチャットのような機能も電子カルテの要件として挙げられています。でもそれって電子カルテの中で実現しなくても、機能としてGoogle Workspaceのチャットでやっても良いはずなんですよ。実際にヘンリーのシステムを導入している例では、電子カルテの他にGoogleのアプリをフル活用している病院もあります。

もう一つの大きな理由はセキュリティですね。最近のランサムウェアの例を調べると、被害にあっているのはほぼオンプレミスで通信はVPNというシステムなのです。つまり閉域で閉じてセキュリティを確保しようとしても、完全に守ることは事実上無理だと私は思っています。それよりはパブリッククラウドベースでセキュリティを担保することでセキュリティを実現できる、それがベストな形だと信じています。

クラウドベースで開発することが自然な発想だったと語る縣氏（中央）

日本では東日本大震災の時に東北地方の企業が持っていたオフコンやサーバーが津波で流されて事業継続が非常に難しくなったことからオンプレで持つよりはクラウド側に預けた方が安心だというある意味、カルチャーショックのようなことが起こって以来、クラウドでビジネスシステムを構築するというハードルは低くなりましたね。ところでヘンリーのシステムは病院向けの電子カルテとレセプトシステム、つまり医療と会計に関わるシステムということですが、ターゲットはまだ紙で業務を行っている病院なんですか？

縣：日本では、電子化が進んでいない病院というのはまだ半分くらいあるんですよね。大手の病院ではかなり進んでいますが、日本の医療を支えている中小の病院というのはそのくらいのシステム化率なんです。我々は当初、クリニック向けのシステムを開発して提供しましたが、やっぱり病院向け、つまり入院患者さんを受け入れる医療をやっている組織をシステム化、電子化しないと日本の医療は良くならないと思って開発を行っています。

現在は社員数が120名、そのうち開発は40名くらいでリモート開発を行っています。最初はドメイン知識がなかったので、創業者の知り合いの医師の病院に参加して知識を獲得して、システムを開発したという経緯があります。実際には電子カルテを初めて導入するという病院もありますが、すでに電子カルテが入っている病院のシステムを入れ替えるという形態も多くあります。

現在のシステムはクラウドベースということですが、プラットフォームは何ですか？

縣：インフラストラクチャーとしてはGoogle Cloudを使っています。でも将来的にAWSに移行する予定です。バックエンドはKotlinでサービスを書いてフロントエンドはReactですね。データベースもPostgreSQLでコンテナ実行環境はCloud Runです。極々普通のWebサービスであることを外さないように意識しています。医療関係のシステムというと、ソフトウェアエンジニアからは難しそうとか独特のシステムのように思われるかもしれませんが、システム自体は普通のWebサービスなんです！ 外部のエンジニア向けにはそのようにプレゼンテーションしてますね（笑）。

ということはクラウドネイティブっぽいマイクロサービスなんですか？

縣：そうですと言いたいところですが、違います。開発当初はサーバーを2つに分けてAPIでコールする形で実装していたんですが、業務知識を獲得してそれをシステムに落とし込む時にどうしても会計系と診療系、つまり電子カルテシステムの中でマイクロサービス化するのが難しくなってしまったので、現在は大きなコードベースでモノリシックなシステムとして構成されています。これはクリニック向けのシステムから病院向けのシステムに進化する時に実装しなければいけない機能について、マイクロサービス的に分割することが難しいことがわかったということで、当初は2つのサービスに分かれていたものをもう一度、ひとつのコードとして再構成したという経緯があります。

システムとしては大きなコードベースで開発をしているとするとチーム体制はどうなっているんですか？

縣：現在は大きく2つに分かれています。臨床系の電子カルテのシステムとレセプトの会計系のシステムですね。それぞれのシステムの中も2つに分かれているので、大きく言うと4つのチームが開発しているということになります。

SaaSのアプリケーションであるということはアジャイルっぽく「機能が追加されたら即座に顧客のシステムに反映される」ということは実施しているんですか？

縣：実際には病院で使っている人の状況に応じてそこは調整しているという感じですね。それぞれのチームが開発をやっているので、新機能をリリースする際に大きめのリリースが重なってしまうと受け入れる側の準備も必要になります。その部分については開発部門の中のデリバリーというチームがあって、そこがきめ細かに病院の状況を見据えて最適なタイミングで使って更新するということを実施しています。そのチームはもともと顧客の導入作業を行うチームで、どうやったらスムーズに導入ができるかを考えて実行するのが仕事だったんですが、それをシステム更新の部分にも応用するということですね。

モノリシックなシステムだとビルドやテストにすごく時間がかかりそうな気がしますが、その点で問題はないんですか？

縣：ヘンリーが使っているKotlinのビルドシステムは、Gradle社が作っているGradleというビルドシステムにお世話になっている形ですね。依存関係の管理や部分的にビルドしてテストを行うなどの使い易い機能があるので、モノリシックではあるもののその部分については問題ないですね。

実際に今直面している問題、課題は何ですか？

縣：現在のヘンリーのシステムはモノリシック、モジュラーモノリスというのが正確な言葉だと思いますが、それをもう一度、マイクロサービスに移行しなければいけない時期が来ていると考えています。電子カルテのシステムというのは機能要件がものすごく多いのです。しかも診療報酬制度の改定というのが2年に一度必ずありますので常にシステムを更新していかないといけないという運命にあります。その状態でモノリシックのままで良いんだろうか？ という疑問です。

またこれからはAIをシステムに組み込んでいくということも必要になるでしょう。そうするとやはりマイクロサービスのほうが向いていると思うんですね。ヘンリーのシステムってコード自体を書くという作業よりも、業務に必要な機能要件を理解してそれを設計するという部分の仕事がすごく多いのです。そこができればコードを書くという仕事はかなり楽になるはずなんです。人によってはそういう部分も含めてコーディングという人もいますが、私はそこの部分におもしろさというかエンジニアの醍醐味があると感じているので、それを最速でやるとしたらどんなシステムが良いのか？ これについて考えないといけないと思っています。

業務をマイクロサービスで実装したらそれらの修正や機能追加の際に素早く行えるというのが利点ですが、それをモノリシックなシステムに応用してもマイクロサービスよりも速くはならないと思うんですよね。なので開発のスピードを速めるためにはマイクロサービス化が必要だと。それが今、やらないといけないことじゃないかなと。

モノリスからマイクロサービスに移行を検討中

よく開発部門の中にR＆Dというか調査したり実験したりする部門がありますが、そういう試験的にチャレンジするみたいな部門はあるんですか？

縣：今はそれがないのでそれを作りたいと思っているところなんですよ。現在は全員がアプリケーションの開発とインフラのほうに向かっているので。そういう実験だけをやるエンジニアという役目が必要ですね。なので課題は開発のスピードを爆発的に加速すること、そのためのエンジニアのリクルーティングです。社会を変えることに興味があるエンジニアはぜひ、話を聞きに来てください！

クラウドベースのSaaSで電子カルテとレセプトシステムを開発するヘンリーは、当初のマイクロサービス指向から機能要件の実装のためにモノリシックなシステムに移行して開発を行っているという。しかし、やはりマイクロサービス化の流れが必要であろうと製品開発のトップが指摘していることは重要だ。システムの課金ロジックもベッド数やレセプト数という従来のレガシーなシステムに沿った発想から、病院全体の収益からの比率にしたいと語るのは、実際に病院のタイプによってはそれが顧客にとって最適なロジックだからという。それらのシステムの更新を続けるためにもマイクロサービス化は避けて通れないということだろう。ヘンリーの将来を引き続き注目していきたい。