ヘンリーではクラウド基盤の移行プロジェクトを開始しています

株式会社ヘンリーで SRE をやっている id:nabeop です。

今回は SRE チームが中心になって Henry のクラウド基盤を Google Cloud から AWS に移行しようとしているプロジェクトについて紹介します。

なぜ、クラウド基盤を移行するのか?

レセコン一体型電子カルテの Henry は開発当初からクラウド基盤として Google Cloud の Cloud Run や Cloud SQL を使っていました。Henry の開発当初はインフラ担当のエンジニアがいない状態でも少ない人数で最速でサービスを開発する必要があったため、インフラ部分が抽象化されている Google Cloud を選択するのはごく自然な選択だったと思います。

Henry の開発が進むにつれて、開発当初はクリニックを想定していましたが、回復期リハビリテーション病院や急性期のような複雑な機能が必要な医療機関での利用も想定されるようになりました。このように開発開始当初に想定していたよりも複雑な機能が求められつつ、高い信頼性が求められる医療機関さんへの導入を見据え、コンテナの実行基盤を Cloud Run から GKE など抽象化レベルが低く、我々がより細かいコントロールが可能なサービスへの移行についても検討はしました。しかし、Henry のサービス特性などを総合的に考えた結果、クラウド基盤として AWS が適切であると判断しました。

また、急性期の医療機関さんのように24時間/365日で高い稼働レベルを求められる医療機関さんが使い始めるまえにクラウド基盤そのものの移行というリスクの高いプロジェクトを完了しておきたいという背景もありました。

移行プロジェクトの現在地

Henry のアプリケーション部分は Docker コンテナで稼働しているため、クラウド基盤を変更しても全く動かないということはありません。しかし、Google Cloud と AWS では異なる部分もあるため移行を本格的に開始するにあたり下記のような検討を実施しました。

• Google Cloud で構築している内容と同等の構成を AWS で実現するにあたっての懸念点の整理と大まかなコストの試算
• PoC として Henry の最低限の機能を AWS 上で構築し、上記の懸念点以外に大きな見逃しがないかの確認

現在は、PoC 検証によって大きな見逃しはないものの、Google Cloud と AWS での機能差異や AWS では実現が難しい機能が存在することは確認できたので、これらのギャップを埋めるためのアプローチや不確実性の解消のための検証を実施しています。具体的には以下のような検証やアプローチの検討があります。

• Google Cloud (Cloud SQL for PostgreSQL) から AWS (Aurora for PostgreSQL) データマイグレーション時の手順と想定されるダウンタイムの予想
• アプリケーションの CI/CD パイプラインの作り直し
• AWS での置き換えが難しい機能を Google Cloud で維持するための手段の検討
• アプリケーションの移行手順の検討
• ECS サービスの構成の検討

今は上記の内容のうち、予想される不確実性のうちリスクが高いものや不確実性が大きいものを優先して検証しています。

Henry 本体の開発スケジュールとの兼ね合いはありますが、これらの課題を順次解決していき来年中には AWS への移行を完了させる見込みです。

we are hiring!!!

稼働済みのサービスのほぼ全ての機能でクラウドサービスの移行をするというのは今のタイミングでしかできない珍しい取り組みだと思います。また、AWS に移行したあとにも高い信頼性が求められる医療機関さんにも安心して使っていただけるように DR やセキュリティ周りの強化に踏み込んでいく予定です。

AWS 移行プロジェクトだけでなく、高い信頼性が求められる医療機関さんに安心してお使いいただけるシステムにしていくには、さまざまな課題を解決する必要があります。ヘンリーではこれらの課題を一緒に解決してくれる仲間を募集しています。

ヘンリーでの SRE の取り組みに興味をもたられたら、ぜひ気軽にカジュアル面談などでご説明させていただきたいです。

Cloud Operator Days Tokyo 2025 に参加しました

株式会社ヘンリーで SRE をやっている id:nabeop です。

2025年9月5日にクロージングイベントが開催され、Cloud Operator Days Tokyo 2025 が終了しました。会社としての参加は今回が初めてでしたが、クロージングイベントではたくさんのかたに弊社ブースを訪れていただき、とても有意義なイベントでした。運営事務局のみなさま、素敵なイベントを開催していただきありがとうございました。

