株式会社ヘンリーVPoEの@shenyu_cyanです。2023年が始まり、当社の新しい取り組みとしてエンジニアリングブログを始めました。
私たちは「社会課題を解決し続け、より良いセカイを創る」をミッションにプロダクトを開発しています。その第一歩として現在はクリニック・中小病院向けの基幹システムであるクラウド型電子カルテ・レセプトシステム「Henry」を展開しています。
技術ブログの初投稿として、今回はヘンリーが利用している技術スタックおよびその裏の考え方をご紹介し、これからの方向性について書かせていただきます。
ヘンリーの技術スタックを簡単にご紹介しますが、フロントエンドはReact+TypeScriptを採用し、その裏にBFFを設け、GraphQLで通信を行なっています。そして、BFFとバックエンドの各サービス、バックエンドのサービス同士はgRPCでやりとりをします。バックエンドは主にKotlinを採用し（一部はNode.js）、インフラ層はGoogle Cloud Platform（GCP）に統一しています。具体的に採用している技術スタックはwhat we useにて詳しく掲載しているので、ご興味のある方はぜひご覧ください。
さて、ヘンリーはなぜ今の技術スタックを採用しているのか、その裏には3本の柱があると考えています。
開発者体験の良さ
これまでのソフトウェアエンジニアリング界隈での実体験として、使いたい気持ちこそ開発効率向上の源泉だと感じています（ソフトウェアの世界に限らない話しかもしれませんが）。そのため、開発者体験の良さは非常に大切にしています。開発者体験をプロセスベースでざっくり3分割すれば、導入・使用・メンテナンスになると思います。
まず導入というプロセスにおける良い開発者体験はどんなイメージでしょうか？やはりエコシステムは重要な角度だと思います。ドキュメントやサンプルコード、プラグインのような周辺プロジェクトの数とクオリティは導入時の体験を大きく左右します。そのため、我々はエコシステムの充実さに定評があるReactやTerraform等を採用し、その利点を享受してきました。
また、使用時の良い体験、すなわち使いやすさが同じく重要です。例えば弊社はKotlinを採用していますが、標準ライブラリの豊富さはヘンリーのエンジニアの中で好評を博し、開発効率の向上に直結しています。さらに、JVM系言語の特徴としてテストライブラリの充実さがあり、ヘンリーはそれらを活用し、コミュニケーションコストの低減にもつなげています。
通信プロトコル周りはもう一つの例です。ヘンリーではGraphQL、gRPCとRestful APIを採用していますが、いずれもスキーマ駆動の仕組みを導入し、重複作業を無くし、開発者体験の向上を図りました。そのおかげで、コード自動生成はもちろん、仕様書も自動作成できるため社内向けリファレンスサイトを実現できました。
最後はメンテナンスしやすさです。前述の通り、ヘンリーはGCPを採用しています。GCPの各ソリューションの中でもなるべくマネージドサービスを利用しています。例えばヘンリーのバックエンドサービスはすべてCloud Runを利用し、手動メンテナンスの必要性を抑えています。また、SentryやOpenTelemetryといった技術を積極的に導入し、異常を検知しやすく障害時の原因調査を行いやすくするためにObservabilityを重要視しています。
一方、開発者体験に関して工夫すべきところはまだたくさんあります。まずFour Keysを始めとするメトリックスをベースに運用する仕組みを構築し、改善のイテレーションを回す基盤を設けて行きたいと思っています。例えば、直近の課題として、各サービスのインタフェース管理が密結合になってしまっている為、Deployment FrequencyとLead Time for Changesに悪影響を及ぼしているのでこれから改善していきたいと考えています。開発者体験は重要性が高く伸びしろの大きいポイントなので、イテレーションごとの収穫が多く見込めると感じます。
ユーザー体験への追及
使いたい気持ちが開発効率向上の源泉だとすれば、ユーザー体験こそヘンリーの競争優位性の源泉だと私たちは考えています。よって、ヘンリーではユーザー体験への追及を支えるためにさまざまな技術を活用してきました。
ユーザー体験を向上させるのに、細部への拘りが欠かせません。例えば、ヘンリーでは複数の医療スタッフがスムーズにドラッグ・アンド・ドロップを行い、自由自在に記述できるカルテエディターを仕上げるために、Draft.jsなど多くのソリューションを実験した末、Yjs+ProseMirrorを活用した自作エディターを実装しています。そのほか、react-routerやreact-navigationの利用をやめ、ルーターライブラリを自作する事例など、ユーザー体験向上に繋がる技術選定を繰り返してきました。
また、統一性の担保もユーザ体験に関わる重要なテーマだと感じています。ヘンリーでは、Figmaでデザインシステムを構築し、Styled ComponentsとStoryBookを活用し、コンポーネントごとのユーザー体験の一致性を担保しています。
とはいえ、それらはあくまで表面上の工夫だと私たちは思います。より根本からユーザー体験を追及するために、UXリサーチからスタートしたプロトタイピングのフローを回しやすくしていきたいです。そのために、技術面では機能モジュールごとのテスタビリティを高め、フロントエンドのコンポーネントやバックエンドのドメインモデルの粒度と独立性を整備する必要があります。さらに、価値検証を行いやすくする為にフィーチャーフラグAPI化といった現実的な技術課題から機能ごとの開発フロー構築という体制改善まで努力する必要があります。克服しなければいけないチャレンジが多く、難しい挑戦だとは思いますが、医療DXのセンターピンである電子カルテ・レセプトコンピューターなので毎回毎回のチャレンジが着実に医療DXの加速化につながると考えたら胸が熱くなります。
スケールアウトしやすさ
私たちはより良いセカイを創るために社会課題を解決し続けることに力を入れていますが、今の規模感では社会課題を解決し続けるのに力不足を感じています。そのため、もっともっと多くの優秀な仲間にご参画いただくことが不可欠だと考えています。必然的に、組織とシステムのスケールアウトに備えた技術スタックの検討が必要です。
新しいメンバーがスムーズにキャッチアップできるよう、多くの方にとって馴染みのあるツールを優先的に採用しています。例えば、コード管理はGitHubを採用し、デザインツールはFigmaを利用しています。
加えて、大規模な開発でも生産性が落ちにくい型付け言語の採用を徹底しています。もちろん、ソフトウェアのチーム開発において、型だけでは担保できない部分が多々あります。オンボーディング負荷の低減と機械的に発見可能な負債の抑制のためにDetektのような静的分析ツールを導入したり、EOLもしくは脆弱性のあるライブラリを排除するためにRenovateやSocket Securityを導入しています。
ヘンリーが今Cloud RunやCloud Storage等のサービスを利用しているおかげで理論上スケールアウトしやすいインフラになっていますが、実運用に耐えられるプロダクトにするためにデータの構造やオペレーション整備の観点から工夫しなければいけないポイントはまだまだ残っています。
また、組織のスケールアウトによって、各チームがそれぞれの実情に合わせた技術の判断を下すシチュエーションが増えていくと思います。一方、自由度が高すぎますと、横断的なアクティビティがやりづらくなり、技術面のオーバーヘッドが増えるデメリットが出てきます。良いバランスを保つためのチューニングが大きな挑戦であり、エンジニアにとって腕の利くところだと考えます。
各ソフトウェアプロジェクトの発展状況や組織の規模感によって、弊社技術スタックの移り変わりが予見できます。しかし弊社の行動指針「顧客の成果にこだわろう！」でも語られているように、プロダクトチームの思想の根幹に「ビジネスバリュー提供へのフォーカス」という核心があります。そのため、今後ヘンリーの開発チームが技術スタックの新規選定や置き換えを行う際に、その思想からブレることはないでしょう。
それに、今のスケールアウト速度で試算したらヘンリーという組織だけでは世の中の負をすべて解消することは不可能でしょう。そのため、ヘンリーは今後もっとコミュニティにフィードバックし、私たちが蓄積してきた失敗談や技術ノウハウをよく多くの方にシェアし、課題解決に活用いただくことを目指しています。このエンジニアリングブログはまさにその一環です。
2023年残り約11ヶ月、ヘンリーのプロダクトチームにとって飛躍的な一年でありますように我々は頑張っていきます。もしこの記事を通してヘンリーに少しでもご興味が湧きましたら、ぜひ下記のリンクよりお話しの時間を調整させてください。お待ちしております。
