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

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

スタートアップの熱狂と急成長を両立させる野望

VP of Engineeringのid:Songmuです。このエントリーは株式会社ヘンリー Advent Calendar 2023、最終日の記事です。

ヘンリーは今年、本丸の病院向け電子カルテ・レセコンシステムのサービスを開始し、順調に事業が立ち上がっています。早くも業界でもユニークなポジションを獲得し、注目度も上がっています。

そんな中アクセルを踏む決断をし、来年は組織として100人採用に踏み切ることになりました。

ビジネスを勝ち切るためのアクセルを踏むフェーズにおいて、自分がVPoEとして採用や組織開発に主体的にチャレンジできる立場にいることは喜ばしいことです。その中で自分が考えていることを書き出していきます。

公器を志向すること

「面白法人でありながら上場することに意味と面白さがある」

2011年頃、当時私が所属していたカヤック社で代表の柳澤さんが度々こう言っていました。カヤックとして上場を意識し始めた頃です。もともと上場を狙っていた会社ではなかったこともあり、上場は多くのイチ従業員達にとってはどこか他人事で、正直その意義への実感は薄かったと思います。そんな中、その意義を定期的に言葉にし、社員にも考えてもらう示唆を与えていたのは印象に残っています。

世界の片隅で面白そうなことをやっていても自己満足に過ぎず、会社の面白さとそれに伴う価値をもっと広く世に問う事に意味があり、その一つとして上場がある。私はそのように解釈していました。

また、DeNAの南場さんの「不格好経営」に以下のような一節があります。「公器」と言う言葉を私が意識するようになった一節です。

南場カンパニーにしたいのか、それとも公器として育てていきたいのか (中略) 熟考の上、決意した。社会の公器として発展させるために責任を果たす 南場智子. 不格好経営 (p.143) Kindle版.

公器と公開会社であることは異なりますし、ここでその関連が語られているわけではありません。ただ、イチ企業が公器足るためには、公開会社であることは多くの場合必要条件でしょう。

自分たちに公共性の高いミッションがあり、その意義を信じていて、広く世の中に価値をもたらしたい、つまり公器足りたいのであれば、その正当性を公に問う必要があります。個人の自己満足や局所的な箱庭作りに陥っていないかも世の中に評価してもらうということです。上場して公開会社になることは、そのための手段でもあります。

公開して自分たちの価値を問う、というのは実はOSSの精神にも類似する部分があると感じます。

ヘンリー社も「社会課題を解決し続け、より良いセカイを創る」「人類の医療・介護インフラを創る」というミッションを掲げているので公器を志向しているはずです。

スタートアップと急成長

スタートアップにそういう志がある場合、単純に少数精鋭での高い利益率を追い求めるだけだけではなく、その絶対量も意識しないといけません。そのドメインやマーケットに変革を起こすのであれば、広くその領域を取りに行く必要があるからです。現実問題としてWinner takes allの傾向は強く、新規領域で先行者利益で突破するにしても、既存領域でゲリラ的にシェアを拡大するにしても、スピードが必要です。そうしないとマーケットを育てられなかったり、他社に押し負けたりしてジリ貧になる可能性が高いのです。

急成長が必要です。

スタートアップ初期の熱狂

私も何度か経験がありますが、事業やプロダクトが立ち上がった時期の熱狂は何事にも代えがたい快感です。特に、プロダクトリリース後に手応えを感じ始めた頃などは、それまでの苦しみがあった分、その喜びは格別です。

まだ少人数で、メンバー間に部活や研究室のような一体感があり、ミッションも何も言わずとも行き届くツーカーの関係が築かれています。

また、全員が事業やプロダクトの全貌を大体把握しており、プロダクトのどこを変更すればどのような影響があるか大体想像でき、自分の決断の結果がダイレクトに自分に返ってくるので自分ごと化しやすい。そういう全能感があります。

この、一体感と全能感が、この時期の熱狂の源泉です。