今回はブースの様子や弊社から登壇した内容の紹介などをご紹介できればと思います。

「製品支援部に作ってもらったら嬉しいな♪」という、製品と営業でともに作り上げる営み

こんにちは、株式会社ヘンリーのVP of Engineeringを務めている戸田（id:eller）です。このブログではヘンリーでどのようなEngineeringが行われているのかをお伝えしたく記事を執筆してきましたが、今回は趣旨を変えてインタビュー記事をお送りします！

今回のテーマは今年の4月に発足した、隔週で行われている「製品支援部に作ってもらったら嬉しいな♪」という会議体です。製品支援部は「あなたの検査がカルテに書かれてから結果が返ってくるまでに裏側のシステムでは何が起きているのか」を書いた坂口がリードする部であり、電子カルテと外部システムとの連携部分や、導入時の設定や開発を実施しています。

この会議体では製品支援部が所属する製品部門と導入を担う営業部門とが協力して弊社サービスの導入の改善を継続的に行っており、すでに多くのアウトカムを生み出しています。しかも弊社の心得である「明るくさわやか、前向きに」を実践しているなと思えるほがらかな雰囲気で、いま会社の行動指針を率先して体現していると言えるでしょう。

今回はこの会議体の発起人となった共同創業者の林さんに立ち上げ当初の話を聞き、その後で会議体に参加している梅本さん、菊池さん、青柳さんに心がけていることなどを聞きました。読者の皆さんに弊社の雰囲気や大切にしていることが伝われば幸いです。

発起人インタビュー

――この会議体を発足したねらいについて伺いたいです。導入の改善そのものは以前から継続的に行っていましたが、改めて会議体を立ち上げたのはなぜですか。

林：確かにそれっぽい会議はありました。改善要望を出してNotionのデータベースでバックログを管理していたのですが、既に巨大で見えにくく運用が回っているとは思えませんでした。

そこで本来やりたいことに集中するべくバックログをとにかくシンプルにして、製品部門と営業部門が心から1番やりたいと考えていることがすぐにわかるようにしました。何に取り組んでいて、どういう課題感があるのか、が明確であることが大切だと考えたからです。だから会議体の名前もやることを明確に示すものに変えました。

導入の改善には製品支援部の協力が欠かせませんが、製品支援部の余剰時間を作るには導入における彼らの工数を減らすことが必要です。だから導入において製品支援部にどんな差し込みが発生しているのかがお互いに見えるようになったら営業部門側からも差し込みを減らそうという動きが出るだろうという期待がありましたし、初回では梅本の時間をどうやって増やすかという問い掛けをしました。

逆に言えば、製品支援部の余剰ができて導入が改善したら、また営業部門で完結させられる導入が増えて製品支援部の余剰ができるはずです。そうした改善サイクルが自然と回っていく会議体にしたいと考えました。

――半年弱ほど運用して、現状はどうお考えですか。

導入エキスパートが楽しんでこの「製品支援部に作ってもらったら嬉しいな♪」に参加しているのが目に見えていて、すごくいいと思っています。

弊社レセコン一体型クラウド電子カルテ「Henry」の開発や導入においては、どうしても喜びを得るまでのサイクルが長くなる傾向にあります。導入には4ヶ月から半年はかかりますし、開発も要求仕様の発見から実際に製品をお客様にお届けするまでは数ヶ月かけています。

その中で2週間という短い時間で「決めた、やってみた、改善した」のサイクルが回り、製品支援部と営業部門がお互いに感謝しあって喜べる関係になれたこと。参加している4人が純粋に「バックログの一番上にある、この課題を解決するんだ」と握れるようになったことが楽しんで運用できている大きな理由なんじゃないでしょうか。

参加者インタビュー

――こんにちは。まず自己紹介をお願いできますか。

梅本：製品支援部の梅本です。ヘンリーには2024年9月に入社して、外部連携機能やその設定などの実装をしています。よろしくお願いします。

