株式会社ヘンリー エンジニアブログ

株式会社ヘンリーのエンジニアが技術情報を発信します

認知科学を応用した医療ドメインの効率的キャッチアップ

【この記事は株式会社ヘンリーAdvent Calendar 2023の24日目の記事です。昨日は 嶺野さんによるヘルステックエンジニアのキャリアという話でした。】

こんにちは!2023年10月にヘンリーに入社した山口(@tyamaguc07)です。 エンジニアとして、主にHenryのレセコン(医療費・診療報酬)の開発に携わっています。

ドメインキャッチアップの重要さ、難しさ、そして楽しさ

ヘンリーで医療ドメインの理解は欠かすことができないものです。しかし、医療ドメインは情報量が多いだけでなく、読み解く必要性や、深く理解する必要性がある世界です ドメインキャッチアップの重要さや、難しさ(そして楽しさ!!)は @agatan の記事でも触れられています。

電子カルテ・医事会計システムとは、病院における業務基幹システムです。 ご存知の通り、病院にはさまざまな職種(医師、看護師、医療事務、検査技師、etc...)の方がいらっしゃいます。 専門職の方々が、互いに情報をやりとりしながらご自身の専門業務を遂行しています。 それぞれの業務は専門性の高い業務であり、単体で見ても複雑で難易度の高い一つのドメインです。 継続的に、より高い価値を届け続けるためのソフトウェアを開発するためには、そもそも開発対象を深く理解し、それをモデリングする・改善し続けることに心血を注ぐ必要があります。

Henry の開発はなにが楽しい?ソフトウェアエンジニアにとっての魅力と挑戦をご紹介します! - 株式会社ヘンリー エンジニアブログ

診療報酬制度では、保険医療の価格や、ある保険医療を実施するために医療機関が満たしているべき条件、提出すべき書類などが定められています。 ものによっては、継続的に統計データを提出する必要があったり、入院中の患者に対して日々記録を取っておく必要があったりします。 ルールの数も多いのですが、個々のルールについて読み解くのも非常に難しく、これをモデリングする作業には、パズルや謎解き的な面白さがあります。 きれいにモデリングできたときには、ものすごく気持ちよくなれます。

Henry の開発はなにが楽しい?ソフトウェアエンジニアにとっての魅力と挑戦をご紹介します! - 株式会社ヘンリー エンジニアブログ

※ 太字は私による強調

入社して3ヶ月が経ち、実体験を通じて、これらの難しさを乗り越えることの楽しさ、そして乗り越えた先の楽しさがあるのは間違いないと考えています。
しかし、同時にもっと効率的に向き合う方法はないのだろうかとも考えています。
組織としても、来年の100人採用に向けて医療ドメインの理解を効率的に進める方法が仕組みかされていることは重要であると考えています。

そんな中、今年読んだ「プログラマー脳 ~優れたプログラマーになるための認知科学に基づくアプローチ 」(以下、本書)の学びが医療ドメインの理解に応用できるのではないかと考えました。
本書は、認知科学に基づいてプログラミング時に発生する認知負荷をどのように軽減できるかを解説しており、非常に学びの多い一冊でした。
認知負荷は、プログラミングを行う際に限らず他の多くの状況でも発生する現象です。
本書で示されている考え方を転用し、医療ドメインの理解における認知負荷の軽減に応用してみようと思います。

慣れない文章を読む際に発生する問題に向き合う

本書では、まず、慣れないコードを読む際に発生する混乱は長期記憶、短期記憶、ワーキングメモリそれぞれに問題が発生すること、どのように対策できるのか述べられています。

この、慣れないコードを読むプロセスは、厚生労働省から公表される資料や診療報酬制度の文書を読むプロセスと類似していると考え、問題の理解と対策が、転用できるのではないかと考えました。

長期記憶の問題

未知の用語や略語はそれが何であるかを理解できないため、混乱の発生要因となり、理解を進める際の障壁となります。

対応策: 知っている単語や概念を増やす

対象ドメインにおいて知っていることを増やすかというシンプルな対応策です。 ヘンリーでは継続的にメンテナンスされている用語集ががあるので、それを学習に利用することが可能だと考えています。
本書では、素早く学ぶためにフラッシュカードを使うことが提案されています。

具体的なアクション

  • 用語集をフラッシュカード化し学習に利用する

短期記憶の問題

資料の一文に出てくる単語や概念の数が多いので、短期記憶にとどめておくことができず理解を妨げる傾向があります。

たとえば、以下のような文章を見たときには面食らいました。

Ⅱの規定にかかわらず、薬事法等の一部を改正する法律(平成 25 年法律第 84 号)第1条の規定 による改正前の薬事法(昭和 35 年法律第 145 号)第 14 条第1項又は医薬品、医療機器等の品質、有 効性及び安全性の確保等に関する法律(昭和 35 年法律第 145 号)第 23 条の2の5第1項の規定による承認を受け、次の表の左欄の承認番号を付与された同欄に掲げる特定保険医療材料の同表の中欄に掲げる期間における材料価格は、それぞれ同表の右欄に掲げる材料価格とする。

対応策: チャンキングをできるようになる

チャンキングとは物事を覚えるときに複数の情報を一つにまとめ、覚えるべきことの数を減らして短期記憶にとどめやすくすることです。
先程の文章であれば、以下のようにチャンキングできるようになると考えています。

- 「Ⅱ」の規定にかかわらず、
- 薬事法等の一部を改正する法律によって
- 次の表の材料価格とする。

プログラミングの場合は、私達でチャンキングしやすいようにコードを書くこと効率化を図れますが、医療ドメインの情報に関してはこの方法で効率化は図れません。
したがって、与えられた文章を如何にチャンキングできるようになるかが重要となります。

何を知っていればチャンキングができるようになるのでしょうか?
本書では、プログラミングに関する概念、データ構造、文法を知っていればいるほどコードを簡単にチャンク化できるようになると書かれています。
これを、医療ドメインのキャッチアップに転用すると以下の情報を知ることでチャンク化できるようになるのではないかと推測しています。

  1. 公表される文章のよくある構成
  2. 医療制度の背景にある考え方
  3. Henryを開発するにあたって必要な情報、あるいは不要な情報

いずれもオンボーディング時にざっくりと共有可能な情報です。
しかし、プログラミングと比べると明確な情報ではないため、チャンク化しながら文章を読む訓練もより必要であると考えています。

具体的なアクション

  • チャンク化するために有効な情報をオンボーディングで共有する
  • 公表される文章をチャンク化しながら読む訓練を行う

ワーキングメモリの問題

コードが複雑で把握する変数や状態が多いときに発生するもので、理解を妨げます。
医療ドメインにおいても同様に変数や状態が多い文章があるケースがあり、理解を妨げます。 さらに、自然言語ならではの問題として修飾されている対象が不明瞭であったり、文中で名言されていないがコンテキストから察する必要がある事象などがあり、これも理解を妨げます。

たとえば、ある公費のルールは以下のようなものです。

大阪の乳児医療は1日500円以上の場合は限度額500円までとなる(当月2日間は500円限度、それ以降は患者様請求額0円)

CodeGolfでもしたのかと思えるほど情報が削ぎ取られています。

対応策: リファクタリングする

本書では、リファクタリングがワーキングメモリの問題に効果的であることが述べられています。 医療ドメインの理解で発生する同様の問題においても、文章に対してリファクタリングが有効であるように考えられます。先のルールをリファクタリングしてみると以下のようになります。

1)ある月において1回目の外来受診日における患者の負担額は500円を上限となる。
  これは、1回目の外来受診日に複数回外来を受診したとしても、その日に患者が負担する金額は500円までになることを意味する。
2)ある月において2回目の外来受診も同様である。
3)ある月において3回目以降の外来受診に関しては負担額は0円となる。