ただ、この段階はあくまでもスタートを切れただけであり、この後は急成長をする必要があることは先に述べました。そして、組織が大きくなるにつれて熱狂は薄れていってしまうものです。

また、この熱狂の快感にやられてしまった人間は、全員に全貌を把握してもらいパワープレーでゴリ押すことを志向しがちです。認知能力の高いメンバーを揃えて一つのチームでなんとかしようとする。システムの話だけで言うと、何十人も開発者がいるのに、一つのモノリシックなシステムを触らせるようなことです。私自身にもそういった傾向を自覚しています。

成長期における熱狂の失われ方

これまで大企業、百人弱から数百人規模のベンチャー、スタートアップなどに関わる中で、私は熱狂が失われる局面を多く見てきました。以下は自分の周りで起きたことや起きそうになったこと、友人から聞いたことの一部です。

  • 人を増やしすぎる
    • 受け入れキャパシティを超えた採用
    • 採用人数目標圧に負けて採用基準を緩めてしまう
    • 結果として採用が組織力向上に繋がらない
      • 人件費ばかり増える
      • キーパーソンの離職
  • 逆に人を増やしたいのに増やせない
    • アクセルを踏みたいが、諸事情により人が増やせない
    • 事業として勝ちきれない
  • チーム分割による縦割りとサイロ化
    • 相互無関心と局所最適
    • 全体最適を見れず利益を奪い合うケースも
  • 攻めと守りを分けすぎる
    • 守りをおろそかにして、一部の人に押し付ける
      • 「攻め」の人たちが出したゴミ掃除をさせられる感
    • 守り側の人が余計防御的になりブレーキを掛けすぎる
      • 全体のスピードが遅くなる
      • 感情的な対立も
  • ガバナンス軽視
    • できてないことを認識しているならともかく、認識すらできておらず、急にやるべきことが噴出する
    • 上場前にその場しのぎで作られた形式的なワークフローが負債的に残り続ける
    • 逆に無駄な事務作業が増え非効率に
  • 文化形成や明文化を怠る
    • コンテキストや暗黙的な情報格差による成果の出しやすさの格差
    • 結果としての新旧メンバーの意識やコミットメント格差
    • 社歴や部署間での文化の違いや派閥化
    • 社員のベクトルが揃わず、組織のバリューに繋がらない

多くの人が全体観を持てず、全体最適を考えて行動できなくなり、局所最適に陥ることで起きる問題がほとんどです。

私がこれまで所属した組織はいずれも自分を育ててくれて愛着がありますし、今でも仲良くさせてもらっています。幸せなことに、どの組織も悪人はいなかった。他人を蹴落として自分の利益とするような人はいませんでした。それぞれがベストを尽くそうとしていた。ネガティブなことだけ羅列したので印象が悪くなり申し訳ないですが、実際はかなり上手くやっていたと思います。どこも事業継続しているし、上場している企業もあります。

ただ、それでも個人的に歯がゆかったり、悲しい思いをすることも多くありました。当時の自分が、当事者として関わりきれなかったり力不足だったことも反省材料として残っています。

ヘンリー社では、VPoEとして組織開発の当事者としてそれらの課題に主体的に関わるチャンスを得られています。これは私のキャリアにおけるリベンジの機会でもあるのです。

健全に組織を拡大しつつ熱狂を失わないようにできるか、組織が大きくなる中で文化が壊れないようにしつつも事業の成長速度と人が増える速度を同じ角度に保てるか、それらの実現が私のヘンリーにおける大きな野望の一つです。

ヘンリーは事業とプロダクトを大きく伸ばしており、周囲からも急成長を期待されています。野望を実現する舞台が整っているし、実現させないといけない局面でもあるのです。

そしてチームトポロジー

結局、組織拡大においてパワープレーは持続性に欠けます。組織やシステムを権限分離して、独立性や自律性を高める話には向き合わざるを得ません。

