こんにちは。人材プラットフォーム本部プロダクト開発室 第五開発グループ所属の寺内です。 新卒からメドレーに入社して今年で 4 年目のエンジニアで、老人ホーム・介護施設の検索サイトである 介護のほんね の開発を担当しています。 メドレーは 5 月 15 日から 17 日に 沖縄県那覇市の 那覇文化芸術劇場なはーと にて開催された RubyKaigi 2024 に Ruby Sponsor として協賛しました！ RubyKaigi 2024 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。 エンジニアとエンジニア採用担当の計 12 名が現地参加し、たくさんの方々と交流させて頂きました。また、スポンサー LT もさせていただきました。 今回は会場・ブース・発表の様子と、スポンサー LT の内容をご紹介します。 会場の様子 会場となった那覇文化芸術劇場なはーとは、国際通りからほど近い場所でありながら閑静な市街地にありました。 沖縄らしさを感じさせる建築デザイン 建物内は 4 階まで吹き抜けとなっていて開放感が溢れている会場でしたが、セッション間はこのように各社のブースを訪問する人々でいっぱいになり、RubyKaigi の盛況ぶりを感じることができました。 なんと今年の来場者数は約 1400 人だったそうです！ RubyKaigi 2024 の公式配布グッズは、例年とは異なり T シャツではなくかりゆしとビーチサンダルでした！運営の粋な計らいのおかげで、会期中会場がカラフルでしたね。 2 日目から始まったスタンプラリーでは来場者のブース訪問がより活発になったのを感じました。ブースを巡ってスタンプを集めると限定バッジがもらえました。 バッジ交換時にスタッフさんが全力で拍手をしてくださるのでとても幸せな気持ちになりました！ 弊社ブースの様子 メドレーブースではうちわやビーチサンダルなどの沖縄らしいものをはじめ、医療事業を手がける企業のアピールとして絆創膏をノベルティとしてご用意しました。 靴擦れしてしまった方に絆創膏をお渡ししたらとても喜んでいただきました アンケートパネルを用いて参加者の方が抱えている医療体験のお悩みを伺いました。 伺ったお悩みからわかる課題に対してメドレーがプロダクトを通じてどのように向き合い・解決しているのかをご紹介しました。 特に回答が多かったのが 「待ち時間が」長い という課題でした。 メドレーの提供するオンライン診療・服薬指導アプリ「 CLINICS 」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、直近では Uber Eats との連携で服薬指導後30分程度で自宅までお薬を届けてもらうことも可能になったことをご説明すると、「ここまで便利になっていることは知らなかった！」と驚きのお声を多数いただきました。 会場の那覇付近でもこれだけの医療機関が見つかりました また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（ CLINICS 、 MALL 、 Pharms 、 Dentis ）を通じてサポートしていること、一つの課題に対して様々なアプローチをとっていることなどをお話ししました。 ツアー風 T シャツには今年メドレーがスポンサードしたイベントの一覧が掲載されています メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加したメドレーメンバー全員で 発表の様子 3 日間にわたってさまざまなセッションがありましたが、私が気になった以下のセッションについて少しご紹介します。 Keynote DAY1 rubykaigiB 「Long journey of Ruby standard library」 DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」 Matz Keynote Keynote 今年の Keynote は tomoya ishida さんによる「Writing Weird Code」という発表でした。 Quine というコードと実行結果が同じ内容になるプログラムに関する発表で、Rubyの表現力と楽しさを紹介するものでした。 中でも発表中に行われた一人 TRICK(Transcendental Ruby Imbroglio Contest for RubyKaigi)では、Most 〇〇 と名付けられたグラフィカルなコードが紹介され、会場は大盛りあがりでした！ 紹介されていたものは GitHub にて ソースコード が公開されています。 引用元: drive.google.com DAY1 rubykaigiB 「Long journey of Ruby standard library」 Hiroshi SHIBATA さんによる、Ruby の標準ライブラリとは何なのかと、その歴史についての発表でした。 引用元: speakerdeck.com 組み込みクラスと標準ライブラリの違い 組み込みクラスとは require しなくても使えるもので、標準ライブラリとは require しないと使えないものです。標準ライブラリの中には Ruby だけで書かれたものと C 拡張で書かれたものがあります。 歴史と傾向 Ruby の標準ライブラリの数は Ruby1.8 から減少傾向にあります。1.6 から 1.8 では数が増えたようですが、これはインターネットが常時接続ではなかったため、 gem install でインストールするより、Ruby をインストールしただけでたくさんの機能が使えたほうが良いのではという背景のもとに増えたとのことです。 default gems と bundled gems という概念の導入 default gems にコミットされたものは自動で Ruby 本体にもコミットされ、bundled gems にコミットされたものは Ruby 本体にコミットされないようになったそうです。 default gems や bundled gemsに関する活動をする理由は、セキュリティ対応と Ruby の持続可能性を高めるためとのことでした。 セキュリティ対応については、サプライチェーンアタックを防ぐために gem 同士の依存関係を少なくするようにしているそうです。これにより脆弱性対応時に単体のライブラリをアップデートするだけで済むようになり、結果として工数を削減することができるようになったのは開発者として大変ありがたいことだと思いました。 Ruby 自体の持続可能性については、Ruby にコミットしたい人に適切に権限を付与できるようにし、ライブラリ単体でも開発できる状態を目指すということだそうで、Ruby のこれからを支える人々の動きを促進する素晴らしいものだと感じました。 影響 default gems が bundled gems になる影響として、bundler の下で使う際に Gemfile に書かないと使えなくなってしまうことが紹介されました。default gems でもバージョン指定する際は Gemfile に書き込む必要があるようです。 これを解決するために、Ruby3.3 では警告機能が実装されました。 require "csv" などで実行すると、Ruby3.4 では bundled gems になる旨を伝える警告が出力されるというものです。これを元に Gemfile に情報を追加すれば良いので、対応がわかりやすくなったというメリットがあります。 また、自分が使っていないライブラリの警告だとしても、他のどのライブラリから呼び出されているのかも確認できるそうです。これを確認する際に、使っていないものであれば削除して依存関係を少なくする整理にも役立つそうです。 感想 引き続き bundled gems の数を増やして default gems の数を減らすことでメンテナンス性を高める方針のようなので、適宜分類をチェックして Gemfile への追加や Gem を使っているかの整理を進めて行きたいです。 DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」 Shunsuke Mori(kokuyou)さんによる、Ruby で大型言語モデル（LLM）を使用して RBS 型シグネチャを改良するツールである RBS Goose を作成されたことに関する発表でした。 引用元: slides.com RBS とは？ & 既存の RBS 作成手法 RBS とは、Ruby の型構造を定義するためのもので、型検査による安全な開発や補完の強化など開発体験を向上させる目的で使用されます。 既存の RBS 作成手法としては以下の 3 つが紹介されていました。 静的構文解析: 高速であるが推測できるものが少ない。attr_accessor などはメタプログラミングで生成されるものなので静的構文解析では RBS に出力されない。ruby にそもそも型情報がないので untyped になる。 動的ロード: ロード時にクラス全体が読み込まれ、その結果をリフレクションで RBS に書き出すことで、メタプログラミングで生成している attr_accessor のメソッドも定義される。しかし、こちらも型情報がないので untyped になる。 型レベル実行: 実行時の値を渡すときに型の情報を受け渡し、これをとっておいて RBS に出力する。コードを実際に動かす必要がある。 これらの手法では untyped を手作業で直したり、足りないものを補うのが大変であり、これを解決したい動機で RBS Goose を作成されたそうです。 RBS Goose の仕組み RBS Goose は RBS を生成する既存手法でネックになっていた untyped を手作業で直したり、足りないものを補う作業を LLM の力を借りて解決する仕組みのようでした。 RBS 生成の流れは以下のようになっています。 hoge.rb に対して静的構文解析などで hoge.rbs を作成 LLM の入力に使う prompt を組み立て この際に hoge.rb とは全く違う fuga.rb とそれを静的構文解析などで作った fuga.rbs と LLM に出力してほしいお手本の refined_fuga.rbs の 3 つを追加で入れる お手本を入れることで期待する答えを出しやすくする Few-shot プロンプティング という手法を採用している LLM に prompt を渡す RBS を出力 実用レベルにするには複数ファイルを扱えるようにする必要があり、それをどうするかの実現ビジョンについても語られていました。 LLM を使った開発の Tips 開発時の Tips が共有されていたのですが、その中でも特に学びになったのはテスト時の Tips でした。 従量課金のコストがかかる & 応答時間がかかるのでテストに時間がかかってしまうことを解決するために、 VCR のような Web モックを利用すると良いということ、 LLM の再現性確保のために Temperature（言語モデルの出力のランダム性を制御するパラメータのこと）の設定は 0 にすることがおすすめであるという Tips が共有されました。 感想 性能については割愛しますが、RBS Goose を用いてより良い RBS を得られると、補完の強化などで開発体験が向上することが期待できそうで、実用化が待ち遠しいです。 去年の Keynote で ChatGPT に型を推論させてもある程度形になることが語られていましたが、今年の発表で LLM を使用して型情報の定義をサポートするツールが発表されたことで、RBS への興味関心が大きくなりました！ Matz Keynote 今年の RubyKaigi 最後のセッションは Matz が担当しました。どうしたら Ruby をもっとよくできるかについての話では、パフォーマンス改善がキーになるというお話がありました。 パフォーマンス改善のために必要な要素は多岐にわたるため、これをコミュニティ全体で力を合わせて解決していく必要がある というメッセージや、カンファレンスで人々が話をしたことがきっかけでRubyGems が生まれたことから、コミュニティの人々が一緒に取り組めばもっとRuby を良くすることができるはずである というメッセージを受け、Ruby コミュニティの一員として胸の熱くなる想いでした。 メドレーブースに遊びに来てくれた Matz と スポンサー LT の様子 メドレーの LT 登壇は Matz の ClosingLT の直前ということもあり、会場が超満員に。登壇した VPoE の山﨑を応援しようと、サプライズで応援うちわを作っていったのですが、残念ながらあの大舞台からは見えなかったようです（笑） うちわは社内で活用させていただきます あそこまで大きな会場だと思ってなかった…！by 山﨑 LT で発表させていただきましたが、メドレーはコミュニティへの支援を行っています。6 月 13 日に約 1 年半ぶりの開催となる Roppongi.rb をスポンサードしており、メドレーオフィスで開催予定です。ご興味のある方はぜひご参加ください。 https://roppongirb.connpass.com/event/319768/ 私も地域 Ruby コミュニティに積極的に参加しようと思いますので、Ruby コミュニティを一緒に盛り上げていきましょう！ さいごに RubyKaigi 2024 に Ruby Sponsor として協賛した様子をお届けしました。 ブースやパーティーを通じて交流させていただいた皆様、Ruby とそのコミュニティの素晴らしさを存分に体感できるイベントを運営してくださった皆様に心より感謝いたします。 メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味を持っていただいた方からのご連絡をお待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。人材プラットフォーム本部プロダクト開発室 第五開発グループ所属の寺内です。 新卒からメドレーに入社して今年で 4 年目のエンジニアで、老人ホーム・介護施設の検索サイトである 介護のほんね の開発を担当しています。 メドレーは 5 月 15 日から 17 日に 沖縄県那覇市の 那覇文化芸術劇場なはーと にて開催された RubyKaigi 2024 に Ruby Sponsor として協賛しました！ RubyKaigi 2024 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。 エンジニアとエンジニア採用担当の計 12 名が現地参加し、たくさんの方々と交流させて頂きました。また、スポンサー LT もさせていただきました。 今回は会場・ブース・発表の様子と、スポンサー LT の内容をご紹介します。 会場の様子 会場となった那覇文化芸術劇場なはーとは、国際通りからほど近い場所でありながら閑静な市街地にありました。 沖縄らしさを感じさせる建築デザイン 建物内は 4 階まで吹き抜けとなっていて開放感が溢れている会場でしたが、セッション間はこのように各社のブースを訪問する人々でいっぱいになり、RubyKaigi の盛況ぶりを感じることができました。 なんと今年の来場者数は約 1400 人だったそうです！ RubyKaigi 2024 の公式配布グッズは、例年とは異なり T シャツではなくかりゆしとビーチサンダルでした！運営の粋な計らいのおかげで、会期中会場がカラフルでしたね。 2 日目から始まったスタンプラリーでは来場者のブース訪問がより活発になったのを感じました。ブースを巡ってスタンプを集めると限定バッジがもらえました。 バッジ交換時にスタッフさんが全力で拍手をしてくださるのでとても幸せな気持ちになりました！ 弊社ブースの様子 メドレーブースではうちわやビーチサンダルなどの沖縄らしいものをはじめ、医療事業を手がける企業のアピールとして絆創膏をノベルティとしてご用意しました。 靴擦れしてしまった方に絆創膏をお渡ししたらとても喜んでいただきました アンケートパネルを用いて参加者の方が抱えている医療体験のお悩みを伺いました。 伺ったお悩みからわかる課題に対してメドレーがプロダクトを通じてどのように向き合い・解決しているのかをご紹介しました。 特に回答が多かったのが 「待ち時間が」長い という課題でした。 メドレーの提供するオンライン診療・服薬指導アプリ「 CLINICS 」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、直近では Uber Eats との連携で服薬指導後30分程度で自宅までお薬を届けてもらうことも可能になったことをご説明すると、「ここまで便利になっていることは知らなかった！」と驚きのお声を多数いただきました。 会場の那覇付近でもこれだけの医療機関が見つかりました また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（ CLINICS 、 MALL 、 Pharms 、 Dentis ）を通じてサポートしていること、一つの課題に対して様々なアプローチをとっていることなどをお話ししました。 ツアー風 T シャツには今年メドレーがスポンサードしたイベントの一覧が掲載されています メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加したメドレーメンバー全員で 発表の様子 3 日間にわたってさまざまなセッションがありましたが、私が気になった以下のセッションについて少しご紹介します。 Keynote DAY1 rubykaigiB 「Long journey of Ruby standard library」 DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」 Matz Keynote Keynote 今年の Keynote は tomoya ishida さんによる「Writing Weird Code」という発表でした。 Quine というコードと実行結果が同じ内容になるプログラムに関する発表で、Rubyの表現力と楽しさを紹介するものでした。 中でも発表中に行われた一人 TRICK(Transcendental Ruby Imbroglio Contest for RubyKaigi)では、Most 〇〇 と名付けられたグラフィカルなコードが紹介され、会場は大盛りあがりでした！ 紹介されていたものは GitHub にて ソースコード が公開されています。 引用元: drive.google.com DAY1 rubykaigiB 「Long journey of Ruby standard library」 Hiroshi SHIBATA さんによる、Ruby の標準ライブラリとは何なのかと、その歴史についての発表でした。 引用元: speakerdeck.com 組み込みクラスと標準ライブラリの違い 組み込みクラスとは require しなくても使えるもので、標準ライブラリとは require しないと使えないものです。標準ライブラリの中には Ruby だけで書かれたものと C 拡張で書かれたものがあります。 歴史と傾向 Ruby の標準ライブラリの数は Ruby1.8 から減少傾向にあります。1.6 から 1.8 では数が増えたようですが、これはインターネットが常時接続ではなかったため、 gem install でインストールするより、Ruby をインストールしただけでたくさんの機能が使えたほうが良いのではという背景のもとに増えたとのことです。 default gems と bundled gems という概念の導入 default gems にコミットされたものは自動で Ruby 本体にもコミットされ、bundled gems にコミットされたものは Ruby 本体にコミットされないようになったそうです。 default gems や bundled gemsに関する活動をする理由は、セキュリティ対応と Ruby の持続可能性を高めるためとのことでした。 セキュリティ対応については、サプライチェーンアタックを防ぐために gem 同士の依存関係を少なくするようにしているそうです。これにより脆弱性対応時に単体のライブラリをアップデートするだけで済むようになり、結果として工数を削減することができるようになったのは開発者として大変ありがたいことだと思いました。 Ruby 自体の持続可能性については、Ruby にコミットしたい人に適切に権限を付与できるようにし、ライブラリ単体でも開発できる状態を目指すということだそうで、Ruby のこれからを支える人々の動きを促進する素晴らしいものだと感じました。 影響 default gems が bundled gems になる影響として、bundler の下で使う際に Gemfile に書かないと使えなくなってしまうことが紹介されました。default gems でもバージョン指定する際は Gemfile に書き込む必要があるようです。 これを解決するために、Ruby3.3 では警告機能が実装されました。 require "csv" などで実行すると、Ruby3.4 では bundled gems になる旨を伝える警告が出力されるというものです。これを元に Gemfile に情報を追加すれば良いので、対応がわかりやすくなったというメリットがあります。 また、自分が使っていないライブラリの警告だとしても、他のどのライブラリから呼び出されているのかも確認できるそうです。これを確認する際に、使っていないものであれば削除して依存関係を少なくする整理にも役立つそうです。 感想 引き続き bundled gems の数を増やして default gems の数を減らすことでメンテナンス性を高める方針のようなので、適宜分類をチェックして Gemfile への追加や Gem を使っているかの整理を進めて行きたいです。 DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」 Shunsuke Mori(kokuyou)さんによる、Ruby で大型言語モデル（LLM）を使用して RBS 型シグネチャを改良するツールである RBS Goose を作成されたことに関する発表でした。 引用元: slides.com RBS とは？ & 既存の RBS 作成手法 RBS とは、Ruby の型構造を定義するためのもので、型検査による安全な開発や補完の強化など開発体験を向上させる目的で使用されます。 既存の RBS 作成手法としては以下の 3 つが紹介されていました。 静的構文解析: 高速であるが推測できるものが少ない。attr_accessor などはメタプログラミングで生成されるものなので静的構文解析では RBS に出力されない。ruby にそもそも型情報がないので untyped になる。 動的ロード: ロード時にクラス全体が読み込まれ、その結果をリフレクションで RBS に書き出すことで、メタプログラミングで生成している attr_accessor のメソッドも定義される。しかし、こちらも型情報がないので untyped になる。 型レベル実行: 実行時の値を渡すときに型の情報を受け渡し、これをとっておいて RBS に出力する。コードを実際に動かす必要がある。 これらの手法では untyped を手作業で直したり、足りないものを補うのが大変であり、これを解決したい動機で RBS Goose を作成されたそうです。 RBS Goose の仕組み RBS Goose は RBS を生成する既存手法でネックになっていた untyped を手作業で直したり、足りないものを補う作業を LLM の力を借りて解決する仕組みのようでした。 RBS 生成の流れは以下のようになっています。 hoge.rb に対して静的構文解析などで hoge.rbs を作成 LLM の入力に使う prompt を組み立て この際に hoge.rb とは全く違う fuga.rb とそれを静的構文解析などで作った fuga.rbs と LLM に出力してほしいお手本の refined_fuga.rbs の 3 つを追加で入れる お手本を入れることで期待する答えを出しやすくする Few-shot プロンプティング という手法を採用している LLM に prompt を渡す RBS を出力 実用レベルにするには複数ファイルを扱えるようにする必要があり、それをどうするかの実現ビジョンについても語られていました。 LLM を使った開発の Tips 開発時の Tips が共有されていたのですが、その中でも特に学びになったのはテスト時の Tips でした。 従量課金のコストがかかる & 応答時間がかかるのでテストに時間がかかってしまうことを解決するために、 VCR のような Web モックを利用すると良いということ、 LLM の再現性確保のために Temperature（言語モデルの出力のランダム性を制御するパラメータのこと）の設定は 0 にすることがおすすめであるという Tips が共有されました。 感想 性能については割愛しますが、RBS Goose を用いてより良い RBS を得られると、補完の強化などで開発体験が向上することが期待できそうで、実用化が待ち遠しいです。 去年の Keynote で ChatGPT に型を推論させてもある程度形になることが語られていましたが、今年の発表で LLM を使用して型情報の定義をサポートするツールが発表されたことで、RBS への興味関心が大きくなりました！ Matz Keynote 今年の RubyKaigi 最後のセッションは Matz が担当しました。どうしたら Ruby をもっとよくできるかについての話では、パフォーマンス改善がキーになるというお話がありました。 パフォーマンス改善のために必要な要素は多岐にわたるため、これをコミュニティ全体で力を合わせて解決していく必要がある というメッセージや、カンファレンスで人々が話をしたことがきっかけでRubyGems が生まれたことから、コミュニティの人々が一緒に取り組めばもっとRuby を良くすることができるはずである というメッセージを受け、Ruby コミュニティの一員として胸の熱くなる想いでした。 メドレーブースに遊びに来てくれた Matz と スポンサー LT の様子 メドレーの LT 登壇は Matz の ClosingLT の直前ということもあり、会場が超満員に。登壇した VPoE の山﨑を応援しようと、サプライズで応援うちわを作っていったのですが、残念ながらあの大舞台からは見えなかったようです（笑） うちわは社内で活用させていただきます あそこまで大きな会場だと思ってなかった…！by 山﨑 LT で発表させていただきましたが、メドレーはコミュニティへの支援を行っています。6 月 13 日に約 1 年半ぶりの開催となる Roppongi.rb をスポンサードしており、メドレーオフィスで開催予定です。ご興味のある方はぜひご参加ください。 https://roppongirb.connpass.com/event/319768/ 私も地域 Ruby コミュニティに積極的に参加しようと思いますので、Ruby コミュニティを一緒に盛り上げていきましょう！ さいごに RubyKaigi 2024 に Ruby Sponsor として協賛した様子をお届けしました。 ブースやパーティーを通じて交流させていただいた皆様、Ruby とそのコミュニティの素晴らしさを存分に体感できるイベントを運営してくださった皆様に心より感謝いたします。 メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味を持っていただいた方からのご連絡をお待ちしております。 メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp

こんにちは。人材プラットフォーム本部プロダクト開発室 第五開発グループ所属の寺内です。 新卒からメドレーに入社して今年で 4 年目のエンジニアで、老人ホーム・介護施設の検索サイトである 介護のほんね の開発を担当しています。 メドレーは 5 月 15 日から 17 日に 沖縄県那覇市の 那覇文化芸術劇場なはーと にて開催された RubyKaigi 2024 に Ruby Sponsor として協賛しました！ RubyKaigi 2024 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。 エンジニアとエンジニア採用担当の計 12 名が現地参加し、たくさんの方々と交流させて頂きました。また、スポンサー LT もさせていただきました。 今回は会場・ブース・発表の様子と、スポンサー LT の内容をご紹介します。 会場の様子 会場となった那覇文化芸術劇場なはーとは、国際通りからほど近い場所でありながら閑静な市街地にありました。 沖縄らしさを感じさせる建築デザイン 建物内は 4 階まで吹き抜けとなっていて開放感が溢れている会場でしたが、セッション間はこのように各社のブースを訪問する人々でいっぱいになり、RubyKaigi の盛況ぶりを感じることができました。 なんと今年の来場者数は約 1400 人だったそうです！ RubyKaigi 2024 の公式配布グッズは、例年とは異なり T シャツではなくかりゆしとビーチサンダルでした！運営の粋な計らいのおかげで、会期中会場がカラフルでしたね。 2 日目から始まったスタンプラリーでは来場者のブース訪問がより活発になったのを感じました。ブースを巡ってスタンプを集めると限定バッジがもらえました。 バッジ交換時にスタッフさんが全力で拍手をしてくださるのでとても幸せな気持ちになりました！ 弊社ブースの様子 メドレーブースではうちわやビーチサンダルなどの沖縄らしいものをはじめ、医療事業を手がける企業のアピールとして絆創膏をノベルティとしてご用意しました。 靴擦れしてしまった方に絆創膏をお渡ししたらとても喜んでいただきました アンケートパネルを用いて参加者の方が抱えている医療体験のお悩みを伺いました。 伺ったお悩みからわかる課題に対してメドレーがプロダクトを通じてどのように向き合い・解決しているのかをご紹介しました。 特に回答が多かったのが 「待ち時間が」長い という課題でした。 メドレーの提供するオンライン診療・服薬指導アプリ「 CLINICS 」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、直近では Uber Eats との連携で服薬指導後30分程度で自宅までお薬を届けてもらうことも可能になったことをご説明すると、「ここまで便利になっていることは知らなかった！」と驚きのお声を多数いただきました。 会場の那覇付近でもこれだけの医療機関が見つかりました また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（ CLINICS 、 MALL 、 Pharms 、 Dentis ）を通じてサポートしていること、一つの課題に対して様々なアプローチをとっていることなどをお話ししました。 ツアー風 T シャツには今年メドレーがスポンサードしたイベントの一覧が掲載されています メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加したメドレーメンバー全員で 発表の様子 3 日間にわたってさまざまなセッションがありましたが、私が気になった以下のセッションについて少しご紹介します。 Keynote DAY1 rubykaigiB 「Long journey of Ruby standard library」 DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」 Matz Keynote Keynote 今年の Keynote は tomoya ishida さんによる「Writing Weird Code」という発表でした。 Quine というコードと実行結果が同じ内容になるプログラムに関する発表で、Rubyの表現力と楽しさを紹介するものでした。 中でも発表中に行われた一人 TRICK(Transcendental Ruby Imbroglio Contest for RubyKaigi)では、Most 〇〇 と名付けられたグラフィカルなコードが紹介され、会場は大盛りあがりでした！ 紹介されていたものは GitHub にて ソースコード が公開されています。 引用元: drive.google.com DAY1 rubykaigiB 「Long journey of Ruby standard library」 Hiroshi SHIBATA さんによる、Ruby の標準ライブラリとは何なのかと、その歴史についての発表でした。 引用元: speakerdeck.com 組み込みクラスと標準ライブラリの違い 組み込みクラスとは require しなくても使えるもので、標準ライブラリとは require しないと使えないものです。標準ライブラリの中には Ruby だけで書かれたものと C 拡張で書かれたものがあります。 歴史と傾向 Ruby の標準ライブラリの数は Ruby1.8 から減少傾向にあります。1.6 から 1.8 では数が増えたようですが、これはインターネットが常時接続ではなかったため、 gem install でインストールするより、Ruby をインストールしただけでたくさんの機能が使えたほうが良いのではという背景のもとに増えたとのことです。 default gems と bundled gems という概念の導入 default gems にコミットされたものは自動で Ruby 本体にもコミットされ、bundled gems にコミットされたものは Ruby 本体にコミットされないようになったそうです。 default gems や bundled gemsに関する活動をする理由は、セキュリティ対応と Ruby の持続可能性を高めるためとのことでした。 セキュリティ対応については、サプライチェーンアタックを防ぐために gem 同士の依存関係を少なくするようにしているそうです。これにより脆弱性対応時に単体のライブラリをアップデートするだけで済むようになり、結果として工数を削減することができるようになったのは開発者として大変ありがたいことだと思いました。 Ruby 自体の持続可能性については、Ruby にコミットしたい人に適切に権限を付与できるようにし、ライブラリ単体でも開発できる状態を目指すということだそうで、Ruby のこれからを支える人々の動きを促進する素晴らしいものだと感じました。 影響 default gems が bundled gems になる影響として、bundler の下で使う際に Gemfile に書かないと使えなくなってしまうことが紹介されました。default gems でもバージョン指定する際は Gemfile に書き込む必要があるようです。 これを解決するために、Ruby3.3 では警告機能が実装されました。 require "csv" などで実行すると、Ruby3.4 では bundled gems になる旨を伝える警告が出力されるというものです。これを元に Gemfile に情報を追加すれば良いので、対応がわかりやすくなったというメリットがあります。 また、自分が使っていないライブラリの警告だとしても、他のどのライブラリから呼び出されているのかも確認できるそうです。これを確認する際に、使っていないものであれば削除して依存関係を少なくする整理にも役立つそうです。 感想 引き続き bundled gems の数を増やして default gems の数を減らすことでメンテナンス性を高める方針のようなので、適宜分類をチェックして Gemfile への追加や Gem を使っているかの整理を進めて行きたいです。 DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」 Shunsuke Mori(kokuyou)さんによる、Ruby で大型言語モデル（LLM）を使用して RBS 型シグネチャを改良するツールである RBS Goose を作成されたことに関する発表でした。 引用元: slides.com RBS とは？ & 既存の RBS 作成手法 RBS とは、Ruby の型構造を定義するためのもので、型検査による安全な開発や補完の強化など開発体験を向上させる目的で使用されます。 既存の RBS 作成手法としては以下の 3 つが紹介されていました。 静的構文解析: 高速であるが推測できるものが少ない。attr_accessor などはメタプログラミングで生成されるものなので静的構文解析では RBS に出力されない。ruby にそもそも型情報がないので untyped になる。 動的ロード: ロード時にクラス全体が読み込まれ、その結果をリフレクションで RBS に書き出すことで、メタプログラミングで生成している attr_accessor のメソッドも定義される。しかし、こちらも型情報がないので untyped になる。 型レベル実行: 実行時の値を渡すときに型の情報を受け渡し、これをとっておいて RBS に出力する。コードを実際に動かす必要がある。 これらの手法では untyped を手作業で直したり、足りないものを補うのが大変であり、これを解決したい動機で RBS Goose を作成されたそうです。 RBS Goose の仕組み RBS Goose は RBS を生成する既存手法でネックになっていた untyped を手作業で直したり、足りないものを補う作業を LLM の力を借りて解決する仕組みのようでした。 RBS 生成の流れは以下のようになっています。 hoge.rb に対して静的構文解析などで hoge.rbs を作成 LLM の入力に使う prompt を組み立て この際に hoge.rb とは全く違う fuga.rb とそれを静的構文解析などで作った fuga.rbs と LLM に出力してほしいお手本の refined_fuga.rbs の 3 つを追加で入れる お手本を入れることで期待する答えを出しやすくする Few-shot プロンプティング という手法を採用している LLM に prompt を渡す RBS を出力 実用レベルにするには複数ファイルを扱えるようにする必要があり、それをどうするかの実現ビジョンについても語られていました。 LLM を使った開発の Tips 開発時の Tips が共有されていたのですが、その中でも特に学びになったのはテスト時の Tips でした。 従量課金のコストがかかる & 応答時間がかかるのでテストに時間がかかってしまうことを解決するために、 VCR のような Web モックを利用すると良いということ、 LLM の再現性確保のために Temperature（言語モデルの出力のランダム性を制御するパラメータのこと）の設定は 0 にすることがおすすめであるという Tips が共有されました。 感想 性能については割愛しますが、RBS Goose を用いてより良い RBS を得られると、補完の強化などで開発体験が向上することが期待できそうで、実用化が待ち遠しいです。 去年の Keynote で ChatGPT に型を推論させてもある程度形になることが語られていましたが、今年の発表で LLM を使用して型情報の定義をサポートするツールが発表されたことで、RBS への興味関心が大きくなりました！ Matz Keynote 今年の RubyKaigi 最後のセッションは Matz が担当しました。どうしたら Ruby をもっとよくできるかについての話では、パフォーマンス改善がキーになるというお話がありました。 パフォーマンス改善のために必要な要素は多岐にわたるため、これをコミュニティ全体で力を合わせて解決していく必要がある というメッセージや、カンファレンスで人々が話をしたことがきっかけでRubyGems が生まれたことから、コミュニティの人々が一緒に取り組めばもっとRuby を良くすることができるはずである というメッセージを受け、Ruby コミュニティの一員として胸の熱くなる想いでした。 メドレーブースに遊びに来てくれた Matz と スポンサー LT の様子 メドレーの LT 登壇は Matz の ClosingLT の直前ということもあり、会場が超満員に。登壇した VPoE の山﨑を応援しようと、サプライズで応援うちわを作っていったのですが、残念ながらあの大舞台からは見えなかったようです（笑） うちわは社内で活用させていただきます あそこまで大きな会場だと思ってなかった…！by 山﨑 LT で発表させていただきましたが、メドレーはコミュニティへの支援を行っています。6 月 13 日に約 1 年半ぶりの開催となる Roppongi.rb をスポンサードしており、メドレーオフィスで開催予定です。ご興味のある方はぜひご参加ください。 https://roppongirb.connpass.com/event/319768/ 私も地域 Ruby コミュニティに積極的に参加しようと思いますので、Ruby コミュニティを一緒に盛り上げていきましょう！ さいごに RubyKaigi 2024 に Ruby Sponsor として協賛した様子をお届けしました。 ブースやパーティーを通じて交流させていただいた皆様、Ruby とそのコミュニティの素晴らしさを存分に体感できるイベントを運営してくださった皆様に心より感謝いたします。 メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味を持っていただいた方からのご連絡をお待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。人材プラットフォーム本部プロダクト開発室 第五開発グループ所属の寺内です。 新卒からメドレーに入社して今年で 4 年目のエンジニアで、老人ホーム・介護施設の検索サイトである 介護のほんね の開発を担当しています。 メドレーは 5 月 15 日から 17 日に 沖縄県那覇市の 那覇文化芸術劇場なはーと にて開催された RubyKaigi 2024 に Ruby Sponsor として協賛しました！ RubyKaigi 2024 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。 エンジニアとエンジニア採用担当の計 12 名が現地参加し、たくさんの方々と交流させて頂きました。また、スポンサー LT もさせていただきました。 今回は会場・ブース・発表の様子と、スポンサー LT の内容をご紹介します。 会場の様子 会場となった那覇文化芸術劇場なはーとは、国際通りからほど近い場所でありながら閑静な市街地にありました。 沖縄らしさを感じさせる建築デザイン 建物内は 4 階まで吹き抜けとなっていて開放感が溢れている会場でしたが、セッション間はこのように各社のブースを訪問する人々でいっぱいになり、RubyKaigi の盛況ぶりを感じることができました。 なんと今年の来場者数は約 1400 人だったそうです！ RubyKaigi 2024 の公式配布グッズは、例年とは異なり T シャツではなくかりゆしとビーチサンダルでした！運営の粋な計らいのおかげで、会期中会場がカラフルでしたね。 2 日目から始まったスタンプラリーでは来場者のブース訪問がより活発になったのを感じました。ブースを巡ってスタンプを集めると限定バッジがもらえました。 バッジ交換時にスタッフさんが全力で拍手をしてくださるのでとても幸せな気持ちになりました！ 弊社ブースの様子 メドレーブースではうちわやビーチサンダルなどの沖縄らしいものをはじめ、医療事業を手がける企業のアピールとして絆創膏をノベルティとしてご用意しました。 靴擦れしてしまった方に絆創膏をお渡ししたらとても喜んでいただきました アンケートパネルを用いて参加者の方が抱えている医療体験のお悩みを伺いました。 伺ったお悩みからわかる課題に対してメドレーがプロダクトを通じてどのように向き合い・解決しているのかをご紹介しました。 特に回答が多かったのが 「待ち時間が」長い という課題でした。 メドレーの提供するオンライン診療・服薬指導アプリ「 CLINICS 」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、直近では Uber Eats との連携で服薬指導後30分程度で自宅までお薬を届けてもらうことも可能になったことをご説明すると、「ここまで便利になっていることは知らなかった！」と驚きのお声を多数いただきました。 会場の那覇付近でもこれだけの医療機関が見つかりました また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（ CLINICS 、 MALL 、 Pharms 、 Dentis ）を通じてサポートしていること、一つの課題に対して様々なアプローチをとっていることなどをお話ししました。 ツアー風 T シャツには今年メドレーがスポンサードしたイベントの一覧が掲載されています メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加したメドレーメンバー全員で 発表の様子 3 日間にわたってさまざまなセッションがありましたが、私が気になった以下のセッションについて少しご紹介します。 Keynote DAY1 rubykaigiB 「Long journey of Ruby standard library」 DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」 Matz Keynote Keynote 今年の Keynote は tomoya ishida さんによる「Writing Weird Code」という発表でした。 Quine というコードと実行結果が同じ内容になるプログラムに関する発表で、Rubyの表現力と楽しさを紹介するものでした。 中でも発表中に行われた一人 TRICK(Transcendental Ruby Imbroglio Contest for RubyKaigi)では、Most 〇〇 と名付けられたグラフィカルなコードが紹介され、会場は大盛りあがりでした！ 紹介されていたものは GitHub にて ソースコード が公開されています。 引用元: drive.google.com DAY1 rubykaigiB 「Long journey of Ruby standard library」 Hiroshi SHIBATA さんによる、Ruby の標準ライブラリとは何なのかと、その歴史についての発表でした。 引用元: speakerdeck.com 組み込みクラスと標準ライブラリの違い 組み込みクラスとは require しなくても使えるもので、標準ライブラリとは require しないと使えないものです。標準ライブラリの中には Ruby だけで書かれたものと C 拡張で書かれたものがあります。 歴史と傾向 Ruby の標準ライブラリの数は Ruby1.8 から減少傾向にあります。1.6 から 1.8 では数が増えたようですが、これはインターネットが常時接続ではなかったため、 gem install でインストールするより、Ruby をインストールしただけでたくさんの機能が使えたほうが良いのではという背景のもとに増えたとのことです。 default gems と bundled gems という概念の導入 default gems にコミットされたものは自動で Ruby 本体にもコミットされ、bundled gems にコミットされたものは Ruby 本体にコミットされないようになったそうです。 default gems や bundled gemsに関する活動をする理由は、セキュリティ対応と Ruby の持続可能性を高めるためとのことでした。 セキュリティ対応については、サプライチェーンアタックを防ぐために gem 同士の依存関係を少なくするようにしているそうです。これにより脆弱性対応時に単体のライブラリをアップデートするだけで済むようになり、結果として工数を削減することができるようになったのは開発者として大変ありがたいことだと思いました。 Ruby 自体の持続可能性については、Ruby にコミットしたい人に適切に権限を付与できるようにし、ライブラリ単体でも開発できる状態を目指すということだそうで、Ruby のこれからを支える人々の動きを促進する素晴らしいものだと感じました。 影響 default gems が bundled gems になる影響として、bundler の下で使う際に Gemfile に書かないと使えなくなってしまうことが紹介されました。default gems でもバージョン指定する際は Gemfile に書き込む必要があるようです。 これを解決するために、Ruby3.3 では警告機能が実装されました。 require "csv" などで実行すると、Ruby3.4 では bundled gems になる旨を伝える警告が出力されるというものです。これを元に Gemfile に情報を追加すれば良いので、対応がわかりやすくなったというメリットがあります。 また、自分が使っていないライブラリの警告だとしても、他のどのライブラリから呼び出されているのかも確認できるそうです。これを確認する際に、使っていないものであれば削除して依存関係を少なくする整理にも役立つそうです。 感想 引き続き bundled gems の数を増やして default gems の数を減らすことでメンテナンス性を高める方針のようなので、適宜分類をチェックして Gemfile への追加や Gem を使っているかの整理を進めて行きたいです。 DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」 Shunsuke Mori(kokuyou)さんによる、Ruby で大型言語モデル（LLM）を使用して RBS 型シグネチャを改良するツールである RBS Goose を作成されたことに関する発表でした。 引用元: slides.com RBS とは？ & 既存の RBS 作成手法 RBS とは、Ruby の型構造を定義するためのもので、型検査による安全な開発や補完の強化など開発体験を向上させる目的で使用されます。 既存の RBS 作成手法としては以下の 3 つが紹介されていました。 静的構文解析: 高速であるが推測できるものが少ない。attr_accessor などはメタプログラミングで生成されるものなので静的構文解析では RBS に出力されない。ruby にそもそも型情報がないので untyped になる。 動的ロード: ロード時にクラス全体が読み込まれ、その結果をリフレクションで RBS に書き出すことで、メタプログラミングで生成している attr_accessor のメソッドも定義される。しかし、こちらも型情報がないので untyped になる。 型レベル実行: 実行時の値を渡すときに型の情報を受け渡し、これをとっておいて RBS に出力する。コードを実際に動かす必要がある。 これらの手法では untyped を手作業で直したり、足りないものを補うのが大変であり、これを解決したい動機で RBS Goose を作成されたそうです。 RBS Goose の仕組み RBS Goose は RBS を生成する既存手法でネックになっていた untyped を手作業で直したり、足りないものを補う作業を LLM の力を借りて解決する仕組みのようでした。 RBS 生成の流れは以下のようになっています。 hoge.rb に対して静的構文解析などで hoge.rbs を作成 LLM の入力に使う prompt を組み立て この際に hoge.rb とは全く違う fuga.rb とそれを静的構文解析などで作った fuga.rbs と LLM に出力してほしいお手本の refined_fuga.rbs の 3 つを追加で入れる お手本を入れることで期待する答えを出しやすくする Few-shot プロンプティング という手法を採用している LLM に prompt を渡す RBS を出力 実用レベルにするには複数ファイルを扱えるようにする必要があり、それをどうするかの実現ビジョンについても語られていました。 LLM を使った開発の Tips 開発時の Tips が共有されていたのですが、その中でも特に学びになったのはテスト時の Tips でした。 従量課金のコストがかかる & 応答時間がかかるのでテストに時間がかかってしまうことを解決するために、 VCR のような Web モックを利用すると良いということ、 LLM の再現性確保のために Temperature（言語モデルの出力のランダム性を制御するパラメータのこと）の設定は 0 にすることがおすすめであるという Tips が共有されました。 感想 性能については割愛しますが、RBS Goose を用いてより良い RBS を得られると、補完の強化などで開発体験が向上することが期待できそうで、実用化が待ち遠しいです。 去年の Keynote で ChatGPT に型を推論させてもある程度形になることが語られていましたが、今年の発表で LLM を使用して型情報の定義をサポートするツールが発表されたことで、RBS への興味関心が大きくなりました！ Matz Keynote 今年の RubyKaigi 最後のセッションは Matz が担当しました。どうしたら Ruby をもっとよくできるかについての話では、パフォーマンス改善がキーになるというお話がありました。 パフォーマンス改善のために必要な要素は多岐にわたるため、これをコミュニティ全体で力を合わせて解決していく必要がある というメッセージや、カンファレンスで人々が話をしたことがきっかけでRubyGems が生まれたことから、コミュニティの人々が一緒に取り組めばもっとRuby を良くすることができるはずである というメッセージを受け、Ruby コミュニティの一員として胸の熱くなる想いでした。 メドレーブースに遊びに来てくれた Matz と スポンサー LT の様子 メドレーの LT 登壇は Matz の ClosingLT の直前ということもあり、会場が超満員に。登壇した VPoE の山﨑を応援しようと、サプライズで応援うちわを作っていったのですが、残念ながらあの大舞台からは見えなかったようです（笑） うちわは社内で活用させていただきます あそこまで大きな会場だと思ってなかった…！by 山﨑 LT で発表させていただきましたが、メドレーはコミュニティへの支援を行っています。6 月 13 日に約 1 年半ぶりの開催となる Roppongi.rb をスポンサードしており、メドレーオフィスで開催予定です。ご興味のある方はぜひご参加ください。 https://roppongirb.connpass.com/event/319768/ 私も地域 Ruby コミュニティに積極的に参加しようと思いますので、Ruby コミュニティを一緒に盛り上げていきましょう！ さいごに RubyKaigi 2024 に Ruby Sponsor として協賛した様子をお届けしました。 ブースやパーティーを通じて交流させていただいた皆様、Ruby とそのコミュニティの素晴らしさを存分に体感できるイベントを運営してくださった皆様に心より感謝いたします。 メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味を持っていただいた方からのご連絡をお待ちしております。 https://www.medley.jp/jobs/

