2026-06-26

AIにPull RequestのApprove権限を与えて数ヶ月、どのような効果があったか

株式会社ヘンリーでソフトウェアエンジニアをしているwarabiです。

ヘンリーでは今年の1月から、一部のPull RequestでAIがレビューをする際にApproveを出す権限も与えています。

今回はAIにApproveを出させるようにした経緯や、約半年間の運用をしてみてどのような効果があったかをまとめます。

AI活用による実装速度の向上

今年の1月頃から、ヘンリーではClaudeCodeをより効果的に活用して実装の全自動化に力を入れてきました。その成果の一部として、IssueのIDを渡すだけで設計、実装、PR作成までをClaudeCodeが自動で行ってくれるSkillの作成などが挙げられます。

Claude Codeで開発を全自動化する - Orchestrator型Skillの設計と実践 - 株式会社ヘンリーエンジニアブログ

このような成果から1月を転換点として実装の作業は早くなりましたが、その結果としてレビュー対象であるPull Requestの数も増え、レビューコストが高くなるという課題が早々に見えてきました。

レビューコストはAI活用が進むほどに大きな問題となることは目に見えて分かっていたため、早めに解決する必要があると考えました。

Approve自動化

レビューコスト増加の対策として、今回はAIがPull RequestをレビューしてApproveも出す環境を目指しました。

ヘンリーではSkill活用による実装の自動化以前から、CursorやClaudeCodeによるPull Requestレビュー自体は行っていました。ただしこれはレビューコメントを投稿するのみで、Pull Request自体にApproveまでは出さない状態です。コードの品質が高くてもコメントで「Approveです！」と投稿するまでの動きになります。

そこでこのAIレビューのワークフローを調整。Pull RequestにAutoApprovalというラベルを付けていた場合、AIのレビュー結果を元に追加でApproveを出すようにしました。

全てのPull RequestでApprove権限を与えるのではなくラベルを付ける運用にした理由は、人間によるレビューを必須にする余地を残すためです。

このAutoApprovalはバグ修正や簡単な機能追加など、実装難度が低いPull Requestで使う想定のものです。

テーブル定義更新のような破壊的変更を伴うPull Requestや、複雑な実装を伴うPull Requestはラベルを付けずに引き続き人間のレビューを必須とできるようにしています。

どのPull Requestにラベルを付けるかの判断は、Pull Requestの作者に委ねる方針にしています。

組織への展開と性善説運用

AIによるApproveの仕組み自体は整いましたが、これを組織全体にすぐ展開することは危険です。この仕組みを利用する人は、生成コードやレビューについてAIに責任は無くあくまで人間に責任があることを理解しなければなりません。

そこで組織にAutoApprovalを展開するにあたり、AIにApproveさせるとはどういうことかを合わせてNotionに整理して伝えることとしました。

ドキュメントでは以下の2点を理解してもらうことを特に重視しました。

AIのレビューは完璧ではない
AIに責任は無い。最終的なコードの責任が人間にあることは今までと変わらない

ドキュメントを見てもらうことで、マージするコードの責任をあくまで人間（個人やチーム）にあることは変わらないことを了承してもらい、それを利用するかはあくまで各自に任せる性善説運用。導入のハードル自体は上げずに安全に活用してもらうため、このような手順を踏むようにしました。

AutoApproval導入後の状況

AutoApprovalを展開し簡単なPRはAIによってレビューを済ませることで、レビューを遅らせることなく実装のスピードとの両立が行えるようになりました。

AI活用による影響を確認するため、ヘンリーの主要リポジトリについて約半年間のPull Requestのデータを抽出してみます。

全体のPull Request作成数としては、1月のターニングポイント以前と以降を比較すると約2倍の数値となっています。

またAutoApprovalラベル有りとラベル無しのPRの数も比較してみました。

AutoApprovalは導入後から広く活用されるようになりましたが、意外だったことはラベル無し（ = 人間のレビューが必須）のPull Requestが約50%あり想像よりも多かった点です。

AutoApprovalの利用についてバックエンド・フロントエンドそれぞれの割合も見てみました。

フロントエンドでは約70%のPull RequestでAutoApprovalが、バックエンドでは約40%のPull RequestでAutoApprovalが使われている状況でした。この差はバックエンドについてはテーブル定義などもあり、破壊的変更が起きやすいためより慎重なレビューが求められるためと考えられます。

これらの数値から、すべてのPull RequestでAutoApprovalが使われるような乱暴な利用状況にはなっていなく、人間が見るべきPull Requestは引き続き人間が見るよう線引きが行われていることが読み取れます。

ヒヤリハットと安全策

事前に予想できていたことではありますが、AutoApprovalによる影響は良い側面だけではありません。AutoApprovalを使った安易なマージを要因としたヒヤリハットは一定発生しうる問題でした。

このような問題は発覚後に都度対応を検討し、これまで以下のような改善を積み重ねてきました。

mainなどリリースに影響するブランチへのPull RequestではAutoApprovalを使えなくする
サイレントにPull Requestが作成・即マージされることがないよう、メンバーがPullRequestの存在には気付けるよう通知周りの整備をする。
linter など各種設定ファイルの見直し

AutoApprovalの展開後もブラッシュアップを続け、より使い勝手の良い安全な環境を目指そうと取り組んでいます。

AIレビューの品質について

またヒヤリハット以外にもレビュー品質についても課題が残っています。 AIによるレビューの品質は利用するAIモデルの性能やプロンプトに左右されやすく、現状だと複雑な指摘に関してはまだ人間によるレビューに軍配が上がる印象があります。

テストの不足や、潜在的な問題を含んでいるコードをAIが緩い判定でApproveする点は未だ解決しきれていない課題の1つです。

この課題に関してはレビュー用プロンプトやClaude.mdの整備などの改善も行っていますが、モデル選択による影響が大きいとも感じています。Pull Requestの規模や領域に応じてモデルを切り替えるような仕組みの検討も今後行いたいと考えています。

まとめ

今回はAI活用によるPull Request数増加にともなうレビューコスト増加の対策として、AIによる自動Approveの取り組みを行い、実装スピードとレビューコストの両立を目指しました。