なるべくシステムはモノリシックにして、単一チームでのパワープレーを維持したかった自分にとって、チームトポロジーは身につまされる本でした。認知負荷の限界があることを認め、それをどのように構造的に解決するか、という視点をこの本から得られました。

しかし、認知負荷の存在を認めつつもどう立ち向かっていくかがチームトポロジーなのであって、認知負荷に日和ってブレーキを踏み合っていたら意味がありません。局所最適に陥らず、チームが増えてコミュニケーションパスが複雑化してもスピードを落とさないようにしないといけません。

何事も境界をきれいに切ろうとすると、絶対に隙間が生まれてしまいます。境界部分のオーバーラップとインタラクション設計が重要です。人間、境界が見えてしまうと、どうしてもその手前でブレーキをかけることが増え、そこにポテンヒットが集まってしまう。組織においてそれが起こることは「技術の創造と設計」の以下の図がよく表しています。

「技術の創造と設計」p.17

システム設計におけるレイヤードアーキテクチャーも、境界をきれいに切り分けようとすると、逆に隙間だらけで融通の効かないスカスカのバームクーヘンになる危険性があります。

チームトポロジーもレイヤードアーキテクチャーも大事なプラクティスではありますが、形式張って進めすぎると、多くの衰退した大企業が歩んできた轍を踏むことになりかねません。組織の「成熟」を早め、いわゆる大企業病を加速させてしまう諸刃の剣であるように思えるのです。

私としては、境界の手前でブレーキを踏まず、その上での健全な衝突が発生することを良しとしたい。同時にお互いにストレスを抱え合うような、感情的で無駄な軋轢が起きてほしくないとも思っています。

矛盾に立ち向かうための幾つかのアイデア

このようなスタートアップが抱える一種の矛盾に立ち向かうために、個人的に意識している考えを幾つか挙げて行きます。

二項対立を超越する

人間には状況を把握するために二項対立で物事を整理したがる傾向があるように感じます。これはある対象が有害か無害かを瞬時に決断できないと自身の生死に関わったような太古の時代ならともかく、現代では悪癖とも言えます。これは名著「知識創造企業」で似非ダイコトミーとも表現されています。

先に述べたように、組織拡大においては、チームを分割して自律性と独立性と担保しつつも、それぞれが全体観を失ってはいけません。また、少数精鋭の方がスピードが出せるのは間違いないので、精鋭部隊を維持しながら組織を大きくしなければなりません。

それに限らず、スタートアップでは多くの困難な両立を実現する必要があります。「要はバランス」とか言わずに、まずは両取りを考えなくてはいけません。「知識創造企業」ではダイナミックな統合と言われているものです。「要はバランス」とかいい出した時点で二項対立に囚われており、その軸でしか考えられなくなるのです。

このエントリーのタイトルの、熱狂と急成長の両立も、私が実現したい困難な両取りのチャレンジです。

内集団バイアスに陥らない

スタートアップはそれ自体、内集団バイアスが高まりやすい傾向があります。そして、チームが分割され、他チームと断絶されたときにチーム内での内集団バイアスも高まりやすくなります。場合によっては外への価値提供よりも自分たちを守ることが優先され過ぎ、ともすればカルト的にもなり危険です。

組織は内向きになりすぎず、外とのつながりを常に意識しなくてはいけません。企業やチームにおいては、自分達の業務や活動が最終的にどのような顧客や世の中への価値提供につながっているのかというバリューストリームを意識するということです。

これは、全チーム、全社員が意識できることが理想です。自分たちは守りの仕事だから関係ないなどと思ってはいけないし、そう思われてしまうのであれば組織設計の失敗です。

分散と集中

多くの技術トレンドがそうであるように、分散と集中が螺旋のように繰り返されます。組織においても同様で、チームを分割するだけだと、無駄にチームが増えていくだけです。時には統合して分割し直すプロセスも必要でしょう。

両利きの経営

