メドレーの 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

はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年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/ ※カジュアル面談ご希望の際は、<その他>にてその旨をご記載ください

はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年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/ ※カジュアル面談ご希望の際は、<その他>にてその旨をご記載ください

はじめに こんにちは。人材プラットフォーム本部 第一開発グループの坂井( @Hiroshi_mars )です。 2024 年 12 月に主にバックエンドのエンジニアとしてメドレーに入社しました。 入社して日が浅いですが、この記事を通じて少しでもためになったりメドレーについて知っていただけたら嬉しいです。 今回、私は、Docker Desktop for Mac から OrbStack へ移行するプロジェクトを担当しました。以降、Docker Desktop は Docker Desktop for Mac を指します。 対象プロダクト: ジョブメドレーのサイトページ や社内オペレーターが利用するサイト、施設の方々が利用するサイトなど。 期間: 2~3 週間 OrbStack とは 公式 OrbStack とは OrbStack is the fast, light, and easy way to run Docker containers and Linux. Develop at lightspeed with our Docker Desktop alternative. (公式サイトから引用) OrbStack は、Docker コンテナおよび Linux を高速かつ軽量に、容易に実行するためのツールです。 と書かれています。 Docker Desktop の代替として注目されています。 OrbStack の特徴 Docker Desktop より高速で軽量 既存の Docker コマンドや docker-compose 系のコマンドも利用可能 Docker Desktop からの移行が容易 CPU やメモリの使用量が抑えられ、既存の Docker コマンドとの互換性も高いため、移行や運用の負担が少ない点が大きなメリットです。 OrbStack へ移行した理由 大きく二点あります。 OrbStack へ移行した理由 その 1 【OrbStack と Docker Desktop の商用利用の料金差】 OrbStack の料金は こちら Docker Desktop の料金は こちら 今まで Docker Desktop の Docker Team のプランで商用利用していました。しかし、ありがたいことに開発メンバーが増加し、管理できるアカウント数の上限を超えてしまいそうになりました。 Docker Desktop のプランを Docker Team から Docker Business に上げると 1 ユーザーあたりの月額利用料が 15 ドルから 24 ドルに増加します。 そのため、「プランのランクを一つ上に上げる」or「別のツールに移行する」という選択がありました。 「プランのランクを一つ上に上げる」のも可能ではありましたが、 OrbStack へ移行した理由 その 2 に記載されている通りどうやら移行難易度や工数コストが低そうということもあって、「別のツールに移行する」選択をとりました。 この判断はメドレーの行動原則である( Our Essentials )の中の**『日々の倹約と大胆な投資の両立』**に適っています。 無駄なコストを落とせるのなら落とし、落とした分だけ別の大胆な行動に利用する。そういった行動原則に基づいた動きでもあったかと思います。 逆に、移行による工数コストがかなり高かった場合、Docker Desktop のプランを上げる方針になっていた可能性もあります。 OrbStack へ移行した理由 その 2 【OrbStack へ移行が容易】 ブログなどの各種情報源において、OrbStack への移行手順は容易であり移行にかかる工数が低いことが報告されています。 他ブログの一例: https://qiita.com/shoki-y/items/4b8e48a525062a8ec9ad また、社内の別プロダクトで既に移行した実績がありました。 社内の別プロダクトの技術スタックは、今回の移行対象と近しいものでした。 そのため、社内の別プロダクトの移行を行なった方にヒアリングした際も移行コストが小さいことがわかりました。 移行作業に伴う環境差異やそれに伴う工数負担は大きな課題となりやすいですが、OrbStack ではそれらの負担が少ないことが社内、社外の知見調査によって見込まれたため、移行を決断するに至りました。 OrbStack への移行手順 1. OrbStack をインストール インストール方法は 2 種類あります。 Homebrew を使ったインストール brew install orbstack 2. 公式サイト から dmg 形式のファイルをダウンロードする 2. OrbStack の起動 インストール後、Finder のアプリケーションから OrbStack のアイコンを探し、クリックし起動。起動後、以下のような画面が出てきます。 Docker, Kubernetes, Linux どれを利用するのか選択します。 今回は、Docker Desktop から OrbStack に移行するので、Docker を選択します。 Docker を選択すると上記のようなトップ画面が出ます。 3. Docker Desktop から OrbStack へコンテナやイメージの情報を移行する 2 種類方法があります。 トップ画面に表示されている”Migrate from Docker Desktop”をクリックする 上部メニューから”File”->“Migrate Docker Data”をクリックする Docker Desktop 上のコンテナ、ボリューム、イメージが OrbStack に移行されます ＊2 のメニューについての画面 migrate した後、下記のようなポップアップが出ることがあります。 内容はモザイクをつけていますが、下記のようなログが出力される場合があります。 container /~: create container: [Docker] No such image: ... これは、一部のコンテナやイメージの移行に失敗していることを示しています。 今回の移行に関してはこのエラーメッセージを migrate 時に解消しなくても問題ありませんでした。理由としては、エラー対象が自身で以前作成したデータなどが migrate できなかったのみで、後ほど再度作成すればよかったためです。 4. Docker コンテキスト情報の確認と変更 migrate が完了したら、“Docker Desktop”と”OrbStack”どちらを利用して Docker Daemon にアクセスするのか確認する必要があります。 次のコマンドでコンテキストを確認します。 docker context ls 出力例: $ docker context ls NAME DESCRIPTION DOCKER ENDPOINT ERROR default Current DOCKER_HOST based configuration unix:///hogehoge orbstack * OrbStack unix:///hogehoge ”*“が今利用しているコンテキストになります “Docker Desktop” が利用されている場合は次のコマンドで OrbStack に変更します。 docker context use orbstack 出力例: % docker context use orbstack orbstack Current context is now "orbstack" 5. Docker コンテナの立ち上げ Docker コンテナを起動して、正常に移行できたことを確認します。 完全に移行が完了したら Docker Desktop を削除しても問題ないかと思います。 コンテナの起動方法は各自の利用環境に応じて手順が異なるため、本稿では詳細を割愛します。 ハマりポイントや苦労した点 少しハマったポイントや苦労した点などを記載しています。ご参考になれば幸いです。 Docker Network 周りのエラー Docker Desktop でコンテナを立ち上げて、作業していた場合、Docker Network を多かれ少なかれ利用されているかと思います。 Docker Desktop で作成していた Docker Network が存在していた場合、OrbStack で Docker Network を作成しようとすると同じ Docker Network を作成することになってしまい、ネームの被りなどが発生することがあります。 そのため、次のコマンドで Docker Network を確認します。 docker network ls 不要なネットワークが存在していた場合、次のコマンドで削除します。 docker network rm Hogehoge マルチビルド周りのエラー 先ほど記載した Docker_Network 周りのエラー と似たようなエラーになります。 Docker Desktop で作成済みのマルチビルド環境が OrbStack と競合する場合があります。その場合は既存のマルチビルド環境を削除し、OrbStack で新規にマルチビルド環境を構築することで問題を解消できます。 エラー内容 error: Error response from daemon: Conflict. The container name "multibuild" is already in use by container "container_id". You have to remove (or rename ) that container to be able to reuse that name. 次のコマンドで、新たにマルチビルドを作成して利用できます。 docker buildx rm multibuild docker buildx create --name multibuild_new_type docker buildx use multibuild_new_type コンテナとローカルのファイル差分が更新されない問題 通常であれば、Volume を設定していれば、ローカルでファイルを新たに作成したり、mv, cp 等のコマンドでファイルを移したり、ファイル内を書き換えても Docker コンテナ内のファイルも更新されるかと思います。 それが今回、Docker コンテナ内でファイルが更新されない問題が起きていました。 こちらの問題は、原因追及にかなり苦労しました。 調査の結果、以前から利用していた docker-sync が OrbStack への移行後に 正常に 動作していないことがわかりました。 docker-sync とは、Docker 環境でローカルとコンテナ間のファイル同期を高速化するためのツールです。 原因の切り分けには苦労しましたが、次の手順で特定できました。 先行して OrbStack に移行していた別部署の方と連携を取り、両者の環境の違いを聞いた中で docker-sync の利用の有無が挙げられた ファイルの更新が反映されない問題であったため、ファイル同期を最適化する docker-sync が原因ではないかと推測した docker-sync を使用しない環境で検証して問題の解消を確認した そのため、OrbStack への移行を機に docker-sync の利用をやめることで コンテナとローカルのファイル差分が更新されない問題を解決しました。 移行後の OrbStack の使用感 Docker Desktop より UI などがシンプルであり、操作が容易です。 migrates するだけで OrbStack に移行できる手軽さがよかったです。 商用利用の料金も Docker Desktop のプランをあげるより利用料が抑えられるので、良いかと思います。 まとめ OrbStack 移行を実際にやってみて、思っている以上に容易に移行できたと実感しました。 もちろん Docker Desktop も良いかと思いますが、速度や利用料などを加味して、移行の選択肢として OrbStack も入ってきそうな気がしています。 また、OrbStack を実際に使ってみてください。実際に利用することでわかることが多く出てくるかと思います。 We’re hiring メドレーでは一緒に働く仲間を大募集しています！ カジュアル面談も実施しておりますので、お話しだけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 https://www.medley.jp/jobs/ 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ https://pitta.me/matches/BtcyDvCvUZtx メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ https://pitta.me/matches/sNeEHMdSLZpB

