はてなブックマーク

こんにちは。ヘンリーで VPoP (VP of Product) をしている agatan です。 2025年の10月から、これまでのエンジニアとしての役割に加え、VP of Product & 製品部門長という役割を担うことになりました。 これまではテックリードやアーキテクトなど、エンジニアとして、ヘンリーの複雑で巨大なドメイン（レセコン・電子カルテ）に技術面からアプローチしてきました。 VPoPという立場になり、プロダクトと事業をより俯瞰して見る中で、自分の中にあった「ある種の先入観」に気づくことができました。 今日はその言語化と、これからのヘンリーの開発組織が目指す「技術と事業の関係性」について書いてみようと思います。 この記事は qiita.com の1日目の記事です！ 「技術戦略は事業戦略の従属変数である」と知らぬ間に思い込んでいた 先日のアーキテクチャカンファレンスでもお話しし

株式会社ヘンリーで SRE をやっている id:nabeop です。 今回は SRE チームが中心になって Henry のクラウド基盤を Google Cloud から AWS に移行しようとしているプロジェクトについて紹介します。 なぜ、クラウド基盤を移行するのか? レセコン一体型電子カルテの Henry は開発当初からクラウド基盤として Google Cloud の Cloud Run や Cloud SQL を使っていました。Henry の開発当初はインフラ担当のエンジニアがいない状態でも少ない人数で最速でサービスを開発する必要があったため、インフラ部分が抽象化されている Google Cloud を選択するのはごく自然な選択だったと思います。 Henry の開発が進むにつれて、開発当初はクリニックを想定していましたが、回復期リハビリテーション病院や急性期のような複雑な機能が必要な医

ヘンリー CEO / CPOの逆瀬川です。 7/30(水)、当社主催で「Henry QA LT大会」を開催しました🎉 QAのスペシャリストとして活躍する豪華ゲスト3名が登壇し、ハイレベルなLTを繰り広げていただきました。 セッション内容と、公開OKな当日資料を公開します。 オープニング オープニング司会のodashoさん 会場提供をしていただいたFinatextの五十嵐さん 乾杯！！(私) LTの様子 実践！ホリスティックテスティング ヘンリー社 tsukiGさん tsukiGさんの発表の様子 サマリ ヘンリーではプロジェクトライフサイクルを定義して、開発プロセスを回している。 品質活動の4分類をマッピング！ 特徴的な活動 スリーアミーゴスの拡張として、ビジネスチームを召喚。小さな開発を実践してフィードバックを！ BDDの実践！ 探索的テストと、ユーザーの価値が届くかどうかの検証に重きを

株式会社ヘンリーで2025年3月からVP of Engineeringを務めている戸田（id:eller）です。任命から3ヶ月経ったので現状をまとめつつ、今後の見通しなどについてまとめたいと思います。 VPoEとVPoTの違い 私は1月からVP of Technologyも務めており、現在は兼務している状況にあります。本題に入る前にこれら2つがどう異なるか、ヘンリーではどう考えているかを整理してみます。 VP of Engineering（VPoE）はエンジニアリングについてステークホルダーに説明責任を持つポジションであると定義しています。エンジニアリングとは工学ですから、VPoEは工学的アプローチ、特に組織づくりや開発プロセスを見るわけですね。ヘンリーは組織規模を拡大している最中で、またフルリモートを特徴のひとつとしている会社でもあるため、組織づくりや開発プロセスは投資する価値が高い状況

株式会社ヘンリーでオブザーバビリティをやっているsumirenです。 弊社ではトレースバックエンドにHoneycombを活用しています。いまや多くの方が日々の業務で使うようになり、プロダクトの運用になくてはならないものになりました。 この記事では、ヘンリーのメンバがHoneycombをどのように使っているか、Honeycombのアクティビティログから事例紹介します。 ヘンリーにとってのHoneycombの価値 トレースバックエンドというと、おそらく多くの方が1リクエストのツリーを可視化する用途を想像するかと思います。しかし、ヘンリーでHoneycombが定着しているのは、スパンの集計が非常に強力だからだと筆者は考えています。 この記事を通じて、ログの集計やメトリクスではなく、スパンを探索的に集計できることの価値の大きさや面白さが伝われば幸いです。 事例1. ある機能を各テナントのユーザーが