ヒヤリハットやレビュー品質といった課題がいくつか残っていますが、AIにより働き方自体が大きく変わっていく流れに適応するべく今回の仕組みを導入することは必要な流れでした。

AI活用によって生じた新しい問題をさらにAIによって解決する。この繰り返しによって働き方を引き続きアップデートしていこうと思います。

2026-06-23

電子カルテ開発チームの中を紹介

4月に入社したEMR（電子カルテ）部エンジニアのこん(k0n_karin)です。

この記事では、私が所属するEMR部のRチーム（仮名）の開発の様子を紹介します。入社してから約3ヶ月で感じたチームの動き方や雰囲気、ヘンリーならではのポイントを紹介します。

チーム紹介

Rチームは、PdM1人・エンジニア4人・デザイナー1人・QA2人という構成です。特徴的なのがメンバーのバックグラウンドで、QAの2人はどちらも元医療従事者で、それぞれ医療事務と看護師の経験を持っています。さらにPdMは社内の導入部の出身です。導入部は、病院にHenryを導入する前の説明・調整をしたり、運用フローを整備するチームで、いわゆるカスタマーサクセスに近い立場です。医療の現場を知っている人がこれだけ近くにいるのは、あとで書くようにとても心強い存在です。

チームは自分の入社と同じ4月に発足したので、自分としてはちょうどいいタイミングでスタートを切ることができました。

キックオフからスプリントサイクルが回り始めるまで

4月の全社開発キックオフからチームが動き出しました。ありがたいことに先行してPdMがユーザー要求を整理してくれていたので、自分たちはその要求をもとにみんなでイベントストーミングをして、業務プロセスやフローを考えるところからスタートしました。

イベントストーミングについてはこちらの記事がわかりやすいです。

zenn.dev

医療の現場は連携するシステムも多いので、「どこまでをHenryでやって、どこからは連携先のシステムに任せるのか」という線引きや、「どんなイベントが発生するのか」をチーム全員で洗い出し、共通理解を作っていきます。

これと並行して、整理した要求をもとにしたユーザーストーリーをClaudeに食わせて、全部Linearというチケット管理ツールでチケットに起こしていました。こういった作業もClaudeのSkills化されていたので再現性があり、他のチームにも展開しやすい形になっていました。

linear.app

ここからは、プランニング、デイリースクラム、リファインメント、レビュー、レトロなどのスプリントサイクルが回り始めます。大枠は一般的なスクラムイベントと同じなので、ここからはヘンリーならではの工夫や、やってみて感じたことを中心に紹介していきます。

デイリースクラム

デイリースクラムでは進捗の確認に加えて、前日に行われた意思決定の確認もしていました。開発を進めていると、毎日いろんなところで大小さまざまな意思決定が発生します。そのためLinearで「意思決定チケット」を切って運用していました。更新されたものや確定したものをみんなで確認でき、何より後から状態や決定に至った過程を振り返れるのが大きいです。「あれ、これってどうなったんだっけ？」と思ったときも、Linearを見たりLinearのAIに聞いたりすれば大体解決するので、かなり良かったです。

あるサイクルで更新された意思決定チケットたち。画面上部には、意思決定以外にも色んなビューがある。

デイリーリファインメント

デイリーリファインメントでは、エンジニアでプランニングポーカーをしたり、ユーザーストーリーの整理や仕様確認をしています。正直に言うと、最初は「毎日リファインメントか〜」と思っていましたが、毎日話していても認識や理解のズレが生まれていることがあり、各スクラムイベントやSlackでも頻繁にコミュニケーションが行われ、そこで認識が揃ったり疑問が解消されることも多かったです。誰かの質問を聞いて「あ、自分も分かってなかったかも」と気づくこともあれば、その逆もあったので、コミュニケーションの回数の重要性を再認識しました。

スプリント中の開発

入社前後の大きな変化として、手でコードを書くことがほとんどなくなりました。実装はほぼすべてClaude CodeやCodexなどを使って実装します。これは別ブログで紹介しているdevワークフローのおかげが非常に大きいです。ちなみにヘンリーのエンジニアは全員がClaude Teamプランのプレミアムシート（$100）を利用でき、希望者はChatGPT ProでCodexも使えます。

dev.henry.jp

開発スピードはとにかく速くて、手で書いているとついていけないくらい速いです（もちろん周囲のサポートはちゃんとあります）。入社当初はこの速さにとても驚いて、いい意味でギャップを感じました。大体のものはAIに引き渡せる形になっていて、みんながそうしようとしている環境だなと思います。

参考までにPRの件数を紹介すると（PR件数だけで測ってはいけないが）、入社後3ヶ月だけで50件ほどのPRをマージできました。オンボード期間中でもこれだけのPRをマージできたのは、今まででは考えられないスピードでした。チームメンバーには同じ期間で100件を超える人もいるくらいのスピード感なので、気づくとdevelopブランチからかなり離れてしまっていることもあります。これは前述のdevワークフローに加え、AutoApproveの運用（これも別途ブログになる予定です）とフィーチャーフラグのおかげもあり、ガンガンdevelopにマージして、ステージングには即デプロイされる体制になっています。本番デプロイは運用や病院様の都合もあって週1回ですが、緊急度が高いときはhotfixで本番デプロイも何度か行われていました。

レビュー・現地ヒアリング

レビューでは、チームに加えて社内の医療システムエキスパート（≒ドメインエキスパート）や元医療従事者にも入ってもらって、成果物のデモを見ていただきます。さらに月1回くらいのペースで病院様にもレビューに入っていただき、実際に触った感触のフィードバックをいただいていました。自分たちが作っているものが本当に現場で使えるのかを、早い段階から専門家の目で確認してもらえるのは非常にありがたかったです。医療従事者と開発者では全く目線が違うことも体感できました。

レビューに加え、チームで病院訪問してヒアリングする機会もありました。現場に行くと開発だけでは得られない現場の空気感や、現場で働いている方々の実態を深く知ることができ、机上の議論だけで拾いきれない運用課題や要求の解像度を上げることができました。実際に足を運んでヒアリングすると、想定と違うことや現場の方々の背景を知ることができ、一次情報に触れる重要さを再認識できました。

レトロスペクティブ・振り返り

