【2025年版】ヘンリーのオンボーディング体制の現在点

この記事は

qiita.com

の4日目の記事です。

本記事の目的

はじめまして、11月にヘンリーにレセコン開発エンジニアとして入社した Masaki Sugimoto(id:msksgm) です。 株式会社ヘンリー エンジニアブログには、複数の入社エントリ（はじめての転職で難易度鬼のレセコン開発に挑戦している、はじめまして nabeo です）があります。 入社してから1ヶ月ですので、まだまだ業務に慣れない部分がありつつも、最近のヘンリーのオンボーディング情報をアップデートしたり、ヘンリーに少しでも興味がある方に向けて解像度を上げるために執筆しました。

入社後のあれこれ

オンボーディング

入社後の1ヶ月間はオンボーディング期間として設定されています。 この期間は常にMTGがあるわけではなく、最初の2週間ぐらいに1日2~4時間のオンボーディングMTGをやりつつ、チームのMTGに参加したりメンバーとの1on1をこなします。 最初の2週間が終わったら、ほとんどオンボーディングMTGが終わり各チームに本格的に配属していくので、そこからたまにあるオンボーディング系の業務をこなしながら、本格的にチームの業務にとりくんでいきます。

オンボーディングについては、nabeo(id:nabeop)さんと岡部さん(id:takamizawa46)の記事でも取り上げられていますが、エンジニア30名程度、全体で120名程度のスタートアップにしては充実していると思いました。 むしろ充実しすぎているほどの印象を受けました。 個人的なスタートアップの印象は、初日か次の日にはタスクがアサインされるものだと考えていたため、良い意味で面食らいました。

dev.henry.jp

dev.henry.jp

オンボーディングプログラムの内容をいくつか抽象化して列挙すると、以下のようなプログラムが含まれています。 どれも、医療業界未経験の私にとって勉強になる部分が多く、事業の意義やなぜヘンリーで働くのかについて理解を深めることができ非常にありがたかったです。

• 会社の沿革について
• 医療業界まわりの情勢
• 組織説明
• プロダクトのワークショップ

岡部さん(id:takamizawa46)の記事では、チームのオンボーディングについて未整備の部分が多いことが言及されていますが、比較的改善されたと考えています。 入社人数が増えるにつれてドキュメントや Slack が成熟していきました。 最近では Notion AI に質問すると、連携アプリケーション（Notion、Slack など）を横断的に検索してまとめてくれます。これにより、暗黙知や Slack でやりとりされただけの情報も発見しやすくなりました。 整備がしっかりしているかと言われたら、まだまだと考えているので、自分を含めて組織全体で整えていく必要があります。

未成熟だと感じている部分は、チームが担当しているドメイン（特にレセプト業務や診療報酬請求の仕組みなど）知識のキャッチアップ体制です。 私が担当するチームでは、レセコンの開発をしています。 レセコンに関係する、公費、点数、算定といった内容は、専門用語や専門的なワークフローが多く、日本語で会話しているのに内容を理解できない瞬間が多々あります。 上述のワークショップでまったく説明がないことはありませんが、新規参画者が慣れるには時間がかかる内容です。

お客様との関わり

自分の入社タイミングが良かった点が大きいですが、入社してから 病院DXカンファレンス2025を聴講したり、お客様訪問をする機会に恵まれました。

病院DXカンファレンス2025は、ヘンリーが主催したお客様を招待したイベントで「地域医療の理想を共に語る」をテーマに最新技術の共有、成功事例の紹介などをするイベントです。 私は現地参加ではなく配信を聴講しましたが、お客様がHenryを導入することで、どれくらい業務が変わったかを知ることができました。

お客様訪問とは、実際に電子カルテ・レセコンHenry（以下、Henry）を導入しているお客様の病院に訪問することです。 導入してから数ヶ月経過したお客様に訪問したときには、ペーパーレスが進んだことで業務スペースが増えたり特定の業務を削減できたことをお伺いできました。 実際に Henry を使って、業務をこなしている様子をみると Henry を開発する意義を実感しますし、新規参画者目線で現場における Henry の使われ方を見て勉強になりました。 しかし、まだまだ機能不足な点を指摘されたり、数多くの要望をいただいたりすると、ヘンリーが提供したい価値や実現したい地域医療にほど遠いことを痛感し、エンジニアとして身が引き締まる思いになります。

業務に関して

レセコンチームでは、だいたいマネージャー 1 名、PM 1 名、FE 2 名、BE 3 名、テスター 2 名、ドメインエキスパート 1 名という体制で開発をしています。 デイリースタンドアップミーティングやスプリントプランニングのタイミングでドメインエキスパートからフィードバックをもらえる機会が自分にとっては新鮮な環境です。 レセコンの使われ方についての知識がなくても、気軽に聞ける環境であるため、プロダクトづくりにおいて心理的安全性を保ちながら進められています。

技術的な側面では、Henry の BE 開発ではプログラミング言語に Kotlin を利用し、トレースツールには Honeycomb を利用しています。 これらの技術スタックは、私個人の技術的な関心事であるサーバーサイド Kotlin とオブザーバビリティと完全に一致していました。 Kotlin に興味がある理由は、複雑なドメインロジックを安全に表現するのに適していると考えているからです。 オブザーバビリティについては、開発と運用を続けるうちに複雑さと不透明さが増していくシステムにおいて、問題の早期発見と原因特定を可能にする重要な技術だと考えているからです。 ヘンリーでは、これらの関心が高い技術がすでに導入済みであるため、一個人のエンジニアとして手を動かして楽しく、成長を期待できる環境です。

採用技術については、以下の Speaker Deck やエンジニアブログで詳細に紹介されています。 これらに興味がある方は、そちらも参照してみてください。

speakerdeck.com

dev.henry.jp

一方で、ドメイン知識が圧倒的に不足しているため、IC としては業務に苦戦しています。 新規参画したときに、最初から活躍ができないのは当たり前なので、予想はしていましたが、いざ直面すると焦りを感じます。