こんにちは。株式会社ヘンリーでエンジニアをしているagatanです。 私たちが開発する電子カルテ・医事会計システム「Henry」は、非常に巨大な単一のプロダクトです。そして、その性質上、明確なドメイン境界を見出すことが難しいという特性を持っています。この「巨大で複雑なプロダクトを、いかにして組織的に開発し続けるか」という問いに開発チームは長年向き合ってきました。 最近、この大きな問いに対する新たな一手として、かつて2つのgRPCサービスとして分割されていたバックエンドを、段階的に「1プロセスのモジュラーモノリス」へと移行させるプロジェクトが進捗しています。 今回は、その移行の過程についてお話しします。 第一歩: モノレポ化 移行への大きな第一歩目は、2年前に遡ります。当時、第一歩として踏み切った「モノレポ化」については、過去のブログでも紹介されています。 dev.henry.jp この記事

株式会社ヘンリーでエンジニアをしている okbee です。 直近は製品のフルリニューアルを行なっており、詳細は省きますが、私もこの開発に参加しています。社内では「コスト連携」と呼ばれる機能の開発を主に担当していました。 「コスト連携」をざっくりと説明するならば、患者に対して医師が作成した指示（オーダー）を元にして、実際の金額を算出するためのワークフローです。詳細はコンテキストで紹介します。 さて、今回は「コスト連携」の実装を通して感じた反省を元に、より良い設計のヒントとして「コンパイルエラーを活用した手順不足の検知」を考えていきます。 コンテキスト コスト連携には臨床・会計の2つの大きなコンテキストが背景にあります。 患者に対して医師が作成する指示（以降はオーダーと表記）は臨床と呼ばれるコンテキストで作成されます。ちょうど、皆さんがクリニックなどで診察を受ける際に医師が薬を処方したり、注射

ヘンリーは今、何を作っていて、どのような開発をしているのか。VPoE 兼 VPoTの戸田 (id:eller) さんに、プロダクトの説明から、開発体制、技術スタック、開発手法や文化までお話を伺いました。ポッドキャスト番組、ヘンリー理想駆動ラジオのエピソードから書き起こしたものです。よろしければそちらもあわせてお聞き下さい。 本エントリでは、カタカナの「ヘンリー」は株式会社ヘンリーを表し、アルファベットの"Henry"はヘンリーが開発しているプロダクトを表します。 —— 自己紹介をお願いします 戸田: 戸田ケンゴといいます。元々高校生の頃にフリーソフトウェア開発をやっていて、そこから国産ERPパッケージ開発の会社に就職して、そこで様々なチームの経験をしてきました。 そこの会社ではオンプレの製品を作っていたんですけど、それだと保守に限界があるなということに直面しまして、次はオンラインのサービス

ヘンリーで SRE をやっている id:nabeop です。今回は SRE チームで実施しているパフォーマンス分析会という取り組みについて紹介します。 取り組みを導入した時に解決したかった課題感 パフォーマンス分析会の変遷 現在のパフォーマンス分析会の様子 パフォーマンス分析会をやっていて良かったこと Datadog の Database monitoring によってインデックス不足に気づけた EF ファイル生成の高速化を確認できた パフォーマンス分析会の今後 最後に 取り組みを導入した時に解決したかった課題感 パフォーマンス分析会は筆者がヘンリーに入社してからわりとすぐに始めた取り組みでした。 筆者が入社した当時は一人目 SRE として入社した id:eller が Henry の運用の基礎固めをしてくれていました1。Cloud Monitoring を監視基盤としてアラートの設定など

株式会社ヘンリーでSREをしている戸田（id:eller）です。ひとりめSREとしてヘンリーにジョインしてから約3年、現在ではSREも3人のチームになりました。それでも事業計画に対してはまだ足りていないので、SREエンジニア採用を継続的に行っています。 私がSREチームを作るのは前職から続けて2回目なのですが、いずれの場合でも重要だと考えていることがあり、カジュアル面談でもよく話しています。今回はそのエッセンスをまとめて、同業はもちろん弊社への転職を検討されている方にも参考にしていただければと思っています。 前提としての「チームの目的」 チームを作っていくためには、そのチームの目的や存在意義を明確にする必要があります。SREチームであれば、何のSite Reliabilityをなぜ、どのようにしたいかを明確にする必要があります。 そしてこれらを明確にするためには、事業やサービスについての理