長くはなりましたが、ルールの内容が具体的になったと思います。
一方、コードのリファクタリングがそうであるように、リファクタリング前後でルールが変わっていないことを担保する必要があります。
ヘンリーではドメインエキスパートとの協業を前提としているため、ルールが変化していないことを確認することが可能です。
ドメインの理解を進めている最中は、そもそもリファクタリングすること自体が難しい可能性はあります。その場合は、ドメインエキスパートにリファクタリングしていただくことも選択肢にあがります。

具体的なアクション

実装に落とし込むような文章・ルールに関しては、リファクタリングを行う。あるいはドメインエキスパートにリファクタリングを依頼する。

次回?

本書では、他にもメンタルモデルが認知負荷に及ぼす影響であったり、意味波(semantic wave)を踏まえた学習プロセスのアンチパターンなども紹介されています。
これらを取り入れた方法も考えているので、整理できたタイミングでまた記事を書こうと思います。

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

Henry の開発はなにが楽しい?ソフトウェアエンジニアにとっての魅力と挑戦をご紹介します!

こんにちは!ヘンリーでソフトウェアエンジニアをしている @agatan です。

ヘンリーでは、医事会計システム一体型の電子カルテ Henry を開発しています。

この記事では、ヘンリーでソフトウェアエンジニアとして働く上での挑戦や面白さをご紹介したいと思います。
ヘンリーの生み出すプロダクトやビジネスの社会的意義など、ヘンリーで働くモチベーションとなる要素はたくさんあるのですが、あえて今回はエンジニアリングの面白さに焦点を当てて、なぜ僕は Henry の開発を楽しいと感じているのか・どこがチャレンジングなのか、について書いてみます。 「ここが難しい!」という話が多くなっているのですが、難しさは挑戦の種でもあるので、興味を持っていただけるとうれしいです!

(また、今回はエンジニアリングに焦点を当てていますが、僕個人としては、何よりも社会的意義とそれを目指したときのビジネス面の勝ち筋がきれいに整合していることに強く惹かれています。 そういったヘンリーの魅力については、株式会社ヘンリーのカレンダー | Advent Calendar 2023 - QiitaHenry|note の記事をぜひご覧いただければと思います。)

この記事は 株式会社ヘンリー Advent Calendar 2023 20日目の記事です。19日目は 今年も組織が1.5倍に!リモートワーク中心で拡大し続けているスタートアップのコミュニケーション設計|Henry でした。 qiita.com

Henry の技術スタック

前提として Henry を構成する技術について軽くご紹介します。 (少し古い & バックエンド中心の話限定ですが)こちらに以前登壇した際の資料があります。

speakerdeck.com

上記に記載のないものも含め、粒度もバラバラにざっくりまとめると

株式会社ヘンリーの技術スタック - what we use(技術スタックデータベース) にもうすこし詳細に利用しているものが載っています。)

見ていただいて分かる通り、割と普通のWebアプリケーションの構成をしています。 電子カルテというと馴染みのなさそうな雰囲気を覚える方もいらっしゃるかもしれませんが、技術的にはやっていることは概ね普通のWebアプリケーション開発です。

dev.henry.jp

シンプルに開発が難しい!ので見せ場がたくさんある!

電子カルテ・医事会計システムとは、病院における業務基幹システムです。 ご存知の通り、病院にはさまざまな職種(医師、看護師、医療事務、検査技師、etc...)の方がいらっしゃいます。 専門職の方々が、互いに情報をやりとりしながらご自身の専門業務を遂行しています。

それぞれの業務は専門性の高い業務であり、単体で見ても複雑で難易度の高い一つのドメインです。 継続的に、より高い価値を届け続けるためのソフトウェアを開発するためには、そもそも開発対象を深く理解し、それをモデリングする・改善し続けることに心血を注ぐ必要があります。

CRUDとは一線を画す複雑さがあったり、最終的に作るものがCRUDであっても「何をCRUDするのか」を見つめ直さないと適切なモデリングにならないことが多々あります。 開発そのものが単調になることが少なく、純粋に作る部分だけを取り出しても腕の見せどころが比較的多い環境だと思います。

診療報酬制度を解きほぐす面白さ