レトロスペクティブでは、スプリントで起きた出来事のサマリーやスプリント内の感謝や良かった点・改善点をPCSS（Praise, Continue, Start, Stop）などで振り返っていました。

サマリーには、開発での重要な意思決定から完成した機能のデモ動画、Slack上の珍事件まで何でも書くので、みんなでワイワイ振り返りをしていました。

PCSSでは、みんなで付箋を書いた後に、特に議論したい付箋に投票して追加で議論をしていました。このおかげで、何かが形骸化し始めたり改善点があったときも、「これ意味薄くなってない？」「こっちのほうがよくない？」がカジュアルに出てきてネクストアクションにつながるので、プロセスが自然と良くなっていくのも感じられました。とても自律的なチームだと思います。

また、失敗が咎められないというのも印象的でした。言葉としてはもちろんですが、空気感としても「ナイストライ！」という雰囲気が強くチャレンジしやすく、フィードバックももらいやすいと感じました。サイクル中に自分の勘違いでスプリントゴールが達成できなかったときも、責められるのではなく、「失敗の原因は何で、次からは“みんな”でそれをどうカバーできるか」を前向きに考える、という流れだったので、「次のスプリントから意識して頑張ろう！」と思えるような空気感でした。

たのしいレトロの様子。毎週の振り返りで、たくさんの付箋が貼られ、みんなで称賛し合ったり改善したりしています。

ちょうど先日、この3ヶ月間のチーム振り返りワークショップも行いました。この振り返りでは毎週のレトロスペクティブを元に、3ヶ月間で起きたイベントと、その時に感じたポジティブ・ネガティブなことを書き出して3ヶ月を振り返りました。レトロと同様に書き出したイベントでみんなで議論したいものに投票して、追加で議論をして次の開発につながるネクストアクションを決めています。

そしてワークショップの最後に、メンバー同士でそのメンバーの強みや良かった行動をフィードバックするバッヂ（〜〜〜という行動が良かったで賞みたいなもの）を送り合いました。送るときにはみんなの前でひとりひとりが真心こめた一言ともにバッヂを送るので、気恥ずかしいですがとても嬉しかったです。同時に、チームから見た自分の良さや行動特性がわかるので、自分の良さでチームに貢献しよう！と思えました。

たのしいバッヂ授与式の様子。みんなから称賛されたりいろいろな観点で褒められるので、とても嬉しかったです。

チームで開発してみてのその他の感想

最後に、改めてこのチームで開発してみて感じたことを書いておきます。

まず、さきほども少し触れましたが、元医療従事者がチームや社内にいるのが本当に心強いです。「病院だとどうやってましたか？」「これってどう思います？」が気軽に聞けるのが最高でした。もちろん業務や運用は病院によって千差万別な部分もありますが、逆に変わらない部分も多いので、こうした生の声はとても参考になります。

そして、コミュニケーションがとにかくしっかりしていると感じました。SlackやMeetでは質問や意見がよく飛び交っていて、フルリモートだからこそみんなが意識的に発信している印象です。最近はスクラムイベントとは別に、素人質問OKな会や実際に画面を操作しながら疑問解消会などを定期的に開催し、質問の敷居を下げる取り組みも行っています。一方で、話すことが多い分、議論がなかなか進まないこともそこそこあるので、時間管理や同期・非同期の切り分けは、引き続きみんなで頑張っているポイントだったりします。

おわりに

医療という難しいドメインに対して、活発なコミュニケーションと、AIによる高速な開発、そして挑戦しやすい雰囲気で向き合っているのが自分たちのチームの良さだなと感じています。この記事を通して、ヘンリーに少しでも興味を持っていただけたら何よりです！
本記事では公開できない・書ききれない内容もたくさんあるので、興味を持っていただいた方はぜひカジュアル面談でお話しましょう！

jobs.henry.jp

2026-04-30

「医療 × SRE」、両方初心者の私から見たヘンリーとは

SRE

2026年4月1日からヘンリーに入社しました galoitsu です！

SRE（Site Reliability Engineer）として入社して約1か月が経過し、少しずつ業務にも慣れてきたので入社エントリーを書いていきたいと思います。

これまでの経歴

私は新卒で公共分野に強みを持つSIerに入社し、システムエンジニアとして7年間勤務しました。

もともと

社会貢献度が高い仕事をしたい
IT系の仕事がしたい

という2つの大きな思いがあったため、それらの掛け合わせで会社を決めました。

より社会貢献を身近に感じられる地元の市役所という選択肢も検討していましたが、今となっては「IT系の仕事がしたい」という思いもちゃんと取り入れておいてよかったとしみじみ思っています。

その会社では官公庁、地方自治体、医療などの公共分野のお仕事をするのか...と思いきや、7年間まるまる法人向けにお仕事をしていました。正直当初は「公共系やりたかったのに公共系じゃないんかい！」と思ったものの、これもまた今となっては

モダンな技術に触れる機会が多かった
フルリモートなど柔軟な働き方をさせてもらえた
そこで出会えたお客様やチームメンバーが素敵な方ばかりだった

ということから、結果的には私を成長させてくれる機会でしたし、非常に楽しく働かせてもらえたので（当時の上長の）正しい選択だったと思っています。この場をお借りして感謝！

転職のきっかけ

さて、前職の話ばかりしてもしょうがないので、なぜ転職することにしたのかを書きます。

きっかけは色々ありますが、大きなものは以下の2つです。

社会貢献度が高い仕事への情熱が再燃した
もっとエンドユーザーと近い場所で仕事をしたくなった

それぞれ軽く説明していきます。

社会貢献度が高い仕事への情熱が再燃した

新卒の就活のときからの「社会貢献度が高い仕事をしたい」という思いは、ずっと「まあ将来的にはいずれやりたいかなあ...」くらいの弱火で心の端っこにありましたが、再燃した一番の理由は家族の入院・手術の経験です。家族の持病で大学病院にお世話になった経験から、「医療に対してなにか恩返ししたい」という思いと、「おれが日本の医療を変えてやるぜ！」という使命を感じるようになりました。

