はてなブックマーク

株式会社ヘンリーでVP of Technologyをしております、戸田（id:eller）です。 2026年7月10日に成立した改正個人情報保護法では「統計作成等」にのみ利用される場合について、本人の同意なしに個人データを第三者へ提供できる特例が盛り込まれました。一定のAI開発についても、この特例の対象になり得るとされています。 改正法は7月17日に公布され、原則として公布から2年以内に施行される予定です。具体的な対象範囲や公表事項などは、今後、個人情報保護委員会規則やガイドラインで定められます。したがって、本稿執筆時点では、まだこの特例を利用してデータ提供を開始できる段階ではありません。 この改正は、医療情報システムをSaaSとして提供する弊社のような事業者にとっても、患者本人の同意なしに患者データから統計情報やAIモデルを作成し、利用できるようになるということなのでしょうか？ 結論から

株式会社ヘンリーでソフトウェアエンジニアをしているwarabi(@warabi1062)です。 ヘンリーでは今年の1月から、一部のPull RequestでAIがレビューをする際にApproveを出す権限も与えています。 今回はAIにApproveを出させるようにした経緯や、約半年間の運用をしてみてどのような効果があったかをまとめます。 AI活用による実装速度の向上 今年の1月頃から、ヘンリーではClaudeCodeをより効果的に活用して実装の全自動化に力を入れてきました。その成果の一部として、IssueのIDを渡すだけで設計、実装、PR作成までをClaudeCodeが自動で行ってくれるSkillの作成などが挙げられます。 Claude Codeで開発を全自動化する - Orchestrator型Skillの設計と実践 - 株式会社ヘンリー エンジニアブログ このような成果から1月を転換点

こんにちは、ヘンリーの山口です。2026年4月にVPoEに就任しました。 年末にVPoEの打診を受けてから就任までの数ヶ月、「VPoEとして自分は何をやる人なのか」を探していました。一般的にイメージされるVPoEの仕事と、自分が実際にやり始めた仕事がどうにも噛み合わなかったからです。ようやく自分なりの答えに辿り着いたので、その結論とそこに至るまでの考え方を書き残しておきます。 違和感：一般的なVPoE像と、私が始めていた仕事 VPoEと聞いて多くの人が想像するのは、たぶんこういう仕事です。 エンジニアの採用戦略を立てる エンジニアのキャリア開発や評価制度を設計する 技術的な方針を決める 開発チームの生産性を上げる エンジニアリング組織全体を率いる 一方で、打診を受けた後、私が実際に始めていたのはこういう仕事でした。 製品本部の横断チームが、それぞれ「やること・やらないこと」を定義できるよう

株式会社ヘンリーでソフトウェアエンジニアをしているwarabiです。 今回はClaude Code Skillを社内に展開する際に選択したClaude Code Marketplaceの導入と、SkillのPlugin化による副次的な恩恵についてお話しします。 背景 ヘンリーの業務でClaudeCodeを今よりもっと活用するために、開発業務を全自動で行うOrchestrator型Skillの作成と、Skillのチーム展開に関する課題整理をこれまで行ってきました。 それぞれ詳細は以下のブログにまとめてあります。 Claude Codeで開発を全自動化する - Orchestrator型Skillの設計と実践 Claude Code Skillsのチーム展開で気づいたSkill管理の課題と対策 チーム展開の課題を整理した結果、チームSkill展開について以下の方針を取りました。 個人Skill

はじめに 株式会社ヘンリーでソフトウェアエンジニアをしているUGAです。 ヘンリーでは電子カルテ・レセコン一体型のクラウドサービス「Henry」を開発しています。 医療ドメインのプロダクト開発では、コードの複雑さだけでなく、その背景にある医療ドメイン知識の複雑さが大きな壁になります。 この記事では、Claude Codeを使ってコードベースから体系的な技術ドキュメント「解体新書」を自動生成するClaudeCodePluginを開発した話を紹介します。単なるドキュメント自動化の話ではなく、ドメインエキスパートAIをチームで育てるというビジョンに基づいた取り組みです。 きっかけ ヘンリーの開発では、ドメインが複雑であるが故に、日常的にSlackで他のメンバーに質問のメンションを飛ばし、返事を待ち、回答をもらってようやく作業に取りかかるというやり取りが少なくありませんでした。これは聞かれる側も自

株式会社ヘンリーでソフトウェアエンジニアをしているwarabiです。 ヘンリーでは以前から開発にClaude Codeを用いていましたが、最近はSkillの活用などでClaude Codeの性能をもっと引き出そうとする動きが活発になっており、ブログでの発信も増えてきています。 Claude Code を活用した電子カルテの外部連携仕様書メンテナンス自動化の取り組み - 株式会社ヘンリー エンジニアブログ 今回は私が以前に作成したSkillをチームの共有物として管理・展開する際に気付いたSkill管理の課題と対策について話そうと思います。 以前作ったSkillの紹介 起票されたIssueの中身を確認・追加調査をしたうえで実装からPR作成までを全自動で行うOrchestrator型のSkillです。（以降 dev Skillと表現） dev.henry.jp このdev Skill作成は元々チ