これは、書籍「両利きの経営」のタイトルそのままです。既存事業を深めて伸ばすための「知の深化」と、新規事業のイノベーションを生み出すための「知の探索」を両立する考え方です。この「深化」と「探索」の両軸の考え方は、普段の組織の業務設計の中でも応用が効く有用な分類だと感じています。

鉄郎のネジ問題

独立性と自律性を高めた結果、無味乾燥な業務にまで分割されたら、それは果たして業務を行う当人は幸せでしょうか。具体例としては過度なマイクロサービス化はエンジニアのモチベーションを奪いかねないといったことです。

これを私は「銀河鉄道999」からあやかって「鉄郎のネジ問題」と呼んでいます。色々考慮して行き着いた先が、無味乾燥で代替可能なパーツになることだとしたら笑えない話です。それが本当にあなたの欲しかった完全無欠な機械の体なのですか?という話です。

チームを分割するにしても、チームメンバーが創造性が発揮できてバリューストリームへの接続を意識できるレベルにとどめ置くべきでしょう。

銀河鉄道999 14巻 p.212

ポテンヒットをアウトにする

私は仕事においてお見合い落球が発生することが大嫌いです。そういう狭間に落ちそうになっているボールを積極的に取りに行く人が評価されて欲しいと思います。

そういう狭間の業務は、多くの人の死角に入っていたから狭間に落ちそうになっている訳で、目標設定のスコープからは漏れているものです。なので、目標に囚われすぎると、そういった業務を拾いに行くインセンティブはありません。これもまた悪しき局所最適です。

目標設定は大事ですが、それに囚われすぎ、全体最適な行動を取ることが称賛される風土作りや、インセンティブ設計をしたいと考えています。

組織開発上のアクション

これらの考えを元に、これまでとこれから私がどのようなアクションを取っていくかについて述べ、このエントリーを締めようと思います。

ミッション共感とバリュー浸透

組織の急成長の当事者として立ち会え、貢献できることは充実感が高く、得難い経験になるでしょう。しかし、時には痛みが出ることもあるでしょう。成長痛と言われることもありますし、そんな綺麗事では済まないケースもあるかもしれません。

そんな困難な状況ではミッションへの共感と高め、全員がそれを実現したいと思えるか、思ってもらえるかが大事です。最初の方に述べたように、公共性の高いミッションを掲げ、公器足るために急成長を志向しているわけですから、ミッションに共感して納得してもらう必要があるからです。

そんなチャレンジングな状況を楽しめるかどうかも大事です。そういう状況を乗り越えた先にはそれぞれのメンバーの成長もやってきます。それぞれの社会人としての価値も上がり、より面白くチャレンジングでリターンのある仕事がやってくるようになるはずです。

生存者バイアス的な部分がありますが、だからこそ、全員が生き残れるように、誰かに負荷が偏らないように、一丸となって乗り越えられるようにインセンティブ含めて設計する必要があります。

また、行動指針としてのバリューを浸透させていく必要があります。各人のベクトルを合わせて合力を最大化するためです。

その浸透の一環として少し前に社内でバリューについて考えるワークショップを実施しました。

ワークショップの様子

ミッションもそうでありますが、バリューは言葉だけだと曖昧です。そして「エラい」人が「分かっていない」人に説明を尽くそうとするほど、説明された側からすると、他人から押し付けられたモノ感が強まり、自分ゴト化が困難になります。

こういったものは実は曖昧でよく、各人が解釈することで、コンテキストが醸成されます。バリューは特に、ミッション実現のために、メンバー各位が大事にしたいことが抽出されたものでもあるため、全員にオーナーシップを持ってもらう必要があります。

メンバーに解釈してもらわずに放置すると、バリューはすぐに形骸化します。バリューを自分たちのものだと思ってもらえるように、定期的なワークショップなどを通してメンテナンスやアップデートをしていきたいと考えています。