菊池：導入エキスパートの菊池です。この取り組みのおかげで設定画面がめちゃくちゃ充実して嬉しいです。これからオンライン資格確認周りの機能が増えるので、楽しみにしています。

青柳：青柳です。カスタマーサポートをしています。カスタマーサポートも製品支援部との繋がりが強く、「製品支援部に作ってもらったら嬉しいな♪」を通じていろいろな実装を拾ってもらえてただただありがたいと思っています。

――Demodayなどで「製品支援部に作ってもらったら嬉しいな♪」の成果を聞いていると、ペインが着実に解消されている印象を受けます。次々と課題を解決する秘訣はどこにあるのでしょうか。

菊池：まず「こういう運用がしたい」と思ったときにすぐアプローチできる場所ができたのが大きいと思います。導入周りには多くの設定があるんですが、それをどう組み合わせて設定したら何が実現できるのかは今ですらわからないと感じることがあるんです。ですから「こういう事ができるといいな」という要求ベースで議論できる場が生まれて、それならこうしたらできますよとすぐ答えてもらえたり、調査や実装に繋げてもらえたりしてとても助かっています。

図１ 導入エキスパートの菊池さん。ご自身も生成AIを調査に活用するなど、挑戦を続けています。

青柳：私たちは要望とか仕様とかを整理しないまま「こういう事ができるといいな」を喋っちゃうんですよね。それは営業部門の改善点だしもっと精査したほうがいいこともあるんですが、梅本さんが丁寧に紐解いてくれるから大きな問題になってない。

梅本：僕は何度も実際に導入プロセスに入ってますから、アレほしいよね〜みたいなハイコンテキストな話ができるのはあるかもしれませんね。

ちょっと強調しておきたいんですが、営業部門の皆さんからもたくさん僕に歩み寄りをしてくれています。導入時にお客様に記入いただいているシートに改善点がないか、たとえばここはこうするべきか？みたいな提案を持ってきてくれたり。あと先日は管理画面にメニューが増えてきて分かりづらくなっているので整理しようという提案が青柳さんからあり、それがデザイナーの方への相談に繋がったりしています。

図２ 導入支援部の梅本さん。導入プロセスで活躍する機能を多数実装してきました。

――導入プロセスにおける設定はどのように行われ、どんな課題があるのですか。

菊池：まずは顧客や私たちが設定に必要な情報をスプレッドシートにまとめるところから始まります。で、このシートをもとに私たちや製品支援部で設定を行うわけです。

このシートに記入するのが、まず難しいんですよね。どんな設定をしたらどうHenryに反映されるのかが、なかなか想像できない。理想的には顧客がいろんな設定を気軽に試せる、ベストな設定を試行錯誤できる状況だと思いますが、このシートを使ったやり方だとこれが難しいんです。

梅本：たとえば看護計画だとこういうシートを使っていました。設定画面がなかったときはシートに看護問題を埋めて、それぞれの看護問題に使うテンプレートデータを作ってJSON化し、それらのJSONファイルに対してURLを払い出してシートに記入してもらうところまでを導入の皆さんにお願いしていました。製品支援部側ではこのシートをもとにJSONファイルをダウンロードして作業していたわけです。

図３ 導入用シートの一例。看護問題に対するテンプレートデータ（URL）を記入する。

菊池：こういう設定シートを埋めるのに、最悪ケースで1ヶ月とかかかっていたんです。またシートの入力内容に不備があって差し戻されたけど、その理由がわかりにくいということもありました。

梅本：いまは設定画面があって、WYSIWYG エディタも付いてるので、設定画面でもろもろいじれて導入部だけで作業がほぼ完結するようになっています。

図４ 作成した看護計画の設定画面。必要な作業がこのページで完結する。

図５ 項目の並べ替えも、より直感的にできるようになった。

菊池：そうなんですよね。こういう設定画面を作ったり、その画面を顧客が使えるように整えたりといった相談がライトにできるようになったんです。コミュニケーションの敷居がとても下がって助かってます。

――いまヘンリーはより多くの病院様、より複雑な運用をされる病院様に価値をお届けするべく挑戦しています。やりたいことが本当にたくさんあるんじゃないかと思いますが、優先度はどうやってつけているのでしょうか。