個人で実践していること

ここまで、組織の現在のオンボーディング体制について記述しました。 ここからは、入社してから実感した自分の不足している点を解消するために、通常業務と合わせて、おこがましく取り組んでいることを記載します。 N=1 であるため参考にならないかもしれませんが、ヘンリーにはこれらの取り組みを受け入れてくれる組織であることが伝われば幸いです。

ドメインエキスパートとの対話でプロダクトの理解を深める

先述したチームでドメイン知識をキャッチアップできる体制が整っていないことに対する打開策です。 ヘンリーでは、Henry の標準業務運用フローと呼ばれるものを作成中です。 標準業務運用フローでは、Henryが実際にどのように使われるかのフローを定義しています。 中長期的には、CUJ（Critical User Journey）の定義や自動テストの取捨選択に利用されることを期待しています。 運用フローの定義はされているものの、フローが実際にどの画面を利用するのかはわかりづらい状況でした。
そこでどのように使われるかを最も知りたい新規参画者である私がドメインエキスパートとともに実際の画面動作をおさらいしています。 毎朝30~45分程度時間をとり、プロダクトとドメイン知識と業務フローを擦り合わせています。 それを私が持ち帰りドキュメンテーションやコードとの対応をまとめています。 中長期的には新規参画者が運用フローを見るだけでHenryのプロダクト理解が進んだり、フローをコードで表現できないかと画策しています。

興味のある MTG に参加してみる

ヘンリーではギベンと呼ばれる技術勉強会だったり、ドメインの知見共有会だったりと、ドオープンな勉強会が多く開催されています。 すでに、それらにも参加しているのですが、ほかのチームの MTG にも参加してみたりしています。 私はオブザーバビリティや SRE にも興味があったため、SRE 室のランチ会やパフォーマンス分析会にも参加しています。 まだまだ組織的にカオスな側面が多く、MTGの出入りがしやすいため、興味がある特定の分野に参加しやすい状況です。

DevRel 活動に関わる

入社前からヘンリーがカンファレンスのブース出展が多いことから DevRel が盛んであることを知っていました。 過去の経験から、DevRel 運営のつらみも知っているため、どのように運営をしているのか気になっていました。 そこで、先述した興味のある MTG に参加してみるにも近いですが、ヘンリーの DevRel 運営に関わってみることにしました。

スポンサーをしているカンファレンスのブースを手伝ったり、技術書典で売り子になったり、ヘンリー主催の勉強会の裏側で、DevRel 活動の大変さや楽しさを目の当たりにしてきました。 運営側として活動することで新たな発見がありました。特に、ヘンリーを初めて知る人への説明を通じて、プロダクトの価値や事業の意義について改めて理解を深めることができ、普段の業務以上に勉強になることが多いです。

一緒に仕事をする仲間を募集しています

ここまで読んでいただき、ありがとうございます。
エンジニアの数が増えるにつれて不足していた部分が明確になり、オンボーディングも安定しつつあります。 しかし、組織・事業・エンジニアリングのそれぞれの面で、カオスな部分が残っており、そのカオスを一緒に楽しめる仲間を募集しています。

興味のある方は以下の採用サイトから、ぜひコンタクトしてみてください。

技術広報をすると何がいいのか？ 〜得られる効果とコスパについて〜

こんにちは、ヘンリー開発者のタケハタです。
普段はエンジニアとしてプロダクトの開発をしつつ、技術広報ギルドという有志の横断組織で、技術広報の活動をしています。

本記事は株式会社ヘンリー Advent Calendar 2025 3日目の記事になります。
昨日はSREの(id:nabeop / @nabeo)によるなぜ AWS 移設をするのかでした。

目次

• 技術広報の成果は見えづらいとよく言われる
• 効果として期待できるもの
  • 認知の獲得
  • コネクションの形成
  • ブランド力の向上
  • 社内のエンジニアのモチベーションとスキル向上
• 施策ごとの効果
  • 技術ブログ
  • イベントへのスポンサード、ブース出展
  • 自社イベント開催
• ヘンリーで2025年にやってきた施策と成果
  • やってきた施策
  • ヘンリーで得られた効果
  • 前提として、施策1つで直接的な効果は出にくい
• コスパってどうなの？
  • 他の採用やPRをした時の比較をした時
  • その工数をエンジニアが開発に使ったほうがいいのでは？
• 組織を拡大していくのであれば技術広報の価値は高い

技術広報の成果は見えづらいとよく言われる

技術広報は「成果が見えづらい」と言われがちです。 売上に直結するわけでもなく、採用効果も長期的に見ていく必要があり、「施策を一つ実施したら即KPIが伸びる」という性質のものでもありません。 その一方で、ある程度の費用や人的工数はかかります。

そこで本記事では、ヘンリーが実際に取り組んできた技術広報の活動を例に、どのような効果が期待できるのか を具体的に紹介します。

効果として期待できるもの

まず、効果として期待できるものをいくつか紹介します。
主に採用とブランディングになってくるのですが、もうちょっと具体的に書きます。

認知の獲得

まず、会社の名前が知られているということはとても重要なことです。
例えば転職活動をしている時、転職エージェントで渡された大量の求人票をパラパラとめくっていると、名前を知っている企業でないとほぼ目に止まりません。スカウトサイトやSNSで大量のスカウトが来ている場合なども同じでしょう。

逆に聞いたことある企業であれば「なんか聞いたことあるな」と動機になりえますし、さらに"いい印象"を持った上で知っている企業であればとりあえず見てみようとは思えます。 もし本当に強い興味を持ってもらえていたら、「転職しようかな」と考えた時に自分たちの企業の名前を思い浮かべてもらえるかもしれません。

コネクションの形成

採用では候補母集団の広さが重要です。
仮にこちらが採用したいと思った人の候補が10人いたとして、その中で自分たちに興味を持ってもらえるのは2〜3人かもしれませんし、1人もいないかもしれません。その候補を増やしておく必要があります。

いわゆるタレントプールを充実させるという話ですが、そのためにも技術広報は有効です。
今はスカウト媒体やSNSでスカウトを送ってつながることもできますし、社員のリファラルで増やす方法もありますが、あくまで自分たちで見つけられた範囲の人にしかアプローチできません。

それに対して例えばイベントに登壇したりブース出展したりすると、不特定多数の人がこちらの話を聞きに来てくれます。
そこには自分たちの検索には引っかからなかった人や、そもそもオンライン上に現れないような人もいます。
スカウトを送っても見られずに終わるだけだった人が、イベントで自分たちに興味を持って来てくれて、話を聞いてもらえるかもしれません。

ブランド力の向上

エンジニアについて発信することで、自分たちの会社に優秀なエンジニアや、取り組みを発表することで組織の印象を上げることができます。
「この会社はこんなに優秀なエンジニアがいるのか」「こんなすごい取り組みをやっているのか」と思われれば、企業イメージが向上します。

また、技術広報をやっていることで"エンジニアに理解のある会社"というイメージも持ってもらいやすいです。
冒頭で書いた通りお金も工数もかかることなので、会社として理解がなければ基本的にできません。

社内のエンジニアのモチベーションとスキル向上

モチベーション向上

私がブログを初めて書いた時(発信を始めた時)は、義務感にかられてでした。
しかし、今はブログを書いたり登壇したりと、発信すること自体が楽しいと感じています。

その理由の一つとしては、見た人から反応をもらえるのが嬉しいです。
そんなに多いわけではなくても、社内外の誰かしらからポジティブな感想をもらえるのは嬉しいものです。

また、自社の説明やPRをするために語っていると、自分の組織のよさを言語化して理解が深まり働くモチベーションが上がることもあります。

スキル向上

また、アウトプットをすること自体が自分のスキルアップにもつながります。
自分がよく知ってる分野の技術でも、ブログや登壇ではより正確に伝える必要があるため、改めて調べて理解できてなかった部分に気づくことがあります。
また技術的な話でなくても、自分の考え方を言語化することで、強みや課題に気づくこともります。

あとはイベント出展などをしていると、前述のように多くのエンジニアと話す機会ができるので、自分の知らない考え方に触れて見聞を広げることにもつながります。

施策ごとの効果

もう少し具体的に、技術広報の施策と期待できる効果を紹介していきます。

技術ブログ

採用候補者へのPR

ブログが一番力を発揮するのは、採用の候補者が選考に進む前に読めることです。
その会社がどんなことをやっているのか、どんなエンジニアがいるかなど、読むことで雰囲気を掴むことができます。
候補者が読んで面白いと思う記事があれば、受けるか迷っている人へのPRにもなります。
人によっては定常的に発信していること自体に魅力を感じる場合もあります。

また、面談や面接で質問をされた時、その回答として合致する記事があれば渡すこともできます。
その場で説明するのは時間が限られてしまうので、より詳細に伝えることができるものが用意されているのは、とても有効です。

認知の獲得

あとは技術的な内容は、エンジニアの調べ物の検索に引っかかって目にとまることもあります。
記事が多ければそれだけヒットする可能性も上がり、目に留まる頻度が上がれば前述の認知の獲得にもつながります。

そしてもちろんバズる記事を書ければ、その単発で大きな宣伝効果を生む可能性もあります。
しかし、これはめったに起こらないものなので、積み上げが大事ということを意識する方が重要です。

イベントへのスポンサード、ブース出展

多くの人と会いプチカジュアル面談のようなことができる

イベントのスポンサーメニューで鉄板のブース出展は、とにかく不特定多数の参加者と直接話せることが有益です。
多くの企業でクイズやノベルティ配布などコンテンツを用意していますが、大事なのは来てもらった方に自社の話をできることです。
私は何度もブース出展に参加していますが、普段カジュアル面談などで話しているような内容を1日に何十人にも話していて、プチカジュアル面談を大量にしている感覚になります。

スカウトやエージェント経由などでこの人数感と合うには膨大な労力と時間がかかるので、お互い気軽に会って話せる場があるのはとても貴重です。
イベントのテーマに沿って話題も作りやすいので、面談などで話すのが苦手な人にも優しいです。

技術領域へのブランディングとしても有効

会社の使っている技術領域に関連する内容のカンファレンスなどでは、特にマッチする人が来てくれる可能性が上がります。
その領域への会社としての本気度も伝わることで、技術に関心の高いエンジニアが興味を持つ可能性もあり、ブランディングとしても有効です。

自社イベント開催

ブース出展は外のイベントを行ってのアピールする場になりますが、自社でイベントを主催するのはまた違った効果があります。

まず主催者なので、全面的に自社のことを打ち出すことができます。
また、会社を全面に打ち出したイベント来てくれる参加者なので、会社に興味を持ってくれた人も多くなります。
ブース出展などで興味を持ってくれた人に、「こういうイベントやるので来ませんか？」と誘い、さらに会社について深く知ってもらうこともできます。

一番は会社のファンになってもらうことが狙いになります。

ヘンリーで2025年にやってきた施策と成果

では、実際にヘンリーでやってきた施策と、得られた効果を紹介します。

やってきた施策

まずはやってきた施策です。
2025年は技術広報の活動が活発になり、多くのことに取り組みました。

技術ブログ

まずは本ブログです。 dev.henry.jp 月2本以上は書けるように運用しており、今月はQiita Advent Calendarに参加中のため更新も多くなる予定です。

ポッドキャスト

「理想駆動ラジオ」というポッドキャストもやっています。 open.spotify.com こちらはヘンリーの社員を一人ずつインタビューし、ヘンリーでの働き方やパーソナリティを深掘っていく形式になります。
「ヘンリーでどんな人が働いているのか？」を知っていただくためのコンテンツになっています。

スポンサー、ブース出展

以下のイベントにスポンサードし、ブース出展してしました。

技術書典18
技術書典19
CoLab Conf（コラコン） 第1回
CoLab Conf（コラコン） 第2回 ※12/13開催予定
Cloud Operator Days Tokyo 2025
Kotlin Fest 2025
アーキテクチャカンファレンス 2025

技術書典はスポンサードしていますが、ブースは有志のサークルとして申し込んで毎回本を出しています。

カンファレンス登壇

以下のカンファレンスでヘンリーメンバーが登壇しました。

CoLab Conf（コラコン） 第2回
Cloud Operator Days Tokyo 2025
Kotlin Fest 2025
アーキテクチャカンファレンス 2025

自社イベント(コラボ、コミュニティ参加含む)

自社イベントとしては以下を開催しました。

Henry Engineer Meetup #1
Henry Engineer Meetup #2
Henry Engineer Meetup #3
Henry Engineer Meetup #4 ※12/11開催予定
QAの理想を語らNight！
Server-Side Kotlin Night 2025

主には「Henry Engineer Meetup」が定期的な自社イベントとなっており、ヘンリーや医療に興味を持っている方や、社員の知り合いもお誘いしながらヘンリーの開発について知っていただく内容です。
また、Kotlin Fest 2025の非公式アフターイベントやQAに関するイベントを開催したりと、技術領域にフォーカスしたイベントも行っています。

他社コラボイベント

さらに他の企業様ともコラボして、以下のようなイベントもやっています。

シネマ de LT会〜あなたのナレッジ大上映〜
HealthTech Meetup
HealthTech Meetup vol.2
Server-Side Kotlin LT大会 vol.14
Server-Side Kotlin LT大会 vol.15
Server-Side Kotlin LT大会 vol.16

ヘンリーはServer-Side Kotlin Meetupというコミュニティに会社として参加しており、「Server-Side Kotlin LT大会」はそのイベントになります。
最近はHealthTech Meetupという医療系のテック企業による合同イベントも立ち上げており、多くの方にご参加いただいています。

ヘンリーで得られた効果

実際に得られた効果を紹介します。

採用の中で聞いた声

まず、面談などでお話した方から以下のような声をいただきました。

• ブログの記事がいっぱいあったので見て雰囲気がわかった
• ポッドキャストを聞いてどんな人がいるのかわかった
• Kotlin Festでスポンサードしているのを見てヘンリーの名前を知った
• 技術書典の記事で興味を持った
• 候補にしていた企業の中で、選ぶ際に発信しているかを足切りに条件にしていた

やはりブログは面談や選考に来ていただいた候補者の方が、会う前に情報を得るために読んでくださっていることが多かったです。
ポッドキャストも同様の効果がありますね。

スポンサード、ブース出展で知ったという声も非常に嬉しいものでした。
より多くの方に知っていただくためにやってきた施策なので、こちらも期待した効果が出始めていると言えます。

自社イベントから選考につながった

主な自社イベントであるHenry Engineer Meetupでは、そこで興味を持ち選考に進んでいただいた方もいます。
ヘンリーのエンジニアによる発表もありますし、それ以外の社員も多く参加し会社のことをお話しするので、働くイメージが具体的になって決められたようです。

社員の知り合いの方や、過去にカジュアル面談などでお話した方で「もう少し話を聞いてみたい」という方をお招きすることもあります。
もちろん「このイベントに参加したから絶対選考を受けてくれ」というわけではなく、あくまでヘンリーや医療ドメインの面白さを知っていただき、将来的にでも興味を持った時にご一緒できたら嬉しいと考えています。

カジュアル面談数の増加

2024年末と比べて、右肩上がりに増えています。

カジュアル面談数の推移

人事の方でスカウト強化などの動きを他にもしているので、すべてが技術広報の効果というわけではありません。
しかし会社としての露出が増えたことで認知され、スカウトで返信していただけることが増えたり、前述のようにイベントに参加して決めていただいたりと着実につながっています。

前提として、施策1つで直接的な効果は出にくい

効果を色々と書きましたが、施策を1つやっただけで直接的に採用などの効果につながることはまずありません。
例えば大きなカンファレンスに初めて登壇者を出したとして、いきなり「あのセッションを見て入りたいと思いました！」とは普通なりません。
ブログなども数記事書いていきなりバズって、「あの記事を見て転職したいと思いました！」となる人もまずいないでしょう。

なのでやはり積み上げが大事です。
いざ転職しようと思った時に、多くの人が「そういえばヘンリーって会社あったな」と思い浮かべるようになったら勝ちです。

コスパってどうなの？

技術広報に価値があること自体は知っていただけたかもしれませんが、ではそのコストパフォーマンスはどうなのか？と考える人もいるのではないでしょうか。

他の採用やPRをした時の比較をした時

採用は必要なコストが高い

採用やPRは基本的にお金と労力がかかります。
採用に関してはエージェントやスカウト媒体の利用料、サービスによっては成約手数料がかかる場合もあります。PRのために広告を出すのも、もちろん費用がかかります。
さらにそのお金と労力をかけても、自分たちの求めている人と出会うまでには何十人もの人と時間をかけて会う必要があり、さらにそこから候補者から自分たちを選んでもらう必要があります。

技術広報でかかるコスト

それを考えると、一見労力が大きいように見えるブース出展などの活動も、コスパは悪くないのではないかと考えています。
例えばブース出展であれば、使うコストとしては主に以下のようなものがあります。

• お金
  • スポンサー費(ブース出せるプランは大体100万前後〜)
  • 配布するノベルティ制作(新規に作成する場合)
• 作業
  • 運営との事務的なやり取り
  • ブースコンテンツの企画、制作
  • ノベルティの考案(新規に作成する場合)
  • 会場への発送対応
  • 当日のブース対応

これらは広報に関わるメンバー何人かが中心になって、必要に応じて社員に協力を仰ぎながら進めます。
ただ、通常の採用でも前述のようにスカウトや面談・面接の工数や、様々な手数料などの費用がかかります。
なのでそこの差分はあまりないと考えています。

その上で採用以外の効果もある

その上でさらにやることでスキルアップやモチベーション向上につながるという効果も得られます。
さらにヘンリーでは、今のところ協力してもらったメンバーはみんな楽しみながらイベントなどに関わっており、「楽しく採用・PRに関われる」というところも隠れたコスパの良さだと思っています。

もちろんどちらがいいというわけではなく、両軸でやる必要があります。
採用サービスの活用をある程度やりきっている企業であれば、単純にそこにさらに多く工数をつぎ込むよりも、新たな層にアプローチできる可能性がある技術広報に工数を使うのは有効な選択肢になります。

その工数をエンジニアが開発に使ったほうがいいのでは？

広報のような活動は、開発が忙しくなってくるとどうしても後回しにされがちです。
技術広報もエンジニアの力が必要になってくるので、「その工数を開発に使ったらもっとリリース早められるのでは」と思う人もいるでしょう。

採用を止めないのであればやるべき

しかし、それは「エンジニアが面談・面接する時間を開発に回した方がいいから採用止めよう」と言っているのと同じようなことだと思います。
ここまで書いてきた通り、技術広報は採用施策の一つとしても多くの効果が見込めます。
今後も採用を続けて、組織を拡大していくような想定があるのであれば、そのための手段の一つとしてやっておくことは強くおすすめします。

社員のエンゲージメント向上にもつながる

また、この活動により社員のモチベーションが上がり、会社で長く働くことにつながるのであればそれも大きなプラスです。
広報活動に参加したり、広報の成果を見て自分のいる会社を好きになり、3年で辞めてたかもしれない人が10年働いたらそれは1人採用する以上のとてつもない成果です。
私も技術広報ギルドに参加していることが、ヘンリーで楽しく開発できている理由の一つでもあります。
開発だけをやっていたら、今ほどヘンリーのよさを語れなかったと思いますし、技術広報のおかげでより価値を感じながら開発ができています。

組織を拡大していくのであれば技術広報の価値は高い

繰り返しになりますが、組織の拡大をするつもりでエンジニアが必要なのであれば、技術広報をする価値は非常に高いです。
もし「やりたいけど、どれだけ価値があるのかわからない」「成果が見えないので続けるモチベがない」と思っている方がいたら、この記事を参考に自信を持ってやっていただけたら嬉しいです。

ヘンリーでは来年以降もさらに積極的な技術広報の活動をしていこうと考えていますので、イベントなどで見かけた時はぜひお立ち寄りいただければと思います。

告知: 「Henry Engineer Meetup #4 電子カルテ開発の学びと働くリアル」を開催します！

最後に告知です。
本記事の中でも書いていた、「Henry Engineer Meetup」の#4を開催します！

henry.connpass.com

もしこのブログを読んでヘンリーに興味を持っていただいた方は、ぜひお越しください。

なぜ AWS 移設をするのか

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

これは株式会社ヘンリー Advent Calendar 2025 (シーズン1) の2日目の記事です。昨日は VPoP (VP of Product) の縣 (id:agtn / @agatan) による事業戦略は技術戦略に影響を与えるが、技術戦略もまた事業戦略に影響を与えるべきでした。

今年の SRE チームの大きなトピックとしてクラウド基盤を Google Cloud から AWS に移設するプロジェクトが進んでいます。プロジェクト自体は去年から始まっており、粛々と進めていたのですが、ある程度の目処が立ってきたので今年の10月に外部向けにもプロジェクトの存在を公開しました。

カジュアル面談やイベントなどで AWS 移設について言及することがあったのですが、一番質問されたのは「なぜ、クラウド基盤の移設をするのか?」という内容でした。そこで、今回は Google Cloud を選択した経緯と、クラウド基盤の移設を決定した背景について説明したいと思います。

薬学部からITコンサルへ、大企業からスタートアップへ。ヘンリーに入社しました。

はじめに

はじめまして。@ryugen04です。 2025年11月に株式会社ヘンリーに入社しました。

経歴を一言でいうと、「薬剤師免許を持っているけど、薬局で働いたことがないエンジニア」です。薬学部の研究室で医療情報学を学ぶ中でプログラミングに出会い、ITコンサルティング企業で4年、医療系を含む様々なプロジェクトを経験しました。

なぜ大企業からスタートアップへ移ったのか。入社1ヶ月の今、実際に働いてみての所感もあわせて書いてみます。

前職での経験

四苦八苦して大学を卒業したあとに前職のITコンサルティング企業には新卒から4年間在籍し、ありがたいことにシニアランクまで昇進しました。ウォーターフォールもアジャイルも経験し、医療系プロジェクトでは診療報酬に関する開発にも携わらせていただきました。

会社規模が大きかったこともあり、基幹系システムや官公庁系案件、小規模なBtoC案件など、様々なインダストリーに関われたのも良い経験でした。 リーダー的な役割も任せてもらい、マネジメントの基礎を学んだり、スクラムマスターの真似事のような経験もさせてもらいました。

様々な経験をさせてもらった一方、大企業や受託開発に近しい領域ゆえの課題も感じていました。

• 仕様を自分たちで決められない
• プロジェクト体制のため、プロダクトへの継続的なオーナーシップを持ちにくい
• 技術選定や変更に組織的な制約が大きい

これらは会社の良し悪しではなくトレードオフな側面だとは思います。

他に組織面としても、私が志す医療やITの分野に全員が同じ方向を向いているわけではない、といったことに個人的に考えることがありました。

転職を決めた理由

こうした経験を経て、次のような環境を求めるようになりました。

• 技術か医療、あるいはその両方が好きな人たちが集まり、組織全体が同じ方向を向いている
• 小さな規模でスピード感を持ったプロダクト開発ができる
• 技術的により大きな挑戦と成長ができる
• 医療に大きなインパクトを与えるプロダクトを、自分がオーナーシップを持って開発できる

また、個人的な年齢も30手前だったことも意識しました。挑戦をするなら今だろう、と。

ヘンリーに決めた理由

転職では医療×ITという軸で働こう、と考え、いくつかの企業を受けました。医療系テック企業にはアンテナを貼っていたので、ヘンリーのこと自体はもともと知ってはいました。 その中で、ヘンリーを選んだ理由は主に3つあります。

• 目標の大きさ
• アウトプット文化
• 病院見学での印象

「目標の大きさ」としては、ヘンリーは「ノーベル平和賞」を企業理念の中間ゴールとして掲げています。大きな目標ですが、だから良い。 自分のやりたいことである、医療に大きなインパクトを与えるプロダクト開発というところにこの上なくマッチしていますし、持続可能な医療体制という社会課題に本気で取り組む会社の姿勢の表れであり、かつ全員がこの目標の方向を向いているということに大きな価値を感じました。

「アウトプット文化」としては、connpassイベントの開催や、技術書典への出展をしていることに大きな魅力を感じました。 転職当時では以下のような本を2冊出しており、かつそれぞれ100p超という結構なボリュームがあったりします。 techbookfest.org プロダクトの内情をここまで積極的に発信できる、またこのボリュームは個人の気まぐれや献身だけでなく、チームとしてアウトプットを推奨や協力している姿勢を感じました。

「病院見学での印象」としては、選考が進んだ内定承諾前に提案いただき、病院見学をさせてもらいました。印象的だったのは、ヘンリーの社員が現場に複数人入り込み、医療職の方々とラフにコミュニケーションを取っていたことです。電子カルテやレセコンの導入は一般的には経営のトップダウンで決まり、現場的にはnot welcome。もう少し冷たい距離感や殺伐とした雰囲気をイメージしていたので、実際に医療現場を一緒に支えているような風景に好感を覚えました。

丁寧な採用に力を入れていること、病院との距離が近いこと。選考を通じてこれを肌で感じられたことも大きかったです。

入社1ヶ月の実際

スタートアップなので、正直入社初日から修羅場に放り込まれるくらいの覚悟はしていました。 実際はオンボーディングがしっかり設計されていて、良い意味で意外でした。Notionに共通タスクリストやドキュメントがまとまっていて、全社的なキャッチアップがしやすくなっています。スタートアップ特有の「組織が崩壊寸前のカオス」といった雰囲気は正直あまりなく、組織設計がしっかりされているぶん安定感があります。

技術面では、Kotlinがバックエンドのメインであること、複数のサーバー構成であることなど、前職のJavaメインの環境とは異なる部分のキャッチアップと並行しながらタスクを進めています。コードベースはエンジニアのレベルが高く、いわゆる「神クラス」のような負債は見当たりません。GraphQLなどモダンな技術スタックを使っていることも魅力です。前職から言語的にはすべて新しいものへのチャレンジとなっているため、キャッチアップしながら日々頑張っています。

ドメイン知識については、前職で診療報酬に関わっていた経験が思った以上に活きています。薬学部で学んだ医療制度の知識や、医療現場の肌感覚といった部分も、キャッチアップのスピードにプラスしている実感があります。

もちろんわからないことは多いですが、聞けば親切に教えてもらえます。この領域は医療現場の慣習や、厚生労働省などを主体とした国としてのシステム、歴史や制度的な複雑性があり、はじめて取り組む方には想像以上かもしれません。ただ、それをどう扱うかがエンジニアリングの腕の見せ所なのではと思っています。やりがいはありますね。

今やっていること

現在は製品開発本部に所属し、スクラム開発のエンジニアを担当しています。Henryの機能領域として大きく電子カルテ、レセコン、オーダー機能などがありますが、その中のレセコンのサブ領域ですね。

新規画面機能のフロントエンドからバックエンドまでの開発に関われています。

チームで印象的なのは、1週間サイクルでスクラムが回っていること。そしてドメインエキスパート、マネージャー、デザイナー、エンジニアなどなどがそれぞれ自主的に大きくアウトプットしていることです。 開発中はドメインエキスパートと要件を確認しあい、本番環境へのデリバリー前にはリリースノートの書き方やリリースタイミングまで関係する社内メンバーと相談してチームとしてオーナーシップをもって決めています。これは前職では経験できなかったことで、まさに求めていた環境だと感じています。 このスピード感と自主性は、レベルの高い人材が揃っていないと成り立たないと思いました。

まとめ

入社1ヶ月、まだまだわからないことやサポートが必要なことも正直多いです。しかし、求めていた環境ではあると感じています。プロダクトへのオーナーシップ、技術的な挑戦と成長、医療への貢献。これからどう成長していけるか、楽しみです。

採用情報

ヘンリーでは一緒に働く仲間を募集しています。この記事を読んで少しでも興味を持っていただけたら、ぜひ気軽にカジュアル面談の連絡をしてください。

jobs.henry.jp

hrmos.co

事業戦略は技術戦略に影響を与えるが、技術戦略もまた事業戦略に影響を与えるべき

こんにちは。ヘンリーで VPoP (VP of Product) をしている agatan です。 2025年の10月から、これまでのエンジニアとしての役割に加え、VP of Product & 製品部門長という役割を担うことになりました。

これまではテックリードやアーキテクトなど、エンジニアとして、ヘンリーの複雑で巨大なドメイン（レセコン・電子カルテ）に技術面からアプローチしてきました。 VPoPという立場になり、プロダクトと事業をより俯瞰して見る中で、自分の中にあった「ある種の先入観」に気づくことができました。 今日はその言語化と、これからのヘンリーの開発組織が目指す「技術と事業の関係性」について書いてみようと思います。

この記事は

qiita.com

の1日目の記事です！

「技術戦略は事業戦略の従属変数である」と知らぬ間に思い込んでいた

先日のアーキテクチャカンファレンスでもお話ししましたが、私たちが向き合っているドメインは非常に複雑で、ソフトウェアの設計と組織の設計は、そのドメインの性質に応じて考える必要があります。

speakerdeck.com

これまで私は、「技術戦略」つまり「ある事業やプロダクトをどのような作り方で作るか」を決める際、事業戦略を一種の「前提条件（Input）」として捉えていました。 「事業として何を達成したいか（What）」がまずありきで、それを実現するための最適解として「どう作るか（How）」を策定する。依存の矢印は主に「事業 → 技術」への単方向である、というメンタルモデルを、無意識にもってしまっていたのです。

ヘンリーにおいても、マイクロサービス化の意思決定、モジュラーモノリスへの移行、Kotlin や GraphQL といった技術選定など、様々な意思決定に関わってきました。 これらは当然、ドメインの性質や採用市場、既存のコードベースといった制約の中で、その時点での事業目標を達成するためにベストだと考えた選択でした。

しかし、VPoPとして事業計画や予実管理、営業戦略といったレイヤーに深く触れるにつれ、この「単方向の依存」という認識自体が、実は自分自身の可能性、ひいてはエンジニアリング組織の可能性を狭めていたのではないか、と感じるようになりました。

技術戦略は「事業の選択肢」を創出する

今の私は、 「技術戦略と事業戦略は双方向の依存関係にあるべきだ」 と考えています。

事業戦略が技術戦略に要件を与えるのは当然ですが、同時に、技術戦略（現在のアーキテクチャ、チームのケイパビリティ、技術的負債の状況など）が、事業戦略に「リアリティ」と「選択肢」を与えます。

例えば、「小規模チームで作り切ればリスクは低いが時間が掛かる」、「大規模に体制を拡充するとリスクは高まるがうまくいけば時間を短縮できる」。 これは単なる開発リソース配分の話ではなく、事業のキャッシュフローや、市場参入のタイミングそのものを決定づける経営判断です。

また、もっと攻めの視点で言えば、優れた技術戦略は事業に新しいオプションを提供します。 私たちが進めているモジュラーモノリス化やドメイン駆動設計の実践は、単にコードを綺麗にするためだけのものではありません。

• 「このアーキテクチャになっているからこそ、競合他社が半年かかるところを、我々は既存モジュールの組み合わせで1ヶ月で検証できる」
• 「ここが疎結合になっているから、特定の診療科向けに機能を切り出して、別プランとして売り出すことができる」
• 「こういう作りにしておくと、最悪失敗してもこの部分だけを切り離して捨てられるので、ここは攻めよう」

このように、技術的な武器があるからこそ描ける事業戦略が存在します。 エンジニアが技術戦略を磨き込むことは、経営に対して「このルートなら、もっと速く、高く登れる」という登山ルートを提案することと同義なのです。

「不確実性」を飼いならすための対話

もちろん、技術的な挑戦には不確実性がつきものです。「想定より時間がかかる」「パフォーマンスや信頼性に悪影響が出た」といった事象は往々にして起こります。

大前提として、シンプルに技術戦略が間違っていたことを認めて、より良い技術戦略にブラッシュアップしていくことが、まず初めに考えることであるべきです。 しかし、それに加えて重要なのは、その事実を即座に事業戦略へフィードバックし、事業戦略そのものを書き換える勇気を持つことです。

事業、ビジネスサイド、開発など、いろんな視点があり、それぞれお互いの変数が相互に影響し合っていることを認め合い、一緒に悩み、計画を動的にアジャストしていく。 ヘンリーのような難易度の高いドメインで勝つためには、この「双方向の対話」のループを高速に回すことが重要だと思うようになりました。

一人のエンジニアとして

正直なところ、技術戦略と事業戦略の関係性をこのように捉えることができるようになったのは、VPoPになってからでした。それまでは、もちろん事業に貢献することを意識してやってきたつもりではありましたが、どこかで事業戦略自体は所与のものであるという考えをもってしまっていたような気がします。

今振り返れば、テックリードやエンジニアだった頃の自分も、「もっと良い作り方」だけでなく「もっと良い事業の登り方」を考えることができたはずだと感じています。 「事業のことは経営が決めること」と、無意識に自分の領分を技術領域に限定してしまっていたのです。

だからこそ、私はVPoPとして、エンジニアのみんなが「技術の枠」に閉じこもらず、事業戦略という変数すらもハックできるような環境を作っていきたいと考えています。

「エンジニアも全員PLを見て、営業指標を気にしながらコードを書け」みたいなことをいいたいわけではありません。 そうではなく、自分たちが普段向き合っているコードや仕様、開発プロセスの中に、実は事業を動かすための『隠れた変数』があるということを意識できるだけで、もっともっと大きな価値を生み出せるはずだと思っているのです。

ヘンリーでの開発は、降りてきた仕様を単に実装するような開発ではありませんが、それでも事業の登り方のようなレベルの話については「固定された定数（制約）」だと捉えがちです。 しかし、現場のエンジニアだけが知っている事実があるはずです。 現場でコードを書いているエンジニアこそが、プロダクトの「手触り」を一番知っています。

• 「今のアーキテクチャなら、実はこんな機能も低コストで実現できる」
• 「これだけのものを作るには、一度基盤を整備してから一気に作ったほうが速い」

といったような現場からのインサイトが、経営会議の決定をひっくり返すべきだと思っています。

今回は私のバックグラウンドがエンジニアであるため、技術戦略を例にお話ししましたが、これはエンジニアに限った話ではありません。 デザイナー、プロダクトマネージャー（PdM）、ドメインエキスパートなど、あらゆる職能の専門性が、事業戦略にとってクリティカルなインプットを生み出しうると考えています。

私はエンジニアであり、技術以外の領域にはどうしても見落としが生まれます。「専門性を持った人たちが、それぞれの専門性をリスペクトしながら、共通のゴールに向かって越境し合いながら走る」というチームが理想的なチームだと思っています。 だからこそ、エンジニア以外のメンバーからは、それぞれの専門性に基づいた「事業へのインプット」を与えてもらいたいし、エンジニアについても私の見落としに気付かせてもらいたい。それができるような情報流通やコミュニケーション土台を作っていきたいと考えています。

おわりに

「事業戦略は技術戦略に影響を与えるが、技術戦略もまた事業戦略に影響を与えるべき」 すごくふつうのことを言っているかもしれませんが、これを高いレベルで実践するのはなかなかに難しいことだと思います。

ヘンリーの開発組織は、仕様書通りに機能を作る工場ではありません。技術的な洞察をもって、事業の未来を提案するシンクタンクであり、それを最速で形にする実行部隊です。 複雑怪奇な社会課題を技術でハックし、そのレバレッジで事業を非連続に成長させる。そんな「エンジニアリング」を、私たちと一緒に楽しみませんか。

ヘンリーはソフトウェアエンジニアを積極的に募集しています！興味を持っていただけた方は、ぜひお話させてください！

jobs.henry.jp

【挑戦状】誰が書いたコードか当てまShow！！ 〜Kotlin Fest 2025 クイズコンテンツの解説〜

こんにちは。株式会社ヘンリーで開発者をやっているタケハタです。

ヘンリーは去る2025年11月1日に、Kotlin Fest 2025にことりスポンサーとしてスポンサーブースを出展しました。
イベント後に報告のエントリーで書いていたのですが、ブースでコンテンツとしてクイズを出題し、多くの方にチャレンジしていただきました。

そのクイズは「【挑戦状】誰が書いたコードか当てまShow！！」と題し、ヘンリーのエンジニア4人が同じ問題に対してコードを書き、どのコードを誰が書いたか当ててもらうというもので、非常に盛り上がり楽しんでいただくことができました。
そこで今回はそのクイズの紹介と答えの解説を書こうと思います。

正答は下の方に書きますので、この記事を読んでいただいているみなさまもぜひチャレンジしてみてください！

出題したクイズ

回答者紹介

まずはコードを書いた回答者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操作が多く必要で、書き方のクセが出やすい問題になっているところがポイントです。

選択肢(4人のエンジニアが書いたコード)

そしてそれぞれのエンジニアが書いたコードが以下の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: Kengo TODA

AはヘンリーのVPoT、VPoEであるKengo TODAが書いたコードでした。
ポイントとしてはすべての処理をメソッドチェーンで書いている点ですね。
「ひとこと」に書かれている「全ては流れであり、流れこそが全てである...」で始まる文章がヒントで、すべてがチェーンされているコードは、まるで流れに身を任せているかのような処理を表現しています。

正解された方からは以下のようコメントをいただきました。

• 全ては流れであり、流れこそが全てであるって書いてあるから全部メソッドチェーンしてる人だと思った
• 初手split("\n")してるのはJavaっぽいと思ったので、Kotlinを好きって書いてる人とは違うと思った

適切にヒントを読み取って正解されている方も多くいました！

B: タケハタ

Bは私、タケハタが書いたコードでした。
私は一応Kotlinの書籍も過去に出版していて、「ひとこと」にも書いている通り「ﾜﾀｼ Kotlin ﾁｮｯﾄﾃﾞｷﾙ」人間として名乗っています。
なのでgroupingByとfoldという普通の人がなかなか知らない関数を使用したり、PairのListをforEachIndexedで回す時に(name, score)で扱ったりと、Kotlinの機能をふんだんに使ったコードに仕上げました。

正解された方からは以下のようコメントをいただきました。

• Pairを(name, score)で扱ってるのはKotlin玄人っぽい感じがした
• buildStringはKotlin知ってる人っぽい

個人的な想定とは違ったのですが、StringBuilderではなくbuildStringを使うところにKotlinっぽさを感じてわかったという方がかなり多くいました！
やはりKotlin FestではKotlinが好きな方が多く来られていたので、こういった意見も興味深かったです。

C: creasty

Cはヘンリーの創業エンジニアであるcreastyが書いたコードでした。
このコードは正答率も低く、私もポイントがわからなかったのでなにがヒントだったのか後から本人に確認したのですが、なんと「なにも考えてなかった」という答えが返ってきました！
つまりプロフィールにはヒントがなにもなかったのです。どおりで正答率が低いわけですね。

ちなみに正解された方の中には

• 予測不能って書いてるからこれだと思った

とおっしゃっていた方もいたのですが、その方にはコードからなにか感じる予測不能な要素があったのかもしれません。

D: giiita

Dはヘンリーの料理長であるgiiitaが書いたコードでした。
ポイントとしては「ひとこと」にある「業務コードとしてレビューしてもらう気持ちで実装しました」と書かれている通り、コードに丁寧なコメントが書かれている点ですね。
あとは「好きな言語」にScalaを書いていることもポイントで、正解された方からは

• tailrec使うの絶対Scalaの人でしょ！

というコメントもいただきました。
このコードは正答率も一番高かったです！

あとはなぜか

• 「趣味: 土地間取り探し」でわかりました！

とおっしゃっていた方もおり、やはりコードにはエンジニアの様々な一面が表現されるものなのだなと、感動を覚えました。

クイズはいかがだったでしょうか？

本記事を読んでいただいたみなさまは、どのコードを誰が書いたかわかったでしょうか？

当日、ブースでこちらのクイズを多くの方が真剣に取り組み、楽しんでいただけました！
かなり難しいクイズになるかと思ったのですが、想像以上に多くの方が正解していて、参加者のみなさまの洞察力に驚きました。
今後もヘンリーでは様々なイベントで、楽しんでいただけるコンテンツを用意していきますので、ブースなどで見かけた際はぜひお立ち寄りください！

告知: Kotlin Fest 2025のアフターイベントを開催します！

最後に告知です。
ヘンリーでは11月25日(火)に、Kotlin Fest 2025の非公式アフターイベントとしてServer-Side Kotlin Night 2025を開催します！

henry.connpass.com

弊社からKotlin Festに登壇したnabeoも含む、計8名の登壇者でお送りするServer-Side Kotlinのイベントです。
当日直前まで申し込み可能ですので、ぜひこちらもご参加いただければと思います！

Kotlin Fest 2025 でスポンサー出展しました

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

2025年11月1日に開催された Kotlin Fest 2025 にことりスポンサーとしてスポンサーブースを出展しました。

当日のヘンリーのスタッフとブースの様子