こんにちは！ヘンリーでソフトウェアエンジニアをしている @agatan です。
ヘンリーでは、医事会計システム一体型の電子カルテ Henry を開発しています。
この記事では、ヘンリーでソフトウェアエンジニアとして働く上での挑戦や面白さをご紹介したいと思います。
ヘンリーの生み出すプロダクトやビジネスの社会的意義など、ヘンリーで働くモチベーションとなる要素はたくさんあるのですが、あえて今回はエンジニアリングの面白さに焦点を当てて、なぜ僕は Henry の開発を楽しいと感じているのか・どこがチャレンジングなのか、について書いてみます。
「ここが難しい！」という話が多くなっているのですが、難しさは挑戦の種でもあるので、興味を持っていただけるとうれしいです！
（また、今回はエンジニアリングに焦点を当てていますが、僕個人としては、何よりも社会的意義とそれを目指したときのビジネス面の勝ち筋がきれいに整合していることに強く惹かれています。 そういったヘンリーの魅力については、株式会社ヘンリーのカレンダー | Advent Calendar 2023 - Qiita や Henry｜note の記事をぜひご覧いただければと思います。）
この記事は 株式会社ヘンリー Advent Calendar 2023 20日目の記事です。19日目は 今年も組織が1.5倍に！リモートワーク中心で拡大し続けているスタートアップのコミュニケーション設計｜Henry でした。 qiita.com
Henry の技術スタック
前提として Henry を構成する技術について軽くご紹介します。 （少し古い & バックエンド中心の話限定ですが）こちらに以前登壇した際の資料があります。
上記に記載のないものも含め、粒度もバラバラにざっくりまとめると
- インフラ .. GCP (Cloud Run, PostgreSQL on Cloud SQL, Cloud Pub/Sub, etc...)
- バックエンド .. gRPC w/ Kotlin, GraphQL w/ TypeScript (BFF)
- フロントエンド .. Next.js
- CI/CD .. GitHub Actions, CircleCI
- データ基盤 .. dbt, BigQuery
- ほかにも...
- OpenTelemetry
- Mabl, Chromatic を使った自動テスト環境
- etc...
（株式会社ヘンリーの技術スタック - what we use（技術スタックデータベース） にもうすこし詳細に利用しているものが載っています。）
見ていただいて分かる通り、割と普通のWebアプリケーションの構成をしています。 電子カルテというと馴染みのなさそうな雰囲気を覚える方もいらっしゃるかもしれませんが、技術的にはやっていることは概ね普通のWebアプリケーション開発です。
シンプルに開発が難しい！ので見せ場がたくさんある！
電子カルテ・医事会計システムとは、病院における業務基幹システムです。 ご存知の通り、病院にはさまざまな職種（医師、看護師、医療事務、検査技師、etc...）の方がいらっしゃいます。 専門職の方々が、互いに情報をやりとりしながらご自身の専門業務を遂行しています。
それぞれの業務は専門性の高い業務であり、単体で見ても複雑で難易度の高い一つのドメインです。 継続的に、より高い価値を届け続けるためのソフトウェアを開発するためには、そもそも開発対象を深く理解し、それをモデリングする・改善し続けることに心血を注ぐ必要があります。
CRUDとは一線を画す複雑さがあったり、最終的に作るものがCRUDであっても「何をCRUDするのか」を見つめ直さないと適切なモデリングにならないことが多々あります。 開発そのものが単調になることが少なく、純粋に作る部分だけを取り出しても腕の見せどころが比較的多い環境だと思います。
診療報酬制度を解きほぐす面白さ
日本には、診療報酬制度というものがあります。（ なるほど診療報酬！｜国民のみなさまへ｜日本医師会 ）
診療報酬制度では、保険医療の価格や、ある保険医療を実施するために医療機関が満たしているべき条件、提出すべき書類などが定められています。
ものによっては、継続的に統計データを提出する必要があったり、入院中の患者に対して日々記録を取っておく必要があったりします。
ルールの数も多いのですが、個々のルールについて読み解くのも非常に難しく、これをモデリングする作業には、パズルや謎解き的な面白さがあります。 きれいにモデリングできたときには、ものすごく気持ちよくなれます。
（また、診療報酬制度に詳しくなることは、雑学的な面白さもあります。診療報酬制度には、日本の医療の将来を見据えて方向性を示す役割があるため、これを知っておくと少し日本の将来について詳しくなった気分になることができます。）
巨大になっていくシステムをどうチームでさばくか
また、個々の業務・ドメイン単体で見た時の難易度もさることながら、ドメイン同士が深く高密度に連携している、というのも、医療の業務基幹システムの特徴です。 一人の患者に対して、様々な専門職が関わるため、それをスムーズに接続する必要があるのです。
さらにすこし違う視点から見ると、診療報酬制度を核とした結合も強く存在します。
僕自身は、診療報酬制度をもとに会計業務を行うための「医事会計システム」側のコンポーネントを開発しているのですが、診療報酬制度に関わる業務というのは、会計時だけでなく例えば日々の看護においても発生します。
そのため、きれいにシステムやチームを分割することが難しく、開発難易度を上げる要素となってしまっています。
こうしたある種偶発的な複雑さに起因する難しさは、あまり純粋に楽しめるものではないと思いますが、それを乗り越えるために改善の手を考え実行し続けるチームの存在や文化がある環境というのは、とても働きがいがあります。 チームとして、学習して手を打ち続けることが重要だと考えており、実際これまでにチーム分割やモノレポ化などの手を打ってきました。
また、1プロダクトでありながら実質的に複数のドメインが共存しているため、そもそもシステム自体のサイズが巨大です。
僕自身、すでに2.5年開発をしていますが、システムのすべてを把握できているかというとやや怪しく、詳しく内容を知らないコンポーネントも増えていっています。 どれも顧客にとって重要な機能であり、まだまだ足りていない機能もあるなかで、きちんと開発が健全に進んでいる証ではあります。 これも、プロダクトや組織が成長していくなかで、どのようにスケールする体制を作っていくか、という挑戦に繋がっています。
パフォーマンスの維持
業務で日々使うソフトウェアなので、当然スムーズに動作することが求められます。 Henry でもこれまで Next.js への移行などパフォーマンス向上のための手を打ってきました。
Henry はいままでもこれからもどんどん進化していくプロダクトです。 システムの全体像を把握するのが難しいなかで、進化の過程で入る変更は、どうしても局所的な視点での変更になりがちです。
たとえば、「外来会計確定」というイベントをトリガーに走る処理は、この1年でも3,4つ増えています。 それぞれのイベントは、それぞれの業務ドメインを持っていて、 当初は1,2つ程度しかなかった処理だったために同期的に処理していたイベントでしたが、徐々に限界を迎えつつあり、根本的にアーキテクチャを見直す必要も出てきています。
また、「あっちで個別に処理していた内容を、こっちの月次一括処理でも同じことをしたい」というようなケースもあります。 診療報酬制度を中心に、業務が密結合しているため、どうしてもドメインをまたいだ共通処理が出てきてしまいます。 それぞれのドメインが十分に複雑であるため、ドメインをまたいで処理を共通化しようとしたときに、内部実装を細かく知らない状態で共通化してしまったりすると、後々パフォーマンスインシデントでえらい目にあったりします。
意識的に全体の状況を俯瞰する時間を取ることで、対処が必要であることに気づいたり、どういう手を打つべきかを考えるようにしています。 （冷静に俯瞰すれば、実際に問題になっているのは単純な N+1 だったりもするので、気づくこと・手を打つべきと判断することがメインの挑戦といえるかもしれません。）
Reliability
業務基幹システムであり、かつ医療の現場が使うサービスであることを考えると、信頼性も非常に重要です。 障害に対する備えはもちろんですが、日々の開発においても、互換性を維持したデプロイができるように意識したり、自動テストを拡充したりと、考えることがたくさんあります。
また、信頼性は高いに越したことはもちろんないのですが、ガチガチに固めればいいというわけでもありません。同時に開発生産性を高める意識をもって取り組まないと、最終的にはお客様の利益を害する結果に繋がってしまいます。我々は後発であるがゆえに、モダンな開発体制を築き、高い開発力を活かして、スピーディにサービスをより良くしていくことが求められています。
ここについては、まだまだヘンリーとしても取り組むべき課題がたくさんありますが、ポストモーテムの取り組みや障害対応のプラクティスの共有、自動テストの拡充とそのプラクティスの共有など、SREチーム / QAチームを筆頭に改善が続いています。
診療報酬改定
先に述べた「診療報酬制度」は、二年に一度改定されます。
改定の内容は年ごとに大小さまざまですが、Henry というプロダクトの根拠の一つである診療報酬制度が変わる、ということがプロダクトに与える影響は甚大です。（医事会計システムはもちろんですが、電子カルテ側も取る記録の内容がかわったりするため、多大な影響を受けます。）
したがって、二年に一度、（規模はそのときどきによって変わるようですが）大きな変更を迫られることになります。
さらにややこしいことに、改定後であっても、改定前の診療や会計の情報は閲覧・編集したいので、改定前の状態も同時にサポートする必要があります。 診療の記録にはデータ保全の義務があるため、データの寿命は非常に長く、互換性を維持した設計を心がける必要があります。
このあたりに気を使って開発をし、安全にリリースさせる、というのは、ソフトウェアエンジニアの腕の見せどころの一つだと思います。 （一例ですが、ダウンタイムなくデータのマイグレーションやミドルウェアのリプレースを行うために、知識や技術力を発揮することは、ソフトウェアエンジニアの本懐の一つといってもいいのではないでしょうか。）
また、まだまだ電子カルテ業界ではオンプレ・個別対応開発が主流となっています。 Henry はクラウドベースの SaaS という提供形態をとっているため、オンプレや個別対応の開発を行っているプロダクトと比較すると、明確に対応コストが下がっています。 自動テストなど、きちんと開発環境・体制のベストプラクティスを適用することで、我々の対応コストを下げると同時に、競争優位性も築くことができます。
エンジニアリングによって明確な競争優位性を作れるというのも、ヘンリーでエンジニアをする上でやりがいを感じるポイントになっています。
ドメインエキスパートとの協業を前提とした開発体制・プロセス
Henry を作るためには、非常に深いドメイン知識が求められます。 「なにを作るか」「どう作るか」「作ったものが正しく動いているか」などなど、開発を行う上で出てくるほとんどすべてのステップにおいて、ドメイン知識が求められますが、求められるドメイン知識のレベルは非常に高く、習得難易度も高いです。 （わかりやすいところでいうと、診療報酬制度をまとめた書籍「診療点数早見表 2023年4月増補版」は、1,760ページあります。）
そこで、ヘンリーでは、開発チームの中にドメインエキスパートが在籍しており、一緒になって仕様やモデリングを考えたり、動作検証をしてくれたりしています。
もちろんソフトウェアエンジニア自身もドメインを学ぶ活動は活発に実践されていますが、それでも経験豊富で強力なドメインエキスパートがいてくれることの心強さが非常に大きいです。 ドメインエキスパートが開発チーム内にいてくれるおかげで Henry の開発は進んでおり、もしドメインエキスパートがいなければ僕自身も泣きながら開発をしているのではないかと思います。 ここまで複雑でソフトウェアに落とし込む作業自体が難しい領域で、ここまでの手厚い体制が提供された状態で、エンジニアリングに向き合えるというのは、非常に希少な環境なのではないでしょうか。
さらにいえば、ヘンリーの開発体制は、まだまだドメインエキスパートのちからを最大限引き出せてはいないと感じています。 一部では、ドメインエキスパートがエンジニアの書くテストケースをレビューしたり、ドメインエキスパートが作ったテストケースを自動テストに組み込んだりするといった取り組みが進んでいますが、もっともっとこれを推し進めていくことで、直にドメインエキスパートがプロダクトを前に進められるような環境をつくれるのではないかと考えています。 まだまだ夢物語ではありますが、これが達成できれば圧倒的な強みになると思いますし、これも大きな挑戦の一つになると考えています。
データエンジニアリング
安定的に医療を提供するためにも、当然ながら病院は経営に対して関心を持っています。 また、診療報酬制度上も統計データを提出する義務があるケースがあります。 そのため、Henry に入力された・Henry が計算した情報を、さまざまな方式で分析したい、というニーズがあります。
病院ごとにさまざまなニーズがあり、分析したい内容や欲しい情報の粒度もさまざまです。 開発が加速するなかで、安定的にこういった情報を提供するためのデータエンジニアリングの部分も非常にチャレンジングです。
（まだ専任のデータエンジニアが不在の状態なので、ご興味のある方がいらっしゃいましたらお声掛けください！ 現状は dbt + BigQuery での基盤を構築していますが、信頼性やドキュメンテーションなど、課題が山積みです！）
ほかにもいろいろ
細かくは書きませんが、他にもさまざまな挑戦があります。
- Henry 以外のシステムとの連携（相手方がオンプレである場合が多い）をどのように実現するか
- セキュリティ（ リスク・コミュニケーションについて医療ISAC Security Lectureで発表しました｜Henry など）
- 同時編集など、複数名で同時にシステムを利用するユースケースのカバー
などなど...
おわりに
ヘンリーでの開発内容については、社会的意義やビジネス上の価値はある程度外部から想像がつきそう（メンバーインタビューなどからも読み取れそう）だと思いつつ、開発そのものの日常的な面白さについては、あまり想像がつかないのではないかなと思い、あえて焦点を当ててみました。 ちょっと難しさにフォーカスが当たりすぎてしまった感もありますが、こういった挑戦はやはり純粋にソフトウェアエンジニアとしてやりがいを感じます。
少しでも興味を持っていただけた方がいらっしゃいましたら、ぜひカジュアルにお話しましょう！