菊池：隔週で同期的に話し合うときに議論していますね。けっこうちゃんとやれているなと思っています。

梅本：ですね。「これ次に欲しいよね〜」という3者の立場からのコメントを集約して決める感じで。

菊池：隔週というのがちょうど良いのかもしれません。実装がちゃんと進んで次に行けるし、悩み事がぱっと解決する感覚があって楽しいです。

――こうして皆さんを見ていると、本当に楽しく仕事をされているんだなと肌で感じます。明るく前向きにやってこれた理由は何かあるのでしょうか。

青柳：先ほどの話と繋がってきますが、特に整理していない生煮えのアイデアを議論できるのがまずあると思います。私たちは夢を喋ってるだけというか（笑）

あとはバックログに小さな夢を並べることを大切にしていますね。夢が複雑すぎないからある程度の実装によって手が届くし、課題を持ってくる人がそれが解決されることに期待感をしっかり持てているんです。

図６ カスタマーサポートの青柳さん。顧客のために貢献する方法を検討しているときにこの会議体を見つけ、手を挙げて参加しました。

菊池：単純に楽しいですよね。楽しいから導入エキスパートのみんなに「製品支援部の負担を減らすとひとつ設定画面が増えるかもしれないから、みんなで工夫しよう」って話していますし、それが功を奏して製品支援部からのアウトプットが増えたり私たちからのフィードバックに繋がったりしたらいいなと思います。

梅本：僕は導入やカスタマーサポートといった営業本部の皆さんとの関係性が築けたことが大きいと思っています。普段からコミュニケーションをしてきたベースの蓄積があるから「製品支援部に作ってもらったら嬉しいな♪」が回ってる。

実は僕は前職で今ヘンリーの役員を務めている萩原さんと萩原さんの奥さんと仕事をする機会があって、そのときに奥さんにわかりやすく説明してうまくいったという成功体験があるんです。その経験を活かして、相談してくれてありがとうと伝えるとか、サービスの内部構造に明るくない人にも伝わるように理由や仕組みをわかりやすく伝えるようにしています。

青柳：確かに製品支援部のみなさんは気軽に相談できるようにしてくれたり、実装するときもデザインをいくつか持ってきてくれたりして、一緒に作ってくれている感じがありますね。

――自分はすぐ相手のコミュニケーションにケチをつけがちなので、お話を聞いて改めたいと思いました（笑）本日はありがとうございました。

病院理事長訪問でわかった「理想駆動」のおもしろさ

こんにちは！株式会社ヘンリーで働くプロダクトマネージャーの椙村です。今回、電子カルテ・レセコンシステムの Henry を導入いただいた病院の理事長とお話する機会があり、ヘンリーが掲げる基本原則 "理想駆動" が面白いぞ、ヘンリーに入った意味ってこれかもしれないな、という思いを得たので、そのことについて書きたいと思います。少し長くなりますが、何卒お付き合いください！

はじめに

2024年11月にヘンリーに入社して、10ヶ月ほど経ちます。ヘンリーは、病院向けにクラウドの電子カルテ・レセコンを開発・提供している会社です。作っているのはソフトウェアですが、本当に作りたいのは、持続可能で価値の高い地域医療の理想のあり方です。そのためにも何層にも重なる構造的な難題をどう突破するか、一丸となって取り組んでいます。

もともと10年ほど C 向けのサービスのプロダクトマネージャーとして働いてきて、今回初めて B 向けかつ医療ドメインにチャレンジしています。ノリと勢いで、楽しそうという直感をたよりに飛び込んだところ、わからないことにわからないことを掛け合わせて煮詰めたようなわからなさに揉まれながら半年を過ごし、なんとかドメインの概観もつかめてきて、組織文化にも馴染んできました。

その間、現場の感覚を知る機会として何度か病院訪問もさせていただきました。その上で今後より深い課題理解から提案ができるようになるために、もっと病院の方の思想に触れてみたいと CEO 逆瀬川に相談したところ、次の週には中国地方のとある病院の理事長を訪問する機会をいただきました。

