株式会社ヘンリーでVP of Productを務めている縣です。
この記事では、ヘンリーが2026年4月に新設するCRE部（Customer Reliability Engineering）について、なぜこの部門が必要なのか、ヘンリーにおけるCREの定義とは何か、そしてどんな人と一緒にこの部を立ち上げたいのかをお伝えします。
Customer Reliability Engineering
CRE (Customer Reliability Engineering)という言葉を聞いたとき、多くのエンジニアが思い浮かべるのは、Googleが2016年に提唱したCREではないでしょうか。
GoogleのCREは、SRE（Site Reliability Engineering）の考え方を顧客向けに拡張した概念で、SLO/SLIやエラーバジェットをベースに顧客のシステム信頼性をプロバイダーと共同で管理するというものです。一方、日本のSaaS企業では、CREを「問い合わせ起点で技術的な調査を行い、開発チームへエスカレーションする組織」や「カスタマーサポート・カスタマーサクセスの業務効率化のための開発組織」として運用しているケースなど、各社それぞれの形があります。
このように、CREという言葉が指す責務の範囲は企業によってかなり幅があります。この記事では、ヘンリーがCREをどう定義し、何を担う組織として立ち上げたのかを明確にしたいと思います。
ヘンリーのプロダクトが持つ特殊性
ヘンリーが提供しているのは、クラウド型の電子カルテ・レセコンシステムです。医療業界は法令規制と業務の複雑性・専門性が極めて高い領域で、プロダクトを「使えるようにする」までのプロセスが、一般的なSaaSとは桁違いに重いという特徴があります。
たとえば、提供する医療の種類が異なる病院ごとに合わせた設定作業、既存システムからのデータ移行、導入後の保守改善。これらはプロダクトの機能開発とは別のレイヤーにある仕事ですが、ここが崩れると顧客は安定して価値を受け取れません。
また、機能開発の観点でも課題があります。電子カルテ・レセコンは機能の面が広大で、開発チームのキャパシティで全ての面をカバーし続けることは現実的に難しい。どうしても手が回りにくい機能が生まれ、そこに信頼性を下げる要因が溜まっていきます。こうした問題を放置せず潰していくには、意識的に仕組みを設計しなければ達成できません。
つまり、ヘンリーにとっての「信頼性」は、システムの稼働率やレスポンスタイムだけでは語れない。導入、設定、移行、保守改善まで含めて、顧客が安定して成果を出せる状態をつくること、それが僕たちの考える Customer Reliability です。
なぜ今、専門の部門が必要なのか
これまでヘンリーでは、こうした顧客に近い運用業務を専任の小さなチームと、電子カルテや医事会計を開発するエンジニアが兼務的に支えてきました。プロダクトの成長初期にはそれでも回っていましたが、導入病院数が増え、中小病院への展開を本格化するフェーズに入ると、いくつかの構造的な課題が顕在化してきました。
ひとつは、属人化です。設定やデータ移行のノウハウが特定の人に集中し、その人がいないと案件が進まない。もうひとつは、開発部門の余力の圧迫です。プロダクト開発を担うエンジニアが、本来注力すべき新規開発ではなく、導入・保守に近い運用業務に時間を取られてしまい、機能拡充の速度が出せない状態になっていました。
これらを個々の工夫で乗り越え続けるのは限界があります。だからこそ、顧客に近い運用を属人的な対応で終わらせず、再現可能な仕組みに変えることや製品に還元することを専門で担う部門が必要だと判断しました。
HenryのCRE部が担うこと
CRE部のミッションを一言で表すなら、「顧客に近い運用で見つかる課題を、プロダクトと運用の両面から再現可能な仕組みに変える」ことです。
具体的には、以下のような領域を担います。
- Henry の導入を効率化するためのエンジニアリング的サポートや業務フロー設計
- 設定やデータ移行といった、製品オンボーディングの効率化のための製品開発
- 顧客からの声の収集と、それに応じた製品改善
逆に、CRE部が担わないことも明確にしています。プロダクトの新規機能開発に関しては他部署にフルサイクルな形で託し、責任者や完了条件が曖昧な依頼・機能領域をそのまま引き受ける「何でも屋」にはなりません。責務を明確にすることで、CRE部も他部署もそれぞれの領域に集中できる状態をつくることが、組織設計上の最も大事なポイントだと考えています。
「問い合わせ対応」を超えて、再発しない仕組みをつくる
ヘンリーのCRE部では、問い合わせ起点で顧客の課題に触れることも当然あります。ただし、それを一時的な解決で終わらせず、根本的な解決につなげるところまでをCRE部の責務として位置づけています。 そして、解決手段の中で最も優先度が高いのはプロダクトの改善です。運用手順や運営モデルを整備することも重要ですが、そもそもプロダクト側で解決できるなら、それが顧客にとっても組織にとっても最も良い形です。ヘンリーのCRE部が目指すのは、顧客に近い運用の中で見つかった課題をプロダクトの改善として還元し、同じ問題が起きない状態をつくる組織です。
CRE部のエンジニアを募集しています
CRE部は立ち上がったばかりの組織です。やるべきことは山ほどあるのに、まだまだ人が足りていません。 元々この領域に取り組んでいた数名のメンバーも引き続きCRE部として活動予定ですが、事業の状況から逆算した本来的に成し遂げたい責務に対しては、純粋にリソースが不足しすぎている状況です。
CRE部のエンジニアには高いエンジニアリングスキルが求められます。Henryは電子カルテ・レセコンという広大なドメインをカバーするプロダクトであり、CREはその機能や実装を俯瞰的に把握したうえで、必要があれば自ら修正を加えていくことが求められます。単一の機能を開発するのとは異なる難しさがあり、プロダクト全体を横断的に見る力が必要です。
裏を返すと、CRE部は電子カルテ・レセコンという広大なドメインに対して最速で俯瞰的な視点を得られる部署だと考えています。将来的にはCRE部と他の開発部門との交換留学や異動を通じて、相互の知識と経験を融合させていくことも視野に入れています。
加えて、新設の部門をゼロから一緒につくるフェーズなので、エンジニアリングだけでなく、責務定義や運営モデルの設計、チームづくりにも関わることになります。顧客に近い運用とプロダクト開発側の制約の両方を見ながら、事業に直結する仕組みを作る。エンジニアリングと組織づくりの両方に手を伸ばしたい人にとって、面白い環境だと思います。
僕たちが一緒に働きたいのは、曖昧な責務境界を放置せず構造化できる人、現場の泥臭さを理解しつつ属人運用を仕組みに変える意思のある人、そして部門最適ではなく事業全体にとっての優先順位で意思決定できる人です。
おわりに
CRE部はまだまだ立ち上がろうとしている段階の組織です。ここに書いたことも、今時点で考えていること・狙っている方向性であり、今後ヘンリーにおけるCREの定義自体も変化していくと思います。
それでも、僕たちが向き合っている課題感、つまり医療という複雑なドメインで導入から保守改善まで含めた「顧客が安定して成果を出せる状態」を再現可能な形で作り続けたいという方向性が少しでも伝わっていれば嬉しいです。
この挑戦に興味を持っていただけた方は、ぜひカジュアル面談でお話ししましょう。