「社会貢献度が高い仕事」として、特に次世代が幸福になるために大きな意味を持つ医療・教育・育児の3分野に携わりたいと思っていましたが、その中でもとりわけ医療分野のウェイトが高くなったのもこの経験によるものが大きいです。

もっとエンドユーザーと近い場所で仕事をしたくなった

これは前職で客先常駐という形態で業務していたことに起因すると思いますが、ものづくりをする人間として、自分が携わったプロダクトで喜んでいる人を見たい/感じたいと思うようになっていきました。

そして、その人たちからフィードバックを受け、またプロダクトを改善していく。そのサイクルによって、プロダクトを使う人たちと一体となってより良いプロダクトをつくり、より良い未来を目指したいと考えるようになりました。

入社の決め手

ありきたりですが、面談/面接、ヘンリー主催のイベントでお会いした方々がみんな素晴らしい人たちだったことです。

職種としてはSRE（Site Reliability Engineer）に挑戦したいと思っていたため、「医療 × エンドユーザーと近い × SRE」という3軸で会社探しをしていました。ヘンリーはその3軸にぴったりマッチしていたため、応募段階から第一志望ではありました。

最も大きな決め手となったのは最終面接で経営層とお話したときに「縁があってヘンリーに入社したとしたらどんな成長をしたいか」という質問をされたことです。

一般に、就職活動において「御社を自身の成長の場としたい」ということは~~思っていたとしても~~言わないほうが望ましいとされています。当然会社側からしてみれば「うちはあなたの成長のための場ではありませんよ」ということでしょう。まあそれはそうですよね。

ただ、ヘンリーの経営層の方はこちらの回答に対して「そういう成長をしたいなら、ヘンリーはこういうことをしているから、そこでこんな挑戦をしてみるといいかもしれませんね」という回答をしてくださり、ヘンリーで働くイメージが鮮明になったと同時に、ヘンリーで働きたいという思いがより一層強くなりました。

入社してみて...

一番強く感じることは、入社前後でほとんどギャップがないことです。

ヘンリーの行動指針と心得を体現しているメンバーが多く、会社説明資料や面談/面接を担当してくださった方々の人柄から感じ取っていた会社のイメージとほとんど変わりませんでした。部署問わずメンバー全員が社会課題の解決に前向きで、そのためにワンチームで突き進む姿がありました。

唯一ギャップを感じた（というか私の事前の理解が追いついていなかった）のは、生成AIの活用が想像よりもはるかに進んでいたことです。

エンジニアなど開発側のメンバーが生成AIを活用して爆速アウトプットしているのはある程度想像できていたものの、ヘンリーではビジネス側のメンバーも生成AIを積極的に活用しており、Notion AIやGemini、Claudeなど多様な生成AIの強み/弱みを見極めて使い分けています。私が所属するSREチームでも生成AIの活用を推し進めているところです！

これから

ヘンリー、および電子カルテHenryは成長の真っ只中です。他社の電子カルテと比較してまだまだ伸びしろがあります。これからどんどん多くの病院様にHenryを導入いただくためには、どんどん機能を開発していく必要があります！

一方で、機能の開発には障害がつきものです。その発生をいかに減らすか、いかに早く復旧するか、そして同じようなことをいかに発生させないか。これらに責任を持つのがSREです。ただ導入するだけでなく、病院様がHenryを安心して使用していただけるように、SREとしてHenryの信頼性に貢献していきたいと考えています！

そのために、まずは地盤となる運用への理解を深めつつ、信頼性を上げるための改善を少しずつ積み重ねていきます。

おわりに

ヘンリーではSREを募集しています！

医療という、信頼性の低下が患者様の生命に関わりうるような領域で信頼性を担保するというのはやはり難易度が高いです。また、今後はより大きな病院様や急性期病院様などへの導入も目指しているため、国の制度変更やガイドラインなどへの対応も必要になってきており、さらに難易度は上がっていきます。

そんな難しい領域に、やりがいと誇りを持って共に立ち向かう仲間を求めています！！興味を持っていただいた方はぜひカジュアル面談でお話しましょう！

jobs.henry.jp

2026-04-30

HealthTech Meetup vol.3を開催しました #healthtechmeetup

ヘンリーでPMをやっているdam(@aki_hiro0038)です。

2026/4/17にfreeeさんのASOBIBAスペースをお借りして、メドレーさん、リンケージさんと合同で「HealthTech Meetup vol.3」を開催しました。

オープニング

最初はいつもの3人の軽快なトークからはじまりました。

お互いの近況報告からはじまり、今回freeeさんの会場をお借りすることになった背景の話など。ラジオ感覚で聞き流せる話から場の空気が温まり、参加者同士の会話も自然と生じるようになっていきました。

「最近肩が痛くてですね....お客さまの中に、理学療法士の方はいらっしゃいませんか？」という呼びかけに対して「はい、私です！」と手を上げてくださった方がいたのは、本イベントのハイライトの一つです。

弊社LT紹介

今回は各社のまだ解決できていないムズい話をテーマに6社のLTがありました。

弊社からは山本が「医療ワークフローの複雑さが開発チームにもたらす見えない負債」というタイトルで登壇しました。

医療ワークフローの複雑さを受け入れつつ、けど医療システムは不具合に厳しく、でもスタートアップである私たちは早くつくらなければいけないという悩みを話しました。

「大変だからこそ、やる価値があるという」という最後のメッセージは参加いただいた多くの方々の心に強く残ったようで、イベント後のアンケートや懇親会でも「最も印象的な言葉だった」「背中を押された」と大きな反響をいただきました。

speakerdeck.com

開催してみて

今回の「vol.3」をもって、共催3社の持ち回り開催がひと段落し、ちょうど一巡したことになります。

回を重ねるごとに参加者の熱量が高まっているのを感じていますが、次回の開催に向けては、これまでの形式を踏襲するだけでなく、さらに踏み込んだ「新たな取り組み」にもチャレンジしていきたいと考えています。

HealthTech Meetup vol.4は9月頃の開催を予定しています。まだまだこの輪を広げて、引き続きHealthTech業界を盛り上げて行きたいと思いますので、応援よろしくお願いいたします。

さいごに

ヘンリーでは医療 DX を通じて理想駆動で社会課題を解決してくれる仲間を募集しています！！気になった方は気軽にカジュアル面談をお申し込みください。