理事長は何を話したか

今回訪問した理事長は、これまでお父様やご兄弟が理事長・院長を務める中で、ある事情により数年前に理事長に就任をされた方でした。医師ではなく事務方としてこれまで病院運営に携わってこられ、理事長としても独自の視点で経営課題に向き合い、組織改革に取り組んでこられました。その改革の一環として、今年ヘンリーを導入いただき、ありがたいことに多大な期待とともに非常に熱い思いを何度も語っていただいていたという経緯もあり、全社員に対して公開でメッセージを頂戴するため逆瀬川とともに訪問しました。

印象的な言葉をいくつか紹介させてください！

創業の理念以外は全部変えていい！

理事長自身、突如今の役割を担うことになった後、どんな病院づくりをしていくか？を考える上で、一番拠り所にしたのが病院の理念だったそうです。（職員100人規模の病院では珍しい）多面的な人事評価制度の策定をはじめとして、理事長自ら院長や医師など優秀な人材の積極的な採用に取り組み、さらには今回の電子カルテ導入を推し進めるなど、強い組織と医療を作るためにあらゆる課題解決に率先して取り組まれています。松下幸之助も同じことを語ったようですが、やりきってる人の説得力は強い！

客観的な時間（クロノス時間）の効率性を高めるだけでなく、主観的な時間（カイロス時間）の価値を最大化できる、使う人が熱中できるようなソフトウェアを作ろう！

C 向けのプロダクトを作ってきたバックグラウンドもあり、首がもげるほどうなずきました。人々の心に火をつけるプロダクトを作ろう！

社長だけでなく社員も含めて、目標を実現できると本気で信じている組織だけが、高い目標を実現できる！

ヘンリーは、ノーベル平和賞の受賞を目標の一つとして掲げています。その点に興味を持っていただき、実現プランについて逆瀬川を問い詰めてる時に出た言葉です。

自分にどんな意味があったのか

今回自社の製品を導入いただいた病院の経営トップのお話を伺い、自分たちが向き合う課題の重みと情熱に触れられたのは最大の収穫です。ありがとうございました。

もう一つ付け加えると、その関わりを通じてヘンリーの "理想駆動" という基本原則の面白さに気づくことができました。地域医療という大きなものにインパクトある変化を生み出そうとすると、自社の組織だけでは正直変えられるものはそう多くはありません。我々はソフトウェアやサービスを提供しますが、実際に医療を提供するのは医療機関の皆様です。まだまだ未熟な Henry をより良いソフトウェアやサービスに育てながら、同じ理想に共感する人を社外にも増やし、変化のさざ波を大きくしていくことが重要です。

理事長が語ったことを通じて、私は Henry というプロダクトが、機能だけでなくその理想をもって選んでいただき、応援いただけていることを知りました。理想駆動は、自分たちがどのように問題に向き合うか？ということだけでなく、社外の人々をどう巻き込んで大きな変化を生み出すかを示す言葉でもあったわけです。

他の社員たちにとっても影響の大きいセッションだったようで、9割近い社員がリアルタイムでこの話を視聴し、社内のワイガヤ Channel は非常に盛り上がっていました。理想駆動な営みは、さらなる理想駆動な何かにつながっていきそうです。

自分はこれからどうするか

プロダクトマネージャーとして Henry というプロダクトを育てていくことは当然のミッションです。そのミッションの中で、理想駆動をどこまでやり切れるかは重要なチャレンジです。今回のような病院経営者だけでなく、現場のスタッフの皆様との関わりを通じて、より効率性や質の高い業務を追求するために理想を描き、医療現場にとって価値の高い運用フローを考案することこそ、その中核と言えます。この辺りのチャレンジについてはまた別の機会に紹介させてください。