株式会社ヘンリーでオブザーバビリティを担当しているsumirenです。 先日のHoneycombでスパンを削減する - 株式会社ヘンリー エンジニアブログ という記事で、スパン削減にはトレースカットとトレース横断の2つのアプローチがある話をしたうえで、トレース横断での削減について紹介しました。 この記事ではトレースカットでの削減についてヘンリーでの事例を紹介します。 スパン削減の戦略（再掲） 前の記事でも紹介したとおり、スパン削減には大きく2つの方向性があります。（アプリケーションを直す以外） トレースカットでのアプローチ トレースカットでサンプリングする 例：正常なトレースは1%だけサンプルする、無料ユーザーのトレースは1%だけサンプルするなど トレース横断的なアプローチ スパン種類ごとにドロップの条件をつける 例：SET TRANSACTIONのスパンは正常かつ高速ならドロップする こ

株式会社ヘンリーでオブザーバビリティを担当しているsumirenです。 ヘンリーではHoneycombのProプラン、15億スパンの契約をしています。 GraphQLのresolverなどあまりにスパン量が多いものは導入時に削りましたが、顧客数が増えたり新規機能が増えたことでQuotaを超えてしまうようになってきたため、既存スパンを分析したうえで削減を行いました。 トレース集計やHoneycomb素晴らしさを示すことにつながるため、主にスパンの分析についてシェアします。 スパン削減の戦略 スパン削減には大きく2つの方向性があります。（アプリケーションを直す以外） トレースカットでのアプローチ トレースカットでサンプリングする 例：正常なトレースは1%だけサンプルする、無料ユーザーのトレースは1%だけサンプルするなど トレース横断的なアプローチ スパン種類ごとにドロップの条件をつける 例：S

こんにちは。ヘンリーでエンジニアをしている agatan です。 私は現在医事会計チームに所属し、医療事務の皆様が使う会計システム（レセコン）としての側面について Henry の開発に携わっています。 日々開発をする中で、「デリバリーが3倍速ければいろんな問題が解決するのになー」と考えていることがよくあり、そのための障壁や打ち手を考えるために現状の開発の課題感を整理していました。 実はこれはヘンリーのソフトウェアエンジニアリングの向き合っている難しさ（とそこに挑戦する面白さ）の芯の一つなのではないかと思い、せっかくなので記事にしてみることにしました。 （弊社の行動指針に「ドオープン」（自身の考えを積極的に共有する）というものがあるのですが、同僚から「もっとこうするべきだという考え方を出していくのがリーダーシップですよ」とドオープンにフィードバックされました。この記事は、その通りだなと思って

株式会社ヘンリーでSREなどをしている戸田です。弊社では技術勉強会略してギベンを毎週開催しておりますが、このたび個人の方がネットで簡単にサービス販売できるプラットフォームを開発、提供していらっしゃるMOSH株式会社の皆さんと合同で技術勉強会を開催いたしました。MOSH株式会社様の公式Zennでも開催報告を上げていただきましたので、あわせてご覧ください： zenn.dev 弊社からは3名のITエンジニアが発表しておりますので、その内容を軽くご紹介いたします。 GitHubでTerraformできる！tfmigrate & tfactionのご紹介 両社の採用技術の共通点であるTerraformに着目して、筆者（id:eller）が弊社でtfmigrateとtfactionを導入するに至った経緯についてお話ししました。 図1 非公開資料より。tfmigrateとtfactionはとても便利です

こんにちは、アーキテクト室の岩永です。 ヘンリーでは去年からプロダクトのフルリニューアルを進めており、その一環としてフロントエンド開発に MobX を導入しました。 当初は複雑なUIの実装を整理するための View Model として限定的に使い始めましたが、その有用性から徐々に使用範囲を広げ、現在では新規開発のほぼ全てで MobX を活用しています。 本記事では、MobX の採用に至った経緯や、実際の運用を通じて得られた知見を共有します。 特に以下のポイントについて詳しく説明していきます。 MobX の特徴と基本的な使い方 フルリニューアルにおける MobX 採用の背景 段階的な導入プロセスと直面した課題 Domain Model への MobX の活用と今後の展望 フロントエンド開発における状態管理の選択に悩まれている方や、複雑なドメインのプロダクトを作っている方、大規模なリニューアル