こんにちは。人材プラットフォーム本部プロダクト開発室 第五開発グループ所属の寺内です。 新卒からメドレーに入社して今年で 4 年目のエンジニアで、老人ホーム・介護施設の検索サイトである 介護のほんね の開発を担当しています。 メドレーは 5 月 15 日から 17 日に 沖縄県那覇市の 那覇文化芸術劇場なはーと にて開催された RubyKaigi 2024 に Ruby Sponsor として協賛しました！ RubyKaigi 2024 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。 エンジニアとエンジニア採用担当の計 12 名が現地参加し、たくさんの方々と交流させて頂きました。また、スポンサー LT もさせていただきました。 今回は会場・ブース・発表の様子と、スポンサー LT の内容をご紹介します。 会場の様子 会場となった那覇文化芸術劇場なはーとは、国際通りからほど近い場所でありながら閑静な市街地にありました。 沖縄らしさを感じさせる建築デザイン 建物内は 4 階まで吹き抜けとなっていて開放感が溢れている会場でしたが、セッション間はこのように各社のブースを訪問する人々でいっぱいになり、RubyKaigi の盛況ぶりを感じることができました。 なんと今年の来場者数は約 1400 人だったそうです！ RubyKaigi 2024 の公式配布グッズは、例年とは異なり T シャツではなくかりゆしとビーチサンダルでした！運営の粋な計らいのおかげで、会期中会場がカラフルでしたね。 2 日目から始まったスタンプラリーでは来場者のブース訪問がより活発になったのを感じました。ブースを巡ってスタンプを集めると限定バッジがもらえました。 バッジ交換時にスタッフさんが全力で拍手をしてくださるのでとても幸せな気持ちになりました！ 弊社ブースの様子 メドレーブースではうちわやビーチサンダルなどの沖縄らしいものをはじめ、医療事業を手がける企業のアピールとして絆創膏をノベルティとしてご用意しました。 靴擦れしてしまった方に絆創膏をお渡ししたらとても喜んでいただきました アンケートパネルを用いて参加者の方が抱えている医療体験のお悩みを伺いました。 伺ったお悩みからわかる課題に対してメドレーがプロダクトを通じてどのように向き合い・解決しているのかをご紹介しました。 特に回答が多かったのが 「待ち時間が」長い という課題でした。 メドレーの提供するオンライン診療・服薬指導アプリ「 CLINICS 」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、直近では Uber Eats との連携で服薬指導後30分程度で自宅までお薬を届けてもらうことも可能になったことをご説明すると、「ここまで便利になっていることは知らなかった！」と驚きのお声を多数いただきました。 会場の那覇付近でもこれだけの医療機関が見つかりました また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（ CLINICS 、 MALL 、 Pharms 、 Dentis ）を通じてサポートしていること、一つの課題に対して様々なアプローチをとっていることなどをお話ししました。 ツアー風 T シャツには今年メドレーがスポンサードしたイベントの一覧が掲載されています メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加したメドレーメンバー全員で 発表の様子 3 日間にわたってさまざまなセッションがありましたが、私が気になった以下のセッションについて少しご紹介します。 Keynote DAY1 rubykaigiB 「Long journey of Ruby standard library」 DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」 Matz Keynote Keynote 今年の Keynote は tomoya ishida さんによる「Writing Weird Code」という発表でした。 Quine というコードと実行結果が同じ内容になるプログラムに関する発表で、Rubyの表現力と楽しさを紹介するものでした。 中でも発表中に行われた一人 TRICK(Transcendental Ruby Imbroglio Contest for RubyKaigi)では、Most 〇〇 と名付けられたグラフィカルなコードが紹介され、会場は大盛りあがりでした！ 紹介されていたものは GitHub にて ソースコード が公開されています。 引用元: drive.google.com DAY1 rubykaigiB 「Long journey of Ruby standard library」 Hiroshi SHIBATA さんによる、Ruby の標準ライブラリとは何なのかと、その歴史についての発表でした。 引用元: speakerdeck.com 組み込みクラスと標準ライブラリの違い 組み込みクラスとは require しなくても使えるもので、標準ライブラリとは require しないと使えないものです。標準ライブラリの中には Ruby だけで書かれたものと C 拡張で書かれたものがあります。 歴史と傾向 Ruby の標準ライブラリの数は Ruby1.8 から減少傾向にあります。1.6 から 1.8 では数が増えたようですが、これはインターネットが常時接続ではなかったため、 gem install でインストールするより、Ruby をインストールしただけでたくさんの機能が使えたほうが良いのではという背景のもとに増えたとのことです。 default gems と bundled gems という概念の導入 default gems にコミットされたものは自動で Ruby 本体にもコミットされ、bundled gems にコミットされたものは Ruby 本体にコミットされないようになったそうです。 default gems や bundled gemsに関する活動をする理由は、セキュリティ対応と Ruby の持続可能性を高めるためとのことでした。 セキュリティ対応については、サプライチェーンアタックを防ぐために gem 同士の依存関係を少なくするようにしているそうです。これにより脆弱性対応時に単体のライブラリをアップデートするだけで済むようになり、結果として工数を削減することができるようになったのは開発者として大変ありがたいことだと思いました。 Ruby 自体の持続可能性については、Ruby にコミットしたい人に適切に権限を付与できるようにし、ライブラリ単体でも開発できる状態を目指すということだそうで、Ruby のこれからを支える人々の動きを促進する素晴らしいものだと感じました。 影響 default gems が bundled gems になる影響として、bundler の下で使う際に Gemfile に書かないと使えなくなってしまうことが紹介されました。default gems でもバージョン指定する際は Gemfile に書き込む必要があるようです。 これを解決するために、Ruby3.3 では警告機能が実装されました。 require "csv" などで実行すると、Ruby3.4 では bundled gems になる旨を伝える警告が出力されるというものです。これを元に Gemfile に情報を追加すれば良いので、対応がわかりやすくなったというメリットがあります。 また、自分が使っていないライブラリの警告だとしても、他のどのライブラリから呼び出されているのかも確認できるそうです。これを確認する際に、使っていないものであれば削除して依存関係を少なくする整理にも役立つそうです。 感想 引き続き bundled gems の数を増やして default gems の数を減らすことでメンテナンス性を高める方針のようなので、適宜分類をチェックして Gemfile への追加や Gem を使っているかの整理を進めて行きたいです。 DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」 Shunsuke Mori(kokuyou)さんによる、Ruby で大型言語モデル（LLM）を使用して RBS 型シグネチャを改良するツールである RBS Goose を作成されたことに関する発表でした。 引用元: slides.com RBS とは？ & 既存の RBS 作成手法 RBS とは、Ruby の型構造を定義するためのもので、型検査による安全な開発や補完の強化など開発体験を向上させる目的で使用されます。 既存の RBS 作成手法としては以下の 3 つが紹介されていました。 静的構文解析: 高速であるが推測できるものが少ない。attr_accessor などはメタプログラミングで生成されるものなので静的構文解析では RBS に出力されない。ruby にそもそも型情報がないので untyped になる。 動的ロード: ロード時にクラス全体が読み込まれ、その結果をリフレクションで RBS に書き出すことで、メタプログラミングで生成している attr_accessor のメソッドも定義される。しかし、こちらも型情報がないので untyped になる。 型レベル実行: 実行時の値を渡すときに型の情報を受け渡し、これをとっておいて RBS に出力する。コードを実際に動かす必要がある。 これらの手法では untyped を手作業で直したり、足りないものを補うのが大変であり、これを解決したい動機で RBS Goose を作成されたそうです。 RBS Goose の仕組み RBS Goose は RBS を生成する既存手法でネックになっていた untyped を手作業で直したり、足りないものを補う作業を LLM の力を借りて解決する仕組みのようでした。 RBS 生成の流れは以下のようになっています。 hoge.rb に対して静的構文解析などで hoge.rbs を作成 LLM の入力に使う prompt を組み立て この際に hoge.rb とは全く違う fuga.rb とそれを静的構文解析などで作った fuga.rbs と LLM に出力してほしいお手本の refined_fuga.rbs の 3 つを追加で入れる お手本を入れることで期待する答えを出しやすくする Few-shot プロンプティング という手法を採用している LLM に prompt を渡す RBS を出力 実用レベルにするには複数ファイルを扱えるようにする必要があり、それをどうするかの実現ビジョンについても語られていました。 LLM を使った開発の Tips 開発時の Tips が共有されていたのですが、その中でも特に学びになったのはテスト時の Tips でした。 従量課金のコストがかかる & 応答時間がかかるのでテストに時間がかかってしまうことを解決するために、 VCR のような Web モックを利用すると良いということ、 LLM の再現性確保のために Temperature（言語モデルの出力のランダム性を制御するパラメータのこと）の設定は 0 にすることがおすすめであるという Tips が共有されました。 感想 性能については割愛しますが、RBS Goose を用いてより良い RBS を得られると、補完の強化などで開発体験が向上することが期待できそうで、実用化が待ち遠しいです。 去年の Keynote で ChatGPT に型を推論させてもある程度形になることが語られていましたが、今年の発表で LLM を使用して型情報の定義をサポートするツールが発表されたことで、RBS への興味関心が大きくなりました！ Matz Keynote 今年の RubyKaigi 最後のセッションは Matz が担当しました。どうしたら Ruby をもっとよくできるかについての話では、パフォーマンス改善がキーになるというお話がありました。 パフォーマンス改善のために必要な要素は多岐にわたるため、これをコミュニティ全体で力を合わせて解決していく必要がある というメッセージや、カンファレンスで人々が話をしたことがきっかけでRubyGems が生まれたことから、コミュニティの人々が一緒に取り組めばもっとRuby を良くすることができるはずである というメッセージを受け、Ruby コミュニティの一員として胸の熱くなる想いでした。 メドレーブースに遊びに来てくれた Matz と スポンサー LT の様子 メドレーの LT 登壇は Matz の ClosingLT の直前ということもあり、会場が超満員に。登壇した VPoE の山﨑を応援しようと、サプライズで応援うちわを作っていったのですが、残念ながらあの大舞台からは見えなかったようです（笑） うちわは社内で活用させていただきます あそこまで大きな会場だと思ってなかった…！by 山﨑 LT で発表させていただきましたが、メドレーはコミュニティへの支援を行っています。6 月 13 日に約 1 年半ぶりの開催となる Roppongi.rb をスポンサードしており、メドレーオフィスで開催予定です。ご興味のある方はぜひご参加ください。 https://roppongirb.connpass.com/event/319768/ 私も地域 Ruby コミュニティに積極的に参加しようと思いますので、Ruby コミュニティを一緒に盛り上げていきましょう！ さいごに RubyKaigi 2024 に Ruby Sponsor として協賛した様子をお届けしました。 ブースやパーティーを通じて交流させていただいた皆様、Ruby とそのコミュニティの素晴らしさを存分に体感できるイベントを運営してくださった皆様に心より感謝いたします。 メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味を持っていただいた方からのご連絡をお待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。人材プラットフォーム本部プロダクト開発室 第五開発グループ所属の寺内です。 新卒からメドレーに入社して今年で 4 年目のエンジニアで、老人ホーム・介護施設の検索サイトである 介護のほんね の開発を担当しています。 メドレーは 5 月 15 日から 17 日に 沖縄県那覇市の 那覇文化芸術劇場なはーと にて開催された RubyKaigi 2024 に Ruby Sponsor として協賛しました！ RubyKaigi 2024 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。 エンジニアとエンジニア採用担当の計 12 名が現地参加し、たくさんの方々と交流させて頂きました。また、スポンサー LT もさせていただきました。 今回は会場・ブース・発表の様子と、スポンサー LT の内容をご紹介します。 会場の様子 会場となった那覇文化芸術劇場なはーとは、国際通りからほど近い場所でありながら閑静な市街地にありました。 沖縄らしさを感じさせる建築デザイン 建物内は 4 階まで吹き抜けとなっていて開放感が溢れている会場でしたが、セッション間はこのように各社のブースを訪問する人々でいっぱいになり、RubyKaigi の盛況ぶりを感じることができました。 なんと今年の来場者数は約 1400 人だったそうです！ RubyKaigi 2024 の公式配布グッズは、例年とは異なり T シャツではなくかりゆしとビーチサンダルでした！運営の粋な計らいのおかげで、会期中会場がカラフルでしたね。 2 日目から始まったスタンプラリーでは来場者のブース訪問がより活発になったのを感じました。ブースを巡ってスタンプを集めると限定バッジがもらえました。 バッジ交換時にスタッフさんが全力で拍手をしてくださるのでとても幸せな気持ちになりました！ 弊社ブースの様子 メドレーブースではうちわやビーチサンダルなどの沖縄らしいものをはじめ、医療事業を手がける企業のアピールとして絆創膏をノベルティとしてご用意しました。 靴擦れしてしまった方に絆創膏をお渡ししたらとても喜んでいただきました アンケートパネルを用いて参加者の方が抱えている医療体験のお悩みを伺いました。 伺ったお悩みからわかる課題に対してメドレーがプロダクトを通じてどのように向き合い・解決しているのかをご紹介しました。 特に回答が多かったのが 「待ち時間が」長い という課題でした。 メドレーの提供するオンライン診療・服薬指導アプリ「 CLINICS 」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、直近では Uber Eats との連携で服薬指導後30分程度で自宅までお薬を届けてもらうことも可能になったことをご説明すると、「ここまで便利になっていることは知らなかった！」と驚きのお声を多数いただきました。 会場の那覇付近でもこれだけの医療機関が見つかりました また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（ CLINICS 、 MALL 、 Pharms 、 Dentis ）を通じてサポートしていること、一つの課題に対して様々なアプローチをとっていることなどをお話ししました。 ツアー風 T シャツには今年メドレーがスポンサードしたイベントの一覧が掲載されています メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加したメドレーメンバー全員で 発表の様子 3 日間にわたってさまざまなセッションがありましたが、私が気になった以下のセッションについて少しご紹介します。 Keynote DAY1 rubykaigiB 「Long journey of Ruby standard library」 DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」 Matz Keynote Keynote 今年の Keynote は tomoya ishida さんによる「Writing Weird Code」という発表でした。 Quine というコードと実行結果が同じ内容になるプログラムに関する発表で、Rubyの表現力と楽しさを紹介するものでした。 中でも発表中に行われた一人 TRICK(Transcendental Ruby Imbroglio Contest for RubyKaigi)では、Most 〇〇 と名付けられたグラフィカルなコードが紹介され、会場は大盛りあがりでした！ 紹介されていたものは GitHub にて ソースコード が公開されています。 引用元: drive.google.com DAY1 rubykaigiB 「Long journey of Ruby standard library」 Hiroshi SHIBATA さんによる、Ruby の標準ライブラリとは何なのかと、その歴史についての発表でした。 引用元: speakerdeck.com 組み込みクラスと標準ライブラリの違い 組み込みクラスとは require しなくても使えるもので、標準ライブラリとは require しないと使えないものです。標準ライブラリの中には Ruby だけで書かれたものと C 拡張で書かれたものがあります。 歴史と傾向 Ruby の標準ライブラリの数は Ruby1.8 から減少傾向にあります。1.6 から 1.8 では数が増えたようですが、これはインターネットが常時接続ではなかったため、 gem install でインストールするより、Ruby をインストールしただけでたくさんの機能が使えたほうが良いのではという背景のもとに増えたとのことです。 default gems と bundled gems という概念の導入 default gems にコミットされたものは自動で Ruby 本体にもコミットされ、bundled gems にコミットされたものは Ruby 本体にコミットされないようになったそうです。 default gems や bundled gemsに関する活動をする理由は、セキュリティ対応と Ruby の持続可能性を高めるためとのことでした。 セキュリティ対応については、サプライチェーンアタックを防ぐために gem 同士の依存関係を少なくするようにしているそうです。これにより脆弱性対応時に単体のライブラリをアップデートするだけで済むようになり、結果として工数を削減することができるようになったのは開発者として大変ありがたいことだと思いました。 Ruby 自体の持続可能性については、Ruby にコミットしたい人に適切に権限を付与できるようにし、ライブラリ単体でも開発できる状態を目指すということだそうで、Ruby のこれからを支える人々の動きを促進する素晴らしいものだと感じました。 影響 default gems が bundled gems になる影響として、bundler の下で使う際に Gemfile に書かないと使えなくなってしまうことが紹介されました。default gems でもバージョン指定する際は Gemfile に書き込む必要があるようです。 これを解決するために、Ruby3.3 では警告機能が実装されました。 require "csv" などで実行すると、Ruby3.4 では bundled gems になる旨を伝える警告が出力されるというものです。これを元に Gemfile に情報を追加すれば良いので、対応がわかりやすくなったというメリットがあります。 また、自分が使っていないライブラリの警告だとしても、他のどのライブラリから呼び出されているのかも確認できるそうです。これを確認する際に、使っていないものであれば削除して依存関係を少なくする整理にも役立つそうです。 感想 引き続き bundled gems の数を増やして default gems の数を減らすことでメンテナンス性を高める方針のようなので、適宜分類をチェックして Gemfile への追加や Gem を使っているかの整理を進めて行きたいです。 DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」 Shunsuke Mori(kokuyou)さんによる、Ruby で大型言語モデル（LLM）を使用して RBS 型シグネチャを改良するツールである RBS Goose を作成されたことに関する発表でした。 引用元: slides.com RBS とは？ & 既存の RBS 作成手法 RBS とは、Ruby の型構造を定義するためのもので、型検査による安全な開発や補完の強化など開発体験を向上させる目的で使用されます。 既存の RBS 作成手法としては以下の 3 つが紹介されていました。 静的構文解析: 高速であるが推測できるものが少ない。attr_accessor などはメタプログラミングで生成されるものなので静的構文解析では RBS に出力されない。ruby にそもそも型情報がないので untyped になる。 動的ロード: ロード時にクラス全体が読み込まれ、その結果をリフレクションで RBS に書き出すことで、メタプログラミングで生成している attr_accessor のメソッドも定義される。しかし、こちらも型情報がないので untyped になる。 型レベル実行: 実行時の値を渡すときに型の情報を受け渡し、これをとっておいて RBS に出力する。コードを実際に動かす必要がある。 これらの手法では untyped を手作業で直したり、足りないものを補うのが大変であり、これを解決したい動機で RBS Goose を作成されたそうです。 RBS Goose の仕組み RBS Goose は RBS を生成する既存手法でネックになっていた untyped を手作業で直したり、足りないものを補う作業を LLM の力を借りて解決する仕組みのようでした。 RBS 生成の流れは以下のようになっています。 hoge.rb に対して静的構文解析などで hoge.rbs を作成 LLM の入力に使う prompt を組み立て この際に hoge.rb とは全く違う fuga.rb とそれを静的構文解析などで作った fuga.rbs と LLM に出力してほしいお手本の refined_fuga.rbs の 3 つを追加で入れる お手本を入れることで期待する答えを出しやすくする Few-shot プロンプティング という手法を採用している LLM に prompt を渡す RBS を出力 実用レベルにするには複数ファイルを扱えるようにする必要があり、それをどうするかの実現ビジョンについても語られていました。 LLM を使った開発の Tips 開発時の Tips が共有されていたのですが、その中でも特に学びになったのはテスト時の Tips でした。 従量課金のコストがかかる & 応答時間がかかるのでテストに時間がかかってしまうことを解決するために、 VCR のような Web モックを利用すると良いということ、 LLM の再現性確保のために Temperature（言語モデルの出力のランダム性を制御するパラメータのこと）の設定は 0 にすることがおすすめであるという Tips が共有されました。 感想 性能については割愛しますが、RBS Goose を用いてより良い RBS を得られると、補完の強化などで開発体験が向上することが期待できそうで、実用化が待ち遠しいです。 去年の Keynote で ChatGPT に型を推論させてもある程度形になることが語られていましたが、今年の発表で LLM を使用して型情報の定義をサポートするツールが発表されたことで、RBS への興味関心が大きくなりました！ Matz Keynote 今年の RubyKaigi 最後のセッションは Matz が担当しました。どうしたら Ruby をもっとよくできるかについての話では、パフォーマンス改善がキーになるというお話がありました。 パフォーマンス改善のために必要な要素は多岐にわたるため、これをコミュニティ全体で力を合わせて解決していく必要がある というメッセージや、カンファレンスで人々が話をしたことがきっかけでRubyGems が生まれたことから、コミュニティの人々が一緒に取り組めばもっとRuby を良くすることができるはずである というメッセージを受け、Ruby コミュニティの一員として胸の熱くなる想いでした。 メドレーブースに遊びに来てくれた Matz と スポンサー LT の様子 メドレーの LT 登壇は Matz の ClosingLT の直前ということもあり、会場が超満員に。登壇した VPoE の山﨑を応援しようと、サプライズで応援うちわを作っていったのですが、残念ながらあの大舞台からは見えなかったようです（笑） うちわは社内で活用させていただきます あそこまで大きな会場だと思ってなかった…！by 山﨑 LT で発表させていただきましたが、メドレーはコミュニティへの支援を行っています。6 月 13 日に約 1 年半ぶりの開催となる Roppongi.rb をスポンサードしており、メドレーオフィスで開催予定です。ご興味のある方はぜひご参加ください。 https://roppongirb.connpass.com/event/319768/ 私も地域 Ruby コミュニティに積極的に参加しようと思いますので、Ruby コミュニティを一緒に盛り上げていきましょう！ さいごに RubyKaigi 2024 に Ruby Sponsor として協賛した様子をお届けしました。 ブースやパーティーを通じて交流させていただいた皆様、Ruby とそのコミュニティの素晴らしさを存分に体感できるイベントを運営してくださった皆様に心より感謝いたします。 メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味を持っていただいた方からのご連絡をお待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。人材プラットフォーム本部プロダクト開発室 第五開発グループ所属の寺内です。 新卒からメドレーに入社して今年で 4 年目のエンジニアで、老人ホーム・介護施設の検索サイトである 介護のほんね の開発を担当しています。 メドレーは 5 月 15 日から 17 日に 沖縄県那覇市の 那覇文化芸術劇場なはーと にて開催された RubyKaigi 2024 に Ruby Sponsor として協賛しました！ RubyKaigi 2024 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。 エンジニアとエンジニア採用担当の計 12 名が現地参加し、たくさんの方々と交流させて頂きました。また、スポンサー LT もさせていただきました。 今回は会場・ブース・発表の様子と、スポンサー LT の内容をご紹介します。 会場の様子 会場となった那覇文化芸術劇場なはーとは、国際通りからほど近い場所でありながら閑静な市街地にありました。 沖縄らしさを感じさせる建築デザイン 建物内は 4 階まで吹き抜けとなっていて開放感が溢れている会場でしたが、セッション間はこのように各社のブースを訪問する人々でいっぱいになり、RubyKaigi の盛況ぶりを感じることができました。 なんと今年の来場者数は約 1400 人だったそうです！ RubyKaigi 2024 の公式配布グッズは、例年とは異なり T シャツではなくかりゆしとビーチサンダルでした！運営の粋な計らいのおかげで、会期中会場がカラフルでしたね。 2 日目から始まったスタンプラリーでは来場者のブース訪問がより活発になったのを感じました。ブースを巡ってスタンプを集めると限定バッジがもらえました。 バッジ交換時にスタッフさんが全力で拍手をしてくださるのでとても幸せな気持ちになりました！ 弊社ブースの様子 メドレーブースではうちわやビーチサンダルなどの沖縄らしいものをはじめ、医療事業を手がける企業のアピールとして絆創膏をノベルティとしてご用意しました。 靴擦れしてしまった方に絆創膏をお渡ししたらとても喜んでいただきました アンケートパネルを用いて参加者の方が抱えている医療体験のお悩みを伺いました。 伺ったお悩みからわかる課題に対してメドレーがプロダクトを通じてどのように向き合い・解決しているのかをご紹介しました。 特に回答が多かったのが 「待ち時間が」長い という課題でした。 メドレーの提供するオンライン診療・服薬指導アプリ「 CLINICS 」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、直近では Uber Eats との連携で服薬指導後30分程度で自宅までお薬を届けてもらうことも可能になったことをご説明すると、「ここまで便利になっていることは知らなかった！」と驚きのお声を多数いただきました。 会場の那覇付近でもこれだけの医療機関が見つかりました また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（ CLINICS 、 MALL 、 Pharms 、 Dentis ）を通じてサポートしていること、一つの課題に対して様々なアプローチをとっていることなどをお話ししました。 ツアー風 T シャツには今年メドレーがスポンサードしたイベントの一覧が掲載されています メドレーブースにお越しいただいた皆様、ありがとうございました！ 参加したメドレーメンバー全員で 発表の様子 3 日間にわたってさまざまなセッションがありましたが、私が気になった以下のセッションについて少しご紹介します。 Keynote DAY1 rubykaigiB 「Long journey of Ruby standard library」 DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」 Matz Keynote Keynote 今年の Keynote は tomoya ishida さんによる「Writing Weird Code」という発表でした。 Quine というコードと実行結果が同じ内容になるプログラムに関する発表で、Rubyの表現力と楽しさを紹介するものでした。 中でも発表中に行われた一人 TRICK(Transcendental Ruby Imbroglio Contest for RubyKaigi)では、Most 〇〇 と名付けられたグラフィカルなコードが紹介され、会場は大盛りあがりでした！ 紹介されていたものは GitHub にて ソースコード が公開されています。 引用元: drive.google.com DAY1 rubykaigiB 「Long journey of Ruby standard library」 Hiroshi SHIBATA さんによる、Ruby の標準ライブラリとは何なのかと、その歴史についての発表でした。 引用元: speakerdeck.com 組み込みクラスと標準ライブラリの違い 組み込みクラスとは require しなくても使えるもので、標準ライブラリとは require しないと使えないものです。標準ライブラリの中には Ruby だけで書かれたものと C 拡張で書かれたものがあります。 歴史と傾向 Ruby の標準ライブラリの数は Ruby1.8 から減少傾向にあります。1.6 から 1.8 では数が増えたようですが、これはインターネットが常時接続ではなかったため、 gem install でインストールするより、Ruby をインストールしただけでたくさんの機能が使えたほうが良いのではという背景のもとに増えたとのことです。 default gems と bundled gems という概念の導入 default gems にコミットされたものは自動で Ruby 本体にもコミットされ、bundled gems にコミットされたものは Ruby 本体にコミットされないようになったそうです。 default gems や bundled gemsに関する活動をする理由は、セキュリティ対応と Ruby の持続可能性を高めるためとのことでした。 セキュリティ対応については、サプライチェーンアタックを防ぐために gem 同士の依存関係を少なくするようにしているそうです。これにより脆弱性対応時に単体のライブラリをアップデートするだけで済むようになり、結果として工数を削減することができるようになったのは開発者として大変ありがたいことだと思いました。 Ruby 自体の持続可能性については、Ruby にコミットしたい人に適切に権限を付与できるようにし、ライブラリ単体でも開発できる状態を目指すということだそうで、Ruby のこれからを支える人々の動きを促進する素晴らしいものだと感じました。 影響 default gems が bundled gems になる影響として、bundler の下で使う際に Gemfile に書かないと使えなくなってしまうことが紹介されました。default gems でもバージョン指定する際は Gemfile に書き込む必要があるようです。 これを解決するために、Ruby3.3 では警告機能が実装されました。 require "csv" などで実行すると、Ruby3.4 では bundled gems になる旨を伝える警告が出力されるというものです。これを元に Gemfile に情報を追加すれば良いので、対応がわかりやすくなったというメリットがあります。 また、自分が使っていないライブラリの警告だとしても、他のどのライブラリから呼び出されているのかも確認できるそうです。これを確認する際に、使っていないものであれば削除して依存関係を少なくする整理にも役立つそうです。 感想 引き続き bundled gems の数を増やして default gems の数を減らすことでメンテナンス性を高める方針のようなので、適宜分類をチェックして Gemfile への追加や Gem を使っているかの整理を進めて行きたいです。 DAY2 rubykaigiB 「Let’s use LLMs from Ruby 〜 Refine RBS types using LLM 〜」 Shunsuke Mori(kokuyou)さんによる、Ruby で大型言語モデル（LLM）を使用して RBS 型シグネチャを改良するツールである RBS Goose を作成されたことに関する発表でした。 引用元: slides.com RBS とは？ & 既存の RBS 作成手法 RBS とは、Ruby の型構造を定義するためのもので、型検査による安全な開発や補完の強化など開発体験を向上させる目的で使用されます。 既存の RBS 作成手法としては以下の 3 つが紹介されていました。 静的構文解析: 高速であるが推測できるものが少ない。attr_accessor などはメタプログラミングで生成されるものなので静的構文解析では RBS に出力されない。ruby にそもそも型情報がないので untyped になる。 動的ロード: ロード時にクラス全体が読み込まれ、その結果をリフレクションで RBS に書き出すことで、メタプログラミングで生成している attr_accessor のメソッドも定義される。しかし、こちらも型情報がないので untyped になる。 型レベル実行: 実行時の値を渡すときに型の情報を受け渡し、これをとっておいて RBS に出力する。コードを実際に動かす必要がある。 これらの手法では untyped を手作業で直したり、足りないものを補うのが大変であり、これを解決したい動機で RBS Goose を作成されたそうです。 RBS Goose の仕組み RBS Goose は RBS を生成する既存手法でネックになっていた untyped を手作業で直したり、足りないものを補う作業を LLM の力を借りて解決する仕組みのようでした。 RBS 生成の流れは以下のようになっています。 hoge.rb に対して静的構文解析などで hoge.rbs を作成 LLM の入力に使う prompt を組み立て この際に hoge.rb とは全く違う fuga.rb とそれを静的構文解析などで作った fuga.rbs と LLM に出力してほしいお手本の refined_fuga.rbs の 3 つを追加で入れる お手本を入れることで期待する答えを出しやすくする Few-shot プロンプティング という手法を採用している LLM に prompt を渡す RBS を出力 実用レベルにするには複数ファイルを扱えるようにする必要があり、それをどうするかの実現ビジョンについても語られていました。 LLM を使った開発の Tips 開発時の Tips が共有されていたのですが、その中でも特に学びになったのはテスト時の Tips でした。 従量課金のコストがかかる & 応答時間がかかるのでテストに時間がかかってしまうことを解決するために、 VCR のような Web モックを利用すると良いということ、 LLM の再現性確保のために Temperature（言語モデルの出力のランダム性を制御するパラメータのこと）の設定は 0 にすることがおすすめであるという Tips が共有されました。 感想 性能については割愛しますが、RBS Goose を用いてより良い RBS を得られると、補完の強化などで開発体験が向上することが期待できそうで、実用化が待ち遠しいです。 去年の Keynote で ChatGPT に型を推論させてもある程度形になることが語られていましたが、今年の発表で LLM を使用して型情報の定義をサポートするツールが発表されたことで、RBS への興味関心が大きくなりました！ Matz Keynote 今年の RubyKaigi 最後のセッションは Matz が担当しました。どうしたら Ruby をもっとよくできるかについての話では、パフォーマンス改善がキーになるというお話がありました。 パフォーマンス改善のために必要な要素は多岐にわたるため、これをコミュニティ全体で力を合わせて解決していく必要がある というメッセージや、カンファレンスで人々が話をしたことがきっかけでRubyGems が生まれたことから、コミュニティの人々が一緒に取り組めばもっとRuby を良くすることができるはずである というメッセージを受け、Ruby コミュニティの一員として胸の熱くなる想いでした。 メドレーブースに遊びに来てくれた Matz と スポンサー LT の様子 メドレーの LT 登壇は Matz の ClosingLT の直前ということもあり、会場が超満員に。登壇した VPoE の山﨑を応援しようと、サプライズで応援うちわを作っていったのですが、残念ながらあの大舞台からは見えなかったようです（笑） うちわは社内で活用させていただきます あそこまで大きな会場だと思ってなかった…！by 山﨑 LT で発表させていただきましたが、メドレーはコミュニティへの支援を行っています。6 月 13 日に約 1 年半ぶりの開催となる Roppongi.rb をスポンサードしており、メドレーオフィスで開催予定です。ご興味のある方はぜひご参加ください。 https://roppongirb.connpass.com/event/319768/ 私も地域 Ruby コミュニティに積極的に参加しようと思いますので、Ruby コミュニティを一緒に盛り上げていきましょう！ さいごに RubyKaigi 2024 に Ruby Sponsor として協賛した様子をお届けしました。 ブースやパーティーを通じて交流させていただいた皆様、Ruby とそのコミュニティの素晴らしさを存分に体感できるイベントを運営してくださった皆様に心より感謝いたします。 メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味を持っていただいた方からのご連絡をお待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。 メドレーは 5 月 11 日に中野セントラルパークカンファレンスにて開催された TSKaigi 2024 に Gold Sponsor として協賛しました！ TSKaigi は、今年から開催された日本最大級の TypeScript をテーマとした技術カンファレンスです。 エンジニアの徳永と吉岡、髙橋の計 3 名が現地参加し、たくさんの方々と交流させて頂きました。 今回はスポンサー LT とブースの様子をご紹介します。 スポンサー LT スポンサー LT セッションでは、「チームで挑む TypeScript コードの漸進的改善」というテーマで髙橋が発表しました。 発表では、 クラウド診療支援システム CLINICS の Web フロントエンドのコードを「typescript-eslint のルール読み合わせ会」を通じて改善している取り組みについて紹介しました。 詳細は次の発表資料にまとめていますので、是非ご覧ください。 ブースの様子 ブースでは、ノベルティの絆創膏、うちわ、パンフレットなどを配布しながら、メドレーのプロダクトや開発文化を紹介しました。 また、医療 UX の「ここなんとかならない？」をテーマに、参加者の方々が抱える医療体験のお悩みをパネル投票する企画を実施しました。 その結果、待ち時間の長さ、問診票の非効率性、予約に関連する 3 つのお悩みが特に多くの投票を集めました。 メドレーが提供する オンライン診療・服薬指導アプリ CLINICS では、インターネットを通じて、自宅や職場から診察、服薬指導を受けることができるので、これらのお悩みを解決することができます！ 機会があれば是非ご活用ください。 さいごに TSKaigi に協賛した様子をお届けしました。 LT セッションやブースにお越しくださった皆様、ありがとうございました！ そして何よりも、素晴らしいカンファレンスを企画・開催して頂いた運営スタッフの皆様、本当にありがとうございました！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味がある方からのご連絡をお待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。 メドレーは 5 月 11 日に中野セントラルパークカンファレンスにて開催された TSKaigi 2024 に Gold Sponsor として協賛しました！ TSKaigi は、今年から開催された日本最大級の TypeScript をテーマとした技術カンファレンスです。 エンジニアの徳永と吉岡、髙橋の計 3 名が現地参加し、たくさんの方々と交流させて頂きました。 今回はスポンサー LT とブースの様子をご紹介します。 スポンサー LT スポンサー LT セッションでは、「チームで挑む TypeScript コードの漸進的改善」というテーマで髙橋が発表しました。 発表では、 クラウド診療支援システム CLINICS の Web フロントエンドのコードを「typescript-eslint のルール読み合わせ会」を通じて改善している取り組みについて紹介しました。 詳細は次の発表資料にまとめていますので、是非ご覧ください。 ブースの様子 ブースでは、ノベルティの絆創膏、うちわ、パンフレットなどを配布しながら、メドレーのプロダクトや開発文化を紹介しました。 また、医療 UX の「ここなんとかならない？」をテーマに、参加者の方々が抱える医療体験のお悩みをパネル投票する企画を実施しました。 その結果、待ち時間の長さ、問診票の非効率性、予約に関連する 3 つのお悩みが特に多くの投票を集めました。 メドレーが提供する オンライン診療・服薬指導アプリ CLINICS では、インターネットを通じて、自宅や職場から診察、服薬指導を受けることができるので、これらのお悩みを解決することができます！ 機会があれば是非ご活用ください。 さいごに TSKaigi に協賛した様子をお届けしました。 LT セッションやブースにお越しくださった皆様、ありがとうございました！ そして何よりも、素晴らしいカンファレンスを企画・開催して頂いた運営スタッフの皆様、本当にありがとうございました！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味がある方からのご連絡をお待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。 メドレーは 5 月 11 日に中野セントラルパークカンファレンスにて開催された TSKaigi 2024 に Gold Sponsor として協賛しました！ TSKaigi は、今年から開催された日本最大級の TypeScript をテーマとした技術カンファレンスです。 エンジニアの徳永と吉岡、髙橋の計 3 名が現地参加し、たくさんの方々と交流させて頂きました。 今回はスポンサー LT とブースの様子をご紹介します。 スポンサー LT スポンサー LT セッションでは、「チームで挑む TypeScript コードの漸進的改善」というテーマで髙橋が発表しました。 発表では、 クラウド診療支援システム CLINICS の Web フロントエンドのコードを「typescript-eslint のルール読み合わせ会」を通じて改善している取り組みについて紹介しました。 詳細は次の発表資料にまとめていますので、是非ご覧ください。 ブースの様子 ブースでは、ノベルティの絆創膏、うちわ、パンフレットなどを配布しながら、メドレーのプロダクトや開発文化を紹介しました。 また、医療 UX の「ここなんとかならない？」をテーマに、参加者の方々が抱える医療体験のお悩みをパネル投票する企画を実施しました。 その結果、待ち時間の長さ、問診票の非効率性、予約に関連する 3 つのお悩みが特に多くの投票を集めました。 メドレーが提供する オンライン診療・服薬指導アプリ CLINICS では、インターネットを通じて、自宅や職場から診察、服薬指導を受けることができるので、これらのお悩みを解決することができます！ 機会があれば是非ご活用ください。 さいごに TSKaigi に協賛した様子をお届けしました。 LT セッションやブースにお越しくださった皆様、ありがとうございました！ そして何よりも、素晴らしいカンファレンスを企画・開催して頂いた運営スタッフの皆様、本当にありがとうございました！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味がある方からのご連絡をお待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。 メドレーは 5 月 11 日に中野セントラルパークカンファレンスにて開催された TSKaigi 2024 に Gold Sponsor として協賛しました！ TSKaigi は、今年から開催された日本最大級の TypeScript をテーマとした技術カンファレンスです。 エンジニアの徳永と吉岡、髙橋の計 3 名が現地参加し、たくさんの方々と交流させて頂きました。 今回はスポンサー LT とブースの様子をご紹介します。 スポンサー LT スポンサー LT セッションでは、「チームで挑む TypeScript コードの漸進的改善」というテーマで髙橋が発表しました。 発表では、 クラウド診療支援システム CLINICS の Web フロントエンドのコードを「typescript-eslint のルール読み合わせ会」を通じて改善している取り組みについて紹介しました。 詳細は次の発表資料にまとめていますので、是非ご覧ください。 ブースの様子 ブースでは、ノベルティの絆創膏、うちわ、パンフレットなどを配布しながら、メドレーのプロダクトや開発文化を紹介しました。 また、医療 UX の「ここなんとかならない？」をテーマに、参加者の方々が抱える医療体験のお悩みをパネル投票する企画を実施しました。 その結果、待ち時間の長さ、問診票の非効率性、予約に関連する 3 つのお悩みが特に多くの投票を集めました。 メドレーが提供する オンライン診療・服薬指導アプリ CLINICS では、インターネットを通じて、自宅や職場から診察、服薬指導を受けることができるので、これらのお悩みを解決することができます！ 機会があれば是非ご活用ください。 さいごに TSKaigi に協賛した様子をお届けしました。 LT セッションやブースにお越しくださった皆様、ありがとうございました！ そして何よりも、素晴らしいカンファレンスを企画・開催して頂いた運営スタッフの皆様、本当にありがとうございました！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味がある方からのご連絡をお待ちしております。 メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp

こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。 メドレーは 5 月 11 日に中野セントラルパークカンファレンスにて開催された TSKaigi 2024 に Gold Sponsor として協賛しました！ TSKaigi は、今年から開催された日本最大級の TypeScript をテーマとした技術カンファレンスです。 エンジニアの徳永と吉岡、髙橋の計 3 名が現地参加し、たくさんの方々と交流させて頂きました。 今回はスポンサー LT とブースの様子をご紹介します。 スポンサー LT スポンサー LT セッションでは、「チームで挑む TypeScript コードの漸進的改善」というテーマで髙橋が発表しました。 発表では、 クラウド診療支援システム CLINICS の Web フロントエンドのコードを「typescript-eslint のルール読み合わせ会」を通じて改善している取り組みについて紹介しました。 詳細は次の発表資料にまとめていますので、是非ご覧ください。 ブースの様子 ブースでは、ノベルティの絆創膏、うちわ、パンフレットなどを配布しながら、メドレーのプロダクトや開発文化を紹介しました。 また、医療 UX の「ここなんとかならない？」をテーマに、参加者の方々が抱える医療体験のお悩みをパネル投票する企画を実施しました。 その結果、待ち時間の長さ、問診票の非効率性、予約に関連する 3 つのお悩みが特に多くの投票を集めました。 メドレーが提供する オンライン診療・服薬指導アプリ CLINICS では、インターネットを通じて、自宅や職場から診察、服薬指導を受けることができるので、これらのお悩みを解決することができます！ 機会があれば是非ご活用ください。 さいごに TSKaigi に協賛した様子をお届けしました。 LT セッションやブースにお越しくださった皆様、ありがとうございました！ そして何よりも、素晴らしいカンファレンスを企画・開催して頂いた運営スタッフの皆様、本当にありがとうございました！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味がある方からのご連絡をお待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。 メドレーは 5 月 11 日に中野セントラルパークカンファレンスにて開催された TSKaigi 2024 に Gold Sponsor として協賛しました！ TSKaigi は、今年から開催された日本最大級の TypeScript をテーマとした技術カンファレンスです。 エンジニアの徳永と吉岡、髙橋の計 3 名が現地参加し、たくさんの方々と交流させて頂きました。 今回はスポンサー LT とブースの様子をご紹介します。 スポンサー LT スポンサー LT セッションでは、「チームで挑む TypeScript コードの漸進的改善」というテーマで髙橋が発表しました。 発表では、 クラウド診療支援システム CLINICS の Web フロントエンドのコードを「typescript-eslint のルール読み合わせ会」を通じて改善している取り組みについて紹介しました。 詳細は次の発表資料にまとめていますので、是非ご覧ください。 ブースの様子 ブースでは、ノベルティの絆創膏、うちわ、パンフレットなどを配布しながら、メドレーのプロダクトや開発文化を紹介しました。 また、医療 UX の「ここなんとかならない？」をテーマに、参加者の方々が抱える医療体験のお悩みをパネル投票する企画を実施しました。 その結果、待ち時間の長さ、問診票の非効率性、予約に関連する 3 つのお悩みが特に多くの投票を集めました。 メドレーが提供する オンライン診療・服薬指導アプリ CLINICS では、インターネットを通じて、自宅や職場から診察、服薬指導を受けることができるので、これらのお悩みを解決することができます！ 機会があれば是非ご活用ください。 さいごに TSKaigi に協賛した様子をお届けしました。 LT セッションやブースにお越しくださった皆様、ありがとうございました！ そして何よりも、素晴らしいカンファレンスを企画・開催して頂いた運営スタッフの皆様、本当にありがとうございました！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味がある方からのご連絡をお待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。 メドレーは 5 月 11 日に中野セントラルパークカンファレンスにて開催された TSKaigi 2024 に Gold Sponsor として協賛しました！ TSKaigi は、今年から開催された日本最大級の TypeScript をテーマとした技術カンファレンスです。 エンジニアの徳永と吉岡、髙橋の計 3 名が現地参加し、たくさんの方々と交流させて頂きました。 今回はスポンサー LT とブースの様子をご紹介します。 スポンサー LT スポンサー LT セッションでは、「チームで挑む TypeScript コードの漸進的改善」というテーマで髙橋が発表しました。 発表では、 クラウド診療支援システム CLINICS の Web フロントエンドのコードを「typescript-eslint のルール読み合わせ会」を通じて改善している取り組みについて紹介しました。 詳細は次の発表資料にまとめていますので、是非ご覧ください。 ブースの様子 ブースでは、ノベルティの絆創膏、うちわ、パンフレットなどを配布しながら、メドレーのプロダクトや開発文化を紹介しました。 また、医療 UX の「ここなんとかならない？」をテーマに、参加者の方々が抱える医療体験のお悩みをパネル投票する企画を実施しました。 その結果、待ち時間の長さ、問診票の非効率性、予約に関連する 3 つのお悩みが特に多くの投票を集めました。 メドレーが提供する オンライン診療・服薬指導アプリ CLINICS では、インターネットを通じて、自宅や職場から診察、服薬指導を受けることができるので、これらのお悩みを解決することができます！ 機会があれば是非ご活用ください。 さいごに TSKaigi に協賛した様子をお届けしました。 LT セッションやブースにお越しくださった皆様、ありがとうございました！ そして何よりも、素晴らしいカンファレンスを企画・開催して頂いた運営スタッフの皆様、本当にありがとうございました！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味がある方からのご連絡をお待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。 メドレーは 5 月 11 日に中野セントラルパークカンファレンスにて開催された TSKaigi 2024 に Gold Sponsor として協賛しました！ TSKaigi は、今年から開催された日本最大級の TypeScript をテーマとした技術カンファレンスです。 エンジニアの徳永と吉岡、髙橋の計 3 名が現地参加し、たくさんの方々と交流させて頂きました。 今回はスポンサー LT とブースの様子をご紹介します。 スポンサー LT スポンサー LT セッションでは、「チームで挑む TypeScript コードの漸進的改善」というテーマで髙橋が発表しました。 発表では、 クラウド診療支援システム CLINICS の Web フロントエンドのコードを「typescript-eslint のルール読み合わせ会」を通じて改善している取り組みについて紹介しました。 詳細は次の発表資料にまとめていますので、是非ご覧ください。 ブースの様子 ブースでは、ノベルティの絆創膏、うちわ、パンフレットなどを配布しながら、メドレーのプロダクトや開発文化を紹介しました。 また、医療 UX の「ここなんとかならない？」をテーマに、参加者の方々が抱える医療体験のお悩みをパネル投票する企画を実施しました。 その結果、待ち時間の長さ、問診票の非効率性、予約に関連する 3 つのお悩みが特に多くの投票を集めました。 メドレーが提供する オンライン診療・服薬指導アプリ CLINICS では、インターネットを通じて、自宅や職場から診察、服薬指導を受けることができるので、これらのお悩みを解決することができます！ 機会があれば是非ご活用ください。 さいごに TSKaigi に協賛した様子をお届けしました。 LT セッションやブースにお越しくださった皆様、ありがとうございました！ そして何よりも、素晴らしいカンファレンスを企画・開催して頂いた運営スタッフの皆様、本当にありがとうございました！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味がある方からのご連絡をお待ちしております。 https://www.medley.jp/jobs/

こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。 メドレーは 5 月 11 日に中野セントラルパークカンファレンスにて開催された TSKaigi 2024 に Gold Sponsor として協賛しました！ TSKaigi は、今年から開催された日本最大級の TypeScript をテーマとした技術カンファレンスです。 エンジニアの徳永と吉岡、髙橋の計 3 名が現地参加し、たくさんの方々と交流させて頂きました。 今回はスポンサー LT とブースの様子をご紹介します。 スポンサー LT スポンサー LT セッションでは、「チームで挑む TypeScript コードの漸進的改善」というテーマで髙橋が発表しました。 発表では、 クラウド診療支援システム CLINICS の Web フロントエンドのコードを「typescript-eslint のルール読み合わせ会」を通じて改善している取り組みについて紹介しました。 詳細は次の発表資料にまとめていますので、是非ご覧ください。 ブースの様子 ブースでは、ノベルティの絆創膏、うちわ、パンフレットなどを配布しながら、メドレーのプロダクトや開発文化を紹介しました。 また、医療 UX の「ここなんとかならない？」をテーマに、参加者の方々が抱える医療体験のお悩みをパネル投票する企画を実施しました。 その結果、待ち時間の長さ、問診票の非効率性、予約に関連する 3 つのお悩みが特に多くの投票を集めました。 メドレーが提供する オンライン診療・服薬指導アプリ CLINICS では、インターネットを通じて、自宅や職場から診察、服薬指導を受けることができるので、これらのお悩みを解決することができます！ 機会があれば是非ご活用ください。 さいごに TSKaigi に協賛した様子をお届けしました。 LT セッションやブースにお越しくださった皆様、ありがとうございました！ そして何よりも、素晴らしいカンファレンスを企画・開催して頂いた運営スタッフの皆様、本当にありがとうございました！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味がある方からのご連絡をお待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。今回は 2022 年新卒入社したエンジニア達にインタビューした記事をお送りします。 この 1 年で彼らがどのような業務を経験してきたのかや、リアルな現在の立ち位置などをお伝えしたいと考えています。 それでは、ご覧ください! 自己紹介 飯田さん 研修後は ジョブメドレー で顧客向けの機能開発を担当。その後 シゴトーク でインフラ領域を中心にリニューアルに従事する。現在は Jobley で施策の開発やインフラ周りまで幅広く業務を担当。 飯田さん 岡田さん 研修後はジョブメドレーでの開発業務を担当後、シゴトークへ。ジョブメドレーとの連携強化のプロジェクトなど経験し、現在はシゴトークの開発全般を担当。 岡田さん 徳永さん 研修後は ジョブメドレーアカデミー に配属。プロダクト改善などを担当しつつ、直近では生成 AI を使った機能の開発やバックエンドからモバイルまで幅広い開発に従事。 徳永さん 古川さん 研修後は Pharms に配属。フロントエンドからインフラまで幅広く担当。小規模施策の開発に始まり現在は中規模施策のプロジェクトリードをしながら開発を行なう。 古川さん 村上さん 研修後は CLINICS に配属。電子カルテ関連の開発を経て、現在は中規模施策のプロジェクトリードをしながら開発を行なう。 村上さん 吉岡さん 研修後は 患者アプリ CLINICS に配属。Web アプリとネイティブアプリの機能開発を担当した後、CLINICS に配属。現在は定常改善や、フロントエンドの大規模改修などに従事。 吉岡さん ファーストキャリアとしてメドレーを選んだ理由について ── まずはファーストキャリアにメドレーへ入社を決めた理由をお伺いしていきたいと思います。 飯田 : 元々ベンチャー気質が高いことを軸に会社選びをしていました。新卒入社の社員が多数いるような規模が大きい会社だと、自分がその中に埋もれてしまい、自由度が高い動きができなさそうだと考えていたからです。メドレーは新卒が少ないのでその辺りはマッチしていました。医療という領域に関しても、 日常生活に関わるところで社会に貢献できるような領域が良いなと考えていたことや、家族が看護師をやっていることもあり医療業界の課題を身近に感じられ、医療に対して興味があった ことが理由になっています。 岡田 : 自分の体調が悪くなることが昔から多かったためヘルスケア業界に興味があったのですが、そこに近い業界だったのがひとつの理由です。また会社のミッションがとても分かりやすかったというのがあります。他社に比べて、メドレーは 世の中を良くしてくという会社のビジョンに、ちゃんと基づいてプロダクトを開発している んだなというのが具体的に分かって一貫性を感じられたのが大きいです。 他には、「エンジニア」という職種だともちろん技術分野が専門領域になっていくわけですが、その領域に閉じず、プロダクトを中心に課題解決する上でエンジニアリング以外のことも考えながら開発をしているプロダクトファーストな考えも魅力的でした。 徳永 : 自分は岡田くんのように特にヘルスケア領域に興味があったということはなかったんです。どちらかというと、 エンジニアとしてこれから働いていく上で自分が大切にしたい志向や価値観というのが、メドレーのエンジニアの方達と話をしていく中でマッチする なと感じたのが大きいです。 それまでも色々な会社さんとの選考をしていたんですが、メドレーのエンジニアは「本質を追い求める」という姿勢の元、エンジニアリングが好きで、それをプロダクトへ還元していくという部分が自分のフィーリングにあったという感じでした。 ── フィーリングに合ったということですが、他にもマッチすると思った部分はありましたか? 徳永 : エンジニアの雰囲気も大人な感じの方が多く、体育会系の「気合と根性で頑張る」という進め方ではなく、合理的に物事を進めるために必要なコミュニケーションをきちんと取っていくところなどが魅力でした。そうした部分も含めて自分が働いている将来というのが想像できました。 古川 : 自分は親が薬剤師で医療分野に元々興味があり、医療 x IT という軸で就活をしていく過程でメドレーを知ったのが最初の出会いでした。お話を聞いていくうちに「課題解決のためのプロダクト作り」という点が非常に魅力に感じました。社会を良くするためにプロダクトを良くしていこうという姿勢で会社に一体感が生まれているのが、すごく良いなと。 会社に限らないかもしれないですが、組織も人が多くなってくるとやっぱり方向性が少しずつズレていくという感じになりがちだと思うんですが、メドレーの場合は 会社として「医療業界をもっと良くしていくための事業をしていく」という軸が通っている のを感じて、最終的にはこの部分に惹かれて入社を決めました。 あとは、上場企業という「安心感」もファーストキャリアの選択に影響しました。 岡田 : 自分も新卒入社の社員目線だと、入社する会社の安定感というのは重要だと思っていました。 村上 : 就活する前は特定の業界に限らず色々な会社を見ていました。学生時代に様々な業界のエンジニアインターンやアルバイトなどしていたのですが、その過程で「せっかく正社員で働くなら、より社会的意義がある事業をやるべきだな」と感じました。そうした意識で就活に臨んで 自分が興味を持って取り組めそうなのは医療業界だなと思った のが最初のきっかけでした。 メドレーは選考の中で、技術領域を問わずに開発できることなどがマッチすると感じたのと、サービスが医療機関だけでなく患者側も充実しているということも入社の決め手になりました。自分が患者になることも多いので、とても課題が分かりやすかったんです。 吉岡 : 自分も元々エンタメなどの領域より、医療や教育、金融領域を中心に就活をしていました。中でもメドレーの「医療ヘルスケアの未来をつくる」というミッションへの自分の共感度が非常に高かったのが、入社の理由でした。日本の医療制度をきちんと維持するためのプロダクトを作っていくんだという姿勢が非常に良かったです。 またさきほどの話にも出ていましたが、 医療機関のためのプロダクトと患者のためのプロダクトという両面へのアプローチをしている のも決め手でした。やはり医療費の問題などは医療機関だけへのアプローチでは解決できないと思うので、そういう意味でも一貫性が感じられて良かったです。 現在のチーム内での役割について ── では次に現在のチームでの皆さんの役割や動き方、チームメンバーとの関わり方について聞いていきたいと思います。 飯田 : 現在 Jobley の開発チームではエンジニアが 4 人いるのですが、その内 2 人がプロダクト施策の立案を行ないつつ、自分を含む残りの 2 人が実装をメインにして開発を行なっています。状況に合わせ PM 兼任のエンジニアと実装担当のエンジニアとで二人三脚で開発をしたり、単独での開発を行なったりと柔軟に対応していってます。 チームメンバーとの関わりという点では、 エンジニアチームだけで開発するということはなく、セールスやカスタマーサクセスの方たちと一緒に要件を詰めていく ことが最近は多いです。そのためセールスの業務フローなどもキャッチアップする必要があるので大変ですが、面白くやりがいを感じるところでもありますね。 岡田 : シゴトークでは、PM とエンジニアの二人三脚という体制で開発をしています。PM と日々要件を刷り合わせながら、実装は自分が行なっていていくというスタイルです。Pull Request のレビューだけは元々シゴトークを開発されていたエンジニアの方々にお願いしています。 また、例えばプロダクトのセキュリティ強化の取り組みやアプリの認証機能の一新、QA 環境の整備など、自分が普段触れない領域の施策を行った際はスキルアップを実感できました。ライブラリのアップデートや、リファクタリングなども 裁量を持ってやらせてもらっています 。 徳永 : ジョブメドレーアカデミーはジョブメドレーや CLINICS に比べると小規模なチーム構成となっています。エンジニアが 7 人、PM が 3 人、プロダクトオーナーが 1 人という体制で開発をしてるのですが、 良い意味で新卒入社エンジニアとして裁量を持って開発をさせてもらっています 。 開発チームも徐々に大きくなっているので、タスクを上手く回すための仕組みを考えたり、チームを上手く機能させるために朝会の構成を変更してみたり。技術的な部分では CI/CD など開発全体に関わる分野についても、任せてもらっています。 また ニュースリリース にもなりましたが、社内で初めての 生成 AI を使った機能の開発 は、プロダクトオーナーと自分の 2 人が中心になって進めていきました。 開発に入る前段階でロジカルに「こういった課題をこの機能で解決していく」ということが伝えられれば、ある程度技術的に実験的なものも導入することができる環境です 。 古川 : Pharms では現在エンジニアが 4 人、PM 1 人、デザイナーが 1 人というのが中心メンバーとなっています。Pharms は現在色々と機能拡大をしていっているのですが、エンジニアが 4 人なので本当に全員で何でもやっていくという感じで開発しています。とはいえ、メンバー各々で得意分野は違うので、得意なところは積極的に拾いに行く感じです。 自分はと言うと、得意分野のインフラ部分に関してはほとんど任せてもらっており、自分からの発信で先輩のテックリードエンジニアの方とすり合わせしながら色々な施策を行なっています。その他にもクォーター毎に数個は中・大規模な施策が計画されるので、そうしたもののいくつかのリードをさせてもらったりしています。ですので、 アプリケーションの開発という面でもプロジェクトを上手く進行させるという面でも、とても楽しく業務をしています 。 村上 : CLINICS ではまず「基幹」と「周辺」とざっくり 2 つのチームに分かれており、「基幹」が主にレセコン(レセプトコンピュータの略。医療施設から健康保険組合などの支払い機関に対し、診療報酬を請求するために、電子カルテと連動してレセプトと呼ばれる診療報酬明細書を作成するシステム)とのやりとりを、「周辺」では予約や問診、資格確認など CLINICS と患者との接点となるシステム、という形で担当業務が分かれています。自分はずっと基幹チームにアサインされています。チーム全対応のエンジニアの内訳はアプリケーション担当が 6~7 人、インフラ担当が 3 人ほどになっています。 現在は大きなプロジェクトが 1 つ進行していて、既存のレセコンをメドレーで新規開発しているレセコンに移行するというものですが、その中に 中規模なプロジェクトが複数平行して進んでいて、その内のいくつかを自分がリード させてもらっています。 リードしているプロジェクトの進行管理やチームメンバー間での問題共有方法などを考えているのですが、この辺りは挑戦できる幅が広く、難しいですが面白いと感じています。課題についてプロジェクトに限定せず、他のシステムや進捗状況に影響がないかを配慮する必要があり、そうした視点で適切に異なる立場の関係者を巻き込むことで、より包括的な解決策を導き出そうと意識をしています。 吉岡 : 自分は今は村上と一緒のチームで業務をしているんですが、レセコンなどの部分というよりは、先程の話の「周辺」の開発をすることが多いです。基本的に平行して複数のプロジェクトが走っており、それぞれのプロジェクトでディレクター 1 人、エンジニア数人、他にデザイナーという形で進めていくことが多いです。 大まかにディレクターが要件などをまとめたものをベースとして、その後にデザイナーやエンジニアも入って要件定義などをしていき、徐々に形にしていくという事が多いですね。 ── お二人で組んで仕事をすることもあるんですか? 村上 : はい、とても多いです。 進行しているプロジェクトの他にも、定常改善やバグ改修などのタスクがありますが、そうしたタスクを「どのタイミングで」「どの優先度で」対応していくかなどをチーム内で議論してから実施するので。 吉岡 : プロジェクトやそうしたタスクとは別に、エンジニア主導で大規模なリファクタリングなども行なっています。担当しているプロジェクトの他にそうしたものを手がけていて、一緒になることが多いです。 入社してメドレーの文化を強く意識した出来事 ── メドレーで働いている中で、特に文化を強く感じたエピソードなど聞いてみたいです。 飯田 : 開発に関係する人全員が「プロダクト志向が強い」ということでしょうか。具体的には、開発の要件定義段階から全員関わるので、もちろんビジネスサイドの方からも「こうした方が良いのではないか」というアイデアは出てきますが、開発サイドからも「どういう機能が一番ユーザに価値を届けられるか」という視点で一緒になって考えるんです。そもそもどういった課題を解決するものなのかという基礎の部分から一緒に考えていくのがメドレーでは当たり前になっているという感じがします。 開発サイドもビジネスサイドも同じ方向を向いているので、提案などもちゃんとロジカルで筋が通っているものであれば通るというのは、すごく意見しがいがある と思います。そのための相談なんかも、もちろんしやすいですし、とても良い文化だなと感じています。 岡田 : 開発にあたって PM が 施策などを Issue として立ててくれるのですが、言語化が行き届いていて何が問題で、どうして実施するのか、その影響なんかがすごく分かりやすいという点はメドレーが大事にしている「ドキュメントドリブン」という文化を感じます。 そのような環境なので、大抵のことは最低限の文章のやり取りだけでスムーズに進みますし、上手くいかない状況になっても善後策などが立てやすくなっていると思います。 徳永 : メドレーは新卒入社の社員数は少ないので、中途入社の方がほとんどという環境です。入社してすぐは「自分の意見は通るのかな」とか「自分より後に入社した経験年数が長い中途入社の方とどう付き合おう」などが心配でした。でも メドレーでは「建設的に進める」という文化があるので、立場に関係なく議論できる環境があるので、とても仕事がしやすい です。自分の意見が例え間違っていたとしても議論が起きるということは、認識がズレていたということだからと軌道修正もできるので本当に働きやすいです。 また、とても良いなと思ったのが、部署や職種に関わらず Confluence の情報に誰でもアクセスできるという文化ですね。秘匿情報以外は基本的に全て Confluence でオープンになっているおかげで、自分とは直接関係ない部署の現在の動きなどがキャッチアップできるので、そういった人たちとコミュニケーションを取るときにもすごく助かります。 古川 : 徳永とかぶるところがあるんですが、「建設的に進める」という部分は非常にメドレーらしさを感じる文化です。例えば PM が「施策をこうしましょう」となっても、自分が「このフローってこうなった方が良いですよね」という意見を言えるし、そこを起点に 議論に発展してより良いものを作っていけるというのは本当に素晴らしい と感じています。 実際に自分がリードしていた施策の中でもエンジニア・ デザイナー・ PM ・カスタマーサクセスという立場が違うメンバー同士で改めて薬局の業務フローを整理しなおして、より良い仕様にできたりということがありました。 機能リリース後もちゃんと「あるべき姿」を目指して改善をできたりしたので、こういう考え方はとても仕事がしやすいです。 村上 : 自分からは「組織水準を高める」という文化について言及させてください。自分が関わっている電子カルテやレセコンという領域は深い業務知識が必要で、初めて関わった人からすると、そもそもどういうフローで機能が使われているかとか、特定の場合に何でこうなるんだろうというところが、理解しづらいんです。でも、自分のチームは新卒・中途問わず、まだ深いドメイン知識がない、といった状態からでも入って活躍しやすい環境だというのを感じています。 いきなり専門の業務知識が必要な開発というのはやはり難しいので、そうした部分と直接は関係しない周辺領域の開発から始めてもらって、徐々に電子カルテやレセコンに直接関係する開発に入ってもらえるようなオンボーディングができています。開発の中で、あるべき姿について議論になったりで色々なメンバーと話をしていくので、 医療業務のキャッチアップはかなりしやすい環境 だと思います。 もうひとつ「長期のカスタマー価値を追求する」という部分も文化を感じていて、主にマネージャーを含め、短期的な KPI に沿った開発よりも、長期的に顧客への価値提供に寄与できる開発を優先していくという意識が非常に強いのが良いと感じます。 特に今現在、社内で開発が進んでいる新規レセコンの開発については強く思いますね。 吉岡 : 自分が強く感じているメドレーの文化としては「ドキュメントドリブン」です。ミーティングなども、こういうことの結論を得るために協議する、というのが明確に分かる資料を事前に用意して行います。ですので、「これ何の時間だっけ?」みたいな状態になりにくいのが良いです。 あとは ミーティングによる同期的、Slack や Confluence などによる非同期のコミュニケーションを適材適所で全員が使いわけているので、そもそもコミュニケーションで無駄な行き違いのようなものも、ほとんど無い のも、仕事がしやすいと思っています。 もうひとつは、自分もやはりプロダクト志向の強さというところを感じています。現在はディレクターなどと一緒に開発をしていく体制になっているんですが、UI や顧客体験なども含めてエンジニアでも、ちゃんとプロダクトとしての理想の姿を考えて開発するという姿勢がとても強いです。自分の専門ではない領域でもきちんと考えながら開発をしていくので、やりがいがあります。 これからメドレーに入社する方へのメッセージ ── では最後になりますが、特に新卒でメドレーの入社を考えている方へのメッセージなどあれば、お伺いしたいです。 飯田 : そうですね、「先輩が新卒に対してとても期待してくれている」というのは伝えたいと思います。自分の場合、研修が終わって 3 ヶ月経ったぐらいで、シゴトークのインフラ環境を全部刷新するという大きなプロジェクトのリードを任せてもらえたんです。もちろん SRE の先輩などと協力しつつ進めたものだったんですが、 研修終わってすぐにそんな大きなプロジェクトを裁量持って進められるような環境なので、すごくやりがいがあります 。 岡田 : 稲本(人材プラットフォーム CTO)が「新卒だから」みたいな接し方をせずに、いちエンジニアとして接してくれているのは個人的に嬉しいポイントです。また 責任を持った上で裁量持って自由に動いていける業務環境があるのが、すごく良い です。ちゃんとプロダクトの事を考えて開発をしたい人にはおすすめできる環境だと思います。 徳永 : 新卒の良いところは「同期」感を持てるところかなと思います。今もランチ等でこのメンバーと技術的なところなどを気軽に相談できるのはとても良いです。 切磋琢磨していく環境じゃないかなと思っているので、そうした環境を求めるならすごく良い と思います。 古川 : 受け身で仕事を行うのではなく、ガツガツと自分の方から求めにいく姿勢の人には、すごくマッチする会社だと思います。せっかく裁量持って業務を進めることができる環境なので、 遠慮せずにがんがんと物事進めることができる人には最高 なんじゃないかと考えています。 自分はインフラだけではなくて、サーバやフロントエンドも開発していきたいと考えているんですが、小規模なプロジェクトであれば全て行える環境なため、自分一人でプロジェクトを完結することができるのは、性に合っているなと思ってます。周りのサポートや先輩との壁打ちなどはちゃんとやってもらえるので、とても勉強になり成長できると思います。 村上 : メドレーで開発をしていくについれて、医療ドメインという領域で自分が関わっていることが人の役に立っているんだなというのが日々実感できるところは良いです。特に色々な医療機関のサポートができるというプロダクトに関わっているので、直接医療機関やその先にいる患者さんの 役に立っているという実感は、正直 1 年目で感じられるものではないと思っていたので、良い驚き です。 また大きいデータを取り扱うという経験ができているのも貴重だなと感じています。現在のプロダクトでは契約医療機関も非常に多いですし、その大量のデータの設計を変更したりというところを、裁量持って実施できるのは良い経験になっています。 吉岡 : メドレーの「プロダクト志向」を持っている先輩エンジニアと働けるというのはとても良い経験だと思っています。一般的にはエンジニアは技術さえあればという感じになりやすかったりすると思うのですが、メドレーではもちろん新しい技術なども使いながら、それを いかにプロダクトやその先のユーザへの価値提供に繋げるかを考えている方が集っている ので、そういう思考でプロダクト開発ができているのはすごく勉強になります。 ── ありがとうございました! 本当に 1 年で皆さんが濃い業務経験を積んでいるのが分かるインタビューになりました。 さいごに それぞれ異なるチームや業務内容ですが、新卒エンジニアでも裁量を持って業務に臨めることや、プロダクトの重要な部分の開発にどんどん関わっていけることが伝わるインタビューとなりました。 メドレーは新卒入社のエンジニアも積極的に募集していますので、今回気になったという方はお気軽にカジュアル面談をしましょう! open.talentio.com open.talentio.com

はじめに みなさん、こんにちは。エンジニアの新居です。今回は 2022 年新卒入社したエンジニア達にインタビューした記事をお送りします。 この 1 年で彼らがどのような業務を経験してきたのかや、リアルな現在の立ち位置などをお伝えしたいと考えています。 それでは、ご覧ください! 自己紹介 飯田さん 研修後は ジョブメドレー で顧客向けの機能開発を担当。その後 シゴトーク でインフラ領域を中心にリニューアルに従事する。現在は Jobley で施策の開発やインフラ周りまで幅広く業務を担当。 飯田さん 岡田さん 研修後はジョブメドレーでの開発業務を担当後、シゴトークへ。ジョブメドレーとの連携強化のプロジェクトなど経験し、現在はシゴトークの開発全般を担当。 岡田さん 徳永さん 研修後は ジョブメドレーアカデミー に配属。プロダクト改善などを担当しつつ、直近では生成 AI を使った機能の開発やバックエンドからモバイルまで幅広い開発に従事。 徳永さん 古川さん 研修後は Pharms に配属。フロントエンドからインフラまで幅広く担当。小規模施策の開発に始まり現在は中規模施策のプロジェクトリードをしながら開発を行なう。 古川さん 村上さん 研修後は CLINICS に配属。電子カルテ関連の開発を経て、現在は中規模施策のプロジェクトリードをしながら開発を行なう。 村上さん 吉岡さん 研修後は 患者アプリ CLINICS に配属。Web アプリとネイティブアプリの機能開発を担当した後、CLINICS に配属。現在は定常改善や、フロントエンドの大規模改修などに従事。 吉岡さん ファーストキャリアとしてメドレーを選んだ理由について ── まずはファーストキャリアにメドレーへ入社を決めた理由をお伺いしていきたいと思います。 飯田 : 元々ベンチャー気質が高いことを軸に会社選びをしていました。新卒入社の社員が多数いるような規模が大きい会社だと、自分がその中に埋もれてしまい、自由度が高い動きができなさそうだと考えていたからです。メドレーは新卒が少ないのでその辺りはマッチしていました。医療という領域に関しても、 日常生活に関わるところで社会に貢献できるような領域が良いなと考えていたことや、家族が看護師をやっていることもあり医療業界の課題を身近に感じられ、医療に対して興味があった ことが理由になっています。 岡田 : 自分の体調が悪くなることが昔から多かったためヘルスケア業界に興味があったのですが、そこに近い業界だったのがひとつの理由です。また会社のミッションがとても分かりやすかったというのがあります。他社に比べて、メドレーは 世の中を良くしてくという会社のビジョンに、ちゃんと基づいてプロダクトを開発している んだなというのが具体的に分かって一貫性を感じられたのが大きいです。 他には、「エンジニア」という職種だともちろん技術分野が専門領域になっていくわけですが、その領域に閉じず、プロダクトを中心に課題解決する上でエンジニアリング以外のことも考えながら開発をしているプロダクトファーストな考えも魅力的でした。 徳永 : 自分は岡田くんのように特にヘルスケア領域に興味があったということはなかったんです。どちらかというと、 エンジニアとしてこれから働いていく上で自分が大切にしたい志向や価値観というのが、メドレーのエンジニアの方達と話をしていく中でマッチする なと感じたのが大きいです。 それまでも色々な会社さんとの選考をしていたんですが、メドレーのエンジニアは「本質を追い求める」という姿勢の元、エンジニアリングが好きで、それをプロダクトへ還元していくという部分が自分のフィーリングにあったという感じでした。 ── フィーリングに合ったということですが、他にもマッチすると思った部分はありましたか? 徳永 : エンジニアの雰囲気も大人な感じの方が多く、体育会系の「気合と根性で頑張る」という進め方ではなく、合理的に物事を進めるために必要なコミュニケーションをきちんと取っていくところなどが魅力でした。そうした部分も含めて自分が働いている将来というのが想像できました。 古川 : 自分は親が薬剤師で医療分野に元々興味があり、医療 x IT という軸で就活をしていく過程でメドレーを知ったのが最初の出会いでした。お話を聞いていくうちに「課題解決のためのプロダクト作り」という点が非常に魅力に感じました。社会を良くするためにプロダクトを良くしていこうという姿勢で会社に一体感が生まれているのが、すごく良いなと。 会社に限らないかもしれないですが、組織も人が多くなってくるとやっぱり方向性が少しずつズレていくという感じになりがちだと思うんですが、メドレーの場合は 会社として「医療業界をもっと良くしていくための事業をしていく」という軸が通っている のを感じて、最終的にはこの部分に惹かれて入社を決めました。 あとは、上場企業という「安心感」もファーストキャリアの選択に影響しました。 岡田 : 自分も新卒入社の社員目線だと、入社する会社の安定感というのは重要だと思っていました。 村上 : 就活する前は特定の業界に限らず色々な会社を見ていました。学生時代に様々な業界のエンジニアインターンやアルバイトなどしていたのですが、その過程で「せっかく正社員で働くなら、より社会的意義がある事業をやるべきだな」と感じました。そうした意識で就活に臨んで 自分が興味を持って取り組めそうなのは医療業界だなと思った のが最初のきっかけでした。 メドレーは選考の中で、技術領域を問わずに開発できることなどがマッチすると感じたのと、サービスが医療機関だけでなく患者側も充実しているということも入社の決め手になりました。自分が患者になることも多いので、とても課題が分かりやすかったんです。 吉岡 : 自分も元々エンタメなどの領域より、医療や教育、金融領域を中心に就活をしていました。中でもメドレーの「医療ヘルスケアの未来をつくる」というミッションへの自分の共感度が非常に高かったのが、入社の理由でした。日本の医療制度をきちんと維持するためのプロダクトを作っていくんだという姿勢が非常に良かったです。 またさきほどの話にも出ていましたが、 医療機関のためのプロダクトと患者のためのプロダクトという両面へのアプローチをしている のも決め手でした。やはり医療費の問題などは医療機関だけへのアプローチでは解決できないと思うので、そういう意味でも一貫性が感じられて良かったです。 現在のチーム内での役割について ── では次に現在のチームでの皆さんの役割や動き方、チームメンバーとの関わり方について聞いていきたいと思います。 飯田 : 現在 Jobley の開発チームではエンジニアが 4 人いるのですが、その内 2 人がプロダクト施策の立案を行ないつつ、自分を含む残りの 2 人が実装をメインにして開発を行なっています。状況に合わせ PM 兼任のエンジニアと実装担当のエンジニアとで二人三脚で開発をしたり、単独での開発を行なったりと柔軟に対応していってます。 チームメンバーとの関わりという点では、 エンジニアチームだけで開発するということはなく、セールスやカスタマーサクセスの方たちと一緒に要件を詰めていく ことが最近は多いです。そのためセールスの業務フローなどもキャッチアップする必要があるので大変ですが、面白くやりがいを感じるところでもありますね。 岡田 : シゴトークでは、PM とエンジニアの二人三脚という体制で開発をしています。PM と日々要件を刷り合わせながら、実装は自分が行なっていていくというスタイルです。Pull Request のレビューだけは元々シゴトークを開発されていたエンジニアの方々にお願いしています。 また、例えばプロダクトのセキュリティ強化の取り組みやアプリの認証機能の一新、QA 環境の整備など、自分が普段触れない領域の施策を行った際はスキルアップを実感できました。ライブラリのアップデートや、リファクタリングなども 裁量を持ってやらせてもらっています 。 徳永 : ジョブメドレーアカデミーはジョブメドレーや CLINICS に比べると小規模なチーム構成となっています。エンジニアが 7 人、PM が 3 人、プロダクトオーナーが 1 人という体制で開発をしてるのですが、 良い意味で新卒入社エンジニアとして裁量を持って開発をさせてもらっています 。 開発チームも徐々に大きくなっているので、タスクを上手く回すための仕組みを考えたり、チームを上手く機能させるために朝会の構成を変更してみたり。技術的な部分では CI/CD など開発全体に関わる分野についても、任せてもらっています。 また ニュースリリース にもなりましたが、社内で初めての 生成 AI を使った機能の開発 は、プロダクトオーナーと自分の 2 人が中心になって進めていきました。 開発に入る前段階でロジカルに「こういった課題をこの機能で解決していく」ということが伝えられれば、ある程度技術的に実験的なものも導入することができる環境です 。 古川 : Pharms では現在エンジニアが 4 人、PM 1 人、デザイナーが 1 人というのが中心メンバーとなっています。Pharms は現在色々と機能拡大をしていっているのですが、エンジニアが 4 人なので本当に全員で何でもやっていくという感じで開発しています。とはいえ、メンバー各々で得意分野は違うので、得意なところは積極的に拾いに行く感じです。 自分はと言うと、得意分野のインフラ部分に関してはほとんど任せてもらっており、自分からの発信で先輩のテックリードエンジニアの方とすり合わせしながら色々な施策を行なっています。その他にもクォーター毎に数個は中・大規模な施策が計画されるので、そうしたもののいくつかのリードをさせてもらったりしています。ですので、 アプリケーションの開発という面でもプロジェクトを上手く進行させるという面でも、とても楽しく業務をしています 。 村上 : CLINICS ではまず「基幹」と「周辺」とざっくり 2 つのチームに分かれており、「基幹」が主にレセコン(レセプトコンピュータの略。医療施設から健康保険組合などの支払い機関に対し、診療報酬を請求するために、電子カルテと連動してレセプトと呼ばれる診療報酬明細書を作成するシステム)とのやりとりを、「周辺」では予約や問診、資格確認など CLINICS と患者との接点となるシステム、という形で担当業務が分かれています。自分はずっと基幹チームにアサインされています。チーム全対応のエンジニアの内訳はアプリケーション担当が 6~7 人、インフラ担当が 3 人ほどになっています。 現在は大きなプロジェクトが 1 つ進行していて、既存のレセコンをメドレーで新規開発しているレセコンに移行するというものですが、その中に 中規模なプロジェクトが複数平行して進んでいて、その内のいくつかを自分がリード させてもらっています。 リードしているプロジェクトの進行管理やチームメンバー間での問題共有方法などを考えているのですが、この辺りは挑戦できる幅が広く、難しいですが面白いと感じています。課題についてプロジェクトに限定せず、他のシステムや進捗状況に影響がないかを配慮する必要があり、そうした視点で適切に異なる立場の関係者を巻き込むことで、より包括的な解決策を導き出そうと意識をしています。 吉岡 : 自分は今は村上と一緒のチームで業務をしているんですが、レセコンなどの部分というよりは、先程の話の「周辺」の開発をすることが多いです。基本的に平行して複数のプロジェクトが走っており、それぞれのプロジェクトでディレクター 1 人、エンジニア数人、他にデザイナーという形で進めていくことが多いです。 大まかにディレクターが要件などをまとめたものをベースとして、その後にデザイナーやエンジニアも入って要件定義などをしていき、徐々に形にしていくという事が多いですね。 ── お二人で組んで仕事をすることもあるんですか? 村上 : はい、とても多いです。 進行しているプロジェクトの他にも、定常改善やバグ改修などのタスクがありますが、そうしたタスクを「どのタイミングで」「どの優先度で」対応していくかなどをチーム内で議論してから実施するので。 吉岡 : プロジェクトやそうしたタスクとは別に、エンジニア主導で大規模なリファクタリングなども行なっています。担当しているプロジェクトの他にそうしたものを手がけていて、一緒になることが多いです。 入社してメドレーの文化を強く意識した出来事 ── メドレーで働いている中で、特に文化を強く感じたエピソードなど聞いてみたいです。 飯田 : 開発に関係する人全員が「プロダクト志向が強い」ということでしょうか。具体的には、開発の要件定義段階から全員関わるので、もちろんビジネスサイドの方からも「こうした方が良いのではないか」というアイデアは出てきますが、開発サイドからも「どういう機能が一番ユーザに価値を届けられるか」という視点で一緒になって考えるんです。そもそもどういった課題を解決するものなのかという基礎の部分から一緒に考えていくのがメドレーでは当たり前になっているという感じがします。 開発サイドもビジネスサイドも同じ方向を向いているので、提案などもちゃんとロジカルで筋が通っているものであれば通るというのは、すごく意見しがいがある と思います。そのための相談なんかも、もちろんしやすいですし、とても良い文化だなと感じています。 岡田 : 開発にあたって PM が 施策などを Issue として立ててくれるのですが、言語化が行き届いていて何が問題で、どうして実施するのか、その影響なんかがすごく分かりやすいという点はメドレーが大事にしている「ドキュメントドリブン」という文化を感じます。 そのような環境なので、大抵のことは最低限の文章のやり取りだけでスムーズに進みますし、上手くいかない状況になっても善後策などが立てやすくなっていると思います。 徳永 : メドレーは新卒入社の社員数は少ないので、中途入社の方がほとんどという環境です。入社してすぐは「自分の意見は通るのかな」とか「自分より後に入社した経験年数が長い中途入社の方とどう付き合おう」などが心配でした。でも メドレーでは「建設的に進める」という文化があるので、立場に関係なく議論できる環境があるので、とても仕事がしやすい です。自分の意見が例え間違っていたとしても議論が起きるということは、認識がズレていたということだからと軌道修正もできるので本当に働きやすいです。 また、とても良いなと思ったのが、部署や職種に関わらず Confluence の情報に誰でもアクセスできるという文化ですね。秘匿情報以外は基本的に全て Confluence でオープンになっているおかげで、自分とは直接関係ない部署の現在の動きなどがキャッチアップできるので、そういった人たちとコミュニケーションを取るときにもすごく助かります。 古川 : 徳永とかぶるところがあるんですが、「建設的に進める」という部分は非常にメドレーらしさを感じる文化です。例えば PM が「施策をこうしましょう」となっても、自分が「このフローってこうなった方が良いですよね」という意見を言えるし、そこを起点に 議論に発展してより良いものを作っていけるというのは本当に素晴らしい と感じています。 実際に自分がリードしていた施策の中でもエンジニア・ デザイナー・ PM ・カスタマーサクセスという立場が違うメンバー同士で改めて薬局の業務フローを整理しなおして、より良い仕様にできたりということがありました。 機能リリース後もちゃんと「あるべき姿」を目指して改善をできたりしたので、こういう考え方はとても仕事がしやすいです。 村上 : 自分からは「組織水準を高める」という文化について言及させてください。自分が関わっている電子カルテやレセコンという領域は深い業務知識が必要で、初めて関わった人からすると、そもそもどういうフローで機能が使われているかとか、特定の場合に何でこうなるんだろうというところが、理解しづらいんです。でも、自分のチームは新卒・中途問わず、まだ深いドメイン知識がない、といった状態からでも入って活躍しやすい環境だというのを感じています。 いきなり専門の業務知識が必要な開発というのはやはり難しいので、そうした部分と直接は関係しない周辺領域の開発から始めてもらって、徐々に電子カルテやレセコンに直接関係する開発に入ってもらえるようなオンボーディングができています。開発の中で、あるべき姿について議論になったりで色々なメンバーと話をしていくので、 医療業務のキャッチアップはかなりしやすい環境 だと思います。 もうひとつ「長期のカスタマー価値を追求する」という部分も文化を感じていて、主にマネージャーを含め、短期的な KPI に沿った開発よりも、長期的に顧客への価値提供に寄与できる開発を優先していくという意識が非常に強いのが良いと感じます。 特に今現在、社内で開発が進んでいる新規レセコンの開発については強く思いますね。 吉岡 : 自分が強く感じているメドレーの文化としては「ドキュメントドリブン」です。ミーティングなども、こういうことの結論を得るために協議する、というのが明確に分かる資料を事前に用意して行います。ですので、「これ何の時間だっけ?」みたいな状態になりにくいのが良いです。 あとは ミーティングによる同期的、Slack や Confluence などによる非同期のコミュニケーションを適材適所で全員が使いわけているので、そもそもコミュニケーションで無駄な行き違いのようなものも、ほとんど無い のも、仕事がしやすいと思っています。 もうひとつは、自分もやはりプロダクト志向の強さというところを感じています。現在はディレクターなどと一緒に開発をしていく体制になっているんですが、UI や顧客体験なども含めてエンジニアでも、ちゃんとプロダクトとしての理想の姿を考えて開発するという姿勢がとても強いです。自分の専門ではない領域でもきちんと考えながら開発をしていくので、やりがいがあります。 これからメドレーに入社する方へのメッセージ ── では最後になりますが、特に新卒でメドレーの入社を考えている方へのメッセージなどあれば、お伺いしたいです。 飯田 : そうですね、「先輩が新卒に対してとても期待してくれている」というのは伝えたいと思います。自分の場合、研修が終わって 3 ヶ月経ったぐらいで、シゴトークのインフラ環境を全部刷新するという大きなプロジェクトのリードを任せてもらえたんです。もちろん SRE の先輩などと協力しつつ進めたものだったんですが、 研修終わってすぐにそんな大きなプロジェクトを裁量持って進められるような環境なので、すごくやりがいがあります 。 岡田 : 稲本(人材プラットフォーム CTO)が「新卒だから」みたいな接し方をせずに、いちエンジニアとして接してくれているのは個人的に嬉しいポイントです。また 責任を持った上で裁量持って自由に動いていける業務環境があるのが、すごく良い です。ちゃんとプロダクトの事を考えて開発をしたい人にはおすすめできる環境だと思います。 徳永 : 新卒の良いところは「同期」感を持てるところかなと思います。今もランチ等でこのメンバーと技術的なところなどを気軽に相談できるのはとても良いです。 切磋琢磨していく環境じゃないかなと思っているので、そうした環境を求めるならすごく良い と思います。 古川 : 受け身で仕事を行うのではなく、ガツガツと自分の方から求めにいく姿勢の人には、すごくマッチする会社だと思います。せっかく裁量持って業務を進めることができる環境なので、 遠慮せずにがんがんと物事進めることができる人には最高 なんじゃないかと考えています。 自分はインフラだけではなくて、サーバやフロントエンドも開発していきたいと考えているんですが、小規模なプロジェクトであれば全て行える環境なため、自分一人でプロジェクトを完結することができるのは、性に合っているなと思ってます。周りのサポートや先輩との壁打ちなどはちゃんとやってもらえるので、とても勉強になり成長できると思います。 村上 : メドレーで開発をしていくについれて、医療ドメインという領域で自分が関わっていることが人の役に立っているんだなというのが日々実感できるところは良いです。特に色々な医療機関のサポートができるというプロダクトに関わっているので、直接医療機関やその先にいる患者さんの 役に立っているという実感は、正直 1 年目で感じられるものではないと思っていたので、良い驚き です。 また大きいデータを取り扱うという経験ができているのも貴重だなと感じています。現在のプロダクトでは契約医療機関も非常に多いですし、その大量のデータの設計を変更したりというところを、裁量持って実施できるのは良い経験になっています。 吉岡 : メドレーの「プロダクト志向」を持っている先輩エンジニアと働けるというのはとても良い経験だと思っています。一般的にはエンジニアは技術さえあればという感じになりやすかったりすると思うのですが、メドレーではもちろん新しい技術なども使いながら、それを いかにプロダクトやその先のユーザへの価値提供に繋げるかを考えている方が集っている ので、そういう思考でプロダクト開発ができているのはすごく勉強になります。 ── ありがとうございました! 本当に 1 年で皆さんが濃い業務経験を積んでいるのが分かるインタビューになりました。 さいごに それぞれ異なるチームや業務内容ですが、新卒エンジニアでも裁量を持って業務に臨めることや、プロダクトの重要な部分の開発にどんどん関わっていけることが伝わるインタビューとなりました。 メドレーは新卒入社のエンジニアも積極的に募集していますので、今回気になったという方はお気軽にカジュアル面談をしましょう! https://open.talentio.com/r/1/c/medley/pages/54863

はじめに みなさん、こんにちは。エンジニアの新居です。今回は 2022 年新卒入社したエンジニア達にインタビューした記事をお送りします。 この 1 年で彼らがどのような業務を経験してきたのかや、リアルな現在の立ち位置などをお伝えしたいと考えています。 それでは、ご覧ください! 自己紹介 飯田さん 研修後は ジョブメドレー で顧客向けの機能開発を担当。その後 シゴトーク でインフラ領域を中心にリニューアルに従事する。現在は Jobley で施策の開発やインフラ周りまで幅広く業務を担当。 飯田さん 岡田さん 研修後はジョブメドレーでの開発業務を担当後、シゴトークへ。ジョブメドレーとの連携強化のプロジェクトなど経験し、現在はシゴトークの開発全般を担当。 岡田さん 徳永さん 研修後は ジョブメドレーアカデミー に配属。プロダクト改善などを担当しつつ、直近では生成 AI を使った機能の開発やバックエンドからモバイルまで幅広い開発に従事。 徳永さん 古川さん 研修後は Pharms に配属。フロントエンドからインフラまで幅広く担当。小規模施策の開発に始まり現在は中規模施策のプロジェクトリードをしながら開発を行なう。 古川さん 村上さん 研修後は CLINICS に配属。電子カルテ関連の開発を経て、現在は中規模施策のプロジェクトリードをしながら開発を行なう。 村上さん 吉岡さん 研修後は 患者アプリ CLINICS に配属。Web アプリとネイティブアプリの機能開発を担当した後、CLINICS に配属。現在は定常改善や、フロントエンドの大規模改修などに従事。 吉岡さん ファーストキャリアとしてメドレーを選んだ理由について ── まずはファーストキャリアにメドレーへ入社を決めた理由をお伺いしていきたいと思います。 飯田 : 元々ベンチャー気質が高いことを軸に会社選びをしていました。新卒入社の社員が多数いるような規模が大きい会社だと、自分がその中に埋もれてしまい、自由度が高い動きができなさそうだと考えていたからです。メドレーは新卒が少ないのでその辺りはマッチしていました。医療という領域に関しても、 日常生活に関わるところで社会に貢献できるような領域が良いなと考えていたことや、家族が看護師をやっていることもあり医療業界の課題を身近に感じられ、医療に対して興味があった ことが理由になっています。 岡田 : 自分の体調が悪くなることが昔から多かったためヘルスケア業界に興味があったのですが、そこに近い業界だったのがひとつの理由です。また会社のミッションがとても分かりやすかったというのがあります。他社に比べて、メドレーは 世の中を良くしてくという会社のビジョンに、ちゃんと基づいてプロダクトを開発している んだなというのが具体的に分かって一貫性を感じられたのが大きいです。 他には、「エンジニア」という職種だともちろん技術分野が専門領域になっていくわけですが、その領域に閉じず、プロダクトを中心に課題解決する上でエンジニアリング以外のことも考えながら開発をしているプロダクトファーストな考えも魅力的でした。 徳永 : 自分は岡田くんのように特にヘルスケア領域に興味があったということはなかったんです。どちらかというと、 エンジニアとしてこれから働いていく上で自分が大切にしたい志向や価値観というのが、メドレーのエンジニアの方達と話をしていく中でマッチする なと感じたのが大きいです。 それまでも色々な会社さんとの選考をしていたんですが、メドレーのエンジニアは「本質を追い求める」という姿勢の元、エンジニアリングが好きで、それをプロダクトへ還元していくという部分が自分のフィーリングにあったという感じでした。 ── フィーリングに合ったということですが、他にもマッチすると思った部分はありましたか? 徳永 : エンジニアの雰囲気も大人な感じの方が多く、体育会系の「気合と根性で頑張る」という進め方ではなく、合理的に物事を進めるために必要なコミュニケーションをきちんと取っていくところなどが魅力でした。そうした部分も含めて自分が働いている将来というのが想像できました。 古川 : 自分は親が薬剤師で医療分野に元々興味があり、医療 x IT という軸で就活をしていく過程でメドレーを知ったのが最初の出会いでした。お話を聞いていくうちに「課題解決のためのプロダクト作り」という点が非常に魅力に感じました。社会を良くするためにプロダクトを良くしていこうという姿勢で会社に一体感が生まれているのが、すごく良いなと。 会社に限らないかもしれないですが、組織も人が多くなってくるとやっぱり方向性が少しずつズレていくという感じになりがちだと思うんですが、メドレーの場合は 会社として「医療業界をもっと良くしていくための事業をしていく」という軸が通っている のを感じて、最終的にはこの部分に惹かれて入社を決めました。 あとは、上場企業という「安心感」もファーストキャリアの選択に影響しました。 岡田 : 自分も新卒入社の社員目線だと、入社する会社の安定感というのは重要だと思っていました。 村上 : 就活する前は特定の業界に限らず色々な会社を見ていました。学生時代に様々な業界のエンジニアインターンやアルバイトなどしていたのですが、その過程で「せっかく正社員で働くなら、より社会的意義がある事業をやるべきだな」と感じました。そうした意識で就活に臨んで 自分が興味を持って取り組めそうなのは医療業界だなと思った のが最初のきっかけでした。 メドレーは選考の中で、技術領域を問わずに開発できることなどがマッチすると感じたのと、サービスが医療機関だけでなく患者側も充実しているということも入社の決め手になりました。自分が患者になることも多いので、とても課題が分かりやすかったんです。 吉岡 : 自分も元々エンタメなどの領域より、医療や教育、金融領域を中心に就活をしていました。中でもメドレーの「医療ヘルスケアの未来をつくる」というミッションへの自分の共感度が非常に高かったのが、入社の理由でした。日本の医療制度をきちんと維持するためのプロダクトを作っていくんだという姿勢が非常に良かったです。 またさきほどの話にも出ていましたが、 医療機関のためのプロダクトと患者のためのプロダクトという両面へのアプローチをしている のも決め手でした。やはり医療費の問題などは医療機関だけへのアプローチでは解決できないと思うので、そういう意味でも一貫性が感じられて良かったです。 現在のチーム内での役割について ── では次に現在のチームでの皆さんの役割や動き方、チームメンバーとの関わり方について聞いていきたいと思います。 飯田 : 現在 Jobley の開発チームではエンジニアが 4 人いるのですが、その内 2 人がプロダクト施策の立案を行ないつつ、自分を含む残りの 2 人が実装をメインにして開発を行なっています。状況に合わせ PM 兼任のエンジニアと実装担当のエンジニアとで二人三脚で開発をしたり、単独での開発を行なったりと柔軟に対応していってます。 チームメンバーとの関わりという点では、 エンジニアチームだけで開発するということはなく、セールスやカスタマーサクセスの方たちと一緒に要件を詰めていく ことが最近は多いです。そのためセールスの業務フローなどもキャッチアップする必要があるので大変ですが、面白くやりがいを感じるところでもありますね。 岡田 : シゴトークでは、PM とエンジニアの二人三脚という体制で開発をしています。PM と日々要件を刷り合わせながら、実装は自分が行なっていていくというスタイルです。Pull Request のレビューだけは元々シゴトークを開発されていたエンジニアの方々にお願いしています。 また、例えばプロダクトのセキュリティ強化の取り組みやアプリの認証機能の一新、QA 環境の整備など、自分が普段触れない領域の施策を行った際はスキルアップを実感できました。ライブラリのアップデートや、リファクタリングなども 裁量を持ってやらせてもらっています 。 徳永 : ジョブメドレーアカデミーはジョブメドレーや CLINICS に比べると小規模なチーム構成となっています。エンジニアが 7 人、PM が 3 人、プロダクトオーナーが 1 人という体制で開発をしてるのですが、 良い意味で新卒入社エンジニアとして裁量を持って開発をさせてもらっています 。 開発チームも徐々に大きくなっているので、タスクを上手く回すための仕組みを考えたり、チームを上手く機能させるために朝会の構成を変更してみたり。技術的な部分では CI/CD など開発全体に関わる分野についても、任せてもらっています。 また ニュースリリース にもなりましたが、社内で初めての 生成 AI を使った機能の開発 は、プロダクトオーナーと自分の 2 人が中心になって進めていきました。 開発に入る前段階でロジカルに「こういった課題をこの機能で解決していく」ということが伝えられれば、ある程度技術的に実験的なものも導入することができる環境です 。 古川 : Pharms では現在エンジニアが 4 人、PM 1 人、デザイナーが 1 人というのが中心メンバーとなっています。Pharms は現在色々と機能拡大をしていっているのですが、エンジニアが 4 人なので本当に全員で何でもやっていくという感じで開発しています。とはいえ、メンバー各々で得意分野は違うので、得意なところは積極的に拾いに行く感じです。 自分はと言うと、得意分野のインフラ部分に関してはほとんど任せてもらっており、自分からの発信で先輩のテックリードエンジニアの方とすり合わせしながら色々な施策を行なっています。その他にもクォーター毎に数個は中・大規模な施策が計画されるので、そうしたもののいくつかのリードをさせてもらったりしています。ですので、 アプリケーションの開発という面でもプロジェクトを上手く進行させるという面でも、とても楽しく業務をしています 。 村上 : CLINICS ではまず「基幹」と「周辺」とざっくり 2 つのチームに分かれており、「基幹」が主にレセコン(レセプトコンピュータの略。医療施設から健康保険組合などの支払い機関に対し、診療報酬を請求するために、電子カルテと連動してレセプトと呼ばれる診療報酬明細書を作成するシステム)とのやりとりを、「周辺」では予約や問診、資格確認など CLINICS と患者との接点となるシステム、という形で担当業務が分かれています。自分はずっと基幹チームにアサインされています。チーム全対応のエンジニアの内訳はアプリケーション担当が 6~7 人、インフラ担当が 3 人ほどになっています。 現在は大きなプロジェクトが 1 つ進行していて、既存のレセコンをメドレーで新規開発しているレセコンに移行するというものですが、その中に 中規模なプロジェクトが複数平行して進んでいて、その内のいくつかを自分がリード させてもらっています。 リードしているプロジェクトの進行管理やチームメンバー間での問題共有方法などを考えているのですが、この辺りは挑戦できる幅が広く、難しいですが面白いと感じています。課題についてプロジェクトに限定せず、他のシステムや進捗状況に影響がないかを配慮する必要があり、そうした視点で適切に異なる立場の関係者を巻き込むことで、より包括的な解決策を導き出そうと意識をしています。 吉岡 : 自分は今は村上と一緒のチームで業務をしているんですが、レセコンなどの部分というよりは、先程の話の「周辺」の開発をすることが多いです。基本的に平行して複数のプロジェクトが走っており、それぞれのプロジェクトでディレクター 1 人、エンジニア数人、他にデザイナーという形で進めていくことが多いです。 大まかにディレクターが要件などをまとめたものをベースとして、その後にデザイナーやエンジニアも入って要件定義などをしていき、徐々に形にしていくという事が多いですね。 ── お二人で組んで仕事をすることもあるんですか? 村上 : はい、とても多いです。 進行しているプロジェクトの他にも、定常改善やバグ改修などのタスクがありますが、そうしたタスクを「どのタイミングで」「どの優先度で」対応していくかなどをチーム内で議論してから実施するので。 吉岡 : プロジェクトやそうしたタスクとは別に、エンジニア主導で大規模なリファクタリングなども行なっています。担当しているプロジェクトの他にそうしたものを手がけていて、一緒になることが多いです。 入社してメドレーの文化を強く意識した出来事 ── メドレーで働いている中で、特に文化を強く感じたエピソードなど聞いてみたいです。 飯田 : 開発に関係する人全員が「プロダクト志向が強い」ということでしょうか。具体的には、開発の要件定義段階から全員関わるので、もちろんビジネスサイドの方からも「こうした方が良いのではないか」というアイデアは出てきますが、開発サイドからも「どういう機能が一番ユーザに価値を届けられるか」という視点で一緒になって考えるんです。そもそもどういった課題を解決するものなのかという基礎の部分から一緒に考えていくのがメドレーでは当たり前になっているという感じがします。 開発サイドもビジネスサイドも同じ方向を向いているので、提案などもちゃんとロジカルで筋が通っているものであれば通るというのは、すごく意見しがいがある と思います。そのための相談なんかも、もちろんしやすいですし、とても良い文化だなと感じています。 岡田 : 開発にあたって PM が 施策などを Issue として立ててくれるのですが、言語化が行き届いていて何が問題で、どうして実施するのか、その影響なんかがすごく分かりやすいという点はメドレーが大事にしている「ドキュメントドリブン」という文化を感じます。 そのような環境なので、大抵のことは最低限の文章のやり取りだけでスムーズに進みますし、上手くいかない状況になっても善後策などが立てやすくなっていると思います。 徳永 : メドレーは新卒入社の社員数は少ないので、中途入社の方がほとんどという環境です。入社してすぐは「自分の意見は通るのかな」とか「自分より後に入社した経験年数が長い中途入社の方とどう付き合おう」などが心配でした。でも メドレーでは「建設的に進める」という文化があるので、立場に関係なく議論できる環境があるので、とても仕事がしやすい です。自分の意見が例え間違っていたとしても議論が起きるということは、認識がズレていたということだからと軌道修正もできるので本当に働きやすいです。 また、とても良いなと思ったのが、部署や職種に関わらず Confluence の情報に誰でもアクセスできるという文化ですね。秘匿情報以外は基本的に全て Confluence でオープンになっているおかげで、自分とは直接関係ない部署の現在の動きなどがキャッチアップできるので、そういった人たちとコミュニケーションを取るときにもすごく助かります。 古川 : 徳永とかぶるところがあるんですが、「建設的に進める」という部分は非常にメドレーらしさを感じる文化です。例えば PM が「施策をこうしましょう」となっても、自分が「このフローってこうなった方が良いですよね」という意見を言えるし、そこを起点に 議論に発展してより良いものを作っていけるというのは本当に素晴らしい と感じています。 実際に自分がリードしていた施策の中でもエンジニア・ デザイナー・ PM ・カスタマーサクセスという立場が違うメンバー同士で改めて薬局の業務フローを整理しなおして、より良い仕様にできたりということがありました。 機能リリース後もちゃんと「あるべき姿」を目指して改善をできたりしたので、こういう考え方はとても仕事がしやすいです。 村上 : 自分からは「組織水準を高める」という文化について言及させてください。自分が関わっている電子カルテやレセコンという領域は深い業務知識が必要で、初めて関わった人からすると、そもそもどういうフローで機能が使われているかとか、特定の場合に何でこうなるんだろうというところが、理解しづらいんです。でも、自分のチームは新卒・中途問わず、まだ深いドメイン知識がない、といった状態からでも入って活躍しやすい環境だというのを感じています。 いきなり専門の業務知識が必要な開発というのはやはり難しいので、そうした部分と直接は関係しない周辺領域の開発から始めてもらって、徐々に電子カルテやレセコンに直接関係する開発に入ってもらえるようなオンボーディングができています。開発の中で、あるべき姿について議論になったりで色々なメンバーと話をしていくので、 医療業務のキャッチアップはかなりしやすい環境 だと思います。 もうひとつ「長期のカスタマー価値を追求する」という部分も文化を感じていて、主にマネージャーを含め、短期的な KPI に沿った開発よりも、長期的に顧客への価値提供に寄与できる開発を優先していくという意識が非常に強いのが良いと感じます。 特に今現在、社内で開発が進んでいる新規レセコンの開発については強く思いますね。 吉岡 : 自分が強く感じているメドレーの文化としては「ドキュメントドリブン」です。ミーティングなども、こういうことの結論を得るために協議する、というのが明確に分かる資料を事前に用意して行います。ですので、「これ何の時間だっけ?」みたいな状態になりにくいのが良いです。 あとは ミーティングによる同期的、Slack や Confluence などによる非同期のコミュニケーションを適材適所で全員が使いわけているので、そもそもコミュニケーションで無駄な行き違いのようなものも、ほとんど無い のも、仕事がしやすいと思っています。 もうひとつは、自分もやはりプロダクト志向の強さというところを感じています。現在はディレクターなどと一緒に開発をしていく体制になっているんですが、UI や顧客体験なども含めてエンジニアでも、ちゃんとプロダクトとしての理想の姿を考えて開発するという姿勢がとても強いです。自分の専門ではない領域でもきちんと考えながら開発をしていくので、やりがいがあります。 これからメドレーに入社する方へのメッセージ ── では最後になりますが、特に新卒でメドレーの入社を考えている方へのメッセージなどあれば、お伺いしたいです。 飯田 : そうですね、「先輩が新卒に対してとても期待してくれている」というのは伝えたいと思います。自分の場合、研修が終わって 3 ヶ月経ったぐらいで、シゴトークのインフラ環境を全部刷新するという大きなプロジェクトのリードを任せてもらえたんです。もちろん SRE の先輩などと協力しつつ進めたものだったんですが、 研修終わってすぐにそんな大きなプロジェクトを裁量持って進められるような環境なので、すごくやりがいがあります 。 岡田 : 稲本(人材プラットフォーム CTO)が「新卒だから」みたいな接し方をせずに、いちエンジニアとして接してくれているのは個人的に嬉しいポイントです。また 責任を持った上で裁量持って自由に動いていける業務環境があるのが、すごく良い です。ちゃんとプロダクトの事を考えて開発をしたい人にはおすすめできる環境だと思います。 徳永 : 新卒の良いところは「同期」感を持てるところかなと思います。今もランチ等でこのメンバーと技術的なところなどを気軽に相談できるのはとても良いです。 切磋琢磨していく環境じゃないかなと思っているので、そうした環境を求めるならすごく良い と思います。 古川 : 受け身で仕事を行うのではなく、ガツガツと自分の方から求めにいく姿勢の人には、すごくマッチする会社だと思います。せっかく裁量持って業務を進めることができる環境なので、 遠慮せずにがんがんと物事進めることができる人には最高 なんじゃないかと考えています。 自分はインフラだけではなくて、サーバやフロントエンドも開発していきたいと考えているんですが、小規模なプロジェクトであれば全て行える環境なため、自分一人でプロジェクトを完結することができるのは、性に合っているなと思ってます。周りのサポートや先輩との壁打ちなどはちゃんとやってもらえるので、とても勉強になり成長できると思います。 村上 : メドレーで開発をしていくについれて、医療ドメインという領域で自分が関わっていることが人の役に立っているんだなというのが日々実感できるところは良いです。特に色々な医療機関のサポートができるというプロダクトに関わっているので、直接医療機関やその先にいる患者さんの 役に立っているという実感は、正直 1 年目で感じられるものではないと思っていたので、良い驚き です。 また大きいデータを取り扱うという経験ができているのも貴重だなと感じています。現在のプロダクトでは契約医療機関も非常に多いですし、その大量のデータの設計を変更したりというところを、裁量持って実施できるのは良い経験になっています。 吉岡 : メドレーの「プロダクト志向」を持っている先輩エンジニアと働けるというのはとても良い経験だと思っています。一般的にはエンジニアは技術さえあればという感じになりやすかったりすると思うのですが、メドレーではもちろん新しい技術なども使いながら、それを いかにプロダクトやその先のユーザへの価値提供に繋げるかを考えている方が集っている ので、そういう思考でプロダクト開発ができているのはすごく勉強になります。 ── ありがとうございました! 本当に 1 年で皆さんが濃い業務経験を積んでいるのが分かるインタビューになりました。 さいごに それぞれ異なるチームや業務内容ですが、新卒エンジニアでも裁量を持って業務に臨めることや、プロダクトの重要な部分の開発にどんどん関わっていけることが伝わるインタビューとなりました。 メドレーは新卒入社のエンジニアも積極的に募集していますので、今回気になったという方はお気軽にカジュアル面談をしましょう! open.talentio.com open.talentio.com