日本には、診療報酬制度というものがあります。( なるほど診療報酬!|国民のみなさまへ|日本医師会
診療報酬制度では、保険医療の価格や、ある保険医療を実施するために医療機関が満たしているべき条件、提出すべき書類などが定められています。 ものによっては、継続的に統計データを提出する必要があったり、入院中の患者に対して日々記録を取っておく必要があったりします。

ルールの数も多いのですが、個々のルールについて読み解くのも非常に難しく、これをモデリングする作業には、パズルや謎解き的な面白さがあります。 きれいにモデリングできたときには、ものすごく気持ちよくなれます。

(また、診療報酬制度に詳しくなることは、雑学的な面白さもあります。診療報酬制度には、日本の医療の将来を見据えて方向性を示す役割があるため、これを知っておくと少し日本の将来について詳しくなった気分になることができます。)

巨大になっていくシステムをどうチームでさばくか

また、個々の業務・ドメイン単体で見た時の難易度もさることながら、ドメイン同士が深く高密度に連携している、というのも、医療の業務基幹システムの特徴です。 一人の患者に対して、様々な専門職が関わるため、それをスムーズに接続する必要があるのです。

さらにすこし違う視点から見ると、診療報酬制度を核とした結合も強く存在します。
僕自身は、診療報酬制度をもとに会計業務を行うための「医事会計システム」側のコンポーネントを開発しているのですが、診療報酬制度に関わる業務というのは、会計時だけでなく例えば日々の看護においても発生します。

そのため、きれいにシステムやチームを分割することが難しく、開発難易度を上げる要素となってしまっています。

こうしたある種偶発的な複雑さに起因する難しさは、あまり純粋に楽しめるものではないと思いますが、それを乗り越えるために改善の手を考え実行し続けるチームの存在や文化がある環境というのは、とても働きがいがあります。 チームとして、学習して手を打ち続けることが重要だと考えており、実際これまでにチーム分割やモノレポ化などの手を打ってきました。

dev.henry.jp

dev.henry.jp

また、1プロダクトでありながら実質的に複数のドメインが共存しているため、そもそもシステム自体のサイズが巨大です。

僕自身、すでに2.5年開発をしていますが、システムのすべてを把握できているかというとやや怪しく、詳しく内容を知らないコンポーネントも増えていっています。 どれも顧客にとって重要な機能であり、まだまだ足りていない機能もあるなかで、きちんと開発が健全に進んでいる証ではあります。 これも、プロダクトや組織が成長していくなかで、どのようにスケールする体制を作っていくか、という挑戦に繋がっています。

パフォーマンスの維持

業務で日々使うソフトウェアなので、当然スムーズに動作することが求められます。 Henry でもこれまで Next.js への移行などパフォーマンス向上のための手を打ってきました。

dev.henry.jp

Henry はいままでもこれからもどんどん進化していくプロダクトです。 システムの全体像を把握するのが難しいなかで、進化の過程で入る変更は、どうしても局所的な視点での変更になりがちです。

たとえば、「外来会計確定」というイベントをトリガーに走る処理は、この1年でも3,4つ増えています。 それぞれのイベントは、それぞれの業務ドメインを持っていて、 当初は1,2つ程度しかなかった処理だったために同期的に処理していたイベントでしたが、徐々に限界を迎えつつあり、根本的にアーキテクチャを見直す必要も出てきています。

また、「あっちで個別に処理していた内容を、こっちの月次一括処理でも同じことをしたい」というようなケースもあります。 診療報酬制度を中心に、業務が密結合しているため、どうしてもドメインをまたいだ共通処理が出てきてしまいます。 それぞれのドメインが十分に複雑であるため、ドメインをまたいで処理を共通化しようとしたときに、内部実装を細かく知らない状態で共通化してしまったりすると、後々パフォーマンスインシデントでえらい目にあったりします。

意識的に全体の状況を俯瞰する時間を取ることで、対処が必要であることに気づいたり、どういう手を打つべきかを考えるようにしています。 (冷静に俯瞰すれば、実際に問題になっているのは単純な N+1 だったりもするので、気づくこと・手を打つべきと判断することがメインの挑戦といえるかもしれません。)

Reliability

業務基幹システムであり、かつ医療の現場が使うサービスであることを考えると、信頼性も非常に重要です。 障害に対する備えはもちろんですが、日々の開発においても、互換性を維持したデプロイができるように意識したり、自動テストを拡充したりと、考えることがたくさんあります。

また、信頼性は高いに越したことはもちろんないのですが、ガチガチに固めればいいというわけでもありません。同時に開発生産性を高める意識をもって取り組まないと、最終的にはお客様の利益を害する結果に繋がってしまいます。我々は後発であるがゆえに、モダンな開発体制を築き、高い開発力を活かして、スピーディにサービスをより良くしていくことが求められています。

ここについては、まだまだヘンリーとしても取り組むべき課題がたくさんありますが、ポストモーテムの取り組みや障害対応のプラクティスの共有、自動テストの拡充とそのプラクティスの共有など、SREチーム / QAチームを筆頭に改善が続いています。

dev.henry.jp

dev.henry.jp

診療報酬改定

先に述べた「診療報酬制度」は、二年に一度改定されます。

改定の内容は年ごとに大小さまざまですが、Henry というプロダクトの根拠の一つである診療報酬制度が変わる、ということがプロダクトに与える影響は甚大です。(医事会計システムはもちろんですが、電子カルテ側も取る記録の内容がかわったりするため、多大な影響を受けます。)
したがって、二年に一度、(規模はそのときどきによって変わるようですが)大きな変更を迫られることになります。

さらにややこしいことに、改定後であっても、改定前の診療や会計の情報は閲覧・編集したいので、改定前の状態も同時にサポートする必要があります。 診療の記録にはデータ保全の義務があるため、データの寿命は非常に長く、互換性を維持した設計を心がける必要があります。

このあたりに気を使って開発をし、安全にリリースさせる、というのは、ソフトウェアエンジニアの腕の見せどころの一つだと思います。 (一例ですが、ダウンタイムなくデータのマイグレーションやミドルウェアのリプレースを行うために、知識や技術力を発揮することは、ソフトウェアエンジニアの本懐の一つといってもいいのではないでしょうか。)

また、まだまだ電子カルテ業界ではオンプレ・個別対応開発が主流となっています。 Henry はクラウドベースの SaaS という提供形態をとっているため、オンプレや個別対応の開発を行っているプロダクトと比較すると、明確に対応コストが下がっています。 自動テストなど、きちんと開発環境・体制のベストプラクティスを適用することで、我々の対応コストを下げると同時に、競争優位性も築くことができます。

エンジニアリングによって明確な競争優位性を作れるというのも、ヘンリーでエンジニアをする上でやりがいを感じるポイントになっています。

ドメインエキスパートとの協業を前提とした開発体制・プロセス

Henry を作るためには、非常に深いドメイン知識が求められます。 「なにを作るか」「どう作るか」「作ったものが正しく動いているか」などなど、開発を行う上で出てくるほとんどすべてのステップにおいて、ドメイン知識が求められますが、求められるドメイン知識のレベルは非常に高く、習得難易度も高いです。 (わかりやすいところでいうと、診療報酬制度をまとめた書籍「診療点数早見表 2023年4月増補版」は、1,760ページあります。)

そこで、ヘンリーでは、開発チームの中にドメインエキスパートが在籍しており、一緒になって仕様やモデリングを考えたり、動作検証をしてくれたりしています。

note.com

note.com

もちろんソフトウェアエンジニア自身もドメインを学ぶ活動は活発に実践されていますが、それでも経験豊富で強力なドメインエキスパートがいてくれることの心強さが非常に大きいです。 ドメインエキスパートが開発チーム内にいてくれるおかげで Henry の開発は進んでおり、もしドメインエキスパートがいなければ僕自身も泣きながら開発をしているのではないかと思います。 ここまで複雑でソフトウェアに落とし込む作業自体が難しい領域で、ここまでの手厚い体制が提供された状態で、エンジニアリングに向き合えるというのは、非常に希少な環境なのではないでしょうか。

さらにいえば、ヘンリーの開発体制は、まだまだドメインエキスパートのちからを最大限引き出せてはいないと感じています。 一部では、ドメインエキスパートがエンジニアの書くテストケースをレビューしたり、ドメインエキスパートが作ったテストケースを自動テストに組み込んだりするといった取り組みが進んでいますが、もっともっとこれを推し進めていくことで、直にドメインエキスパートがプロダクトを前に進められるような環境をつくれるのではないかと考えています。 まだまだ夢物語ではありますが、これが達成できれば圧倒的な強みになると思いますし、これも大きな挑戦の一つになると考えています。

データエンジニアリング

安定的に医療を提供するためにも、当然ながら病院は経営に対して関心を持っています。 また、診療報酬制度上も統計データを提出する義務があるケースがあります。 そのため、Henry に入力された・Henry が計算した情報を、さまざまな方式で分析したい、というニーズがあります。

病院ごとにさまざまなニーズがあり、分析したい内容や欲しい情報の粒度もさまざまです。 開発が加速するなかで、安定的にこういった情報を提供するためのデータエンジニアリングの部分も非常にチャレンジングです。

(まだ専任のデータエンジニアが不在の状態なので、ご興味のある方がいらっしゃいましたらお声掛けください! 現状は dbt + BigQuery での基盤を構築していますが、信頼性やドキュメンテーションなど、課題が山積みです!)

ほかにもいろいろ

細かくは書きませんが、他にもさまざまな挑戦があります。

などなど...

おわりに

ヘンリーでの開発内容については、社会的意義やビジネス上の価値はある程度外部から想像がつきそう(メンバーインタビューなどからも読み取れそう)だと思いつつ、開発そのものの日常的な面白さについては、あまり想像がつかないのではないかなと思い、あえて焦点を当ててみました。 ちょっと難しさにフォーカスが当たりすぎてしまった感もありますが、こういった挑戦はやはり純粋にソフトウェアエンジニアとしてやりがいを感じます。

少しでも興味を持っていただけた方がいらっしゃいましたら、ぜひカジュアルにお話しましょう!

jobs.henry-app.jp

事例から学ぶクラウドへのOpenTelemetry導入のハマりどころ

ヘンリーでSRE / SDETをしているsumirenです。

この記事は株式会社ヘンリーAdvent Calendar 2023の9日目の記事です。昨日は id:nabeopカジュアルな社内勉強会 : ギベンの紹介 という記事でした。

背景

ヘンリーでは分散トレーシングにOpenTelemetryを用いています。元々、ログはCloud Runの標準出力をCloud Loggingが拾ってくれるものを見ており、メトリクスもCloud Runがマネージドで取得してくれるものを見ていました。しかし、オブザーバビリティを高め、また民主化するためには、トレースを起点にメトリクスやログなど全てのシグナルを追えるべきだと考え、OpenTelemetryを導入しました。

ローカルでいくつかのマイクロサービスとOpenTelemetry Collectorを立ち上げ、Jaegerで分散トレースを追えるようにするまでは簡単でした。長かったのは、計装の入ったサービスをクラウドにデプロイしてから、実際に使えるようになるまでです。

この記事では、そうしたヘンリーでの導入事例から、クラウドへのOpenTelemetry導入のハマりどころを2つ抜き出して解説します。実際に皆様が全く同じ問題にぶつかることは考えづらいですが、問題の理解を通してOpenTelemetryへの理解度が高まることを目指しています。

この記事は導入とアプリケーションレイヤにフォーカスします。運用中の問題やネットワークレイヤの問題は取り上げません。

1. クラウドプラットフォームがトレースに干渉する

事象

最も大きな問題は、「クラウド上でなぜかトレースが切れる」というものでした。

ヘンリーではGoogle Cloudを採用しているため、トレースバックエンドとしてはCloud Traceを検討していました。以下がシステムの構成です。

Cloud Traceを用いたシステム構成

フロントエンドからのGraphQLリクエストをBFFで受け付け、gRPCを提供するバックエンドのマイクロサービスに対して解決しています(図中黒い線)。その過程で、OpenTelemetryの自動計装により各サーバーからOpenTelemetry Collectorへのテレメトリーデータが流れ、Cloud Traceに集約されています(図中青い線)。なお、フロントエンドサーバーは今回あまり関係がないためグレーアウトしています。

こちらをローカルで動かしたときのトレースのイメージは以下のとおりです。うまく動いており、BFFの処理の一部でマイクロサービスを2回呼び出しているといったことがわかります。

ローカルではトレースが動いている図

一方、ソフトウェアとOpenTelemetry CollectorをCloud Runにデプロイすると、当初は以下のようなトレースになってしまっていました。BFFの処理とマイクロサービスの処理の関係性が現れておらず、トレースに対して2本のツリーがあるように見えます。

クラウドにデプロイするとトレースが動かない図

原因

Cloud RunがOpenTelemetryに干渉することが原因でした。

前提知識として、OpenTelemetryでは、個別のサービスがOpenTelemetry Collectorやオブザーバビリティバックエンドにトレースを中心としたシグナルをそれぞれ独自に送ります。その際、サービス間で自分のスパンがどのスパンの子になるべきか知るために、サービス間の呼び出しにデフォルトではtraceparentヘッダというHTTPヘッダを使います。この機能をContext Propagationと言います。もしContext Propagationについて詳しくなければ、手前味噌ですがこちらの記事も参照してみてください。
OpenTelemetry 分散トレーシングのシステムアーキテクチャ

Cloud Runは、このtraceparentヘッダを見つけると、独自のスパンを発行し、traceparentヘッダを書き換えて自身が乗せているアプリケーションに対してリクエストをプロキシします。この独自のスパンはCloud Traceに送信されます。先程のシステム構成について、この動きを書き加えたものが以下の図解になります(図中ピンクの線)。私たちの預かりしらぬところでCloud Runがスパンを割り込ませ、Cloud Traceに連携していることが分かるでしょうか。

Cloud TraceとCloud Runのスパン自動連携

問題は、Cloud Runは自身が生成したスパンをデフォルトではほとんどサンプリングで間引いてしまいCloud Traceに連携しないということです。

OpenTelemetryのデフォルトのサンプリングロジックでは、親スパンがある場合には親スパンのサンプル有無に従います。親がサンプルしたかどうかはtraceparentヘッダのtrace flagsというカラムからわかります。しかし、Cloud Runはtraceparentヘッダに干渉するにも関わらず、Parentbasedなサンプリングロジックになっていません。つまり、BFFやマイクロサービスにAlwaysOnのサンプリング設定をしても、Cloud Runは独自の仕様でCloud Traceに独自に生成したスパンを連携するかどうかを勝手に決めてしまうということです。

トレースは子スパンが親スパンのIDを持つことで成り立っているツリー構造です。1つでも間のノードが抜けてしまえば、その部分はツリーが分断してしまい、オブザーバビリティバックエンド目線は独立した2つのツリーに見えてしまいます。こうして、上記のような事象が発生したというわけです。

この状況を脱するには、Cloud RunにOpenTelemetryへの干渉をやめさせるか、Cloud Runに必ずスパンを生成させるか、全てのトレースを保存することを諦めれば良いということになります。

学び

ここで伝えたかったことは、Context PropagationがHTTPヘッダを用いたもので、かつtraceparentのように標準化されているために、PaaSやIaaSがインターセプトする余地があるということです。

トレースがいくつかのツリーに細切れになってしまったり、一部のスパンしか可視化されないとしたら、こうしたクラウドによるおせっかいな干渉を疑うと良いかも知れません。

加えて、この事例を通じて、Context Propagationやサンプリングに対する皆様の理解が深まっていましたら幸いです。

余談

この記事の趣旨はあくまでクラウド一般でのOpenTelemetry導入のハマりどころです。そのため以下は余談ですが、ヘンリーではこの問題は完全には解消していません。

Cloud Traceのドキュメントには、フロントエンドからのリクエストに特定のHTTPヘッダを付与することでトレースを強制させることが可能とあるのですが、ヘンリーでは度々トレースされない事象を確認しており、現在サポートとやりとりをしています。

そして、仮にCloud Runにトレースを強制させることに成功したり、Cloud RunがParentbasedなサンプリングロジックを実装することで、スパンが抜ける現象が解決しても、ベンダーロックインになっているという問題が残ります。例えばDatadogなどに移行したくなったときには、結局Cloud Runが生成したスパンはCloud Traceにしか伝わっておらず、Datadog目線はスパンが抜けてしまうという問題が発生するからです。

これを防ぐためには、皮肉なことにOpenTelemetryをやめてDatadog Agentのような独自エージェントを使うのが一番手っ取り早いかもしれません。他には、Cloud Runの知らないPropagatorを使うという手段も考えられます。

個人的には、Cloud Runの設定でOpenTelemetryへの干渉を無効化できると一番嬉しいです。

2. シグナルを全てOpenTelemetryで扱うとクラウドプラットフォームの恩恵を受けづらい場合がある

事象

当初は、トレースと併せてログやメトリクスもOpenTelemetryベースで取り扱うことを考えていました。トレースとの紐づけが自動的に行われるからです。

以下はOpenTelemetry導入前の図解です。実際には構造化ログに対するtraceIdの採番はできていましたが、トレースやメトリクスは使っていなかったため導入前と表現しています。ログに関しては標準出力に出す部分だけで自身でコントロールしており、メトリクスにいたってはフルマネージドでした。

OpenTelemetry導入前のオブザーバビリティバックエンド構成

今回、トレース以外にログやメトリクスもOpenTelemetryベースでOpenTelemetry Collector(またはオブザーバビリティバックエンド)に送信する検証をした際に、Cloud LoggingとCloud Runの標準の連携が効かなくなるという事象が発生しました。以下はある検証環境におけるCloud Loggingの画面なのですが、図解のとおり、Cloud Runなどの他のGoogle Cloudのサービスと連携してログを絞り込む機能があります。OpenTelemetryベースでログを送ると、この機能が使えなくなってしまいました。

リソースとログを紐付けるCloud Loggingの機能

原因

このときのシステム構成の図解は次のとおりでした。Google Cloudマネージドで実現される部分はなくなっており、全てがセルフコントロールとなっています。

全てのシグナルをOpenTelemetryの通信で取り扱うシステム構成

ご想像のとおり、事象の原因は、Google Cloudマネージドな連携ではなくなったことです。当初はCloud LoggingはCloud Runとのマネージドな連携によりログの出処がCloud Runであることが分かっており、Google Cloudの強みである機能間のシナジーを活かせていました。アプリからOpenTelemetry Collectorを経由してログが送りつけられるようになったことで、それが分からなくなってしまったということです。

実際には、Cloud Loggingは構造化ログに含まれているメタデータを見ることでGoogle Cloud上のどのリソースで発生したログなのかを判断しているようです。そのため、本来Cloud Runがやっているであろう構造化ログへの属性の付与をアプリケーション上で行えば、こうした機能を維持できるようです。実際、そうした処理を自動で行うためのエージェントもGoogle Cloudから出ているようです(どちらもヘンリーでは検証していません)。

しかし、stdoutに書き出すだけの標準の連携に比べると、構造化ログをいじったりエージェントを追加するのは少々手間でした。また、今までとログの出方がやや変わってしまう不安もありました。そうしたことから、ヘンリーではログだけ今までどおりstdoutによるCloud Loggingへの連携に倒しました。図解にすると、次のような構成です。

ヘンリーのオブザーバビリティバックエンド構成

オブザーバビリティにおいて重要なのは、ログやメトリクスをトレースと紐付けることです。Cloud Loggingの場合、上記図解のような構成でも一工夫加えることでログとトレース(スパン)を紐付けることができます。構造化ログにtracespanIdという属性を生やすだけです。アプリケーション上でOpenTelemetryのSDKを用いることで、現在のリクエストのコンテキストにおけるtraceとspanIdを取得し、構造化ログに埋め込みます。

学び

ここで伝えたかったことは、一口にOpenTelemetryを採用するといっても、クラウドの技術スタックに応じて各シグナルの最適な扱い方が変わりうるということです。

ローカルで検証しているうちは、トレースもログもメトリクスも全てotlpでOpenTelemetry Collectorに送って、そこからJaegerなどの各種オブザーバビリティバックエンドに送ればいいような気持ちになります。しかし実際には、Cloud Logging等のクラウドプラットフォームに付随するオブザーバビリティツールの標準の連携を活かすほうが速かったり、従来のログやメトリクスの出方を大きく変えたくない場合などが出てくると思います。

そのため、クラウド上でのシステム構成のイメージを早めにつけた状態で、検証の計画などを立てていけると良いと思います。

まとめ

OpenTelemetryの活用方法は実際のところクラウドに大きく依存します。PaaSがOpenTelemetryに干渉したり、ツール間のシナジーを活かしつつOpenTelemetryのパワーを最大限発揮したくなったりします。

こうしたことを踏まえ、クラウドドリブンでOpenTelemetryの導入を検討・検証していくとよいのではないでしょうか。そして、トラブルにぶつかった際にはこの記事の内容を思い出していただけると、何かの役に立つかも知れません。

ヘンリーでも、今度はDatadogの採用を検討していますが、この記事で紹介した経験を踏まえて、トレースだけでなくログやメトリクスのDatadogへの流し方や紐づけ方について最初から仮説を立ててPoCを進めています。

ヘンリーではSREやQAエンジニアなど各種職員を募集しています。話だけでも聞いてみようかなと思っていただけるようでしたら、ぜひご連絡ください。お話しましょう。

カジュアルな社内勉強会 : ギベンの紹介

この記事は株式会社ヘンリーのカレンダー | Advent Calendar 2023 - Qiitaの 12/8 の記事です。昨日は和田さんの医療現場のプロダクト開発をする事になった私が現場を理解するためにしていることという記事でした。

ヘンリーで SRE をやっている id:nabeop です。職種は SRE ですが、有志として社内の技術的なアウトプットの後押しを隙間時間でやっています。今回は後押し施策の1つとして社内技術勉強会 (略してギベン) を立ち上げたので、その様子について紹介します。

ギベン立ち上げの経緯

ヘンリーではギベンが開始される前から技術にかかわらず、特定の話題に興味がある有志によって勉強会が開催されていたので、勉強会が活発な組織という印象がありました。ただし、継続的な勉強会というわけではなく、スポットで勉強会が開催されるという感じだったので、気軽に参加できるようなゆるい感じの勉強会が定期的に開催さると良いかも?と思っていました。

そのような中、今年の夏頃に id:Songmu さんが「社内技術勉強会をやるぞ」というエントリが社内ブログで出されました。

id:Songmu さんの技術勉強会立ち上げのエントリ

そのエントリのなかで id:nabeop はノウハウがありそう、ということで指名がありました。実際に前職でも技術勉強会の運営には携わっていたし、ヘンリーでも同様の取り組みをしたいと考えていたので、やるぞ!という気持ちになりました。

立ち上げエントリの2日後に運営に名乗り出たアンサーエントリ

カジュアルだけど継続して開催できる場を作るために考えたこと

まず、技術勉強会の目的は

  • 社内のエンジニア同士の横の情報共有の促進
  • 技術発進力の向上

の2つを目的にしました。

ヘンリーでは元々ほぼ全ての人がリモート勤務で、人数も増えてきたということもあり、他チームの様子やそもそも仕事であまり関わることもない人もできてきたので、気軽に情報共有をしつつ、人となりがわかるようにしたいと思っていました。特に僕は開発チームに所属しないで組織横断で改善を進める部署の SRE をやっているということもあり、他チームとの交流は積極的にしていきたいと考えていました。

また、ヘンリーではエンジニア含めて積極採用を展開していることもあり、世の中でのプレゼンスを上げたいと考えてもいます。技術勉強会で発表経験を積んで、対外発表のハードルを下げたいし、対外発表のネタになりそうな情報の共有もできたら嬉しいと考えていました。

このような背景もあって、個人的には上記の目的に加えて、

  • 気軽に発表できる雰囲気作り
  • 継続して開催できる

という裏目標を設定しました。

気軽に発表できる雰囲気を作るために、アンサーエントリに以下のように書いてみました。

  • 発表内容は難しく考える必要はないです
    • 仕事の内容に関わらず趣味の範囲でやっていることの共有とかでも良いです
    • 発表のクオリティーは一旦忘れましょう。なんならノー準備でも大丈夫です
  • 聴講者の場合はコメントをいっぱいして盛り上げてください
  • 発表が得意な人は相談にのるなど、手助けをしてもらえるとありがたいです

この手のイベントを継続して開催するためにはコンスタントに発表者が確保できることが前提になってくるので、ハードルを高く設定しすぎないようにコントロールしつつ、発表してよかったという体験をしてもらえるように心がけています。とくに、あまりハードルをあげすぎると発表者の確保に難儀するということは経験的に知っていたので、期待値のコントロールには注意する必要があると考えています。

なので、「発表のクオリティーは一旦忘れましょう。なんならノー準備でも大丈夫です。」というところは結構重要です。実際に僕が発表する時に全く資料を用意しないで、普段使っているエディタである Emacs を設定ファイルを映しながら解説する、みたいなゆるい感じでやってみました。

また、「仕事の内容に関わらず趣味の範囲でやっていることの共有とかでも良いです」とあるとおり、「技術」勉強会と名乗っていますが、特にトピックについて限定していません。これは何かしら喋りたい内容が出てきた時に「これはギベン向きな内容か?」と考えずに発表して欲しいし、むしろ仕事以外で興味をもっていることを話してもらうと、同僚の個性が知れて、より交流が進むのではないかと考えたからです。

さらに、後からも見返しつつ、ギベンの雰囲気を感じてもらえるように

  • ギベンは Google Meet の録画機能を使って保存し、かつ、コメントも Google Meet のチャット機能によってコメントのタイムスタンプ付きで保存されるようにする
  • 後日、録画を YouTube にアップロードする時にコメントも追加する

というようなことをしています。

使っているエディタを紹介する会の様子

ギベンの様子

このような感じで2023年の8月から始めた毎週月曜日の夕方の30分枠でギベンを初めて、休日以外は毎週開催できています。個人的に印象に残っているのは以下の発表でした。

  • OBS 解説
    • OBS は気になっていたけど、実際にどんな雰囲気なのかとかがわかってよかったです
    • 僕は mac ユーザで、macOS で動かす時の注意点とかも教えてもらえました
  • treesitter 紹介
    • treesitter については emacs 29 から標準で使える、くらいの情報しか知らなかったけど、この発表をきいてええやんとなって、emacs 29 で積極的に使おうという気持ちになれました
  • ISUCON 13 反省会
    • ISUCON の翌日に参加者からの報告がきけてよかったです
    • 最近は参加できていなかったけど、来年は参加したいという気持ちになりました

他にも各方面から間接的に良い取り組みだね、という話も聞いているので、引き続きやっていきたいですね。

また、外部で登壇する前にギベンで発表してみて、発表内容のブラッシュアップをするなど、内向けのアウトプットから外向けのアウトプットへのリンクも出来上がりつつあります。ゆくゆくはギベンで発表した内容が外向きのアウトプットに昇華されるようなケースも出てくると良いなと思っています。

Advent Calendar 2023をやるので2023年を振り返ってみます

💡 こちらは株式会社ヘンリー Advent Calendar 2023の第1日目の記事です。

ヘンリーエンジニアブログ初回の記事がリリースされて300日余り経ち、この間計18エントリーが公開されました。数はそれほど多くないですが、年初公言していた「蓄積してきた失敗談や技術ノウハウのシェア」はある程度行えたのではないかと思われます。そして、この12月、さらにシェアを増やすべく、有志の企画によりヘンリー史上初のアドベントカレンダーを行うことになりました。僭越ながら今回は引き続き私、VPoEのshenyu_cyanよりトップバッターを務めさせていただきます。

年初の記事では開発者体験、ユーザー体験とスケールアウトの3側面から展望を述べさせていただきましたので、今回はこの3側面から振り返らせていただきます。

DALL·E作アドベントカレンダーイメージ図

スケールアウト

初めからはわかりやすいスケールアウトの話よりスタートします。スケールアウトの観点で考えるとき、人数と事業の二角度が視点に含まれていると思われます。事業の成長によって人数を増やす判断につながり、人数の増加によって事業の可能性が広がる為、両者は切っても切り離せない相互依存の関係だと考えられます。

まず人数の増加によるスケールアウトの施策が実施されました。イメージしていただくために最も集計しやすい客観的データを上げますと、ヘンリーの正社員数は2022年12月31日時点27名でしたが、2024年1月1日には50名以上になる見込みです。プロダウト開発のメンバーに絞ってみても17名から30名になるので傾向が同じく、ほぼ倍増として捉えられます。

そういう背景の中で、チーム構成とアプリケーションアーキテクチャの再編が不可欠になり、プロダクトチームに関する大きな再編が計2回行われました。開発時にますます痛感する認知過負荷を解消するために、4月に開発チームの分界点を見直し、コンプリケイテッド・サブシステムを解除した上ストリームアラインドチームを2つ立ち上げることにしました。また、8月にプロダクト組織内の役割分担を見直し、それぞれのロールを再調整しました。例えば、より抽象的な課題に取り組むCTO室の新設やカスタマーサクセス関係の開発機能の分割はまさにその時から始めました。その中、VPoEの業務範囲を合わせて広げるようにし、開発組織の価値を引き上げ続けるロールと仕組みの展開にフォーカスするロールへ分けました。

アプリケーションアーキテクチャの再編は4月のチーム再編と同時に行われていたため、解きたい課題がつながっていました。正確な分界点をより簡単に探り出せ、効率的に試行錯誤を繰り返せるようにしたく、マルチリポからモノリポへの移行を実施しました。技術面でのしっかりとした準備のおかげでスムーズな移行が達成できました。

組織とアーキテクチャの再編について、正解がわかっているわけでなく、みんなで一緒に手探りしながら実施している中で、来年以降振り返ってみたら微妙だったという所感が全然あり得ます。それでもバリューの「ドオープン」の元で、ADR(Architecture Decision Records)の役割と同じようにブログや社内Notionにちゃんと記録を残し、苦労の実体験を今後のヒントに繋げていけたらと考えます。

ユーザー体験

ヘンリーではUI/UXのガイドラインと製品コンセプトを掲げた上プロダクトの開発を進め、ユーザー体験の一貫性を保ちながらプロダクトの進化を目指しています。ユーザー体験を追求する中、今社内で最もよく使われている言葉はジョブ理論の「ジョブ」です。聞き慣れていない方も多いと思いますが、我々の中では達成したいこと(WillとWant)と解釈しています。

社内の説明用スライド抜粋

院長や看護師長、医事課長の方々にご協力を仰ぎ、医療機関の各ロールがやっていることと実現したいことを整理し、各ジョブの落とし込みを行いました。それらの実用化はまだこれからですが、プロダクト作りにきちんと反映していけたらと考えています。

また、実践面でも多くの工夫を重ねてきました。例えば、ヘンリーのプロダクトはもともと純React SPAでしたが、利用時の待ち時間によるストレスを解消すべく、Next.jsの導入に至りました。アーキテクチャも変わった大きめの変更でしたが、事前検証と同時期に導入され始めたMablのおかげで大きな不具合が現れませんでした。さらにフロントエンドのルーター部分に関して、React Suspenseを利用することになり、遷移体験が向上しました。

上記のようなわかりやすいユーザ体験向上と別に、常にヘンリーを満足して利用いただくために、適切なサポートが不可欠です。お客様からの問い合わせが来た場合、状況を迅速に理解するために、2つの側面から工夫を行いました。まず、サービス上の画面操作を記録するブラウザ拡張機能を提供し、お客様端末側の事象を特定しやすくしました(技術詳細については後日のAdvent Calendarにて公開予定)。同時に、プロダクトの可観測性向上を繰り返して行い、裏側の改善もしっかりと進めました。とはいえ、改善余地はまだたくさん残っていると考えています。これからはより手を広げ、可観測性関連ツールの活用を検討していく予定です。

開発者体験

開発者体験に関して、引き続き重要視しながら技術選定をしていると感じます。年初以降の技術スタック変化に関して、速度向上とDoppelgangers問題解消のためにpnpmの導入を実施したり、コンポーネントテスト作成の省力化を実現するためにChromaticを導入したことはまさに好例だと考えます。上記のNext.jsの導入の場合でも、開発者体験の向上を一要因として上げていました。

多くの改善のうち、ChatOpsの推進によってもたらされた開発者体験の向上は、触れなければいけないと考えます。例えば、ヘンリーではセキュリティ担保のためにGoogle CloudPlatform周りのスーパーユーザ権限を付与しない運用になっています。そのため、インフラに関する一時的な変更などを行いたい場合、専用リポジトリに対してPull Requestを送り、権限をもらう必要があります。そういった権限申請をSlackで半自動的に実施可能になったおかげで、わざわざGitHub上からPull Requestを作成する手間が減り、レコードも取りやすくなりました。

それに、ツールによる開発者体験の向上はもちろん大事ですが、人数が増えてきている中、技術トピックに関する交流の促進はもう一つ大事なテーマになってきます。ありがたいことに、有志による社内技術勉強会が企画され、コンテンツが多種多様で、私を含む多くの方にとって毎週の楽しみになっています。

社内技術勉強会のコンテンツ

加えて輪読会も継続的に開催され、「オブザーバビリティ・エンジニアリング」や「ソフトウェア見積り」のような名作が続々と今年の輪読会にて読破されました。輪読会形式なので、本の内容より行われた議論は最も多くの収穫につながったと感じますので、そのメリットをちゃんと享受できるようにしていきたいと思います。

振り返ってみて

2023年はまだ残り1ヶ月ではありますが、振り返ってみたら私個人にとっても、ヘンリーの組織にとっても変化の激しく、学びの多い一年になっていると考えます。

まず私の仕事の幅が大きく広がったため、これまで触れようと思わなかった知識や経験にたっぷり触れるきっかけが多く生まれました。私は元々技術畑の人間であり、ヘンリーに参画して以来は主に開発組織のチーム作りを行ってきました。しかし今は開発組織のみならず、全社範囲の組織作りに携わっています。職種とメンバー構成の違いによって、必要になってくる設計思想が異なります。手探りをしながら、実践と学習のループを回しています。

組織の角度から考えた場合、新しい仲間の参画によりもたらされた変化が最も学びのきっかけになっていたと感じます。前述のように、人員拡大によって組織の再構築およびチューニングの繰り返しが必然となり、そのプロセスからたくさんの経験が生まれました。特に今の主力製品である中小病院様向けのHenryが今年の年初にリリースされたばかりと考えたら変化の目紛しさが非常に印象的で、感慨無量と言えます。

また、新しい仲間の加入は新しい考え方をもたらしてくれました。ヘンリーに入社する方にはミッションである「社会課題を解決し続け、より良い世界をつくる」とバリューの「理想駆動・爆速アウトプット・ドオープン」への共感を求めていますが、みなさんの人生経験やこれまで歩んできたキャリアがそれぞれなので、性格がもちろん多種多様です。そこで異なる思想の交流による考え方の火花が生まれ、数多くの創意工夫や変則的な思考に繋がりました。今日から25日までの記事はある意味その体現だと考えています。ぜひ毎日の記事をチェックして頂き、交流を深められたら幸いです。

OpenTelemetry Meetup 2023-10 で登壇しました

ヘンリーで SRE をやっている id:nabeop です。2023/10/19 に開催された OpenTelemetry Meetup 2023-10に登壇したので感想とフォローアップエントリです。

まず、Meetup の企画をしていただいた運営のみなさま、素敵な会場やオンライン中継をご提供いただいた CARTA HOLDINGS 様に感謝します。本当にありがとうございました。当日は久しぶりにたくさんの聴講があるイベントの登壇で緊張しましたが、素晴らしい発表も聴けてとても実りが多い Meetup でした。

登壇内容

今回の登壇資料は Speakerdeck にアップロードしています。

speakerdeck.com

今回は時間の関係で複数のアプローチを PoC 環境で構築しての比較までしか共有できませんでしたが、社内では引き続き OpenTelemetry の構成見直しは進んでいて、近いうちにサービス環境の OpenTelemetry 周りの構成を入れ替えて、可観測性の向上に繋げたいと思っています。このあたりはまた機会をみつけて、得られた知見をみなさんにお届けしたいと考えています。

さて、今回の発表ではお金の話が目立ってしまいました。確かに Cloud Native な環境で可観測性を獲得するためにはそれなりのコストがかかります。しかし、抽象度の高い PaaS などの環境に構築された複数のコンポーネントが複雑に関連していることが前提になってきている場合は何らかの手段によって可観測性を高めるための手段の導入はサービスの安定性の維持には必要不可欠です。

実際に我々も OpenTelemetry は導入していて、可視化されたトレース情報による恩恵を実感したものの、保存されているトレース情報に課題感を感じたので、今回の見直しをしています。今回の発表のように導入にはいくつかのアプローチが存在し、それぞれにコスト面でのメリットとデメリットがあります。他にも運用面や開発面でのメリットとデメリットがあります。それぞれの環境でバランスが良い選択があるはずなので、今回の発表が選択時の参考になれば嬉しいです。

僕以外の方の発表内容もとても参考になって、@ymotongpoo さんの OpenTelemetryのここ4年の流れは OpenTelemtry が登場した背景を丁寧に解説していただけたので、自分の中の知識も整理できて助かりました。とくに OpenTelemetry が設立された背景は全く追えてなかったのでよかったです。

また、逆井さんジョインしたチームのマイクロサービスたちを再計装した話は、ちょうど僕らも PoC が終わった後には計装の詳細を詰めていく必要があるので、実務の経験からくる知見はとてもありがたかったです。このあたりの知見は日本語ではまだまだ出てきていないので、僕らも同じように知見が共有できるようにしたいとう思いを改めて実感しました。

Q&A セッションで話題に出ていた exampler については僕も全然知らない話題だったので、配信のアーカイブなどで復習したいですね。

今後

今はインフラ面の構成方針はおおまかにはきまっていて、あとは細かい構成の調整や計装内容について検討しているところです。遅くとも今年中には本格的に稼働を開始して運用知見を貯めるフェーズにしたいと考えています。

ヘンリーでは Observability の整備の他にも複雑なシステムに正面から向き合って、社会課題を解決していく仲間を募集しています。興味のあるかたはぜひご連絡ください。

jobs.henry-app.jp

ダブルVPoEが取り組むチーム作りとは?急拡大するヘンリーの“芯”|ヘンリーという組織を紐解く

株式会社ヘンリーは、「社会課題を解決し続け、より良いセカイを創る」というMissionのもと、中小病院向けの基幹システムであるクラウド型電子カルテ・レセプトシステム「Henry」を開発・展開しています。

2023年2月には中小病院向けプロダクトをリリースし、事業の成長とともに組織の急拡大を図るフェーズに入ったヘンリー。8月からはVPoEを2人体制とし、エンジニアの採用・育成・評価などを強化していくことになりました。

今回は、ダブルVPoEとして開発組織のチーム作りに携わる張沈宇(Cyan:シアン)さん松木雅幸(Songmu:ソンム―)さんのお二人にお話を伺いました。ヘンリーがチーム作りにおいて大切にしていることや、今後の急拡大において注意すべきこととは、一体何なのでしょうか。

シアン(左)とソンムー(右)

組織拡大に伴う課題を解決するため、ダブルVPoEに

─ 今回、VPoEが2人体制になったのはなぜですか?

シアン:ヘンリーでは、2024年末までにフルコミット(週3日以上、計24時間以上勤務の従業員。2023年10月現在で47名)の数を100人以上にまで増やしていこうと計画しています。その計画通りに進めていくために必要な採用力を強化したり、組織が大きくなるにつれて出てきてしまいそうな課題をどんどん倒していくためには、VPoEが私1人では手が足りませんでした。

また、ヘンリーはエンジニア市場における存在感がまだまだ弱く、良さを知ってもらうための発信も必要だと感じていました。ソンム―は発信力を持っていますし、そういった面でも強みが発揮できるということもあって、ダブルVPoEという体制を作ることになったんです。

ソンム―:ヘンリーは今年の2月に中小病院向けのプロダクトをリリースし、今ではその手応えも感じられるようになってきました。ただ、そのプロダクトや事業の成長に合わせて、組織もどんどん拡大・成長させていかなければならない。そこが課題として出てきそうだと認識していますし、エンジニア採用や組織作りの面でやるべきこともたくさんあります。

つまり、採用力を高めてプロダクトチームの採用速度を上げ、組織を急速に拡大させていく必要があるのです。そこで、採用や組織作りに関わってきた私がVPoEになって、2人体制で進めていくことになりました。

─ お二人の役割分担について教えてください。

ソンム―:私は主にプロダクトチームの採用と技術広報、ヘルスチェックをメインに行っています。エンジニアの採用自体はもともとシアンがやっていたのですが、VPoEになって引き継ぎました。これまで私がやってきたことを生かしながら、開発組織をより良くしていくのが私の役割だと考えています。

シアン:私はプロダクトチームだけでなく、全体的な採用に関わるようになりました。必ず選考フローのどこかで顔を出す、という形ですね。ただ、業務内容としては採用をメインに行っているわけではありません。

社内外への広報やオンボーディング、目標設定など全社の施策に対して広く浅く携わり、どちらかというと採用より後の段階で、文化作りや仕組み作りの部分に関して動いているようなイメージです。

バリューを大事に、生き生きと社会課題に向き合うチーム

─ 現在のヘンリーは、VPoEの立場から見てどんなチームだと感じますか?

シアン:「生き生きしているチーム」だと思います。そしてメンバーがちゃんとプロダクトの価値を認識していて、自分たちの仕事によって社会に貢献していくぞという想いを強く持っています。

それが顧客の本質的なニーズや課題を深掘りして、その課題を解決するためのソリューションとしてプロダクトを提供しよう、という動きにつながっているのがヘンリーというチームが持つ強みなのではないでしょうか。

ただ、人が増えてチームも複数に分かれてきたことで、チーム間でのコミュニケーションが不足している部分は課題だと感じています。チームをまたいでフィードバックしあうような仕組みを作って、人が増えても組織全体で一体となって動けるように改善していきたいですね。

ソンム―:私もそう思います。ヘンリーのミッションが「社会課題を解決し続け、より良いセカイを創る」だからということもあり、ちゃんとチームで課題解決していこうと思って入社されている方ばかりなので、素敵な人が揃ったすごくいいチームだなと感じますね。

あとは私たちのバリューに「理想駆動」「爆速アウトプット」「ドオープン」という3つの考え方があるのですが、特に「ドオープン」の情報をオープンにする文化は、今いるメンバーと今後入ってくる方とで意識の差が生まれてくるのではないかと懸念しています。

そのあたりもちゃんと組織全体でエンジニアリング的に駆動していくことが、今後大事になりそうです。

─ チーム作りを行っていく中で、お二人が大切にされているポイントについて教えてください。

ソンム―:私たちはまだ小さいスタートアップ企業です。だからこそ、メンバーの中で「ヘンリーが世の中にどういう価値を提供しているのか」という目線を揃えることが大切だと思っています。

その上で、気持ちよく働いてもらえる環境を整えていくことが必要なのではないでしょうか。

シアン:その通りですね。事業だけが成長していくのではなく、事業とともに急成長できる組織を実現したいという観点も大切にしています。さらに言えば、事業がうまくいかなかったケースのことも考える必要がありますよね。

ソンム―:事業が苦しい時はきっとどうしてもやってきますが、そこで大事になってくるのがミッションやバリューといった文化だと思います。自分たちの行動指針や価値基準がきちんと浸透していれば、たとえ事業が苦しくても、人がどんどん抜けていって組織ごと崩壊する、といったことにはなりにくいのかなと。

─ バリュー浸透のために行われている取り組みはありますか?

シアン:「理想駆動」「爆速アウトプット」「ドオープン」3つのバリューを社内のSlackスタンプにして、みんなで使うようにしています。定例ミーティングの中では、最近スタンプが押されていたスレッドを発表して、バリューを意識してもらう取り組みも行っています。

ソンム―:バリューはちゃんと解釈することがすごく大事で、「これは理想駆動/爆速アウトプット/ドオープンを体現してるよね」とすり合わせていくことで文化が醸成されて認識が揃っていくのだと思うので、Slackのスタンプはいい施策だなと感じています。

バリューは自分たちが行動するときや、どういう人と働きたいか、どういう人が評価されてほしいか、といった部分を映す鏡であると思うので、大事にしながらアップデートしていきたいですね。

オンボーディングコンテンツもさらに強化

─ では、働きやすい環境を整えるためにやっていること・今後やっていくことはありますか?

シアン:今はオンボーディングにすごく力を入れていますね。入社する前の段階からどんな体験を提供したらスムーズにキャッチアップできるのか、入社した後は一人前になるまでどのようにサポートしていくのか、その後も継続的に生産性を向上させていくためには、といったことがヘンリーでの働きやすさに関わってくるので、全方面で設計を進めています。

─ オンボーディングの施策について、もう少し詳しくお聞かせください。

シアン:今やっているオンボーディングのコンテンツとしては、Notionに各自1つオンボーディングシートを作成して、取り組むべきタスクをチェックリストにしています。入社1日目には何をすべきか、最初の1週間ではこういうことをやって、といったタスクをこなしていって、その中でいろんな情報をキャッチアップしていくというイメージです。

Notionのオンボーディングシート

ただ、医療ドメインは複雑で深い世界なので、病院での実際のオペレーションやワークフローなどの実践的な知識も含め、もう少し踏み込んだオンボーディングをしなければなりません。今はそのあたりを整理・設計している段階ですね。

やるべきことの数が多くなってくると、今のようにチェックリストでこなしていくのは結構大変なので、ゲーム感覚でクリアしていけるように設計することを心がけています。ここはずっとブラッシュアップし続けるべきところですね。

複雑な医療ドメインに立ち向かう強いチームを作っていく

─ 現在のヘンリーは採用に力を入れて、どんどん人を増やしていく段階にありますが、急拡大に伴い注意しなければならないと感じている点はありますか?

シアン:出会える課題を先回りして特定し、内部の制度と仕組みをちゃんと整えなければならない、というところですかね。特にポジションが多くなると引き継ぎが不十分になったり、対応の精度が欠けてしまったりする可能性も考えられるので、コミュニケーション不足が起こらないように意識した組織作りをしなければなりません。

ソンム―:今、エンジニアの採用は売り手市場で、プロダクトチームの採用は難易度が高いのが現状です。それでも数値目標のために採用の基準を下げるようなことはしてきませんでしたし、これからもしないよう注意していきます。

あとは採用基準を明確にしておくことも大事ですよね。単にスキル的なことだけではなく、我々のカルチャーにフィットしているかとか、不確実性の高い状況でも楽しめるかとか、そういった基準をはっきりさせた上で採用を進めていかなければならないと感じています。

─ エンジニアの採用を行う際は、どのようなことを大切にされているのでしょうか?

シアン:ヘンリーのメンバーは優秀な人が揃っていますので、そのメンバーと一緒に働けるスキルセットが大切なのはもちろん、複雑なドメインの難しさに負けずに自分事化して取り組めるかどうか、といったところも採用のキーポイントになります。

我々受け入れる側としても、難しいドメインに飛び込んできてくれる人への受け入れ体制をしっかりと整えて、心配せず飛び込んできてもらえるような環境にする必要がありますね。 ─組織としてやるべきことと、個人がやりたいことのバランスは取れていますか?

ソンム―:今は事業の成長・拡大を大切にしたいフェーズでもあるので、全てのメンバーの「これがやりたい!」という希望を叶えられているわけではないと思います。でも個人のやりたいことも大切にしたい、という想いはみんなが持っています。

社内ではwill-can-mustの話がよく出てきますし、採用のタイミングであったり、人の配置転換や役割の変化が発生するときに「その人のwillはどうなんだっけ」という話はかなりたくさんする会社です。やっぱり、自分のやりたいことをやっていた方が生産性の向上につながるのは間違いないですし、今後も疎かにしたくない部分ですね。

一人ひとりが熱意を持って成長し続けていくヘンリー

─ お二人が描くVPoEとしての展望についてお聞かせください。

シアン:これまでプロダクトチームにフォーカスして動いてきましたが、今後はヘンリーの組織全体に目を向けて、カルチャーを作っていく立場になります。プロダクトチームのチーム作りで感じた課題や培ってきたノウハウは、プロダクトチーム以外のところでもしっかり活かしていきたいですね。

ソンム―:私はスタートアップの熱狂が好きで、みんなで目線や価値基準が揃っている中で物作りをしていく過程が好きなので、それを組織が拡大していく中でも維持していきたいと思っています。

だんだんと一人ひとりの当事者意識みたいなものが薄れてきたりとか、組織が縦割りになっていったりとか、それで熱を失って面白くなくなってしまうことは、組織拡大に伴って起こりやすいと思うんですよね。そういうことが起きないように抗いたいという想いはすごくあるので、文化の定着やチームワークの促進といったところに取り組んでいきたいです。

─ 最後に、ヘンリーに興味をお持ちの方へのメッセージをお願いします。

ソンム―:ヘンリーはエンジニアリングに対する理解度がかなり高い組織です。営業の人やCEOの2人も、エンジニアリングのことを学んだり目線合わせをしてくれているので、エンジニアにとってはかなりいい職場だなと思いますね。

また、企業としてあるべき姿を描いて「理想駆動」していくこと、そしてみんなが立場や情報を「ドオープン」にして「爆速アウトプット」していく、というバリューはやっぱり大事にしたいと思っています。そういったところに共感していただける方は、ぜひ一度カジュアル面談などでお会いしましょう!

シアン:ヘンリーはこれまでも激しい変化を経験してきました。これから成長を加速させていく中でも、課題が出てきたらみんなで解決し、その繰り返しの中で組織も様々な変化を変化を遂げていくことでしょう。

そういった課題解決のプロセスや変化のプロセスを味わいながら仕事がしたいという方には、ヘンリーはすごく面白い環境だと思っています。今後新しく入ってこられる方とも一緒に楽しんでいけたらいいなと思いますので、まずは気軽にお話ししましょう!


ヘンリーでは、さらなる成長に向けて採用も積極的に行っています。ご興味をお持ちいただけた方は、ぜひお気軽にご連絡ください。

https://jobs.henry-app.jp/