株式会社ヘンリーでSREをしているsumirenです。 ヘンリーではオブザーバビリティバックエンドにHoneycombを採用しています。 Cloud Runでサービス間通信をしている場合、こうした外部オブザーバビリティバックエンドとOpenTelemetryを使うと、トレースが途切れてしまう課題があります。 解決してから1年弱経ってしまったのですが、対処事例を紹介します。 Cloud Run + OpenTelemetry + 外部バックエンドでトレースが途切れてしまう理由 途切れてしまう理由を解説するために図解を用意しました。ここでは2つのCloud Runアプリケーションがサービス間通信を行い、番号順に処理を行ってトレースを生成しています。便宜上各アプリケーションはスパンを1つしか生成しない形で図解していますが、スパン数が増えても問題の本質は変わりません。またトレースIDやスパンIDは

株式会社ヘンリーで電子カルテと外部機器・ソフトウェアの連携部分の開発を担当している坂口（id:wakwak3125）です。この記事は株式会社ヘンリー Advent Calendar 2024の14日目の記事です。前回は「大きくて複雑なものを作る人達へ送る一冊｜永田 健人」でした。 はじめに 電子カルテというものはたくさんの周辺分野の機器やソフトウェアと連携をして診療行為を記録していますがその中でも比較的身近な検査に焦点をあてて実際に裏側ではどのようなデータのやり取りが行われているのか、どういった課題があるのかについて解説してみようと思います。 ここでは院内や院外で実施される血液検査や尿検査などに代表される「検体検査」を対象とします。 検査システムと電子カルテの役割 まず検査システムと電子カルテのそれぞれの役割を簡単に解説します。 検査システム 血液検査や尿検査などの検体検査の結果の表示や患

id:Songmu です。この記事は株式会社ヘンリー Advent Calendar 2024 5日目の記事です。 ヘンリーは北海道から沖縄まで、何なら上海から働いている社員さえいるフルリモートの会社です。フルリモート環境においては特に、社員の相互理解、そのためのそれぞれの自己開示が大事です。リモートに限らず、一部の人の声が大きくなりすぎて多様性が損なわれないよう、メンバーに自己開示を促し、支援することも必要です。 ヘンリーではその促進のために、Notion上に自己紹介やユーザーマニュアル、社内ブログ等を書いてもらう取り組みをしています。それに加えて Henry FMという社内ラジオがあり、広報メンバーを中心とした有志のギルドで運営されています。社員へのインタビューや雑談の録音を元に、30分程度の音声コンテンツが週に2本程度更新されています。これもNotion上で社内公開されており、Not

VP of Engineeringの id:Songmu です。さて、ここ1年くらいプロダクト開発に直接携わっていないので、価値提供に直接繋がらなくなったような、なんとなくの不安感があります。これまでの職場では無理矢理でも何らかの形でプロダクト開発に携わっていたので初めての感覚です。 ただ、採用やエンジニアリング組織周りへのフォーカスは、私自身が望んでいることです。自分が過去所属した組織でやりきれなかったことに対するリベンジであり、ありがたいことに、VPoEとして組織開発の当事者としてそれらの課題に主体的に関わるチャンスを与えられているということです。そのあたりの話は、去年末のエントリにも書きました。 それに、あまり表に出してきませんでしたが、私はなんだかんだ、ここ10年くらいマネジメントだったりエンジニア採用に取り組んできたので、そこに関する発信などもしたいとも思うようになっています。

こんにちは！ヘンリーでソフトウェアエンジニアをしている @agatan です。 今日は小ネタで、サーバーサイド Java / Kotlin エコシステムで意外と使われている ThreadLocal と、それを Coroutine と安全に組み合わせる方法について紹介します！ TL; DR ThreadContextElementを使おう！ ThreadLocal とは java.lang.ThreadLocal<T> は、その名の通り、スレッドローカルな（= スレッドごとに独立した値を持つ）変数を定義するための機構です。 ある Thread で値を書き換えたとしても、他の Thread から見た ThreadLocal 変数の中身は書き換わらない、という性質があります。 import kotlin.concurrent.thread val tls: ThreadLocal<Int> =

株式会社ヘンリーで SRE をやっている id:nabeop です。 みなさん、キーボードを使っていますか?エンジニアに限らず、毎日触っているガジェットで一番使っているガジェットは何か?という問いをすると、かなりの割合でキーボードが上がると思います。実際にヘンリーの Slack ワークスペースにはキーボードに関する話題を扱う #zzz-social-keyboard というチャンネルがあり、おすすめのキーボードの相談から、気になるキーボードやキースイッチの紹介などで賑わっています。 そんな中で M3 さんのテックブログで突撃！ 隣のキーボード M3 2024 - エムスリーテックブログというエントリが公開され、#zzz-social-keyboard でも話題になりました。で、#zzz-social-keyboard の参加者もキーボードには負けないくらいのこだわりがあるので、アンケートを