2026-04-23

接合面で不確実性を下げ、効率性を上げる ── 私のVPoEとしての仕事

こんにちは、ヘンリーの山口です。2026年4月にVPoEに就任しました。

年末にVPoEの打診を受けてから就任までの数ヶ月、「VPoEとして自分は何をやる人なのか」を探していました。一般的にイメージされるVPoEの仕事と、自分が実際にやり始めた仕事がどうにも噛み合わなかったからです。ようやく自分なりの答えに辿り着いたので、その結論とそこに至るまでの考え方を書き残しておきます。

違和感：一般的なVPoE像と、私が始めていた仕事

VPoEと聞いて多くの人が想像するのは、たぶんこういう仕事です。

エンジニアの採用戦略を立てる
エンジニアのキャリア開発や評価制度を設計する
技術的な方針を決める
開発チームの生産性を上げる
エンジニアリング組織全体を率いる

一方で、打診を受けた後、私が実際に始めていたのはこういう仕事でした。

製品本部の横断チームが、それぞれ「やること・やらないこと」を定義できるように支援する
横断チームと開発チームの関わり方を設計する
営業や導入など、ビジネス側のプロセスとの接合面を整理する

「これは本当にVPoEの仕事なのか？」という疑問がずっとありました。答えを出すために、まず「Engineering」という言葉を自分なりに定義し直すところから始めました。

Engineeringとは何か

そもそもEngineeringとは何か。多くの人はコードを書くことを想像すると思います。ただ、エンジニアがコードを書いて何をしているかというと、手作業でやっていたことを自動化したり、曖昧だったルールを明確なロジックに落とし込んだり、属人的な判断を再現可能なプロセスにしたりしている。こうした一つひとつが、不確実性や非効率を減らしていく営みです。

Engineeringは本来、与えられた制約の中で現実的な解を作り上げる営みです。私はその本質を不確実なものを確実にし、非効率なものを効率化することだと捉えています。コードを書くのはその手段の一つにすぎない。

この定義に立つと、私の仕事も説明できるようになります。

個人の知識と経験に依存していた判断プロセスを、組織としてスケールできる形にしていく。状況ごとに異なっていた関わり方を、再現可能なパターンとして設計する。こういった不確実性を下げ、効率性を上げる仕事が私のEngineeringです。

ヘンリーのエンジニアは、自ずと不確実性を下げていけるメンバーが揃っています。採用や予算の戦略はVPoPが、技術的な方針はVPoTと現場のエンジニアが担っていて、日々のマネジメントも各チームのリーダーが見ています。そもそも自走できるメンバーが多く、手厚いマネジメントを必要とする状況ではありません。

しかし、不確実性や非効率はエンジニアにだけ発生するわけではありません。QAのチーム、ドメインエキスパートのチーム、カスタマーサクセスに関わるチーム——こうした横断的なチームが開発チームとどう噛み合うのか。営業や導入プロセスといったビジネス側との接合面をどう設計するのか。こういった領域は今のところ個人の力でうまく回っています。ただ、組織が拡大していく中で特定の人に頼り続ける構造のままでは回らなくなり始めています。

横断チームと開発チーム、そしてビジネス側との接合面で不確実性を下げて効率性を上げることが、私のVPoEとしての仕事です。

仕組み化そのものが目的ではありません。組織の中にある不確実性と非効率をほどいて、全体が前に進みやすくなる状態を作る。その手段として、仕組みや定義や設計を使っているだけです。

実際にやっていること

今やっていることは、大きく2つあります。

ひとつ目は、横断チームの「やること・やらないこと」を定義する仕事です。横断的な役割を担うチームは日々の活動が多岐にわたる分、スコープが曖昧になりがちです。各チームのリーダーにボールを持ってもらいつつ、私はその言語化と構造化を伴走する形で関わっています。

あるチームでは、日々の行動の裏にある意思決定や意図を形式知にしながら、「一番大事な仕事は何か」を探るワークショップを重ねています。リーダー自身の言葉で、核心に近い表現が生まれつつあるところです。別のチームでは、「何をするチームなのか」がすでに明文化され、全社への展開も終わって、実績作りのフェーズに入っています。

定義ができてくると面白い副作用が出てきます。「やらないと決めたこと」の受け皿をどこに作るかという次の論点が現れるのです。これは私がVPoEとして引き受けるべき仕事になります。やらないと決めたものを宙ぶらりんにしないで、適切な場所やプロセスに移す。移す先がなければ、新しく作るか、既存の定義を見直す。ここまで含めて「定義する」ということだと考えています。

ふたつ目は、営業案件のリスク評価プロセスの再設計です。これまで属人的な運用で回していた領域ですが、組織の拡大と事業環境の変化でそのままでは立ち行かなくなり始めていました。実務の一部を私が一時的に巻き取りながら、営業側と一緒に属人的な判断を形式知として取り出し、再現可能な仕組みに落とし込んでいるところです。営業側にも同じ課題意識があり、進めやすい状況です。

また、開発チームの機能の作り方が多様化していく中で、横断チームが各開発チームとどう関わるかの設計も、これからの論点です。すでに各方面で具体的な動きが始まっているので、それらの意図を理解した上で、パターンとして整理していくつもりです。

目指している状態

これらを通じて目指しているのは、顧客が1年間で感じる価値の総量を増やすことです。

使える機能がより早く手元に届く。存在を知らなかった機能が見つかる。ヘンリーとの付き合い方自体が時間とともに良くなっていく。そういう状態を作りたい。開発のアウトプットが増えなくても顧客が受け取る価値は増やせる、という前提を私は持っています。横断チームと開発チームとビジネス側の接合面が滑らかになれば、すでに作られた価値がきちんと届くようになり、次に作るべき価値の解像度も上がっていく。

VPoEというロールは会社やフェーズによって中身がかなり違うものだと思います。ヘンリーの今のフェーズと組織の形に対して、私が担うべきEngineeringはこういうものだというのが現時点の答えです。まだ手探りの部分も多いですが、一つずつ形にしていきます。