はじめに こんにちは。人材プラットフォーム本部 第一開発グループの坂井( @Hiroshi_mars )です。 2024 年 12 月に主にバックエンドのエンジニアとしてメドレーに入社しました。 入社して日が浅いですが、この記事を通じて少しでもためになったりメドレーについて知っていただけたら嬉しいです。 今回、私は、Docker Desktop for Mac から OrbStack へ移行するプロジェクトを担当しました。以降、Docker Desktop は Docker Desktop for Mac を指します。 対象プロダクト: ジョブメドレーのサイトページ や社内オペレーターが利用するサイト、施設の方々が利用するサイトなど。 期間: 2~3 週間 OrbStack とは 公式 OrbStack とは OrbStack is the fast, light, and easy way to run Docker containers and Linux. Develop at lightspeed with our Docker Desktop alternative. (公式サイトから引用) OrbStack は、Docker コンテナおよび Linux を高速かつ軽量に、容易に実行するためのツールです。 と書かれています。 Docker Desktop の代替として注目されています。 OrbStack の特徴 Docker Desktop より高速で軽量 既存の Docker コマンドや docker-compose 系のコマンドも利用可能 Docker Desktop からの移行が容易 CPU やメモリの使用量が抑えられ、既存の Docker コマンドとの互換性も高いため、移行や運用の負担が少ない点が大きなメリットです。 OrbStack へ移行した理由 大きく二点あります。 OrbStack へ移行した理由 その 1 【OrbStack と Docker Desktop の商用利用の料金差】 OrbStack の料金は こちら Docker Desktop の料金は こちら 今まで Docker Desktop の Docker Team のプランで商用利用していました。しかし、ありがたいことに開発メンバーが増加し、管理できるアカウント数の上限を超えてしまいそうになりました。 Docker Desktop のプランを Docker Team から Docker Business に上げると 1 ユーザーあたりの月額利用料が 15 ドルから 24 ドルに増加します。 そのため、「プランのランクを一つ上に上げる」or「別のツールに移行する」という選択がありました。 「プランのランクを一つ上に上げる」のも可能ではありましたが、 OrbStack へ移行した理由 その 2 に記載されている通りどうやら移行難易度や工数コストが低そうということもあって、「別のツールに移行する」選択をとりました。 この判断はメドレーの行動原則である( Our Essentials )の中の**『日々の倹約と大胆な投資の両立』**に適っています。 無駄なコストを落とせるのなら落とし、落とした分だけ別の大胆な行動に利用する。そういった行動原則に基づいた動きでもあったかと思います。 逆に、移行による工数コストがかなり高かった場合、Docker Desktop のプランを上げる方針になっていた可能性もあります。 OrbStack へ移行した理由 その 2 【OrbStack へ移行が容易】 ブログなどの各種情報源において、OrbStack への移行手順は容易であり移行にかかる工数が低いことが報告されています。 他ブログの一例: https://qiita.com/shoki-y/items/4b8e48a525062a8ec9ad また、社内の別プロダクトで既に移行した実績がありました。 社内の別プロダクトの技術スタックは、今回の移行対象と近しいものでした。 そのため、社内の別プロダクトの移行を行なった方にヒアリングした際も移行コストが小さいことがわかりました。 移行作業に伴う環境差異やそれに伴う工数負担は大きな課題となりやすいですが、OrbStack ではそれらの負担が少ないことが社内、社外の知見調査によって見込まれたため、移行を決断するに至りました。 OrbStack への移行手順 1. OrbStack をインストール インストール方法は 2 種類あります。 Homebrew を使ったインストール brew install orbstack 2. 公式サイト から dmg 形式のファイルをダウンロードする 2. OrbStack の起動 インストール後、Finder のアプリケーションから OrbStack のアイコンを探し、クリックし起動。起動後、以下のような画面が出てきます。 Docker, Kubernetes, Linux どれを利用するのか選択します。 今回は、Docker Desktop から OrbStack に移行するので、Docker を選択します。 Docker を選択すると上記のようなトップ画面が出ます。 3. Docker Desktop から OrbStack へコンテナやイメージの情報を移行する 2 種類方法があります。 トップ画面に表示されている”Migrate from Docker Desktop”をクリックする 上部メニューから”File”->“Migrate Docker Data”をクリックする Docker Desktop 上のコンテナ、ボリューム、イメージが OrbStack に移行されます ＊2 のメニューについての画面 migrate した後、下記のようなポップアップが出ることがあります。 内容はモザイクをつけていますが、下記のようなログが出力される場合があります。 container /~: create container: [Docker] No such image: ... これは、一部のコンテナやイメージの移行に失敗していることを示しています。 今回の移行に関してはこのエラーメッセージを migrate 時に解消しなくても問題ありませんでした。理由としては、エラー対象が自身で以前作成したデータなどが migrate できなかったのみで、後ほど再度作成すればよかったためです。 4. Docker コンテキスト情報の確認と変更 migrate が完了したら、“Docker Desktop”と”OrbStack”どちらを利用して Docker Daemon にアクセスするのか確認する必要があります。 次のコマンドでコンテキストを確認します。 docker context ls 出力例: $ docker context ls NAME DESCRIPTION DOCKER ENDPOINT ERROR default Current DOCKER_HOST based configuration unix:///hogehoge orbstack * OrbStack unix:///hogehoge ”*“が今利用しているコンテキストになります “Docker Desktop” が利用されている場合は次のコマンドで OrbStack に変更します。 docker context use orbstack 出力例: % docker context use orbstack orbstack Current context is now "orbstack" 5. Docker コンテナの立ち上げ Docker コンテナを起動して、正常に移行できたことを確認します。 完全に移行が完了したら Docker Desktop を削除しても問題ないかと思います。 コンテナの起動方法は各自の利用環境に応じて手順が異なるため、本稿では詳細を割愛します。 ハマりポイントや苦労した点 少しハマったポイントや苦労した点などを記載しています。ご参考になれば幸いです。 Docker Network 周りのエラー Docker Desktop でコンテナを立ち上げて、作業していた場合、Docker Network を多かれ少なかれ利用されているかと思います。 Docker Desktop で作成していた Docker Network が存在していた場合、OrbStack で Docker Network を作成しようとすると同じ Docker Network を作成することになってしまい、ネームの被りなどが発生することがあります。 そのため、次のコマンドで Docker Network を確認します。 docker network ls 不要なネットワークが存在していた場合、次のコマンドで削除します。 docker network rm Hogehoge マルチビルド周りのエラー 先ほど記載した Docker_Network 周りのエラー と似たようなエラーになります。 Docker Desktop で作成済みのマルチビルド環境が OrbStack と競合する場合があります。その場合は既存のマルチビルド環境を削除し、OrbStack で新規にマルチビルド環境を構築することで問題を解消できます。 エラー内容 error: Error response from daemon: Conflict. The container name "multibuild" is already in use by container "container_id". You have to remove (or rename ) that container to be able to reuse that name. 次のコマンドで、新たにマルチビルドを作成して利用できます。 docker buildx rm multibuild docker buildx create --name multibuild_new_type docker buildx use multibuild_new_type コンテナとローカルのファイル差分が更新されない問題 通常であれば、Volume を設定していれば、ローカルでファイルを新たに作成したり、mv, cp 等のコマンドでファイルを移したり、ファイル内を書き換えても Docker コンテナ内のファイルも更新されるかと思います。 それが今回、Docker コンテナ内でファイルが更新されない問題が起きていました。 こちらの問題は、原因追及にかなり苦労しました。 調査の結果、以前から利用していた docker-sync が OrbStack への移行後に 正常に 動作していないことがわかりました。 docker-sync とは、Docker 環境でローカルとコンテナ間のファイル同期を高速化するためのツールです。 原因の切り分けには苦労しましたが、次の手順で特定できました。 先行して OrbStack に移行していた別部署の方と連携を取り、両者の環境の違いを聞いた中で docker-sync の利用の有無が挙げられた ファイルの更新が反映されない問題であったため、ファイル同期を最適化する docker-sync が原因ではないかと推測した docker-sync を使用しない環境で検証して問題の解消を確認した そのため、OrbStack への移行を機に docker-sync の利用をやめることで コンテナとローカルのファイル差分が更新されない問題を解決しました。 移行後の OrbStack の使用感 Docker Desktop より UI などがシンプルであり、操作が容易です。 migrates するだけで OrbStack に移行できる手軽さがよかったです。 商用利用の料金も Docker Desktop のプランをあげるより利用料が抑えられるので、良いかと思います。 まとめ OrbStack 移行を実際にやってみて、思っている以上に容易に移行できたと実感しました。 もちろん Docker Desktop も良いかと思いますが、速度や利用料などを加味して、移行の選択肢として OrbStack も入ってきそうな気がしています。 また、OrbStack を実際に使ってみてください。実際に利用することでわかることが多く出てくるかと思います。 We’re hiring メドレーでは一緒に働く仲間を大募集しています！ カジュアル面談も実施しておりますので、お話しだけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 https://www.medley.jp/jobs/ 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ https://pitta.me/matches/BtcyDvCvUZtx メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ https://pitta.me/matches/sNeEHMdSLZpB