sumirenです。 ヘンリーではオブザーバビリティに投資をし、開発生産性と品質を高める取り組みをしています。 この記事では、ヘンリーが考えるオブザーバビリティ成熟度を解説し、最後にヘンリーの現状と今後について解説します。 オブザーバビリティ成熟度 全体像 筆者は、オブザーバビリティの成熟度について、以下のように考えています。 これはあくまで一般的な概念ではなく、筆者が説明のために考えた便宜上のモデルになります。 なにもない インフラメトリック アプリケーションログ 非構造化ログ 構造化ログ リクエストに紐づくログ アプリケーションメトリック（ログベース） トレース トレース単体 システム固有の共通的な計装 ドメイン/機能カットの計装 トレースの分析と集計 トレースの相関分析 オブザーバビリティ成熟度が低い状態〜中程度の状態 1. なにもない〜 2. インフラメトリック なにもない状態は、

LEADING QUALITYの輪読会後の雑談中様子 株式会社ヘンリーCEOの逆瀬川です。 4月から製品企画の責任者として開発ロードマップや要件開発を行っています。 特に今後、電子カルテを開発するチームでは人数も増え、これから大きな機能開発も増えていくため、これまで以上に品質向上への取り組みを強化しています。 具体的には、品質と信頼性を上げるための施策会議（品質と信頼性の会）や、不具合分析の定例会を開始しました。 本日は、品質と信頼性の会で出てきた施策のひとつである探索的テストを学び、早速実行したところ、大きな効果が出たので共有します。 弊社の品質の守護神 Aさん依存体質からの脱却！！ 探索的テストに取り組むことになった背景としては、QAのAさんへの依存です。 元々医療事務出身のAさんがQAやテストを学び、チームの全てのテストを担っていました。ドメインエキスパートでもある彼女はスクリプトテ

VP of Engineeringの id:Songmu です。冒頭に、大事なお知らせですが、今週土曜日(6/22)に開催される、Kotlin Fest 2024にヘンリーはスポンサーをしています。スポンサーブースも出展しますので、是非お立ち寄りください。私もいます。 また、Henryの開発者の一人でもあり「Kotlin サーバーサイドプラグラミング実践開発」の著者でもある、 @n_takehata が、2024年版 Kotlin サーバーサイドプログラミング実践開発というタイトルで登壇します。是非こちらも聞きに来てください。 ヘンリーも社員数が増えてきたこともあり、このスポンサーを機に、イベントやコミュニティ参加に関する制度づくりを始めました。また、それらに参加する社員も増えて欲しいと思っています。そのために、改めて、社員がイベントやコミュニティに参加する意義を考え直して整理した内容が本

株式会社ヘンリーでSREなどをやってる戸田（id:eller）です。最近の仕事のテーマはリスクコミュニケーションとサイト信頼性です。 弊社のビルドとデプロイは長らくCircle CIを使ってきました。一方でGitHub Actionsも強力なRunnerを使うハードルが下がったり、Circle CIのcontextsよりも使いやすいvariablesやsecretsの管理ができるようになってきたりしています。特にNodeJS開発界隈はGitHub ActionsがメジャーなCI/CD環境になってきている感触もあります。 今回は既存デプロイパイプライン整理のため、NextJSプロジェクトのデプロイパイプラインをGitHub Actionsで組み直しました。要点をご紹介いたしますので、どなたかの参考になれば幸いです。 要件 ビルドとデプロイを分離すること。コンテナイメージとアセットをビルドのタ

ヘンリーで SRE をやっている id:nabeop です。最近の仕事のテーマはサービスの可観測性の向上と信頼性の計測です。 最近では可観測性の文脈では OpenTelemetry が話題に上がると思いますが、ヘンリーでも OpenTelemetry を導入してテレメトリデータを収集して、各種バックエンドに転送しています。分散トレース周りの話題については、以下のエントリがあります。 ヘンリーではマイクロサービスからのテレメトリデータは Cloud Run で構築した OpenTelemetry Collector で集約し、otelcol のパイプライン中で必要な処理を実施し、バックエンドに転送するアプローチを採用しています。 OpenTelemetry Collector でテレメトリデータを収集している様子 現在は監視基盤の移行期なので、メトリクスが Google Cloud と Da