ヘンリーで SRE をやっている 
id:nabeop です。
Cloud Operator Days Tokyo 2025 (CODT2025) は運用者が日々取り組んでいる新しい挑戦、成功・失敗体験、得られたノウハウを分かち合うインフラエンジニア向けの技術イベントです。弊社では CODT 2025 に Platium スポンサーとして参加しています。本ブログエントリでは CODT 2025 での弊社での取り組みについて紹介します。
続きを読むQAの理想を語らNight！を開催しました！
ヘンリー CEO / CPOの逆瀬川です。 7/30(水)、当社主催で「Henry QA LT大会」を開催しました🎉
QAのスペシャリストとして活躍する豪華ゲスト3名が登壇し、ハイレベルなLTを繰り広げていただきました。
セッション内容と、公開OKな当日資料を公開します。
オープニング
LTの様子
実践！ホリスティックテスティング
ヘンリー社 tsukiGさん
サマリ
ヘンリーではプロジェクトライフサイクルを定義して、開発プロセスを回している。
品質活動の4分類をマッピング！
特徴的な活動
- スリーアミーゴスの拡張として、ビジネスチームを召喚。小さな開発を実践してフィードバックを！
- BDDの実践！
- 探索的テストと、ユーザーの価値が届くかどうかの検証に重きをおいた打鍵会
- 病院に寄り添うリリース戦略として、ユーザーへのでも環境の展開や、エンジニアでの現地での素早い対応
- 仲間募集しています！
資料
ホリスティックテスティングの右側も大切にする
10X社 ブロッコリーさん
サマリ
- ホリスティックテスティングは、どこでもテストするよって話
- Sift-leftはブロッコリーさんの過去の登壇資料を読んでね
- Sift-rightを定量と定性から[はか]る
- 定量的に[はか]る
- 事業を理解して、データをボトルネックを測ることが大事
- 10Xの例 配達枠と注文のバランスや、小売のかご単価の利益の構造のデータ見てボトルネックを分析しよう
- 定性的に[はか]る
- 行動から品質を察[はか]る
- 仲間募集しています！
資料
入り口から考えるソフトウェアテストエンジニアのキャリア ~ 別々のスタート地点と、それを乗り越える学びの力 ~
shimashima35さん
サマリ
- 理想のキャリアパスとして、まずはジュニアソフトエンジニアとして広く浅く学ぶ
- が、最近は、スペシャリストとしてデベロッパーとテストエンジニアが入口から分かれてしまっている？
- shimashimaさんの場合は、SIから入ったので一通り経験することが当たり前だったが、専門性がある人は周りにいたわけではなかった
- ソフトエンジニアのSWEBOK V4の領域体系を見てコアスキルを見てみるとやることが多い
- 学ぶことが多いし入口で学んでいなかったら、勉強していこう！学習環境は楽になっているので勉強しよう！
- LLMと一緒にWebアプリを一通り作ってみて、困ったことをLLMに聞くのが良い。UI以外のテストの幅も拡がる
- まずは、自分の手を動かしましょう！
資料
パネルディスカッション
また、イベントの終盤では登壇者が再集合し、会場からの質問へのQ&Aへの回答やQAのキャリアについて語る場面も。QAの技術からキャリアまでさまざまな角度から、参加者の皆様と一緒に学びを深める機会となり、キャリア感も三者三様で白熱した議論が繰り広がれました。
会場でやり取りされた質疑応答の内容の一部をご紹介します。 会場に来ていたエンジニアの方からは、「AIを使ってテストを書いたりしているので、心に刺さりました 」という声も。
- [お題] 定性、定量の[はか]るどっちを重視している？また、行き来をどうやってやっている？
- A: 今は定量を重視しているけど、初期は定性を重視。定性で現場の解像度をあげないと業務の流れとか、データを見るべきポイントがわからない by ブロッコリーさん
- [お題] テストの活動で、荒いところと細かいところが合ったが意図はありますか？注力しているポイント等が表されているのではないか？
- A: Shift-leftに寄ってしまっている。Rightもやっていかないという想いがある。やることが沢山あり、全部のタッチポイントにQAが関わるのが難しいので、今後は元気玉システムで、ワンチームで活動を充実させていきたいby tsukiGさん
- [お題] QA観点で、AI頼る部分を知りたい。うまく活用できてない
- A: テストの手順書をMCP経由で、実行出来ないかとかレビューの自動化が出来ないかというところを試している。mablもやっているよね(笑)。テスト設計の壁打ち設計で言うと、観点を踏まえてAIに壁打ちしていくのが良いと思う by shimashima35さん
- A: ある程度、テスト設計がある程度それっぽいのが出来るので「それっぽいのが出来る」のでレビューコストがかかる。そもそも、QAとAIの相性が悪いと思う。正しいことを確認したいQA vs 確率論で正解にたどり着きたいAI。実例MappingをGherkin記法に変換するのは出来る。ホリスティックテスティングの無限大の図は、一連のつながりが大事。そこを変換するところに、AIを活用するのが良いのでは？ by tsukiGさん
- [お題] QAエンジニアのキャリアへのお悩み
- A: テスト会社によっても、会社ごとに特色があり強みがテスト会社ごとに異なるはず。経験があることがチャンス。テストエンジニアリング力を上げるものは３つ。1つは、ソフトウェアテスト技法練習帳。2つ目はテスト設計コンテストのチュートリアルをやる。3つめは、WACATEへの参加！合宿型のワークショップの勉強会でテストエンジニアリングが学べる。 by ブロッコリーさん
最後に
ヘンリーでは、今後もこのようなイベントを開催し、事業に学びを活かしていく予定です。
2025年9月11日 (木) にVerticalな深いドメイン開発の開発者、QA、PdM向けのイベントとして「Henry Engineer Meetup #2 〜医療システム開発の難しさ・面白さ レセコン編〜」というイベントを開催します。 参加者を絶賛募集中なので、深いドメイン開発の難しさ、面白さのリアルについて知りたい方は、ぜひ参加登録してください。懇親タイムでは、オフレコトーク満載でレセコン(医事会計システム)の開発に付いてお話したいと思います。
また、QA 以外でもヘンリーの理想を実現するために手伝ってくれる仲間を募集しています。弊社に興味のある方はぜひカジュアル面談させてください。
はてなさんと合同で技術勉強会を開催しました
株式会社ヘンリーで SRE などをしている id:nabeop です。弊社では技術勉強会1を毎週開催しておりますが、このたび「はてなブログ」などの個人向けサービスや出版社向けマンガビューワの「GigaViewer」、オブザーバビリティプラットフォーム「Mackerel」、発話分析ソリューション「toitta」などを開発している株式会社はてなさんとと合同でクローズドな技術勉強会を実施しました。
当日は双方から発表し日頃の様子などが知れて良い交流ができました。
弊社の参加者の発表内容を軽くご紹介します。
CIを整備してメンテナンスを生成AIに任せる
一條さん(@hazumirr)が個人開発しているツールのメンテナスをAIを活用することでメンテナンスコストを極力かけないようにしている様子を発表しました。
ヘンリーにおける OpenTelemetry のトレース活用の様子
弊社の2つ目の発表は id:nabeop が Henry で OpenTelemetry の分散トレースを扱うにあたり、トレースに属性を追加することで調査などに活用している様子を紹介しました。
k1LoW/deck の紹介
飛び入りでフェローの 
id:Songmu さんが Markdown で記述した内容を Google Slides のスライドに変換する k1LoW/deck の紹介をしてくれました。k1LoW/deck で実際にスライドを作成しつつ、最近のコントリビュート内容の解説などしてくれてとても盛り上がりました。
宣伝
2025年7月30日 (水) に QA エンジニア向けのイベントとして「QAの理想を語らNight!」というイベントを開催します。参加者を絶賛募集中なので QA について興味のある人や QA の理想と現実のギャップに悩んでいる人はぜひ参加登録してください。
また、QA 以外でもヘンリーの理想を実現するために手伝ってくれる仲間を募集しています。弊社に興味のある方はぜひカジュアル面談させてください。
CoLab Conf（コラコン）でブース出展しました！
Henry開発者のタケハタ(@n_takehata)です
7/13(日)、ヘンリーはCoLab Conf（コラコン）にてブース出展をしました！ 今回はヘンリーブースのコンテンツや写真など、会場の様子をご紹介できればと思います。
CoLab Conf（コラコン）とは？
サポーターズCoLabさんが主催された、「U35エンジニアの生存戦略を考えるテックカンファレンス」です。
supporterz-seminar.connpass.com
今回は「AI」と「キャリア」をテーマに、豪華なスピーカーの方々によるセッションや、スポンサー企業によるブース出展がありました。
ヘンリーも御縁があり、ブースを出展させていただきました。
ブースの様子
ヘンリーのブースの様子です。
スタンプラリーを開催したりと、運営の方でも盛り上げていただいたこともあり、一日中絶え間なく参加者のみなさまに来ていただきとても盛況でした！
医療業界クイズを実施しました！
今回のヘンリーブースでは、医療業界クイズを実施しました！ 全問正解された方には、景品として以前技術書典でヘンリーの有志メンバーで販売した同人誌「電子カルテの開発を支える技術 ~ モダンな技術で再発明する ~」をプレゼント。
クイズは以下のような問題をご用意しました。
政府の調査にて、DX（デジタル・トランスフォーメーション）が一番遅れていると言われている産業は次のうちどれ？ - 漁業 - 宿泊サービス業 - 農業 - 医療福祉業 全国の病院に対し、政府は2030年に電子カルテの導入率100%を目指していますが、まだ電子カルテが導入されていない割合は？ - 10%程度 - 20%程度 - 30%程度 - 40%程度 次のうち、法的な「病院」の定義として正しいものは？ - 内科・外科の両方を標榜している医療機関 - 入院設備を持ち、患者を24時間受け入れられる医療機関 - 入院ベッド数が20床以上の医療機関
来られたみなさん興味を持って挑戦してくださって、問題の答え合わせをしながらヘンリーの取り組みについてお話しすることができて嬉しかったです。
クイズを通して普段は馴染みのない方にも、医療業界の抱える課題や、ヘンリー含め医療DXに取り組む事業の意義を知っていただくきっかけになったのではないかと思います。
ブースにお立ち寄りいただいたみなさん、ありがとうございました！
当日ブースにお立ち寄りいただいたみなさん、ありがとうございました！
またイベントとしても大変盛況かつ会場の混乱もなく、運営スタッフのみなさまにも大変感謝しております。
今後も機会がありましたら、ブース出展など含めイベントにも協力させていただければと思っています。
VPoEとして大切にしていることと、2025年上期に実施した施策
株式会社ヘンリーで2025年3月からVP of Engineeringを務めている戸田（id:eller）です。任命から3ヶ月経ったので現状をまとめつつ、今後の見通しなどについてまとめたいと思います。
VPoEとVPoTの違い
私は1月からVP of Technologyも務めており、現在は兼務している状況にあります。本題に入る前にこれら2つがどう異なるか、ヘンリーではどう考えているかを整理してみます。
VP of Engineering（VPoE）はエンジニアリングについてステークホルダーに説明責任を持つポジションであると定義しています。エンジニアリングとは工学ですから、VPoEは工学的アプローチ、特に組織づくりや開発プロセスを見るわけですね。ヘンリーは組織規模を拡大している最中で、またフルリモートを特徴のひとつとしている会社でもあるため、組織づくりや開発プロセスは投資する価値が高い状況です。個々人が裁量を持って自律的に働ける環境と、周囲とのシナジーを活かして組織としてのアウトカムを最大化していける環境の双方を実現することが求められています。
対してVP of Technology（VPoT）は技術についてステークホルダーに説明責任を持つポジションであると定義しています。製品としてのHenryがどう技術的な選択をしてきたか、これからどう対応を進めようとしているか、を見ることになります。Henryは病院向け電子カルテとしては前例のないクラウドネイティブ実装であり、業界に対してクラウドネイティブの強みや運用、セキュリティについての考え方などを継続的に発信していくことも求められています。
ひとことで言えばVPoEが組織体制、開発プロセスを、VPoTがサービスの実装詳細やその仕様を見ると思えばよいでしょう。いずれも製品本部に留まらず全社的に横断した機能として期待されています。直近は次のような活動をしてきています：
- VPoE
- 部室長向けオンボーディングないしコーチングの企画と実施
- 行動規範, 等級制度ないし評価制度の検討
- 大きくなったstream-alignedチームの分割
- VPoT
- お客様に提示するセキュリティホワイトペーパーや仕様書の作成
- SIerやネットワーク事業者に提示する稼働環境仕様書の作成
- noteでの情報セキュリティ関連情報の発信
本日はVPoEの部分にフォーカスして、ヘンリーが抱えている課題とその対策について述べていきます。
ヘンリーにおけるエンジニアリングの課題
私は3代目のVPoEですから、先達の学びを活かすことができます。ということで歴史の振り返りから始めましょう。
歴史的背景
私の前にも id:shenyu_cyan さんと id:Songmu さんがVPoEとして活動されています。その背景についてはダブルVPoEについてのブログ記事が参考になるでしょう。
大きく分けて「圧倒的に強い開発組織を作り上げる」「強い開発組織の改善力を会社全体に展開する」の2つのミッションを持っていました。現在のVPoEも同様に双方のミッションを持っていますが、後者の一部は組織開発や経営企画といった他部署でも取り組まれています。このため今回は論点を単純化する目的から、後者は割愛します。
「圧倒的に強い開発組織を作り上げる」ために必要な課題は3つ、採用とロイヤリティ、そしてエンパワーメントです。そして採用が現状もっとも難しいという認識を持っています。
採用の強化が最優先課題である
ITシステム開発の世界では「人月の神話」に代表される重要な知見があります。人を増やしてもシステム開発は早くならないということですね。「カップラーメンを3人で作っても1分ではできない」との説明もされます。ですからプロジェクトの進捗が悪いからと言って、いたずらに人を増やすことには慎重であるべきだと考えています。
しかしこれを踏まえても、ヘンリーのエンジニア組織はやるべきことに対して小さすぎます。理想ベースで考えると7〜8チームはあってもいいだろという体感がありますが、現状は合計4〜5チームで、まだ足りません。プロジェクトの進みが遅いというよりは、人がいないのでプロジェクトを始められない状況と言えるでしょう。
せめて6チームに増やすことを年内でやりたいのですが、そうするとまだまだエンジニアやDE、QAやデザイナーなどの採用を継続的に行う必要があります。採用だけが解決ではないのは当然で他の施策も並行で進めますが、組織としてできることを増やせるのが採用の良さであり、長期的に投資をしていくべきだと考えています。
行動指針を「あたりまえ」の存在にしたい
ヘンリーでは「理想駆動」「爆速アウトプット」「ドオープン」をバリューとして掲げてきましたが、先日これをブラッシュアップした新しい行動指針が誕生しました。
私は行動指針は周囲を巻き込むための素材であり、成長の種であり、ロイヤリティの源泉であると考えています。新しい行動指針が私たちの中で「あたりまえ」になれば、我々をひとつの組織としてまとめ社会課題に挑戦させてくれるでしょう。一方で行動指針は我々ののびしろを規定するものでもありますから、今現在はできていないところも多々あります。その事実を認知し、我々の日々の行動に浸透させて、「あたりまえ」にしていく過程を回していくことがVPoEとして重要であると考えます。
なかでも特に「燃える理想」「爆速アウトプット」がきちんとできるスピードある組織や仕組みをつくること、「自分起点」や「ワンチーム」を支える心理的安全性を醸成すること、が重要です。これには日々の1on1やブログでの発信、経営会議での議論など様々なアプローチが有効なはずで、戦略的に臨んでいく必要があります。
リーダーシップを握り合う組織の土台としてのミドルマネジメントが必要
書籍「チームワーキング」で推奨されている「目標を握り続ける」リーダーシップを推進するには、マネジメントだけではなく従業員それぞれが自分起点で行動して周囲を巻き込んでいくことが必要となります。マネジメントが率先してリーダーシップを発揮することも重要ですが、他にもチームに対して期待値を伝えたり、発言しやすい環境を整えたり、挑戦の障害を取り除いたりと様々なアプローチが効果的です。しかし製品本部ではCPOが部室長を兼務する体制が続いていた関係で、こうしたアプローチを継続的に取る余裕がない状態が続いていました。
自分起点での行動がしっかり回るとみんなのモチベーションも上がるし、結果として生産性も影響されるとは思うんですが、そのためには心理的安全性に加えて失敗を奨励する文化が必要になります。しかし、これらは資源的・時間的な余裕がないとなかなか生まれません。人が足りない・時間が足りない製品本部では特に難しいやつだという認識を持っています。
施策
ここまででVPoEとして認識している課題を述べてきました。ではこれらの課題に対し、VPoEとしてどのような打ち手を取ってきたかをご紹介します。
部室長オンボーディング
行動指針を浸透させ、心理的安全性を醸成し、失敗を奨励する文化にするためには、マネジメントが重要です。特に私たち製品本部ではつい最近まで部室長専任が存在しませんでした。ですからマネジメントが行動指針を率先して行い、チームメンバーに目を配り、多様なアプローチで組織を変えていくためには、マネジメントの育成が不可欠だと考えました。ヘンリーの従業員は自ら学べる方が多いとはいえ、経営会議が期待するマネジメントの役割を部室長にしっかりと伝えなければ、組織として目指している姿には近づけないはずだからです。
ヘンリーの経営会議メンバーは知識創造企業や戦略の要諦などを読み合わせて議論の土台としていますが、この施策では知識創造企業のミドルアップダウンマネジメントを意識しました。ミドルマネジメントが機能するためには理想と現実世界の間に横たわる矛盾を解決するだけの情熱や裁量が必要になりますが、それを正しく活かすための仕組みを経営会議と管理本部とで整備してオンボーディング化しました。
ただ最初は前述の通りそもそも部室長専任が存在せず本部長が兼務していたので、まずは部室長を任命して権限委譲することの検討から始まりました。その過程で大き過ぎるstream-alignedチームを分割していますが、そのために必要なドメイン分割の難しさは以前の記事でも紹介していますのでここでは割愛します。
このオンボーディングとフォローアップが今年もっとも重要な施策です。また部室長と部室員のコミュニケーションはまだ手探りというか横断的な打ち手は存在しないので、1on1のやりかたとか心理的安全性の作り方とか失敗を奨励する文化についてとかは、これから進めていきます。
採用をドライブしていく
採用を進めるうえでの課題はいくつかあると思いますが、まず会社そのものが認知されていないこと、次に医療というドメインに抵抗感があること、そして何をやっているのか製品本部の実像が伝わりにくいことがあると考えています。いずれも体外的な情報発信を進めていくことが必要だと考えており、この技術ブログ、note、ならびに各種イベントでの情報発信を進めていきます。
採用はまさにみんなで実践するものですが、VPoEとしてはその実践を回し始めることをしっかりやろうと思っています。現在はコンスタントにブログを出すこと、発信したことのない人を無理なく巻き込んでいくことの2つに絞って活動しています。直近ではQAの方向けのイベントを企画しておりますので、関心をお持ちの方はぜひご参加いただければと思います。
行動指針の浸透を進める
行動指針をSlackでじゃんじゃかつぶやいたり、他の従業員の書き込みに行動指針絵文字で反応したりして、新しい行動指針あったわーというリマインドをかけていっています。また弊社には経営会議から情報を共有する仕組みはもちろん、社内でベストプラクティスやグッドトライを共有するDemodayや感謝を伝えるための #all-praise チャネルなどもありますので、それらを通じても行動指針を浸透させていきます。
製品本部全員と1on1をする
いろいろと施策を打ったところで完全はないので、こまめなコミュニケーションを続けてセーフティネットとすることが欠かせないと思っています。特に燃え尽きの発見や部室長のカバーは、直接話すことでしか実現できません。
私たちのエンジニアリング組織は既に40名近い規模の組織になっていますが、少なくても四半期に1度は一人ひとりと1on1をしていきます。
まとめ
3代目のVPoEとして「圧倒的に強い開発組織を作り上げる」ために、部室長オンボーディングや採用を、行動指針の浸透を心がけています。2025年下期においてもこれらを継続するとともに、より自律できる組織を作ったり評価制度を検討したりといった施策を打っていくつもりです。
私たち製品本部には中小病院の皆さんの課題解決のため、やりたいと考えていることがたくさんあります。今いる従業員みんなに活躍してもらうことも、ファンを増やして従業員となってもらうことも、どちらも実行してエンパワーメントフライホイールをくるくる回していきます。事業やチームに関心をお持ちの方は、ぜひ採用サイトも覗いていただけると嬉しいです。
医療×QAエンジニアの1年間振り返り#ホリスティックテスト
🩺 入社1年を振り返る
こんにちは、ヘンリーでQAエンジニアをしている tsukiG です。
気がつけば入社して1年が経ちました。
「そろそろ何か発信しないとな…」と思いつつ、ようやく筆を取りました。
医療というまったく新しい、そして難易度の高いドメインに飛び込んだことで、 正直、なかなかスムーズにはいかず、日々の調査・理解に多くの時間を要していました。
それでも、外来体験のリニューアルという大きな節目を迎えることができました。
ようやく、 「自分たちは何をしてきたのか」「なぜそれが必要だったのか」を、少しずつ言葉にできるようになってきた気がしています。
今回はこの1年を振り返りながら、 ヘンリーという医療スタートアップが、どのように品質と向き合っているのかをお伝えしたいと思います。
🕹️ 入社前
私はこれまで約15年間、QA/テストの世界でキャリアを積んできました。
とはいえ、基本は エンタメ業界。 ゲームやMVNO、音楽配信、広告など体験重視のB2Cに関わっていました。
そんな私が自ら選んだとはいえ、医療の世界へ。
当然、医療に関する知識や経験はゼロ。
分厚い診療報酬制度の本に恐れおののいた記憶も未だに鮮明です。
でもそれ以上にワクワクしていたんです。
「自分の考える品質ライフサイクルが実践できるかもしれない」と。
🔍 入社の決め手：ホリスティックテストの思想
私自身が理想とするのは「ホリスティックテスト（Holistic Testing）」です。
これは、Janet Gregoryが提唱している考え方で、 開発ライフサイクル全体にテスト活動を織り込み、“誰もがどこかの工程で品質に関与する”という文化を指していると私は解釈しています。
ヘンリーの面談でその萌芽を感じ、「この組織なら実践できるかもしれない」と思えたことが、入社の大きな決め手になりました。
🧠 実際どうだったの？
結論から言うと、ヘンリーはホリスティックテストの実践に非常に近い状態にありました。
たとえば、こんなシーンが見られました：
ドメインエキスパートがQAにロールチェンジし、卓越した現場力でテストをリード
エンジニアが自らE2Eテストを設計・実行
ビジネスサイドのメンバーが週次でリグレッションテストを実施
ドメインエキスパートがmablで自動テストを作成
代表の逆瀬川が自らテスト設計・実行を行う。QA meetupから積極的に学びを持ち帰る
入社直後の印象
ロールや所属に関係なく、社員全員が自然と品質に向き合っている。
この姿勢は、入社当初から強く印象に残っています。
そして、 時には 立ち止まり 工程を遡る そんな柔軟性も時折見ることができ、
まさにホリスティックテストというネーミング背景を体現していると感じました。
一方で、体系的なプロセスやテストに関する知識の整備という点では、まだ発展途上。
品質を“安定して”支える仕組みづくりには、多くの改善余地があると感じていました。
とはいえ、 体系的なテストの知識があるわけではなく、 プロセスや効率化、そして品質を安定して保つ仕組みにはまだ課題が依然多く残っていました。
🔧 入社後に取り組んだこと
そのような課題に対して、私は次のようなアクションを進めてきました。
🧱 テストプロセスの整備と運用
- テストが抜けたままリリースされる…を防ぐために
- リリースプランの運用ルールを明文化
- チーム内で共通認識を得るための場づくり
🧭 マインドマップを活用したテスト分析
- テスト分析にマインドマップを導入し、仕様理解を“構造化”して見える化
- 観点のレビュー性・網羅性を向上させる土台として活用
🏗️ ハイレベルテスト設計による探索的テストの促進
- 詳細手順に落とす前に「どの観点を検証するか？」を設計
- 必要に応じて詳細テストケースに展開し、探索と確認のバランスをとる
🌞 1年後の変化と実感
こうした取り組みの積み重ねにより、
プロダクト開発のライフサイクル全体における品質活動が、より組織的に進化してきたと感じています。
- Discover：顧客インタビュー、価値仮説の明確化
- Understand：BDDや実例マッピングの導入
- Build：開発中からビジネスチームによるフィードバック
- Deploy：横断的な探索的テスト、非機能テストの実施
- Release / Observe：Feature Flagを活用した段階的リリース、パフォーマンス監視
- Learn：仮説検証やOSTを取り入れた振り返り
品質はテストだけの話ではない
という実感を、より多くのメンバーが持てるようになってきたと思います。
🔭 これからの展望と「元気玉」的品質づくり
今後もホリスティックテストの実践を深めていきますが、
次のチャレンジとして以下のような領域に取り組んでいます：
- チームごとの最適な品質プラクティスの探索
- Agile Testing（4象限）との再接続
- BDD / 実例マッピングの実践
有名な漫画に「元気玉」という技があります。
多くの人から少しずつエネルギーを分けてもらい、それを集めて大きな力に変える必殺技です。 私が考えるホリスティックテストも、まさにこの「元気玉」に近いものだと思っています。
一人ひとりが少しずつ品質を意識し、行動に移すことで、結果として大きな品質が生まれる。
ただ、それだけでは足りません。 ホリスティックテストで本当に大切なのは、集めた“エネルギー”が人や工程をまたいでも減衰しないこと。 つまり、
品質に対する熱量が組織全体にスムーズに伝わる“伝導率の高さ”
が肝だと考えます。
QAはその“エネルギー”をうまく集めるだけでなく、 それがライフサイクル全体に途切れなく伝わり、自然に循環する仕組みをつくる存在でありたい。
そんな「元気玉の伝導路」のような品質の仕組みを、 これからも医療という難易度の高い現場で、粘り強く磨いていきたいと思います。
2025/07/30にヘンリー主催のQAイベント開催します。 その中でホリスティックテストの話をLTで話す予定なので、ご都合あえばぜひご参加ください
📮 最後まで読んでいただきありがとうございました！
「医療×QA」「ホリスティックテスト」などに興味がある方、ヘンリーに興味を持っていただいた方、一度お話ししましょう。
jobs.henry.jp
製品組織全体のHoneycomb活用事例
株式会社ヘンリーでオブザーバビリティをやっているsumirenです。
弊社ではトレースバックエンドにHoneycombを活用しています。いまや多くの方が日々の業務で使うようになり、プロダクトの運用になくてはならないものになりました。
この記事では、ヘンリーのメンバがHoneycombをどのように使っているか、Honeycombのアクティビティログから事例紹介します。
ヘンリーにとってのHoneycombの価値
トレースバックエンドというと、おそらく多くの方が1リクエストのツリーを可視化する用途を想像するかと思います。しかし、ヘンリーでHoneycombが定着しているのは、スパンの集計が非常に強力だからだと筆者は考えています。
この記事を通じて、ログの集計やメトリクスではなく、スパンを探索的に集計できることの価値の大きさや面白さが伝われば幸いです。
事例1. ある機能を各テナントのユーザーが何名くらいリクエストしているか集計する
id:horsewinの利用ログを参考にしています。
マイクロサービスAについて、目玉となる新機能をリリースしたようです。特定のアクター向けの機能であり、テナント別にも機能のオンオフをしています。各テナントのどれくらいのユーザーがこのエンドポイントを利用しているか確認することで、リリースがうまくいって使ってもらえているかを確かめることができます。
Honeycombではこうした集計は簡単です。WHEREで特定マイクロサービスの特定エンドポイントに絞ったうえで、テナント別にGROUP BYし、ユーザーIDでCOUNT_DISTINCTします（下図）。
同じことをアプリケーションメトリクス で実現するには、エンドポイントやユーザー ID、テナント ID などの属性ごとにメトリクスを分割・生成できるようあらかじめ定義しておく必要があります。ここで言う属性を一般にディメンションと呼びます。しかし、こうしたディメンションを含むメトリクスが都合よく収集されていることはそう多くありません。
Honeycombではインデックスなどの設定なしで、スパンに含まれる全ての項目を集計対象にできます。そのため、テナントを絞ってGraphQLオペレーションごとのレイテンシと実行数をカウントするなど、アイデアとニーズ次第で様々な軸でリクエストを集計することができます。
事例2. 問題のあるDBクエリがどのエンドポイントから呼ばれたときに遅いか集計する
id:nabeopの利用ログを参考にしています。
あるクエリでスロークエリが発生していたようです。一方で、いつも遅いわけでないため、どうやらクエリの使われ方に依存していそうです。Query InsightsなどマネージドDB側でわかるのは普通ここまでです。
トレースバックエンドでエンドポイントごとにクエリを集計することで、問題のあるエンドポイントを絞り込むことができます。
Honeycombでは、こうしたユースケースのために、「トレースとのJOIN」のような集計ができます。この例は、「db.statementを持つスパンを、そのルートにあたるスパンのgraphql.operation.nameでGROUP BYする」といった内容になっています（下図）。
集計結果を見ると、ListPatientSummariesというエンドポイントから使われたときだけこのクエリが遅いことがわかります（下図）。
あとは当該エンドポイントのコードを読んでもいいですし、さらに分母を絞って、次の事例のように異常検知を利用してもよいでしょう。
事例3. 異常検知で遅いリクエストの属性を絞り込む
id:giiita22の利用ログを参考にしています。
集計から洞察を得るには、異常値を示すメトリクスと相関のあるディメンションを特定することが重要です。例えば、前の例では「DB クエリの遅さ」という異常メトリクスと、「エンドポイント名」というディメンションの相関を検証し、その結果、特定エンドポイントだけが遅いと判明しましす。ここで、どのディメンションに着目するかという仮説の立案自体を自動化できれば、さらに効率的です。
さて、ある機能について、顧客から応答が遅いという問い合わせを受けたようです。過去のメンバーの記事にもあるとおり、マイクロサービスのモジュラモノリス移行といったアーキテクチャ的な変更や、大規模なリニューアルもあり、モジュラモノリスが怪しいのはわかっていました。
ヒートマップを見てみると、時間帯によらずリクエストの応答時間にばらつきがあることがわかります（下図）。
ここで、ディメンションをあれこれと入れてみるかわりに、異常検知を実行して、2秒以下のものと2秒以上のものでどのような属性の違いがあるかを調べていました。「EncounterTemplatesQuery」のエンドポイント（GraphQLオペレーション）が、異常な集合において76%を占めていることがわかります（下図）。これで、インフラ起因ではなくアプリ起因のようだということがわかりました。
さらに、ここから分母を絞り込んでもう一度集計と異常検知をしています。問題のあるエンドポイントだけの集計結果を見ると、必ずしもそのエンドポイントが常に遅いとは言えなさそうで、データに依存していそうです（下図）。ここでまた異常検知の出番です。
こうして分母を絞り込んで異常検知をすることで、無関係な分母と属性値が減るため、より異常なものと正常なものの差がクリアに見えるようになります。この例では、特定のparentFolderIdが指定されている場合は明らかに異常側に入る割合が多くなっています（下図）。ただし、それでも8%と少ないため、おそらくnullの場合も遅いのでしょう。この情報と、遅いトレースの確認により、DataLoader周りの実装に問題があることがわかったようです。
まとめ
ヘンリーでは製品組織全体でHoneycombを日々使いこなしています。カスタマーサクセスの方がアクティブユーザーを計測するのに利用したり、正式リリース前から使用していることもログからわかっています。
また、用途としては、単にトレース1つ1つを見るだけでなく、集計や全体の分析が大きく役立っています。障害や問題に対する仮説の検証も即座にデータで行うことができ、異常検知で経験や勘といったアートに頼らない仮説立案まで進めています。
GraphQLオペレーション名やリクエストボディ（マスキング含む）などの手動計装は、主に筆者が実装しました。他にもフィーチャーフラグやレスポンスのサイズなど豊富な計装があります。事例を踏まえると、手動計装がいかに強力か理解できるのではないでしょうか。スパンに1つ属性を足すことは、問題分析の手札を1つ増やすことと全く同義だからです。ヘンリーでは、機能個別のドメインロジックに対する手動計装も進めています。
Honeycombを導入した直後は、本当に組織に浸透するか不安もありましたが、この記事を書きながらヘンリーのメンバが日々大量のクエリを投げているログを見て、杞憂だったと安心しています。ご興味がある方はぜひカジュアルに弊社メンバとお話しましょう。