はじめに こんにちは。人材プラットフォーム本部 第一開発グループの坂井( @Hiroshi_mars )です。 2024 年 12 月に主にバックエンドのエンジニアとしてメドレーに入社しました。 入社して日が浅いですが、この記事を通じて少しでもためになったりメドレーについて知っていただけたら嬉しいです。 今回、私は、Docker Desktop for Mac から OrbStack へ移行するプロジェクトを担当しました。以降、Docker Desktop は Docker Desktop for Mac を指します。 対象プロダクト: ジョブメドレーのサイトページ や社内オペレーターが利用するサイト、施設の方々が利用するサイトなど。 期間: 2~3 週間 OrbStack とは 公式 OrbStack とは OrbStack is the fast, light, and easy way to run Docker containers and Linux. Develop at lightspeed with our Docker Desktop alternative. (公式サイトから引用) OrbStack は、Docker コンテナおよび Linux を高速かつ軽量に、容易に実行するためのツールです。 と書かれています。 Docker Desktop の代替として注目されています。 OrbStack の特徴 Docker Desktop より高速で軽量 既存の Docker コマンドや docker-compose 系のコマンドも利用可能 Docker Desktop からの移行が容易 CPU やメモリの使用量が抑えられ、既存の Docker コマンドとの互換性も高いため、移行や運用の負担が少ない点が大きなメリットです。 OrbStack へ移行した理由 大きく二点あります。 OrbStack へ移行した理由 その 1 【OrbStack と Docker Desktop の商用利用の料金差】 OrbStack の料金は こちら Docker Desktop の料金は こちら 今まで Docker Desktop の Docker Team のプランで商用利用していました。しかし、ありがたいことに開発メンバーが増加し、管理できるアカウント数の上限を超えてしまいそうになりました。 Docker Desktop のプランを Docker Team から Docker Business に上げると 1 ユーザーあたりの月額利用料が 15 ドルから 24 ドルに増加します。 そのため、「プランのランクを一つ上に上げる」or「別のツールに移行する」という選択がありました。 「プランのランクを一つ上に上げる」のも可能ではありましたが、 OrbStack へ移行した理由 その 2 に記載されている通りどうやら移行難易度や工数コストが低そうということもあって、「別のツールに移行する」選択をとりました。 この判断はメドレーの行動原則である( Our Essentials )の中の**『日々の倹約と大胆な投資の両立』**に適っています。 無駄なコストを落とせるのなら落とし、落とした分だけ別の大胆な行動に利用する。そういった行動原則に基づいた動きでもあったかと思います。 逆に、移行による工数コストがかなり高かった場合、Docker Desktop のプランを上げる方針になっていた可能性もあります。 OrbStack へ移行した理由 その 2 【OrbStack へ移行が容易】 ブログなどの各種情報源において、OrbStack への移行手順は容易であり移行にかかる工数が低いことが報告されています。 他ブログの一例: https://qiita.com/shoki-y/items/4b8e48a525062a8ec9ad また、社内の別プロダクトで既に移行した実績がありました。 社内の別プロダクトの技術スタックは、今回の移行対象と近しいものでした。 そのため、社内の別プロダクトの移行を行なった方にヒアリングした際も移行コストが小さいことがわかりました。 移行作業に伴う環境差異やそれに伴う工数負担は大きな課題となりやすいですが、OrbStack ではそれらの負担が少ないことが社内、社外の知見調査によって見込まれたため、移行を決断するに至りました。 OrbStack への移行手順 1. OrbStack をインストール インストール方法は 2 種類あります。 Homebrew を使ったインストール brew install orbstack 2. 公式サイト から dmg 形式のファイルをダウンロードする 2. OrbStack の起動 インストール後、Finder のアプリケーションから OrbStack のアイコンを探し、クリックし起動。起動後、以下のような画面が出てきます。 Docker, Kubernetes, Linux どれを利用するのか選択します。 今回は、Docker Desktop から OrbStack に移行するので、Docker を選択します。 Docker を選択すると上記のようなトップ画面が出ます。 3. Docker Desktop から OrbStack へコンテナやイメージの情報を移行する 2 種類方法があります。 トップ画面に表示されている”Migrate from Docker Desktop”をクリックする 上部メニューから”File”->“Migrate Docker Data”をクリックする Docker Desktop 上のコンテナ、ボリューム、イメージが OrbStack に移行されます ＊2 のメニューについての画面 migrate した後、下記のようなポップアップが出ることがあります。 内容はモザイクをつけていますが、下記のようなログが出力される場合があります。 container /~: create container: [Docker] No such image: ... これは、一部のコンテナやイメージの移行に失敗していることを示しています。 今回の移行に関してはこのエラーメッセージを migrate 時に解消しなくても問題ありませんでした。理由としては、エラー対象が自身で以前作成したデータなどが migrate できなかったのみで、後ほど再度作成すればよかったためです。 4. Docker コンテキスト情報の確認と変更 migrate が完了したら、“Docker Desktop”と”OrbStack”どちらを利用して Docker Daemon にアクセスするのか確認する必要があります。 次のコマンドでコンテキストを確認します。 docker context ls 出力例: $ docker context ls NAME DESCRIPTION DOCKER ENDPOINT ERROR default Current DOCKER_HOST based configuration unix:///hogehoge orbstack * OrbStack unix:///hogehoge ”*“が今利用しているコンテキストになります “Docker Desktop” が利用されている場合は次のコマンドで OrbStack に変更します。 docker context use orbstack 出力例: % docker context use orbstack orbstack Current context is now "orbstack" 5. Docker コンテナの立ち上げ Docker コンテナを起動して、正常に移行できたことを確認します。 完全に移行が完了したら Docker Desktop を削除しても問題ないかと思います。 コンテナの起動方法は各自の利用環境に応じて手順が異なるため、本稿では詳細を割愛します。 ハマりポイントや苦労した点 少しハマったポイントや苦労した点などを記載しています。ご参考になれば幸いです。 Docker Network 周りのエラー Docker Desktop でコンテナを立ち上げて、作業していた場合、Docker Network を多かれ少なかれ利用されているかと思います。 Docker Desktop で作成していた Docker Network が存在していた場合、OrbStack で Docker Network を作成しようとすると同じ Docker Network を作成することになってしまい、ネームの被りなどが発生することがあります。 そのため、次のコマンドで Docker Network を確認します。 docker network ls 不要なネットワークが存在していた場合、次のコマンドで削除します。 docker network rm Hogehoge マルチビルド周りのエラー 先ほど記載した Docker_Network 周りのエラー と似たようなエラーになります。 Docker Desktop で作成済みのマルチビルド環境が OrbStack と競合する場合があります。その場合は既存のマルチビルド環境を削除し、OrbStack で新規にマルチビルド環境を構築することで問題を解消できます。 エラー内容 error: Error response from daemon: Conflict. The container name "multibuild" is already in use by container "container_id". You have to remove (or rename ) that container to be able to reuse that name. 次のコマンドで、新たにマルチビルドを作成して利用できます。 docker buildx rm multibuild docker buildx create --name multibuild_new_type docker buildx use multibuild_new_type コンテナとローカルのファイル差分が更新されない問題 通常であれば、Volume を設定していれば、ローカルでファイルを新たに作成したり、mv, cp 等のコマンドでファイルを移したり、ファイル内を書き換えても Docker コンテナ内のファイルも更新されるかと思います。 それが今回、Docker コンテナ内でファイルが更新されない問題が起きていました。 こちらの問題は、原因追及にかなり苦労しました。 調査の結果、以前から利用していた docker-sync が OrbStack への移行後に 正常に 動作していないことがわかりました。 docker-sync とは、Docker 環境でローカルとコンテナ間のファイル同期を高速化するためのツールです。 原因の切り分けには苦労しましたが、次の手順で特定できました。 先行して OrbStack に移行していた別部署の方と連携を取り、両者の環境の違いを聞いた中で docker-sync の利用の有無が挙げられた ファイルの更新が反映されない問題であったため、ファイル同期を最適化する docker-sync が原因ではないかと推測した docker-sync を使用しない環境で検証して問題の解消を確認した そのため、OrbStack への移行を機に docker-sync の利用をやめることで コンテナとローカルのファイル差分が更新されない問題を解決しました。 移行後の OrbStack の使用感 Docker Desktop より UI などがシンプルであり、操作が容易です。 migrates するだけで OrbStack に移行できる手軽さがよかったです。 商用利用の料金も Docker Desktop のプランをあげるより利用料が抑えられるので、良いかと思います。 まとめ OrbStack 移行を実際にやってみて、思っている以上に容易に移行できたと実感しました。 もちろん Docker Desktop も良いかと思いますが、速度や利用料などを加味して、移行の選択肢として OrbStack も入ってきそうな気がしています。 また、OrbStack を実際に使ってみてください。実際に利用することでわかることが多く出てくるかと思います。 We’re hiring メドレーでは一緒に働く仲間を大募集しています！ カジュアル面談も実施しておりますので、お話しだけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 https://www.medley.jp/jobs/ 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ https://pitta.me/matches/BtcyDvCvUZtx メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ https://pitta.me/matches/sNeEHMdSLZpB