はじめに みなさん、こんにちは。エンジニアの新居です。今回は 2022 年新卒入社したエンジニア達にインタビューした記事をお送りします。 この 1 年で彼らがどのような業務を経験してきたのかや、リアルな現在の立ち位置などをお伝えしたいと考えています。 それでは、ご覧ください! 自己紹介 飯田さん 研修後は ジョブメドレー で顧客向けの機能開発を担当。その後 シゴトーク でインフラ領域を中心にリニューアルに従事する。現在は Jobley で施策の開発やインフラ周りまで幅広く業務を担当。 飯田さん 岡田さん 研修後はジョブメドレーでの開発業務を担当後、シゴトークへ。ジョブメドレーとの連携強化のプロジェクトなど経験し、現在はシゴトークの開発全般を担当。 岡田さん 徳永さん 研修後は ジョブメドレーアカデミー に配属。プロダクト改善などを担当しつつ、直近では生成 AI を使った機能の開発やバックエンドからモバイルまで幅広い開発に従事。 徳永さん 古川さん 研修後は Pharms に配属。フロントエンドからインフラまで幅広く担当。小規模施策の開発に始まり現在は中規模施策のプロジェクトリードをしながら開発を行なう。 古川さん 村上さん 研修後は CLINICS に配属。電子カルテ関連の開発を経て、現在は中規模施策のプロジェクトリードをしながら開発を行なう。 村上さん 吉岡さん 研修後は 患者アプリ CLINICS に配属。Web アプリとネイティブアプリの機能開発を担当した後、CLINICS に配属。現在は定常改善や、フロントエンドの大規模改修などに従事。 吉岡さん ファーストキャリアとしてメドレーを選んだ理由について ── まずはファーストキャリアにメドレーへ入社を決めた理由をお伺いしていきたいと思います。 飯田 : 元々ベンチャー気質が高いことを軸に会社選びをしていました。新卒入社の社員が多数いるような規模が大きい会社だと、自分がその中に埋もれてしまい、自由度が高い動きができなさそうだと考えていたからです。メドレーは新卒が少ないのでその辺りはマッチしていました。医療という領域に関しても、 日常生活に関わるところで社会に貢献できるような領域が良いなと考えていたことや、家族が看護師をやっていることもあり医療業界の課題を身近に感じられ、医療に対して興味があった ことが理由になっています。 岡田 : 自分の体調が悪くなることが昔から多かったためヘルスケア業界に興味があったのですが、そこに近い業界だったのがひとつの理由です。また会社のミッションがとても分かりやすかったというのがあります。他社に比べて、メドレーは 世の中を良くしてくという会社のビジョンに、ちゃんと基づいてプロダクトを開発している んだなというのが具体的に分かって一貫性を感じられたのが大きいです。 他には、「エンジニア」という職種だともちろん技術分野が専門領域になっていくわけですが、その領域に閉じず、プロダクトを中心に課題解決する上でエンジニアリング以外のことも考えながら開発をしているプロダクトファーストな考えも魅力的でした。 徳永 : 自分は岡田くんのように特にヘルスケア領域に興味があったということはなかったんです。どちらかというと、 エンジニアとしてこれから働いていく上で自分が大切にしたい志向や価値観というのが、メドレーのエンジニアの方達と話をしていく中でマッチする なと感じたのが大きいです。 それまでも色々な会社さんとの選考をしていたんですが、メドレーのエンジニアは「本質を追い求める」という姿勢の元、エンジニアリングが好きで、それをプロダクトへ還元していくという部分が自分のフィーリングにあったという感じでした。 ── フィーリングに合ったということですが、他にもマッチすると思った部分はありましたか? 徳永 : エンジニアの雰囲気も大人な感じの方が多く、体育会系の「気合と根性で頑張る」という進め方ではなく、合理的に物事を進めるために必要なコミュニケーションをきちんと取っていくところなどが魅力でした。そうした部分も含めて自分が働いている将来というのが想像できました。 古川 : 自分は親が薬剤師で医療分野に元々興味があり、医療 x IT という軸で就活をしていく過程でメドレーを知ったのが最初の出会いでした。お話を聞いていくうちに「課題解決のためのプロダクト作り」という点が非常に魅力に感じました。社会を良くするためにプロダクトを良くしていこうという姿勢で会社に一体感が生まれているのが、すごく良いなと。 会社に限らないかもしれないですが、組織も人が多くなってくるとやっぱり方向性が少しずつズレていくという感じになりがちだと思うんですが、メドレーの場合は 会社として「医療業界をもっと良くしていくための事業をしていく」という軸が通っている のを感じて、最終的にはこの部分に惹かれて入社を決めました。 あとは、上場企業という「安心感」もファーストキャリアの選択に影響しました。 岡田 : 自分も新卒入社の社員目線だと、入社する会社の安定感というのは重要だと思っていました。 村上 : 就活する前は特定の業界に限らず色々な会社を見ていました。学生時代に様々な業界のエンジニアインターンやアルバイトなどしていたのですが、その過程で「せっかく正社員で働くなら、より社会的意義がある事業をやるべきだな」と感じました。そうした意識で就活に臨んで 自分が興味を持って取り組めそうなのは医療業界だなと思った のが最初のきっかけでした。 メドレーは選考の中で、技術領域を問わずに開発できることなどがマッチすると感じたのと、サービスが医療機関だけでなく患者側も充実しているということも入社の決め手になりました。自分が患者になることも多いので、とても課題が分かりやすかったんです。 吉岡 : 自分も元々エンタメなどの領域より、医療や教育、金融領域を中心に就活をしていました。中でもメドレーの「医療ヘルスケアの未来をつくる」というミッションへの自分の共感度が非常に高かったのが、入社の理由でした。日本の医療制度をきちんと維持するためのプロダクトを作っていくんだという姿勢が非常に良かったです。 またさきほどの話にも出ていましたが、 医療機関のためのプロダクトと患者のためのプロダクトという両面へのアプローチをしている のも決め手でした。やはり医療費の問題などは医療機関だけへのアプローチでは解決できないと思うので、そういう意味でも一貫性が感じられて良かったです。 現在のチーム内での役割について ── では次に現在のチームでの皆さんの役割や動き方、チームメンバーとの関わり方について聞いていきたいと思います。 飯田 : 現在 Jobley の開発チームではエンジニアが 4 人いるのですが、その内 2 人がプロダクト施策の立案を行ないつつ、自分を含む残りの 2 人が実装をメインにして開発を行なっています。状況に合わせ PM 兼任のエンジニアと実装担当のエンジニアとで二人三脚で開発をしたり、単独での開発を行なったりと柔軟に対応していってます。 チームメンバーとの関わりという点では、 エンジニアチームだけで開発するということはなく、セールスやカスタマーサクセスの方たちと一緒に要件を詰めていく ことが最近は多いです。そのためセールスの業務フローなどもキャッチアップする必要があるので大変ですが、面白くやりがいを感じるところでもありますね。 岡田 : シゴトークでは、PM とエンジニアの二人三脚という体制で開発をしています。PM と日々要件を刷り合わせながら、実装は自分が行なっていていくというスタイルです。Pull Request のレビューだけは元々シゴトークを開発されていたエンジニアの方々にお願いしています。 また、例えばプロダクトのセキュリティ強化の取り組みやアプリの認証機能の一新、QA 環境の整備など、自分が普段触れない領域の施策を行った際はスキルアップを実感できました。ライブラリのアップデートや、リファクタリングなども 裁量を持ってやらせてもらっています 。 徳永 : ジョブメドレーアカデミーはジョブメドレーや CLINICS に比べると小規模なチーム構成となっています。エンジニアが 7 人、PM が 3 人、プロダクトオーナーが 1 人という体制で開発をしてるのですが、 良い意味で新卒入社エンジニアとして裁量を持って開発をさせてもらっています 。 開発チームも徐々に大きくなっているので、タスクを上手く回すための仕組みを考えたり、チームを上手く機能させるために朝会の構成を変更してみたり。技術的な部分では CI/CD など開発全体に関わる分野についても、任せてもらっています。 また ニュースリリース にもなりましたが、社内で初めての 生成 AI を使った機能の開発 は、プロダクトオーナーと自分の 2 人が中心になって進めていきました。 開発に入る前段階でロジカルに「こういった課題をこの機能で解決していく」ということが伝えられれば、ある程度技術的に実験的なものも導入することができる環境です 。 古川 : Pharms では現在エンジニアが 4 人、PM 1 人、デザイナーが 1 人というのが中心メンバーとなっています。Pharms は現在色々と機能拡大をしていっているのですが、エンジニアが 4 人なので本当に全員で何でもやっていくという感じで開発しています。とはいえ、メンバー各々で得意分野は違うので、得意なところは積極的に拾いに行く感じです。 自分はと言うと、得意分野のインフラ部分に関してはほとんど任せてもらっており、自分からの発信で先輩のテックリードエンジニアの方とすり合わせしながら色々な施策を行なっています。その他にもクォーター毎に数個は中・大規模な施策が計画されるので、そうしたもののいくつかのリードをさせてもらったりしています。ですので、 アプリケーションの開発という面でもプロジェクトを上手く進行させるという面でも、とても楽しく業務をしています 。 村上 : CLINICS ではまず「基幹」と「周辺」とざっくり 2 つのチームに分かれており、「基幹」が主にレセコン(レセプトコンピュータの略。医療施設から健康保険組合などの支払い機関に対し、診療報酬を請求するために、電子カルテと連動してレセプトと呼ばれる診療報酬明細書を作成するシステム)とのやりとりを、「周辺」では予約や問診、資格確認など CLINICS と患者との接点となるシステム、という形で担当業務が分かれています。自分はずっと基幹チームにアサインされています。チーム全対応のエンジニアの内訳はアプリケーション担当が 6~7 人、インフラ担当が 3 人ほどになっています。 現在は大きなプロジェクトが 1 つ進行していて、既存のレセコンをメドレーで新規開発しているレセコンに移行するというものですが、その中に 中規模なプロジェクトが複数平行して進んでいて、その内のいくつかを自分がリード させてもらっています。 リードしているプロジェクトの進行管理やチームメンバー間での問題共有方法などを考えているのですが、この辺りは挑戦できる幅が広く、難しいですが面白いと感じています。課題についてプロジェクトに限定せず、他のシステムや進捗状況に影響がないかを配慮する必要があり、そうした視点で適切に異なる立場の関係者を巻き込むことで、より包括的な解決策を導き出そうと意識をしています。 吉岡 : 自分は今は村上と一緒のチームで業務をしているんですが、レセコンなどの部分というよりは、先程の話の「周辺」の開発をすることが多いです。基本的に平行して複数のプロジェクトが走っており、それぞれのプロジェクトでディレクター 1 人、エンジニア数人、他にデザイナーという形で進めていくことが多いです。 大まかにディレクターが要件などをまとめたものをベースとして、その後にデザイナーやエンジニアも入って要件定義などをしていき、徐々に形にしていくという事が多いですね。 ── お二人で組んで仕事をすることもあるんですか? 村上 : はい、とても多いです。 進行しているプロジェクトの他にも、定常改善やバグ改修などのタスクがありますが、そうしたタスクを「どのタイミングで」「どの優先度で」対応していくかなどをチーム内で議論してから実施するので。 吉岡 : プロジェクトやそうしたタスクとは別に、エンジニア主導で大規模なリファクタリングなども行なっています。担当しているプロジェクトの他にそうしたものを手がけていて、一緒になることが多いです。 入社してメドレーの文化を強く意識した出来事 ── メドレーで働いている中で、特に文化を強く感じたエピソードなど聞いてみたいです。 飯田 : 開発に関係する人全員が「プロダクト志向が強い」ということでしょうか。具体的には、開発の要件定義段階から全員関わるので、もちろんビジネスサイドの方からも「こうした方が良いのではないか」というアイデアは出てきますが、開発サイドからも「どういう機能が一番ユーザに価値を届けられるか」という視点で一緒になって考えるんです。そもそもどういった課題を解決するものなのかという基礎の部分から一緒に考えていくのがメドレーでは当たり前になっているという感じがします。 開発サイドもビジネスサイドも同じ方向を向いているので、提案などもちゃんとロジカルで筋が通っているものであれば通るというのは、すごく意見しがいがある と思います。そのための相談なんかも、もちろんしやすいですし、とても良い文化だなと感じています。 岡田 : 開発にあたって PM が 施策などを Issue として立ててくれるのですが、言語化が行き届いていて何が問題で、どうして実施するのか、その影響なんかがすごく分かりやすいという点はメドレーが大事にしている「ドキュメントドリブン」という文化を感じます。 そのような環境なので、大抵のことは最低限の文章のやり取りだけでスムーズに進みますし、上手くいかない状況になっても善後策などが立てやすくなっていると思います。 徳永 : メドレーは新卒入社の社員数は少ないので、中途入社の方がほとんどという環境です。入社してすぐは「自分の意見は通るのかな」とか「自分より後に入社した経験年数が長い中途入社の方とどう付き合おう」などが心配でした。でも メドレーでは「建設的に進める」という文化があるので、立場に関係なく議論できる環境があるので、とても仕事がしやすい です。自分の意見が例え間違っていたとしても議論が起きるということは、認識がズレていたということだからと軌道修正もできるので本当に働きやすいです。 また、とても良いなと思ったのが、部署や職種に関わらず Confluence の情報に誰でもアクセスできるという文化ですね。秘匿情報以外は基本的に全て Confluence でオープンになっているおかげで、自分とは直接関係ない部署の現在の動きなどがキャッチアップできるので、そういった人たちとコミュニケーションを取るときにもすごく助かります。 古川 : 徳永とかぶるところがあるんですが、「建設的に進める」という部分は非常にメドレーらしさを感じる文化です。例えば PM が「施策をこうしましょう」となっても、自分が「このフローってこうなった方が良いですよね」という意見を言えるし、そこを起点に 議論に発展してより良いものを作っていけるというのは本当に素晴らしい と感じています。 実際に自分がリードしていた施策の中でもエンジニア・ デザイナー・ PM ・カスタマーサクセスという立場が違うメンバー同士で改めて薬局の業務フローを整理しなおして、より良い仕様にできたりということがありました。 機能リリース後もちゃんと「あるべき姿」を目指して改善をできたりしたので、こういう考え方はとても仕事がしやすいです。 村上 : 自分からは「組織水準を高める」という文化について言及させてください。自分が関わっている電子カルテやレセコンという領域は深い業務知識が必要で、初めて関わった人からすると、そもそもどういうフローで機能が使われているかとか、特定の場合に何でこうなるんだろうというところが、理解しづらいんです。でも、自分のチームは新卒・中途問わず、まだ深いドメイン知識がない、といった状態からでも入って活躍しやすい環境だというのを感じています。 いきなり専門の業務知識が必要な開発というのはやはり難しいので、そうした部分と直接は関係しない周辺領域の開発から始めてもらって、徐々に電子カルテやレセコンに直接関係する開発に入ってもらえるようなオンボーディングができています。開発の中で、あるべき姿について議論になったりで色々なメンバーと話をしていくので、 医療業務のキャッチアップはかなりしやすい環境 だと思います。 もうひとつ「長期のカスタマー価値を追求する」という部分も文化を感じていて、主にマネージャーを含め、短期的な KPI に沿った開発よりも、長期的に顧客への価値提供に寄与できる開発を優先していくという意識が非常に強いのが良いと感じます。 特に今現在、社内で開発が進んでいる新規レセコンの開発については強く思いますね。 吉岡 : 自分が強く感じているメドレーの文化としては「ドキュメントドリブン」です。ミーティングなども、こういうことの結論を得るために協議する、というのが明確に分かる資料を事前に用意して行います。ですので、「これ何の時間だっけ?」みたいな状態になりにくいのが良いです。 あとは ミーティングによる同期的、Slack や Confluence などによる非同期のコミュニケーションを適材適所で全員が使いわけているので、そもそもコミュニケーションで無駄な行き違いのようなものも、ほとんど無い のも、仕事がしやすいと思っています。 もうひとつは、自分もやはりプロダクト志向の強さというところを感じています。現在はディレクターなどと一緒に開発をしていく体制になっているんですが、UI や顧客体験なども含めてエンジニアでも、ちゃんとプロダクトとしての理想の姿を考えて開発するという姿勢がとても強いです。自分の専門ではない領域でもきちんと考えながら開発をしていくので、やりがいがあります。 これからメドレーに入社する方へのメッセージ ── では最後になりますが、特に新卒でメドレーの入社を考えている方へのメッセージなどあれば、お伺いしたいです。 飯田 : そうですね、「先輩が新卒に対してとても期待してくれている」というのは伝えたいと思います。自分の場合、研修が終わって 3 ヶ月経ったぐらいで、シゴトークのインフラ環境を全部刷新するという大きなプロジェクトのリードを任せてもらえたんです。もちろん SRE の先輩などと協力しつつ進めたものだったんですが、 研修終わってすぐにそんな大きなプロジェクトを裁量持って進められるような環境なので、すごくやりがいがあります 。 岡田 : 稲本(人材プラットフォーム CTO)が「新卒だから」みたいな接し方をせずに、いちエンジニアとして接してくれているのは個人的に嬉しいポイントです。また 責任を持った上で裁量持って自由に動いていける業務環境があるのが、すごく良い です。ちゃんとプロダクトの事を考えて開発をしたい人にはおすすめできる環境だと思います。 徳永 : 新卒の良いところは「同期」感を持てるところかなと思います。今もランチ等でこのメンバーと技術的なところなどを気軽に相談できるのはとても良いです。 切磋琢磨していく環境じゃないかなと思っているので、そうした環境を求めるならすごく良い と思います。 古川 : 受け身で仕事を行うのではなく、ガツガツと自分の方から求めにいく姿勢の人には、すごくマッチする会社だと思います。せっかく裁量持って業務を進めることができる環境なので、 遠慮せずにがんがんと物事進めることができる人には最高 なんじゃないかと考えています。 自分はインフラだけではなくて、サーバやフロントエンドも開発していきたいと考えているんですが、小規模なプロジェクトであれば全て行える環境なため、自分一人でプロジェクトを完結することができるのは、性に合っているなと思ってます。周りのサポートや先輩との壁打ちなどはちゃんとやってもらえるので、とても勉強になり成長できると思います。 村上 : メドレーで開発をしていくについれて、医療ドメインという領域で自分が関わっていることが人の役に立っているんだなというのが日々実感できるところは良いです。特に色々な医療機関のサポートができるというプロダクトに関わっているので、直接医療機関やその先にいる患者さんの 役に立っているという実感は、正直 1 年目で感じられるものではないと思っていたので、良い驚き です。 また大きいデータを取り扱うという経験ができているのも貴重だなと感じています。現在のプロダクトでは契約医療機関も非常に多いですし、その大量のデータの設計を変更したりというところを、裁量持って実施できるのは良い経験になっています。 吉岡 : メドレーの「プロダクト志向」を持っている先輩エンジニアと働けるというのはとても良い経験だと思っています。一般的にはエンジニアは技術さえあればという感じになりやすかったりすると思うのですが、メドレーではもちろん新しい技術なども使いながら、それを いかにプロダクトやその先のユーザへの価値提供に繋げるかを考えている方が集っている ので、そういう思考でプロダクト開発ができているのはすごく勉強になります。 ── ありがとうございました! 本当に 1 年で皆さんが濃い業務経験を積んでいるのが分かるインタビューになりました。 さいごに それぞれ異なるチームや業務内容ですが、新卒エンジニアでも裁量を持って業務に臨めることや、プロダクトの重要な部分の開発にどんどん関わっていけることが伝わるインタビューとなりました。 メドレーは新卒入社のエンジニアも積極的に募集していますので、今回気になったという方はお気軽にカジュアル面談をしましょう! open.talentio.com open.talentio.com