1978年、ホンダのトップは「冒険しよう」というスローガンで新しいコンセプトカーの開発を打ち出した。 (中略) ホンダのトップが与えた使命の曖昧さは、開発チーム内に混乱を引き起こした。逆説的に聞こえるかもしれないが、この混乱が実は、全く新しいクルマをめざすというきわめてはっきりした方向感覚をもたらした。 野中 郁次郎; 竹内 弘高. 知識創造企業(新装版) (pp.38-39). 東洋経済新報社. Kindle 版.

採用

私が、ヘンリーの中で持っているメインのミッションが、エンジニア含めたプロダクトチーム全体の採用です。

採用においてはそれぞれの専門性に加えて、先に述べたミッション・バリューへの共感が大事です。ミスマッチによる採用失敗のダメージは大きく後を引くため、採用基準は妥協してはいけません。

私は、エンジニア採用を中心に採用には10年近く携わってきましたが、自分が採用に関わったエンジニアについては、失敗したことはほぼ無いと思っています。これは自分の中での自慢です。

ただ、一年で100人を超えるような採用ペースには携わったことはありませんし、そういうペースで多くの魅力的な人材を採用している企業に対して羨望の眼差しを向けてきました。

優秀な人が綺羅星のように集まり、それぞれがコラボレーションして思いもよらぬ価値を生み出せる環境は魅力的です。それを実現したいと考えています。

フィードバックサイクルの設計

「評価」というとアレルギー反応を起こしてしまう人が多いと思いますが、大事なのはフィードバックサイクルです。それを設計して改善し続け、それを回して経験学習を促進させ、個人や組織の成長につなげることです。

ここでも大事なのはミッションに共感し、バリューに沿った行動が取れているか、そして、各人がバリューストリームのどこにいるかを意識することだと考えています。外向きへの価値提供が意識されないと内集団バイアスが強まる危険性があることはすでに述べました。

自分たちがどのような価値を生み出しているかを意識し、それを表明する。それに対して周りからフィードバックをもらう。フィードバックには当然称賛も含まれます。その繰り返しが大事です。

それらを踏まえた評価設計にも取り組んでいきますが、あまりにも大きなテーマなので、それはまた別の機会。

ビルドトラップに気をつける

最後に自戒ですが、組織開発的なアクションはやりすぎてしまうことも多く、得てしてオーバーエンジニアリング的になりがちです。プロダクト開発における作りすぎ、いわゆる「ビルドトラップ」と言われる事象が発生しやすいのです。

プロダクト開発がそうであるように、やった方が良いことはたくさんありますが、その中で今やるべきことは一握りしかありません。また、内向きな指向が強まると、自分たちの行動を正当化しすぎる内集団バイアスにもつながり兼ねません。組織開発の営みも、やはり組織の体外的な価値提供にどのようにつながっているかを意識することが大事です。

自分たちのやっていることを正しいと信じて行動しつつ、それを常に疑い続ける。そのように矛盾を内在していきたいと私自身は考えています。

まとめ

本エントリーは、ヘンリーという有力な舞台の上で、私の過去に対するリベンジを果たしたい、という私の個人的な物語でもありました。スタートアップの熱狂を維持しながら中身の伴った急成長を実現したいし、世の中に価値を提供し続けられる組織づくりをしたいと考えています。

ヘンリーはまだ100人に満たないスタートアップですが、事業が立ち上がり、マーケットにも受け入れられ始めています。メインの仮説検証は終わり、価値を届けるサイクルを回し始められています。事業の確度も高くなり、各人が価値提供を実感してフォーカスしやすい状況です。

自分たちでも信じがたいことですが、ヘンリーは病院向け電子カルテ・レセコン領域において、信じられないくらいユニークで有力なポジショニングができています。そしてまだまだ課題は山積みです。カジュアル面談に来ていただいたらその辺りのお話をさせていただきます。

このような状況の中で、一緒にヘンリーで世の中への価値提供に取り組んでくれる方を募集しています。単に興味があって話してみたいというのも歓迎なので、まずは連絡をお待ちしています。

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

【この記事は株式会社ヘンリー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