はじめに こんにちは。人材プラットフォーム本部 第一開発グループの坂井( @Hiroshi_mars )です。 2024 年 12 月に主にバックエンドのエンジニアとしてメドレーに入社しました。 入社して日が浅いですが、この記事を通じて少しでもためになったりメドレーについて知っていただけたら嬉しいです。 今回、私は、Docker Desktop for Mac から OrbStack へ移行するプロジェクトを担当しました。以降、Docker Desktop は Docker Desktop for Mac を指します。 対象プロダクト: ジョブメドレーのサイトページ や社内オペレーターが利用するサイト、施設の方々が利用するサイトなど。 期間: 2~3 週間 OrbStack とは 公式 OrbStack とは OrbStack is the fast, light, and easy way to run Docker containers and Linux. Develop at lightspeed with our Docker Desktop alternative. (公式サイトから引用) OrbStack は、Docker コンテナおよび Linux を高速かつ軽量に、容易に実行するためのツールです。 と書かれています。 Docker Desktop の代替として注目されています。 OrbStack の特徴 Docker Desktop より高速で軽量 既存の Docker コマンドや docker-compose 系のコマンドも利用可能 Docker Desktop からの移行が容易 CPU やメモリの使用量が抑えられ、既存の Docker コマンドとの互換性も高いため、移行や運用の負担が少ない点が大きなメリットです。 OrbStack へ移行した理由 大きく二点あります。 OrbStack へ移行した理由 その 1 【OrbStack と Docker Desktop の商用利用の料金差】 OrbStack の料金は こちら Docker Desktop の料金は こちら 今まで Docker Desktop の Docker Team のプランで商用利用していました。しかし、ありがたいことに開発メンバーが増加し、管理できるアカウント数の上限を超えてしまいそうになりました。 Docker Desktop のプランを Docker Team から Docker Business に上げると 1 ユーザーあたりの月額利用料が 15 ドルから 24 ドルに増加します。 そのため、「プランのランクを一つ上に上げる」or「別のツールに移行する」という選択がありました。 「プランのランクを一つ上に上げる」のも可能ではありましたが、 OrbStack へ移行した理由 その 2 に記載されている通りどうやら移行難易度や工数コストが低そうということもあって、「別のツールに移行する」選択をとりました。 この判断はメドレーの行動原則である( Our Essentials )の中の**『日々の倹約と大胆な投資の両立』**に適っています。 無駄なコストを落とせるのなら落とし、落とした分だけ別の大胆な行動に利用する。そういった行動原則に基づいた動きでもあったかと思います。 逆に、移行による工数コストがかなり高かった場合、Docker Desktop のプランを上げる方針になっていた可能性もあります。 OrbStack へ移行した理由 その 2 【OrbStack へ移行が容易】 ブログなどの各種情報源において、OrbStack への移行手順は容易であり移行にかかる工数が低いことが報告されています。 他ブログの一例: https://qiita.com/shoki-y/items/4b8e48a525062a8ec9ad また、社内の別プロダクトで既に移行した実績がありました。 社内の別プロダクトの技術スタックは、今回の移行対象と近しいものでした。 そのため、社内の別プロダクトの移行を行なった方にヒアリングした際も移行コストが小さいことがわかりました。 移行作業に伴う環境差異やそれに伴う工数負担は大きな課題となりやすいですが、OrbStack ではそれらの負担が少ないことが社内、社外の知見調査によって見込まれたため、移行を決断するに至りました。 OrbStack への移行手順 1. OrbStack をインストール インストール方法は 2 種類あります。 Homebrew を使ったインストール brew install orbstack 2. 公式サイト から dmg 形式のファイルをダウンロードする 2. OrbStack の起動 インストール後、Finder のアプリケーションから OrbStack のアイコンを探し、クリックし起動。起動後、以下のような画面が出てきます。 Docker, Kubernetes, Linux どれを利用するのか選択します。 今回は、Docker Desktop から OrbStack に移行するので、Docker を選択します。 Docker を選択すると上記のようなトップ画面が出ます。 3. Docker Desktop から OrbStack へコンテナやイメージの情報を移行する 2 種類方法があります。 トップ画面に表示されている”Migrate from Docker Desktop”をクリックする 上部メニューから”File”->“Migrate Docker Data”をクリックする Docker Desktop 上のコンテナ、ボリューム、イメージが OrbStack に移行されます ＊2 のメニューについての画面 migrate した後、下記のようなポップアップが出ることがあります。 内容はモザイクをつけていますが、下記のようなログが出力される場合があります。 container /~: create container: [Docker] No such image: ... これは、一部のコンテナやイメージの移行に失敗していることを示しています。 今回の移行に関してはこのエラーメッセージを migrate 時に解消しなくても問題ありませんでした。理由としては、エラー対象が自身で以前作成したデータなどが migrate できなかったのみで、後ほど再度作成すればよかったためです。 4. Docker コンテキスト情報の確認と変更 migrate が完了したら、“Docker Desktop”と”OrbStack”どちらを利用して Docker Daemon にアクセスするのか確認する必要があります。 次のコマンドでコンテキストを確認します。 docker context ls 出力例: $ docker context ls NAME DESCRIPTION DOCKER ENDPOINT ERROR default Current DOCKER_HOST based configuration unix:///hogehoge orbstack * OrbStack unix:///hogehoge ”*“が今利用しているコンテキストになります “Docker Desktop” が利用されている場合は次のコマンドで OrbStack に変更します。 docker context use orbstack 出力例: % docker context use orbstack orbstack Current context is now "orbstack" 5. Docker コンテナの立ち上げ Docker コンテナを起動して、正常に移行できたことを確認します。 完全に移行が完了したら Docker Desktop を削除しても問題ないかと思います。 コンテナの起動方法は各自の利用環境に応じて手順が異なるため、本稿では詳細を割愛します。 ハマりポイントや苦労した点 少しハマったポイントや苦労した点などを記載しています。ご参考になれば幸いです。 Docker Network 周りのエラー Docker Desktop でコンテナを立ち上げて、作業していた場合、Docker Network を多かれ少なかれ利用されているかと思います。 Docker Desktop で作成していた Docker Network が存在していた場合、OrbStack で Docker Network を作成しようとすると同じ Docker Network を作成することになってしまい、ネームの被りなどが発生することがあります。 そのため、次のコマンドで Docker Network を確認します。 docker network ls 不要なネットワークが存在していた場合、次のコマンドで削除します。 docker network rm Hogehoge マルチビルド周りのエラー 先ほど記載した Docker_Network 周りのエラー と似たようなエラーになります。 Docker Desktop で作成済みのマルチビルド環境が OrbStack と競合する場合があります。その場合は既存のマルチビルド環境を削除し、OrbStack で新規にマルチビルド環境を構築することで問題を解消できます。 エラー内容 error: Error response from daemon: Conflict. The container name "multibuild" is already in use by container "container_id". You have to remove (or rename ) that container to be able to reuse that name. 次のコマンドで、新たにマルチビルドを作成して利用できます。 docker buildx rm multibuild docker buildx create --name multibuild_new_type docker buildx use multibuild_new_type コンテナとローカルのファイル差分が更新されない問題 通常であれば、Volume を設定していれば、ローカルでファイルを新たに作成したり、mv, cp 等のコマンドでファイルを移したり、ファイル内を書き換えても Docker コンテナ内のファイルも更新されるかと思います。 それが今回、Docker コンテナ内でファイルが更新されない問題が起きていました。 こちらの問題は、原因追及にかなり苦労しました。 調査の結果、以前から利用していた docker-sync が OrbStack への移行後に 正常に 動作していないことがわかりました。 docker-sync とは、Docker 環境でローカルとコンテナ間のファイル同期を高速化するためのツールです。 原因の切り分けには苦労しましたが、次の手順で特定できました。 先行して OrbStack に移行していた別部署の方と連携を取り、両者の環境の違いを聞いた中で docker-sync の利用の有無が挙げられた ファイルの更新が反映されない問題であったため、ファイル同期を最適化する docker-sync が原因ではないかと推測した docker-sync を使用しない環境で検証して問題の解消を確認した そのため、OrbStack への移行を機に docker-sync の利用をやめることで コンテナとローカルのファイル差分が更新されない問題を解決しました。 移行後の OrbStack の使用感 Docker Desktop より UI などがシンプルであり、操作が容易です。 migrates するだけで OrbStack に移行できる手軽さがよかったです。 商用利用の料金も Docker Desktop のプランをあげるより利用料が抑えられるので、良いかと思います。 まとめ OrbStack 移行を実際にやってみて、思っている以上に容易に移行できたと実感しました。 もちろん Docker Desktop も良いかと思いますが、速度や利用料などを加味して、移行の選択肢として OrbStack も入ってきそうな気がしています。 また、OrbStack を実際に使ってみてください。実際に利用することでわかることが多く出てくるかと思います。 We’re hiring メドレーでは一緒に働く仲間を大募集しています！ カジュアル面談も実施しておりますので、お話しだけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 https://www.medley.jp/jobs/ 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ https://pitta.me/matches/BtcyDvCvUZtx メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ https://pitta.me/matches/sNeEHMdSLZpB

