はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年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

はじめに こんにちは。人材プラットフォーム本部 第一開発グループの坂井( @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

こんにちは、 Jobley でエンジニアをしている新居です。 メドレーでは 2022 年 7 月から現在まで約 2 年半、テックブログをひと月に 1 記事以上のリズムで公開し続けてきました。 この記事では企業のテックブログを一定のリズムで継続運営する方法を、メドレーの事例に沿って紹介します。テックブログを継続運営することにお困りの方の手助けになれば幸いです。 メドレーのテックブログのトップページ テックブログ運営にまつわる課題 テックブログ運営で最も難しいことは、継続的に記事を執筆し公開し続けることだと思います。 過去を振り返ると、今回紹介する方法をとる前も、コンスタントに記事を公開していました。しかし、記事を安定供給できる体制ではありませんでした。 具体的には、社内勉強会で発表した内容をテックブログにも書いてもらう運用をしていた時期があり、勉強会の準備とテックブログの執筆の両方を業務と並行して行うことは、執筆者にとって相当な負荷となっていました。執筆者の業務が忙しくなり、公開が滞るときもありました。 もちろん有志で執筆してもらうケースも多々ありましたが、このような負荷の高いルールに頼る運営は苦しく、長く続きませんでした。 それでもメドレーでは、採用活動の一環として社外のエンジニアやデザイナー、プロダクト開発に関わる方々にメドレーのことを知っていただきたいという目的があり、どうにかテックブログを継続できる方法を模索していました。 テックブログを継続運営するための取り組み ここからは、上記の課題を改善し、メドレーで約 2 年半継続してきたテックブログ運営の方法を紹介します。 メドレーでは、テックブログ運営委員会を設立し、組織的に運営するというアプローチをとっています。 具体的にどのように運営しているのか、以下の順に紹介していきます。 運営委員会のメンバー構成 運営委員会の活動 執筆推進の流れ 運営委員会の KPI 大切にしていること 運営委員会のメンバー構成 まずはメンバー構成についてです。 リーダー（必須） テックブログや運営体制のビジョンを示すのが主な役目 **会社のブランディング戦略や採用強化中の職種・ポジションを理解し、公開する記事の方向性や品質をコントロールする必要があるため、**会社の意思決定者（ CTO やマネージャー陣、また採用チームなど）と密に連携を取れる人が良い コーディネーター（必須） 記事執筆推進や定例のファシリテーション、議事録の共有が主な役目 記事ネタの収集や執筆依頼を円滑に進行するため、各事業からコーディネーターを選出することがポイント メドレーでは人材プラットフォーム事業と医療プラットフォーム事業の 2 事業から、それぞれ 1 名ずつエンジニアを選出している アドバイザー（任意） 記事ネタの提案や運営体制の改善などが主な役目 採用活動に対する解像度が高い人や会社全体を広く見ている人に協力してもらうと記事ネタの収集力が高まるため、適切に巻き込んでいくと良い メドレーでは採用チームの人や CTO 室所属の人にアドバイザーとして参加してもらっている 現在メドレーではリーダー 1 名、コーディネーター 2 名、アドバイザー 3 名の計 6 名で運営委員会を構成しています。各メンバーは運営委員会とは別にメインの業務を持ちながら、兼任で活動しています。 この体制により、組織全体を縦と横に幅広くカバーでき、テックブログの運営を効率的に進めることができています。 特にコーディネーターについては、各事業から最低 1 名を選出することで、それぞれの事業内で行われた施策や活動を把握しやすくなり、組織規模の拡大にも対応しやすくなります。 継続的な運営を実現するためには、業務の負担が特定の事業に偏らないような体制を整えることが大切です。 チームで協力して活動することで、個人に依存しない仕組みも築くことができ、突発的な問題や課題が発生しても、メンバー全員で協力して解決できます。 運営委員会の活動 続いて、運営委員会の中でやってることについてです。定例、振り返り、執筆推進が主になります。 定例 隔週で開催 アジェンダは前回決めたネクストアクションの状況共有、執筆状況の共有、次月以降の記事案の検討、その他議論共有 ここでのポイントとして、スケジュールを逆算して次の記事案を必ず決めることが超重要（決まらないまま終わらない） 例えば、記事を来月の最終営業日に公開する場合、遅くとも今月の中旬には記事案が確定し執筆者への合意もとれてる状態になってる必要があるので、スケジュールを逆算して次の記事案を必ず決める 振り返り 年 1 回で実施 今年度を振り返り、次年度の継続アクション・改善アクションを決める 直近の振り返りでは、技術系記事の数を増やしたことによる PV 数の増加や、カジュアル面談の場でテックブログの話題になることで面談がしやすくなったという成果も確認でき、継続アクションのひとつとすることを決定できた 執筆推進 以下で詳細に説明 執筆推進の流れ 続いて、執筆推進の流れを詳しく紹介します。 全体の流れは図の通りで、Step 1 から Step 3 までの流れで記事を作成していきます。 時間軸としては、Step 1 で記事の執筆依頼を終えた後、Step 2 を 3 ~ 4 週間くらいで、Step 3 を 2 週間くらいで完了させ、記事を公開するという感じで進めています。 記事執筆の流れ では、Step 1 から順に説明していきます。 Step 1 1. 記事案の選定と決定 担当: 運営委員会 定例で記事案を決定する 後述する頭出しのときに NG が出た場合に備えて候補をいくつか用意しておく 記事案のカテゴリ 技術系記事（メドレーならではの制約や困ったポイントなどがあれば、それらを明確にする） 例: トイルの削減も、情報漏洩リスクの削減も、両方手に入れる。IAM Identity Center は欲張りなんだ。 インタビュー記事 例: FY22 新卒入社エンジニアはこの 1 年でどのような成長をしてきたのかインタビューしました イベント参加記事 例: pmconf 2024 にゴールドスポンサーとして協賛しました！ etc 2. 記事案の頭出し 担当: コーディネーター 執筆完了後に NG になるのを防ぐため、先に CTO へ頭出しを行う 定例の議事録共有と合わせる形で、来月はこの記事で進める予定であることを共有する 3. 執筆の事前依頼 担当: コーディネーター 突然執筆を依頼して驚かれないように、執筆を正式依頼する前に執筆者に依頼の頭出しをしておく 4. 執筆の正式依頼 担当: コーディネーター 執筆は業務と同じ扱いなので、Slack のパブリックなチャンネルで、メンションに CTO や執筆者の上長など関係者を含み、執筆を正式に依頼する Step 2 5. スケジュールの作成 担当: コーディネーター 執筆、初稿提出、レビュー、最終レビューまでの流れをカレンダーに落とし込み、関係者に共有する 締切を明確にしつつ、通常業務の合間でも最後まで執筆作業を走りきれるよう、しっかりコーディネーターが進捗確認などしつつフォローする 6. 執筆環境の構築 担当: コーディネーター GitHub で記事を管理しているので、記事のベースファイルを作成し、Issue と Pull Request を用意する 執筆者の負担をなるべく減らし、記事執筆のみに集中してもらえるようにする 7. 記事構成案の作成 担当: 執筆者 さあ執筆しよう！という気持ちを抑え、わかりやすい記事構成となるよう、先に記事の構成案（章立てと各章の概要）を作り骨子を固める（コーディネーターが壁打ちなどサポート） 8. 執筆 担当: 執筆者 作成した記事構成案をベースにして執筆する Step 3 9. 運営レビュー 担当: 運営委員会、その他関係者（執筆者の上長など） 誤字脱字の基本的な確認に加え、記事をより良くするための提案を行う 後続の最終レビューの負担を減らすために、ここでできる限り記事を公開可能な状態まで持っていく 10. 最終レビュー 担当: 広報チーム、CTO 広報チームには広報視点で問題ないかを確認してもらい、CTO には網羅的な視点で問題ないかを最終確認してもらう ここで記事を公開可能な状態に仕上げる 11. 公開 担当: コーディネーター、執筆者、広報チーム 記事を公開し、社内外に共有する メドレーの公式 X アカウント でも発信しているので、フォローよろしくお願いします 運営委員会の KPI 続いて、運営委員会で設定している KPI についてです。 KPI はシンプルに、ひと月に最低 1 記事以上を公開すること まずは継続することが大事なので、最初はシンプルな KPI にしておくこと。もし KPI を増やすなら継続できる体制が整ってから 大切にしていること 最後に、ここまでで太字で強調したポイント以外に、運営上特に大切な 2 点を紹介します。 テックブログをやる目的を明確にする 何をやるにしても目的を定めて共通認識として持つことは大切ですが、テックブログの運営も同様に目的を明確にしてブレないようにする メドレーでは採用に繋げることを目的としており、テックブログを通じて社外の方々にメドレーことを知っていただき、解像度を上げてもらえるように努めている 目的が明確だと記事案の検討にも軸ができ、例えばプロダクトマネージャーの採用を強化してるならプロダクトマネージャー向けの記事を用意したりという動きができる 執筆は業務であることを明確にする 記事執筆において軽視されがちな印象で、執筆が業務であることが当たり前のようで当たり前になってなかったりする 通常業務との兼ね合いは必要になるが、業務であるということはイコール業務中に時間を確保して取り組むべきことである しかし、そこがふわっとしていると業務中に執筆し辛くなり、執筆がビハインドして公開が遅れる可能性が高くなる メドレーでは運営委員会の発足時に CTO から執筆は業務としてしっかり取り組んで欲しいという話があり、その文脈を含んで運営オペレーションを構築してきた背景がある 例えば執筆依頼を執筆者の上長を含めて行ったり、皆が見える場所で依頼などのコミュニケーションをとったり、公開までのスケジュールを細かく引いて開発プロジェクトと同じように進めたり おわりに メドレーが約 2 年半継続してきたテックブログ運営の方法を紹介しました。 リーダーとコーディネーターを中心とした運営委員会により、組織全体を縦と横に幅広くカバーし、開発プロジェクトと同じように関係者との調整やスケジューリングを行い、運営にも執筆者にも負担が集中しない無理のない体制を築くことにより、テックブログを継続運営しています。 会社の規模やフェーズによってはそのまま取り入れるのは難しいかもしれません。エッセンスだけを抽出して会社のスタイルや風土に合う形にカスタマイズし、ミニマムに運営を始めて推進していくのも良いかもしれません。 今回の記事が、テックブログを継続運営することにお困りの方の参考になれば幸いです。 We’re hiring メドレーでは一緒に働く仲間を大募集しています。カジュアル面談も実施しておりますので、少しでもご興味のある方はぜひご応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは、 Jobley でエンジニアをしている新居です。 メドレーでは 2022 年 7 月から現在まで約 2 年半、テックブログをひと月に 1 記事以上のリズムで公開し続けてきました。 この記事では企業のテックブログを一定のリズムで継続運営する方法を、メドレーの事例に沿って紹介します。テックブログを継続運営することにお困りの方の手助けになれば幸いです。 メドレーのテックブログのトップページ テックブログ運営にまつわる課題 テックブログ運営で最も難しいことは、継続的に記事を執筆し公開し続けることだと思います。 過去を振り返ると、今回紹介する方法をとる前も、コンスタントに記事を公開していました。しかし、記事を安定供給できる体制ではありませんでした。 具体的には、社内勉強会で発表した内容をテックブログにも書いてもらう運用をしていた時期があり、勉強会の準備とテックブログの執筆の両方を業務と並行して行うことは、執筆者にとって相当な負荷となっていました。執筆者の業務が忙しくなり、公開が滞るときもありました。 もちろん有志で執筆してもらうケースも多々ありましたが、このような負荷の高いルールに頼る運営は苦しく、長く続きませんでした。 それでもメドレーでは、採用活動の一環として社外のエンジニアやデザイナー、プロダクト開発に関わる方々にメドレーのことを知っていただきたいという目的があり、どうにかテックブログを継続できる方法を模索していました。 テックブログを継続運営するための取り組み ここからは、上記の課題を改善し、メドレーで約 2 年半継続してきたテックブログ運営の方法を紹介します。 メドレーでは、テックブログ運営委員会を設立し、組織的に運営するというアプローチをとっています。 具体的にどのように運営しているのか、以下の順に紹介していきます。 運営委員会のメンバー構成 運営委員会の活動 執筆推進の流れ 運営委員会の KPI 大切にしていること 運営委員会のメンバー構成 まずはメンバー構成についてです。 リーダー（必須） テックブログや運営体制のビジョンを示すのが主な役目 **会社のブランディング戦略や採用強化中の職種・ポジションを理解し、公開する記事の方向性や品質をコントロールする必要があるため、**会社の意思決定者（ CTO やマネージャー陣、また採用チームなど）と密に連携を取れる人が良い コーディネーター（必須） 記事執筆推進や定例のファシリテーション、議事録の共有が主な役目 記事ネタの収集や執筆依頼を円滑に進行するため、各事業からコーディネーターを選出することがポイント メドレーでは人材プラットフォーム事業と医療プラットフォーム事業の 2 事業から、それぞれ 1 名ずつエンジニアを選出している アドバイザー（任意） 記事ネタの提案や運営体制の改善などが主な役目 採用活動に対する解像度が高い人や会社全体を広く見ている人に協力してもらうと記事ネタの収集力が高まるため、適切に巻き込んでいくと良い メドレーでは採用チームの人や CTO 室所属の人にアドバイザーとして参加してもらっている 現在メドレーではリーダー 1 名、コーディネーター 2 名、アドバイザー 3 名の計 6 名で運営委員会を構成しています。各メンバーは運営委員会とは別にメインの業務を持ちながら、兼任で活動しています。 この体制により、組織全体を縦と横に幅広くカバーでき、テックブログの運営を効率的に進めることができています。 特にコーディネーターについては、各事業から最低 1 名を選出することで、それぞれの事業内で行われた施策や活動を把握しやすくなり、組織規模の拡大にも対応しやすくなります。 継続的な運営を実現するためには、業務の負担が特定の事業に偏らないような体制を整えることが大切です。 チームで協力して活動することで、個人に依存しない仕組みも築くことができ、突発的な問題や課題が発生しても、メンバー全員で協力して解決できます。 運営委員会の活動 続いて、運営委員会の中でやってることについてです。定例、振り返り、執筆推進が主になります。 定例 隔週で開催 アジェンダは前回決めたネクストアクションの状況共有、執筆状況の共有、次月以降の記事案の検討、その他議論共有 ここでのポイントとして、スケジュールを逆算して次の記事案を必ず決めることが超重要（決まらないまま終わらない） 例えば、記事を来月の最終営業日に公開する場合、遅くとも今月の中旬には記事案が確定し執筆者への合意もとれてる状態になってる必要があるので、スケジュールを逆算して次の記事案を必ず決める 振り返り 年 1 回で実施 今年度を振り返り、次年度の継続アクション・改善アクションを決める 直近の振り返りでは、技術系記事の数を増やしたことによる PV 数の増加や、カジュアル面談の場でテックブログの話題になることで面談がしやすくなったという成果も確認でき、継続アクションのひとつとすることを決定できた 執筆推進 以下で詳細に説明 執筆推進の流れ 続いて、執筆推進の流れを詳しく紹介します。 全体の流れは図の通りで、Step 1 から Step 3 までの流れで記事を作成していきます。 時間軸としては、Step 1 で記事の執筆依頼を終えた後、Step 2 を 3 ~ 4 週間くらいで、Step 3 を 2 週間くらいで完了させ、記事を公開するという感じで進めています。 記事執筆の流れ では、Step 1 から順に説明していきます。 Step 1 1. 記事案の選定と決定 担当: 運営委員会 定例で記事案を決定する 後述する頭出しのときに NG が出た場合に備えて候補をいくつか用意しておく 記事案のカテゴリ 技術系記事（メドレーならではの制約や困ったポイントなどがあれば、それらを明確にする） 例: トイルの削減も、情報漏洩リスクの削減も、両方手に入れる。IAM Identity Center は欲張りなんだ。 インタビュー記事 例: FY22 新卒入社エンジニアはこの 1 年でどのような成長をしてきたのかインタビューしました イベント参加記事 例: pmconf 2024 にゴールドスポンサーとして協賛しました！ etc 2. 記事案の頭出し 担当: コーディネーター 執筆完了後に NG になるのを防ぐため、先に CTO へ頭出しを行う 定例の議事録共有と合わせる形で、来月はこの記事で進める予定であることを共有する 3. 執筆の事前依頼 担当: コーディネーター 突然執筆を依頼して驚かれないように、執筆を正式依頼する前に執筆者に依頼の頭出しをしておく 4. 執筆の正式依頼 担当: コーディネーター 執筆は業務と同じ扱いなので、Slack のパブリックなチャンネルで、メンションに CTO や執筆者の上長など関係者を含み、執筆を正式に依頼する Step 2 5. スケジュールの作成 担当: コーディネーター 執筆、初稿提出、レビュー、最終レビューまでの流れをカレンダーに落とし込み、関係者に共有する 締切を明確にしつつ、通常業務の合間でも最後まで執筆作業を走りきれるよう、しっかりコーディネーターが進捗確認などしつつフォローする 6. 執筆環境の構築 担当: コーディネーター GitHub で記事を管理しているので、記事のベースファイルを作成し、Issue と Pull Request を用意する 執筆者の負担をなるべく減らし、記事執筆のみに集中してもらえるようにする 7. 記事構成案の作成 担当: 執筆者 さあ執筆しよう！という気持ちを抑え、わかりやすい記事構成となるよう、先に記事の構成案（章立てと各章の概要）を作り骨子を固める（コーディネーターが壁打ちなどサポート） 8. 執筆 担当: 執筆者 作成した記事構成案をベースにして執筆する Step 3 9. 運営レビュー 担当: 運営委員会、その他関係者（執筆者の上長など） 誤字脱字の基本的な確認に加え、記事をより良くするための提案を行う 後続の最終レビューの負担を減らすために、ここでできる限り記事を公開可能な状態まで持っていく 10. 最終レビュー 担当: 広報チーム、CTO 広報チームには広報視点で問題ないかを確認してもらい、CTO には網羅的な視点で問題ないかを最終確認してもらう ここで記事を公開可能な状態に仕上げる 11. 公開 担当: コーディネーター、執筆者、広報チーム 記事を公開し、社内外に共有する メドレーの公式 X アカウント でも発信しているので、フォローよろしくお願いします 運営委員会の KPI 続いて、運営委員会で設定している KPI についてです。 KPI はシンプルに、ひと月に最低 1 記事以上を公開すること まずは継続することが大事なので、最初はシンプルな KPI にしておくこと。もし KPI を増やすなら継続できる体制が整ってから 大切にしていること 最後に、ここまでで太字で強調したポイント以外に、運営上特に大切な 2 点を紹介します。 テックブログをやる目的を明確にする 何をやるにしても目的を定めて共通認識として持つことは大切ですが、テックブログの運営も同様に目的を明確にしてブレないようにする メドレーでは採用に繋げることを目的としており、テックブログを通じて社外の方々にメドレーことを知っていただき、解像度を上げてもらえるように努めている 目的が明確だと記事案の検討にも軸ができ、例えばプロダクトマネージャーの採用を強化してるならプロダクトマネージャー向けの記事を用意したりという動きができる 執筆は業務であることを明確にする 記事執筆において軽視されがちな印象で、執筆が業務であることが当たり前のようで当たり前になってなかったりする 通常業務との兼ね合いは必要になるが、業務であるということはイコール業務中に時間を確保して取り組むべきことである しかし、そこがふわっとしていると業務中に執筆し辛くなり、執筆がビハインドして公開が遅れる可能性が高くなる メドレーでは運営委員会の発足時に CTO から執筆は業務としてしっかり取り組んで欲しいという話があり、その文脈を含んで運営オペレーションを構築してきた背景がある 例えば執筆依頼を執筆者の上長を含めて行ったり、皆が見える場所で依頼などのコミュニケーションをとったり、公開までのスケジュールを細かく引いて開発プロジェクトと同じように進めたり おわりに メドレーが約 2 年半継続してきたテックブログ運営の方法を紹介しました。 リーダーとコーディネーターを中心とした運営委員会により、組織全体を縦と横に幅広くカバーし、開発プロジェクトと同じように関係者との調整やスケジューリングを行い、運営にも執筆者にも負担が集中しない無理のない体制を築くことにより、テックブログを継続運営しています。 会社の規模やフェーズによってはそのまま取り入れるのは難しいかもしれません。エッセンスだけを抽出して会社のスタイルや風土に合う形にカスタマイズし、ミニマムに運営を始めて推進していくのも良いかもしれません。 今回の記事が、テックブログを継続運営することにお困りの方の参考になれば幸いです。 We’re hiring メドレーでは一緒に働く仲間を大募集しています。カジュアル面談も実施しておりますので、少しでもご興味のある方はぜひご応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは、 Jobley でエンジニアをしている新居です。 メドレーでは 2022 年 7 月から現在まで約 2 年半、テックブログをひと月に 1 記事以上のリズムで公開し続けてきました。 この記事では企業のテックブログを一定のリズムで継続運営する方法を、メドレーの事例に沿って紹介します。テックブログを継続運営することにお困りの方の手助けになれば幸いです。 メドレーのテックブログのトップページ テックブログ運営にまつわる課題 テックブログ運営で最も難しいことは、継続的に記事を執筆し公開し続けることだと思います。 過去を振り返ると、今回紹介する方法をとる前も、コンスタントに記事を公開していました。しかし、記事を安定供給できる体制ではありませんでした。 具体的には、社内勉強会で発表した内容をテックブログにも書いてもらう運用をしていた時期があり、勉強会の準備とテックブログの執筆の両方を業務と並行して行うことは、執筆者にとって相当な負荷となっていました。執筆者の業務が忙しくなり、公開が滞るときもありました。 もちろん有志で執筆してもらうケースも多々ありましたが、このような負荷の高いルールに頼る運営は苦しく、長く続きませんでした。 それでもメドレーでは、採用活動の一環として社外のエンジニアやデザイナー、プロダクト開発に関わる方々にメドレーのことを知っていただきたいという目的があり、どうにかテックブログを継続できる方法を模索していました。 テックブログを継続運営するための取り組み ここからは、上記の課題を改善し、メドレーで約 2 年半継続してきたテックブログ運営の方法を紹介します。 メドレーでは、テックブログ運営委員会を設立し、組織的に運営するというアプローチをとっています。 具体的にどのように運営しているのか、以下の順に紹介していきます。 運営委員会のメンバー構成 運営委員会の活動 執筆推進の流れ 運営委員会の KPI 大切にしていること 運営委員会のメンバー構成 まずはメンバー構成についてです。 リーダー（必須） テックブログや運営体制のビジョンを示すのが主な役目 **会社のブランディング戦略や採用強化中の職種・ポジションを理解し、公開する記事の方向性や品質をコントロールする必要があるため、**会社の意思決定者（ CTO やマネージャー陣、また採用チームなど）と密に連携を取れる人が良い コーディネーター（必須） 記事執筆推進や定例のファシリテーション、議事録の共有が主な役目 記事ネタの収集や執筆依頼を円滑に進行するため、各事業からコーディネーターを選出することがポイント メドレーでは人材プラットフォーム事業と医療プラットフォーム事業の 2 事業から、それぞれ 1 名ずつエンジニアを選出している アドバイザー（任意） 記事ネタの提案や運営体制の改善などが主な役目 採用活動に対する解像度が高い人や会社全体を広く見ている人に協力してもらうと記事ネタの収集力が高まるため、適切に巻き込んでいくと良い メドレーでは採用チームの人や CTO 室所属の人にアドバイザーとして参加してもらっている 現在メドレーではリーダー 1 名、コーディネーター 2 名、アドバイザー 3 名の計 6 名で運営委員会を構成しています。各メンバーは運営委員会とは別にメインの業務を持ちながら、兼任で活動しています。 この体制により、組織全体を縦と横に幅広くカバーでき、テックブログの運営を効率的に進めることができています。 特にコーディネーターについては、各事業から最低 1 名を選出することで、それぞれの事業内で行われた施策や活動を把握しやすくなり、組織規模の拡大にも対応しやすくなります。 継続的な運営を実現するためには、業務の負担が特定の事業に偏らないような体制を整えることが大切です。 チームで協力して活動することで、個人に依存しない仕組みも築くことができ、突発的な問題や課題が発生しても、メンバー全員で協力して解決できます。 運営委員会の活動 続いて、運営委員会の中でやってることについてです。定例、振り返り、執筆推進が主になります。 定例 隔週で開催 アジェンダは前回決めたネクストアクションの状況共有、執筆状況の共有、次月以降の記事案の検討、その他議論共有 ここでのポイントとして、スケジュールを逆算して次の記事案を必ず決めることが超重要（決まらないまま終わらない） 例えば、記事を来月の最終営業日に公開する場合、遅くとも今月の中旬には記事案が確定し執筆者への合意もとれてる状態になってる必要があるので、スケジュールを逆算して次の記事案を必ず決める 振り返り 年 1 回で実施 今年度を振り返り、次年度の継続アクション・改善アクションを決める 直近の振り返りでは、技術系記事の数を増やしたことによる PV 数の増加や、カジュアル面談の場でテックブログの話題になることで面談がしやすくなったという成果も確認でき、継続アクションのひとつとすることを決定できた 執筆推進 以下で詳細に説明 執筆推進の流れ 続いて、執筆推進の流れを詳しく紹介します。 全体の流れは図の通りで、Step 1 から Step 3 までの流れで記事を作成していきます。 時間軸としては、Step 1 で記事の執筆依頼を終えた後、Step 2 を 3 ~ 4 週間くらいで、Step 3 を 2 週間くらいで完了させ、記事を公開するという感じで進めています。 記事執筆の流れ では、Step 1 から順に説明していきます。 Step 1 1. 記事案の選定と決定 担当: 運営委員会 定例で記事案を決定する 後述する頭出しのときに NG が出た場合に備えて候補をいくつか用意しておく 記事案のカテゴリ 技術系記事（メドレーならではの制約や困ったポイントなどがあれば、それらを明確にする） 例: トイルの削減も、情報漏洩リスクの削減も、両方手に入れる。IAM Identity Center は欲張りなんだ。 インタビュー記事 例: FY22 新卒入社エンジニアはこの 1 年でどのような成長をしてきたのかインタビューしました イベント参加記事 例: pmconf 2024 にゴールドスポンサーとして協賛しました！ etc 2. 記事案の頭出し 担当: コーディネーター 執筆完了後に NG になるのを防ぐため、先に CTO へ頭出しを行う 定例の議事録共有と合わせる形で、来月はこの記事で進める予定であることを共有する 3. 執筆の事前依頼 担当: コーディネーター 突然執筆を依頼して驚かれないように、執筆を正式依頼する前に執筆者に依頼の頭出しをしておく 4. 執筆の正式依頼 担当: コーディネーター 執筆は業務と同じ扱いなので、Slack のパブリックなチャンネルで、メンションに CTO や執筆者の上長など関係者を含み、執筆を正式に依頼する Step 2 5. スケジュールの作成 担当: コーディネーター 執筆、初稿提出、レビュー、最終レビューまでの流れをカレンダーに落とし込み、関係者に共有する 締切を明確にしつつ、通常業務の合間でも最後まで執筆作業を走りきれるよう、しっかりコーディネーターが進捗確認などしつつフォローする 6. 執筆環境の構築 担当: コーディネーター GitHub で記事を管理しているので、記事のベースファイルを作成し、Issue と Pull Request を用意する 執筆者の負担をなるべく減らし、記事執筆のみに集中してもらえるようにする 7. 記事構成案の作成 担当: 執筆者 さあ執筆しよう！という気持ちを抑え、わかりやすい記事構成となるよう、先に記事の構成案（章立てと各章の概要）を作り骨子を固める（コーディネーターが壁打ちなどサポート） 8. 執筆 担当: 執筆者 作成した記事構成案をベースにして執筆する Step 3 9. 運営レビュー 担当: 運営委員会、その他関係者（執筆者の上長など） 誤字脱字の基本的な確認に加え、記事をより良くするための提案を行う 後続の最終レビューの負担を減らすために、ここでできる限り記事を公開可能な状態まで持っていく 10. 最終レビュー 担当: 広報チーム、CTO 広報チームには広報視点で問題ないかを確認してもらい、CTO には網羅的な視点で問題ないかを最終確認してもらう ここで記事を公開可能な状態に仕上げる 11. 公開 担当: コーディネーター、執筆者、広報チーム 記事を公開し、社内外に共有する メドレーの公式 X アカウント でも発信しているので、フォローよろしくお願いします 運営委員会の KPI 続いて、運営委員会で設定している KPI についてです。 KPI はシンプルに、ひと月に最低 1 記事以上を公開すること まずは継続することが大事なので、最初はシンプルな KPI にしておくこと。もし KPI を増やすなら継続できる体制が整ってから 大切にしていること 最後に、ここまでで太字で強調したポイント以外に、運営上特に大切な 2 点を紹介します。 テックブログをやる目的を明確にする 何をやるにしても目的を定めて共通認識として持つことは大切ですが、テックブログの運営も同様に目的を明確にしてブレないようにする メドレーでは採用に繋げることを目的としており、テックブログを通じて社外の方々にメドレーことを知っていただき、解像度を上げてもらえるように努めている 目的が明確だと記事案の検討にも軸ができ、例えばプロダクトマネージャーの採用を強化してるならプロダクトマネージャー向けの記事を用意したりという動きができる 執筆は業務であることを明確にする 記事執筆において軽視されがちな印象で、執筆が業務であることが当たり前のようで当たり前になってなかったりする 通常業務との兼ね合いは必要になるが、業務であるということはイコール業務中に時間を確保して取り組むべきことである しかし、そこがふわっとしていると業務中に執筆し辛くなり、執筆がビハインドして公開が遅れる可能性が高くなる メドレーでは運営委員会の発足時に CTO から執筆は業務としてしっかり取り組んで欲しいという話があり、その文脈を含んで運営オペレーションを構築してきた背景がある 例えば執筆依頼を執筆者の上長を含めて行ったり、皆が見える場所で依頼などのコミュニケーションをとったり、公開までのスケジュールを細かく引いて開発プロジェクトと同じように進めたり おわりに メドレーが約 2 年半継続してきたテックブログ運営の方法を紹介しました。 リーダーとコーディネーターを中心とした運営委員会により、組織全体を縦と横に幅広くカバーし、開発プロジェクトと同じように関係者との調整やスケジューリングを行い、運営にも執筆者にも負担が集中しない無理のない体制を築くことにより、テックブログを継続運営しています。 会社の規模やフェーズによってはそのまま取り入れるのは難しいかもしれません。エッセンスだけを抽出して会社のスタイルや風土に合う形にカスタマイズし、ミニマムに運営を始めて推進していくのも良いかもしれません。 今回の記事が、テックブログを継続運営することにお困りの方の参考になれば幸いです。 We’re hiring メドレーでは一緒に働く仲間を大募集しています。カジュアル面談も実施しておりますので、少しでもご興味のある方はぜひご応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは、 Jobley でエンジニアをしている新居です。 メドレーでは 2022 年 7 月から現在まで約 2 年半、テックブログをひと月に 1 記事以上のリズムで公開し続けてきました。 この記事では企業のテックブログを一定のリズムで継続運営する方法を、メドレーの事例に沿って紹介します。テックブログを継続運営することにお困りの方の手助けになれば幸いです。 メドレーのテックブログのトップページ テックブログ運営にまつわる課題 テックブログ運営で最も難しいことは、継続的に記事を執筆し公開し続けることだと思います。 過去を振り返ると、今回紹介する方法をとる前も、コンスタントに記事を公開していました。しかし、記事を安定供給できる体制ではありませんでした。 具体的には、社内勉強会で発表した内容をテックブログにも書いてもらう運用をしていた時期があり、勉強会の準備とテックブログの執筆の両方を業務と並行して行うことは、執筆者にとって相当な負荷となっていました。執筆者の業務が忙しくなり、公開が滞るときもありました。 もちろん有志で執筆してもらうケースも多々ありましたが、このような負荷の高いルールに頼る運営は苦しく、長く続きませんでした。 それでもメドレーでは、採用活動の一環として社外のエンジニアやデザイナー、プロダクト開発に関わる方々にメドレーのことを知っていただきたいという目的があり、どうにかテックブログを継続できる方法を模索していました。 テックブログを継続運営するための取り組み ここからは、上記の課題を改善し、メドレーで約 2 年半継続してきたテックブログ運営の方法を紹介します。 メドレーでは、テックブログ運営委員会を設立し、組織的に運営するというアプローチをとっています。 具体的にどのように運営しているのか、以下の順に紹介していきます。 運営委員会のメンバー構成 運営委員会の活動 執筆推進の流れ 運営委員会の KPI 大切にしていること 運営委員会のメンバー構成 まずはメンバー構成についてです。 リーダー（必須） テックブログや運営体制のビジョンを示すのが主な役目 **会社のブランディング戦略や採用強化中の職種・ポジションを理解し、公開する記事の方向性や品質をコントロールする必要があるため、**会社の意思決定者（ CTO やマネージャー陣、また採用チームなど）と密に連携を取れる人が良い コーディネーター（必須） 記事執筆推進や定例のファシリテーション、議事録の共有が主な役目 記事ネタの収集や執筆依頼を円滑に進行するため、各事業からコーディネーターを選出することがポイント メドレーでは人材プラットフォーム事業と医療プラットフォーム事業の 2 事業から、それぞれ 1 名ずつエンジニアを選出している アドバイザー（任意） 記事ネタの提案や運営体制の改善などが主な役目 採用活動に対する解像度が高い人や会社全体を広く見ている人に協力してもらうと記事ネタの収集力が高まるため、適切に巻き込んでいくと良い メドレーでは採用チームの人や CTO 室所属の人にアドバイザーとして参加してもらっている 現在メドレーではリーダー 1 名、コーディネーター 2 名、アドバイザー 3 名の計 6 名で運営委員会を構成しています。各メンバーは運営委員会とは別にメインの業務を持ちながら、兼任で活動しています。 この体制により、組織全体を縦と横に幅広くカバーでき、テックブログの運営を効率的に進めることができています。 特にコーディネーターについては、各事業から最低 1 名を選出することで、それぞれの事業内で行われた施策や活動を把握しやすくなり、組織規模の拡大にも対応しやすくなります。 継続的な運営を実現するためには、業務の負担が特定の事業に偏らないような体制を整えることが大切です。 チームで協力して活動することで、個人に依存しない仕組みも築くことができ、突発的な問題や課題が発生しても、メンバー全員で協力して解決できます。 運営委員会の活動 続いて、運営委員会の中でやってることについてです。定例、振り返り、執筆推進が主になります。 定例 隔週で開催 アジェンダは前回決めたネクストアクションの状況共有、執筆状況の共有、次月以降の記事案の検討、その他議論共有 ここでのポイントとして、スケジュールを逆算して次の記事案を必ず決めることが超重要（決まらないまま終わらない） 例えば、記事を来月の最終営業日に公開する場合、遅くとも今月の中旬には記事案が確定し執筆者への合意もとれてる状態になってる必要があるので、スケジュールを逆算して次の記事案を必ず決める 振り返り 年 1 回で実施 今年度を振り返り、次年度の継続アクション・改善アクションを決める 直近の振り返りでは、技術系記事の数を増やしたことによる PV 数の増加や、カジュアル面談の場でテックブログの話題になることで面談がしやすくなったという成果も確認でき、継続アクションのひとつとすることを決定できた 執筆推進 以下で詳細に説明 執筆推進の流れ 続いて、執筆推進の流れを詳しく紹介します。 全体の流れは図の通りで、Step 1 から Step 3 までの流れで記事を作成していきます。 時間軸としては、Step 1 で記事の執筆依頼を終えた後、Step 2 を 3 ~ 4 週間くらいで、Step 3 を 2 週間くらいで完了させ、記事を公開するという感じで進めています。 記事執筆の流れ では、Step 1 から順に説明していきます。 Step 1 1. 記事案の選定と決定 担当: 運営委員会 定例で記事案を決定する 後述する頭出しのときに NG が出た場合に備えて候補をいくつか用意しておく 記事案のカテゴリ 技術系記事（メドレーならではの制約や困ったポイントなどがあれば、それらを明確にする） 例: トイルの削減も、情報漏洩リスクの削減も、両方手に入れる。IAM Identity Center は欲張りなんだ。 インタビュー記事 例: FY22 新卒入社エンジニアはこの 1 年でどのような成長をしてきたのかインタビューしました イベント参加記事 例: pmconf 2024 にゴールドスポンサーとして協賛しました！ etc 2. 記事案の頭出し 担当: コーディネーター 執筆完了後に NG になるのを防ぐため、先に CTO へ頭出しを行う 定例の議事録共有と合わせる形で、来月はこの記事で進める予定であることを共有する 3. 執筆の事前依頼 担当: コーディネーター 突然執筆を依頼して驚かれないように、執筆を正式依頼する前に執筆者に依頼の頭出しをしておく 4. 執筆の正式依頼 担当: コーディネーター 執筆は業務と同じ扱いなので、Slack のパブリックなチャンネルで、メンションに CTO や執筆者の上長など関係者を含み、執筆を正式に依頼する Step 2 5. スケジュールの作成 担当: コーディネーター 執筆、初稿提出、レビュー、最終レビューまでの流れをカレンダーに落とし込み、関係者に共有する 締切を明確にしつつ、通常業務の合間でも最後まで執筆作業を走りきれるよう、しっかりコーディネーターが進捗確認などしつつフォローする 6. 執筆環境の構築 担当: コーディネーター GitHub で記事を管理しているので、記事のベースファイルを作成し、Issue と Pull Request を用意する 執筆者の負担をなるべく減らし、記事執筆のみに集中してもらえるようにする 7. 記事構成案の作成 担当: 執筆者 さあ執筆しよう！という気持ちを抑え、わかりやすい記事構成となるよう、先に記事の構成案（章立てと各章の概要）を作り骨子を固める（コーディネーターが壁打ちなどサポート） 8. 執筆 担当: 執筆者 作成した記事構成案をベースにして執筆する Step 3 9. 運営レビュー 担当: 運営委員会、その他関係者（執筆者の上長など） 誤字脱字の基本的な確認に加え、記事をより良くするための提案を行う 後続の最終レビューの負担を減らすために、ここでできる限り記事を公開可能な状態まで持っていく 10. 最終レビュー 担当: 広報チーム、CTO 広報チームには広報視点で問題ないかを確認してもらい、CTO には網羅的な視点で問題ないかを最終確認してもらう ここで記事を公開可能な状態に仕上げる 11. 公開 担当: コーディネーター、執筆者、広報チーム 記事を公開し、社内外に共有する メドレーの公式 X アカウント でも発信しているので、フォローよろしくお願いします 運営委員会の KPI 続いて、運営委員会で設定している KPI についてです。 KPI はシンプルに、ひと月に最低 1 記事以上を公開すること まずは継続することが大事なので、最初はシンプルな KPI にしておくこと。もし KPI を増やすなら継続できる体制が整ってから 大切にしていること 最後に、ここまでで太字で強調したポイント以外に、運営上特に大切な 2 点を紹介します。 テックブログをやる目的を明確にする 何をやるにしても目的を定めて共通認識として持つことは大切ですが、テックブログの運営も同様に目的を明確にしてブレないようにする メドレーでは採用に繋げることを目的としており、テックブログを通じて社外の方々にメドレーことを知っていただき、解像度を上げてもらえるように努めている 目的が明確だと記事案の検討にも軸ができ、例えばプロダクトマネージャーの採用を強化してるならプロダクトマネージャー向けの記事を用意したりという動きができる 執筆は業務であることを明確にする 記事執筆において軽視されがちな印象で、執筆が業務であることが当たり前のようで当たり前になってなかったりする 通常業務との兼ね合いは必要になるが、業務であるということはイコール業務中に時間を確保して取り組むべきことである しかし、そこがふわっとしていると業務中に執筆し辛くなり、執筆がビハインドして公開が遅れる可能性が高くなる メドレーでは運営委員会の発足時に CTO から執筆は業務としてしっかり取り組んで欲しいという話があり、その文脈を含んで運営オペレーションを構築してきた背景がある 例えば執筆依頼を執筆者の上長を含めて行ったり、皆が見える場所で依頼などのコミュニケーションをとったり、公開までのスケジュールを細かく引いて開発プロジェクトと同じように進めたり おわりに メドレーが約 2 年半継続してきたテックブログ運営の方法を紹介しました。 リーダーとコーディネーターを中心とした運営委員会により、組織全体を縦と横に幅広くカバーし、開発プロジェクトと同じように関係者との調整やスケジューリングを行い、運営にも執筆者にも負担が集中しない無理のない体制を築くことにより、テックブログを継続運営しています。 会社の規模やフェーズによってはそのまま取り入れるのは難しいかもしれません。エッセンスだけを抽出して会社のスタイルや風土に合う形にカスタマイズし、ミニマムに運営を始めて推進していくのも良いかもしれません。 今回の記事が、テックブログを継続運営することにお困りの方の参考になれば幸いです。 We’re hiring メドレーでは一緒に働く仲間を大募集しています。カジュアル面談も実施しておりますので、少しでもご興味のある方はぜひご応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは、 Jobley でエンジニアをしている新居です。 メドレーでは 2022 年 7 月から現在まで約 2 年半、テックブログをひと月に 1 記事以上のリズムで公開し続けてきました。 この記事では企業のテックブログを一定のリズムで継続運営する方法を、メドレーの事例に沿って紹介します。テックブログを継続運営することにお困りの方の手助けになれば幸いです。 メドレーのテックブログのトップページ テックブログ運営にまつわる課題 テックブログ運営で最も難しいことは、継続的に記事を執筆し公開し続けることだと思います。 過去を振り返ると、今回紹介する方法をとる前も、コンスタントに記事を公開していました。しかし、記事を安定供給できる体制ではありませんでした。 具体的には、社内勉強会で発表した内容をテックブログにも書いてもらう運用をしていた時期があり、勉強会の準備とテックブログの執筆の両方を業務と並行して行うことは、執筆者にとって相当な負荷となっていました。執筆者の業務が忙しくなり、公開が滞るときもありました。 もちろん有志で執筆してもらうケースも多々ありましたが、このような負荷の高いルールに頼る運営は苦しく、長く続きませんでした。 それでもメドレーでは、採用活動の一環として社外のエンジニアやデザイナー、プロダクト開発に関わる方々にメドレーのことを知っていただきたいという目的があり、どうにかテックブログを継続できる方法を模索していました。 テックブログを継続運営するための取り組み ここからは、上記の課題を改善し、メドレーで約 2 年半継続してきたテックブログ運営の方法を紹介します。 メドレーでは、テックブログ運営委員会を設立し、組織的に運営するというアプローチをとっています。 具体的にどのように運営しているのか、以下の順に紹介していきます。 運営委員会のメンバー構成 運営委員会の活動 執筆推進の流れ 運営委員会の KPI 大切にしていること 運営委員会のメンバー構成 まずはメンバー構成についてです。 リーダー（必須） テックブログや運営体制のビジョンを示すのが主な役目 **会社のブランディング戦略や採用強化中の職種・ポジションを理解し、公開する記事の方向性や品質をコントロールする必要があるため、**会社の意思決定者（ CTO やマネージャー陣、また採用チームなど）と密に連携を取れる人が良い コーディネーター（必須） 記事執筆推進や定例のファシリテーション、議事録の共有が主な役目 記事ネタの収集や執筆依頼を円滑に進行するため、各事業からコーディネーターを選出することがポイント メドレーでは人材プラットフォーム事業と医療プラットフォーム事業の 2 事業から、それぞれ 1 名ずつエンジニアを選出している アドバイザー（任意） 記事ネタの提案や運営体制の改善などが主な役目 採用活動に対する解像度が高い人や会社全体を広く見ている人に協力してもらうと記事ネタの収集力が高まるため、適切に巻き込んでいくと良い メドレーでは採用チームの人や CTO 室所属の人にアドバイザーとして参加してもらっている 現在メドレーではリーダー 1 名、コーディネーター 2 名、アドバイザー 3 名の計 6 名で運営委員会を構成しています。各メンバーは運営委員会とは別にメインの業務を持ちながら、兼任で活動しています。 この体制により、組織全体を縦と横に幅広くカバーでき、テックブログの運営を効率的に進めることができています。 特にコーディネーターについては、各事業から最低 1 名を選出することで、それぞれの事業内で行われた施策や活動を把握しやすくなり、組織規模の拡大にも対応しやすくなります。 継続的な運営を実現するためには、業務の負担が特定の事業に偏らないような体制を整えることが大切です。 チームで協力して活動することで、個人に依存しない仕組みも築くことができ、突発的な問題や課題が発生しても、メンバー全員で協力して解決できます。 運営委員会の活動 続いて、運営委員会の中でやってることについてです。定例、振り返り、執筆推進が主になります。 定例 隔週で開催 アジェンダは前回決めたネクストアクションの状況共有、執筆状況の共有、次月以降の記事案の検討、その他議論共有 ここでのポイントとして、スケジュールを逆算して次の記事案を必ず決めることが超重要（決まらないまま終わらない） 例えば、記事を来月の最終営業日に公開する場合、遅くとも今月の中旬には記事案が確定し執筆者への合意もとれてる状態になってる必要があるので、スケジュールを逆算して次の記事案を必ず決める 振り返り 年 1 回で実施 今年度を振り返り、次年度の継続アクション・改善アクションを決める 直近の振り返りでは、技術系記事の数を増やしたことによる PV 数の増加や、カジュアル面談の場でテックブログの話題になることで面談がしやすくなったという成果も確認でき、継続アクションのひとつとすることを決定できた 執筆推進 以下で詳細に説明 執筆推進の流れ 続いて、執筆推進の流れを詳しく紹介します。 全体の流れは図の通りで、Step 1 から Step 3 までの流れで記事を作成していきます。 時間軸としては、Step 1 で記事の執筆依頼を終えた後、Step 2 を 3 ~ 4 週間くらいで、Step 3 を 2 週間くらいで完了させ、記事を公開するという感じで進めています。 記事執筆の流れ では、Step 1 から順に説明していきます。 Step 1 1. 記事案の選定と決定 担当: 運営委員会 定例で記事案を決定する 後述する頭出しのときに NG が出た場合に備えて候補をいくつか用意しておく 記事案のカテゴリ 技術系記事（メドレーならではの制約や困ったポイントなどがあれば、それらを明確にする） 例: トイルの削減も、情報漏洩リスクの削減も、両方手に入れる。IAM Identity Center は欲張りなんだ。 インタビュー記事 例: FY22 新卒入社エンジニアはこの 1 年でどのような成長をしてきたのかインタビューしました イベント参加記事 例: pmconf 2024 にゴールドスポンサーとして協賛しました！ etc 2. 記事案の頭出し 担当: コーディネーター 執筆完了後に NG になるのを防ぐため、先に CTO へ頭出しを行う 定例の議事録共有と合わせる形で、来月はこの記事で進める予定であることを共有する 3. 執筆の事前依頼 担当: コーディネーター 突然執筆を依頼して驚かれないように、執筆を正式依頼する前に執筆者に依頼の頭出しをしておく 4. 執筆の正式依頼 担当: コーディネーター 執筆は業務と同じ扱いなので、Slack のパブリックなチャンネルで、メンションに CTO や執筆者の上長など関係者を含み、執筆を正式に依頼する Step 2 5. スケジュールの作成 担当: コーディネーター 執筆、初稿提出、レビュー、最終レビューまでの流れをカレンダーに落とし込み、関係者に共有する 締切を明確にしつつ、通常業務の合間でも最後まで執筆作業を走りきれるよう、しっかりコーディネーターが進捗確認などしつつフォローする 6. 執筆環境の構築 担当: コーディネーター GitHub で記事を管理しているので、記事のベースファイルを作成し、Issue と Pull Request を用意する 執筆者の負担をなるべく減らし、記事執筆のみに集中してもらえるようにする 7. 記事構成案の作成 担当: 執筆者 さあ執筆しよう！という気持ちを抑え、わかりやすい記事構成となるよう、先に記事の構成案（章立てと各章の概要）を作り骨子を固める（コーディネーターが壁打ちなどサポート） 8. 執筆 担当: 執筆者 作成した記事構成案をベースにして執筆する Step 3 9. 運営レビュー 担当: 運営委員会、その他関係者（執筆者の上長など） 誤字脱字の基本的な確認に加え、記事をより良くするための提案を行う 後続の最終レビューの負担を減らすために、ここでできる限り記事を公開可能な状態まで持っていく 10. 最終レビュー 担当: 広報チーム、CTO 広報チームには広報視点で問題ないかを確認してもらい、CTO には網羅的な視点で問題ないかを最終確認してもらう ここで記事を公開可能な状態に仕上げる 11. 公開 担当: コーディネーター、執筆者、広報チーム 記事を公開し、社内外に共有する メドレーの公式 X アカウント でも発信しているので、フォローよろしくお願いします 運営委員会の KPI 続いて、運営委員会で設定している KPI についてです。 KPI はシンプルに、ひと月に最低 1 記事以上を公開すること まずは継続することが大事なので、最初はシンプルな KPI にしておくこと。もし KPI を増やすなら継続できる体制が整ってから 大切にしていること 最後に、ここまでで太字で強調したポイント以外に、運営上特に大切な 2 点を紹介します。 テックブログをやる目的を明確にする 何をやるにしても目的を定めて共通認識として持つことは大切ですが、テックブログの運営も同様に目的を明確にしてブレないようにする メドレーでは採用に繋げることを目的としており、テックブログを通じて社外の方々にメドレーことを知っていただき、解像度を上げてもらえるように努めている 目的が明確だと記事案の検討にも軸ができ、例えばプロダクトマネージャーの採用を強化してるならプロダクトマネージャー向けの記事を用意したりという動きができる 執筆は業務であることを明確にする 記事執筆において軽視されがちな印象で、執筆が業務であることが当たり前のようで当たり前になってなかったりする 通常業務との兼ね合いは必要になるが、業務であるということはイコール業務中に時間を確保して取り組むべきことである しかし、そこがふわっとしていると業務中に執筆し辛くなり、執筆がビハインドして公開が遅れる可能性が高くなる メドレーでは運営委員会の発足時に CTO から執筆は業務としてしっかり取り組んで欲しいという話があり、その文脈を含んで運営オペレーションを構築してきた背景がある 例えば執筆依頼を執筆者の上長を含めて行ったり、皆が見える場所で依頼などのコミュニケーションをとったり、公開までのスケジュールを細かく引いて開発プロジェクトと同じように進めたり おわりに メドレーが約 2 年半継続してきたテックブログ運営の方法を紹介しました。 リーダーとコーディネーターを中心とした運営委員会により、組織全体を縦と横に幅広くカバーし、開発プロジェクトと同じように関係者との調整やスケジューリングを行い、運営にも執筆者にも負担が集中しない無理のない体制を築くことにより、テックブログを継続運営しています。 会社の規模やフェーズによってはそのまま取り入れるのは難しいかもしれません。エッセンスだけを抽出して会社のスタイルや風土に合う形にカスタマイズし、ミニマムに運営を始めて推進していくのも良いかもしれません。 今回の記事が、テックブログを継続運営することにお困りの方の参考になれば幸いです。 We’re hiring メドレーでは一緒に働く仲間を大募集しています。カジュアル面談も実施しておりますので、少しでもご興味のある方はぜひご応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは、 Jobley でエンジニアをしている新居です。 メドレーでは 2022 年 7 月から現在まで約 2 年半、テックブログをひと月に 1 記事以上のリズムで公開し続けてきました。 この記事では企業のテックブログを一定のリズムで継続運営する方法を、メドレーの事例に沿って紹介します。テックブログを継続運営することにお困りの方の手助けになれば幸いです。 メドレーのテックブログのトップページ テックブログ運営にまつわる課題 テックブログ運営で最も難しいことは、継続的に記事を執筆し公開し続けることだと思います。 過去を振り返ると、今回紹介する方法をとる前も、コンスタントに記事を公開していました。しかし、記事を安定供給できる体制ではありませんでした。 具体的には、社内勉強会で発表した内容をテックブログにも書いてもらう運用をしていた時期があり、勉強会の準備とテックブログの執筆の両方を業務と並行して行うことは、執筆者にとって相当な負荷となっていました。執筆者の業務が忙しくなり、公開が滞るときもありました。 もちろん有志で執筆してもらうケースも多々ありましたが、このような負荷の高いルールに頼る運営は苦しく、長く続きませんでした。 それでもメドレーでは、採用活動の一環として社外のエンジニアやデザイナー、プロダクト開発に関わる方々にメドレーのことを知っていただきたいという目的があり、どうにかテックブログを継続できる方法を模索していました。 テックブログを継続運営するための取り組み ここからは、上記の課題を改善し、メドレーで約 2 年半継続してきたテックブログ運営の方法を紹介します。 メドレーでは、テックブログ運営委員会を設立し、組織的に運営するというアプローチをとっています。 具体的にどのように運営しているのか、以下の順に紹介していきます。 運営委員会のメンバー構成 運営委員会の活動 執筆推進の流れ 運営委員会の KPI 大切にしていること 運営委員会のメンバー構成 まずはメンバー構成についてです。 リーダー（必須） テックブログや運営体制のビジョンを示すのが主な役目 **会社のブランディング戦略や採用強化中の職種・ポジションを理解し、公開する記事の方向性や品質をコントロールする必要があるため、**会社の意思決定者（ CTO やマネージャー陣、また採用チームなど）と密に連携を取れる人が良い コーディネーター（必須） 記事執筆推進や定例のファシリテーション、議事録の共有が主な役目 記事ネタの収集や執筆依頼を円滑に進行するため、各事業からコーディネーターを選出することがポイント メドレーでは人材プラットフォーム事業と医療プラットフォーム事業の 2 事業から、それぞれ 1 名ずつエンジニアを選出している アドバイザー（任意） 記事ネタの提案や運営体制の改善などが主な役目 採用活動に対する解像度が高い人や会社全体を広く見ている人に協力してもらうと記事ネタの収集力が高まるため、適切に巻き込んでいくと良い メドレーでは採用チームの人や CTO 室所属の人にアドバイザーとして参加してもらっている 現在メドレーではリーダー 1 名、コーディネーター 2 名、アドバイザー 3 名の計 6 名で運営委員会を構成しています。各メンバーは運営委員会とは別にメインの業務を持ちながら、兼任で活動しています。 この体制により、組織全体を縦と横に幅広くカバーでき、テックブログの運営を効率的に進めることができています。 特にコーディネーターについては、各事業から最低 1 名を選出することで、それぞれの事業内で行われた施策や活動を把握しやすくなり、組織規模の拡大にも対応しやすくなります。 継続的な運営を実現するためには、業務の負担が特定の事業に偏らないような体制を整えることが大切です。 チームで協力して活動することで、個人に依存しない仕組みも築くことができ、突発的な問題や課題が発生しても、メンバー全員で協力して解決できます。 運営委員会の活動 続いて、運営委員会の中でやってることについてです。定例、振り返り、執筆推進が主になります。 定例 隔週で開催 アジェンダは前回決めたネクストアクションの状況共有、執筆状況の共有、次月以降の記事案の検討、その他議論共有 ここでのポイントとして、スケジュールを逆算して次の記事案を必ず決めることが超重要（決まらないまま終わらない） 例えば、記事を来月の最終営業日に公開する場合、遅くとも今月の中旬には記事案が確定し執筆者への合意もとれてる状態になってる必要があるので、スケジュールを逆算して次の記事案を必ず決める 振り返り 年 1 回で実施 今年度を振り返り、次年度の継続アクション・改善アクションを決める 直近の振り返りでは、技術系記事の数を増やしたことによる PV 数の増加や、カジュアル面談の場でテックブログの話題になることで面談がしやすくなったという成果も確認でき、継続アクションのひとつとすることを決定できた 執筆推進 以下で詳細に説明 執筆推進の流れ 続いて、執筆推進の流れを詳しく紹介します。 全体の流れは図の通りで、Step 1 から Step 3 までの流れで記事を作成していきます。 時間軸としては、Step 1 で記事の執筆依頼を終えた後、Step 2 を 3 ~ 4 週間くらいで、Step 3 を 2 週間くらいで完了させ、記事を公開するという感じで進めています。 記事執筆の流れ では、Step 1 から順に説明していきます。 Step 1 1. 記事案の選定と決定 担当: 運営委員会 定例で記事案を決定する 後述する頭出しのときに NG が出た場合に備えて候補をいくつか用意しておく 記事案のカテゴリ 技術系記事（メドレーならではの制約や困ったポイントなどがあれば、それらを明確にする） 例: トイルの削減も、情報漏洩リスクの削減も、両方手に入れる。IAM Identity Center は欲張りなんだ。 インタビュー記事 例: FY22 新卒入社エンジニアはこの 1 年でどのような成長をしてきたのかインタビューしました イベント参加記事 例: pmconf 2024 にゴールドスポンサーとして協賛しました！ etc 2. 記事案の頭出し 担当: コーディネーター 執筆完了後に NG になるのを防ぐため、先に CTO へ頭出しを行う 定例の議事録共有と合わせる形で、来月はこの記事で進める予定であることを共有する 3. 執筆の事前依頼 担当: コーディネーター 突然執筆を依頼して驚かれないように、執筆を正式依頼する前に執筆者に依頼の頭出しをしておく 4. 執筆の正式依頼 担当: コーディネーター 執筆は業務と同じ扱いなので、Slack のパブリックなチャンネルで、メンションに CTO や執筆者の上長など関係者を含み、執筆を正式に依頼する Step 2 5. スケジュールの作成 担当: コーディネーター 執筆、初稿提出、レビュー、最終レビューまでの流れをカレンダーに落とし込み、関係者に共有する 締切を明確にしつつ、通常業務の合間でも最後まで執筆作業を走りきれるよう、しっかりコーディネーターが進捗確認などしつつフォローする 6. 執筆環境の構築 担当: コーディネーター GitHub で記事を管理しているので、記事のベースファイルを作成し、Issue と Pull Request を用意する 執筆者の負担をなるべく減らし、記事執筆のみに集中してもらえるようにする 7. 記事構成案の作成 担当: 執筆者 さあ執筆しよう！という気持ちを抑え、わかりやすい記事構成となるよう、先に記事の構成案（章立てと各章の概要）を作り骨子を固める（コーディネーターが壁打ちなどサポート） 8. 執筆 担当: 執筆者 作成した記事構成案をベースにして執筆する Step 3 9. 運営レビュー 担当: 運営委員会、その他関係者（執筆者の上長など） 誤字脱字の基本的な確認に加え、記事をより良くするための提案を行う 後続の最終レビューの負担を減らすために、ここでできる限り記事を公開可能な状態まで持っていく 10. 最終レビュー 担当: 広報チーム、CTO 広報チームには広報視点で問題ないかを確認してもらい、CTO には網羅的な視点で問題ないかを最終確認してもらう ここで記事を公開可能な状態に仕上げる 11. 公開 担当: コーディネーター、執筆者、広報チーム 記事を公開し、社内外に共有する メドレーの公式 X アカウント でも発信しているので、フォローよろしくお願いします 運営委員会の KPI 続いて、運営委員会で設定している KPI についてです。 KPI はシンプルに、ひと月に最低 1 記事以上を公開すること まずは継続することが大事なので、最初はシンプルな KPI にしておくこと。もし KPI を増やすなら継続できる体制が整ってから 大切にしていること 最後に、ここまでで太字で強調したポイント以外に、運営上特に大切な 2 点を紹介します。 テックブログをやる目的を明確にする 何をやるにしても目的を定めて共通認識として持つことは大切ですが、テックブログの運営も同様に目的を明確にしてブレないようにする メドレーでは採用に繋げることを目的としており、テックブログを通じて社外の方々にメドレーことを知っていただき、解像度を上げてもらえるように努めている 目的が明確だと記事案の検討にも軸ができ、例えばプロダクトマネージャーの採用を強化してるならプロダクトマネージャー向けの記事を用意したりという動きができる 執筆は業務であることを明確にする 記事執筆において軽視されがちな印象で、執筆が業務であることが当たり前のようで当たり前になってなかったりする 通常業務との兼ね合いは必要になるが、業務であるということはイコール業務中に時間を確保して取り組むべきことである しかし、そこがふわっとしていると業務中に執筆し辛くなり、執筆がビハインドして公開が遅れる可能性が高くなる メドレーでは運営委員会の発足時に CTO から執筆は業務としてしっかり取り組んで欲しいという話があり、その文脈を含んで運営オペレーションを構築してきた背景がある 例えば執筆依頼を執筆者の上長を含めて行ったり、皆が見える場所で依頼などのコミュニケーションをとったり、公開までのスケジュールを細かく引いて開発プロジェクトと同じように進めたり おわりに メドレーが約 2 年半継続してきたテックブログ運営の方法を紹介しました。 リーダーとコーディネーターを中心とした運営委員会により、組織全体を縦と横に幅広くカバーし、開発プロジェクトと同じように関係者との調整やスケジューリングを行い、運営にも執筆者にも負担が集中しない無理のない体制を築くことにより、テックブログを継続運営しています。 会社の規模やフェーズによってはそのまま取り入れるのは難しいかもしれません。エッセンスだけを抽出して会社のスタイルや風土に合う形にカスタマイズし、ミニマムに運営を始めて推進していくのも良いかもしれません。 今回の記事が、テックブログを継続運営することにお困りの方の参考になれば幸いです。 We’re hiring メドレーでは一緒に働く仲間を大募集しています。カジュアル面談も実施しておりますので、少しでもご興味のある方はぜひご応募お待ちしております。 https://www.medley.jp/jobs/

こんにちは、 Jobley でエンジニアをしている新居です。 メドレーでは 2022 年 7 月から現在まで約 2 年半、テックブログをひと月に 1 記事以上のリズムで公開し続けてきました。 この記事では企業のテックブログを一定のリズムで継続運営する方法を、メドレーの事例に沿って紹介します。テックブログを継続運営することにお困りの方の手助けになれば幸いです。 メドレーのテックブログのトップページ テックブログ運営にまつわる課題 テックブログ運営で最も難しいことは、継続的に記事を執筆し公開し続けることだと思います。 過去を振り返ると、今回紹介する方法をとる前も、コンスタントに記事を公開していました。しかし、記事を安定供給できる体制ではありませんでした。 具体的には、社内勉強会で発表した内容をテックブログにも書いてもらう運用をしていた時期があり、勉強会の準備とテックブログの執筆の両方を業務と並行して行うことは、執筆者にとって相当な負荷となっていました。執筆者の業務が忙しくなり、公開が滞るときもありました。 もちろん有志で執筆してもらうケースも多々ありましたが、このような負荷の高いルールに頼る運営は苦しく、長く続きませんでした。 それでもメドレーでは、採用活動の一環として社外のエンジニアやデザイナー、プロダクト開発に関わる方々にメドレーのことを知っていただきたいという目的があり、どうにかテックブログを継続できる方法を模索していました。 テックブログを継続運営するための取り組み ここからは、上記の課題を改善し、メドレーで約 2 年半継続してきたテックブログ運営の方法を紹介します。 メドレーでは、テックブログ運営委員会を設立し、組織的に運営するというアプローチをとっています。 具体的にどのように運営しているのか、以下の順に紹介していきます。 運営委員会のメンバー構成 運営委員会の活動 執筆推進の流れ 運営委員会の KPI 大切にしていること 運営委員会のメンバー構成 まずはメンバー構成についてです。 リーダー（必須） テックブログや運営体制のビジョンを示すのが主な役目 **会社のブランディング戦略や採用強化中の職種・ポジションを理解し、公開する記事の方向性や品質をコントロールする必要があるため、**会社の意思決定者（ CTO やマネージャー陣、また採用チームなど）と密に連携を取れる人が良い コーディネーター（必須） 記事執筆推進や定例のファシリテーション、議事録の共有が主な役目 記事ネタの収集や執筆依頼を円滑に進行するため、各事業からコーディネーターを選出することがポイント メドレーでは人材プラットフォーム事業と医療プラットフォーム事業の 2 事業から、それぞれ 1 名ずつエンジニアを選出している アドバイザー（任意） 記事ネタの提案や運営体制の改善などが主な役目 採用活動に対する解像度が高い人や会社全体を広く見ている人に協力してもらうと記事ネタの収集力が高まるため、適切に巻き込んでいくと良い メドレーでは採用チームの人や CTO 室所属の人にアドバイザーとして参加してもらっている 現在メドレーではリーダー 1 名、コーディネーター 2 名、アドバイザー 3 名の計 6 名で運営委員会を構成しています。各メンバーは運営委員会とは別にメインの業務を持ちながら、兼任で活動しています。 この体制により、組織全体を縦と横に幅広くカバーでき、テックブログの運営を効率的に進めることができています。 特にコーディネーターについては、各事業から最低 1 名を選出することで、それぞれの事業内で行われた施策や活動を把握しやすくなり、組織規模の拡大にも対応しやすくなります。 継続的な運営を実現するためには、業務の負担が特定の事業に偏らないような体制を整えることが大切です。 チームで協力して活動することで、個人に依存しない仕組みも築くことができ、突発的な問題や課題が発生しても、メンバー全員で協力して解決できます。 運営委員会の活動 続いて、運営委員会の中でやってることについてです。定例、振り返り、執筆推進が主になります。 定例 隔週で開催 アジェンダは前回決めたネクストアクションの状況共有、執筆状況の共有、次月以降の記事案の検討、その他議論共有 ここでのポイントとして、スケジュールを逆算して次の記事案を必ず決めることが超重要（決まらないまま終わらない） 例えば、記事を来月の最終営業日に公開する場合、遅くとも今月の中旬には記事案が確定し執筆者への合意もとれてる状態になってる必要があるので、スケジュールを逆算して次の記事案を必ず決める 振り返り 年 1 回で実施 今年度を振り返り、次年度の継続アクション・改善アクションを決める 直近の振り返りでは、技術系記事の数を増やしたことによる PV 数の増加や、カジュアル面談の場でテックブログの話題になることで面談がしやすくなったという成果も確認でき、継続アクションのひとつとすることを決定できた 執筆推進 以下で詳細に説明 執筆推進の流れ 続いて、執筆推進の流れを詳しく紹介します。 全体の流れは図の通りで、Step 1 から Step 3 までの流れで記事を作成していきます。 時間軸としては、Step 1 で記事の執筆依頼を終えた後、Step 2 を 3 ~ 4 週間くらいで、Step 3 を 2 週間くらいで完了させ、記事を公開するという感じで進めています。 記事執筆の流れ では、Step 1 から順に説明していきます。 Step 1 1. 記事案の選定と決定 担当: 運営委員会 定例で記事案を決定する 後述する頭出しのときに NG が出た場合に備えて候補をいくつか用意しておく 記事案のカテゴリ 技術系記事（メドレーならではの制約や困ったポイントなどがあれば、それらを明確にする） 例: トイルの削減も、情報漏洩リスクの削減も、両方手に入れる。IAM Identity Center は欲張りなんだ。 インタビュー記事 例: FY22 新卒入社エンジニアはこの 1 年でどのような成長をしてきたのかインタビューしました イベント参加記事 例: pmconf 2024 にゴールドスポンサーとして協賛しました！ etc 2. 記事案の頭出し 担当: コーディネーター 執筆完了後に NG になるのを防ぐため、先に CTO へ頭出しを行う 定例の議事録共有と合わせる形で、来月はこの記事で進める予定であることを共有する 3. 執筆の事前依頼 担当: コーディネーター 突然執筆を依頼して驚かれないように、執筆を正式依頼する前に執筆者に依頼の頭出しをしておく 4. 執筆の正式依頼 担当: コーディネーター 執筆は業務と同じ扱いなので、Slack のパブリックなチャンネルで、メンションに CTO や執筆者の上長など関係者を含み、執筆を正式に依頼する Step 2 5. スケジュールの作成 担当: コーディネーター 執筆、初稿提出、レビュー、最終レビューまでの流れをカレンダーに落とし込み、関係者に共有する 締切を明確にしつつ、通常業務の合間でも最後まで執筆作業を走りきれるよう、しっかりコーディネーターが進捗確認などしつつフォローする 6. 執筆環境の構築 担当: コーディネーター GitHub で記事を管理しているので、記事のベースファイルを作成し、Issue と Pull Request を用意する 執筆者の負担をなるべく減らし、記事執筆のみに集中してもらえるようにする 7. 記事構成案の作成 担当: 執筆者 さあ執筆しよう！という気持ちを抑え、わかりやすい記事構成となるよう、先に記事の構成案（章立てと各章の概要）を作り骨子を固める（コーディネーターが壁打ちなどサポート） 8. 執筆 担当: 執筆者 作成した記事構成案をベースにして執筆する Step 3 9. 運営レビュー 担当: 運営委員会、その他関係者（執筆者の上長など） 誤字脱字の基本的な確認に加え、記事をより良くするための提案を行う 後続の最終レビューの負担を減らすために、ここでできる限り記事を公開可能な状態まで持っていく 10. 最終レビュー 担当: 広報チーム、CTO 広報チームには広報視点で問題ないかを確認してもらい、CTO には網羅的な視点で問題ないかを最終確認してもらう ここで記事を公開可能な状態に仕上げる 11. 公開 担当: コーディネーター、執筆者、広報チーム 記事を公開し、社内外に共有する メドレーの公式 X アカウント でも発信しているので、フォローよろしくお願いします 運営委員会の KPI 続いて、運営委員会で設定している KPI についてです。 KPI はシンプルに、ひと月に最低 1 記事以上を公開すること まずは継続することが大事なので、最初はシンプルな KPI にしておくこと。もし KPI を増やすなら継続できる体制が整ってから 大切にしていること 最後に、ここまでで太字で強調したポイント以外に、運営上特に大切な 2 点を紹介します。 テックブログをやる目的を明確にする 何をやるにしても目的を定めて共通認識として持つことは大切ですが、テックブログの運営も同様に目的を明確にしてブレないようにする メドレーでは採用に繋げることを目的としており、テックブログを通じて社外の方々にメドレーことを知っていただき、解像度を上げてもらえるように努めている 目的が明確だと記事案の検討にも軸ができ、例えばプロダクトマネージャーの採用を強化してるならプロダクトマネージャー向けの記事を用意したりという動きができる 執筆は業務であることを明確にする 記事執筆において軽視されがちな印象で、執筆が業務であることが当たり前のようで当たり前になってなかったりする 通常業務との兼ね合いは必要になるが、業務であるということはイコール業務中に時間を確保して取り組むべきことである しかし、そこがふわっとしていると業務中に執筆し辛くなり、執筆がビハインドして公開が遅れる可能性が高くなる メドレーでは運営委員会の発足時に CTO から執筆は業務としてしっかり取り組んで欲しいという話があり、その文脈を含んで運営オペレーションを構築してきた背景がある 例えば執筆依頼を執筆者の上長を含めて行ったり、皆が見える場所で依頼などのコミュニケーションをとったり、公開までのスケジュールを細かく引いて開発プロジェクトと同じように進めたり おわりに メドレーが約 2 年半継続してきたテックブログ運営の方法を紹介しました。 リーダーとコーディネーターを中心とした運営委員会により、組織全体を縦と横に幅広くカバーし、開発プロジェクトと同じように関係者との調整やスケジューリングを行い、運営にも執筆者にも負担が集中しない無理のない体制を築くことにより、テックブログを継続運営しています。 会社の規模やフェーズによってはそのまま取り入れるのは難しいかもしれません。エッセンスだけを抽出して会社のスタイルや風土に合う形にカスタマイズし、ミニマムに運営を始めて推進していくのも良いかもしれません。 今回の記事が、テックブログを継続運営することにお困りの方の参考になれば幸いです。 We’re hiring メドレーでは一緒に働く仲間を大募集しています。カジュアル面談も実施しておりますので、少しでもご興味のある方はぜひご応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp