はじめに こんにちは、医療プラットフォーム本部 SRE グループの大塚です。入社から 3 年ほど CLINICS のソフトウェアエンジニアとして開発に携わり、その中でプロダクトの安定稼働のための信頼性向上の技術的な取り込みも担当していました。 このたび、医療プラットフォームにおけるシステムの安定稼働と信頼性の確保がこれまで以上に求められる状況になり、正式に SRE チームを立ち上げました。医療機関向け SaaS である CLINICS の信頼性向上を主眼に発足し、立ち上げから SLO の策定や運用効率化などの成果が出ています。 この記事では、以下の内容についてお話しします。 医療プラットフォームにおける SRE チーム立ち上げの経緯 医療プラットフォームの中核である CLINICS について 医療プラットフォーム SRE チームの組織体制と役割 医療プラットフォーム SRE チームとしての展望 医療系 SaaS に興味があるエンジニアや、SRE としてのキャリアに関心がある方に向けて書いています。医療の発展にテクノロジーで貢献したいと考える方にとって参考になれば幸いです。 なぜ、医療プラットフォームで SRE チーム立ち上げたのか？ 医療プラットフォームの中核を担う CLINICS 医療プラットフォームは「医療ヘルスケアの未来をつくる」、「納得できる医療」の実現のために、様々な医療領域のプロダクトを提供しています。 その中でも、医療機関向け SaaS である CLINICS は高い信頼性が求められています。CLINICS は電子カルテ、予約管理、会計システム、オンライン診療など、診療所の基幹業務をトータルでサポートするクラウドサービスです。診療所の日々の運営に不可欠な業務を担うシステムであるため、高い信頼性と安定性が求められます。 また、CLINICS は医療機関と患者をつなぐ接点でもあり、システムには患者向けの API なども含まれます。そのため、システムの信頼性は患者の観点から見ても重要です。 CLINICS に求められる非機能要件 CLINICS は診療業務の基幹システムであり、診療所の業務をリアルタイムでサポートします。機能面の品質はもちろん、非機能要件（信頼性、可用性、パフォーマンス、保守性など）も極めて重要です。 例えば、システムの応答速度が遅くなり患者が受付や会計で長時間待たされると、医療機関だけでなく患者の体験も悪化します。そして、システム停止は診療所の業務が遂行できなくなることを意味します。 その結果、CLINICS サポートへの負荷増大や医療機関の信頼性低下などの影響を招きます。障害復旧対応で開発計画の変更が余儀なくされ、開発速度の低下を生じさせる一因になります。 しかし、CLINICS においてはこれらの非機能要件を満たすことは簡単ではありません。CLINICS は医療プラットフォームの中で最も歴史が長いプロダクトです。契約医療機関数は数千を超え、診療所の業務時間中は常に大量のデータとトラフィックを処理します。また、 CLINICS はレセコン（診療報酬請求事務を管理・自動化するシステム） などの複数のシステムで構成され、インフラなどの運用コストも高くなっています。 CLINICS を含む医療プラットフォームの成長に伴う技術課題 私自身も CLINICS のソフトウェアエンジニアとして開発に携わり、インフラに詳しいメンバー数人と共に可用性や信頼性に関するタスクを担当してきました。しかし、事業の成長に伴いシステム規模が拡大する中で、機能開発とシステム信頼性の両立が困難になっていました。 システムが深刻な状態には至っていませんでしたが、概ね以下のような課題を抱えていました。 長年の運用の中で非効率な DB へのクエリが蓄積し、処理に時間がかかる箇所が散見される トイル（SRE における反復的な運用作業）が増大し、運用業務の負荷が大きくなり、さらに悪循環を生む ライブラリ対応の優先度が下がり、 EOL 対応に追われている アラートの振り返りと暫定的な再発防止策は実施するが、根本対応までやりきれない また、これらの課題は、 Dentis や Pharms などの医療プラットフォーム内の他のプロダクトでも発生する可能性が高いです。他のプロダクトも CLINICS と同様の体制で開発と運用されており、すでに同じ課題が顕在化しつつあります。 CLINICS の医療機関数は日々増加しており、今後も事業拡大が見込まれます。それは他のプロダクトでも同様です。CLINICS に限らず医療プラットフォーム全体の成長を加速させるには、 信頼性の高い基盤構築に向き合えるチーム体制の構築が不可欠です。 医療プラットフォーム SRE チームの発足 信頼性課題などの中長期的な課題解決を目指す医療プラットフォーム SRE チームを発足しました。CLINICS に限らず、医療プラットフォーム全体を対応範囲としています。先程述べたように、システム信頼性の課題は医療プラットフォーム全体の課題であるためです。SRE チームが医療プラットフォームの横断組織として機能することで、システム信頼性に関する知見を集約します。 まずは、医療プラットフォームの中でも 中心的な役割を担う大規模なシステムである CLINICS の信頼性向上を最優先課題としています。SRE チームは CLINICS での取り組みの中で得た知見を医療プラットフォーム全体に還元します。 2025 年 4 月現在、SRE チームは CLINICS プロダクトに専任する形で活動しています。一般に知られている Embedded SRE です。この形態では、SRE チームメンバーが開発チームに直接入り込み、密に連携しながら信頼性向上に取り組みます。 CLINICS の信頼性向上を目指した SRE の取り組み ここからは CLINICS に対して現在行っている取り組みを説明します。 SRE チームの役割とミッション CLINICS における SRE チームのミッションは 「事業成長を支え、安定した開発基盤と顧客の信頼性を維持する文化、仕組みを構築すること」 です。SRE チームは信頼性向上に専念することで、開発チームは機能開発に集中できる状態を目指し、CLINICS プロダクトは事業と品質の両輪での成長を図ります。 前半で述べた課題に対応するために、SRE チームの立ち上げ時にまず 3 つの重点目標を設定しました。それぞれの目標に対する取り組みと一部の成果を紹介します。 目標 1: トイル排除と中長期課題へのシフト 課題: 日常的な運用作業（トイル）を自動化し、少人数での複数システムの運用ができ、足元の課題から中長期的な課題へ時間を使えるようにする 主な取り組み: 既存インフラリソースの Terraform import を実施 : 新しいインフラリソースは Terraform で作成されていました。しかし、リリース初期から存在するリソースは違い、インフラ運用の属人化を引き起こしていました。Terraform import を定常的に実施し、誰でも実装可能で、レビューしやすい運用を実現しました。 定常的に発生する運用業務の自動化 : CLINICS は運用するシステムも多く、月次の更新処理や定常的なスケールアップ対応など、数多くの運用タスクがありました。 AWS Step Functions などにより定常的な業務を自動化し、運用負荷軽減を実現しました。 目標 2: 改善文化の浸透 課題: ポストモーテム 文化(障害後の振り返り文化)を確立し、再発防止が適切に実行され、改善課題が積み上がり続ける状態から脱する。 主な取り組み: ポストモーテムの標準化: 以前から振り返りの文化はありましたが、定式化されておらず、各々が各自の形式で振り返りを実施していました。 チームでのナレッジ共有がなされず、障害対応での属人化の要因となっていました。体系的に障害を振り返る仕組みを作り、CLINICS のチーム全体に展開することで、チームでの障害対応力を向上させました。 アラート改善を定常的に回す仕組みの策定 : 緊急性が高い事象や顧客とのコミュニケーションが必要な事象はアラートの検知時に迅速に解決できていました。しかし、タイミングの問題で発生する瑣末なフロントエンドのエラーなどは「オオカミ少年」になり、アラートを定期的に検知していました。開発チーム全体で根本対応できるものは実施する、すぐに解決が難しいものは一定期間無視するなど、対応ルールを精緻化しました。 目標 3: SLO による信頼性可視化 課題: CLINICS の関係者が納得できる 信頼性の指標(SLO) を構築し、改善施策はこれらの指標改善を優先する 主な取り組み: 重要な顧客体験 (Critical User Journey) の策定と SLO ダッシュボードの作成: CUJ(Critical User Journey) を特定し、Datadog 上に SLO のダッシュボードを作成しました。フロントエンドのパフォーマンスモニタリングを目的とした Datadog RUM(Realtime User Monitoring) などを導入することで、オブザーバビリティの強化も実現し、顧客体験をより厳密にトラッキングできるようにしました。 SLO モニタリングの実施: 作成したダッシュボードをもとに受付、診察、会計など 3 つの顧客体験について、可用性、レイテンシー、エラー率の目標値を設定しました。閾値の調整やエラーバジェットのモニタリングを定期実施し、アラート改善に役立てる取り組みを実現しました。 SRE チームにおけるその他の取り組み 上記の取り組み以外にも、SRE の一般的な以下の業務にも取り組んでいます。 事業成長を見越したキャパシティプランニング システムのモニタリングによる事前の課題発見 障害対応プロセスの改善 インフラコストの削減 DB 等のパフォーマンス問題の改善 ライブラリ対応やセキュリティ対応の効率化 アーキテクチャとリリースフローの改善…など SRE チームの取り組みの成果が実を結び始める これらの取り組みにより、CLINICS 開発メンバー全体（開発チームを含む）の運用負担が軽減されました。 信頼性の維持をしつつ、目の前の課題だけでなく将来を見据えた取り組みに注力する余裕が生まれています。開発チームとの協業を強化し、機能開発時に SLO の組み込みを進め、改善目標の指標としても活用する計画を立てています。他にも障害時の信頼性向上を目的とした Sidekiq Pro の導入など、信頼性向上にも取り組んでいます。 このように私たちの取り組みが徐々に成果を上げ始めています。 開発チームと SRE チームの協働により、当初実現したかった CLINICS の機能開発とシステム信頼性の両立が実現しつつあります 。今後もこの連携と SRE の取り組みを深め、より安定したサービス提供を目指してまいります。 医療プラットフォーム SRE チームとしての展望 ここまでは、CLINICS における SRE の取り組みを書いてきました。ここからは、今後医療プラットフォーム全体に SRE としてどのように貢献しようとしているのかの展望を述べます。 医療プラットフォーム全体への SRE ノウハウ展開 CLINICS での知見を活かし、今後、 Dentis や Pharms といった医療プラットフォームの他のプロダクトにも SRE のノウハウを展開していく予定です。 CLINICS は規模が大きく、信頼性要求も高いため、培ったノウハウは他のプロダクトにも十分応用できると考えています。ノウハウを展開することで、医療プラットフォーム全体での信頼性の底上げを実現します。 プロダクトの拡充に対して柔軟に対応できる仕組みづくり 医療プラットフォームは、「医療ヘルスケアの未来をつくる」というミッション実現のために、今後も新規開発や M&A によるプロダクト増加も見込まれます。 新たなプロダクトが加わった際にも、医療プラットフォーム標準の信頼性水準に迅速に引き上げることが重要です。 SRE チームは、医療プラットフォームに属する全てのプロダクトが高い信頼性を維持できる体制を目指します。 事業運営に関わる全関係者が納得する SRE 文化の醸成 SRE の取り組みは開発チームだけのものではありません。ポストモーテムや開発優先度の判断において、非開発メンバーの視点は不可欠です。プロダクトマネージャーや QA メンバーはもちろん、カスタマーサクセス・サポートチームも信頼性の考え方を共有することで、「なぜ機能開発より安定性向上を優先すべきか」といった判断に事業全体の納得感が生まれます。 SLO などの指標は単なる技術的な数値ではなく、顧客体験と事業成長を支える重要な要素です。医療プラットフォーム全体で信頼性と機能開発のバランスを適切に取りながら前進できる文化を育むこと、これも SRE チームの重要なミッションの一つです。 まとめ：医療ヘルスケアの未来を支える SRE 医療プラットフォームの SRE 立ち上げについてお伝えしました。医療プラットフォームの成長と「医療ヘルスケアの未来」創造のために、SRE による信頼性確保は欠かせないミッションです。 SRE としても医療プラットフォームとしても、挑戦したいことは山積みです。事業成長を加速し、医療機関と患者の体験を向上させるために、SRE の活動は不可欠です。 何より、「医療ヘルスケアの未来をつくる」というミッションに共感し、技術で医療の課題解決に貢献したいという情熱を持つ方をお待ちしています。私たちと一緒にこのミッションを実現しませんか？ 興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは、医療プラットフォーム本部 SRE グループの大塚です。入社から 3 年ほど CLINICS のソフトウェアエンジニアとして開発に携わり、その中でプロダクトの安定稼働のための信頼性向上の技術的な取り込みも担当していました。 このたび、医療プラットフォームにおけるシステムの安定稼働と信頼性の確保がこれまで以上に求められる状況になり、正式に SRE チームを立ち上げました。医療機関向け SaaS である CLINICS の信頼性向上を主眼に発足し、立ち上げから SLO の策定や運用効率化などの成果が出ています。 この記事では、以下の内容についてお話しします。 医療プラットフォームにおける SRE チーム立ち上げの経緯 医療プラットフォームの中核である CLINICS について 医療プラットフォーム SRE チームの組織体制と役割 医療プラットフォーム SRE チームとしての展望 医療系 SaaS に興味があるエンジニアや、SRE としてのキャリアに関心がある方に向けて書いています。医療の発展にテクノロジーで貢献したいと考える方にとって参考になれば幸いです。 なぜ、医療プラットフォームで SRE チーム立ち上げたのか？ 医療プラットフォームの中核を担う CLINICS 医療プラットフォームは「医療ヘルスケアの未来をつくる」、「納得できる医療」の実現のために、様々な医療領域のプロダクトを提供しています。 その中でも、医療機関向け SaaS である CLINICS は高い信頼性が求められています。CLINICS は電子カルテ、予約管理、会計システム、オンライン診療など、診療所の基幹業務をトータルでサポートするクラウドサービスです。診療所の日々の運営に不可欠な業務を担うシステムであるため、高い信頼性と安定性が求められます。 また、CLINICS は医療機関と患者をつなぐ接点でもあり、システムには患者向けの API なども含まれます。そのため、システムの信頼性は患者の観点から見ても重要です。 CLINICS に求められる非機能要件 CLINICS は診療業務の基幹システムであり、診療所の業務をリアルタイムでサポートします。機能面の品質はもちろん、非機能要件（信頼性、可用性、パフォーマンス、保守性など）も極めて重要です。 例えば、システムの応答速度が遅くなり患者が受付や会計で長時間待たされると、医療機関だけでなく患者の体験も悪化します。そして、システム停止は診療所の業務が遂行できなくなることを意味します。 その結果、CLINICS サポートへの負荷増大や医療機関の信頼性低下などの影響を招きます。障害復旧対応で開発計画の変更が余儀なくされ、開発速度の低下を生じさせる一因になります。 しかし、CLINICS においてはこれらの非機能要件を満たすことは簡単ではありません。CLINICS は医療プラットフォームの中で最も歴史が長いプロダクトです。契約医療機関数は数千を超え、診療所の業務時間中は常に大量のデータとトラフィックを処理します。また、 CLINICS はレセコン（診療報酬請求事務を管理・自動化するシステム） などの複数のシステムで構成され、インフラなどの運用コストも高くなっています。 CLINICS を含む医療プラットフォームの成長に伴う技術課題 私自身も CLINICS のソフトウェアエンジニアとして開発に携わり、インフラに詳しいメンバー数人と共に可用性や信頼性に関するタスクを担当してきました。しかし、事業の成長に伴いシステム規模が拡大する中で、機能開発とシステム信頼性の両立が困難になっていました。 システムが深刻な状態には至っていませんでしたが、概ね以下のような課題を抱えていました。 長年の運用の中で非効率な DB へのクエリが蓄積し、処理に時間がかかる箇所が散見される トイル（SRE における反復的な運用作業）が増大し、運用業務の負荷が大きくなり、さらに悪循環を生む ライブラリ対応の優先度が下がり、 EOL 対応に追われている アラートの振り返りと暫定的な再発防止策は実施するが、根本対応までやりきれない また、これらの課題は、 Dentis や Pharms などの医療プラットフォーム内の他のプロダクトでも発生する可能性が高いです。他のプロダクトも CLINICS と同様の体制で開発と運用されており、すでに同じ課題が顕在化しつつあります。 CLINICS の医療機関数は日々増加しており、今後も事業拡大が見込まれます。それは他のプロダクトでも同様です。CLINICS に限らず医療プラットフォーム全体の成長を加速させるには、 信頼性の高い基盤構築に向き合えるチーム体制の構築が不可欠です。 医療プラットフォーム SRE チームの発足 信頼性課題などの中長期的な課題解決を目指す医療プラットフォーム SRE チームを発足しました。CLINICS に限らず、医療プラットフォーム全体を対応範囲としています。先程述べたように、システム信頼性の課題は医療プラットフォーム全体の課題であるためです。SRE チームが医療プラットフォームの横断組織として機能することで、システム信頼性に関する知見を集約します。 まずは、医療プラットフォームの中でも 中心的な役割を担う大規模なシステムである CLINICS の信頼性向上を最優先課題としています。SRE チームは CLINICS での取り組みの中で得た知見を医療プラットフォーム全体に還元します。 2025 年 4 月現在、SRE チームは CLINICS プロダクトに専任する形で活動しています。一般に知られている Embedded SRE です。この形態では、SRE チームメンバーが開発チームに直接入り込み、密に連携しながら信頼性向上に取り組みます。 CLINICS の信頼性向上を目指した SRE の取り組み ここからは CLINICS に対して現在行っている取り組みを説明します。 SRE チームの役割とミッション CLINICS における SRE チームのミッションは 「事業成長を支え、安定した開発基盤と顧客の信頼性を維持する文化、仕組みを構築すること」 です。SRE チームは信頼性向上に専念することで、開発チームは機能開発に集中できる状態を目指し、CLINICS プロダクトは事業と品質の両輪での成長を図ります。 前半で述べた課題に対応するために、SRE チームの立ち上げ時にまず 3 つの重点目標を設定しました。それぞれの目標に対する取り組みと一部の成果を紹介します。 目標 1: トイル排除と中長期課題へのシフト 課題: 日常的な運用作業（トイル）を自動化し、少人数での複数システムの運用ができ、足元の課題から中長期的な課題へ時間を使えるようにする 主な取り組み: 既存インフラリソースの Terraform import を実施 : 新しいインフラリソースは Terraform で作成されていました。しかし、リリース初期から存在するリソースは違い、インフラ運用の属人化を引き起こしていました。Terraform import を定常的に実施し、誰でも実装可能で、レビューしやすい運用を実現しました。 定常的に発生する運用業務の自動化 : CLINICS は運用するシステムも多く、月次の更新処理や定常的なスケールアップ対応など、数多くの運用タスクがありました。 AWS Step Functions などにより定常的な業務を自動化し、運用負荷軽減を実現しました。 目標 2: 改善文化の浸透 課題: ポストモーテム 文化(障害後の振り返り文化)を確立し、再発防止が適切に実行され、改善課題が積み上がり続ける状態から脱する。 主な取り組み: ポストモーテムの標準化: 以前から振り返りの文化はありましたが、定式化されておらず、各々が各自の形式で振り返りを実施していました。 チームでのナレッジ共有がなされず、障害対応での属人化の要因となっていました。体系的に障害を振り返る仕組みを作り、CLINICS のチーム全体に展開することで、チームでの障害対応力を向上させました。 アラート改善を定常的に回す仕組みの策定 : 緊急性が高い事象や顧客とのコミュニケーションが必要な事象はアラートの検知時に迅速に解決できていました。しかし、タイミングの問題で発生する瑣末なフロントエンドのエラーなどは「オオカミ少年」になり、アラートを定期的に検知していました。開発チーム全体で根本対応できるものは実施する、すぐに解決が難しいものは一定期間無視するなど、対応ルールを精緻化しました。 目標 3: SLO による信頼性可視化 課題: CLINICS の関係者が納得できる 信頼性の指標(SLO) を構築し、改善施策はこれらの指標改善を優先する 主な取り組み: 重要な顧客体験 (Critical User Journey) の策定と SLO ダッシュボードの作成: CUJ(Critical User Journey) を特定し、Datadog 上に SLO のダッシュボードを作成しました。フロントエンドのパフォーマンスモニタリングを目的とした Datadog RUM(Realtime User Monitoring) などを導入することで、オブザーバビリティの強化も実現し、顧客体験をより厳密にトラッキングできるようにしました。 SLO モニタリングの実施: 作成したダッシュボードをもとに受付、診察、会計など 3 つの顧客体験について、可用性、レイテンシー、エラー率の目標値を設定しました。閾値の調整やエラーバジェットのモニタリングを定期実施し、アラート改善に役立てる取り組みを実現しました。 SRE チームにおけるその他の取り組み 上記の取り組み以外にも、SRE の一般的な以下の業務にも取り組んでいます。 事業成長を見越したキャパシティプランニング システムのモニタリングによる事前の課題発見 障害対応プロセスの改善 インフラコストの削減 DB 等のパフォーマンス問題の改善 ライブラリ対応やセキュリティ対応の効率化 アーキテクチャとリリースフローの改善…など SRE チームの取り組みの成果が実を結び始める これらの取り組みにより、CLINICS 開発メンバー全体（開発チームを含む）の運用負担が軽減されました。 信頼性の維持をしつつ、目の前の課題だけでなく将来を見据えた取り組みに注力する余裕が生まれています。開発チームとの協業を強化し、機能開発時に SLO の組み込みを進め、改善目標の指標としても活用する計画を立てています。他にも障害時の信頼性向上を目的とした Sidekiq Pro の導入など、信頼性向上にも取り組んでいます。 このように私たちの取り組みが徐々に成果を上げ始めています。 開発チームと SRE チームの協働により、当初実現したかった CLINICS の機能開発とシステム信頼性の両立が実現しつつあります 。今後もこの連携と SRE の取り組みを深め、より安定したサービス提供を目指してまいります。 医療プラットフォーム SRE チームとしての展望 ここまでは、CLINICS における SRE の取り組みを書いてきました。ここからは、今後医療プラットフォーム全体に SRE としてどのように貢献しようとしているのかの展望を述べます。 医療プラットフォーム全体への SRE ノウハウ展開 CLINICS での知見を活かし、今後、 Dentis や Pharms といった医療プラットフォームの他のプロダクトにも SRE のノウハウを展開していく予定です。 CLINICS は規模が大きく、信頼性要求も高いため、培ったノウハウは他のプロダクトにも十分応用できると考えています。ノウハウを展開することで、医療プラットフォーム全体での信頼性の底上げを実現します。 プロダクトの拡充に対して柔軟に対応できる仕組みづくり 医療プラットフォームは、「医療ヘルスケアの未来をつくる」というミッション実現のために、今後も新規開発や M&A によるプロダクト増加も見込まれます。 新たなプロダクトが加わった際にも、医療プラットフォーム標準の信頼性水準に迅速に引き上げることが重要です。 SRE チームは、医療プラットフォームに属する全てのプロダクトが高い信頼性を維持できる体制を目指します。 事業運営に関わる全関係者が納得する SRE 文化の醸成 SRE の取り組みは開発チームだけのものではありません。ポストモーテムや開発優先度の判断において、非開発メンバーの視点は不可欠です。プロダクトマネージャーや QA メンバーはもちろん、カスタマーサクセス・サポートチームも信頼性の考え方を共有することで、「なぜ機能開発より安定性向上を優先すべきか」といった判断に事業全体の納得感が生まれます。 SLO などの指標は単なる技術的な数値ではなく、顧客体験と事業成長を支える重要な要素です。医療プラットフォーム全体で信頼性と機能開発のバランスを適切に取りながら前進できる文化を育むこと、これも SRE チームの重要なミッションの一つです。 まとめ：医療ヘルスケアの未来を支える SRE 医療プラットフォームの SRE 立ち上げについてお伝えしました。医療プラットフォームの成長と「医療ヘルスケアの未来」創造のために、SRE による信頼性確保は欠かせないミッションです。 SRE としても医療プラットフォームとしても、挑戦したいことは山積みです。事業成長を加速し、医療機関と患者の体験を向上させるために、SRE の活動は不可欠です。 何より、「医療ヘルスケアの未来をつくる」というミッションに共感し、技術で医療の課題解決に貢献したいという情熱を持つ方をお待ちしています。私たちと一緒にこのミッションを実現しませんか？ 興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 https://www.medley.jp/jobs/

はじめに こんにちは、医療プラットフォーム本部 SRE グループの大塚です。入社から 3 年ほど CLINICS のソフトウェアエンジニアとして開発に携わり、その中でプロダクトの安定稼働のための信頼性向上の技術的な取り込みも担当していました。 このたび、医療プラットフォームにおけるシステムの安定稼働と信頼性の確保がこれまで以上に求められる状況になり、正式に SRE チームを立ち上げました。医療機関向け SaaS である CLINICS の信頼性向上を主眼に発足し、立ち上げから SLO の策定や運用効率化などの成果が出ています。 この記事では、以下の内容についてお話しします。 医療プラットフォームにおける SRE チーム立ち上げの経緯 医療プラットフォームの中核である CLINICS について 医療プラットフォーム SRE チームの組織体制と役割 医療プラットフォーム SRE チームとしての展望 医療系 SaaS に興味があるエンジニアや、SRE としてのキャリアに関心がある方に向けて書いています。医療の発展にテクノロジーで貢献したいと考える方にとって参考になれば幸いです。 なぜ、医療プラットフォームで SRE チーム立ち上げたのか？ 医療プラットフォームの中核を担う CLINICS 医療プラットフォームは「医療ヘルスケアの未来をつくる」、「納得できる医療」の実現のために、様々な医療領域のプロダクトを提供しています。 その中でも、医療機関向け SaaS である CLINICS は高い信頼性が求められています。CLINICS は電子カルテ、予約管理、会計システム、オンライン診療など、診療所の基幹業務をトータルでサポートするクラウドサービスです。診療所の日々の運営に不可欠な業務を担うシステムであるため、高い信頼性と安定性が求められます。 また、CLINICS は医療機関と患者をつなぐ接点でもあり、システムには患者向けの API なども含まれます。そのため、システムの信頼性は患者の観点から見ても重要です。 CLINICS に求められる非機能要件 CLINICS は診療業務の基幹システムであり、診療所の業務をリアルタイムでサポートします。機能面の品質はもちろん、非機能要件（信頼性、可用性、パフォーマンス、保守性など）も極めて重要です。 例えば、システムの応答速度が遅くなり患者が受付や会計で長時間待たされると、医療機関だけでなく患者の体験も悪化します。そして、システム停止は診療所の業務が遂行できなくなることを意味します。 その結果、CLINICS サポートへの負荷増大や医療機関の信頼性低下などの影響を招きます。障害復旧対応で開発計画の変更が余儀なくされ、開発速度の低下を生じさせる一因になります。 しかし、CLINICS においてはこれらの非機能要件を満たすことは簡単ではありません。CLINICS は医療プラットフォームの中で最も歴史が長いプロダクトです。契約医療機関数は数千を超え、診療所の業務時間中は常に大量のデータとトラフィックを処理します。また、 CLINICS はレセコン（診療報酬請求事務を管理・自動化するシステム） などの複数のシステムで構成され、インフラなどの運用コストも高くなっています。 CLINICS を含む医療プラットフォームの成長に伴う技術課題 私自身も CLINICS のソフトウェアエンジニアとして開発に携わり、インフラに詳しいメンバー数人と共に可用性や信頼性に関するタスクを担当してきました。しかし、事業の成長に伴いシステム規模が拡大する中で、機能開発とシステム信頼性の両立が困難になっていました。 システムが深刻な状態には至っていませんでしたが、概ね以下のような課題を抱えていました。 長年の運用の中で非効率な DB へのクエリが蓄積し、処理に時間がかかる箇所が散見される トイル（SRE における反復的な運用作業）が増大し、運用業務の負荷が大きくなり、さらに悪循環を生む ライブラリ対応の優先度が下がり、 EOL 対応に追われている アラートの振り返りと暫定的な再発防止策は実施するが、根本対応までやりきれない また、これらの課題は、 Dentis や Pharms などの医療プラットフォーム内の他のプロダクトでも発生する可能性が高いです。他のプロダクトも CLINICS と同様の体制で開発と運用されており、すでに同じ課題が顕在化しつつあります。 CLINICS の医療機関数は日々増加しており、今後も事業拡大が見込まれます。それは他のプロダクトでも同様です。CLINICS に限らず医療プラットフォーム全体の成長を加速させるには、 信頼性の高い基盤構築に向き合えるチーム体制の構築が不可欠です。 医療プラットフォーム SRE チームの発足 信頼性課題などの中長期的な課題解決を目指す医療プラットフォーム SRE チームを発足しました。CLINICS に限らず、医療プラットフォーム全体を対応範囲としています。先程述べたように、システム信頼性の課題は医療プラットフォーム全体の課題であるためです。SRE チームが医療プラットフォームの横断組織として機能することで、システム信頼性に関する知見を集約します。 まずは、医療プラットフォームの中でも 中心的な役割を担う大規模なシステムである CLINICS の信頼性向上を最優先課題としています。SRE チームは CLINICS での取り組みの中で得た知見を医療プラットフォーム全体に還元します。 2025 年 4 月現在、SRE チームは CLINICS プロダクトに専任する形で活動しています。一般に知られている Embedded SRE です。この形態では、SRE チームメンバーが開発チームに直接入り込み、密に連携しながら信頼性向上に取り組みます。 CLINICS の信頼性向上を目指した SRE の取り組み ここからは CLINICS に対して現在行っている取り組みを説明します。 SRE チームの役割とミッション CLINICS における SRE チームのミッションは 「事業成長を支え、安定した開発基盤と顧客の信頼性を維持する文化、仕組みを構築すること」 です。SRE チームは信頼性向上に専念することで、開発チームは機能開発に集中できる状態を目指し、CLINICS プロダクトは事業と品質の両輪での成長を図ります。 前半で述べた課題に対応するために、SRE チームの立ち上げ時にまず 3 つの重点目標を設定しました。それぞれの目標に対する取り組みと一部の成果を紹介します。 目標 1: トイル排除と中長期課題へのシフト 課題: 日常的な運用作業（トイル）を自動化し、少人数での複数システムの運用ができ、足元の課題から中長期的な課題へ時間を使えるようにする 主な取り組み: 既存インフラリソースの Terraform import を実施 : 新しいインフラリソースは Terraform で作成されていました。しかし、リリース初期から存在するリソースは違い、インフラ運用の属人化を引き起こしていました。Terraform import を定常的に実施し、誰でも実装可能で、レビューしやすい運用を実現しました。 定常的に発生する運用業務の自動化 : CLINICS は運用するシステムも多く、月次の更新処理や定常的なスケールアップ対応など、数多くの運用タスクがありました。 AWS Step Functions などにより定常的な業務を自動化し、運用負荷軽減を実現しました。 目標 2: 改善文化の浸透 課題: ポストモーテム 文化(障害後の振り返り文化)を確立し、再発防止が適切に実行され、改善課題が積み上がり続ける状態から脱する。 主な取り組み: ポストモーテムの標準化: 以前から振り返りの文化はありましたが、定式化されておらず、各々が各自の形式で振り返りを実施していました。 チームでのナレッジ共有がなされず、障害対応での属人化の要因となっていました。体系的に障害を振り返る仕組みを作り、CLINICS のチーム全体に展開することで、チームでの障害対応力を向上させました。 アラート改善を定常的に回す仕組みの策定 : 緊急性が高い事象や顧客とのコミュニケーションが必要な事象はアラートの検知時に迅速に解決できていました。しかし、タイミングの問題で発生する瑣末なフロントエンドのエラーなどは「オオカミ少年」になり、アラートを定期的に検知していました。開発チーム全体で根本対応できるものは実施する、すぐに解決が難しいものは一定期間無視するなど、対応ルールを精緻化しました。 目標 3: SLO による信頼性可視化 課題: CLINICS の関係者が納得できる 信頼性の指標(SLO) を構築し、改善施策はこれらの指標改善を優先する 主な取り組み: 重要な顧客体験 (Critical User Journey) の策定と SLO ダッシュボードの作成: CUJ(Critical User Journey) を特定し、Datadog 上に SLO のダッシュボードを作成しました。フロントエンドのパフォーマンスモニタリングを目的とした Datadog RUM(Realtime User Monitoring) などを導入することで、オブザーバビリティの強化も実現し、顧客体験をより厳密にトラッキングできるようにしました。 SLO モニタリングの実施: 作成したダッシュボードをもとに受付、診察、会計など 3 つの顧客体験について、可用性、レイテンシー、エラー率の目標値を設定しました。閾値の調整やエラーバジェットのモニタリングを定期実施し、アラート改善に役立てる取り組みを実現しました。 SRE チームにおけるその他の取り組み 上記の取り組み以外にも、SRE の一般的な以下の業務にも取り組んでいます。 事業成長を見越したキャパシティプランニング システムのモニタリングによる事前の課題発見 障害対応プロセスの改善 インフラコストの削減 DB 等のパフォーマンス問題の改善 ライブラリ対応やセキュリティ対応の効率化 アーキテクチャとリリースフローの改善…など SRE チームの取り組みの成果が実を結び始める これらの取り組みにより、CLINICS 開発メンバー全体（開発チームを含む）の運用負担が軽減されました。 信頼性の維持をしつつ、目の前の課題だけでなく将来を見据えた取り組みに注力する余裕が生まれています。開発チームとの協業を強化し、機能開発時に SLO の組み込みを進め、改善目標の指標としても活用する計画を立てています。他にも障害時の信頼性向上を目的とした Sidekiq Pro の導入など、信頼性向上にも取り組んでいます。 このように私たちの取り組みが徐々に成果を上げ始めています。 開発チームと SRE チームの協働により、当初実現したかった CLINICS の機能開発とシステム信頼性の両立が実現しつつあります 。今後もこの連携と SRE の取り組みを深め、より安定したサービス提供を目指してまいります。 医療プラットフォーム SRE チームとしての展望 ここまでは、CLINICS における SRE の取り組みを書いてきました。ここからは、今後医療プラットフォーム全体に SRE としてどのように貢献しようとしているのかの展望を述べます。 医療プラットフォーム全体への SRE ノウハウ展開 CLINICS での知見を活かし、今後、 Dentis や Pharms といった医療プラットフォームの他のプロダクトにも SRE のノウハウを展開していく予定です。 CLINICS は規模が大きく、信頼性要求も高いため、培ったノウハウは他のプロダクトにも十分応用できると考えています。ノウハウを展開することで、医療プラットフォーム全体での信頼性の底上げを実現します。 プロダクトの拡充に対して柔軟に対応できる仕組みづくり 医療プラットフォームは、「医療ヘルスケアの未来をつくる」というミッション実現のために、今後も新規開発や M&A によるプロダクト増加も見込まれます。 新たなプロダクトが加わった際にも、医療プラットフォーム標準の信頼性水準に迅速に引き上げることが重要です。 SRE チームは、医療プラットフォームに属する全てのプロダクトが高い信頼性を維持できる体制を目指します。 事業運営に関わる全関係者が納得する SRE 文化の醸成 SRE の取り組みは開発チームだけのものではありません。ポストモーテムや開発優先度の判断において、非開発メンバーの視点は不可欠です。プロダクトマネージャーや QA メンバーはもちろん、カスタマーサクセス・サポートチームも信頼性の考え方を共有することで、「なぜ機能開発より安定性向上を優先すべきか」といった判断に事業全体の納得感が生まれます。 SLO などの指標は単なる技術的な数値ではなく、顧客体験と事業成長を支える重要な要素です。医療プラットフォーム全体で信頼性と機能開発のバランスを適切に取りながら前進できる文化を育むこと、これも SRE チームの重要なミッションの一つです。 まとめ：医療ヘルスケアの未来を支える SRE 医療プラットフォームの SRE 立ち上げについてお伝えしました。医療プラットフォームの成長と「医療ヘルスケアの未来」創造のために、SRE による信頼性確保は欠かせないミッションです。 SRE としても医療プラットフォームとしても、挑戦したいことは山積みです。事業成長を加速し、医療機関と患者の体験を向上させるために、SRE の活動は不可欠です。 何より、「医療ヘルスケアの未来をつくる」というミッションに共感し、技術で医療の課題解決に貢献したいという情熱を持つ方をお待ちしています。私たちと一緒にこのミッションを実現しませんか？ 興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 https://www.medley.jp/jobs/

はじめに こんにちは、医療プラットフォーム本部 SRE グループの大塚です。入社から 3 年ほど CLINICS のソフトウェアエンジニアとして開発に携わり、その中でプロダクトの安定稼働のための信頼性向上の技術的な取り込みも担当していました。 このたび、医療プラットフォームにおけるシステムの安定稼働と信頼性の確保がこれまで以上に求められる状況になり、正式に SRE チームを立ち上げました。医療機関向け SaaS である CLINICS の信頼性向上を主眼に発足し、立ち上げから SLO の策定や運用効率化などの成果が出ています。 この記事では、以下の内容についてお話しします。 医療プラットフォームにおける SRE チーム立ち上げの経緯 医療プラットフォームの中核である CLINICS について 医療プラットフォーム SRE チームの組織体制と役割 医療プラットフォーム SRE チームとしての展望 医療系 SaaS に興味があるエンジニアや、SRE としてのキャリアに関心がある方に向けて書いています。医療の発展にテクノロジーで貢献したいと考える方にとって参考になれば幸いです。 なぜ、医療プラットフォームで SRE チーム立ち上げたのか？ 医療プラットフォームの中核を担う CLINICS 医療プラットフォームは「医療ヘルスケアの未来をつくる」、「納得できる医療」の実現のために、様々な医療領域のプロダクトを提供しています。 その中でも、医療機関向け SaaS である CLINICS は高い信頼性が求められています。CLINICS は電子カルテ、予約管理、会計システム、オンライン診療など、診療所の基幹業務をトータルでサポートするクラウドサービスです。診療所の日々の運営に不可欠な業務を担うシステムであるため、高い信頼性と安定性が求められます。 また、CLINICS は医療機関と患者をつなぐ接点でもあり、システムには患者向けの API なども含まれます。そのため、システムの信頼性は患者の観点から見ても重要です。 CLINICS に求められる非機能要件 CLINICS は診療業務の基幹システムであり、診療所の業務をリアルタイムでサポートします。機能面の品質はもちろん、非機能要件（信頼性、可用性、パフォーマンス、保守性など）も極めて重要です。 例えば、システムの応答速度が遅くなり患者が受付や会計で長時間待たされると、医療機関だけでなく患者の体験も悪化します。そして、システム停止は診療所の業務が遂行できなくなることを意味します。 その結果、CLINICS サポートへの負荷増大や医療機関の信頼性低下などの影響を招きます。障害復旧対応で開発計画の変更が余儀なくされ、開発速度の低下を生じさせる一因になります。 しかし、CLINICS においてはこれらの非機能要件を満たすことは簡単ではありません。CLINICS は医療プラットフォームの中で最も歴史が長いプロダクトです。契約医療機関数は数千を超え、診療所の業務時間中は常に大量のデータとトラフィックを処理します。また、 CLINICS はレセコン（診療報酬請求事務を管理・自動化するシステム） などの複数のシステムで構成され、インフラなどの運用コストも高くなっています。 CLINICS を含む医療プラットフォームの成長に伴う技術課題 私自身も CLINICS のソフトウェアエンジニアとして開発に携わり、インフラに詳しいメンバー数人と共に可用性や信頼性に関するタスクを担当してきました。しかし、事業の成長に伴いシステム規模が拡大する中で、機能開発とシステム信頼性の両立が困難になっていました。 システムが深刻な状態には至っていませんでしたが、概ね以下のような課題を抱えていました。 長年の運用の中で非効率な DB へのクエリが蓄積し、処理に時間がかかる箇所が散見される トイル（SRE における反復的な運用作業）が増大し、運用業務の負荷が大きくなり、さらに悪循環を生む ライブラリ対応の優先度が下がり、 EOL 対応に追われている アラートの振り返りと暫定的な再発防止策は実施するが、根本対応までやりきれない また、これらの課題は、 Dentis や Pharms などの医療プラットフォーム内の他のプロダクトでも発生する可能性が高いです。他のプロダクトも CLINICS と同様の体制で開発と運用されており、すでに同じ課題が顕在化しつつあります。 CLINICS の医療機関数は日々増加しており、今後も事業拡大が見込まれます。それは他のプロダクトでも同様です。CLINICS に限らず医療プラットフォーム全体の成長を加速させるには、 信頼性の高い基盤構築に向き合えるチーム体制の構築が不可欠です。 医療プラットフォーム SRE チームの発足 信頼性課題などの中長期的な課題解決を目指す医療プラットフォーム SRE チームを発足しました。CLINICS に限らず、医療プラットフォーム全体を対応範囲としています。先程述べたように、システム信頼性の課題は医療プラットフォーム全体の課題であるためです。SRE チームが医療プラットフォームの横断組織として機能することで、システム信頼性に関する知見を集約します。 まずは、医療プラットフォームの中でも 中心的な役割を担う大規模なシステムである CLINICS の信頼性向上を最優先課題としています。SRE チームは CLINICS での取り組みの中で得た知見を医療プラットフォーム全体に還元します。 2025 年 4 月現在、SRE チームは CLINICS プロダクトに専任する形で活動しています。一般に知られている Embedded SRE です。この形態では、SRE チームメンバーが開発チームに直接入り込み、密に連携しながら信頼性向上に取り組みます。 CLINICS の信頼性向上を目指した SRE の取り組み ここからは CLINICS に対して現在行っている取り組みを説明します。 SRE チームの役割とミッション CLINICS における SRE チームのミッションは 「事業成長を支え、安定した開発基盤と顧客の信頼性を維持する文化、仕組みを構築すること」 です。SRE チームは信頼性向上に専念することで、開発チームは機能開発に集中できる状態を目指し、CLINICS プロダクトは事業と品質の両輪での成長を図ります。 前半で述べた課題に対応するために、SRE チームの立ち上げ時にまず 3 つの重点目標を設定しました。それぞれの目標に対する取り組みと一部の成果を紹介します。 目標 1: トイル排除と中長期課題へのシフト 課題: 日常的な運用作業（トイル）を自動化し、少人数での複数システムの運用ができ、足元の課題から中長期的な課題へ時間を使えるようにする 主な取り組み: 既存インフラリソースの Terraform import を実施 : 新しいインフラリソースは Terraform で作成されていました。しかし、リリース初期から存在するリソースは違い、インフラ運用の属人化を引き起こしていました。Terraform import を定常的に実施し、誰でも実装可能で、レビューしやすい運用を実現しました。 定常的に発生する運用業務の自動化 : CLINICS は運用するシステムも多く、月次の更新処理や定常的なスケールアップ対応など、数多くの運用タスクがありました。 AWS Step Functions などにより定常的な業務を自動化し、運用負荷軽減を実現しました。 目標 2: 改善文化の浸透 課題: ポストモーテム 文化(障害後の振り返り文化)を確立し、再発防止が適切に実行され、改善課題が積み上がり続ける状態から脱する。 主な取り組み: ポストモーテムの標準化: 以前から振り返りの文化はありましたが、定式化されておらず、各々が各自の形式で振り返りを実施していました。 チームでのナレッジ共有がなされず、障害対応での属人化の要因となっていました。体系的に障害を振り返る仕組みを作り、CLINICS のチーム全体に展開することで、チームでの障害対応力を向上させました。 アラート改善を定常的に回す仕組みの策定 : 緊急性が高い事象や顧客とのコミュニケーションが必要な事象はアラートの検知時に迅速に解決できていました。しかし、タイミングの問題で発生する瑣末なフロントエンドのエラーなどは「オオカミ少年」になり、アラートを定期的に検知していました。開発チーム全体で根本対応できるものは実施する、すぐに解決が難しいものは一定期間無視するなど、対応ルールを精緻化しました。 目標 3: SLO による信頼性可視化 課題: CLINICS の関係者が納得できる 信頼性の指標(SLO) を構築し、改善施策はこれらの指標改善を優先する 主な取り組み: 重要な顧客体験 (Critical User Journey) の策定と SLO ダッシュボードの作成: CUJ(Critical User Journey) を特定し、Datadog 上に SLO のダッシュボードを作成しました。フロントエンドのパフォーマンスモニタリングを目的とした Datadog RUM(Realtime User Monitoring) などを導入することで、オブザーバビリティの強化も実現し、顧客体験をより厳密にトラッキングできるようにしました。 SLO モニタリングの実施: 作成したダッシュボードをもとに受付、診察、会計など 3 つの顧客体験について、可用性、レイテンシー、エラー率の目標値を設定しました。閾値の調整やエラーバジェットのモニタリングを定期実施し、アラート改善に役立てる取り組みを実現しました。 SRE チームにおけるその他の取り組み 上記の取り組み以外にも、SRE の一般的な以下の業務にも取り組んでいます。 事業成長を見越したキャパシティプランニング システムのモニタリングによる事前の課題発見 障害対応プロセスの改善 インフラコストの削減 DB 等のパフォーマンス問題の改善 ライブラリ対応やセキュリティ対応の効率化 アーキテクチャとリリースフローの改善…など SRE チームの取り組みの成果が実を結び始める これらの取り組みにより、CLINICS 開発メンバー全体（開発チームを含む）の運用負担が軽減されました。 信頼性の維持をしつつ、目の前の課題だけでなく将来を見据えた取り組みに注力する余裕が生まれています。開発チームとの協業を強化し、機能開発時に SLO の組み込みを進め、改善目標の指標としても活用する計画を立てています。他にも障害時の信頼性向上を目的とした Sidekiq Pro の導入など、信頼性向上にも取り組んでいます。 このように私たちの取り組みが徐々に成果を上げ始めています。 開発チームと SRE チームの協働により、当初実現したかった CLINICS の機能開発とシステム信頼性の両立が実現しつつあります 。今後もこの連携と SRE の取り組みを深め、より安定したサービス提供を目指してまいります。 医療プラットフォーム SRE チームとしての展望 ここまでは、CLINICS における SRE の取り組みを書いてきました。ここからは、今後医療プラットフォーム全体に SRE としてどのように貢献しようとしているのかの展望を述べます。 医療プラットフォーム全体への SRE ノウハウ展開 CLINICS での知見を活かし、今後、 Dentis や Pharms といった医療プラットフォームの他のプロダクトにも SRE のノウハウを展開していく予定です。 CLINICS は規模が大きく、信頼性要求も高いため、培ったノウハウは他のプロダクトにも十分応用できると考えています。ノウハウを展開することで、医療プラットフォーム全体での信頼性の底上げを実現します。 プロダクトの拡充に対して柔軟に対応できる仕組みづくり 医療プラットフォームは、「医療ヘルスケアの未来をつくる」というミッション実現のために、今後も新規開発や M&A によるプロダクト増加も見込まれます。 新たなプロダクトが加わった際にも、医療プラットフォーム標準の信頼性水準に迅速に引き上げることが重要です。 SRE チームは、医療プラットフォームに属する全てのプロダクトが高い信頼性を維持できる体制を目指します。 事業運営に関わる全関係者が納得する SRE 文化の醸成 SRE の取り組みは開発チームだけのものではありません。ポストモーテムや開発優先度の判断において、非開発メンバーの視点は不可欠です。プロダクトマネージャーや QA メンバーはもちろん、カスタマーサクセス・サポートチームも信頼性の考え方を共有することで、「なぜ機能開発より安定性向上を優先すべきか」といった判断に事業全体の納得感が生まれます。 SLO などの指標は単なる技術的な数値ではなく、顧客体験と事業成長を支える重要な要素です。医療プラットフォーム全体で信頼性と機能開発のバランスを適切に取りながら前進できる文化を育むこと、これも SRE チームの重要なミッションの一つです。 まとめ：医療ヘルスケアの未来を支える SRE 医療プラットフォームの SRE 立ち上げについてお伝えしました。医療プラットフォームの成長と「医療ヘルスケアの未来」創造のために、SRE による信頼性確保は欠かせないミッションです。 SRE としても医療プラットフォームとしても、挑戦したいことは山積みです。事業成長を加速し、医療機関と患者の体験を向上させるために、SRE の活動は不可欠です。 何より、「医療ヘルスケアの未来をつくる」というミッションに共感し、技術で医療の課題解決に貢献したいという情熱を持つ方をお待ちしています。私たちと一緒にこのミッションを実現しませんか？ 興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは、医療プラットフォーム本部 SRE グループの大塚です。入社から 3 年ほど CLINICS のソフトウェアエンジニアとして開発に携わり、その中でプロダクトの安定稼働のための信頼性向上の技術的な取り込みも担当していました。 このたび、医療プラットフォームにおけるシステムの安定稼働と信頼性の確保がこれまで以上に求められる状況になり、正式に SRE チームを立ち上げました。医療機関向け SaaS である CLINICS の信頼性向上を主眼に発足し、立ち上げから SLO の策定や運用効率化などの成果が出ています。 この記事では、以下の内容についてお話しします。 医療プラットフォームにおける SRE チーム立ち上げの経緯 医療プラットフォームの中核である CLINICS について 医療プラットフォーム SRE チームの組織体制と役割 医療プラットフォーム SRE チームとしての展望 医療系 SaaS に興味があるエンジニアや、SRE としてのキャリアに関心がある方に向けて書いています。医療の発展にテクノロジーで貢献したいと考える方にとって参考になれば幸いです。 なぜ、医療プラットフォームで SRE チーム立ち上げたのか？ 医療プラットフォームの中核を担う CLINICS 医療プラットフォームは「医療ヘルスケアの未来をつくる」、「納得できる医療」の実現のために、様々な医療領域のプロダクトを提供しています。 その中でも、医療機関向け SaaS である CLINICS は高い信頼性が求められています。CLINICS は電子カルテ、予約管理、会計システム、オンライン診療など、診療所の基幹業務をトータルでサポートするクラウドサービスです。診療所の日々の運営に不可欠な業務を担うシステムであるため、高い信頼性と安定性が求められます。 また、CLINICS は医療機関と患者をつなぐ接点でもあり、システムには患者向けの API なども含まれます。そのため、システムの信頼性は患者の観点から見ても重要です。 CLINICS に求められる非機能要件 CLINICS は診療業務の基幹システムであり、診療所の業務をリアルタイムでサポートします。機能面の品質はもちろん、非機能要件（信頼性、可用性、パフォーマンス、保守性など）も極めて重要です。 例えば、システムの応答速度が遅くなり患者が受付や会計で長時間待たされると、医療機関だけでなく患者の体験も悪化します。そして、システム停止は診療所の業務が遂行できなくなることを意味します。 その結果、CLINICS サポートへの負荷増大や医療機関の信頼性低下などの影響を招きます。障害復旧対応で開発計画の変更が余儀なくされ、開発速度の低下を生じさせる一因になります。 しかし、CLINICS においてはこれらの非機能要件を満たすことは簡単ではありません。CLINICS は医療プラットフォームの中で最も歴史が長いプロダクトです。契約医療機関数は数千を超え、診療所の業務時間中は常に大量のデータとトラフィックを処理します。また、 CLINICS はレセコン（診療報酬請求事務を管理・自動化するシステム） などの複数のシステムで構成され、インフラなどの運用コストも高くなっています。 CLINICS を含む医療プラットフォームの成長に伴う技術課題 私自身も CLINICS のソフトウェアエンジニアとして開発に携わり、インフラに詳しいメンバー数人と共に可用性や信頼性に関するタスクを担当してきました。しかし、事業の成長に伴いシステム規模が拡大する中で、機能開発とシステム信頼性の両立が困難になっていました。 システムが深刻な状態には至っていませんでしたが、概ね以下のような課題を抱えていました。 長年の運用の中で非効率な DB へのクエリが蓄積し、処理に時間がかかる箇所が散見される トイル（SRE における反復的な運用作業）が増大し、運用業務の負荷が大きくなり、さらに悪循環を生む ライブラリ対応の優先度が下がり、 EOL 対応に追われている アラートの振り返りと暫定的な再発防止策は実施するが、根本対応までやりきれない また、これらの課題は、 Dentis や Pharms などの医療プラットフォーム内の他のプロダクトでも発生する可能性が高いです。他のプロダクトも CLINICS と同様の体制で開発と運用されており、すでに同じ課題が顕在化しつつあります。 CLINICS の医療機関数は日々増加しており、今後も事業拡大が見込まれます。それは他のプロダクトでも同様です。CLINICS に限らず医療プラットフォーム全体の成長を加速させるには、 信頼性の高い基盤構築に向き合えるチーム体制の構築が不可欠です。 医療プラットフォーム SRE チームの発足 信頼性課題などの中長期的な課題解決を目指す医療プラットフォーム SRE チームを発足しました。CLINICS に限らず、医療プラットフォーム全体を対応範囲としています。先程述べたように、システム信頼性の課題は医療プラットフォーム全体の課題であるためです。SRE チームが医療プラットフォームの横断組織として機能することで、システム信頼性に関する知見を集約します。 まずは、医療プラットフォームの中でも 中心的な役割を担う大規模なシステムである CLINICS の信頼性向上を最優先課題としています。SRE チームは CLINICS での取り組みの中で得た知見を医療プラットフォーム全体に還元します。 2025 年 4 月現在、SRE チームは CLINICS プロダクトに専任する形で活動しています。一般に知られている Embedded SRE です。この形態では、SRE チームメンバーが開発チームに直接入り込み、密に連携しながら信頼性向上に取り組みます。 CLINICS の信頼性向上を目指した SRE の取り組み ここからは CLINICS に対して現在行っている取り組みを説明します。 SRE チームの役割とミッション CLINICS における SRE チームのミッションは 「事業成長を支え、安定した開発基盤と顧客の信頼性を維持する文化、仕組みを構築すること」 です。SRE チームは信頼性向上に専念することで、開発チームは機能開発に集中できる状態を目指し、CLINICS プロダクトは事業と品質の両輪での成長を図ります。 前半で述べた課題に対応するために、SRE チームの立ち上げ時にまず 3 つの重点目標を設定しました。それぞれの目標に対する取り組みと一部の成果を紹介します。 目標 1: トイル排除と中長期課題へのシフト 課題: 日常的な運用作業（トイル）を自動化し、少人数での複数システムの運用ができ、足元の課題から中長期的な課題へ時間を使えるようにする 主な取り組み: 既存インフラリソースの Terraform import を実施 : 新しいインフラリソースは Terraform で作成されていました。しかし、リリース初期から存在するリソースは違い、インフラ運用の属人化を引き起こしていました。Terraform import を定常的に実施し、誰でも実装可能で、レビューしやすい運用を実現しました。 定常的に発生する運用業務の自動化 : CLINICS は運用するシステムも多く、月次の更新処理や定常的なスケールアップ対応など、数多くの運用タスクがありました。 AWS Step Functions などにより定常的な業務を自動化し、運用負荷軽減を実現しました。 目標 2: 改善文化の浸透 課題: ポストモーテム 文化(障害後の振り返り文化)を確立し、再発防止が適切に実行され、改善課題が積み上がり続ける状態から脱する。 主な取り組み: ポストモーテムの標準化: 以前から振り返りの文化はありましたが、定式化されておらず、各々が各自の形式で振り返りを実施していました。 チームでのナレッジ共有がなされず、障害対応での属人化の要因となっていました。体系的に障害を振り返る仕組みを作り、CLINICS のチーム全体に展開することで、チームでの障害対応力を向上させました。 アラート改善を定常的に回す仕組みの策定 : 緊急性が高い事象や顧客とのコミュニケーションが必要な事象はアラートの検知時に迅速に解決できていました。しかし、タイミングの問題で発生する瑣末なフロントエンドのエラーなどは「オオカミ少年」になり、アラートを定期的に検知していました。開発チーム全体で根本対応できるものは実施する、すぐに解決が難しいものは一定期間無視するなど、対応ルールを精緻化しました。 目標 3: SLO による信頼性可視化 課題: CLINICS の関係者が納得できる 信頼性の指標(SLO) を構築し、改善施策はこれらの指標改善を優先する 主な取り組み: 重要な顧客体験 (Critical User Journey) の策定と SLO ダッシュボードの作成: CUJ(Critical User Journey) を特定し、Datadog 上に SLO のダッシュボードを作成しました。フロントエンドのパフォーマンスモニタリングを目的とした Datadog RUM(Realtime User Monitoring) などを導入することで、オブザーバビリティの強化も実現し、顧客体験をより厳密にトラッキングできるようにしました。 SLO モニタリングの実施: 作成したダッシュボードをもとに受付、診察、会計など 3 つの顧客体験について、可用性、レイテンシー、エラー率の目標値を設定しました。閾値の調整やエラーバジェットのモニタリングを定期実施し、アラート改善に役立てる取り組みを実現しました。 SRE チームにおけるその他の取り組み 上記の取り組み以外にも、SRE の一般的な以下の業務にも取り組んでいます。 事業成長を見越したキャパシティプランニング システムのモニタリングによる事前の課題発見 障害対応プロセスの改善 インフラコストの削減 DB 等のパフォーマンス問題の改善 ライブラリ対応やセキュリティ対応の効率化 アーキテクチャとリリースフローの改善…など SRE チームの取り組みの成果が実を結び始める これらの取り組みにより、CLINICS 開発メンバー全体（開発チームを含む）の運用負担が軽減されました。 信頼性の維持をしつつ、目の前の課題だけでなく将来を見据えた取り組みに注力する余裕が生まれています。開発チームとの協業を強化し、機能開発時に SLO の組み込みを進め、改善目標の指標としても活用する計画を立てています。他にも障害時の信頼性向上を目的とした Sidekiq Pro の導入など、信頼性向上にも取り組んでいます。 このように私たちの取り組みが徐々に成果を上げ始めています。 開発チームと SRE チームの協働により、当初実現したかった CLINICS の機能開発とシステム信頼性の両立が実現しつつあります 。今後もこの連携と SRE の取り組みを深め、より安定したサービス提供を目指してまいります。 医療プラットフォーム SRE チームとしての展望 ここまでは、CLINICS における SRE の取り組みを書いてきました。ここからは、今後医療プラットフォーム全体に SRE としてどのように貢献しようとしているのかの展望を述べます。 医療プラットフォーム全体への SRE ノウハウ展開 CLINICS での知見を活かし、今後、 Dentis や Pharms といった医療プラットフォームの他のプロダクトにも SRE のノウハウを展開していく予定です。 CLINICS は規模が大きく、信頼性要求も高いため、培ったノウハウは他のプロダクトにも十分応用できると考えています。ノウハウを展開することで、医療プラットフォーム全体での信頼性の底上げを実現します。 プロダクトの拡充に対して柔軟に対応できる仕組みづくり 医療プラットフォームは、「医療ヘルスケアの未来をつくる」というミッション実現のために、今後も新規開発や M&A によるプロダクト増加も見込まれます。 新たなプロダクトが加わった際にも、医療プラットフォーム標準の信頼性水準に迅速に引き上げることが重要です。 SRE チームは、医療プラットフォームに属する全てのプロダクトが高い信頼性を維持できる体制を目指します。 事業運営に関わる全関係者が納得する SRE 文化の醸成 SRE の取り組みは開発チームだけのものではありません。ポストモーテムや開発優先度の判断において、非開発メンバーの視点は不可欠です。プロダクトマネージャーや QA メンバーはもちろん、カスタマーサクセス・サポートチームも信頼性の考え方を共有することで、「なぜ機能開発より安定性向上を優先すべきか」といった判断に事業全体の納得感が生まれます。 SLO などの指標は単なる技術的な数値ではなく、顧客体験と事業成長を支える重要な要素です。医療プラットフォーム全体で信頼性と機能開発のバランスを適切に取りながら前進できる文化を育むこと、これも SRE チームの重要なミッションの一つです。 まとめ：医療ヘルスケアの未来を支える SRE 医療プラットフォームの SRE 立ち上げについてお伝えしました。医療プラットフォームの成長と「医療ヘルスケアの未来」創造のために、SRE による信頼性確保は欠かせないミッションです。 SRE としても医療プラットフォームとしても、挑戦したいことは山積みです。事業成長を加速し、医療機関と患者の体験を向上させるために、SRE の活動は不可欠です。 何より、「医療ヘルスケアの未来をつくる」というミッションに共感し、技術で医療の課題解決に貢献したいという情熱を持つ方をお待ちしています。私たちと一緒にこのミッションを実現しませんか？ 興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

メドレーの AI 活用戦略 こんにちは！メドレー株式会社 人材プラットフォーム本部 VPoE の倉林( @terukura )です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。 昨今、多くの企業が AI の活用に取り組んでいますが、メドレーでは**「全職種が全業務で当たり前に AI を活用している企業：AI for All」**を目指して、それぞれの役割や業務に合わせた AI 活用を進めています。 メドレーでは「AI for All」を旗印に、AI 活用戦略を大きく 3 つの領域に分けています。 AI for All 1. AI 活用による業務オペレーションの効率化 ：日々の業務プロセスを AI で効率化し、ルーティンワークの時間を削減することで、より創造的な業務に集中できる環境を作ります。 2. AI 活用によるエンジニアリング生産性向上 ：開発サイクルの短縮と品質向上を実現し、より多くの価値を生み出せるようにします。 3. AI 活用によるプロダクト価値提供 ：ユーザーに直接価値を届ける AI 機能を実装し、メドレーのサービスをさらに進化させます。 またこれらの領域をそれぞれブーストさせるために、土台となる基礎活動もしっかり推進しています。 安心・安全な AI 活用のためのガイドライン整備 ：医療領域を扱う企業として、セキュリティとプライバシー保護は最優先事項です。社内では「AI ガイドライン」を整備し、明確な指針を提供することで、安心して AI ツールを活用できる環境を整えています。 AI Enabling ：全社の AI 活用レベルを底上げするため、様々な AI ツールや活用環境の整備、最新ツールの評価・共有、定期的な勉強会開催などを推進しています。社内 AI プラットフォームとして Dify を導入し、各部門が様々なモデルやフローの検証・活用を容易に行える環境を提供することで、技術的な障壁を低減しています。 今回の blog では、こうした全社的な取り組みの中でもエンジニア面談・面接でよく質問いただく 「AI 活用によるエンジニアリング生産性向上」 について、具体的な活用ツールなども踏まえてご紹介できればと思います。 プロダクト開発・エンジニアリングの変化 特に最近では、Claude Sonnet 3.7 の登場もあり、コーディング領域における AI 活用は大きなゲームチェンジを迎えていると感じています。 エンジニアリング生産性の飛躍的な向上が現実のものとなり、従来の開発スタイルを根本から見直す時期に来ています。 開発スタイルの変化 AI を活用しているエンジニアとそうでないエンジニアの間で、処理できるタスク量に大きな差が生まれつつあります。もちろん、AI が活用しやすい領域とそうでない領域があるものの、その差は想像以上に大きく、今後さらに拡大していくでしょう。 メドレーでは 2025 年末までに、プロダクト開発のあらゆる職種(PdM/QA/Design/Engineer)・工程において AI 活用率 100%を目指しています。これは単なる数値目標ではなく、全デベロッパーが AI を自分の「パートナー」として効果的に活用できる状態を実現するためのビジョンです。 活用している AI ツール メドレーのエンジニアリング組織では、様々な AI ツールを開発プロセスに組み込み、生産性と創造性を高めています。以下では、特に効果を発揮している主要なツールとその実際の活用シーンについてご紹介します。 コード生成・開発支援ツール: Cursor、GitHub Copilot、Cline、Windsurf 元々 GitHub Copilot は全社導入していましたが、最近では Cursor をはじめとする AI エージェントや AI 搭載コードエディタも全社で利用できる環境を整えています。 これらのツールは単なるコード補完にとどまらず、開発体験そのものを変革しています。 思考支援・問題解決ツール: Claude、ChatGPT、Gemini、NotebookLM 対話型 AI は、思考のパートナーとして日々活躍しています。特に複雑な課題に直面した際、これらのツールを活用して問題解決の糸口を見つけています。 UIUX のプロトタイピングにもこれらのツールが大いに貢献しています。特に artifact 生成機能を活用することで、アイデアから視覚的な UI 案まで素早く作成でき、PdM・デザイナー・エンジニア間のコミュニケーションが格段にスムーズになっていく兆しを感じています。 自律型開発エージェント: Devin Devin は、開発スタイルに新たな可能性をもたらしています。「非同期での開発」を可能にし、開発者が他のタスクに取り組んでいる間でも、定型的な開発作業や特定の機能実装を進めることが現実となってきています。 検証初月で約 1,500 ACUs（約 375 時間相当）の活用実績があり、Devin を活用しているデベロッパーも現在 80 名を超えています。今後も予算の一部を Devin に割り当て、さらなる活用強化を進めています。 AI 開発プラットフォーム: Dify Dify のようなプラットフォームは、社内の AI 活用の実験場となっています。様々なモデルやプロンプトの検証、複雑な AI ワークフローの構築など、AI の可能性を探求する基盤として活用しています。 AI ツール活用の今後の基本方針 これらのツールを適材適所で組み合わせることで、開発プロセス全体の効率化を実現し、全社員が AI を自分のパートナーとして活用できる環境づくりを進めています。 その際、私たちが特に重視している点は以下の 2 つです： 単なるツール導入にとどまらず、効果的な活用方法のナレッジを組織内で共有し、継続的に改善していくこと FourKeys を軸に開発生産性をモニタリングし、データに基づいた改善を進めること まだ過渡期ではありますが、すでに複数のチームで開発サイクルの短縮や品質向上といった、生産性向上の明確な兆候が表れ始めています。 推進・検証中の領域 以下の領域は現在積極的に推進・検証中です。成果が出次第、順次アウトプットしていきます。 AI×QA AI を活用したテスト自動生成によるテストカバレッジの向上と QA 工数の削減 エッジケースの自動検出機能による人間が見落としがちなバグの早期発見 AI× データマネージメント 大規模データセットからのインサイト抽出と意思決定支援 データクレンジングと前処理の自動化によるデータ品質向上 「AI ファースト」の開発フロー AI が理解しやすいコード構造とドキュメント体系の標準化 ナレッジやルールを AI が理解しやすい形で蓄積・管理 MCP の利用ルールとガードレールの整備 安全かつ効率的な AI 活用のための社内 MCP ポリシーとガードレール設計 ドメイン知識を組み込んだ自社 MCP の開発と展開 AI 活用時代のエンジニア採用・人材要件 AI ツールを効果的に活用できる思考力と指示能力を重視した採用基準 技術的深さと AI との協業スキルを評価する新たな人材ペルソナ AI 関連費用対効果・費用モニタリング 各種ツールのコスト・モデルのコストなど様々なコスト管理 生産性モニタリング 医療 ×AI の可能性 医療現場では従来から画像診断や遺伝子解析などの臨床領域で AI 活用が進んでいますが、その他の業務領域にも AI を取り入れることで、さらなる効率化や価値創出の可能性が広がっていると考えています。 患者情報の入力や整理、診療記録の作成、医療スタッフ間のコミュニケーション、スケジュール管理など、医療現場の日常業務に AI を活用することで、医療従事者の負担を軽減し、本来の患者ケアにより集中できる環境づくりにつながる可能性があると思います。 メドレーは医療 DX から医療 AX へと進化する中で、医療従事者と患者の双方に価値を提供できる独自のポジションにあります。今後も AI を活用した新しいプロダクトラインアップを発表予定ですので、ご期待ください！ We’re hiring メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！ カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me

メドレーの AI 活用戦略 こんにちは！メドレー株式会社 人材プラットフォーム本部 VPoE の倉林( @terukura )です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。 昨今、多くの企業が AI の活用に取り組んでいますが、メドレーでは**「全職種が全業務で当たり前に AI を活用している企業：AI for All」**を目指して、それぞれの役割や業務に合わせた AI 活用を進めています。 メドレーでは「AI for All」を旗印に、AI 活用戦略を大きく 3 つの領域に分けています。 AI for All 1. AI 活用による業務オペレーションの効率化 ：日々の業務プロセスを AI で効率化し、ルーティンワークの時間を削減することで、より創造的な業務に集中できる環境を作ります。 2. AI 活用によるエンジニアリング生産性向上 ：開発サイクルの短縮と品質向上を実現し、より多くの価値を生み出せるようにします。 3. AI 活用によるプロダクト価値提供 ：ユーザーに直接価値を届ける AI 機能を実装し、メドレーのサービスをさらに進化させます。 またこれらの領域をそれぞれブーストさせるために、土台となる基礎活動もしっかり推進しています。 安心・安全な AI 活用のためのガイドライン整備 ：医療領域を扱う企業として、セキュリティとプライバシー保護は最優先事項です。社内では「AI ガイドライン」を整備し、明確な指針を提供することで、安心して AI ツールを活用できる環境を整えています。 AI Enabling ：全社の AI 活用レベルを底上げするため、様々な AI ツールや活用環境の整備、最新ツールの評価・共有、定期的な勉強会開催などを推進しています。社内 AI プラットフォームとして Dify を導入し、各部門が様々なモデルやフローの検証・活用を容易に行える環境を提供することで、技術的な障壁を低減しています。 今回の blog では、こうした全社的な取り組みの中でもエンジニア面談・面接でよく質問いただく 「AI 活用によるエンジニアリング生産性向上」 について、具体的な活用ツールなども踏まえてご紹介できればと思います。 プロダクト開発・エンジニアリングの変化 特に最近では、Claude Sonnet 3.7 の登場もあり、コーディング領域における AI 活用は大きなゲームチェンジを迎えていると感じています。 エンジニアリング生産性の飛躍的な向上が現実のものとなり、従来の開発スタイルを根本から見直す時期に来ています。 開発スタイルの変化 AI を活用しているエンジニアとそうでないエンジニアの間で、処理できるタスク量に大きな差が生まれつつあります。もちろん、AI が活用しやすい領域とそうでない領域があるものの、その差は想像以上に大きく、今後さらに拡大していくでしょう。 メドレーでは 2025 年末までに、プロダクト開発のあらゆる職種(PdM/QA/Design/Engineer)・工程において AI 活用率 100%を目指しています。これは単なる数値目標ではなく、全デベロッパーが AI を自分の「パートナー」として効果的に活用できる状態を実現するためのビジョンです。 活用している AI ツール メドレーのエンジニアリング組織では、様々な AI ツールを開発プロセスに組み込み、生産性と創造性を高めています。以下では、特に効果を発揮している主要なツールとその実際の活用シーンについてご紹介します。 コード生成・開発支援ツール: Cursor、GitHub Copilot、Cline、Windsurf 元々 GitHub Copilot は全社導入していましたが、最近では Cursor をはじめとする AI エージェントや AI 搭載コードエディタも全社で利用できる環境を整えています。 これらのツールは単なるコード補完にとどまらず、開発体験そのものを変革しています。 思考支援・問題解決ツール: Claude、ChatGPT、Gemini、NotebookLM 対話型 AI は、思考のパートナーとして日々活躍しています。特に複雑な課題に直面した際、これらのツールを活用して問題解決の糸口を見つけています。 UIUX のプロトタイピングにもこれらのツールが大いに貢献しています。特に artifact 生成機能を活用することで、アイデアから視覚的な UI 案まで素早く作成でき、PdM・デザイナー・エンジニア間のコミュニケーションが格段にスムーズになっていく兆しを感じています。 自律型開発エージェント: Devin Devin は、開発スタイルに新たな可能性をもたらしています。「非同期での開発」を可能にし、開発者が他のタスクに取り組んでいる間でも、定型的な開発作業や特定の機能実装を進めることが現実となってきています。 検証初月で約 1,500 ACUs（約 375 時間相当）の活用実績があり、Devin を活用しているデベロッパーも現在 80 名を超えています。今後も予算の一部を Devin に割り当て、さらなる活用強化を進めています。 AI 開発プラットフォーム: Dify Dify のようなプラットフォームは、社内の AI 活用の実験場となっています。様々なモデルやプロンプトの検証、複雑な AI ワークフローの構築など、AI の可能性を探求する基盤として活用しています。 AI ツール活用の今後の基本方針 これらのツールを適材適所で組み合わせることで、開発プロセス全体の効率化を実現し、全社員が AI を自分のパートナーとして活用できる環境づくりを進めています。 その際、私たちが特に重視している点は以下の 2 つです： 単なるツール導入にとどまらず、効果的な活用方法のナレッジを組織内で共有し、継続的に改善していくこと FourKeys を軸に開発生産性をモニタリングし、データに基づいた改善を進めること まだ過渡期ではありますが、すでに複数のチームで開発サイクルの短縮や品質向上といった、生産性向上の明確な兆候が表れ始めています。 推進・検証中の領域 以下の領域は現在積極的に推進・検証中です。成果が出次第、順次アウトプットしていきます。 AI×QA AI を活用したテスト自動生成によるテストカバレッジの向上と QA 工数の削減 エッジケースの自動検出機能による人間が見落としがちなバグの早期発見 AI× データマネージメント 大規模データセットからのインサイト抽出と意思決定支援 データクレンジングと前処理の自動化によるデータ品質向上 「AI ファースト」の開発フロー AI が理解しやすいコード構造とドキュメント体系の標準化 ナレッジやルールを AI が理解しやすい形で蓄積・管理 MCP の利用ルールとガードレールの整備 安全かつ効率的な AI 活用のための社内 MCP ポリシーとガードレール設計 ドメイン知識を組み込んだ自社 MCP の開発と展開 AI 活用時代のエンジニア採用・人材要件 AI ツールを効果的に活用できる思考力と指示能力を重視した採用基準 技術的深さと AI との協業スキルを評価する新たな人材ペルソナ AI 関連費用対効果・費用モニタリング 各種ツールのコスト・モデルのコストなど様々なコスト管理 生産性モニタリング 医療 ×AI の可能性 医療現場では従来から画像診断や遺伝子解析などの臨床領域で AI 活用が進んでいますが、その他の業務領域にも AI を取り入れることで、さらなる効率化や価値創出の可能性が広がっていると考えています。 患者情報の入力や整理、診療記録の作成、医療スタッフ間のコミュニケーション、スケジュール管理など、医療現場の日常業務に AI を活用することで、医療従事者の負担を軽減し、本来の患者ケアにより集中できる環境づくりにつながる可能性があると思います。 メドレーは医療 DX から医療 AX へと進化する中で、医療従事者と患者の双方に価値を提供できる独自のポジションにあります。今後も AI を活用した新しいプロダクトラインアップを発表予定ですので、ご期待ください！ We’re hiring メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！ カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me

メドレーの AI 活用戦略 こんにちは！メドレー株式会社 人材プラットフォーム本部 VPoE の倉林( @terukura )です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。 昨今、多くの企業が AI の活用に取り組んでいますが、メドレーでは**「全職種が全業務で当たり前に AI を活用している企業：AI for All」**を目指して、それぞれの役割や業務に合わせた AI 活用を進めています。 メドレーでは「AI for All」を旗印に、AI 活用戦略を大きく 3 つの領域に分けています。 AI for All 1. AI 活用による業務オペレーションの効率化 ：日々の業務プロセスを AI で効率化し、ルーティンワークの時間を削減することで、より創造的な業務に集中できる環境を作ります。 2. AI 活用によるエンジニアリング生産性向上 ：開発サイクルの短縮と品質向上を実現し、より多くの価値を生み出せるようにします。 3. AI 活用によるプロダクト価値提供 ：ユーザーに直接価値を届ける AI 機能を実装し、メドレーのサービスをさらに進化させます。 またこれらの領域をそれぞれブーストさせるために、土台となる基礎活動もしっかり推進しています。 安心・安全な AI 活用のためのガイドライン整備 ：医療領域を扱う企業として、セキュリティとプライバシー保護は最優先事項です。社内では「AI ガイドライン」を整備し、明確な指針を提供することで、安心して AI ツールを活用できる環境を整えています。 AI Enabling ：全社の AI 活用レベルを底上げするため、様々な AI ツールや活用環境の整備、最新ツールの評価・共有、定期的な勉強会開催などを推進しています。社内 AI プラットフォームとして Dify を導入し、各部門が様々なモデルやフローの検証・活用を容易に行える環境を提供することで、技術的な障壁を低減しています。 今回の blog では、こうした全社的な取り組みの中でもエンジニア面談・面接でよく質問いただく 「AI 活用によるエンジニアリング生産性向上」 について、具体的な活用ツールなども踏まえてご紹介できればと思います。 プロダクト開発・エンジニアリングの変化 特に最近では、Claude Sonnet 3.7 の登場もあり、コーディング領域における AI 活用は大きなゲームチェンジを迎えていると感じています。 エンジニアリング生産性の飛躍的な向上が現実のものとなり、従来の開発スタイルを根本から見直す時期に来ています。 開発スタイルの変化 AI を活用しているエンジニアとそうでないエンジニアの間で、処理できるタスク量に大きな差が生まれつつあります。もちろん、AI が活用しやすい領域とそうでない領域があるものの、その差は想像以上に大きく、今後さらに拡大していくでしょう。 メドレーでは 2025 年末までに、プロダクト開発のあらゆる職種(PdM/QA/Design/Engineer)・工程において AI 活用率 100%を目指しています。これは単なる数値目標ではなく、全デベロッパーが AI を自分の「パートナー」として効果的に活用できる状態を実現するためのビジョンです。 活用している AI ツール メドレーのエンジニアリング組織では、様々な AI ツールを開発プロセスに組み込み、生産性と創造性を高めています。以下では、特に効果を発揮している主要なツールとその実際の活用シーンについてご紹介します。 コード生成・開発支援ツール: Cursor、GitHub Copilot、Cline、Windsurf 元々 GitHub Copilot は全社導入していましたが、最近では Cursor をはじめとする AI エージェントや AI 搭載コードエディタも全社で利用できる環境を整えています。 これらのツールは単なるコード補完にとどまらず、開発体験そのものを変革しています。 思考支援・問題解決ツール: Claude、ChatGPT、Gemini、NotebookLM 対話型 AI は、思考のパートナーとして日々活躍しています。特に複雑な課題に直面した際、これらのツールを活用して問題解決の糸口を見つけています。 UIUX のプロトタイピングにもこれらのツールが大いに貢献しています。特に artifact 生成機能を活用することで、アイデアから視覚的な UI 案まで素早く作成でき、PdM・デザイナー・エンジニア間のコミュニケーションが格段にスムーズになっていく兆しを感じています。 自律型開発エージェント: Devin Devin は、開発スタイルに新たな可能性をもたらしています。「非同期での開発」を可能にし、開発者が他のタスクに取り組んでいる間でも、定型的な開発作業や特定の機能実装を進めることが現実となってきています。 検証初月で約 1,500 ACUs（約 375 時間相当）の活用実績があり、Devin を活用しているデベロッパーも現在 80 名を超えています。今後も予算の一部を Devin に割り当て、さらなる活用強化を進めています。 AI 開発プラットフォーム: Dify Dify のようなプラットフォームは、社内の AI 活用の実験場となっています。様々なモデルやプロンプトの検証、複雑な AI ワークフローの構築など、AI の可能性を探求する基盤として活用しています。 AI ツール活用の今後の基本方針 これらのツールを適材適所で組み合わせることで、開発プロセス全体の効率化を実現し、全社員が AI を自分のパートナーとして活用できる環境づくりを進めています。 その際、私たちが特に重視している点は以下の 2 つです： 単なるツール導入にとどまらず、効果的な活用方法のナレッジを組織内で共有し、継続的に改善していくこと FourKeys を軸に開発生産性をモニタリングし、データに基づいた改善を進めること まだ過渡期ではありますが、すでに複数のチームで開発サイクルの短縮や品質向上といった、生産性向上の明確な兆候が表れ始めています。 推進・検証中の領域 以下の領域は現在積極的に推進・検証中です。成果が出次第、順次アウトプットしていきます。 AI×QA AI を活用したテスト自動生成によるテストカバレッジの向上と QA 工数の削減 エッジケースの自動検出機能による人間が見落としがちなバグの早期発見 AI× データマネージメント 大規模データセットからのインサイト抽出と意思決定支援 データクレンジングと前処理の自動化によるデータ品質向上 「AI ファースト」の開発フロー AI が理解しやすいコード構造とドキュメント体系の標準化 ナレッジやルールを AI が理解しやすい形で蓄積・管理 MCP の利用ルールとガードレールの整備 安全かつ効率的な AI 活用のための社内 MCP ポリシーとガードレール設計 ドメイン知識を組み込んだ自社 MCP の開発と展開 AI 活用時代のエンジニア採用・人材要件 AI ツールを効果的に活用できる思考力と指示能力を重視した採用基準 技術的深さと AI との協業スキルを評価する新たな人材ペルソナ AI 関連費用対効果・費用モニタリング 各種ツールのコスト・モデルのコストなど様々なコスト管理 生産性モニタリング 医療 ×AI の可能性 医療現場では従来から画像診断や遺伝子解析などの臨床領域で AI 活用が進んでいますが、その他の業務領域にも AI を取り入れることで、さらなる効率化や価値創出の可能性が広がっていると考えています。 患者情報の入力や整理、診療記録の作成、医療スタッフ間のコミュニケーション、スケジュール管理など、医療現場の日常業務に AI を活用することで、医療従事者の負担を軽減し、本来の患者ケアにより集中できる環境づくりにつながる可能性があると思います。 メドレーは医療 DX から医療 AX へと進化する中で、医療従事者と患者の双方に価値を提供できる独自のポジションにあります。今後も AI を活用した新しいプロダクトラインアップを発表予定ですので、ご期待ください！ We’re hiring メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！ カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me

メドレーの AI 活用戦略 こんにちは！メドレー株式会社 人材プラットフォーム本部 VPoE の倉林( @terukura )です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。 昨今、多くの企業が AI の活用に取り組んでいますが、メドレーでは**「全職種が全業務で当たり前に AI を活用している企業：AI for All」**を目指して、それぞれの役割や業務に合わせた AI 活用を進めています。 メドレーでは「AI for All」を旗印に、AI 活用戦略を大きく 3 つの領域に分けています。 AI for All 1. AI 活用による業務オペレーションの効率化 ：日々の業務プロセスを AI で効率化し、ルーティンワークの時間を削減することで、より創造的な業務に集中できる環境を作ります。 2. AI 活用によるエンジニアリング生産性向上 ：開発サイクルの短縮と品質向上を実現し、より多くの価値を生み出せるようにします。 3. AI 活用によるプロダクト価値提供 ：ユーザーに直接価値を届ける AI 機能を実装し、メドレーのサービスをさらに進化させます。 またこれらの領域をそれぞれブーストさせるために、土台となる基礎活動もしっかり推進しています。 安心・安全な AI 活用のためのガイドライン整備 ：医療領域を扱う企業として、セキュリティとプライバシー保護は最優先事項です。社内では「AI ガイドライン」を整備し、明確な指針を提供することで、安心して AI ツールを活用できる環境を整えています。 AI Enabling ：全社の AI 活用レベルを底上げするため、様々な AI ツールや活用環境の整備、最新ツールの評価・共有、定期的な勉強会開催などを推進しています。社内 AI プラットフォームとして Dify を導入し、各部門が様々なモデルやフローの検証・活用を容易に行える環境を提供することで、技術的な障壁を低減しています。 今回の blog では、こうした全社的な取り組みの中でもエンジニア面談・面接でよく質問いただく 「AI 活用によるエンジニアリング生産性向上」 について、具体的な活用ツールなども踏まえてご紹介できればと思います。 プロダクト開発・エンジニアリングの変化 特に最近では、Claude Sonnet 3.7 の登場もあり、コーディング領域における AI 活用は大きなゲームチェンジを迎えていると感じています。 エンジニアリング生産性の飛躍的な向上が現実のものとなり、従来の開発スタイルを根本から見直す時期に来ています。 開発スタイルの変化 AI を活用しているエンジニアとそうでないエンジニアの間で、処理できるタスク量に大きな差が生まれつつあります。もちろん、AI が活用しやすい領域とそうでない領域があるものの、その差は想像以上に大きく、今後さらに拡大していくでしょう。 メドレーでは 2025 年末までに、プロダクト開発のあらゆる職種(PdM/QA/Design/Engineer)・工程において AI 活用率 100%を目指しています。これは単なる数値目標ではなく、全デベロッパーが AI を自分の「パートナー」として効果的に活用できる状態を実現するためのビジョンです。 活用している AI ツール メドレーのエンジニアリング組織では、様々な AI ツールを開発プロセスに組み込み、生産性と創造性を高めています。以下では、特に効果を発揮している主要なツールとその実際の活用シーンについてご紹介します。 コード生成・開発支援ツール: Cursor、GitHub Copilot、Cline、Windsurf 元々 GitHub Copilot は全社導入していましたが、最近では Cursor をはじめとする AI エージェントや AI 搭載コードエディタも全社で利用できる環境を整えています。 これらのツールは単なるコード補完にとどまらず、開発体験そのものを変革しています。 思考支援・問題解決ツール: Claude、ChatGPT、Gemini、NotebookLM 対話型 AI は、思考のパートナーとして日々活躍しています。特に複雑な課題に直面した際、これらのツールを活用して問題解決の糸口を見つけています。 UIUX のプロトタイピングにもこれらのツールが大いに貢献しています。特に artifact 生成機能を活用することで、アイデアから視覚的な UI 案まで素早く作成でき、PdM・デザイナー・エンジニア間のコミュニケーションが格段にスムーズになっていく兆しを感じています。 自律型開発エージェント: Devin Devin は、開発スタイルに新たな可能性をもたらしています。「非同期での開発」を可能にし、開発者が他のタスクに取り組んでいる間でも、定型的な開発作業や特定の機能実装を進めることが現実となってきています。 検証初月で約 1,500 ACUs（約 375 時間相当）の活用実績があり、Devin を活用しているデベロッパーも現在 80 名を超えています。今後も予算の一部を Devin に割り当て、さらなる活用強化を進めています。 AI 開発プラットフォーム: Dify Dify のようなプラットフォームは、社内の AI 活用の実験場となっています。様々なモデルやプロンプトの検証、複雑な AI ワークフローの構築など、AI の可能性を探求する基盤として活用しています。 AI ツール活用の今後の基本方針 これらのツールを適材適所で組み合わせることで、開発プロセス全体の効率化を実現し、全社員が AI を自分のパートナーとして活用できる環境づくりを進めています。 その際、私たちが特に重視している点は以下の 2 つです： 単なるツール導入にとどまらず、効果的な活用方法のナレッジを組織内で共有し、継続的に改善していくこと FourKeys を軸に開発生産性をモニタリングし、データに基づいた改善を進めること まだ過渡期ではありますが、すでに複数のチームで開発サイクルの短縮や品質向上といった、生産性向上の明確な兆候が表れ始めています。 推進・検証中の領域 以下の領域は現在積極的に推進・検証中です。成果が出次第、順次アウトプットしていきます。 AI×QA AI を活用したテスト自動生成によるテストカバレッジの向上と QA 工数の削減 エッジケースの自動検出機能による人間が見落としがちなバグの早期発見 AI× データマネージメント 大規模データセットからのインサイト抽出と意思決定支援 データクレンジングと前処理の自動化によるデータ品質向上 「AI ファースト」の開発フロー AI が理解しやすいコード構造とドキュメント体系の標準化 ナレッジやルールを AI が理解しやすい形で蓄積・管理 MCP の利用ルールとガードレールの整備 安全かつ効率的な AI 活用のための社内 MCP ポリシーとガードレール設計 ドメイン知識を組み込んだ自社 MCP の開発と展開 AI 活用時代のエンジニア採用・人材要件 AI ツールを効果的に活用できる思考力と指示能力を重視した採用基準 技術的深さと AI との協業スキルを評価する新たな人材ペルソナ AI 関連費用対効果・費用モニタリング 各種ツールのコスト・モデルのコストなど様々なコスト管理 生産性モニタリング 医療 ×AI の可能性 医療現場では従来から画像診断や遺伝子解析などの臨床領域で AI 活用が進んでいますが、その他の業務領域にも AI を取り入れることで、さらなる効率化や価値創出の可能性が広がっていると考えています。 患者情報の入力や整理、診療記録の作成、医療スタッフ間のコミュニケーション、スケジュール管理など、医療現場の日常業務に AI を活用することで、医療従事者の負担を軽減し、本来の患者ケアにより集中できる環境づくりにつながる可能性があると思います。 メドレーは医療 DX から医療 AX へと進化する中で、医療従事者と患者の双方に価値を提供できる独自のポジションにあります。今後も AI を活用した新しいプロダクトラインアップを発表予定ですので、ご期待ください！ We’re hiring メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！ カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 https://www.medley.jp/jobs/ 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ https://pitta.me/matches/BtcyDvCvUZtx

メドレーの AI 活用戦略 こんにちは！メドレー株式会社 人材プラットフォーム本部 VPoE の倉林( @terukura )です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。 昨今、多くの企業が AI の活用に取り組んでいますが、メドレーでは**「全職種が全業務で当たり前に AI を活用している企業：AI for All」**を目指して、それぞれの役割や業務に合わせた AI 活用を進めています。 メドレーでは「AI for All」を旗印に、AI 活用戦略を大きく 3 つの領域に分けています。 AI for All 1. AI 活用による業務オペレーションの効率化 ：日々の業務プロセスを AI で効率化し、ルーティンワークの時間を削減することで、より創造的な業務に集中できる環境を作ります。 2. AI 活用によるエンジニアリング生産性向上 ：開発サイクルの短縮と品質向上を実現し、より多くの価値を生み出せるようにします。 3. AI 活用によるプロダクト価値提供 ：ユーザーに直接価値を届ける AI 機能を実装し、メドレーのサービスをさらに進化させます。 またこれらの領域をそれぞれブーストさせるために、土台となる基礎活動もしっかり推進しています。 安心・安全な AI 活用のためのガイドライン整備 ：医療領域を扱う企業として、セキュリティとプライバシー保護は最優先事項です。社内では「AI ガイドライン」を整備し、明確な指針を提供することで、安心して AI ツールを活用できる環境を整えています。 AI Enabling ：全社の AI 活用レベルを底上げするため、様々な AI ツールや活用環境の整備、最新ツールの評価・共有、定期的な勉強会開催などを推進しています。社内 AI プラットフォームとして Dify を導入し、各部門が様々なモデルやフローの検証・活用を容易に行える環境を提供することで、技術的な障壁を低減しています。 今回の blog では、こうした全社的な取り組みの中でもエンジニア面談・面接でよく質問いただく 「AI 活用によるエンジニアリング生産性向上」 について、具体的な活用ツールなども踏まえてご紹介できればと思います。 プロダクト開発・エンジニアリングの変化 特に最近では、Claude Sonnet 3.7 の登場もあり、コーディング領域における AI 活用は大きなゲームチェンジを迎えていると感じています。 エンジニアリング生産性の飛躍的な向上が現実のものとなり、従来の開発スタイルを根本から見直す時期に来ています。 開発スタイルの変化 AI を活用しているエンジニアとそうでないエンジニアの間で、処理できるタスク量に大きな差が生まれつつあります。もちろん、AI が活用しやすい領域とそうでない領域があるものの、その差は想像以上に大きく、今後さらに拡大していくでしょう。 メドレーでは 2025 年末までに、プロダクト開発のあらゆる職種(PdM/QA/Design/Engineer)・工程において AI 活用率 100%を目指しています。これは単なる数値目標ではなく、全デベロッパーが AI を自分の「パートナー」として効果的に活用できる状態を実現するためのビジョンです。 活用している AI ツール メドレーのエンジニアリング組織では、様々な AI ツールを開発プロセスに組み込み、生産性と創造性を高めています。以下では、特に効果を発揮している主要なツールとその実際の活用シーンについてご紹介します。 コード生成・開発支援ツール: Cursor、GitHub Copilot、Cline、Windsurf 元々 GitHub Copilot は全社導入していましたが、最近では Cursor をはじめとする AI エージェントや AI 搭載コードエディタも全社で利用できる環境を整えています。 これらのツールは単なるコード補完にとどまらず、開発体験そのものを変革しています。 思考支援・問題解決ツール: Claude、ChatGPT、Gemini、NotebookLM 対話型 AI は、思考のパートナーとして日々活躍しています。特に複雑な課題に直面した際、これらのツールを活用して問題解決の糸口を見つけています。 UIUX のプロトタイピングにもこれらのツールが大いに貢献しています。特に artifact 生成機能を活用することで、アイデアから視覚的な UI 案まで素早く作成でき、PdM・デザイナー・エンジニア間のコミュニケーションが格段にスムーズになっていく兆しを感じています。 自律型開発エージェント: Devin Devin は、開発スタイルに新たな可能性をもたらしています。「非同期での開発」を可能にし、開発者が他のタスクに取り組んでいる間でも、定型的な開発作業や特定の機能実装を進めることが現実となってきています。 検証初月で約 1,500 ACUs（約 375 時間相当）の活用実績があり、Devin を活用しているデベロッパーも現在 80 名を超えています。今後も予算の一部を Devin に割り当て、さらなる活用強化を進めています。 AI 開発プラットフォーム: Dify Dify のようなプラットフォームは、社内の AI 活用の実験場となっています。様々なモデルやプロンプトの検証、複雑な AI ワークフローの構築など、AI の可能性を探求する基盤として活用しています。 AI ツール活用の今後の基本方針 これらのツールを適材適所で組み合わせることで、開発プロセス全体の効率化を実現し、全社員が AI を自分のパートナーとして活用できる環境づくりを進めています。 その際、私たちが特に重視している点は以下の 2 つです： 単なるツール導入にとどまらず、効果的な活用方法のナレッジを組織内で共有し、継続的に改善していくこと FourKeys を軸に開発生産性をモニタリングし、データに基づいた改善を進めること まだ過渡期ではありますが、すでに複数のチームで開発サイクルの短縮や品質向上といった、生産性向上の明確な兆候が表れ始めています。 推進・検証中の領域 以下の領域は現在積極的に推進・検証中です。成果が出次第、順次アウトプットしていきます。 AI×QA AI を活用したテスト自動生成によるテストカバレッジの向上と QA 工数の削減 エッジケースの自動検出機能による人間が見落としがちなバグの早期発見 AI× データマネージメント 大規模データセットからのインサイト抽出と意思決定支援 データクレンジングと前処理の自動化によるデータ品質向上 「AI ファースト」の開発フロー AI が理解しやすいコード構造とドキュメント体系の標準化 ナレッジやルールを AI が理解しやすい形で蓄積・管理 MCP の利用ルールとガードレールの整備 安全かつ効率的な AI 活用のための社内 MCP ポリシーとガードレール設計 ドメイン知識を組み込んだ自社 MCP の開発と展開 AI 活用時代のエンジニア採用・人材要件 AI ツールを効果的に活用できる思考力と指示能力を重視した採用基準 技術的深さと AI との協業スキルを評価する新たな人材ペルソナ AI 関連費用対効果・費用モニタリング 各種ツールのコスト・モデルのコストなど様々なコスト管理 生産性モニタリング 医療 ×AI の可能性 医療現場では従来から画像診断や遺伝子解析などの臨床領域で AI 活用が進んでいますが、その他の業務領域にも AI を取り入れることで、さらなる効率化や価値創出の可能性が広がっていると考えています。 患者情報の入力や整理、診療記録の作成、医療スタッフ間のコミュニケーション、スケジュール管理など、医療現場の日常業務に AI を活用することで、医療従事者の負担を軽減し、本来の患者ケアにより集中できる環境づくりにつながる可能性があると思います。 メドレーは医療 DX から医療 AX へと進化する中で、医療従事者と患者の双方に価値を提供できる独自のポジションにあります。今後も AI を活用した新しいプロダクトラインアップを発表予定ですので、ご期待ください！ We’re hiring メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！ カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me

メドレーの AI 活用戦略 こんにちは！メドレー株式会社 人材プラットフォーム本部 VPoE の倉林( @terukura )です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。 昨今、多くの企業が AI の活用に取り組んでいますが、メドレーでは**「全職種が全業務で当たり前に AI を活用している企業：AI for All」**を目指して、それぞれの役割や業務に合わせた AI 活用を進めています。 メドレーでは「AI for All」を旗印に、AI 活用戦略を大きく 3 つの領域に分けています。 AI for All 1. AI 活用による業務オペレーションの効率化 ：日々の業務プロセスを AI で効率化し、ルーティンワークの時間を削減することで、より創造的な業務に集中できる環境を作ります。 2. AI 活用によるエンジニアリング生産性向上 ：開発サイクルの短縮と品質向上を実現し、より多くの価値を生み出せるようにします。 3. AI 活用によるプロダクト価値提供 ：ユーザーに直接価値を届ける AI 機能を実装し、メドレーのサービスをさらに進化させます。 またこれらの領域をそれぞれブーストさせるために、土台となる基礎活動もしっかり推進しています。 安心・安全な AI 活用のためのガイドライン整備 ：医療領域を扱う企業として、セキュリティとプライバシー保護は最優先事項です。社内では「AI ガイドライン」を整備し、明確な指針を提供することで、安心して AI ツールを活用できる環境を整えています。 AI Enabling ：全社の AI 活用レベルを底上げするため、様々な AI ツールや活用環境の整備、最新ツールの評価・共有、定期的な勉強会開催などを推進しています。社内 AI プラットフォームとして Dify を導入し、各部門が様々なモデルやフローの検証・活用を容易に行える環境を提供することで、技術的な障壁を低減しています。 今回の blog では、こうした全社的な取り組みの中でもエンジニア面談・面接でよく質問いただく 「AI 活用によるエンジニアリング生産性向上」 について、具体的な活用ツールなども踏まえてご紹介できればと思います。 プロダクト開発・エンジニアリングの変化 特に最近では、Claude Sonnet 3.7 の登場もあり、コーディング領域における AI 活用は大きなゲームチェンジを迎えていると感じています。 エンジニアリング生産性の飛躍的な向上が現実のものとなり、従来の開発スタイルを根本から見直す時期に来ています。 開発スタイルの変化 AI を活用しているエンジニアとそうでないエンジニアの間で、処理できるタスク量に大きな差が生まれつつあります。もちろん、AI が活用しやすい領域とそうでない領域があるものの、その差は想像以上に大きく、今後さらに拡大していくでしょう。 メドレーでは 2025 年末までに、プロダクト開発のあらゆる職種(PdM/QA/Design/Engineer)・工程において AI 活用率 100%を目指しています。これは単なる数値目標ではなく、全デベロッパーが AI を自分の「パートナー」として効果的に活用できる状態を実現するためのビジョンです。 活用している AI ツール メドレーのエンジニアリング組織では、様々な AI ツールを開発プロセスに組み込み、生産性と創造性を高めています。以下では、特に効果を発揮している主要なツールとその実際の活用シーンについてご紹介します。 コード生成・開発支援ツール: Cursor、GitHub Copilot、Cline、Windsurf 元々 GitHub Copilot は全社導入していましたが、最近では Cursor をはじめとする AI エージェントや AI 搭載コードエディタも全社で利用できる環境を整えています。 これらのツールは単なるコード補完にとどまらず、開発体験そのものを変革しています。 思考支援・問題解決ツール: Claude、ChatGPT、Gemini、NotebookLM 対話型 AI は、思考のパートナーとして日々活躍しています。特に複雑な課題に直面した際、これらのツールを活用して問題解決の糸口を見つけています。 UIUX のプロトタイピングにもこれらのツールが大いに貢献しています。特に artifact 生成機能を活用することで、アイデアから視覚的な UI 案まで素早く作成でき、PdM・デザイナー・エンジニア間のコミュニケーションが格段にスムーズになっていく兆しを感じています。 自律型開発エージェント: Devin Devin は、開発スタイルに新たな可能性をもたらしています。「非同期での開発」を可能にし、開発者が他のタスクに取り組んでいる間でも、定型的な開発作業や特定の機能実装を進めることが現実となってきています。 検証初月で約 1,500 ACUs（約 375 時間相当）の活用実績があり、Devin を活用しているデベロッパーも現在 80 名を超えています。今後も予算の一部を Devin に割り当て、さらなる活用強化を進めています。 AI 開発プラットフォーム: Dify Dify のようなプラットフォームは、社内の AI 活用の実験場となっています。様々なモデルやプロンプトの検証、複雑な AI ワークフローの構築など、AI の可能性を探求する基盤として活用しています。 AI ツール活用の今後の基本方針 これらのツールを適材適所で組み合わせることで、開発プロセス全体の効率化を実現し、全社員が AI を自分のパートナーとして活用できる環境づくりを進めています。 その際、私たちが特に重視している点は以下の 2 つです： 単なるツール導入にとどまらず、効果的な活用方法のナレッジを組織内で共有し、継続的に改善していくこと FourKeys を軸に開発生産性をモニタリングし、データに基づいた改善を進めること まだ過渡期ではありますが、すでに複数のチームで開発サイクルの短縮や品質向上といった、生産性向上の明確な兆候が表れ始めています。 推進・検証中の領域 以下の領域は現在積極的に推進・検証中です。成果が出次第、順次アウトプットしていきます。 AI×QA AI を活用したテスト自動生成によるテストカバレッジの向上と QA 工数の削減 エッジケースの自動検出機能による人間が見落としがちなバグの早期発見 AI× データマネージメント 大規模データセットからのインサイト抽出と意思決定支援 データクレンジングと前処理の自動化によるデータ品質向上 「AI ファースト」の開発フロー AI が理解しやすいコード構造とドキュメント体系の標準化 ナレッジやルールを AI が理解しやすい形で蓄積・管理 MCP の利用ルールとガードレールの整備 安全かつ効率的な AI 活用のための社内 MCP ポリシーとガードレール設計 ドメイン知識を組み込んだ自社 MCP の開発と展開 AI 活用時代のエンジニア採用・人材要件 AI ツールを効果的に活用できる思考力と指示能力を重視した採用基準 技術的深さと AI との協業スキルを評価する新たな人材ペルソナ AI 関連費用対効果・費用モニタリング 各種ツールのコスト・モデルのコストなど様々なコスト管理 生産性モニタリング 医療 ×AI の可能性 医療現場では従来から画像診断や遺伝子解析などの臨床領域で AI 活用が進んでいますが、その他の業務領域にも AI を取り入れることで、さらなる効率化や価値創出の可能性が広がっていると考えています。 患者情報の入力や整理、診療記録の作成、医療スタッフ間のコミュニケーション、スケジュール管理など、医療現場の日常業務に AI を活用することで、医療従事者の負担を軽減し、本来の患者ケアにより集中できる環境づくりにつながる可能性があると思います。 メドレーは医療 DX から医療 AX へと進化する中で、医療従事者と患者の双方に価値を提供できる独自のポジションにあります。今後も AI を活用した新しいプロダクトラインアップを発表予定ですので、ご期待ください！ We’re hiring メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！ カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me

メドレーの AI 活用戦略 こんにちは！メドレー株式会社 人材プラットフォーム本部 VPoE の倉林( @terukura )です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。 昨今、多くの企業が AI の活用に取り組んでいますが、メドレーでは**「全職種が全業務で当たり前に AI を活用している企業：AI for All」**を目指して、それぞれの役割や業務に合わせた AI 活用を進めています。 メドレーでは「AI for All」を旗印に、AI 活用戦略を大きく 3 つの領域に分けています。 AI for All 1. AI 活用による業務オペレーションの効率化 ：日々の業務プロセスを AI で効率化し、ルーティンワークの時間を削減することで、より創造的な業務に集中できる環境を作ります。 2. AI 活用によるエンジニアリング生産性向上 ：開発サイクルの短縮と品質向上を実現し、より多くの価値を生み出せるようにします。 3. AI 活用によるプロダクト価値提供 ：ユーザーに直接価値を届ける AI 機能を実装し、メドレーのサービスをさらに進化させます。 またこれらの領域をそれぞれブーストさせるために、土台となる基礎活動もしっかり推進しています。 安心・安全な AI 活用のためのガイドライン整備 ：医療領域を扱う企業として、セキュリティとプライバシー保護は最優先事項です。社内では「AI ガイドライン」を整備し、明確な指針を提供することで、安心して AI ツールを活用できる環境を整えています。 AI Enabling ：全社の AI 活用レベルを底上げするため、様々な AI ツールや活用環境の整備、最新ツールの評価・共有、定期的な勉強会開催などを推進しています。社内 AI プラットフォームとして Dify を導入し、各部門が様々なモデルやフローの検証・活用を容易に行える環境を提供することで、技術的な障壁を低減しています。 今回の blog では、こうした全社的な取り組みの中でもエンジニア面談・面接でよく質問いただく 「AI 活用によるエンジニアリング生産性向上」 について、具体的な活用ツールなども踏まえてご紹介できればと思います。 プロダクト開発・エンジニアリングの変化 特に最近では、Claude Sonnet 3.7 の登場もあり、コーディング領域における AI 活用は大きなゲームチェンジを迎えていると感じています。 エンジニアリング生産性の飛躍的な向上が現実のものとなり、従来の開発スタイルを根本から見直す時期に来ています。 開発スタイルの変化 AI を活用しているエンジニアとそうでないエンジニアの間で、処理できるタスク量に大きな差が生まれつつあります。もちろん、AI が活用しやすい領域とそうでない領域があるものの、その差は想像以上に大きく、今後さらに拡大していくでしょう。 メドレーでは 2025 年末までに、プロダクト開発のあらゆる職種(PdM/QA/Design/Engineer)・工程において AI 活用率 100%を目指しています。これは単なる数値目標ではなく、全デベロッパーが AI を自分の「パートナー」として効果的に活用できる状態を実現するためのビジョンです。 活用している AI ツール メドレーのエンジニアリング組織では、様々な AI ツールを開発プロセスに組み込み、生産性と創造性を高めています。以下では、特に効果を発揮している主要なツールとその実際の活用シーンについてご紹介します。 コード生成・開発支援ツール: Cursor、GitHub Copilot、Cline、Windsurf 元々 GitHub Copilot は全社導入していましたが、最近では Cursor をはじめとする AI エージェントや AI 搭載コードエディタも全社で利用できる環境を整えています。 これらのツールは単なるコード補完にとどまらず、開発体験そのものを変革しています。 思考支援・問題解決ツール: Claude、ChatGPT、Gemini、NotebookLM 対話型 AI は、思考のパートナーとして日々活躍しています。特に複雑な課題に直面した際、これらのツールを活用して問題解決の糸口を見つけています。 UIUX のプロトタイピングにもこれらのツールが大いに貢献しています。特に artifact 生成機能を活用することで、アイデアから視覚的な UI 案まで素早く作成でき、PdM・デザイナー・エンジニア間のコミュニケーションが格段にスムーズになっていく兆しを感じています。 自律型開発エージェント: Devin Devin は、開発スタイルに新たな可能性をもたらしています。「非同期での開発」を可能にし、開発者が他のタスクに取り組んでいる間でも、定型的な開発作業や特定の機能実装を進めることが現実となってきています。 検証初月で約 1,500 ACUs（約 375 時間相当）の活用実績があり、Devin を活用しているデベロッパーも現在 80 名を超えています。今後も予算の一部を Devin に割り当て、さらなる活用強化を進めています。 AI 開発プラットフォーム: Dify Dify のようなプラットフォームは、社内の AI 活用の実験場となっています。様々なモデルやプロンプトの検証、複雑な AI ワークフローの構築など、AI の可能性を探求する基盤として活用しています。 AI ツール活用の今後の基本方針 これらのツールを適材適所で組み合わせることで、開発プロセス全体の効率化を実現し、全社員が AI を自分のパートナーとして活用できる環境づくりを進めています。 その際、私たちが特に重視している点は以下の 2 つです： 単なるツール導入にとどまらず、効果的な活用方法のナレッジを組織内で共有し、継続的に改善していくこと FourKeys を軸に開発生産性をモニタリングし、データに基づいた改善を進めること まだ過渡期ではありますが、すでに複数のチームで開発サイクルの短縮や品質向上といった、生産性向上の明確な兆候が表れ始めています。 推進・検証中の領域 以下の領域は現在積極的に推進・検証中です。成果が出次第、順次アウトプットしていきます。 AI×QA AI を活用したテスト自動生成によるテストカバレッジの向上と QA 工数の削減 エッジケースの自動検出機能による人間が見落としがちなバグの早期発見 AI× データマネージメント 大規模データセットからのインサイト抽出と意思決定支援 データクレンジングと前処理の自動化によるデータ品質向上 「AI ファースト」の開発フロー AI が理解しやすいコード構造とドキュメント体系の標準化 ナレッジやルールを AI が理解しやすい形で蓄積・管理 MCP の利用ルールとガードレールの整備 安全かつ効率的な AI 活用のための社内 MCP ポリシーとガードレール設計 ドメイン知識を組み込んだ自社 MCP の開発と展開 AI 活用時代のエンジニア採用・人材要件 AI ツールを効果的に活用できる思考力と指示能力を重視した採用基準 技術的深さと AI との協業スキルを評価する新たな人材ペルソナ AI 関連費用対効果・費用モニタリング 各種ツールのコスト・モデルのコストなど様々なコスト管理 生産性モニタリング 医療 ×AI の可能性 医療現場では従来から画像診断や遺伝子解析などの臨床領域で AI 活用が進んでいますが、その他の業務領域にも AI を取り入れることで、さらなる効率化や価値創出の可能性が広がっていると考えています。 患者情報の入力や整理、診療記録の作成、医療スタッフ間のコミュニケーション、スケジュール管理など、医療現場の日常業務に AI を活用することで、医療従事者の負担を軽減し、本来の患者ケアにより集中できる環境づくりにつながる可能性があると思います。 メドレーは医療 DX から医療 AX へと進化する中で、医療従事者と患者の双方に価値を提供できる独自のポジションにあります。今後も AI を活用した新しいプロダクトラインアップを発表予定ですので、ご期待ください！ We’re hiring メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！ カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me

メドレーの AI 活用戦略 こんにちは！メドレー株式会社 人材プラットフォーム本部 VPoE の倉林( @terukura )です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。 昨今、多くの企業が AI の活用に取り組んでいますが、メドレーでは**「全職種が全業務で当たり前に AI を活用している企業：AI for All」**を目指して、それぞれの役割や業務に合わせた AI 活用を進めています。 メドレーでは「AI for All」を旗印に、AI 活用戦略を大きく 3 つの領域に分けています。 AI for All 1. AI 活用による業務オペレーションの効率化 ：日々の業務プロセスを AI で効率化し、ルーティンワークの時間を削減することで、より創造的な業務に集中できる環境を作ります。 2. AI 活用によるエンジニアリング生産性向上 ：開発サイクルの短縮と品質向上を実現し、より多くの価値を生み出せるようにします。 3. AI 活用によるプロダクト価値提供 ：ユーザーに直接価値を届ける AI 機能を実装し、メドレーのサービスをさらに進化させます。 またこれらの領域をそれぞれブーストさせるために、土台となる基礎活動もしっかり推進しています。 安心・安全な AI 活用のためのガイドライン整備 ：医療領域を扱う企業として、セキュリティとプライバシー保護は最優先事項です。社内では「AI ガイドライン」を整備し、明確な指針を提供することで、安心して AI ツールを活用できる環境を整えています。 AI Enabling ：全社の AI 活用レベルを底上げするため、様々な AI ツールや活用環境の整備、最新ツールの評価・共有、定期的な勉強会開催などを推進しています。社内 AI プラットフォームとして Dify を導入し、各部門が様々なモデルやフローの検証・活用を容易に行える環境を提供することで、技術的な障壁を低減しています。 今回の blog では、こうした全社的な取り組みの中でもエンジニア面談・面接でよく質問いただく 「AI 活用によるエンジニアリング生産性向上」 について、具体的な活用ツールなども踏まえてご紹介できればと思います。 プロダクト開発・エンジニアリングの変化 特に最近では、Claude Sonnet 3.7 の登場もあり、コーディング領域における AI 活用は大きなゲームチェンジを迎えていると感じています。 エンジニアリング生産性の飛躍的な向上が現実のものとなり、従来の開発スタイルを根本から見直す時期に来ています。 開発スタイルの変化 AI を活用しているエンジニアとそうでないエンジニアの間で、処理できるタスク量に大きな差が生まれつつあります。もちろん、AI が活用しやすい領域とそうでない領域があるものの、その差は想像以上に大きく、今後さらに拡大していくでしょう。 メドレーでは 2025 年末までに、プロダクト開発のあらゆる職種(PdM/QA/Design/Engineer)・工程において AI 活用率 100%を目指しています。これは単なる数値目標ではなく、全デベロッパーが AI を自分の「パートナー」として効果的に活用できる状態を実現するためのビジョンです。 活用している AI ツール メドレーのエンジニアリング組織では、様々な AI ツールを開発プロセスに組み込み、生産性と創造性を高めています。以下では、特に効果を発揮している主要なツールとその実際の活用シーンについてご紹介します。 コード生成・開発支援ツール: Cursor、GitHub Copilot、Cline、Windsurf 元々 GitHub Copilot は全社導入していましたが、最近では Cursor をはじめとする AI エージェントや AI 搭載コードエディタも全社で利用できる環境を整えています。 これらのツールは単なるコード補完にとどまらず、開発体験そのものを変革しています。 思考支援・問題解決ツール: Claude、ChatGPT、Gemini、NotebookLM 対話型 AI は、思考のパートナーとして日々活躍しています。特に複雑な課題に直面した際、これらのツールを活用して問題解決の糸口を見つけています。 UIUX のプロトタイピングにもこれらのツールが大いに貢献しています。特に artifact 生成機能を活用することで、アイデアから視覚的な UI 案まで素早く作成でき、PdM・デザイナー・エンジニア間のコミュニケーションが格段にスムーズになっていく兆しを感じています。 自律型開発エージェント: Devin Devin は、開発スタイルに新たな可能性をもたらしています。「非同期での開発」を可能にし、開発者が他のタスクに取り組んでいる間でも、定型的な開発作業や特定の機能実装を進めることが現実となってきています。 検証初月で約 1,500 ACUs（約 375 時間相当）の活用実績があり、Devin を活用しているデベロッパーも現在 80 名を超えています。今後も予算の一部を Devin に割り当て、さらなる活用強化を進めています。 AI 開発プラットフォーム: Dify Dify のようなプラットフォームは、社内の AI 活用の実験場となっています。様々なモデルやプロンプトの検証、複雑な AI ワークフローの構築など、AI の可能性を探求する基盤として活用しています。 AI ツール活用の今後の基本方針 これらのツールを適材適所で組み合わせることで、開発プロセス全体の効率化を実現し、全社員が AI を自分のパートナーとして活用できる環境づくりを進めています。 その際、私たちが特に重視している点は以下の 2 つです： 単なるツール導入にとどまらず、効果的な活用方法のナレッジを組織内で共有し、継続的に改善していくこと FourKeys を軸に開発生産性をモニタリングし、データに基づいた改善を進めること まだ過渡期ではありますが、すでに複数のチームで開発サイクルの短縮や品質向上といった、生産性向上の明確な兆候が表れ始めています。 推進・検証中の領域 以下の領域は現在積極的に推進・検証中です。成果が出次第、順次アウトプットしていきます。 AI×QA AI を活用したテスト自動生成によるテストカバレッジの向上と QA 工数の削減 エッジケースの自動検出機能による人間が見落としがちなバグの早期発見 AI× データマネージメント 大規模データセットからのインサイト抽出と意思決定支援 データクレンジングと前処理の自動化によるデータ品質向上 「AI ファースト」の開発フロー AI が理解しやすいコード構造とドキュメント体系の標準化 ナレッジやルールを AI が理解しやすい形で蓄積・管理 MCP の利用ルールとガードレールの整備 安全かつ効率的な AI 活用のための社内 MCP ポリシーとガードレール設計 ドメイン知識を組み込んだ自社 MCP の開発と展開 AI 活用時代のエンジニア採用・人材要件 AI ツールを効果的に活用できる思考力と指示能力を重視した採用基準 技術的深さと AI との協業スキルを評価する新たな人材ペルソナ AI 関連費用対効果・費用モニタリング 各種ツールのコスト・モデルのコストなど様々なコスト管理 生産性モニタリング 医療 ×AI の可能性 医療現場では従来から画像診断や遺伝子解析などの臨床領域で AI 活用が進んでいますが、その他の業務領域にも AI を取り入れることで、さらなる効率化や価値創出の可能性が広がっていると考えています。 患者情報の入力や整理、診療記録の作成、医療スタッフ間のコミュニケーション、スケジュール管理など、医療現場の日常業務に AI を活用することで、医療従事者の負担を軽減し、本来の患者ケアにより集中できる環境づくりにつながる可能性があると思います。 メドレーは医療 DX から医療 AX へと進化する中で、医療従事者と患者の双方に価値を提供できる独自のポジションにあります。今後も AI を活用した新しいプロダクトラインアップを発表予定ですので、ご期待ください！ We’re hiring メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！ カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me

はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 16 日から 18 日に 愛媛県松山市の 愛媛県県民文化会館 にて開催された RubyKaigi 2025 に Platinum Sponsor として協賛しました！ RubyKaigi 2025 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。 入社したての私も含め、エンジニアとエンジニア採用担当の計 13 名が現地参加し、たくさんの方々と交流させて頂きました。 今回は会場・ブースと発表の様子をご紹介します。 会場の様子 当日は3日間とも天候に恵まれ穏やかな春の日和の中、RubyKaigi 2025 が行われました。 愛媛県民文化会館は松山市の道後温泉と大街道にほど近い立地で、県内最大級の文化施設の一つです。メインホールには2,725席を有しています。 重厚で堅牢な印象を与える外観 100を超える企業の協賛のもと、1,518名ものRubyistが参加。歴代でも最大規模のイベントとなりました！ 広々として開放感のある場内 参加者に配布された公式グッズは、オリジナルTシャツに加えて御朱印帳や砥部焼の箸置き、松竹錠の形をしたアクリルキーホルダーなど、開催地・愛媛県の特色を活かしたグッズとなっていました。 弊社ブースの様子 弊社は会場に入ってすぐ正面の場所にブースを設置させていただきました。 みなさんが感じている医療DXの課題をアンケートでヒアリングし、弊社がそれらの課題に技術を活用してどのように取り組んでいるかをご説明しました。 また、 弊社公式X をフォローしていただいた方や、弊社のイベントやテックブログなどの情報をご案内するメーリングリストに登録していただいた方にノベルティも差し上げました。医療事業を手がける企業としてのアピールも兼ねて、ノベルティには衛生キットと絆創膏をご用意しました。 オリジナルデザインの絆創膏も衛生キットも大人気でした！ 医療DXの課題アンケートで特に回答が多かったのが  「待ち時間が長い」  という課題でした。 メドレーの提供するオンライン診療・服薬指導アプリ「 CLINICS 」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、Uber Eats との連携で服薬指導後、最短30分程度で自宅までお薬を届けてもらうことも可能なことをご説明しました。 また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（ CLINICS 、 MALL 、 Pharms 、 Dentis ）を通じてサポートしていること、それぞれの課題に対して多様なサービスで様々なアプローチをとっていることなどをお話ししました。 メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加メンバー全員で 発表の様子 どのセッションも大変興味深く、一部難解な内容もありましたが、特に印象深かった下記のセッションについてご紹介します。 Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi Day1: Introducing Type Guard to Steep - Takeshi KOMIYA Day2: Making TCPSocket.new “Happy”! Misaki Shioi Day3: Matz Keynote Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi Day1の基調講演は、@ima1zumiさんによる、普段意識せずに使っている「文字」のコンピュータ上での表現と、Rubyでの扱いに関するセッションでした。文字コードの歴史的背景から最新動向まで深く掘り下げられました。 引用元: speakerdeck.com 概要 文字コードの進化 文字符号化の歴史として、のろしやモールス信号から、コンピュータ時代の ASCII、EBCDIC が紹介されました。特にEBCDICでの日本語表現の困難さ（ Shift-In/Out による 1バイト/2バイト 切り替え）の話は印象的で、現在の文字入力環境のありがたさを痛感しました。その後、世界中の文字を統一的に扱うUnicodeが誕生。「Universal」「Efficient」「Unambiguous」を目指し、UTF-8 や UTF-16 といったエンコーディング方式が普及しました。 Reline の事例から見えた課題 Rubyの REPL ライブラリ「Reline」で、特定の絵文字 🧑‍🧑‍🧒 家族 を入力して Backspace を押すとクラッシュする問題がありました。この絵文字は見た目上1文字でも、内部的には複数の Unicode コードポイント（7つ）で構成されています。Reline がこれをバイト数で処理しようとしたため問題が発生しました。ここで重要なのが、ユーザーが「1文字」と認識する単位である「書記素クラスタ (Grapheme Cluster)」です。合成文字や結合絵文字のように、見た目の文字数と内部コードポイント数が一致しないケースが存在します。Reline の問題は、この書記素クラスタを正しく認識していなかった点にありました。 Ruby における Unicode サポート Ruby は Unicode 15.1.0 仕様への準拠を進めています。Unicode標準のデータベースファイルを取り込み、内部処理に反映させています。正規表現エンジン「Onigmo」もUnicodeに対応しており、 \X （書記素クラスタ）や \p{Property} （Unicodeプロパティ）といったメタ文字が利用できます。これにより、開発者は内部表現を意識せずとも直感的な操作が可能です。書記素クラスタの分割ルール（例：GB9c）にも準拠しようとしています。今後の課題としてUnicode 16.0.0への追従や正規化対応が挙げられました。 感想 文字コードの奥深さ、支える技術、そして Ruby の対応を具体例と共に学べました。文字を入力し表現できていることが当たり前ではないこと、Unicode の複雑さに対応し、開発者が直感的に文字を扱えるようにする Ruby コミュニティの継続的な努力に感銘を受けました。今後の Unicode 標準と Ruby の進化に注目していきたいです。 Day1: Introducing Type Guard to Steep Takeshi KOMIYA さんによるセッションでは、Ruby の静的型チェッカー Steep における型ガード機能の改善と今後の展望が語られました。 引用元 drive.google.com 概要 これまでの Steep と型ガードの課題 Steep は型誤りを防ぐツールですが、従来の型ガードではRubyで多用される present? メソッドのような存在確認と型絞り込みを兼ねるパターンが機能せず、不必要な型エラーが発生し、開発体験を損なう一因となっていました。 Union Type に対する型ガードの強化 この課題に対応するため、Steep 1.10 以降で UnionType（例:  String | nil ）への型ガードが強化されました。設定記述により present? のようなメソッド呼び出しで nil でない型へ絞り込めるようになり、Ruby らしい自然なコードで型チェックの恩恵を受けられます。この機能は開発者定義のメソッドにも適用可能で、柔軟性が向上しました。 また、より直感的な型ガード宣言のため、新しいアノテーション構文  a{guard: self is AdminUser}  が紹介されました。特定の条件下で変数の型が特定の型であることを Steep に伝え、複雑な条件分岐における型情報を明確にします。 今後の展望 将来的な拡張として「Conditional Types」構想が紹介されました。これは特定条件下でのカスタム型ガード適用や返り値型の限定を可能にする機能です。複数の型情報を組み合わせる機能（例:  UserAdmin & Publish ）も関連して検討されており、より高度で精密な型チェックが実現します。 感想 Steep が開発者のフィードバックを取り入れ、より実践的に進化していると感じました。Guard アノテーションや Conditional Types など、今後の機能追加にも期待が持てます。Ruby における静的型チェックがより身近で強力なものになりつつあり、Steep の活用を検討したいと思いました。 Day2: Making TCPSocket.new “Happy” ! Misaki Shioi さんによるセッションでは、Ruby 標準ライブラリのTCP接続改善、特に TCPSocket.new への Happy Eyeballs Version 2 (HEv2) 実装の経緯と技術的挑戦が語られました。 引用元: speakerdeck.com 概要 TCPSocket.new を “Happy” にする試み TCPSocket.new への Happy Eyeballs Version 2 (HEv2, RFC8305) の実装について。HEv2はIPv4/IPv6両対応ホストへの接続を高速化する技術で、名前解決を並行し、早く応答があった方へ接続することで遅延を最小化します。Shioiさんは先行して Socket.tcp にHEv2を実装した経験を活かし、より低レイヤーの TCPSocket.new への改善に挑みました。 課題 先行実装した Socket.tcp 自体の課題（並行処理によるステートマシンの問題）に直面し、if文ベースのロジックに再実装して解決しました。この知見をもとに TCPSocket.new (C言語)へのHEv2実装に着手しましたが、RubyとCでの名前解決ライブラリの挙動差異など、新たな壁にぶつかりました。プラットフォーム間の差異吸収など、C言語レベルでの細かな調整を経てプルリクエストを完成させました。 プルリクエストのマージ後も、CI環境でのテスト失敗やユーザーからのバグ報告など、リリース直前まで予期せぬ問題への対応に追われました。これらの困難を乗り越え、この改善はRuby 3.4に無事に取り込まれました。 感想 HEv2実装の一連の取り組みが、時系列で非常に分かりやすく解説されました。 Socket.tcp の再実装から TCPSocket.new への実装、リリースまでの課題と解決策を追体験できました。実装コードの引用も多く、理解の助けになりました。ネットワーク低レイヤーの改善は Ruby エコシステム全体の品質向上に繋がる重要な取り組みであり、普段利用するTCP接続の裏側で行われているパフォーマンスと信頼性向上のための緻密な努力に感銘を受けました。 Day3: Matz Keynote RubyKaigi 2025 の最後は Matz 氏によるセッションでした。ステージのせり上がるギミックを利用して堂々と登場し、会場を驚きと笑いで包んだ Matz 氏は、現代の開発環境と Ruby の未来について語りました。 AIによる開発支援が急速に進む現代において、本来「楽しい」はずのプログラミングが、AIへの指示出し作業に終始し、人間がまるでAIの「しもべ」であるかのように勘違いしてしまう……。そんな「逆アルファシンドローム」に陥らないよう、Matz 氏は注意を促しました。Ruby の根幹にある「プログラミングを楽しむ」という精神を、技術が進化する今だからこそ、改めて胸に刻むべきだと語りました。 一方で、AIとの協調も未来の重要なテーマです。Matz氏は、将来の高度なAIとのコミュニケーションにおいて、Ruby が持つ「簡潔さ」「豊かな表現力」「高い拡張性」といった特性が、理想的なインターフェースとなり得るとしました。そして、AIがより良く学習できるよう、モダンで質の高い Ruby コードをコミュニティ全体で積極的に公開していくことの重要性を提言しました。 そして Ruby 自体の進化についても、RuboCop、IRB や Parser の進化といった開発者体験を向上させるツールの充実、YJIT/ZJIT や Deoptimization といった技術による着実なパフォーマンス向上についても触れ、Ruby がより強力で使いやすい言語へと進化し続けていることを強調しました。 また、Matz 氏は改めて Ruby の強さの源泉はコミュニティにあると述べました。多様なバックグラウンドを持つ人々を歓迎するオープンな姿勢と、コミュニティ全体で Ruby という言語を育てていく文化こそが、Rubyを特別なものにしています。 さらに、今年の12月に迎えるRubyの30周年を記念して、Ruby4.0 のリリースを予定していることを発表していました。 昨今のAIの目覚ましい発展は、エンジニアとして非常に心躍るものである一方、一抹の不安を感じさせる面もあります。しかし Matz 氏の講演は、むしろ Ruby と共に新しい未来を切り拓いていく希望を与えてくれるものでした。Ruby の「楽しさ」という原点を決して忘れず、AIを強力なパートナーとして、より創造的な開発を追求していきたいと、決意を新たにしました！ さいごに Ruby の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。 運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございます！ 来年は北海道・函館での開催を予定しているそうです。 メドレーには はこだて未来大学出身のメンバーも在籍しており、学内セミナーへの参加も積極的に行なっております。ゆかりある地での開催に向けて、今から非常に楽しみです。 私たちはこれからも Ruby コミュニティとともにさらに成長し、チャレンジし続けます！ After RubyKaigi 2025 を開催します！ https://increments.connpass.com/event/351891/ メドレーは同じくRubyKaigi スポンサー企業である Qiita社・OPTiM社 との合同開催によるアフターイベントを 5 月 14 日 に行います。 RubyKaigi の思い出や Kaigi Effect を受けて挑戦したことなど、楽しく話し合いましょう！ メドレーではこのようなイベントの開催のほかにも、Roppongi.rb など地域コミュニティや技術カンファレンスのスポンサーなどを通して、技術とコミュニティの発展を応援しています。 メドレーではエンジニアを積極採用中です！ メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 Ruby を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ 募集の一覧 https://www.medley.jp/jobs/ ※カジュアル面談ご希望の際は、<その他>にてその旨をご記載ください

はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 16 日から 18 日に 愛媛県松山市の 愛媛県県民文化会館 にて開催された RubyKaigi 2025 に Platinum Sponsor として協賛しました！ RubyKaigi 2025 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。 入社したての私も含め、エンジニアとエンジニア採用担当の計 13 名が現地参加し、たくさんの方々と交流させて頂きました。 今回は会場・ブースと発表の様子をご紹介します。 会場の様子 当日は3日間とも天候に恵まれ穏やかな春の日和の中、RubyKaigi 2025 が行われました。 愛媛県民文化会館は松山市の道後温泉と大街道にほど近い立地で、県内最大級の文化施設の一つです。メインホールには2,725席を有しています。 重厚で堅牢な印象を与える外観 100を超える企業の協賛のもと、1,518名ものRubyistが参加。歴代でも最大規模のイベントとなりました！ 広々として開放感のある場内 参加者に配布された公式グッズは、オリジナルTシャツに加えて御朱印帳や砥部焼の箸置き、松竹錠の形をしたアクリルキーホルダーなど、開催地・愛媛県の特色を活かしたグッズとなっていました。 弊社ブースの様子 弊社は会場に入ってすぐ正面の場所にブースを設置させていただきました。 みなさんが感じている医療DXの課題をアンケートでヒアリングし、弊社がそれらの課題に技術を活用してどのように取り組んでいるかをご説明しました。 また、 弊社公式X をフォローしていただいた方や、弊社のイベントやテックブログなどの情報をご案内するメーリングリストに登録していただいた方にノベルティも差し上げました。医療事業を手がける企業としてのアピールも兼ねて、ノベルティには衛生キットと絆創膏をご用意しました。 オリジナルデザインの絆創膏も衛生キットも大人気でした！ 医療DXの課題アンケートで特に回答が多かったのが  「待ち時間が長い」  という課題でした。 メドレーの提供するオンライン診療・服薬指導アプリ「 CLINICS 」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、Uber Eats との連携で服薬指導後、最短30分程度で自宅までお薬を届けてもらうことも可能なことをご説明しました。 また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（ CLINICS 、 MALL 、 Pharms 、 Dentis ）を通じてサポートしていること、それぞれの課題に対して多様なサービスで様々なアプローチをとっていることなどをお話ししました。 メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加メンバー全員で 発表の様子 どのセッションも大変興味深く、一部難解な内容もありましたが、特に印象深かった下記のセッションについてご紹介します。 Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi Day1: Introducing Type Guard to Steep - Takeshi KOMIYA Day2: Making TCPSocket.new “Happy”! Misaki Shioi Day3: Matz Keynote Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi Day1の基調講演は、@ima1zumiさんによる、普段意識せずに使っている「文字」のコンピュータ上での表現と、Rubyでの扱いに関するセッションでした。文字コードの歴史的背景から最新動向まで深く掘り下げられました。 引用元: speakerdeck.com 概要 文字コードの進化 文字符号化の歴史として、のろしやモールス信号から、コンピュータ時代の ASCII、EBCDIC が紹介されました。特にEBCDICでの日本語表現の困難さ（ Shift-In/Out による 1バイト/2バイト 切り替え）の話は印象的で、現在の文字入力環境のありがたさを痛感しました。その後、世界中の文字を統一的に扱うUnicodeが誕生。「Universal」「Efficient」「Unambiguous」を目指し、UTF-8 や UTF-16 といったエンコーディング方式が普及しました。 Reline の事例から見えた課題 Rubyの REPL ライブラリ「Reline」で、特定の絵文字 🧑‍🧑‍🧒 家族 を入力して Backspace を押すとクラッシュする問題がありました。この絵文字は見た目上1文字でも、内部的には複数の Unicode コードポイント（7つ）で構成されています。Reline がこれをバイト数で処理しようとしたため問題が発生しました。ここで重要なのが、ユーザーが「1文字」と認識する単位である「書記素クラスタ (Grapheme Cluster)」です。合成文字や結合絵文字のように、見た目の文字数と内部コードポイント数が一致しないケースが存在します。Reline の問題は、この書記素クラスタを正しく認識していなかった点にありました。 Ruby における Unicode サポート Ruby は Unicode 15.1.0 仕様への準拠を進めています。Unicode標準のデータベースファイルを取り込み、内部処理に反映させています。正規表現エンジン「Onigmo」もUnicodeに対応しており、 \X （書記素クラスタ）や \p{Property} （Unicodeプロパティ）といったメタ文字が利用できます。これにより、開発者は内部表現を意識せずとも直感的な操作が可能です。書記素クラスタの分割ルール（例：GB9c）にも準拠しようとしています。今後の課題としてUnicode 16.0.0への追従や正規化対応が挙げられました。 感想 文字コードの奥深さ、支える技術、そして Ruby の対応を具体例と共に学べました。文字を入力し表現できていることが当たり前ではないこと、Unicode の複雑さに対応し、開発者が直感的に文字を扱えるようにする Ruby コミュニティの継続的な努力に感銘を受けました。今後の Unicode 標準と Ruby の進化に注目していきたいです。 Day1: Introducing Type Guard to Steep Takeshi KOMIYA さんによるセッションでは、Ruby の静的型チェッカー Steep における型ガード機能の改善と今後の展望が語られました。 引用元 drive.google.com 概要 これまでの Steep と型ガードの課題 Steep は型誤りを防ぐツールですが、従来の型ガードではRubyで多用される present? メソッドのような存在確認と型絞り込みを兼ねるパターンが機能せず、不必要な型エラーが発生し、開発体験を損なう一因となっていました。 Union Type に対する型ガードの強化 この課題に対応するため、Steep 1.10 以降で UnionType（例:  String | nil ）への型ガードが強化されました。設定記述により present? のようなメソッド呼び出しで nil でない型へ絞り込めるようになり、Ruby らしい自然なコードで型チェックの恩恵を受けられます。この機能は開発者定義のメソッドにも適用可能で、柔軟性が向上しました。 また、より直感的な型ガード宣言のため、新しいアノテーション構文  a{guard: self is AdminUser}  が紹介されました。特定の条件下で変数の型が特定の型であることを Steep に伝え、複雑な条件分岐における型情報を明確にします。 今後の展望 将来的な拡張として「Conditional Types」構想が紹介されました。これは特定条件下でのカスタム型ガード適用や返り値型の限定を可能にする機能です。複数の型情報を組み合わせる機能（例:  UserAdmin & Publish ）も関連して検討されており、より高度で精密な型チェックが実現します。 感想 Steep が開発者のフィードバックを取り入れ、より実践的に進化していると感じました。Guard アノテーションや Conditional Types など、今後の機能追加にも期待が持てます。Ruby における静的型チェックがより身近で強力なものになりつつあり、Steep の活用を検討したいと思いました。 Day2: Making TCPSocket.new “Happy” ! Misaki Shioi さんによるセッションでは、Ruby 標準ライブラリのTCP接続改善、特に TCPSocket.new への Happy Eyeballs Version 2 (HEv2) 実装の経緯と技術的挑戦が語られました。 引用元: speakerdeck.com 概要 TCPSocket.new を “Happy” にする試み TCPSocket.new への Happy Eyeballs Version 2 (HEv2, RFC8305) の実装について。HEv2はIPv4/IPv6両対応ホストへの接続を高速化する技術で、名前解決を並行し、早く応答があった方へ接続することで遅延を最小化します。Shioiさんは先行して Socket.tcp にHEv2を実装した経験を活かし、より低レイヤーの TCPSocket.new への改善に挑みました。 課題 先行実装した Socket.tcp 自体の課題（並行処理によるステートマシンの問題）に直面し、if文ベースのロジックに再実装して解決しました。この知見をもとに TCPSocket.new (C言語)へのHEv2実装に着手しましたが、RubyとCでの名前解決ライブラリの挙動差異など、新たな壁にぶつかりました。プラットフォーム間の差異吸収など、C言語レベルでの細かな調整を経てプルリクエストを完成させました。 プルリクエストのマージ後も、CI環境でのテスト失敗やユーザーからのバグ報告など、リリース直前まで予期せぬ問題への対応に追われました。これらの困難を乗り越え、この改善はRuby 3.4に無事に取り込まれました。 感想 HEv2実装の一連の取り組みが、時系列で非常に分かりやすく解説されました。 Socket.tcp の再実装から TCPSocket.new への実装、リリースまでの課題と解決策を追体験できました。実装コードの引用も多く、理解の助けになりました。ネットワーク低レイヤーの改善は Ruby エコシステム全体の品質向上に繋がる重要な取り組みであり、普段利用するTCP接続の裏側で行われているパフォーマンスと信頼性向上のための緻密な努力に感銘を受けました。 Day3: Matz Keynote RubyKaigi 2025 の最後は Matz 氏によるセッションでした。ステージのせり上がるギミックを利用して堂々と登場し、会場を驚きと笑いで包んだ Matz 氏は、現代の開発環境と Ruby の未来について語りました。 AIによる開発支援が急速に進む現代において、本来「楽しい」はずのプログラミングが、AIへの指示出し作業に終始し、人間がまるでAIの「しもべ」であるかのように勘違いしてしまう……。そんな「逆アルファシンドローム」に陥らないよう、Matz 氏は注意を促しました。Ruby の根幹にある「プログラミングを楽しむ」という精神を、技術が進化する今だからこそ、改めて胸に刻むべきだと語りました。 一方で、AIとの協調も未来の重要なテーマです。Matz氏は、将来の高度なAIとのコミュニケーションにおいて、Ruby が持つ「簡潔さ」「豊かな表現力」「高い拡張性」といった特性が、理想的なインターフェースとなり得るとしました。そして、AIがより良く学習できるよう、モダンで質の高い Ruby コードをコミュニティ全体で積極的に公開していくことの重要性を提言しました。 そして Ruby 自体の進化についても、RuboCop、IRB や Parser の進化といった開発者体験を向上させるツールの充実、YJIT/ZJIT や Deoptimization といった技術による着実なパフォーマンス向上についても触れ、Ruby がより強力で使いやすい言語へと進化し続けていることを強調しました。 また、Matz 氏は改めて Ruby の強さの源泉はコミュニティにあると述べました。多様なバックグラウンドを持つ人々を歓迎するオープンな姿勢と、コミュニティ全体で Ruby という言語を育てていく文化こそが、Rubyを特別なものにしています。 さらに、今年の12月に迎えるRubyの30周年を記念して、Ruby4.0 のリリースを予定していることを発表していました。 昨今のAIの目覚ましい発展は、エンジニアとして非常に心躍るものである一方、一抹の不安を感じさせる面もあります。しかし Matz 氏の講演は、むしろ Ruby と共に新しい未来を切り拓いていく希望を与えてくれるものでした。Ruby の「楽しさ」という原点を決して忘れず、AIを強力なパートナーとして、より創造的な開発を追求していきたいと、決意を新たにしました！ さいごに Ruby の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。 運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございます！ 来年は北海道・函館での開催を予定しているそうです。 メドレーには はこだて未来大学出身のメンバーも在籍しており、学内セミナーへの参加も積極的に行なっております。ゆかりある地での開催に向けて、今から非常に楽しみです。 私たちはこれからも Ruby コミュニティとともにさらに成長し、チャレンジし続けます！ After RubyKaigi 2025 を開催します！ https://increments.connpass.com/event/351891/ メドレーは同じくRubyKaigi スポンサー企業である Qiita社・OPTiM社 との合同開催によるアフターイベントを 5 月 14 日 に行います。 RubyKaigi の思い出や Kaigi Effect を受けて挑戦したことなど、楽しく話し合いましょう！ メドレーではこのようなイベントの開催のほかにも、Roppongi.rb など地域コミュニティや技術カンファレンスのスポンサーなどを通して、技術とコミュニティの発展を応援しています。 メドレーではエンジニアを積極採用中です！ メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 Ruby を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ 募集の一覧 https://www.medley.jp/jobs/ ※カジュアル面談ご希望の際は、<その他>にてその旨をご記載ください

はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 16 日から 18 日に 愛媛県松山市の 愛媛県県民文化会館 にて開催された RubyKaigi 2025 に Platinum Sponsor として協賛しました！ RubyKaigi 2025 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。 入社したての私も含め、エンジニアとエンジニア採用担当の計 13 名が現地参加し、たくさんの方々と交流させて頂きました。 今回は会場・ブースと発表の様子をご紹介します。 会場の様子 当日は3日間とも天候に恵まれ穏やかな春の日和の中、RubyKaigi 2025 が行われました。 愛媛県民文化会館は松山市の道後温泉と大街道にほど近い立地で、県内最大級の文化施設の一つです。メインホールには2,725席を有しています。 重厚で堅牢な印象を与える外観 100を超える企業の協賛のもと、1,518名ものRubyistが参加。歴代でも最大規模のイベントとなりました！ 広々として開放感のある場内 参加者に配布された公式グッズは、オリジナルTシャツに加えて御朱印帳や砥部焼の箸置き、松竹錠の形をしたアクリルキーホルダーなど、開催地・愛媛県の特色を活かしたグッズとなっていました。 弊社ブースの様子 弊社は会場に入ってすぐ正面の場所にブースを設置させていただきました。 みなさんが感じている医療DXの課題をアンケートでヒアリングし、弊社がそれらの課題に技術を活用してどのように取り組んでいるかをご説明しました。 また、 弊社公式X をフォローしていただいた方や、弊社のイベントやテックブログなどの情報をご案内するメーリングリストに登録していただいた方にノベルティも差し上げました。医療事業を手がける企業としてのアピールも兼ねて、ノベルティには衛生キットと絆創膏をご用意しました。 オリジナルデザインの絆創膏も衛生キットも大人気でした！ 医療DXの課題アンケートで特に回答が多かったのが  「待ち時間が長い」  という課題でした。 メドレーの提供するオンライン診療・服薬指導アプリ「 CLINICS 」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、Uber Eats との連携で服薬指導後、最短30分程度で自宅までお薬を届けてもらうことも可能なことをご説明しました。 また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（ CLINICS 、 MALL 、 Pharms 、 Dentis ）を通じてサポートしていること、それぞれの課題に対して多様なサービスで様々なアプローチをとっていることなどをお話ししました。 メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加メンバー全員で 発表の様子 どのセッションも大変興味深く、一部難解な内容もありましたが、特に印象深かった下記のセッションについてご紹介します。 Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi Day1: Introducing Type Guard to Steep - Takeshi KOMIYA Day2: Making TCPSocket.new “Happy”! Misaki Shioi Day3: Matz Keynote Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi Day1の基調講演は、@ima1zumiさんによる、普段意識せずに使っている「文字」のコンピュータ上での表現と、Rubyでの扱いに関するセッションでした。文字コードの歴史的背景から最新動向まで深く掘り下げられました。 引用元: speakerdeck.com 概要 文字コードの進化 文字符号化の歴史として、のろしやモールス信号から、コンピュータ時代の ASCII、EBCDIC が紹介されました。特にEBCDICでの日本語表現の困難さ（ Shift-In/Out による 1バイト/2バイト 切り替え）の話は印象的で、現在の文字入力環境のありがたさを痛感しました。その後、世界中の文字を統一的に扱うUnicodeが誕生。「Universal」「Efficient」「Unambiguous」を目指し、UTF-8 や UTF-16 といったエンコーディング方式が普及しました。 Reline の事例から見えた課題 Rubyの REPL ライブラリ「Reline」で、特定の絵文字 🧑‍🧑‍🧒 家族 を入力して Backspace を押すとクラッシュする問題がありました。この絵文字は見た目上1文字でも、内部的には複数の Unicode コードポイント（7つ）で構成されています。Reline がこれをバイト数で処理しようとしたため問題が発生しました。ここで重要なのが、ユーザーが「1文字」と認識する単位である「書記素クラスタ (Grapheme Cluster)」です。合成文字や結合絵文字のように、見た目の文字数と内部コードポイント数が一致しないケースが存在します。Reline の問題は、この書記素クラスタを正しく認識していなかった点にありました。 Ruby における Unicode サポート Ruby は Unicode 15.1.0 仕様への準拠を進めています。Unicode標準のデータベースファイルを取り込み、内部処理に反映させています。正規表現エンジン「Onigmo」もUnicodeに対応しており、 \X （書記素クラスタ）や \p{Property} （Unicodeプロパティ）といったメタ文字が利用できます。これにより、開発者は内部表現を意識せずとも直感的な操作が可能です。書記素クラスタの分割ルール（例：GB9c）にも準拠しようとしています。今後の課題としてUnicode 16.0.0への追従や正規化対応が挙げられました。 感想 文字コードの奥深さ、支える技術、そして Ruby の対応を具体例と共に学べました。文字を入力し表現できていることが当たり前ではないこと、Unicode の複雑さに対応し、開発者が直感的に文字を扱えるようにする Ruby コミュニティの継続的な努力に感銘を受けました。今後の Unicode 標準と Ruby の進化に注目していきたいです。 Day1: Introducing Type Guard to Steep Takeshi KOMIYA さんによるセッションでは、Ruby の静的型チェッカー Steep における型ガード機能の改善と今後の展望が語られました。 引用元 drive.google.com 概要 これまでの Steep と型ガードの課題 Steep は型誤りを防ぐツールですが、従来の型ガードではRubyで多用される present? メソッドのような存在確認と型絞り込みを兼ねるパターンが機能せず、不必要な型エラーが発生し、開発体験を損なう一因となっていました。 Union Type に対する型ガードの強化 この課題に対応するため、Steep 1.10 以降で UnionType（例:  String | nil ）への型ガードが強化されました。設定記述により present? のようなメソッド呼び出しで nil でない型へ絞り込めるようになり、Ruby らしい自然なコードで型チェックの恩恵を受けられます。この機能は開発者定義のメソッドにも適用可能で、柔軟性が向上しました。 また、より直感的な型ガード宣言のため、新しいアノテーション構文  a{guard: self is AdminUser}  が紹介されました。特定の条件下で変数の型が特定の型であることを Steep に伝え、複雑な条件分岐における型情報を明確にします。 今後の展望 将来的な拡張として「Conditional Types」構想が紹介されました。これは特定条件下でのカスタム型ガード適用や返り値型の限定を可能にする機能です。複数の型情報を組み合わせる機能（例:  UserAdmin & Publish ）も関連して検討されており、より高度で精密な型チェックが実現します。 感想 Steep が開発者のフィードバックを取り入れ、より実践的に進化していると感じました。Guard アノテーションや Conditional Types など、今後の機能追加にも期待が持てます。Ruby における静的型チェックがより身近で強力なものになりつつあり、Steep の活用を検討したいと思いました。 Day2: Making TCPSocket.new “Happy” ! Misaki Shioi さんによるセッションでは、Ruby 標準ライブラリのTCP接続改善、特に TCPSocket.new への Happy Eyeballs Version 2 (HEv2) 実装の経緯と技術的挑戦が語られました。 引用元: speakerdeck.com 概要 TCPSocket.new を “Happy” にする試み TCPSocket.new への Happy Eyeballs Version 2 (HEv2, RFC8305) の実装について。HEv2はIPv4/IPv6両対応ホストへの接続を高速化する技術で、名前解決を並行し、早く応答があった方へ接続することで遅延を最小化します。Shioiさんは先行して Socket.tcp にHEv2を実装した経験を活かし、より低レイヤーの TCPSocket.new への改善に挑みました。 課題 先行実装した Socket.tcp 自体の課題（並行処理によるステートマシンの問題）に直面し、if文ベースのロジックに再実装して解決しました。この知見をもとに TCPSocket.new (C言語)へのHEv2実装に着手しましたが、RubyとCでの名前解決ライブラリの挙動差異など、新たな壁にぶつかりました。プラットフォーム間の差異吸収など、C言語レベルでの細かな調整を経てプルリクエストを完成させました。 プルリクエストのマージ後も、CI環境でのテスト失敗やユーザーからのバグ報告など、リリース直前まで予期せぬ問題への対応に追われました。これらの困難を乗り越え、この改善はRuby 3.4に無事に取り込まれました。 感想 HEv2実装の一連の取り組みが、時系列で非常に分かりやすく解説されました。 Socket.tcp の再実装から TCPSocket.new への実装、リリースまでの課題と解決策を追体験できました。実装コードの引用も多く、理解の助けになりました。ネットワーク低レイヤーの改善は Ruby エコシステム全体の品質向上に繋がる重要な取り組みであり、普段利用するTCP接続の裏側で行われているパフォーマンスと信頼性向上のための緻密な努力に感銘を受けました。 Day3: Matz Keynote RubyKaigi 2025 の最後は Matz 氏によるセッションでした。ステージのせり上がるギミックを利用して堂々と登場し、会場を驚きと笑いで包んだ Matz 氏は、現代の開発環境と Ruby の未来について語りました。 AIによる開発支援が急速に進む現代において、本来「楽しい」はずのプログラミングが、AIへの指示出し作業に終始し、人間がまるでAIの「しもべ」であるかのように勘違いしてしまう……。そんな「逆アルファシンドローム」に陥らないよう、Matz 氏は注意を促しました。Ruby の根幹にある「プログラミングを楽しむ」という精神を、技術が進化する今だからこそ、改めて胸に刻むべきだと語りました。 一方で、AIとの協調も未来の重要なテーマです。Matz氏は、将来の高度なAIとのコミュニケーションにおいて、Ruby が持つ「簡潔さ」「豊かな表現力」「高い拡張性」といった特性が、理想的なインターフェースとなり得るとしました。そして、AIがより良く学習できるよう、モダンで質の高い Ruby コードをコミュニティ全体で積極的に公開していくことの重要性を提言しました。 そして Ruby 自体の進化についても、RuboCop、IRB や Parser の進化といった開発者体験を向上させるツールの充実、YJIT/ZJIT や Deoptimization といった技術による着実なパフォーマンス向上についても触れ、Ruby がより強力で使いやすい言語へと進化し続けていることを強調しました。 また、Matz 氏は改めて Ruby の強さの源泉はコミュニティにあると述べました。多様なバックグラウンドを持つ人々を歓迎するオープンな姿勢と、コミュニティ全体で Ruby という言語を育てていく文化こそが、Rubyを特別なものにしています。 さらに、今年の12月に迎えるRubyの30周年を記念して、Ruby4.0 のリリースを予定していることを発表していました。 昨今のAIの目覚ましい発展は、エンジニアとして非常に心躍るものである一方、一抹の不安を感じさせる面もあります。しかし Matz 氏の講演は、むしろ Ruby と共に新しい未来を切り拓いていく希望を与えてくれるものでした。Ruby の「楽しさ」という原点を決して忘れず、AIを強力なパートナーとして、より創造的な開発を追求していきたいと、決意を新たにしました！ さいごに Ruby の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。 運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございます！ 来年は北海道・函館での開催を予定しているそうです。 メドレーには はこだて未来大学出身のメンバーも在籍しており、学内セミナーへの参加も積極的に行なっております。ゆかりある地での開催に向けて、今から非常に楽しみです。 私たちはこれからも Ruby コミュニティとともにさらに成長し、チャレンジし続けます！ After RubyKaigi 2025 を開催します！ https://increments.connpass.com/event/351891/ メドレーは同じくRubyKaigi スポンサー企業である Qiita社・OPTiM社 との合同開催によるアフターイベントを 5 月 14 日 に行います。 RubyKaigi の思い出や Kaigi Effect を受けて挑戦したことなど、楽しく話し合いましょう！ メドレーではこのようなイベントの開催のほかにも、Roppongi.rb など地域コミュニティや技術カンファレンスのスポンサーなどを通して、技術とコミュニティの発展を応援しています。 メドレーではエンジニアを積極採用中です！ メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 Ruby を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ 募集の一覧 https://www.medley.jp/jobs/ ※カジュアル面談ご希望の際は、<その他>にてその旨をご記載ください

はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 16 日から 18 日に 愛媛県松山市の 愛媛県県民文化会館 にて開催された RubyKaigi 2025 に Platinum Sponsor として協賛しました！ RubyKaigi 2025 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。 入社したての私も含め、エンジニアとエンジニア採用担当の計 13 名が現地参加し、たくさんの方々と交流させて頂きました。 今回は会場・ブースと発表の様子をご紹介します。 会場の様子 当日は3日間とも天候に恵まれ穏やかな春の日和の中、RubyKaigi 2025 が行われました。 愛媛県民文化会館は松山市の道後温泉と大街道にほど近い立地で、県内最大級の文化施設の一つです。メインホールには2,725席を有しています。 重厚で堅牢な印象を与える外観 100を超える企業の協賛のもと、1,518名ものRubyistが参加。歴代でも最大規模のイベントとなりました！ 広々として開放感のある場内 参加者に配布された公式グッズは、オリジナルTシャツに加えて御朱印帳や砥部焼の箸置き、松竹錠の形をしたアクリルキーホルダーなど、開催地・愛媛県の特色を活かしたグッズとなっていました。 弊社ブースの様子 弊社は会場に入ってすぐ正面の場所にブースを設置させていただきました。 みなさんが感じている医療DXの課題をアンケートでヒアリングし、弊社がそれらの課題に技術を活用してどのように取り組んでいるかをご説明しました。 また、 弊社公式X をフォローしていただいた方や、弊社のイベントやテックブログなどの情報をご案内するメーリングリストに登録していただいた方にノベルティも差し上げました。医療事業を手がける企業としてのアピールも兼ねて、ノベルティには衛生キットと絆創膏をご用意しました。 オリジナルデザインの絆創膏も衛生キットも大人気でした！ 医療DXの課題アンケートで特に回答が多かったのが  「待ち時間が長い」  という課題でした。 メドレーの提供するオンライン診療・服薬指導アプリ「 CLINICS 」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、Uber Eats との連携で服薬指導後、最短30分程度で自宅までお薬を届けてもらうことも可能なことをご説明しました。 また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（ CLINICS 、 MALL 、 Pharms 、 Dentis ）を通じてサポートしていること、それぞれの課題に対して多様なサービスで様々なアプローチをとっていることなどをお話ししました。 メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加メンバー全員で 発表の様子 どのセッションも大変興味深く、一部難解な内容もありましたが、特に印象深かった下記のセッションについてご紹介します。 Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi Day1: Introducing Type Guard to Steep - Takeshi KOMIYA Day2: Making TCPSocket.new “Happy”! Misaki Shioi Day3: Matz Keynote Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi Day1の基調講演は、@ima1zumiさんによる、普段意識せずに使っている「文字」のコンピュータ上での表現と、Rubyでの扱いに関するセッションでした。文字コードの歴史的背景から最新動向まで深く掘り下げられました。 引用元: speakerdeck.com 概要 文字コードの進化 文字符号化の歴史として、のろしやモールス信号から、コンピュータ時代の ASCII、EBCDIC が紹介されました。特にEBCDICでの日本語表現の困難さ（ Shift-In/Out による 1バイト/2バイト 切り替え）の話は印象的で、現在の文字入力環境のありがたさを痛感しました。その後、世界中の文字を統一的に扱うUnicodeが誕生。「Universal」「Efficient」「Unambiguous」を目指し、UTF-8 や UTF-16 といったエンコーディング方式が普及しました。 Reline の事例から見えた課題 Rubyの REPL ライブラリ「Reline」で、特定の絵文字 🧑‍🧑‍🧒 家族 を入力して Backspace を押すとクラッシュする問題がありました。この絵文字は見た目上1文字でも、内部的には複数の Unicode コードポイント（7つ）で構成されています。Reline がこれをバイト数で処理しようとしたため問題が発生しました。ここで重要なのが、ユーザーが「1文字」と認識する単位である「書記素クラスタ (Grapheme Cluster)」です。合成文字や結合絵文字のように、見た目の文字数と内部コードポイント数が一致しないケースが存在します。Reline の問題は、この書記素クラスタを正しく認識していなかった点にありました。 Ruby における Unicode サポート Ruby は Unicode 15.1.0 仕様への準拠を進めています。Unicode標準のデータベースファイルを取り込み、内部処理に反映させています。正規表現エンジン「Onigmo」もUnicodeに対応しており、 \X （書記素クラスタ）や \p{Property} （Unicodeプロパティ）といったメタ文字が利用できます。これにより、開発者は内部表現を意識せずとも直感的な操作が可能です。書記素クラスタの分割ルール（例：GB9c）にも準拠しようとしています。今後の課題としてUnicode 16.0.0への追従や正規化対応が挙げられました。 感想 文字コードの奥深さ、支える技術、そして Ruby の対応を具体例と共に学べました。文字を入力し表現できていることが当たり前ではないこと、Unicode の複雑さに対応し、開発者が直感的に文字を扱えるようにする Ruby コミュニティの継続的な努力に感銘を受けました。今後の Unicode 標準と Ruby の進化に注目していきたいです。 Day1: Introducing Type Guard to Steep Takeshi KOMIYA さんによるセッションでは、Ruby の静的型チェッカー Steep における型ガード機能の改善と今後の展望が語られました。 引用元 drive.google.com 概要 これまでの Steep と型ガードの課題 Steep は型誤りを防ぐツールですが、従来の型ガードではRubyで多用される present? メソッドのような存在確認と型絞り込みを兼ねるパターンが機能せず、不必要な型エラーが発生し、開発体験を損なう一因となっていました。 Union Type に対する型ガードの強化 この課題に対応するため、Steep 1.10 以降で UnionType（例:  String | nil ）への型ガードが強化されました。設定記述により present? のようなメソッド呼び出しで nil でない型へ絞り込めるようになり、Ruby らしい自然なコードで型チェックの恩恵を受けられます。この機能は開発者定義のメソッドにも適用可能で、柔軟性が向上しました。 また、より直感的な型ガード宣言のため、新しいアノテーション構文  a{guard: self is AdminUser}  が紹介されました。特定の条件下で変数の型が特定の型であることを Steep に伝え、複雑な条件分岐における型情報を明確にします。 今後の展望 将来的な拡張として「Conditional Types」構想が紹介されました。これは特定条件下でのカスタム型ガード適用や返り値型の限定を可能にする機能です。複数の型情報を組み合わせる機能（例:  UserAdmin & Publish ）も関連して検討されており、より高度で精密な型チェックが実現します。 感想 Steep が開発者のフィードバックを取り入れ、より実践的に進化していると感じました。Guard アノテーションや Conditional Types など、今後の機能追加にも期待が持てます。Ruby における静的型チェックがより身近で強力なものになりつつあり、Steep の活用を検討したいと思いました。 Day2: Making TCPSocket.new “Happy” ! Misaki Shioi さんによるセッションでは、Ruby 標準ライブラリのTCP接続改善、特に TCPSocket.new への Happy Eyeballs Version 2 (HEv2) 実装の経緯と技術的挑戦が語られました。 引用元: speakerdeck.com 概要 TCPSocket.new を “Happy” にする試み TCPSocket.new への Happy Eyeballs Version 2 (HEv2, RFC8305) の実装について。HEv2はIPv4/IPv6両対応ホストへの接続を高速化する技術で、名前解決を並行し、早く応答があった方へ接続することで遅延を最小化します。Shioiさんは先行して Socket.tcp にHEv2を実装した経験を活かし、より低レイヤーの TCPSocket.new への改善に挑みました。 課題 先行実装した Socket.tcp 自体の課題（並行処理によるステートマシンの問題）に直面し、if文ベースのロジックに再実装して解決しました。この知見をもとに TCPSocket.new (C言語)へのHEv2実装に着手しましたが、RubyとCでの名前解決ライブラリの挙動差異など、新たな壁にぶつかりました。プラットフォーム間の差異吸収など、C言語レベルでの細かな調整を経てプルリクエストを完成させました。 プルリクエストのマージ後も、CI環境でのテスト失敗やユーザーからのバグ報告など、リリース直前まで予期せぬ問題への対応に追われました。これらの困難を乗り越え、この改善はRuby 3.4に無事に取り込まれました。 感想 HEv2実装の一連の取り組みが、時系列で非常に分かりやすく解説されました。 Socket.tcp の再実装から TCPSocket.new への実装、リリースまでの課題と解決策を追体験できました。実装コードの引用も多く、理解の助けになりました。ネットワーク低レイヤーの改善は Ruby エコシステム全体の品質向上に繋がる重要な取り組みであり、普段利用するTCP接続の裏側で行われているパフォーマンスと信頼性向上のための緻密な努力に感銘を受けました。 Day3: Matz Keynote RubyKaigi 2025 の最後は Matz 氏によるセッションでした。ステージのせり上がるギミックを利用して堂々と登場し、会場を驚きと笑いで包んだ Matz 氏は、現代の開発環境と Ruby の未来について語りました。 AIによる開発支援が急速に進む現代において、本来「楽しい」はずのプログラミングが、AIへの指示出し作業に終始し、人間がまるでAIの「しもべ」であるかのように勘違いしてしまう……。そんな「逆アルファシンドローム」に陥らないよう、Matz 氏は注意を促しました。Ruby の根幹にある「プログラミングを楽しむ」という精神を、技術が進化する今だからこそ、改めて胸に刻むべきだと語りました。 一方で、AIとの協調も未来の重要なテーマです。Matz氏は、将来の高度なAIとのコミュニケーションにおいて、Ruby が持つ「簡潔さ」「豊かな表現力」「高い拡張性」といった特性が、理想的なインターフェースとなり得るとしました。そして、AIがより良く学習できるよう、モダンで質の高い Ruby コードをコミュニティ全体で積極的に公開していくことの重要性を提言しました。 そして Ruby 自体の進化についても、RuboCop、IRB や Parser の進化といった開発者体験を向上させるツールの充実、YJIT/ZJIT や Deoptimization といった技術による着実なパフォーマンス向上についても触れ、Ruby がより強力で使いやすい言語へと進化し続けていることを強調しました。 また、Matz 氏は改めて Ruby の強さの源泉はコミュニティにあると述べました。多様なバックグラウンドを持つ人々を歓迎するオープンな姿勢と、コミュニティ全体で Ruby という言語を育てていく文化こそが、Rubyを特別なものにしています。 さらに、今年の12月に迎えるRubyの30周年を記念して、Ruby4.0 のリリースを予定していることを発表していました。 昨今のAIの目覚ましい発展は、エンジニアとして非常に心躍るものである一方、一抹の不安を感じさせる面もあります。しかし Matz 氏の講演は、むしろ Ruby と共に新しい未来を切り拓いていく希望を与えてくれるものでした。Ruby の「楽しさ」という原点を決して忘れず、AIを強力なパートナーとして、より創造的な開発を追求していきたいと、決意を新たにしました！ さいごに Ruby の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。 運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございます！ 来年は北海道・函館での開催を予定しているそうです。 メドレーには はこだて未来大学出身のメンバーも在籍しており、学内セミナーへの参加も積極的に行なっております。ゆかりある地での開催に向けて、今から非常に楽しみです。 私たちはこれからも Ruby コミュニティとともにさらに成長し、チャレンジし続けます！ After RubyKaigi 2025 を開催します！ https://increments.connpass.com/event/351891/ メドレーは同じくRubyKaigi スポンサー企業である Qiita社・OPTiM社 との合同開催によるアフターイベントを 5 月 14 日 に行います。 RubyKaigi の思い出や Kaigi Effect を受けて挑戦したことなど、楽しく話し合いましょう！ メドレーではこのようなイベントの開催のほかにも、Roppongi.rb など地域コミュニティや技術カンファレンスのスポンサーなどを通して、技術とコミュニティの発展を応援しています。 メドレーではエンジニアを積極採用中です！ メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 Ruby を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ 募集の一覧 https://www.medley.jp/jobs/ ※カジュアル面談ご希望の際は、<その他>にてその旨をご記載ください

はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 16 日から 18 日に 愛媛県松山市の 愛媛県県民文化会館 にて開催された RubyKaigi 2025 に Platinum Sponsor として協賛しました！ RubyKaigi 2025 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。 入社したての私も含め、エンジニアとエンジニア採用担当の計 13 名が現地参加し、たくさんの方々と交流させて頂きました。 今回は会場・ブースと発表の様子をご紹介します。 会場の様子 当日は3日間とも天候に恵まれ穏やかな春の日和の中、RubyKaigi 2025 が行われました。 愛媛県民文化会館は松山市の道後温泉と大街道にほど近い立地で、県内最大級の文化施設の一つです。メインホールには2,725席を有しています。 重厚で堅牢な印象を与える外観 100を超える企業の協賛のもと、1,518名ものRubyistが参加。歴代でも最大規模のイベントとなりました！ 広々として開放感のある場内 参加者に配布された公式グッズは、オリジナルTシャツに加えて御朱印帳や砥部焼の箸置き、松竹錠の形をしたアクリルキーホルダーなど、開催地・愛媛県の特色を活かしたグッズとなっていました。 弊社ブースの様子 弊社は会場に入ってすぐ正面の場所にブースを設置させていただきました。 みなさんが感じている医療DXの課題をアンケートでヒアリングし、弊社がそれらの課題に技術を活用してどのように取り組んでいるかをご説明しました。 また、 弊社公式X をフォローしていただいた方や、弊社のイベントやテックブログなどの情報をご案内するメーリングリストに登録していただいた方にノベルティも差し上げました。医療事業を手がける企業としてのアピールも兼ねて、ノベルティには衛生キットと絆創膏をご用意しました。 オリジナルデザインの絆創膏も衛生キットも大人気でした！ 医療DXの課題アンケートで特に回答が多かったのが  「待ち時間が長い」  という課題でした。 メドレーの提供するオンライン診療・服薬指導アプリ「 CLINICS 」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、Uber Eats との連携で服薬指導後、最短30分程度で自宅までお薬を届けてもらうことも可能なことをご説明しました。 また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（ CLINICS 、 MALL 、 Pharms 、 Dentis ）を通じてサポートしていること、それぞれの課題に対して多様なサービスで様々なアプローチをとっていることなどをお話ししました。 メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加メンバー全員で 発表の様子 どのセッションも大変興味深く、一部難解な内容もありましたが、特に印象深かった下記のセッションについてご紹介します。 Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi Day1: Introducing Type Guard to Steep - Takeshi KOMIYA Day2: Making TCPSocket.new “Happy”! Misaki Shioi Day3: Matz Keynote Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi Day1の基調講演は、@ima1zumiさんによる、普段意識せずに使っている「文字」のコンピュータ上での表現と、Rubyでの扱いに関するセッションでした。文字コードの歴史的背景から最新動向まで深く掘り下げられました。 引用元: speakerdeck.com 概要 文字コードの進化 文字符号化の歴史として、のろしやモールス信号から、コンピュータ時代の ASCII、EBCDIC が紹介されました。特にEBCDICでの日本語表現の困難さ（ Shift-In/Out による 1バイト/2バイト 切り替え）の話は印象的で、現在の文字入力環境のありがたさを痛感しました。その後、世界中の文字を統一的に扱うUnicodeが誕生。「Universal」「Efficient」「Unambiguous」を目指し、UTF-8 や UTF-16 といったエンコーディング方式が普及しました。 Reline の事例から見えた課題 Rubyの REPL ライブラリ「Reline」で、特定の絵文字 🧑‍🧑‍🧒 家族 を入力して Backspace を押すとクラッシュする問題がありました。この絵文字は見た目上1文字でも、内部的には複数の Unicode コードポイント（7つ）で構成されています。Reline がこれをバイト数で処理しようとしたため問題が発生しました。ここで重要なのが、ユーザーが「1文字」と認識する単位である「書記素クラスタ (Grapheme Cluster)」です。合成文字や結合絵文字のように、見た目の文字数と内部コードポイント数が一致しないケースが存在します。Reline の問題は、この書記素クラスタを正しく認識していなかった点にありました。 Ruby における Unicode サポート Ruby は Unicode 15.1.0 仕様への準拠を進めています。Unicode標準のデータベースファイルを取り込み、内部処理に反映させています。正規表現エンジン「Onigmo」もUnicodeに対応しており、 \X （書記素クラスタ）や \p{Property} （Unicodeプロパティ）といったメタ文字が利用できます。これにより、開発者は内部表現を意識せずとも直感的な操作が可能です。書記素クラスタの分割ルール（例：GB9c）にも準拠しようとしています。今後の課題としてUnicode 16.0.0への追従や正規化対応が挙げられました。 感想 文字コードの奥深さ、支える技術、そして Ruby の対応を具体例と共に学べました。文字を入力し表現できていることが当たり前ではないこと、Unicode の複雑さに対応し、開発者が直感的に文字を扱えるようにする Ruby コミュニティの継続的な努力に感銘を受けました。今後の Unicode 標準と Ruby の進化に注目していきたいです。 Day1: Introducing Type Guard to Steep Takeshi KOMIYA さんによるセッションでは、Ruby の静的型チェッカー Steep における型ガード機能の改善と今後の展望が語られました。 引用元 drive.google.com 概要 これまでの Steep と型ガードの課題 Steep は型誤りを防ぐツールですが、従来の型ガードではRubyで多用される present? メソッドのような存在確認と型絞り込みを兼ねるパターンが機能せず、不必要な型エラーが発生し、開発体験を損なう一因となっていました。 Union Type に対する型ガードの強化 この課題に対応するため、Steep 1.10 以降で UnionType（例:  String | nil ）への型ガードが強化されました。設定記述により present? のようなメソッド呼び出しで nil でない型へ絞り込めるようになり、Ruby らしい自然なコードで型チェックの恩恵を受けられます。この機能は開発者定義のメソッドにも適用可能で、柔軟性が向上しました。 また、より直感的な型ガード宣言のため、新しいアノテーション構文  a{guard: self is AdminUser}  が紹介されました。特定の条件下で変数の型が特定の型であることを Steep に伝え、複雑な条件分岐における型情報を明確にします。 今後の展望 将来的な拡張として「Conditional Types」構想が紹介されました。これは特定条件下でのカスタム型ガード適用や返り値型の限定を可能にする機能です。複数の型情報を組み合わせる機能（例:  UserAdmin & Publish ）も関連して検討されており、より高度で精密な型チェックが実現します。 感想 Steep が開発者のフィードバックを取り入れ、より実践的に進化していると感じました。Guard アノテーションや Conditional Types など、今後の機能追加にも期待が持てます。Ruby における静的型チェックがより身近で強力なものになりつつあり、Steep の活用を検討したいと思いました。 Day2: Making TCPSocket.new “Happy” ! Misaki Shioi さんによるセッションでは、Ruby 標準ライブラリのTCP接続改善、特に TCPSocket.new への Happy Eyeballs Version 2 (HEv2) 実装の経緯と技術的挑戦が語られました。 引用元: speakerdeck.com 概要 TCPSocket.new を “Happy” にする試み TCPSocket.new への Happy Eyeballs Version 2 (HEv2, RFC8305) の実装について。HEv2はIPv4/IPv6両対応ホストへの接続を高速化する技術で、名前解決を並行し、早く応答があった方へ接続することで遅延を最小化します。Shioiさんは先行して Socket.tcp にHEv2を実装した経験を活かし、より低レイヤーの TCPSocket.new への改善に挑みました。 課題 先行実装した Socket.tcp 自体の課題（並行処理によるステートマシンの問題）に直面し、if文ベースのロジックに再実装して解決しました。この知見をもとに TCPSocket.new (C言語)へのHEv2実装に着手しましたが、RubyとCでの名前解決ライブラリの挙動差異など、新たな壁にぶつかりました。プラットフォーム間の差異吸収など、C言語レベルでの細かな調整を経てプルリクエストを完成させました。 プルリクエストのマージ後も、CI環境でのテスト失敗やユーザーからのバグ報告など、リリース直前まで予期せぬ問題への対応に追われました。これらの困難を乗り越え、この改善はRuby 3.4に無事に取り込まれました。 感想 HEv2実装の一連の取り組みが、時系列で非常に分かりやすく解説されました。 Socket.tcp の再実装から TCPSocket.new への実装、リリースまでの課題と解決策を追体験できました。実装コードの引用も多く、理解の助けになりました。ネットワーク低レイヤーの改善は Ruby エコシステム全体の品質向上に繋がる重要な取り組みであり、普段利用するTCP接続の裏側で行われているパフォーマンスと信頼性向上のための緻密な努力に感銘を受けました。 Day3: Matz Keynote RubyKaigi 2025 の最後は Matz 氏によるセッションでした。ステージのせり上がるギミックを利用して堂々と登場し、会場を驚きと笑いで包んだ Matz 氏は、現代の開発環境と Ruby の未来について語りました。 AIによる開発支援が急速に進む現代において、本来「楽しい」はずのプログラミングが、AIへの指示出し作業に終始し、人間がまるでAIの「しもべ」であるかのように勘違いしてしまう……。そんな「逆アルファシンドローム」に陥らないよう、Matz 氏は注意を促しました。Ruby の根幹にある「プログラミングを楽しむ」という精神を、技術が進化する今だからこそ、改めて胸に刻むべきだと語りました。 一方で、AIとの協調も未来の重要なテーマです。Matz氏は、将来の高度なAIとのコミュニケーションにおいて、Ruby が持つ「簡潔さ」「豊かな表現力」「高い拡張性」といった特性が、理想的なインターフェースとなり得るとしました。そして、AIがより良く学習できるよう、モダンで質の高い Ruby コードをコミュニティ全体で積極的に公開していくことの重要性を提言しました。 そして Ruby 自体の進化についても、RuboCop、IRB や Parser の進化といった開発者体験を向上させるツールの充実、YJIT/ZJIT や Deoptimization といった技術による着実なパフォーマンス向上についても触れ、Ruby がより強力で使いやすい言語へと進化し続けていることを強調しました。 また、Matz 氏は改めて Ruby の強さの源泉はコミュニティにあると述べました。多様なバックグラウンドを持つ人々を歓迎するオープンな姿勢と、コミュニティ全体で Ruby という言語を育てていく文化こそが、Rubyを特別なものにしています。 さらに、今年の12月に迎えるRubyの30周年を記念して、Ruby4.0 のリリースを予定していることを発表していました。 昨今のAIの目覚ましい発展は、エンジニアとして非常に心躍るものである一方、一抹の不安を感じさせる面もあります。しかし Matz 氏の講演は、むしろ Ruby と共に新しい未来を切り拓いていく希望を与えてくれるものでした。Ruby の「楽しさ」という原点を決して忘れず、AIを強力なパートナーとして、より創造的な開発を追求していきたいと、決意を新たにしました！ さいごに Ruby の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。 運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございます！ 来年は北海道・函館での開催を予定しているそうです。 メドレーには はこだて未来大学出身のメンバーも在籍しており、学内セミナーへの参加も積極的に行なっております。ゆかりある地での開催に向けて、今から非常に楽しみです。 私たちはこれからも Ruby コミュニティとともにさらに成長し、チャレンジし続けます！ After RubyKaigi 2025 を開催します！ https://increments.connpass.com/event/351891/ メドレーは同じくRubyKaigi スポンサー企業である Qiita社・OPTiM社 との合同開催によるアフターイベントを 5 月 14 日 に行います。 RubyKaigi の思い出や Kaigi Effect を受けて挑戦したことなど、楽しく話し合いましょう！ メドレーではこのようなイベントの開催のほかにも、Roppongi.rb など地域コミュニティや技術カンファレンスのスポンサーなどを通して、技術とコミュニティの発展を応援しています。 メドレーではエンジニアを積極採用中です！ メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 Ruby を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ 募集の一覧 https://www.medley.jp/jobs/ ※カジュアル面談ご希望の際は、<その他>にてその旨をご記載ください

はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 16 日から 18 日に 愛媛県松山市の 愛媛県県民文化会館 にて開催された RubyKaigi 2025 に Platinum Sponsor として協賛しました！ RubyKaigi 2025 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。 入社したての私も含め、エンジニアとエンジニア採用担当の計 13 名が現地参加し、たくさんの方々と交流させて頂きました。 今回は会場・ブースと発表の様子をご紹介します。 会場の様子 当日は3日間とも天候に恵まれ穏やかな春の日和の中、RubyKaigi 2025 が行われました。 愛媛県民文化会館は松山市の道後温泉と大街道にほど近い立地で、県内最大級の文化施設の一つです。メインホールには2,725席を有しています。 重厚で堅牢な印象を与える外観 100を超える企業の協賛のもと、1,518名ものRubyistが参加。歴代でも最大規模のイベントとなりました！ 広々として開放感のある場内 参加者に配布された公式グッズは、オリジナルTシャツに加えて御朱印帳や砥部焼の箸置き、松竹錠の形をしたアクリルキーホルダーなど、開催地・愛媛県の特色を活かしたグッズとなっていました。 弊社ブースの様子 弊社は会場に入ってすぐ正面の場所にブースを設置させていただきました。 みなさんが感じている医療DXの課題をアンケートでヒアリングし、弊社がそれらの課題に技術を活用してどのように取り組んでいるかをご説明しました。 また、 弊社公式X をフォローしていただいた方や、弊社のイベントやテックブログなどの情報をご案内するメーリングリストに登録していただいた方にノベルティも差し上げました。医療事業を手がける企業としてのアピールも兼ねて、ノベルティには衛生キットと絆創膏をご用意しました。 オリジナルデザインの絆創膏も衛生キットも大人気でした！ 医療DXの課題アンケートで特に回答が多かったのが  「待ち時間が長い」  という課題でした。 メドレーの提供するオンライン診療・服薬指導アプリ「 CLINICS 」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、Uber Eats との連携で服薬指導後、最短30分程度で自宅までお薬を届けてもらうことも可能なことをご説明しました。 また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（ CLINICS 、 MALL 、 Pharms 、 Dentis ）を通じてサポートしていること、それぞれの課題に対して多様なサービスで様々なアプローチをとっていることなどをお話ししました。 メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加メンバー全員で 発表の様子 どのセッションも大変興味深く、一部難解な内容もありましたが、特に印象深かった下記のセッションについてご紹介します。 Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi Day1: Introducing Type Guard to Steep - Takeshi KOMIYA Day2: Making TCPSocket.new “Happy”! Misaki Shioi Day3: Matz Keynote Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi Day1の基調講演は、@ima1zumiさんによる、普段意識せずに使っている「文字」のコンピュータ上での表現と、Rubyでの扱いに関するセッションでした。文字コードの歴史的背景から最新動向まで深く掘り下げられました。 引用元: speakerdeck.com 概要 文字コードの進化 文字符号化の歴史として、のろしやモールス信号から、コンピュータ時代の ASCII、EBCDIC が紹介されました。特にEBCDICでの日本語表現の困難さ（ Shift-In/Out による 1バイト/2バイト 切り替え）の話は印象的で、現在の文字入力環境のありがたさを痛感しました。その後、世界中の文字を統一的に扱うUnicodeが誕生。「Universal」「Efficient」「Unambiguous」を目指し、UTF-8 や UTF-16 といったエンコーディング方式が普及しました。 Reline の事例から見えた課題 Rubyの REPL ライブラリ「Reline」で、特定の絵文字 🧑‍🧑‍🧒 家族 を入力して Backspace を押すとクラッシュする問題がありました。この絵文字は見た目上1文字でも、内部的には複数の Unicode コードポイント（7つ）で構成されています。Reline がこれをバイト数で処理しようとしたため問題が発生しました。ここで重要なのが、ユーザーが「1文字」と認識する単位である「書記素クラスタ (Grapheme Cluster)」です。合成文字や結合絵文字のように、見た目の文字数と内部コードポイント数が一致しないケースが存在します。Reline の問題は、この書記素クラスタを正しく認識していなかった点にありました。 Ruby における Unicode サポート Ruby は Unicode 15.1.0 仕様への準拠を進めています。Unicode標準のデータベースファイルを取り込み、内部処理に反映させています。正規表現エンジン「Onigmo」もUnicodeに対応しており、 \X （書記素クラスタ）や \p{Property} （Unicodeプロパティ）といったメタ文字が利用できます。これにより、開発者は内部表現を意識せずとも直感的な操作が可能です。書記素クラスタの分割ルール（例：GB9c）にも準拠しようとしています。今後の課題としてUnicode 16.0.0への追従や正規化対応が挙げられました。 感想 文字コードの奥深さ、支える技術、そして Ruby の対応を具体例と共に学べました。文字を入力し表現できていることが当たり前ではないこと、Unicode の複雑さに対応し、開発者が直感的に文字を扱えるようにする Ruby コミュニティの継続的な努力に感銘を受けました。今後の Unicode 標準と Ruby の進化に注目していきたいです。 Day1: Introducing Type Guard to Steep Takeshi KOMIYA さんによるセッションでは、Ruby の静的型チェッカー Steep における型ガード機能の改善と今後の展望が語られました。 引用元 drive.google.com 概要 これまでの Steep と型ガードの課題 Steep は型誤りを防ぐツールですが、従来の型ガードではRubyで多用される present? メソッドのような存在確認と型絞り込みを兼ねるパターンが機能せず、不必要な型エラーが発生し、開発体験を損なう一因となっていました。 Union Type に対する型ガードの強化 この課題に対応するため、Steep 1.10 以降で UnionType（例:  String | nil ）への型ガードが強化されました。設定記述により present? のようなメソッド呼び出しで nil でない型へ絞り込めるようになり、Ruby らしい自然なコードで型チェックの恩恵を受けられます。この機能は開発者定義のメソッドにも適用可能で、柔軟性が向上しました。 また、より直感的な型ガード宣言のため、新しいアノテーション構文  a{guard: self is AdminUser}  が紹介されました。特定の条件下で変数の型が特定の型であることを Steep に伝え、複雑な条件分岐における型情報を明確にします。 今後の展望 将来的な拡張として「Conditional Types」構想が紹介されました。これは特定条件下でのカスタム型ガード適用や返り値型の限定を可能にする機能です。複数の型情報を組み合わせる機能（例:  UserAdmin & Publish ）も関連して検討されており、より高度で精密な型チェックが実現します。 感想 Steep が開発者のフィードバックを取り入れ、より実践的に進化していると感じました。Guard アノテーションや Conditional Types など、今後の機能追加にも期待が持てます。Ruby における静的型チェックがより身近で強力なものになりつつあり、Steep の活用を検討したいと思いました。 Day2: Making TCPSocket.new “Happy” ! Misaki Shioi さんによるセッションでは、Ruby 標準ライブラリのTCP接続改善、特に TCPSocket.new への Happy Eyeballs Version 2 (HEv2) 実装の経緯と技術的挑戦が語られました。 引用元: speakerdeck.com 概要 TCPSocket.new を “Happy” にする試み TCPSocket.new への Happy Eyeballs Version 2 (HEv2, RFC8305) の実装について。HEv2はIPv4/IPv6両対応ホストへの接続を高速化する技術で、名前解決を並行し、早く応答があった方へ接続することで遅延を最小化します。Shioiさんは先行して Socket.tcp にHEv2を実装した経験を活かし、より低レイヤーの TCPSocket.new への改善に挑みました。 課題 先行実装した Socket.tcp 自体の課題（並行処理によるステートマシンの問題）に直面し、if文ベースのロジックに再実装して解決しました。この知見をもとに TCPSocket.new (C言語)へのHEv2実装に着手しましたが、RubyとCでの名前解決ライブラリの挙動差異など、新たな壁にぶつかりました。プラットフォーム間の差異吸収など、C言語レベルでの細かな調整を経てプルリクエストを完成させました。 プルリクエストのマージ後も、CI環境でのテスト失敗やユーザーからのバグ報告など、リリース直前まで予期せぬ問題への対応に追われました。これらの困難を乗り越え、この改善はRuby 3.4に無事に取り込まれました。 感想 HEv2実装の一連の取り組みが、時系列で非常に分かりやすく解説されました。 Socket.tcp の再実装から TCPSocket.new への実装、リリースまでの課題と解決策を追体験できました。実装コードの引用も多く、理解の助けになりました。ネットワーク低レイヤーの改善は Ruby エコシステム全体の品質向上に繋がる重要な取り組みであり、普段利用するTCP接続の裏側で行われているパフォーマンスと信頼性向上のための緻密な努力に感銘を受けました。 Day3: Matz Keynote RubyKaigi 2025 の最後は Matz 氏によるセッションでした。ステージのせり上がるギミックを利用して堂々と登場し、会場を驚きと笑いで包んだ Matz 氏は、現代の開発環境と Ruby の未来について語りました。 AIによる開発支援が急速に進む現代において、本来「楽しい」はずのプログラミングが、AIへの指示出し作業に終始し、人間がまるでAIの「しもべ」であるかのように勘違いしてしまう……。そんな「逆アルファシンドローム」に陥らないよう、Matz 氏は注意を促しました。Ruby の根幹にある「プログラミングを楽しむ」という精神を、技術が進化する今だからこそ、改めて胸に刻むべきだと語りました。 一方で、AIとの協調も未来の重要なテーマです。Matz氏は、将来の高度なAIとのコミュニケーションにおいて、Ruby が持つ「簡潔さ」「豊かな表現力」「高い拡張性」といった特性が、理想的なインターフェースとなり得るとしました。そして、AIがより良く学習できるよう、モダンで質の高い Ruby コードをコミュニティ全体で積極的に公開していくことの重要性を提言しました。 そして Ruby 自体の進化についても、RuboCop、IRB や Parser の進化といった開発者体験を向上させるツールの充実、YJIT/ZJIT や Deoptimization といった技術による着実なパフォーマンス向上についても触れ、Ruby がより強力で使いやすい言語へと進化し続けていることを強調しました。 また、Matz 氏は改めて Ruby の強さの源泉はコミュニティにあると述べました。多様なバックグラウンドを持つ人々を歓迎するオープンな姿勢と、コミュニティ全体で Ruby という言語を育てていく文化こそが、Rubyを特別なものにしています。 さらに、今年の12月に迎えるRubyの30周年を記念して、Ruby4.0 のリリースを予定していることを発表していました。 昨今のAIの目覚ましい発展は、エンジニアとして非常に心躍るものである一方、一抹の不安を感じさせる面もあります。しかし Matz 氏の講演は、むしろ Ruby と共に新しい未来を切り拓いていく希望を与えてくれるものでした。Ruby の「楽しさ」という原点を決して忘れず、AIを強力なパートナーとして、より創造的な開発を追求していきたいと、決意を新たにしました！ さいごに Ruby の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。 運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございます！ 来年は北海道・函館での開催を予定しているそうです。 メドレーには はこだて未来大学出身のメンバーも在籍しており、学内セミナーへの参加も積極的に行なっております。ゆかりある地での開催に向けて、今から非常に楽しみです。 私たちはこれからも Ruby コミュニティとともにさらに成長し、チャレンジし続けます！ After RubyKaigi 2025 を開催します！ https://increments.connpass.com/event/351891/ メドレーは同じくRubyKaigi スポンサー企業である Qiita社・OPTiM社 との合同開催によるアフターイベントを 5 月 14 日 に行います。 RubyKaigi の思い出や Kaigi Effect を受けて挑戦したことなど、楽しく話し合いましょう！ メドレーではこのようなイベントの開催のほかにも、Roppongi.rb など地域コミュニティや技術カンファレンスのスポンサーなどを通して、技術とコミュニティの発展を応援しています。 メドレーではエンジニアを積極採用中です！ メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 Ruby を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ 募集の一覧 https://www.medley.jp/jobs/ ※カジュアル面談ご希望の際は、<その他>にてその旨をご記載ください

はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 16 日から 18 日に 愛媛県松山市の 愛媛県県民文化会館 にて開催された RubyKaigi 2025 に Platinum Sponsor として協賛しました！ RubyKaigi 2025 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。 入社したての私も含め、エンジニアとエンジニア採用担当の計 13 名が現地参加し、たくさんの方々と交流させて頂きました。 今回は会場・ブースと発表の様子をご紹介します。 会場の様子 当日は3日間とも天候に恵まれ穏やかな春の日和の中、RubyKaigi 2025 が行われました。 愛媛県民文化会館は松山市の道後温泉と大街道にほど近い立地で、県内最大級の文化施設の一つです。メインホールには2,725席を有しています。 重厚で堅牢な印象を与える外観 100を超える企業の協賛のもと、1,518名ものRubyistが参加。歴代でも最大規模のイベントとなりました！ 広々として開放感のある場内 参加者に配布された公式グッズは、オリジナルTシャツに加えて御朱印帳や砥部焼の箸置き、松竹錠の形をしたアクリルキーホルダーなど、開催地・愛媛県の特色を活かしたグッズとなっていました。 弊社ブースの様子 弊社は会場に入ってすぐ正面の場所にブースを設置させていただきました。 みなさんが感じている医療DXの課題をアンケートでヒアリングし、弊社がそれらの課題に技術を活用してどのように取り組んでいるかをご説明しました。 また、 弊社公式X をフォローしていただいた方や、弊社のイベントやテックブログなどの情報をご案内するメーリングリストに登録していただいた方にノベルティも差し上げました。医療事業を手がける企業としてのアピールも兼ねて、ノベルティには衛生キットと絆創膏をご用意しました。 オリジナルデザインの絆創膏も衛生キットも大人気でした！ 医療DXの課題アンケートで特に回答が多かったのが  「待ち時間が長い」  という課題でした。 メドレーの提供するオンライン診療・服薬指導アプリ「 CLINICS 」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、Uber Eats との連携で服薬指導後、最短30分程度で自宅までお薬を届けてもらうことも可能なことをご説明しました。 また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（ CLINICS 、 MALL 、 Pharms 、 Dentis ）を通じてサポートしていること、それぞれの課題に対して多様なサービスで様々なアプローチをとっていることなどをお話ししました。 メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加メンバー全員で 発表の様子 どのセッションも大変興味深く、一部難解な内容もありましたが、特に印象深かった下記のセッションについてご紹介します。 Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi Day1: Introducing Type Guard to Steep - Takeshi KOMIYA Day2: Making TCPSocket.new “Happy”! Misaki Shioi Day3: Matz Keynote Day1 Keynote: Ruby Taught Me About Encoding Under the Hood - Mari Imaizumi Day1の基調講演は、@ima1zumiさんによる、普段意識せずに使っている「文字」のコンピュータ上での表現と、Rubyでの扱いに関するセッションでした。文字コードの歴史的背景から最新動向まで深く掘り下げられました。 引用元: speakerdeck.com 概要 文字コードの進化 文字符号化の歴史として、のろしやモールス信号から、コンピュータ時代の ASCII、EBCDIC が紹介されました。特にEBCDICでの日本語表現の困難さ（ Shift-In/Out による 1バイト/2バイト 切り替え）の話は印象的で、現在の文字入力環境のありがたさを痛感しました。その後、世界中の文字を統一的に扱うUnicodeが誕生。「Universal」「Efficient」「Unambiguous」を目指し、UTF-8 や UTF-16 といったエンコーディング方式が普及しました。 Reline の事例から見えた課題 Rubyの REPL ライブラリ「Reline」で、特定の絵文字 🧑‍🧑‍🧒 家族 を入力して Backspace を押すとクラッシュする問題がありました。この絵文字は見た目上1文字でも、内部的には複数の Unicode コードポイント（7つ）で構成されています。Reline がこれをバイト数で処理しようとしたため問題が発生しました。ここで重要なのが、ユーザーが「1文字」と認識する単位である「書記素クラスタ (Grapheme Cluster)」です。合成文字や結合絵文字のように、見た目の文字数と内部コードポイント数が一致しないケースが存在します。Reline の問題は、この書記素クラスタを正しく認識していなかった点にありました。 Ruby における Unicode サポート Ruby は Unicode 15.1.0 仕様への準拠を進めています。Unicode標準のデータベースファイルを取り込み、内部処理に反映させています。正規表現エンジン「Onigmo」もUnicodeに対応しており、 \X （書記素クラスタ）や \p{Property} （Unicodeプロパティ）といったメタ文字が利用できます。これにより、開発者は内部表現を意識せずとも直感的な操作が可能です。書記素クラスタの分割ルール（例：GB9c）にも準拠しようとしています。今後の課題としてUnicode 16.0.0への追従や正規化対応が挙げられました。 感想 文字コードの奥深さ、支える技術、そして Ruby の対応を具体例と共に学べました。文字を入力し表現できていることが当たり前ではないこと、Unicode の複雑さに対応し、開発者が直感的に文字を扱えるようにする Ruby コミュニティの継続的な努力に感銘を受けました。今後の Unicode 標準と Ruby の進化に注目していきたいです。 Day1: Introducing Type Guard to Steep Takeshi KOMIYA さんによるセッションでは、Ruby の静的型チェッカー Steep における型ガード機能の改善と今後の展望が語られました。 引用元 drive.google.com 概要 これまでの Steep と型ガードの課題 Steep は型誤りを防ぐツールですが、従来の型ガードではRubyで多用される present? メソッドのような存在確認と型絞り込みを兼ねるパターンが機能せず、不必要な型エラーが発生し、開発体験を損なう一因となっていました。 Union Type に対する型ガードの強化 この課題に対応するため、Steep 1.10 以降で UnionType（例:  String | nil ）への型ガードが強化されました。設定記述により present? のようなメソッド呼び出しで nil でない型へ絞り込めるようになり、Ruby らしい自然なコードで型チェックの恩恵を受けられます。この機能は開発者定義のメソッドにも適用可能で、柔軟性が向上しました。 また、より直感的な型ガード宣言のため、新しいアノテーション構文  a{guard: self is AdminUser}  が紹介されました。特定の条件下で変数の型が特定の型であることを Steep に伝え、複雑な条件分岐における型情報を明確にします。 今後の展望 将来的な拡張として「Conditional Types」構想が紹介されました。これは特定条件下でのカスタム型ガード適用や返り値型の限定を可能にする機能です。複数の型情報を組み合わせる機能（例:  UserAdmin & Publish ）も関連して検討されており、より高度で精密な型チェックが実現します。 感想 Steep が開発者のフィードバックを取り入れ、より実践的に進化していると感じました。Guard アノテーションや Conditional Types など、今後の機能追加にも期待が持てます。Ruby における静的型チェックがより身近で強力なものになりつつあり、Steep の活用を検討したいと思いました。 Day2: Making TCPSocket.new “Happy” ! Misaki Shioi さんによるセッションでは、Ruby 標準ライブラリのTCP接続改善、特に TCPSocket.new への Happy Eyeballs Version 2 (HEv2) 実装の経緯と技術的挑戦が語られました。 引用元: speakerdeck.com 概要 TCPSocket.new を “Happy” にする試み TCPSocket.new への Happy Eyeballs Version 2 (HEv2, RFC8305) の実装について。HEv2はIPv4/IPv6両対応ホストへの接続を高速化する技術で、名前解決を並行し、早く応答があった方へ接続することで遅延を最小化します。Shioiさんは先行して Socket.tcp にHEv2を実装した経験を活かし、より低レイヤーの TCPSocket.new への改善に挑みました。 課題 先行実装した Socket.tcp 自体の課題（並行処理によるステートマシンの問題）に直面し、if文ベースのロジックに再実装して解決しました。この知見をもとに TCPSocket.new (C言語)へのHEv2実装に着手しましたが、RubyとCでの名前解決ライブラリの挙動差異など、新たな壁にぶつかりました。プラットフォーム間の差異吸収など、C言語レベルでの細かな調整を経てプルリクエストを完成させました。 プルリクエストのマージ後も、CI環境でのテスト失敗やユーザーからのバグ報告など、リリース直前まで予期せぬ問題への対応に追われました。これらの困難を乗り越え、この改善はRuby 3.4に無事に取り込まれました。 感想 HEv2実装の一連の取り組みが、時系列で非常に分かりやすく解説されました。 Socket.tcp の再実装から TCPSocket.new への実装、リリースまでの課題と解決策を追体験できました。実装コードの引用も多く、理解の助けになりました。ネットワーク低レイヤーの改善は Ruby エコシステム全体の品質向上に繋がる重要な取り組みであり、普段利用するTCP接続の裏側で行われているパフォーマンスと信頼性向上のための緻密な努力に感銘を受けました。 Day3: Matz Keynote RubyKaigi 2025 の最後は Matz 氏によるセッションでした。ステージのせり上がるギミックを利用して堂々と登場し、会場を驚きと笑いで包んだ Matz 氏は、現代の開発環境と Ruby の未来について語りました。 AIによる開発支援が急速に進む現代において、本来「楽しい」はずのプログラミングが、AIへの指示出し作業に終始し、人間がまるでAIの「しもべ」であるかのように勘違いしてしまう……。そんな「逆アルファシンドローム」に陥らないよう、Matz 氏は注意を促しました。Ruby の根幹にある「プログラミングを楽しむ」という精神を、技術が進化する今だからこそ、改めて胸に刻むべきだと語りました。 一方で、AIとの協調も未来の重要なテーマです。Matz氏は、将来の高度なAIとのコミュニケーションにおいて、Ruby が持つ「簡潔さ」「豊かな表現力」「高い拡張性」といった特性が、理想的なインターフェースとなり得るとしました。そして、AIがより良く学習できるよう、モダンで質の高い Ruby コードをコミュニティ全体で積極的に公開していくことの重要性を提言しました。 そして Ruby 自体の進化についても、RuboCop、IRB や Parser の進化といった開発者体験を向上させるツールの充実、YJIT/ZJIT や Deoptimization といった技術による着実なパフォーマンス向上についても触れ、Ruby がより強力で使いやすい言語へと進化し続けていることを強調しました。 また、Matz 氏は改めて Ruby の強さの源泉はコミュニティにあると述べました。多様なバックグラウンドを持つ人々を歓迎するオープンな姿勢と、コミュニティ全体で Ruby という言語を育てていく文化こそが、Rubyを特別なものにしています。 さらに、今年の12月に迎えるRubyの30周年を記念して、Ruby4.0 のリリースを予定していることを発表していました。 昨今のAIの目覚ましい発展は、エンジニアとして非常に心躍るものである一方、一抹の不安を感じさせる面もあります。しかし Matz 氏の講演は、むしろ Ruby と共に新しい未来を切り拓いていく希望を与えてくれるものでした。Ruby の「楽しさ」という原点を決して忘れず、AIを強力なパートナーとして、より創造的な開発を追求していきたいと、決意を新たにしました！ さいごに Ruby の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。 運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございます！ 来年は北海道・函館での開催を予定しているそうです。 メドレーには はこだて未来大学出身のメンバーも在籍しており、学内セミナーへの参加も積極的に行なっております。ゆかりある地での開催に向けて、今から非常に楽しみです。 私たちはこれからも Ruby コミュニティとともにさらに成長し、チャレンジし続けます！ After RubyKaigi 2025 を開催します！ https://increments.connpass.com/event/351891/ メドレーは同じくRubyKaigi スポンサー企業である Qiita社・OPTiM社 との合同開催によるアフターイベントを 5 月 14 日 に行います。 RubyKaigi の思い出や Kaigi Effect を受けて挑戦したことなど、楽しく話し合いましょう！ メドレーではこのようなイベントの開催のほかにも、Roppongi.rb など地域コミュニティや技術カンファレンスのスポンサーなどを通して、技術とコミュニティの発展を応援しています。 メドレーではエンジニアを積極採用中です！ メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 Ruby を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ 募集の一覧 https://www.medley.jp/jobs/ ※カジュアル面談ご希望の際は、<その他>にてその旨をご記載ください