はじめに こんにちは。人材プラットフォーム本部 第一開発グループの坂井( @Hiroshi_mars )です。 2024 年 12 月に主にバックエンドのエンジニアとしてメドレーに入社しました。 入社して日が浅いですが、この記事を通じて少しでもためになったりメドレーについて知っていただけたら嬉しいです。 今回、私は、Docker Desktop for Mac から OrbStack へ移行するプロジェクトを担当しました。以降、Docker Desktop は Docker Desktop for Mac を指します。 対象プロダクト: ジョブメドレーのサイトページ や社内オペレーターが利用するサイト、施設の方々が利用するサイトなど。 期間: 2~3 週間 OrbStack とは 公式 OrbStack とは OrbStack is the fast, light, and easy way to run Docker containers and Linux. Develop at lightspeed with our Docker Desktop alternative. (公式サイトから引用) OrbStack は、Docker コンテナおよび Linux を高速かつ軽量に、容易に実行するためのツールです。 と書かれています。 Docker Desktop の代替として注目されています。 OrbStack の特徴 Docker Desktop より高速で軽量 既存の Docker コマンドや docker-compose 系のコマンドも利用可能 Docker Desktop からの移行が容易 CPU やメモリの使用量が抑えられ、既存の Docker コマンドとの互換性も高いため、移行や運用の負担が少ない点が大きなメリットです。 OrbStack へ移行した理由 大きく二点あります。 OrbStack へ移行した理由 その 1 【OrbStack と Docker Desktop の商用利用の料金差】 OrbStack の料金は こちら Docker Desktop の料金は こちら 今まで Docker Desktop の Docker Team のプランで商用利用していました。しかし、ありがたいことに開発メンバーが増加し、管理できるアカウント数の上限を超えてしまいそうになりました。 Docker Desktop のプランを Docker Team から Docker Business に上げると 1 ユーザーあたりの月額利用料が 15 ドルから 24 ドルに増加します。 そのため、「プランのランクを一つ上に上げる」or「別のツールに移行する」という選択がありました。 「プランのランクを一つ上に上げる」のも可能ではありましたが、 OrbStack へ移行した理由 その 2 に記載されている通りどうやら移行難易度や工数コストが低そうということもあって、「別のツールに移行する」選択をとりました。 この判断はメドレーの行動原則である( Our Essentials )の中の**『日々の倹約と大胆な投資の両立』**に適っています。 無駄なコストを落とせるのなら落とし、落とした分だけ別の大胆な行動に利用する。そういった行動原則に基づいた動きでもあったかと思います。 逆に、移行による工数コストがかなり高かった場合、Docker Desktop のプランを上げる方針になっていた可能性もあります。 OrbStack へ移行した理由 その 2 【OrbStack へ移行が容易】 ブログなどの各種情報源において、OrbStack への移行手順は容易であり移行にかかる工数が低いことが報告されています。 他ブログの一例: https://qiita.com/shoki-y/items/4b8e48a525062a8ec9ad また、社内の別プロダクトで既に移行した実績がありました。 社内の別プロダクトの技術スタックは、今回の移行対象と近しいものでした。 そのため、社内の別プロダクトの移行を行なった方にヒアリングした際も移行コストが小さいことがわかりました。 移行作業に伴う環境差異やそれに伴う工数負担は大きな課題となりやすいですが、OrbStack ではそれらの負担が少ないことが社内、社外の知見調査によって見込まれたため、移行を決断するに至りました。 OrbStack への移行手順 1. OrbStack をインストール インストール方法は 2 種類あります。 Homebrew を使ったインストール brew install orbstack 2. 公式サイト から dmg 形式のファイルをダウンロードする 2. OrbStack の起動 インストール後、Finder のアプリケーションから OrbStack のアイコンを探し、クリックし起動。起動後、以下のような画面が出てきます。 Docker, Kubernetes, Linux どれを利用するのか選択します。 今回は、Docker Desktop から OrbStack に移行するので、Docker を選択します。 Docker を選択すると上記のようなトップ画面が出ます。 3. Docker Desktop から OrbStack へコンテナやイメージの情報を移行する 2 種類方法があります。 トップ画面に表示されている”Migrate from Docker Desktop”をクリックする 上部メニューから”File”->“Migrate Docker Data”をクリックする Docker Desktop 上のコンテナ、ボリューム、イメージが OrbStack に移行されます ＊2 のメニューについての画面 migrate した後、下記のようなポップアップが出ることがあります。 内容はモザイクをつけていますが、下記のようなログが出力される場合があります。 container /~: create container: [Docker] No such image: ... これは、一部のコンテナやイメージの移行に失敗していることを示しています。 今回の移行に関してはこのエラーメッセージを migrate 時に解消しなくても問題ありませんでした。理由としては、エラー対象が自身で以前作成したデータなどが migrate できなかったのみで、後ほど再度作成すればよかったためです。 4. Docker コンテキスト情報の確認と変更 migrate が完了したら、“Docker Desktop”と”OrbStack”どちらを利用して Docker Daemon にアクセスするのか確認する必要があります。 次のコマンドでコンテキストを確認します。 docker context ls 出力例: $ docker context ls NAME DESCRIPTION DOCKER ENDPOINT ERROR default Current DOCKER_HOST based configuration unix:///hogehoge orbstack * OrbStack unix:///hogehoge ”*“が今利用しているコンテキストになります “Docker Desktop” が利用されている場合は次のコマンドで OrbStack に変更します。 docker context use orbstack 出力例: % docker context use orbstack orbstack Current context is now "orbstack" 5. Docker コンテナの立ち上げ Docker コンテナを起動して、正常に移行できたことを確認します。 完全に移行が完了したら Docker Desktop を削除しても問題ないかと思います。 コンテナの起動方法は各自の利用環境に応じて手順が異なるため、本稿では詳細を割愛します。 ハマりポイントや苦労した点 少しハマったポイントや苦労した点などを記載しています。ご参考になれば幸いです。 Docker Network 周りのエラー Docker Desktop でコンテナを立ち上げて、作業していた場合、Docker Network を多かれ少なかれ利用されているかと思います。 Docker Desktop で作成していた Docker Network が存在していた場合、OrbStack で Docker Network を作成しようとすると同じ Docker Network を作成することになってしまい、ネームの被りなどが発生することがあります。 そのため、次のコマンドで Docker Network を確認します。 docker network ls 不要なネットワークが存在していた場合、次のコマンドで削除します。 docker network rm Hogehoge マルチビルド周りのエラー 先ほど記載した Docker_Network 周りのエラー と似たようなエラーになります。 Docker Desktop で作成済みのマルチビルド環境が OrbStack と競合する場合があります。その場合は既存のマルチビルド環境を削除し、OrbStack で新規にマルチビルド環境を構築することで問題を解消できます。 エラー内容 error: Error response from daemon: Conflict. The container name "multibuild" is already in use by container "container_id". You have to remove (or rename ) that container to be able to reuse that name. 次のコマンドで、新たにマルチビルドを作成して利用できます。 docker buildx rm multibuild docker buildx create --name multibuild_new_type docker buildx use multibuild_new_type コンテナとローカルのファイル差分が更新されない問題 通常であれば、Volume を設定していれば、ローカルでファイルを新たに作成したり、mv, cp 等のコマンドでファイルを移したり、ファイル内を書き換えても Docker コンテナ内のファイルも更新されるかと思います。 それが今回、Docker コンテナ内でファイルが更新されない問題が起きていました。 こちらの問題は、原因追及にかなり苦労しました。 調査の結果、以前から利用していた docker-sync が OrbStack への移行後に 正常に 動作していないことがわかりました。 docker-sync とは、Docker 環境でローカルとコンテナ間のファイル同期を高速化するためのツールです。 原因の切り分けには苦労しましたが、次の手順で特定できました。 先行して OrbStack に移行していた別部署の方と連携を取り、両者の環境の違いを聞いた中で docker-sync の利用の有無が挙げられた ファイルの更新が反映されない問題であったため、ファイル同期を最適化する docker-sync が原因ではないかと推測した docker-sync を使用しない環境で検証して問題の解消を確認した そのため、OrbStack への移行を機に docker-sync の利用をやめることで コンテナとローカルのファイル差分が更新されない問題を解決しました。 移行後の OrbStack の使用感 Docker Desktop より UI などがシンプルであり、操作が容易です。 migrates するだけで OrbStack に移行できる手軽さがよかったです。 商用利用の料金も Docker Desktop のプランをあげるより利用料が抑えられるので、良いかと思います。 まとめ OrbStack 移行を実際にやってみて、思っている以上に容易に移行できたと実感しました。 もちろん Docker Desktop も良いかと思いますが、速度や利用料などを加味して、移行の選択肢として OrbStack も入ってきそうな気がしています。 また、OrbStack を実際に使ってみてください。実際に利用することでわかることが多く出てくるかと思います。 We’re hiring メドレーでは一緒に働く仲間を大募集しています！ カジュアル面談も実施しておりますので、お話しだけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 https://www.medley.jp/jobs/ 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ https://pitta.me/matches/BtcyDvCvUZtx メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ https://pitta.me/matches/sNeEHMdSLZpB