この記事では、Claude CodeのSkill(Agent Skill)やCIを活用して、コードベースから外部連携の仕様書を自動生成・更新する仕組みを構築した取り組みを紹介します。 はじめに こんにちは！ヘンリーで電子カルテ開発チームでエンジニアをしているわくわく(@wakwak3125 / @wakwakjp) です。 最近社内でのAI活用が進んでいており、 https://dev.henry.jp/entry/claude-code-orchestrator のような便利なSkillのおかげで開発自体の速度がぐんぐん上がっています。 一方で、まだまだ人の手で行われている部分が多いのも事実です。今回はその人力で行われていて、抜け漏れのチェックが非常にめんどくさい「仕様書」と呼ばれるもののメンテナンスを Claude Code, Skill, GitHub Actions を使い半自動化

株式会社ヘンリーでソフトウェアエンジニアをしているwarabiです。 ヘンリーは医療業界向けのプロダクトを開発しており、開発メンバーにも難解なドメイン知識が求められます。そのため普段からドメインの理解や深堀りに時間をかけたいところですが、実際は開発業務も進めなければならないため、時間の使い方に悩んでいました。 この課題に向き合うために、普段開発で使っているClaude Code（Anthropic社が提供するCLIベースのAIコーディングアシスタント）をもっとうまく活用し、実装にかける時間を減らして学習に充てる時間を増やせないかと考えました。 それまでのClaudeCodeの使い方と課題 それまでの私のClaude Codeの使い方は、一言で表すとAIとのペアプロです。 AIによるコードの変更をリアルタイムに確認しながらその場で質問もできるため、設計やサービスの理解には役立ちます。 ただ、

株式会社ヘンリーでVPoEを務めている戸田（id:eller）と申します。これはHenryアドベントカレンダー 2025 シリーズ 1における6日目の投稿です。昨日の記事は kobayang の デザインシステムライブラリを実装するためのテクニック でした。 本日は弊社で経営と執行を分離するためにどう権限委譲を進めてきたかをご紹介したいと思います。スタートアップのVPoEって何をやってるんだろう、という疑問にお答えできれば幸いです。 目次 目次 解きたい課題 何がブロッカーだったのか 課題を解く10ヶ月 1月: 方針の明確化と障害の分析を行い、戦略を立てる 3月: 医事チームを分割して権限委譲できる大きさにする 7月: 電子カルテチームを分割して権限委譲できる大きさにする 9月: 逆瀬川の部長兼務が終了する 11月: 縣が製品部門代表としてお客様にご挨拶をする 振り返って、VPoEは何をし

こんにちは、ヘンリー開発者のタケハタです。 普段はエンジニアとしてプロダクトの開発をしつつ、技術広報ギルドという有志の横断組織で、技術広報の活動をしています。 本記事は株式会社ヘンリー Advent Calendar 2025 3日目の記事になります。 昨日はSREの(id:nabeop / @nabeo)によるなぜ AWS 移設をするのかでした。 目次 技術広報の成果は見えづらいとよく言われる 効果として期待できるもの 認知の獲得 コネクションの形成 ブランド力の向上 社内のエンジニアのモチベーションとスキル向上 施策ごとの効果 技術ブログ イベントへのスポンサード、ブース出展 自社イベント開催 ヘンリーで2025年にやってきた施策と成果 やってきた施策 ヘンリーで得られた効果 前提として、施策1つで直接的な効果は出にくい コスパってどうなの？ 他の採用やPRをした時の比較をした時 その

ヘンリーで SRE をやっている id:nabeop です。 これは株式会社ヘンリー Advent Calendar 2025 (シーズン1) の2日目の記事です。昨日は VPoP (VP of Product) の縣 (id:agtn / @agatan) による事業戦略は技術戦略に影響を与えるが、技術戦略もまた事業戦略に影響を与えるべきでした。 今年の SRE チームの大きなトピックとしてクラウド基盤を Google Cloud から AWS に移設するプロジェクトが進んでいます。プロジェクト自体は去年から始まっており、粛々と進めていたのですが、ある程度の目処が立ってきたので今年の10月に外部向けにもプロジェクトの存在を公開しました。 カジュアル面談やイベントなどで AWS 移設について言及することがあったのですが、一番質問されたのは「なぜ、クラウド基盤の移設をするのか?」という内容で

こんにちは。ヘンリーで 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 の活用と今後の展望 フロントエンド開発における状態管理の選択に悩まれている方や、複雑なドメインのプロダクトを作っている方、大規模なリニューアル