加えて、今回のセッションをきっかけに、組織としてのヘンリーを育てていくことも重要なミッションと感じるようになりました。理事長が理想の医療のあり方を実現するために組織のあり方に目を向けたのと同じように、我々自身も望ましいあり方があるはずです。ヘンリーという組織は、変化を生み出す一つのシステムとして見ることができます。我々は、そのシステムに、理想駆動を中核的な設計思想として組み込もうとしています。今回の理事長とのお話を通じて、理想駆動という考え方は、組織の外とも繋がりながら、システム全体が持つエネルギーを大きくし、変化を大きくしていける可能性があることを学びました。プロダクトマネージャーとして、扱うプロダクトだけでなく、このシステムにどんな影響を与えられるか？今後のヘンリーでの時間に、とてもワクワクする機会になりました。

---

ヘンリーでは医療業界の課題に向き合い、電子カルテ・レセコンの開発に取り組むソフトウェアエンジニアを大大大募集しています。 今回の記事の感想など、お気軽にカジュアル面談でお話ししましょう！！！！

株式会社ヘンリー 採用情報

Kotlin Fest 2025 に「ことりスポンサー」として参加します

ヘンリーで SRE をやっています id:nabeop です。

弊社では昨年に引き続き[^1] Kotlin Fest 2025 でも「ことりスポンサー」として参加します。また、弊社から筆者がkotlin-lsp の開発開始に触発されて、Emacs で Kotlin 開発に挑戦した記録としてショートトラックで登壇します。

Cloud Operator Days Tokyo 2025 に参加しています

ヘンリーで 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な当日資料を公開します。

オープニング

オープニング司会のodashoさん

会場提供をしていただいたFinatextの五十嵐さん

乾杯！！(私)

LTの様子

実践！ホリスティックテスティング

ヘンリー社 tsukiGさん

tsukiGさんの発表の様子

サマリ

• ヘンリーではプロジェクトライフサイクルを定義して、開発プロセスを回している。

• 品質活動の4分類をマッピング！

• 特徴的な活動

  • スリーアミーゴスの拡張として、ビジネスチームを召喚。小さな開発を実践してフィードバックを！
  • BDDの実践！
  • 探索的テストと、ユーザーの価値が届くかどうかの検証に重きをおいた打鍵会
  • 病院に寄り添うリリース戦略として、ユーザーへのでも環境の展開や、エンジニアでの現地での素早い対応
  • 仲間募集しています！

資料

speakerdeck.com

ホリスティックテスティングの右側も大切にする

10X社 ブロッコリーさん

ブロッコリーさんの発表の様子

サマリ

• ホリスティックテスティングは、どこでもテストするよって話
• Sift-leftはブロッコリーさんの過去の登壇資料を読んでね
• Sift-rightを定量と定性から[はか]る
• 定量的に[はか]る
  • 事業を理解して、データをボトルネックを測ることが大事
  • 10Xの例 配達枠と注文のバランスや、小売のかご単価の利益の構造のデータ見てボトルネックを分析しよう
• 定性的に[はか]る
  • 行動から品質を察[はか]る
• 仲間募集しています！

資料

speakerdeck.com

入り口から考えるソフトウェアテストエンジニアのキャリア ~ 別々のスタート地点と、それを乗り越える学びの力 ~

shimashima35さん

shimashima35さんの発表の様子

サマリ

• 理想のキャリアパスとして、まずはジュニアソフトエンジニアとして広く浅く学ぶ
• が、最近は、スペシャリストとしてデベロッパーとテストエンジニアが入口から分かれてしまっている？
• shimashimaさんの場合は、SIから入ったので一通り経験することが当たり前だったが、専門性がある人は周りにいたわけではなかった
• ソフトエンジニアのSWEBOK V4の領域体系を見てコアスキルを見てみるとやることが多い
• 学ぶことが多いし入口で学んでいなかったら、勉強していこう！学習環境は楽になっているので勉強しよう！
• LLMと一緒にWebアプリを一通り作ってみて、困ったことをLLMに聞くのが良い。UI以外のテストの幅も拡がる
• まずは、自分の手を動かしましょう！

資料

speakerdeck.com

パネルディスカッション

パネルディスカッションの様子

また、イベントの終盤では登壇者が再集合し、会場からの質問への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 以外でもヘンリーの理想を実現するために手伝ってくれる仲間を募集しています。弊社に興味のある方はぜひカジュアル面談させてください。