はじめに こんにちは。人材プラットフォーム本部 第一開発グループの坂井( @Hiroshi_mars )です。 2024 年 12 月に主にバックエンドのエンジニアとしてメドレーに入社しました。 入社して日が浅いですが、この記事を通じて少しでもためになったりメドレーについて知っていただけたら嬉しいです。 今回、私は、Docker Desktop for Mac から OrbStack へ移行するプロジェクトを担当しました。以降、Docker Desktop は Docker Desktop for Mac を指します。 対象プロダクト: ジョブメドレーのサイトページ や社内オペレーターが利用するサイト、施設の方々が利用するサイトなど。 期間: 2~3 週間 OrbStack とは 公式 OrbStack とは OrbStack is the fast, light, and easy way to run Docker containers and Linux. Develop at lightspeed with our Docker Desktop alternative. (公式サイトから引用) OrbStack は、Docker コンテナおよび Linux を高速かつ軽量に、容易に実行するためのツールです。 と書かれています。 Docker Desktop の代替として注目されています。 OrbStack の特徴 Docker Desktop より高速で軽量 既存の Docker コマンドや docker-compose 系のコマンドも利用可能 Docker Desktop からの移行が容易 CPU やメモリの使用量が抑えられ、既存の Docker コマンドとの互換性も高いため、移行や運用の負担が少ない点が大きなメリットです。 OrbStack へ移行した理由 大きく二点あります。 OrbStack へ移行した理由 その 1 【OrbStack と Docker Desktop の商用利用の料金差】 OrbStack の料金は こちら Docker Desktop の料金は こちら 今まで Docker Desktop の Docker Team のプランで商用利用していました。しかし、ありがたいことに開発メンバーが増加し、管理できるアカウント数の上限を超えてしまいそうになりました。 Docker Desktop のプランを Docker Team から Docker Business に上げると 1 ユーザーあたりの月額利用料が 15 ドルから 24 ドルに増加します。 そのため、「プランのランクを一つ上に上げる」or「別のツールに移行する」という選択がありました。 「プランのランクを一つ上に上げる」のも可能ではありましたが、 OrbStack へ移行した理由 その 2 に記載されている通りどうやら移行難易度や工数コストが低そうということもあって、「別のツールに移行する」選択をとりました。 この判断はメドレーの行動原則である( Our Essentials )の中の**『日々の倹約と大胆な投資の両立』**に適っています。 無駄なコストを落とせるのなら落とし、落とした分だけ別の大胆な行動に利用する。そういった行動原則に基づいた動きでもあったかと思います。 逆に、移行による工数コストがかなり高かった場合、Docker Desktop のプランを上げる方針になっていた可能性もあります。 OrbStack へ移行した理由 その 2 【OrbStack へ移行が容易】 ブログなどの各種情報源において、OrbStack への移行手順は容易であり移行にかかる工数が低いことが報告されています。 他ブログの一例: https://qiita.com/shoki-y/items/4b8e48a525062a8ec9ad また、社内の別プロダクトで既に移行した実績がありました。 社内の別プロダクトの技術スタックは、今回の移行対象と近しいものでした。 そのため、社内の別プロダクトの移行を行なった方にヒアリングした際も移行コストが小さいことがわかりました。 移行作業に伴う環境差異やそれに伴う工数負担は大きな課題となりやすいですが、OrbStack ではそれらの負担が少ないことが社内、社外の知見調査によって見込まれたため、移行を決断するに至りました。 OrbStack への移行手順 1. OrbStack をインストール インストール方法は 2 種類あります。 Homebrew を使ったインストール brew install orbstack 2. 公式サイト から dmg 形式のファイルをダウンロードする 2. OrbStack の起動 インストール後、Finder のアプリケーションから OrbStack のアイコンを探し、クリックし起動。起動後、以下のような画面が出てきます。 Docker, Kubernetes, Linux どれを利用するのか選択します。 今回は、Docker Desktop から OrbStack に移行するので、Docker を選択します。 Docker を選択すると上記のようなトップ画面が出ます。 3. Docker Desktop から OrbStack へコンテナやイメージの情報を移行する 2 種類方法があります。 トップ画面に表示されている”Migrate from Docker Desktop”をクリックする 上部メニューから”File”->“Migrate Docker Data”をクリックする Docker Desktop 上のコンテナ、ボリューム、イメージが OrbStack に移行されます ＊2 のメニューについての画面 migrate した後、下記のようなポップアップが出ることがあります。 内容はモザイクをつけていますが、下記のようなログが出力される場合があります。 container /~: create container: [Docker] No such image: ... これは、一部のコンテナやイメージの移行に失敗していることを示しています。 今回の移行に関してはこのエラーメッセージを migrate 時に解消しなくても問題ありませんでした。理由としては、エラー対象が自身で以前作成したデータなどが migrate できなかったのみで、後ほど再度作成すればよかったためです。 4. Docker コンテキスト情報の確認と変更 migrate が完了したら、“Docker Desktop”と”OrbStack”どちらを利用して Docker Daemon にアクセスするのか確認する必要があります。 次のコマンドでコンテキストを確認します。 docker context ls 出力例: $ docker context ls NAME DESCRIPTION DOCKER ENDPOINT ERROR default Current DOCKER_HOST based configuration unix:///hogehoge orbstack * OrbStack unix:///hogehoge ”*“が今利用しているコンテキストになります “Docker Desktop” が利用されている場合は次のコマンドで OrbStack に変更します。 docker context use orbstack 出力例: % docker context use orbstack orbstack Current context is now "orbstack" 5. Docker コンテナの立ち上げ Docker コンテナを起動して、正常に移行できたことを確認します。 完全に移行が完了したら Docker Desktop を削除しても問題ないかと思います。 コンテナの起動方法は各自の利用環境に応じて手順が異なるため、本稿では詳細を割愛します。 ハマりポイントや苦労した点 少しハマったポイントや苦労した点などを記載しています。ご参考になれば幸いです。 Docker Network 周りのエラー Docker Desktop でコンテナを立ち上げて、作業していた場合、Docker Network を多かれ少なかれ利用されているかと思います。 Docker Desktop で作成していた Docker Network が存在していた場合、OrbStack で Docker Network を作成しようとすると同じ Docker Network を作成することになってしまい、ネームの被りなどが発生することがあります。 そのため、次のコマンドで Docker Network を確認します。 docker network ls 不要なネットワークが存在していた場合、次のコマンドで削除します。 docker network rm Hogehoge マルチビルド周りのエラー 先ほど記載した Docker_Network 周りのエラー と似たようなエラーになります。 Docker Desktop で作成済みのマルチビルド環境が OrbStack と競合する場合があります。その場合は既存のマルチビルド環境を削除し、OrbStack で新規にマルチビルド環境を構築することで問題を解消できます。 エラー内容 error: Error response from daemon: Conflict. The container name "multibuild" is already in use by container "container_id". You have to remove (or rename ) that container to be able to reuse that name. 次のコマンドで、新たにマルチビルドを作成して利用できます。 docker buildx rm multibuild docker buildx create --name multibuild_new_type docker buildx use multibuild_new_type コンテナとローカルのファイル差分が更新されない問題 通常であれば、Volume を設定していれば、ローカルでファイルを新たに作成したり、mv, cp 等のコマンドでファイルを移したり、ファイル内を書き換えても Docker コンテナ内のファイルも更新されるかと思います。 それが今回、Docker コンテナ内でファイルが更新されない問題が起きていました。 こちらの問題は、原因追及にかなり苦労しました。 調査の結果、以前から利用していた docker-sync が OrbStack への移行後に 正常に 動作していないことがわかりました。 docker-sync とは、Docker 環境でローカルとコンテナ間のファイル同期を高速化するためのツールです。 原因の切り分けには苦労しましたが、次の手順で特定できました。 先行して OrbStack に移行していた別部署の方と連携を取り、両者の環境の違いを聞いた中で docker-sync の利用の有無が挙げられた ファイルの更新が反映されない問題であったため、ファイル同期を最適化する docker-sync が原因ではないかと推測した docker-sync を使用しない環境で検証して問題の解消を確認した そのため、OrbStack への移行を機に docker-sync の利用をやめることで コンテナとローカルのファイル差分が更新されない問題を解決しました。 移行後の OrbStack の使用感 Docker Desktop より UI などがシンプルであり、操作が容易です。 migrates するだけで OrbStack に移行できる手軽さがよかったです。 商用利用の料金も Docker Desktop のプランをあげるより利用料が抑えられるので、良いかと思います。 まとめ OrbStack 移行を実際にやってみて、思っている以上に容易に移行できたと実感しました。 もちろん Docker Desktop も良いかと思いますが、速度や利用料などを加味して、移行の選択肢として OrbStack も入ってきそうな気がしています。 また、OrbStack を実際に使ってみてください。実際に利用することでわかることが多く出てくるかと思います。 We’re hiring メドレーでは一緒に働く仲間を大募集しています！ カジュアル面談も実施しておりますので、お話しだけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 https://www.medley.jp/jobs/ 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ https://pitta.me/matches/BtcyDvCvUZtx メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ https://pitta.me/matches/sNeEHMdSLZpB