同じようにVPoEの役割を探している方や、組織の接合面に課題感を持っている方と意見交換できたら嬉しいです。Xでも発信しているので、気軽に声をかけてください: @tyamaguc07

2026-04-14

入社オンボーディング「病院ごっこ」で体感した病院の複雑さ

4月に入社したてホヤホヤエンジニアのこん（@k0n_karin）です。入社後3日間のオンボーディングで「病院ごっこ」というヘンリーならではのプログラムを体験させていただいたので、病院ごっこで実際に何をしたのか、そしてそれを通して感じた「病院業務の難しさ」と「それを日々回している医療従事者のすごさ」を、入社直後の視点で書いていきます。

本記事がヘンリーや医療ドメインに興味を持つきっかけになれば幸いです。

ヘンリーは何をしているか？

病院ごっこの前に、まずは簡単にヘンリーの紹介をします。

株式会社ヘンリーは、病院向けの基幹システムとして、電子カルテとレセプトコンピューター（会計・請求システム、通称レセコン）を開発・提供している会社です。提供している「Henry」は、電子カルテとレセコンが一体になった病院向けの業界唯一のクラウドネイティブ型のマルチテナントシステムで、病院業務のDXを進めることを目指しています。（なお、医療機関には大きく「クリニック（診療所）」と「病院」があります。病院は入院（病棟）がある分業務フローが増え、多職種連携や会計・請求も複雑になりやすいのが特徴で、ヘンリーが向き合っているのはまさにこの領域です。）

背景として、日本の医療は制度と業務が複雑で、会計・請求の仕組み（診療報酬制度）に強く依存します。そのため中核のレセコンは更新が難しく、20年以上前に作られたシステムが主流になってきました。医療システムはオンプレ中心で、クラウドでも病院ごとに専用環境を用意する形が多く、マルチテナント型のシステムが前提になりにくい領域でした。

ヘンリーはここに対して、スタートアップとして「自社でレセコン一体型電子カルテを作る」ところから挑戦し、クラウドネイティブならではの継続的な改善を医療現場に提供しています。「社会課題を解決しつづけ、より良い世界をつくる」をミッションに、難易度の高い医療領域に向き合っているのがヘンリーです。

ヘンリーは中小病院向けで唯一のクラウドネイティブなレセコン一体型電子カルテプレーヤー

病院ごっことは？

名前は「ごっこ」ですが、中身はかなり本気で、病院の実際の業務フローを一通りなぞりながら、Henryをご利用いただいている医療現場のお客様を本気で理解するプログラムです。

病院ごっこで登場するロール

すべてのロールを説明しているとキリがないため、ここでは一部を列挙するだけにします。

医師
看護師
医療事務
薬剤師
臨床検査技師
放射線技師
管理栄養士・栄養士
リハビリセラピスト
医療ソーシャルワーカー

そして、それぞれのロールが医師の指示（オーダー）を受け、患者に様々な医療行為をします。

実際の病院では、上記以外にも多数のロールが登場し、それぞれのロールが患者に対し医療行為を行うため、ロールの数だけオーダーも増え難しくなります。またオーダーの種類の多さもさることながら、多くのロールが国家資格を有するため、オーダーの内容も非常に専門性が高くなっています。

エンジニアとしては、患者情報や各種オーダーをどのようにモデリングし、どのロールが見てもわかりやすいようなUIを表現できるか、に思いを馳せていました。

病院ごっこで体験した業務フロー

8種類の業務フローに取り組みました。

外来（初診）
外来（再診）
入院準備〜入院当日
入院中のあれこれ
転棟・退院
レセプト業務
外来のリハビリテーション
入院のリハビリテーション

外来の受診はほとんどの人が患者として経験したことがあると思いますが、患者からは見えない入院時の業務やレセプト業務は想像しづらかったです。

一例として、特に難しい入院準備〜入院当日のフローを紹介します。一人の患者が入院するシナリオがこのようになっています。

かなり詳細を省いて簡略化していますが、これでも一人の患者が入院するためのプロセスが多いことがわかります。またそれぞれのステップで確認・入力する内容が専門的で量も多いです。

このフローを二人一組でペアを組んでいくつかのロールを担当して、Henry上で操作していきます。すべて完了するまでに2時間以上かかり、その難易度の高さからみんな頭を抱えていました。

また、レセプト業務という言葉はあまり聞き馴染みがないかもしれません。

医師が各ロールに対しオーダーを出し、オーダーに従って様々な医療行為を行います。この医療行為に対して診療報酬が発生します。皆さんも医療機関を受診した際に会計で受け取るこういう紙です。

診療報酬は1点＝10円で計算され、この診療報酬が病院の収益の源泉となっています。診察した際には患者の健康保険に応じて総額の1〜3割程度を請求し、残った金額は後日まとめて審査支払機関に申請して受け取る必要があります。審査支払機関に提出するデータ（レセプトデータ）は当月の全患者分の診療報酬の明細をまとめ、翌月10日までに提出する必要があります。休日・祝日・年末年始は考慮されません（！？）。提出したデータが審査され、受理されれば翌々月に支払われます。もし、提出したレセプトデータに不備があると返戻（へんれい）され、修正して再提出しなければなりません。

さらに診療報酬のルールはこれくらい厚みがある上に、2年に一度改定があります。

これだけでレセプト業務がいかに難しいかわかりますね。これを知ってから、医療機関に行った際の業務や会計の見え方がかなり変わりました。

病院ごっこで感じたこと

病院ごっこを通して病院内の業務フローを体感できたのはもちろんですが、やはり業務の難しさが非常に印象的でした。難しい上に、患者さんをケアしながらカルテの記載などの事務作業も並行する必要があることを知り、医療従事者の方々の日々の業務がいかに大変かを実感できました。

ロールによって電子カルテとは別の専門システムなども操作する必要があり、薬剤師なら調剤システム、放射線技師ならPACS（医用画像管理システム）など、この他にも多種多様なシステムが存在します。それらと電子カルテを連携させることを前提に開発する必要性も知りました。同時にヘンリーでは、患者さんのケアを妨げず、どんなロールでもスムーズに操作できるプロダクトを提供する必要があります。複雑な業務フローをいかにシンプルで簡単な体験として提供できるかをこれから考え続け、理想の状態を目指して開発していきたいと感じました。

