株式会社ヘンリーでSREをしている戸田（id:eller）です。ひとりめSREとしてヘンリーにジョインしてから約3年、現在ではSREも3人のチームになりました。それでも事業計画に対してはまだ足りていないので、SREエンジニア採用を継続的に行っています。
私がSREチームを作るのは前職から続けて2回目なのですが、いずれの場合でも重要だと考えていることがあり、カジュアル面談でもよく話しています。今回はそのエッセンスをまとめて、同業はもちろん弊社への転職を検討されている方にも参考にしていただければと思っています。
前提としての「チームの目的」
チームを作っていくためには、そのチームの目的や存在意義を明確にする必要があります。SREチームであれば、何のSite Reliabilityをなぜ、どのようにしたいかを明確にする必要があります。 そしてこれらを明確にするためには、事業やサービスについての理解が不可欠です。
弊社のサービスはレセプトコンピュータ一体型のクラウドネイティブ電子カルテです。ITエンジニア向けには「SaaSとして稼働する医療機関向け基幹システムのSREチーム」だと説明するのが通りが良いと思っています。命もお金も要配慮個人情報も扱うシステムであり、高い信頼性とセキュリティが求められるのが特徴です。一方で顧客である中小病院にはシステム運用の専門家がいないことも多いので、インフラやアーキテクチャやサービス運用といった自社がコントロールするものにとどまらず顧客によるサービスの利用や運用も含めて支援する必要があります。
また弊社のサービスはTypeScriptとKotlinで書かれた複数のサーバで構成されており、さらに院内システム（検査など）との連携のために院内ネットワークにインストールいただくアプリケーションも存在します。院内のネットワークや端末は弊社が保守するものではないことや、連携が止まるとお客様の業務が止まることも踏まえて、よりオブザーバビリティが求められるシステムであると言えます。
最後に弊社のサービスは業界的には後発であり、まだ機能は充分ではないことを意識する必要があります。機能開発や改善の頻度も高く、毎週変更をデプロイしており、高速な価値検証をしようという経営方針が徹底されています。ですからデプロイやリリースを安全かつ高頻度に行うことが大切です。
以上をまとめると、ヘンリーにおけるSREは医療ドメインへの理解を持ちながら、高いオブザーバビリティと安全かつ高頻度なデプロイやリリースを実現することが求められています。
SREチームを作るうえで大切にしていること
こうしたの目的を踏まえて、私がSREチームを作るうえで大切にしているのは次の3点です。
運開分離をせず、サイロを壊す
これは最近 id:horsewin が理想駆動ラジオでも触れてくれているのですが、弊社ではプロダクト開発エンジニアがTerraformを通じてインフラを触ることもDatadogを見ることもありますし、逆にSREがプロダクトコードを書くことも普通にあります。といいますかSREは運用担当ではなく、またプロダクト開発エンジニアも開発専任ではありません。デプロイやリリースは全チームで膝を（オンラインで）突き合わせてやりますし、障害発生時も全チームがウォールームに（オンラインで）集まって対応します。
そもそもSREが生まれた背景ないしDevOpsの流れを踏まえると、運開分離をしないのが普通ということになるかと思いますが、ここは重要な観点なのでもう少し説明します。
弊社のように数多くの試行錯誤が必要でサービスそのものが固まっていない場合は、運開分離によるサイロ化と速度の低下は大きなデメリットとなります。また開発のために有用なインプットは運用からこそ得られるので、開発が運用を見ることは非常に重要です。ですからSREは運用をするだけではなく、プロダクト開発エンジニアが目指す運用ができるように基盤を整えたりイネーブリングしたりすることを意識しています。そのためにはデプロイ時の留意点やログラベルの使い方、Datadogの使い方、Honeycombの使い方、tfactionの使い方などをきちんとドキュメントに落とし、GitHubリポジトリやオンボーディング資料からリンクさせるなどして、新しくジョインしたプロダクト開発エンジニアでも短期間でキャッチアップできる状態を作っています。
ちなみにこの文書化は弊社全体の特徴でもあります。この技術ブログも継続的に発信できていますし、技術書典に合同誌を出したのも書くことが習慣化されているからできたことです。カジュアル面談でも弊社を知っていただいたきっかけとしてよく伺うので、やっててよかったと本当に思います。
ドメインへの理解を深める
SREとしてサービスのReliabilityを作るうえで、顧客によるサービスの利用や運用も含めて支援することが必要であると書きました。言い換えると弊社サービスの信頼性は、クラウド上で動作するITシステムだけではなくお客様のご理解や実施いただいている運用にも左右されます。院内ネットワークや端末の性能に起因する体験の悪化もありますし、お客様の現場で行われる医療情報の扱いしだいでは個人情報が充分に守られないことも考えられます。こうした課題に対しても調査したりお客様にご説明できたりする体制を作ることがSREチームには求められます。
また、こうしたドメインの理解はオブザーバビリティを改善することにも役立ちます。医療現場では外来受付やバイタル測定のような毎日行う業務はもちろん、電子レセプト提出のように月初に行う業務や、データ提出のように3ヶ月に1度だけ行う業務があります。このような理解があると、これらの業務に関するサービスの平常状態を定義するのに役立ちます。実際弊社のDatadogには、電子レセプト提出やデータ提出に特化したダッシュボードが用意されています。
弊社ではドメイン勉強会をはじめとした学習機会が提供されています。また私は医療ドメインの知識を持たずに入社したこともあり、医療情報技師の資格を取ることや読書などを通じてドメインの理解を深めるようつとめています。SREチームとしてもドメインについて学んだことを互いに教え合うなどしてお客様業務の理解につとめていくことが重要だと考えています。
個々人の強みを活かす
目標を踏まえると「医療ドメインを理解しつつインフラからアプリ、果てはオブザーバビリティまで何でも対応できるエンジニア」が必要だと言えますが、そんな人はまずいません。 私自身、医療ドメインとアプリ、JVM運用などは得意としている一方で、ネットワークやインフラについてはまだ経験が不足していると感じています。もちろんスキルや知識ではなく気質に起因する課題もあります。
ですからSREエンジニア個々人の強みを活かすことが大切だと感じています。たとえば2人目SREの id:nabeop がジョインしてくれて、SREとしての基礎固めはもちろん、OpenTelemetryの導入や監視の改善といった「私ひとりではできていなかったこと」が数多く解決されました。技術勉強会も開催され、チーム間の情報流通やコミュニケーション機会として楽しく継続できています。また id:sumiren_t がジョインしてくれてからたったの3ヶ月でオブザーバビリティ周りの改善が数多く実施され、どこで何が起きているかを素早く正確に、かつ合理的なコストで把握できるようになりました。
個々人の強みを活かすためには、チーム全員で目標意識が共有されていることや、共通言語が整理されていること、オープンに議論できる土台があることが重要だと考えています。
今のSREチームではScrumしたいと思いつつあまりできていない認識はあるのですが、それでも四半期ごとの目標設定とその継続的な更新は意識して行っています。少なくとも毎月1回は目標を見直し、明らかに達成不可能な目標のドロップや、新しい材料が揃って意思決定が進められるようになった目標の更新などを全員で行っています。
またチームの誰もがPRをレビューできる体制を継続するために、PR依頼先をラウンドロビン方式で決めています。自分がPRレビューをする前提があるので、他のメンバーが担当している課題について朝会で積極的に聞く姿勢ができますし、PR作成側も理解してもらえるように自然と説明責任を果たすようになると考えています。
最後のオープンに議論できる土台は、心理的安全性はもちろんですが、弊社のバリューであるドオープンを守ることに繋がります。これは人数が少ないのでまだそこまで難しくないのですが、それでもオンラインランチ会を開催して業務と関係ない交流機会を作るようにしています。また個人的にも技術勉強会に積極参加するとか、業務に関係ないコミュニケーションをSlackのtimesでするとか、ダジャレに心血を注ぐとか、やれることはやっているつもりです。
まとめ
株式会社ヘンリーのSREチームでは、医療機関向け基幹システムをお客様にご提供するために、運開分離をせず個々人の強みを活かす組織づくりを心がけています。そのためにバリューのひとつであるドオープンを踏まえて、プロダクト開発エンジニアに対するドキュメントやイネーブリングの提供を行うとともに、SREチーム内で協力して動くための目標設定やコミュニケーション設計、学習機会醸成を行っています。
株式会社ヘンリーのSREチームでは、医療 DX のど真ん中であるクラウドネイティブのレセコン一体型電子カルテを一緒に開発してくれる仲間を募集しています。医療 DXやオブザーバビリティ、サービス基盤の構築やプロダクト開発エンジニアへのイネーブリング提供に興味がある方はぜひカジュアル面談しましょう。また2025年6月5日に弊社エンジニアに会えるHenry Engineer Meetupの開催を予定しておりますので、こちらも合わせてご検討ください。お待ちしております！