はじめに こんにちは。人材プラットフォーム本部 第一開発グループの坂井( @Hiroshi_mars )です。 2024 年 12 月に主にバックエンドのエンジニアとしてメドレーに入社しました。 入社して日が浅いですが、この記事を通じて少しでもためになったりメドレーについて知っていただけたら嬉しいです。 今回、私は、Docker Desktop for Mac から OrbStack へ移行するプロジェクトを担当しました。以降、Docker Desktop は Docker Desktop for Mac を指します。 対象プロダクト: ジョブメドレーのサイトページ や社内オペレーターが利用するサイト、施設の方々が利用するサイトなど。 期間: 2~3 週間 OrbStack とは 公式 OrbStack とは OrbStack is the fast, light, and easy way to run Docker containers and Linux. Develop at lightspeed with our Docker Desktop alternative. (公式サイトから引用) OrbStack は、Docker コンテナおよび Linux を高速かつ軽量に、容易に実行するためのツールです。 と書かれています。 Docker Desktop の代替として注目されています。 OrbStack の特徴 Docker Desktop より高速で軽量 既存の Docker コマンドや docker-compose 系のコマンドも利用可能 Docker Desktop からの移行が容易 CPU やメモリの使用量が抑えられ、既存の Docker コマンドとの互換性も高いため、移行や運用の負担が少ない点が大きなメリットです。 OrbStack へ移行した理由 大きく二点あります。 OrbStack へ移行した理由 その 1 【OrbStack と Docker Desktop の商用利用の料金差】 OrbStack の料金は こちら Docker Desktop の料金は こちら 今まで Docker Desktop の Docker Team のプランで商用利用していました。しかし、ありがたいことに開発メンバーが増加し、管理できるアカウント数の上限を超えてしまいそうになりました。 Docker Desktop のプランを Docker Team から Docker Business に上げると 1 ユーザーあたりの月額利用料が 15 ドルから 24 ドルに増加します。 そのため、「プランのランクを一つ上に上げる」or「別のツールに移行する」という選択がありました。 「プランのランクを一つ上に上げる」のも可能ではありましたが、 OrbStack へ移行した理由 その 2 に記載されている通りどうやら移行難易度や工数コストが低そうということもあって、「別のツールに移行する」選択をとりました。 この判断はメドレーの行動原則である( Our Essentials )の中の**『日々の倹約と大胆な投資の両立』**に適っています。 無駄なコストを落とせるのなら落とし、落とした分だけ別の大胆な行動に利用する。そういった行動原則に基づいた動きでもあったかと思います。 逆に、移行による工数コストがかなり高かった場合、Docker Desktop のプランを上げる方針になっていた可能性もあります。 OrbStack へ移行した理由 その 2 【OrbStack へ移行が容易】 ブログなどの各種情報源において、OrbStack への移行手順は容易であり移行にかかる工数が低いことが報告されています。 他ブログの一例: https://qiita.com/shoki-y/items/4b8e48a525062a8ec9ad また、社内の別プロダクトで既に移行した実績がありました。 社内の別プロダクトの技術スタックは、今回の移行対象と近しいものでした。 そのため、社内の別プロダクトの移行を行なった方にヒアリングした際も移行コストが小さいことがわかりました。 移行作業に伴う環境差異やそれに伴う工数負担は大きな課題となりやすいですが、OrbStack ではそれらの負担が少ないことが社内、社外の知見調査によって見込まれたため、移行を決断するに至りました。 OrbStack への移行手順 1. OrbStack をインストール インストール方法は 2 種類あります。 Homebrew を使ったインストール brew install orbstack 2. 公式サイト から dmg 形式のファイルをダウンロードする 2. OrbStack の起動 インストール後、Finder のアプリケーションから OrbStack のアイコンを探し、クリックし起動。起動後、以下のような画面が出てきます。 Docker, Kubernetes, Linux どれを利用するのか選択します。 今回は、Docker Desktop から OrbStack に移行するので、Docker を選択します。 Docker を選択すると上記のようなトップ画面が出ます。 3. Docker Desktop から OrbStack へコンテナやイメージの情報を移行する 2 種類方法があります。 トップ画面に表示されている”Migrate from Docker Desktop”をクリックする 上部メニューから”File”->“Migrate Docker Data”をクリックする Docker Desktop 上のコンテナ、ボリューム、イメージが OrbStack に移行されます ＊2 のメニューについての画面 migrate した後、下記のようなポップアップが出ることがあります。 内容はモザイクをつけていますが、下記のようなログが出力される場合があります。 container /~: create container: [Docker] No such image: ... これは、一部のコンテナやイメージの移行に失敗していることを示しています。 今回の移行に関してはこのエラーメッセージを migrate 時に解消しなくても問題ありませんでした。理由としては、エラー対象が自身で以前作成したデータなどが migrate できなかったのみで、後ほど再度作成すればよかったためです。 4. Docker コンテキスト情報の確認と変更 migrate が完了したら、“Docker Desktop”と”OrbStack”どちらを利用して Docker Daemon にアクセスするのか確認する必要があります。 次のコマンドでコンテキストを確認します。 docker context ls 出力例: $ docker context ls NAME DESCRIPTION DOCKER ENDPOINT ERROR default Current DOCKER_HOST based configuration unix:///hogehoge orbstack * OrbStack unix:///hogehoge ”*“が今利用しているコンテキストになります “Docker Desktop” が利用されている場合は次のコマンドで OrbStack に変更します。 docker context use orbstack 出力例: % docker context use orbstack orbstack Current context is now "orbstack" 5. Docker コンテナの立ち上げ Docker コンテナを起動して、正常に移行できたことを確認します。 完全に移行が完了したら Docker Desktop を削除しても問題ないかと思います。 コンテナの起動方法は各自の利用環境に応じて手順が異なるため、本稿では詳細を割愛します。 ハマりポイントや苦労した点 少しハマったポイントや苦労した点などを記載しています。ご参考になれば幸いです。 Docker Network 周りのエラー Docker Desktop でコンテナを立ち上げて、作業していた場合、Docker Network を多かれ少なかれ利用されているかと思います。 Docker Desktop で作成していた Docker Network が存在していた場合、OrbStack で Docker Network を作成しようとすると同じ Docker Network を作成することになってしまい、ネームの被りなどが発生することがあります。 そのため、次のコマンドで Docker Network を確認します。 docker network ls 不要なネットワークが存在していた場合、次のコマンドで削除します。 docker network rm Hogehoge マルチビルド周りのエラー 先ほど記載した Docker_Network 周りのエラー と似たようなエラーになります。 Docker Desktop で作成済みのマルチビルド環境が OrbStack と競合する場合があります。その場合は既存のマルチビルド環境を削除し、OrbStack で新規にマルチビルド環境を構築することで問題を解消できます。 エラー内容 error: Error response from daemon: Conflict. The container name "multibuild" is already in use by container "container_id". You have to remove (or rename ) that container to be able to reuse that name. 次のコマンドで、新たにマルチビルドを作成して利用できます。 docker buildx rm multibuild docker buildx create --name multibuild_new_type docker buildx use multibuild_new_type コンテナとローカルのファイル差分が更新されない問題 通常であれば、Volume を設定していれば、ローカルでファイルを新たに作成したり、mv, cp 等のコマンドでファイルを移したり、ファイル内を書き換えても Docker コンテナ内のファイルも更新されるかと思います。 それが今回、Docker コンテナ内でファイルが更新されない問題が起きていました。 こちらの問題は、原因追及にかなり苦労しました。 調査の結果、以前から利用していた docker-sync が OrbStack への移行後に 正常に 動作していないことがわかりました。 docker-sync とは、Docker 環境でローカルとコンテナ間のファイル同期を高速化するためのツールです。 原因の切り分けには苦労しましたが、次の手順で特定できました。 先行して OrbStack に移行していた別部署の方と連携を取り、両者の環境の違いを聞いた中で docker-sync の利用の有無が挙げられた ファイルの更新が反映されない問題であったため、ファイル同期を最適化する docker-sync が原因ではないかと推測した docker-sync を使用しない環境で検証して問題の解消を確認した そのため、OrbStack への移行を機に docker-sync の利用をやめることで コンテナとローカルのファイル差分が更新されない問題を解決しました。 移行後の OrbStack の使用感 Docker Desktop より UI などがシンプルであり、操作が容易です。 migrates するだけで OrbStack に移行できる手軽さがよかったです。 商用利用の料金も Docker Desktop のプランをあげるより利用料が抑えられるので、良いかと思います。 まとめ OrbStack 移行を実際にやってみて、思っている以上に容易に移行できたと実感しました。 もちろん Docker Desktop も良いかと思いますが、速度や利用料などを加味して、移行の選択肢として OrbStack も入ってきそうな気がしています。 また、OrbStack を実際に使ってみてください。実際に利用することでわかることが多く出てくるかと思います。 We’re hiring メドレーでは一緒に働く仲間を大募集しています！ カジュアル面談も実施しておりますので、お話しだけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 https://www.medley.jp/jobs/ 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ https://pitta.me/matches/BtcyDvCvUZtx メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ https://pitta.me/matches/sNeEHMdSLZpB