また、レセプトに関わる業務は、さながらエンジニアリングのデバッグのような難しさを感じました。行った医療行為や患者の疾病に対して、分厚いルール本を読み解き適切な診療報酬を請求する中で、ときには過不足がある状態や誤ったレセプトになることもあります。誤ったレセプトで返戻が多発すると、病院の資金繰りが悪化するため、レセプトは病院の経営に直結しています。社内で過去に医療事務の経験がある方もおり、レセプト業務は「宝探しみたいで楽しい」と表現される方もいらっしゃるようでした。

レセプトのさらに難しいところは、公費の存在です。患者への請求は健康保険の種別や自治体ごとの公費によって支払い額が決まります。公費は、国や地方自治体から補助される制度で、わかりやすいもので言うと国の指定難病の医療費助成や東京都の乳幼児や子どもの医療費助成です。この公費は国や都道府県のレベルだけでなく、市区町村のレベルで独自の制度を持っています。全国の市区町村の総数を考えると、恐ろしく膨大な量のルールになりそうです。

ここまでの内容はヘンリーが扱う難しさのごく一部で、これ以外にも様々なところで医療ドメイン特有の難しさがあるそうです。震えますね。医療ドメインのキャッチアップはまだまだかかりそうです。こういった難しさと向き合う中で、社内ではBiz・Dev問わず、実際にHenryを導入いただいた病院や導入前の病院に見学に行き、ヒアリングや検証を行って顧客理解を深めています。

おわりに

このように、病院の業務は複雑かつ多種多様で、膨大な知識量が求められます。人一人ではとてもカバーしきれず、昨今の生成AIでも簡単に解決できるものではありません。本記事を読んで、ヘンリーに興味を持ってくれた人はぜひ勉強会やカジュアル面談でお話しましょう。

jobs.henry.jp

2026-04-13

Claude Code Marketplaceを使ったSkillのチーム展開とPlugin化の恩恵

Claude Code

株式会社ヘンリーでソフトウェアエンジニアをしているwarabiです。

今回はClaude Code Skillを社内に展開する際に選択したClaude Code Marketplaceの導入と、SkillのPlugin化による副次的な恩恵についてお話しします。

背景

ヘンリーの業務でClaudeCodeを今よりもっと活用するために、開発業務を全自動で行うOrchestrator型Skillの作成と、Skillのチーム展開に関する課題整理をこれまで行ってきました。

それぞれ詳細は以下のブログにまとめてあります。

チーム展開の課題を整理した結果、チームSkill展開について以下の方針を取りました。

個人SkillとチームSkillは別で管理する

Skillはdotfilesやエディタ設定と同じく、個人の作業効率を高めるための環境構築の一部として考える。

各自はSkillという個人の環境を改善していき、そのうえで作られたSkillや知見をチームに還元する。

チームに展開する汎用SkillはStarter Kitの位置づけにし、利用するかどうかは任意とする

Skillの作成についてはまだ十分な知見が溜まっていない。この状態でSkillの利用を必須とすると、どう更新していくか意見の衝突が起きやすくなりSkill作成・更新の停滞に繋がりかねない。

チームSkillは「Starter Kit」の位置づけにし、自身のSkill環境が用意できていない人向けの出発点とする。

方針が固まったので、今回はこのStarter Kitを具体的にどうやってチームに届けるかを考えます。

Claude Code Marketplace

結論から言うと、Claude CodeのMarketplace機能を使いSkillのチーム展開を行いました。

Claude Codeは公式のMarketplaceから様々なPluginが展開されており、利用者は好きなPluginを選択することで便利なSkillを簡単に導入することができます。

Figma, Linearなど外部サービス連携や、skill-creatorのような便利系など様々なPluginが公式から提供されています。

このMarketplace機能ですが、公式のMarketplaceだけでなくGitHubリポジトリを使うことで各自がMarketplaceを簡単に作成することができます。

Marketplaceとして認識させるために必要な設定ファイル、およびPluginフォルダを含めることでGitHubリポジトリをMarketplaceとして扱うことができます。

Marketplaceの登録もコマンド1発で済みます。

/plugin marketplace add [organizaion-name]/[repository-name]

設定ファイルなど詳細については公式ドキュメントを参考にしてください。

https://code.claude.com/docs/ja/plugin-marketplaces

補足説明: Pluginについて

新しくPluginというワードが出てきましたが、これは複数Skillや複数Agentなどを纏めて管理する単位と思っていただければ大丈夫です。

marketplace/plugins
├── github-pr // GitHub操作に関するSKillをまとめたplugin
│   └── skills
│       ├── review-pr
│       │   └── SKILL.md
│       └── triage-github-pr-comments
│           └── SKILL.md
├── dev-workflow // 開発系Skill,Agentをまとめたplugin
    ├── agents
    │   ├── create-pr-agent.md
    │   ├── ...
    │   └── triage-review-agent.md
    └── skills
        ├── dev
        │   └── SKILL.md
        ├── ...
        └── plan-implementation
            └── SKILL.md

Skill, Agentの他にもhooksやsettingsの管理なども行えます。

https://code.claude.com/docs/ja/plugins

Marketplaceの利点

Marketplaceを使ったSkillのチーム展開にはいくつかの利点がありました。

GitHubでのSkill管理の流れと整合する

チーム管理とするStarter Skillは公開後もPullRequestが送られて成長していくことを前提としており、1つのリポジトリで管理する想定でした。

リポジトリをそのままMarketplaceとして登録できる機能はこの想定と合致しています。

自動更新機能がある

これまでのSkill作成の経験から、Skillは一度作ったら終わりではなくそこから育てていくものと私は認識しています。

定期的にSkillの更新を行う場合、その度にSkillを利用するメンバーに毎回手作業での更新を促すのは全員にとって手間があり現実的ではありません。

その点Marketplace機能は登録したリポジトリを監視する機能があり、更新があれば自動で各自の環境に反映をすることができます。

利用するPluginを取捨選択できる

Starter Kit自体を利用する・しないの判断は各自に任せていますが、Marketplace機能を使うとStarter Kitの中でも更に必要なPluginを選択してインストールできます。

またSkill開発者目線でも、利用者への影響を気にせず新しいPluginをMarketplaceに追加できる利点もあります。

これらMarketplaceが持つ機能の恩恵もあってチームへのSkill展開がアナウンスや勉強会での紹介だけで済み、想像より簡単に浸透させることができました。

Skillを直す時もPullRequestをマージすれば各自の環境に自動更新されるためアナウンスも不要となり、導入だけでなくSkill改善のコストも低くおさえることができています。

他に検討した案

Marketplaceの他に、いくつか検討した案についてそれぞれ見送った理由を書いておきます。

案1: 開発本体のリポジトリにSkillとして配置する

ヘンリーの開発環境はモノレポではなく、複数のリポジトリに同じSkillを配置する必要が出てきます。更新の同期が破綻する未来が見えていたので候補から外しました。

案2: ローカルの ~/.claude にcloneする

~/.claude には他のClaude設定ファイルが既に存在しており、それらを除外する手間がかかる
最新版を取り込み直すたびにgit pullが必要になる
pushしたくないローカル専用のSkillとコンフリクトする可能性がある

設定ディレクトリに配布物を混ぜること自体に抵抗を感じたというのが正直なところです。

案3: MDMを使った配布

Skillを配りたいだけの目的に対して仕組みが大げさすぎました。管理の複雑さも増すため候補から除外。

Marketplaceによる副次的な恩恵

またチームへの展開手段とは別で、Skill開発者向けの大きな利点がMarketplaceにはありました。

それは、Plugin化によるフォルダの整理です。

PluginによってSkillの境界を引ける

現状のClaude Codeでは単純にSkillを作成・管理する場合ローカルの~/.claude/skills やプロジェクトの .claude/skills にフラットに配置する構造になります。

Skillの数が少ないうちはあまり問題になりませんが、Skillを作り込んでいくうちにその数は確実に増えていきます。

特にOrchestratorSkillのように親Skillが子Skillを呼び出す構成では、一つのワークフローに対して複数のSkillファイルが必要となります。今後もSkillを作り続けると、100を超えるSkillがフラットに並ぶ日も来るかもしれません。

この問題にMarketplaceのPluginという単位が効いてきます。関心事によってPluginを分けられるため、1つのPluginに含まれるSkill数を抑えつつ、全体の整理もつけやすくなります。

ローカル管理の場合（フラットな配置）

.claude/
├── agents
│   ├── create-pr-agent.md
│   ├── implement-agent.md
│   ├── plan-agent.md
│   ├── plan-review-agent.md
│   ├── review-agent.md
│   ├── triage-agent.md
│   ├── triage-execute-agent.md
│   └── triage-review-agent.md
└── skills
    ├── check-updates
    │   └── SKILL.md
    ├── create-plugin
    │   └── SKILL.md
    ├── create-pr
    │   └── SKILL.md
    ├── dev
    │   └── SKILL.md
    ├── implement
    │   └── SKILL.md
    ├── improvement
    │   └── SKILL.md
    ├── linear-manage
    │   └── SKILL.md
    ├── linear-triage
    │   └── SKILL.md
    ├── linear-triage-execute
    │   └── SKILL.md
    ├── linear-triage-review
    │   └── SKILL.md
    ├── lint-settings
    │   └── SKILL.md
    ├── memory-manager
    │   └── SKILL.md
    ├── plan-implementation
    │   └── SKILL.md
    ├── retrospective
    │   └── SKILL.md
    ├── review-lint-rules
    │   └── SKILL.md
    ├── review-pr
    │   └── SKILL.md
    └── slack-notify
        └── SKILL.md

Marketplace管理の場合（Plugin化による整理）

marketplace/plugins
├── dev-workflow
│   ├── agents
│   │   ├── create-pr-agent.md
│   │   ├── implement-agent.md
│   │   ├── plan-agent.md
│   │   ├── plan-review-agent.md
│   │   ├── review-agent.md
│   │   ├── triage-agent.md
│   │   ├── triage-execute-agent.md
│   │   └── triage-review-agent.md
│   └── skills
│       ├── create-pr
│       │   └── SKILL.md
│       ├── dev
│       │   └── SKILL.md
│       ├── implement
│       │   └── SKILL.md
│       ├── linear-manage
│       │   └── SKILL.md
│       ├── linear-triage
│       │   └── SKILL.md
│       ├── linear-triage-execute
│       │   └── SKILL.md
│       ├── linear-triage-review
│       │   └── SKILL.md
│       └── plan-implementation
│           └── SKILL.md
├── github-pr
│   └── skills
│       ├── review-pr
│       │   └── SKILL.md
│       └── triage-github-pr-comments
│           └── SKILL.md
├── retrospective
│   └── skills
│       ├── improvement
│       │   └── SKILL.md
│       └── retrospective
│           ├── SKILL.md
│           └── template.md
├── sentry-triage
│   ├── agents
│   │   └── sentry-investigate-agent.md
│   └── skills
│       ├── sentry-investigate
│       │   ├── SKILL.md
│       │   └── template-result.md
│       └── sentry-triage
│           └── SKILL.md
└── slack-notify
    └── skills
        └── slack-notify
            └── SKILL.md

dev-workflowには開発フロー全体のSkillが、github-prにはPRレビュー関連が、といった具合に関心事で区切られています。フラットなskillsフォルダに全部を並べていた頃と比べると、どのSkillがどの文脈に属するのかが構造として表現されるようになりました。

Skill同士の依存関係が組めるわけではなくSkillの記述次第ではPluginの境界を越えた呼び出しも行えてしまうため、これはあくまでファイル整理上の利点ではあります。ただ、フラットに置くことしかできなかったSkillにPluginという1段区切りを設けることができるのは、Skill開発者にとって大きなメリットとなります。

おわりに

Claude Code Marketplaceを導入したことで、Skillのチーム展開における配布と更新の課題をシンプルに解決できました。GitHubリポジトリとの親和性が高く、既存の開発フローに自然に組み込むことができています。

そして当初は配布手段として検討したMarketplaceでしたが、Plugin単位でSkillの境界を引けるという副次的なメリットも得られました。Skillの数が増えるほど、この整理の恩恵は大きくなると感じています。