ヘンリーで SRE をやっている 
id:nabeop です。
これは株式会社ヘンリー Advent Calendar 2025 (シーズン1) の2日目の記事です。昨日は VPoP (VP of Product) の縣 (
id:agtn / @agatan) による事業戦略は技術戦略に影響を与えるが、技術戦略もまた事業戦略に影響を与えるべきでした。
今年の SRE チームの大きなトピックとしてクラウド基盤を Google Cloud から AWS に移設するプロジェクトが進んでいます。プロジェクト自体は去年から始まっており、粛々と進めていたのですが、ある程度の目処が立ってきたので今年の10月に外部向けにもプロジェクトの存在を公開しました。
カジュアル面談やイベントなどで AWS 移設について言及することがあったのですが、一番質問されたのは「なぜ、クラウド基盤の移設をするのか?」という内容でした。そこで、今回は Google Cloud を選択した経緯と、クラウド基盤の移設を決定した背景について説明したいと思います。
続きを読むはじめまして。@ryugen04です。 2025年11月に株式会社ヘンリーに入社しました。
経歴を一言でいうと、「薬剤師免許を持っているけど、薬局で働いたことがないエンジニア」です。薬学部の研究室で医療情報学を学ぶ中でプログラミングに出会い、ITコンサルティング企業で4年、医療系を含む様々なプロジェクトを経験しました。
なぜ大企業からスタートアップへ移ったのか。入社1ヶ月の今、実際に働いてみての所感もあわせて書いてみます。
四苦八苦して大学を卒業したあとに前職のITコンサルティング企業には新卒から4年間在籍し、ありがたいことにシニアランクまで昇進しました。ウォーターフォールもアジャイルも経験し、医療系プロジェクトでは診療報酬に関する開発にも携わらせていただきました。
会社規模が大きかったこともあり、基幹系システムや官公庁系案件、小規模なBtoC案件など、様々なインダストリーに関われたのも良い経験でした。 リーダー的な役割も任せてもらい、マネジメントの基礎を学んだり、スクラムマスターの真似事のような経験もさせてもらいました。
様々な経験をさせてもらった一方、大企業や受託開発に近しい領域ゆえの課題も感じていました。
これらは会社の良し悪しではなくトレードオフな側面だとは思います。
他に組織面としても、私が志す医療やITの分野に全員が同じ方向を向いているわけではない、といったことに個人的に考えることがありました。
こうした経験を経て、次のような環境を求めるようになりました。
また、個人的な年齢も30手前だったことも意識しました。挑戦をするなら今だろう、と。
転職では医療×ITという軸で働こう、と考え、いくつかの企業を受けました。医療系テック企業にはアンテナを貼っていたので、ヘンリーのこと自体はもともと知ってはいました。 その中で、ヘンリーを選んだ理由は主に3つあります。
「目標の大きさ」としては、ヘンリーは「ノーベル平和賞」を企業理念の中間ゴールとして掲げています。大きな目標ですが、だから良い。 自分のやりたいことである、医療に大きなインパクトを与えるプロダクト開発というところにこの上なくマッチしていますし、持続可能な医療体制という社会課題に本気で取り組む会社の姿勢の表れであり、かつ全員がこの目標の方向を向いているということに大きな価値を感じました。
「アウトプット文化」としては、connpassイベントの開催や、技術書典への出展をしていることに大きな魅力を感じました。 転職当時では以下のような本を2冊出しており、かつそれぞれ100p超という結構なボリュームがあったりします。 techbookfest.org プロダクトの内情をここまで積極的に発信できる、またこのボリュームは個人の気まぐれや献身だけでなく、チームとしてアウトプットを推奨や協力している姿勢を感じました。
「病院見学での印象」としては、選考が進んだ内定承諾前に提案いただき、病院見学をさせてもらいました。印象的だったのは、ヘンリーの社員が現場に複数人入り込み、医療職の方々とラフにコミュニケーションを取っていたことです。電子カルテやレセコンの導入は一般的には経営のトップダウンで決まり、現場的にはnot welcome。もう少し冷たい距離感や殺伐とした雰囲気をイメージしていたので、実際に医療現場を一緒に支えているような風景に好感を覚えました。
丁寧な採用に力を入れていること、病院との距離が近いこと。選考を通じてこれを肌で感じられたことも大きかったです。
スタートアップなので、正直入社初日から修羅場に放り込まれるくらいの覚悟はしていました。 実際はオンボーディングがしっかり設計されていて、良い意味で意外でした。Notionに共通タスクリストやドキュメントがまとまっていて、全社的なキャッチアップがしやすくなっています。スタートアップ特有の「組織が崩壊寸前のカオス」といった雰囲気は正直あまりなく、組織設計がしっかりされているぶん安定感があります。
技術面では、Kotlinがバックエンドのメインであること、複数のサーバー構成であることなど、前職のJavaメインの環境とは異なる部分のキャッチアップと並行しながらタスクを進めています。コードベースはエンジニアのレベルが高く、いわゆる「神クラス」のような負債は見当たりません。GraphQLなどモダンな技術スタックを使っていることも魅力です。前職から言語的にはすべて新しいものへのチャレンジとなっているため、キャッチアップしながら日々頑張っています。
ドメイン知識については、前職で診療報酬に関わっていた経験が思った以上に活きています。薬学部で学んだ医療制度の知識や、医療現場の肌感覚といった部分も、キャッチアップのスピードにプラスしている実感があります。
もちろんわからないことは多いですが、聞けば親切に教えてもらえます。この領域は医療現場の慣習や、厚生労働省などを主体とした国としてのシステム、歴史や制度的な複雑性があり、はじめて取り組む方には想像以上かもしれません。ただ、それをどう扱うかがエンジニアリングの腕の見せ所なのではと思っています。やりがいはありますね。
現在は製品開発本部に所属し、スクラム開発のエンジニアを担当しています。Henryの機能領域として大きく電子カルテ、レセコン、オーダー機能などがありますが、その中のレセコンのサブ領域ですね。
新規画面機能のフロントエンドからバックエンドまでの開発に関われています。
チームで印象的なのは、1週間サイクルでスクラムが回っていること。そしてドメインエキスパート、マネージャー、デザイナー、エンジニアなどなどがそれぞれ自主的に大きくアウトプットしていることです。 開発中はドメインエキスパートと要件を確認しあい、本番環境へのデリバリー前にはリリースノートの書き方やリリースタイミングまで関係する社内メンバーと相談してチームとしてオーナーシップをもって決めています。これは前職では経験できなかったことで、まさに求めていた環境だと感じています。 このスピード感と自主性は、レベルの高い人材が揃っていないと成り立たないと思いました。
入社1ヶ月、まだまだわからないことやサポートが必要なことも正直多いです。しかし、求めていた環境ではあると感じています。プロダクトへのオーナーシップ、技術的な挑戦と成長、医療への貢献。これからどう成長していけるか、楽しみです。
ヘンリーでは一緒に働く仲間を募集しています。この記事を読んで少しでも興味を持っていただけたら、ぜひ気軽にカジュアル面談の連絡をしてください。
こんにちは。ヘンリーで VPoP (VP of Product) をしている agatan です。 2025年の10月から、これまでのエンジニアとしての役割に加え、VP of Product & 製品部門長という役割を担うことになりました。
これまではテックリードやアーキテクトなど、エンジニアとして、ヘンリーの複雑で巨大なドメイン（レセコン・電子カルテ）に技術面からアプローチしてきました。 VPoPという立場になり、プロダクトと事業をより俯瞰して見る中で、自分の中にあった「ある種の先入観」に気づくことができました。 今日はその言語化と、これからのヘンリーの開発組織が目指す「技術と事業の関係性」について書いてみようと思います。
この記事は
の1日目の記事です！
先日のアーキテクチャカンファレンスでもお話ししましたが、私たちが向き合っているドメインは非常に複雑で、ソフトウェアの設計と組織の設計は、そのドメインの性質に応じて考える必要があります。
これまで私は、「技術戦略」つまり「ある事業やプロダクトをどのような作り方で作るか」を決める際、事業戦略を一種の「前提条件（Input）」として捉えていました。 「事業として何を達成したいか（What）」がまずありきで、それを実現するための最適解として「どう作るか（How）」を策定する。依存の矢印は主に「事業 → 技術」への単方向である、というメンタルモデルを、無意識にもってしまっていたのです。
ヘンリーにおいても、マイクロサービス化の意思決定、モジュラーモノリスへの移行、Kotlin や GraphQL といった技術選定など、様々な意思決定に関わってきました。 これらは当然、ドメインの性質や採用市場、既存のコードベースといった制約の中で、その時点での事業目標を達成するためにベストだと考えた選択でした。
しかし、VPoPとして事業計画や予実管理、営業戦略といったレイヤーに深く触れるにつれ、この「単方向の依存」という認識自体が、実は自分自身の可能性、ひいてはエンジニアリング組織の可能性を狭めていたのではないか、と感じるようになりました。
今の私は、 「技術戦略と事業戦略は双方向の依存関係にあるべきだ」 と考えています。
事業戦略が技術戦略に要件を与えるのは当然ですが、同時に、技術戦略（現在のアーキテクチャ、チームのケイパビリティ、技術的負債の状況など）が、事業戦略に「リアリティ」と「選択肢」を与えます。
例えば、「小規模チームで作り切ればリスクは低いが時間が掛かる」、「大規模に体制を拡充するとリスクは高まるがうまくいけば時間を短縮できる」。 これは単なる開発リソース配分の話ではなく、事業のキャッシュフローや、市場参入のタイミングそのものを決定づける経営判断です。
また、もっと攻めの視点で言えば、優れた技術戦略は事業に新しいオプションを提供します。 私たちが進めているモジュラーモノリス化やドメイン駆動設計の実践は、単にコードを綺麗にするためだけのものではありません。
このように、技術的な武器があるからこそ描ける事業戦略が存在します。 エンジニアが技術戦略を磨き込むことは、経営に対して「このルートなら、もっと速く、高く登れる」という登山ルートを提案することと同義なのです。
もちろん、技術的な挑戦には不確実性がつきものです。「想定より時間がかかる」「パフォーマンスや信頼性に悪影響が出た」といった事象は往々にして起こります。
大前提として、シンプルに技術戦略が間違っていたことを認めて、より良い技術戦略にブラッシュアップしていくことが、まず初めに考えることであるべきです。 しかし、それに加えて重要なのは、その事実を即座に事業戦略へフィードバックし、事業戦略そのものを書き換える勇気を持つことです。
事業、ビジネスサイド、開発など、いろんな視点があり、それぞれお互いの変数が相互に影響し合っていることを認め合い、一緒に悩み、計画を動的にアジャストしていく。 ヘンリーのような難易度の高いドメインで勝つためには、この「双方向の対話」のループを高速に回すことが重要だと思うようになりました。
正直なところ、技術戦略と事業戦略の関係性をこのように捉えることができるようになったのは、VPoPになってからでした。それまでは、もちろん事業に貢献することを意識してやってきたつもりではありましたが、どこかで事業戦略自体は所与のものであるという考えをもってしまっていたような気がします。
今振り返れば、テックリードやエンジニアだった頃の自分も、「もっと良い作り方」だけでなく「もっと良い事業の登り方」を考えることができたはずだと感じています。 「事業のことは経営が決めること」と、無意識に自分の領分を技術領域に限定してしまっていたのです。
だからこそ、私はVPoPとして、エンジニアのみんなが「技術の枠」に閉じこもらず、事業戦略という変数すらもハックできるような環境を作っていきたいと考えています。
「エンジニアも全員PLを見て、営業指標を気にしながらコードを書け」みたいなことをいいたいわけではありません。 そうではなく、自分たちが普段向き合っているコードや仕様、開発プロセスの中に、実は事業を動かすための『隠れた変数』があるということを意識できるだけで、もっともっと大きな価値を生み出せるはずだと思っているのです。
ヘンリーでの開発は、降りてきた仕様を単に実装するような開発ではありませんが、それでも事業の登り方のようなレベルの話については「固定された定数（制約）」だと捉えがちです。 しかし、現場のエンジニアだけが知っている事実があるはずです。 現場でコードを書いているエンジニアこそが、プロダクトの「手触り」を一番知っています。
といったような現場からのインサイトが、経営会議の決定をひっくり返すべきだと思っています。
今回は私のバックグラウンドがエンジニアであるため、技術戦略を例にお話ししましたが、これはエンジニアに限った話ではありません。 デザイナー、プロダクトマネージャー（PdM）、ドメインエキスパートなど、あらゆる職能の専門性が、事業戦略にとってクリティカルなインプットを生み出しうると考えています。
私はエンジニアであり、技術以外の領域にはどうしても見落としが生まれます。「専門性を持った人たちが、それぞれの専門性をリスペクトしながら、共通のゴールに向かって越境し合いながら走る」というチームが理想的なチームだと思っています。 だからこそ、エンジニア以外のメンバーからは、それぞれの専門性に基づいた「事業へのインプット」を与えてもらいたいし、エンジニアについても私の見落としに気付かせてもらいたい。それができるような情報流通やコミュニケーション土台を作っていきたいと考えています。
「事業戦略は技術戦略に影響を与えるが、技術戦略もまた事業戦略に影響を与えるべき」 すごくふつうのことを言っているかもしれませんが、これを高いレベルで実践するのはなかなかに難しいことだと思います。
ヘンリーの開発組織は、仕様書通りに機能を作る工場ではありません。技術的な洞察をもって、事業の未来を提案するシンクタンクであり、それを最速で形にする実行部隊です。 複雑怪奇な社会課題を技術でハックし、そのレバレッジで事業を非連続に成長させる。そんな「エンジニアリング」を、私たちと一緒に楽しみませんか。
ヘンリーはソフトウェアエンジニアを積極的に募集しています！興味を持っていただけた方は、ぜひお話させてください！
こんにちは。株式会社ヘンリーで開発者をやっているタケハタです。
ヘンリーは去る2025年11月1日に、Kotlin Fest 2025にことりスポンサーとしてスポンサーブースを出展しました。
イベント後に報告のエントリーで書いていたのですが、ブースでコンテンツとしてクイズを出題し、多くの方にチャレンジしていただきました。
そのクイズは「【挑戦状】誰が書いたコードか当てまShow！！」と題し、ヘンリーのエンジニア4人が同じ問題に対してコードを書き、どのコードを誰が書いたか当ててもらうというもので、非常に盛り上がり楽しんでいただくことができました。
そこで今回はそのクイズの紹介と答えの解説を書こうと思います。
正答は下の方に書きますので、この記事を読んでいただいているみなさまもぜひチャレンジしてみてください！
まずはコードを書いた回答者4名の紹介です(私も回答しています)。
こちらのプロフィールがどのコードを書いたか当てる上でのヒントになります。
VPoTや創業エンジニア、料理長までいてバラエティに飛んだ面々です。
4人が回答した問題は以下です。
上のコメント部分が問題で、書かれている仕様に沿ってsolve関数を実装し、想定実行結果と同じ内容が出力されるようにします。
/** * * 問題: 以下の仕様を満たすように、`solve` 関数を実装してください。 * * - 標準入力から複数行の `name score`（スペース区切り）を読み取ります。 * - 同じ名前が複数回登場した場合は、スコアを合計します。 * - 合計スコアの降順、スコアが同じ場合は名前の昇順で並べます。 * - 同点の場合は同順位とし、順位はスキップされます（例：1位,1位,3位）。 * - 上位3名を出力してください。 * - 出力形式は `順位. 名前 スコア` とします。 */ fun solve(input: String): String { // 実装する } fun main() { val inputs = listOf( // --- Case 1 --- """ alice 10 bob 7 alice 5 cara 7 dave 7 """.trimIndent(), // --- Case 2 --- """ taku 30 haru 20 ken 25 haru 15 ken 10 """.trimIndent(), // --- Case 3 --- """ a 5 b 5 c 5 d 1 e 10 """.trimIndent() ) for ((i, input) in inputs.withIndex()) { println("=== Case ${i + 1} ===") println(solve(input)) println() } } 想定実行結果 === Case 1 === 1. alice 15 2. bob 7 2. cara 7 2. dave 7 === Case 2 === 1. haru 35 1. ken 35 3. taku 30 === Case 3 === 1. e 10 2. a 5 2. b 5 2. c 5
Collection操作が多く必要で、書き方のクセが出やすい問題になっているところがポイントです。
そしてそれぞれのエンジニアが書いたコードが以下のA〜Dの4つになります。
Aの回答
fun solve(input: String): String { var prevScore: Int? = null var prevRank = 1 return input.split("\n") .map { it.split(" ") } .groupBy({ it[0] }, { it[1].toInt() }) .mapValues { it.value.sum() } .toList() .sortedWith(compareByDescending<Pair<String, Int>> { it.second }.thenBy { it.first }) .mapIndexed { index, (name, score) -> val rank = if (prevScore == null || prevScore > score) { index + 1 } else { prevRank } (rank to "$name $score").also { prevScore = score prevRank = rank } }.takeWhile { it.first <= 3 } .joinToString("\n") { "${it.first}. ${it.second}" } }
Bの回答
fun solve(input: String): String { val rankingList = input.lineSequence().map { line -> val array = line.split(" ") Pair(array[0], array[1]) }.groupingBy { it.first }.fold(0) { sum, (_, score) -> sum + score.toInt() }.toList().sortedWith( compareByDescending<Pair<String, Int>> { it.second }.thenBy { it.first } ) return buildString { var rank = 0 var lastScore = 0 rankingList.forEachIndexed { index, (name, score) -> if (lastScore != score) { rank = index + 1 } if (rank > 3) { return@forEachIndexed } appendLine("$rank. $name $score") lastScore = score } } }
Cの回答
fun solve(input: String): String { val scoreMap = buildMap<String, Int> { input.lineSequence().forEach { val (name, score) = it.split(' ', limit = 2) set(name, getOrDefault(name, 0) + score.toInt()) } } val rankingMap = scoreMap .asIterable() .sortedWith(compareByDescending<Map.Entry<String, Int>> { it.value }.thenBy { it.key }) .groupBy({ it.value }, { it.key }) val topScorers = sequence<Triple<Int, String, Int>> { var rank = 1 for ((score, names) in rankingMap) { val competitionRank = rank // 標準競技順位 for (name in names) { yield(Triple(competitionRank, name, score)) rank++ } } } return topScorers .takeWhile { (rank, _, _) -> rank <= 3 } .joinToString("\n") { (rank, name, score) -> "$rank. $name $score" } }
Dの回答
import java.util.TreeSet typealias Name = String typealias Score = Int fun solve(input: String): String { // エントリを表すデータクラス data class Entry(val name: Name, val score: Score) data class RankedEntry(val rank: Int, val entry: Entry) // 登場人物のランキングSET class Ranking : TreeSet<Entry>( compareByDescending<Entry> { it.score } .thenBy { it.name } ) tailrec fun aggregateScores( remaining: List<String>, scoreMap: HashMap<Name, Score> = HashMap() ): HashMap<Name, Score> { if (remaining.isEmpty()) return scoreMap val line = remaining.first().trim() if (line.isNotBlank()) { val (name, scoreStr) = line.split(' ') val score = scoreStr.toInt() scoreMap[name] = (scoreMap[name] ?: 0) + score return aggregateScores( remaining.drop(1), scoreMap ) } return aggregateScores(remaining.drop(1), scoreMap) } // 集計 val scoreMap = aggregateScores(input.lines()) // Rankingクラスを使ってソート val ranking = scoreMap .map { (name, score) -> Entry(name, score) } .toCollection(Ranking()) // 順位を計算し、上位3順位まで表示 return ranking .foldIndexed(listOf<RankedEntry>()) { index, acc, entry -> // 順位の決定 val rank = if (index > 0 && acc.last().entry.score == entry.score) { // 同点の場合は前の順位を維持 acc.last().rank } else { // スコアが異なる場合は順位を更新 index + 1 } acc + RankedEntry(rank, entry) } .takeWhile { it.rank <= 3 } .joinToString("\\n") { "${it.rank}. ${it.entry.name} ${it.entry.score}" } }
誰がどのコードを書いたかわかりましたか？
正答と解説は下の方にありますので、回答を終えた方は下の方へスクロールしてください！
AはヘンリーのVPoT、VPoEであるKengo TODAが書いたコードでした。
ポイントとしてはすべての処理をメソッドチェーンで書いている点ですね。
「ひとこと」に書かれている「全ては流れであり、流れこそが全てである...」で始まる文章がヒントで、すべてがチェーンされているコードは、まるで流れに身を任せているかのような処理を表現しています。
正解された方からは以下のようコメントをいただきました。
適切にヒントを読み取って正解されている方も多くいました！
Bは私、タケハタが書いたコードでした。
私は一応Kotlinの書籍も過去に出版していて、「ひとこと」にも書いている通り「ﾜﾀｼ Kotlin ﾁｮｯﾄﾃﾞｷﾙ」人間として名乗っています。
なのでgroupingByとfoldという普通の人がなかなか知らない関数を使用したり、PairのListをforEachIndexedで回す時に(name, score)で扱ったりと、Kotlinの機能をふんだんに使ったコードに仕上げました。
正解された方からは以下のようコメントをいただきました。
個人的な想定とは違ったのですが、StringBuilderではなくbuildStringを使うところにKotlinっぽさを感じてわかったという方がかなり多くいました！
やはりKotlin FestではKotlinが好きな方が多く来られていたので、こういった意見も興味深かったです。
Cはヘンリーの創業エンジニアであるcreastyが書いたコードでした。
このコードは正答率も低く、私もポイントがわからなかったのでなにがヒントだったのか後から本人に確認したのですが、なんと「なにも考えてなかった」という答えが返ってきました！
つまりプロフィールにはヒントがなにもなかったのです。どおりで正答率が低いわけですね。
ちなみに正解された方の中には
とおっしゃっていた方もいたのですが、その方にはコードからなにか感じる予測不能な要素があったのかもしれません。
Dはヘンリーの料理長であるgiiitaが書いたコードでした。
ポイントとしては「ひとこと」にある「業務コードとしてレビューしてもらう気持ちで実装しました」と書かれている通り、コードに丁寧なコメントが書かれている点ですね。
あとは「好きな言語」にScalaを書いていることもポイントで、正解された方からは
というコメントもいただきました。
このコードは正答率も一番高かったです！
あとはなぜか
とおっしゃっていた方もおり、やはりコードにはエンジニアの様々な一面が表現されるものなのだなと、感動を覚えました。
本記事を読んでいただいたみなさまは、どのコードを誰が書いたかわかったでしょうか？
当日、ブースでこちらのクイズを多くの方が真剣に取り組み、楽しんでいただけました！
かなり難しいクイズになるかと思ったのですが、想像以上に多くの方が正解していて、参加者のみなさまの洞察力に驚きました。
今後もヘンリーでは様々なイベントで、楽しんでいただけるコンテンツを用意していきますので、ブースなどで見かけた際はぜひお立ち寄りください！
最後に告知です。
ヘンリーでは11月25日(火)に、Kotlin Fest 2025の非公式アフターイベントとしてServer-Side Kotlin Night 2025を開催します！
弊社からKotlin Festに登壇したnabeoも含む、計8名の登壇者でお送りするServer-Side Kotlinのイベントです。
当日直前まで申し込み可能ですので、ぜひこちらもご参加いただければと思います！
ヘンリーでPMをやっているdamです。
2025/10/24にタイミーさんのタイミー広場をお借りして、メドレーさん、リンケージさんと合同で「HealthTech Meetup vol.2」を開催しました。
healthtech-meetup.connpass.com
今回は『おもろムズい医療業界』のテーマに沿った各社のショートトークからはじまりました。
弊社からは前々職から15年電子カルテの開発に関わり続けている尾渡が登壇しました。
15年間で感じてきた医療業界特有の苦悩や葛藤を語り、会場からは「あるある〜」と共感の声が湧いていました。
ボタン位置変更で怒られるはありとあらゆる業界であるある #healthtechmeetup
— hidesuke (@hidesuke) 2025年10月24日
今回は参加者からの公募LTを事前募集し、5名の方に登壇いただけました。
どの発表も面白い内容で、それぞれが医療の課題についてどのように向き合っているかの話が興味深かったです。
特に今回は医師の方にもご登壇いただき、より現場視点の話が語られる貴重な機会として盛り上がるシーンもありました。
5分の間にデモ入れたり、カウンセラーも出てきたりLTじゃもったいないタレントが多すぎる(´Д` )ｽｺﾞｲ#healthTechMeetup pic.twitter.com/eoErjrHPF3
— odasho (@odashoDotCom) 2025年10月24日
もっとお話を聞きたい！と思ったところで制限時間5分の銅鑼が鳴り響いて終了〜の流れも盛況で、話の続きについては懇親会で大いに語り合っていただくこともできました。
タイミーさんはIT企業なので社内に銅羅がある（？？？）
— toya (@toya) 2025年10月24日
ていうかでかい銅羅を久しぶり（高校の時以来だから30年以上ぶり）に間近で見ました。
#healthtechmeetup pic.twitter.com/OQltBDloIi
実は前回vol.1の開催に対してvol.2でお申し込み頂いた方は新規の方が多く、はじめましての方々と多く出会えた機会でもありました。
まだまだ医療界隈には知らない領域で頑張っている人が大勢いらっしゃいますね！
次回のHealthTech Meetup vol.3は年明け3月頃の開催を予定しています。まだまだこの輪を広げて、引き続きHealthTech業界を盛り上げて行きたいと思いますので、応援よろしくお願いいたします。
ヘンリーでは医療 DX を通じて理想駆動で社会課題を解決してくれる仲間を募集しています！！気になった方は気軽にカジュアル面談をお申し込みください。
また、2025年11月13日に弊社のエンジニアとカジュアルに話せる少人数のイベントを予定しています。こちらも併せてご検討ください。
