はじめに こんにちは。 CLINICS カルテ の QA 担当をしております QA エンジニアの かみむら です。 医療プラットフォーム本部 CLINICS 開発チームでは、2年以上に渡り自社レセコン 1 の開発を行っています。プロダクトは公開済みであるものの鋭意追加機能の開発を続けており、今後も継続して開発する予定になっています。 QA エンジニアの大切な役割の1つとして、プロセス改善があります。ふりかえりはプロセス改善のアイデアを関係者全員で話し合うための肝となるアクティビティですので、規模の大小問わず取り入れたいものです。 この記事ではレセコン開発におけるプロジェクト体制構築時の黎明期から現在の成熟期に至るまでに行った、四半期毎のふりかえり手法や効果について、かいつまんでご紹介します。 プロジェクトの状況とふりかえりの進め方 まずレセコン開発プロジェクトのチーム体制についてご説明します。メンバーは、初期から現在まで総勢20〜25名前後（内訳：ディレクター3〜5名、カスタマーサクセス2〜4名、エンジニア10数名、QA エンジニア1〜2名）で取り組んでいます。 ※開発詳細については、 Tech Studio MATSUE オフィスのご紹介 からご覧いただけます！ 元々医療プラットフォーム本部では四半期に一度、個々のプロジェクトの垣根なくプロダクトチーム全体でのふりかえりを KPT（ Keep / Problem / Try ）で行うという習慣があります。そこで、レセコン開発のプロジェクトも時期を合わせてふりかえりを行うようにすればメンバーの気持ちと時間の調整がしやすいのではないか？ と考え、プロジェクトマネージャーに相談しながら各四半期の終わり頃に開催することとしました。 当プロジェクトには専任メンバーもいますが、多くのメンバーは他のプロジェクトとの兼務のためふりかえりへの時間の使い方と開催形式には気をつかいました。 特に開発メンバーの半数近くが別拠点（松江オフィス）に勤務していることもあり、東京オフィスメンバーとのコミュニケーションのため完全オンライン形式にする必要がありました（同じ拠点同士は対面で集まり、拠点間のみオンライン接続するというやり方もありますが、経験上個々の発言が拾いにくい等負の側面があることをわかっていたため、全員オンラインでの参加としました）。 具体的には次のように進めています。 ”今期の課題感” についてプロジェクトマネージャーとすり合わせ、その課題に合いそうなふりかえり手法を選定する（参加者の対象をどこまで広げるか、数名ずつのグループに分ける場合はどういう基準で分けるか等も相談） 候補に挙げた手法とタイムテーブルを Confluence に書き起こし、前日までに Slack で事前周知 Google Meet でオンライン開催する ふりかえり結果の要約 / 抜粋 / アクションプランを Confluence に追記し、参加者に Slack で報告 毎回以下の形式を守って執り行いました。 完全オンライン形式で開催 参加者の事前準備はほぼ無し ふりかえりイベント当日にかける時間は1時間だけ 一般的には四半期という長期間を対象とするふりかえりの場合、半日くらいかけて開催してもおかしくないと思うのですが、対象者全員が空いている時間帯を確保するのもなかなか難しく「1時間以内でやり切り最大の効果をあげること」を自分に課していました。 具体例① 「象、死んだ魚、嘔吐」 開催時期：初期（2022年6月） 参加メンバー：12名 まだ「ふりかえりをこうしていこう！」とも決めていなかった頃の、最初に行ったふりかえりは「 象、死んだ魚、嘔吐 」という手法を採用しました。 Airbnb 創業者が考案したコミュニケーション改善の手法で、以下の3要素から構成されています。 「象」…存在しないかのように扱われるが、誰もが知っている事実。 「死んだ魚」…過去に起こったこと（悪臭と腐敗）を乗り越えて、将来への期待を設定する。 「嘔吐」…普段は言わないこと、言うのを控えていることなどをぶっちゃけて話す。 最初期のためチーム全体としても遠慮し合うような雰囲気がまだうっすらとあり、松江と東京の物理的な距離感も相まって「もう全員でぶっちゃけて話そうよ！」という思いでこの手法を選びました（個人的にも気になっていた手法でした）。 少し前に行ったプロダクトチーム全体のふりかえりから、現在のチームは「良い面も悪い面もコミュニケーションのあり方がキーポイントになっていそう」という推測が出ていたことも背景にありました。 「象」「死んだ魚」「嘔吐」それぞれでボードを使用 「四半期毎の開催」と述べましたが、実はこの最初のチーム全員のふりかえりまではプロジェクト開始から半年経過しています。そのためレセコン開発プロジェクト全体としては初回のふりかえりということもあり、「そもそも何のためにふりかえりを行うのか」「このプロジェクトの目的（共通目標）は何か」という部分は特に丁寧に対話する時間をとりました。 ツールは Jamboard を使用し、心理的安全性を高めるためクローズドな状態にして「本当に何でも言える」環境をつくることに腐心しました。 結果、1時間のうち集中して話ができたのは30分程度ですが、かなりいろんなぶっちゃけ話ができたと思います。もちろんこのふりかえりだけが要因ではないですが、その後のプロジェクトメンバー内のコミュニケーションは徐々に滑らかになっていってるな、チームビルディングという意味でも効果があったかなと感じました。 具体例② 「ポジティブふりかえりマッピング」 開催時期：初回リリース後（2023年3月） 参加メンバー：25名 初回リリース後の運用期間を経て次の大型リリースの準備を進めていく中で、関わる人数やロールも一段と増えた時期でした。これまではふりかえりに参加していなかったカスタマーサクセス等のメンバーも招待し、次の期へのキックオフを兼ねて明るい雰囲気で未来へつながっていくお話をしたく、ポジティブふりかえりマッピングを使うことにしました。 この手法は、はじめに「どんな道をたどったにせよ、当時の知識・技術・能力・利用可能なリソース・状況の中で、みんなができる限り最高の仕事をしたはずです。それを心から信じます。」という声明を発表し、「あなたは⚪︎⚪︎プロジェクトにいましたね。どういう点が素晴らしかったですか？」と質問を続けるという作法で進みます。メンバーが次々と素晴らしい点を挙げていくので、みんなが嬉しく和やかな雰囲気になります。 当時のConfluence 参加メンバーも大人数になってきたので、5名ずつのグループをあらかじめつくっておき、グループ毎の Jamboard へ意見を記載してもらいました。持ち時間は10分です。時間短縮のためブレイクアウトルームはつくらず、25名全員がメインルームに参加したままの状態で各自ふせんをつくっていきます。 キックオフとして有用な場になるよう、この回のグループ編成は以下の点に配慮しました。 同じグループ内でなるべく職種が偏らないように 年齢（経験年数）も偏らないように とはいえまったく業務上の接点もないということがないように 次に各グループ毎に挙がった内容が近いふせんを寄せたり、ペンで囲んだりといったグルーピングを5分で行います。 最後に各グループの結果を全員で見ていき要約する時間を15分とります。 メンバーからは「プロジェクトの推進における各自の機動力、組織力が素晴らしい」「効率化のための仕組みが効いて次期稼働可能な状態までもっていけた」等の意見が挙がりました。 素晴らしい点をお互いに見つけて言語化することによって労いや協力の気持ちが思い出され、ふりかえりとしてもキックオフとしても良いイベントになったかなと思います。 とあるグループの最終形態 具体例③ 「温度計」 開催時期：成長期（2023年12月） 参加メンバー：19名 自社レセコンが稼働する医療機関数の更なる増加と診療報酬改定 2 に向けて、持続的なプロダクト開発とオペレーション改善のための話し合いを行いたい時期でした。 このふりかえりでは、以下の3点を重要課題と位置づけました。 良いところを伸ばす 問題を解消する 関係の質を高める この3点の目的にマッチする「温度計」という手法は、チームメンバーが「チームに起きていること」「チームに望むこと」を報告し合います。現在位置から今後に視点を向けることを意識するため、以下の3ステップで進めました。 感謝・興奮 気づき・興味 提案・希望・願望 「温度計」という名の通り、中央に温度計のイラストを配置します。本来は縦長の用紙下部に低温（よくないこと）、上部にいくほど高温（興奮や願望）のふせんを貼る、というルールになっていますが、オンライン画面上ではスクロールが必要な状況を避けたかったため、各ステップのふせんの色を変えることにより（青→黄色→ピンク）温度感を表現することにしました。 「感謝・興奮」は全員で1つのボードを使用し、ありがとうの気持ちが溢れました 「大変だけど楽しい期だった」「チーム感があった」「インフラチームのおかげで開発・不具合対応に集中できた」等の意見があがり、初期から比べると本当に良いチームになっているなと感じました。 またこの頃から「⚪︎⚪︎に関する勉強会 / 品評会をしてみたい」という意見も徐々に増えてきており、一部実現したものもありますが未だにやれていないジャンルもあり、熱が冷めないうちに何らかの形で達成することが今後の課題です。 まとめ ここまで、実際に行ったふりかえり事例を3つご紹介しました。 最後に、どのふりかえりでも共通して行っていたことを踏まえてまとめます。 ふりかえりをする意義を再認識し、場をつくる 前回のふりかえりをふりかえる 他のメンバーが挙げた意見に賛成や近い意見がある場合は、ドット投票を行う 以下に詳しくご説明します。 ふりかえりをする意義を再認識し、場をつくる メンバー全員が「ふりかえり」に慣れているわけではなく、経験が少ないメンバーもいることから、「なぜふりかえりをするのか？」という意義については毎回冒頭で触れて、気持ちをつくっていくということをしていました。毎回別の言葉で、「たいへんな時ほど立ち止まって周りをみることが、これからも一緒に走っていく仲間として大切」のようなお話をしました。 会の前半は説明のため私が1人で話している時間も長めで、オンラインでは参加者の反応がわかりづらくちょっとした無音の時間が続いてしまいがちです。特別にアイスブレイクの時間をとっていないこともあり自然に場を盛り上げていくために、参加メンバーには「環境的にミュート解除しても問題ない人はなるべく声出してください〜」「スタンプくださーい」等と促してわいわいしてもらいました。 前回のふりかえりをふりかえる 四半期毎にふりかえりをする、というリズムもできたので、毎回冒頭で「前回はこういうふりかえりをしましたね」という「ふりかえりのふりかえり」をするようにしています。 あまり時間もとれないのでさらっと触れる程度ですが、今から行うふりかえりの気持ちをつくる上でも重要なパートかなと思っています。 誰かが挙げた意見に賛成や近い意見がある場合は、ドット投票を行う 「ドット投票」もふりかえりの手法の1つですが、あらかじめマークとなるアイコンを準備しておき、それを各自コピーして共感した他の人のふせんの近くに貼ってもらいました。 これによりみんなの関心がある課題が明確になって時間も短縮でき、取り上げる議題に集中できます。 ドット投票の例 ふりかえり手法の選定について さて、私がなぜ毎回課題感に合わせて最適な（と思われる）ふりかえり手法を使うことができたのか、それはふりかえり＆ Miro エバンジェリストである びばさん の『 ふりかえりチートシート 』にかなりお世話になっているためです。 このシートには各ふりかえり手法がどの目的（解消したい課題）に適しているか詳細にマッピングされているので、「今回のふりかえりで解決 / 達成したいこと」を2〜3つ選定し、その中から合いそうな手法をピックアップして詳しく調べてから1時間でやり切れる形式に落とし込んでいきました。 また、課題によっては1つの手法に収めず、複数の手法を組み合わせて使うことも多いです。前述の「ドット投票」もそうですが、軽量な手法である「感謝」（自分が感謝すべき人たちのことを考え、精一杯の誠意を込めて「ありがとう」と言う）は他の手法と組み合わせてアイスブレイク的に使ったりもしました。 このように、毎回異なるふりかえり手法を取り入れることのできる柔軟な組織で一緒に働いてみたい！ と思った方はお気軽に カジュアル面談 をお申し込みください。 良いふりかえり事例を持っている、あるいはふりかえりの仕方に悩んでいる等とにかく語りたい方も一度お話ししてみましょう！ 最後までお読みいただき、ありがとうございました。 Reference&Thanks（ふりかえりの参考図書） ふりかえり読本 場作り編～ふりかえるその前に～ Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き Footnotes レセプトコンピュータ。レセプト（診療報酬明細書）を作成するためのコンピュータ。 https://clinics-cloud.com/column/64 ↩ 通常2年毎に行われる、医療行為に対する点数の見直し。 https://clinics-cloud.com/column/406 ↩

はじめに こんにちは。 CLINICS カルテ の QA 担当をしております QA エンジニアの かみむら です。 医療プラットフォーム本部 CLINICS 開発チームでは、2年以上に渡り自社レセコン 1 の開発を行っています。プロダクトは公開済みであるものの鋭意追加機能の開発を続けており、今後も継続して開発する予定になっています。 QA エンジニアの大切な役割の1つとして、プロセス改善があります。ふりかえりはプロセス改善のアイデアを関係者全員で話し合うための肝となるアクティビティですので、規模の大小問わず取り入れたいものです。 この記事ではレセコン開発におけるプロジェクト体制構築時の黎明期から現在の成熟期に至るまでに行った、四半期毎のふりかえり手法や効果について、かいつまんでご紹介します。 プロジェクトの状況とふりかえりの進め方 まずレセコン開発プロジェクトのチーム体制についてご説明します。メンバーは、初期から現在まで総勢20〜25名前後（内訳：ディレクター3〜5名、カスタマーサクセス2〜4名、エンジニア10数名、QA エンジニア1〜2名）で取り組んでいます。 ※開発詳細については、 Tech Studio MATSUE オフィスのご紹介 からご覧いただけます！ 元々医療プラットフォーム本部では四半期に一度、個々のプロジェクトの垣根なくプロダクトチーム全体でのふりかえりを KPT（ Keep / Problem / Try ）で行うという習慣があります。そこで、レセコン開発のプロジェクトも時期を合わせてふりかえりを行うようにすればメンバーの気持ちと時間の調整がしやすいのではないか？ と考え、プロジェクトマネージャーに相談しながら各四半期の終わり頃に開催することとしました。 当プロジェクトには専任メンバーもいますが、多くのメンバーは他のプロジェクトとの兼務のためふりかえりへの時間の使い方と開催形式には気をつかいました。 特に開発メンバーの半数近くが別拠点（松江オフィス）に勤務していることもあり、東京オフィスメンバーとのコミュニケーションのため完全オンライン形式にする必要がありました（同じ拠点同士は対面で集まり、拠点間のみオンライン接続するというやり方もありますが、経験上個々の発言が拾いにくい等負の側面があることをわかっていたため、全員オンラインでの参加としました）。 具体的には次のように進めています。 ”今期の課題感” についてプロジェクトマネージャーとすり合わせ、その課題に合いそうなふりかえり手法を選定する（参加者の対象をどこまで広げるか、数名ずつのグループに分ける場合はどういう基準で分けるか等も相談） 候補に挙げた手法とタイムテーブルを Confluence に書き起こし、前日までに Slack で事前周知 Google Meet でオンライン開催する ふりかえり結果の要約 / 抜粋 / アクションプランを Confluence に追記し、参加者に Slack で報告 毎回以下の形式を守って執り行いました。 完全オンライン形式で開催 参加者の事前準備はほぼ無し ふりかえりイベント当日にかける時間は1時間だけ 一般的には四半期という長期間を対象とするふりかえりの場合、半日くらいかけて開催してもおかしくないと思うのですが、対象者全員が空いている時間帯を確保するのもなかなか難しく「1時間以内でやり切り最大の効果をあげること」を自分に課していました。 具体例① 「象、死んだ魚、嘔吐」 開催時期：初期（2022年6月） 参加メンバー：12名 まだ「ふりかえりをこうしていこう！」とも決めていなかった頃の、最初に行ったふりかえりは「 象、死んだ魚、嘔吐 」という手法を採用しました。 Airbnb 創業者が考案したコミュニケーション改善の手法で、以下の3要素から構成されています。 「象」…存在しないかのように扱われるが、誰もが知っている事実。 「死んだ魚」…過去に起こったこと（悪臭と腐敗）を乗り越えて、将来への期待を設定する。 「嘔吐」…普段は言わないこと、言うのを控えていることなどをぶっちゃけて話す。 最初期のためチーム全体としても遠慮し合うような雰囲気がまだうっすらとあり、松江と東京の物理的な距離感も相まって「もう全員でぶっちゃけて話そうよ！」という思いでこの手法を選びました（個人的にも気になっていた手法でした）。 少し前に行ったプロダクトチーム全体のふりかえりから、現在のチームは「良い面も悪い面もコミュニケーションのあり方がキーポイントになっていそう」という推測が出ていたことも背景にありました。 「象」「死んだ魚」「嘔吐」それぞれでボードを使用 「四半期毎の開催」と述べましたが、実はこの最初のチーム全員のふりかえりまではプロジェクト開始から半年経過しています。そのためレセコン開発プロジェクト全体としては初回のふりかえりということもあり、「そもそも何のためにふりかえりを行うのか」「このプロジェクトの目的（共通目標）は何か」という部分は特に丁寧に対話する時間をとりました。 ツールは Jamboard を使用し、心理的安全性を高めるためクローズドな状態にして「本当に何でも言える」環境をつくることに腐心しました。 結果、1時間のうち集中して話ができたのは30分程度ですが、かなりいろんなぶっちゃけ話ができたと思います。もちろんこのふりかえりだけが要因ではないですが、その後のプロジェクトメンバー内のコミュニケーションは徐々に滑らかになっていってるな、チームビルディングという意味でも効果があったかなと感じました。 具体例② 「ポジティブふりかえりマッピング」 開催時期：初回リリース後（2023年3月） 参加メンバー：25名 初回リリース後の運用期間を経て次の大型リリースの準備を進めていく中で、関わる人数やロールも一段と増えた時期でした。これまではふりかえりに参加していなかったカスタマーサクセス等のメンバーも招待し、次の期へのキックオフを兼ねて明るい雰囲気で未来へつながっていくお話をしたく、ポジティブふりかえりマッピングを使うことにしました。 この手法は、はじめに「どんな道をたどったにせよ、当時の知識・技術・能力・利用可能なリソース・状況の中で、みんなができる限り最高の仕事をしたはずです。それを心から信じます。」という声明を発表し、「あなたは⚪︎⚪︎プロジェクトにいましたね。どういう点が素晴らしかったですか？」と質問を続けるという作法で進みます。メンバーが次々と素晴らしい点を挙げていくので、みんなが嬉しく和やかな雰囲気になります。 当時のConfluence 参加メンバーも大人数になってきたので、5名ずつのグループをあらかじめつくっておき、グループ毎の Jamboard へ意見を記載してもらいました。持ち時間は10分です。時間短縮のためブレイクアウトルームはつくらず、25名全員がメインルームに参加したままの状態で各自ふせんをつくっていきます。 キックオフとして有用な場になるよう、この回のグループ編成は以下の点に配慮しました。 同じグループ内でなるべく職種が偏らないように 年齢（経験年数）も偏らないように とはいえまったく業務上の接点もないということがないように 次に各グループ毎に挙がった内容が近いふせんを寄せたり、ペンで囲んだりといったグルーピングを5分で行います。 最後に各グループの結果を全員で見ていき要約する時間を15分とります。 メンバーからは「プロジェクトの推進における各自の機動力、組織力が素晴らしい」「効率化のための仕組みが効いて次期稼働可能な状態までもっていけた」等の意見が挙がりました。 素晴らしい点をお互いに見つけて言語化することによって労いや協力の気持ちが思い出され、ふりかえりとしてもキックオフとしても良いイベントになったかなと思います。 とあるグループの最終形態 具体例③ 「温度計」 開催時期：成長期（2023年12月） 参加メンバー：19名 自社レセコンが稼働する医療機関数の更なる増加と診療報酬改定 2 に向けて、持続的なプロダクト開発とオペレーション改善のための話し合いを行いたい時期でした。 このふりかえりでは、以下の3点を重要課題と位置づけました。 良いところを伸ばす 問題を解消する 関係の質を高める この3点の目的にマッチする「温度計」という手法は、チームメンバーが「チームに起きていること」「チームに望むこと」を報告し合います。現在位置から今後に視点を向けることを意識するため、以下の3ステップで進めました。 感謝・興奮 気づき・興味 提案・希望・願望 「温度計」という名の通り、中央に温度計のイラストを配置します。本来は縦長の用紙下部に低温（よくないこと）、上部にいくほど高温（興奮や願望）のふせんを貼る、というルールになっていますが、オンライン画面上ではスクロールが必要な状況を避けたかったため、各ステップのふせんの色を変えることにより（青→黄色→ピンク）温度感を表現することにしました。 「感謝・興奮」は全員で1つのボードを使用し、ありがとうの気持ちが溢れました 「大変だけど楽しい期だった」「チーム感があった」「インフラチームのおかげで開発・不具合対応に集中できた」等の意見があがり、初期から比べると本当に良いチームになっているなと感じました。 またこの頃から「⚪︎⚪︎に関する勉強会 / 品評会をしてみたい」という意見も徐々に増えてきており、一部実現したものもありますが未だにやれていないジャンルもあり、熱が冷めないうちに何らかの形で達成することが今後の課題です。 まとめ ここまで、実際に行ったふりかえり事例を3つご紹介しました。 最後に、どのふりかえりでも共通して行っていたことを踏まえてまとめます。 ふりかえりをする意義を再認識し、場をつくる 前回のふりかえりをふりかえる 他のメンバーが挙げた意見に賛成や近い意見がある場合は、ドット投票を行う 以下に詳しくご説明します。 ふりかえりをする意義を再認識し、場をつくる メンバー全員が「ふりかえり」に慣れているわけではなく、経験が少ないメンバーもいることから、「なぜふりかえりをするのか？」という意義については毎回冒頭で触れて、気持ちをつくっていくということをしていました。毎回別の言葉で、「たいへんな時ほど立ち止まって周りをみることが、これからも一緒に走っていく仲間として大切」のようなお話をしました。 会の前半は説明のため私が1人で話している時間も長めで、オンラインでは参加者の反応がわかりづらくちょっとした無音の時間が続いてしまいがちです。特別にアイスブレイクの時間をとっていないこともあり自然に場を盛り上げていくために、参加メンバーには「環境的にミュート解除しても問題ない人はなるべく声出してください〜」「スタンプくださーい」等と促してわいわいしてもらいました。 前回のふりかえりをふりかえる 四半期毎にふりかえりをする、というリズムもできたので、毎回冒頭で「前回はこういうふりかえりをしましたね」という「ふりかえりのふりかえり」をするようにしています。 あまり時間もとれないのでさらっと触れる程度ですが、今から行うふりかえりの気持ちをつくる上でも重要なパートかなと思っています。 誰かが挙げた意見に賛成や近い意見がある場合は、ドット投票を行う 「ドット投票」もふりかえりの手法の1つですが、あらかじめマークとなるアイコンを準備しておき、それを各自コピーして共感した他の人のふせんの近くに貼ってもらいました。 これによりみんなの関心がある課題が明確になって時間も短縮でき、取り上げる議題に集中できます。 ドット投票の例 ふりかえり手法の選定について さて、私がなぜ毎回課題感に合わせて最適な（と思われる）ふりかえり手法を使うことができたのか、それはふりかえり＆ Miro エバンジェリストである びばさん の『 ふりかえりチートシート 』にかなりお世話になっているためです。 このシートには各ふりかえり手法がどの目的（解消したい課題）に適しているか詳細にマッピングされているので、「今回のふりかえりで解決 / 達成したいこと」を2〜3つ選定し、その中から合いそうな手法をピックアップして詳しく調べてから1時間でやり切れる形式に落とし込んでいきました。 また、課題によっては1つの手法に収めず、複数の手法を組み合わせて使うことも多いです。前述の「ドット投票」もそうですが、軽量な手法である「感謝」（自分が感謝すべき人たちのことを考え、精一杯の誠意を込めて「ありがとう」と言う）は他の手法と組み合わせてアイスブレイク的に使ったりもしました。 このように、毎回異なるふりかえり手法を取り入れることのできる柔軟な組織で一緒に働いてみたい！ と思った方はお気軽に カジュアル面談 をお申し込みください。 良いふりかえり事例を持っている、あるいはふりかえりの仕方に悩んでいる等とにかく語りたい方も一度お話ししてみましょう！ 最後までお読みいただき、ありがとうございました。 Reference&Thanks（ふりかえりの参考図書） ふりかえり読本 場作り編～ふりかえるその前に～ Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き Footnotes レセプトコンピュータ。レセプト（診療報酬明細書）を作成するためのコンピュータ。 https://clinics-cloud.com/column/64 ↩ 通常2年毎に行われる、医療行為に対する点数の見直し。 https://clinics-cloud.com/column/406 ↩

はじめに こんにちは。 CLINICS カルテ の QA 担当をしております QA エンジニアの かみむら です。 医療プラットフォーム本部 CLINICS 開発チームでは、2年以上に渡り自社レセコン 1 の開発を行っています。プロダクトは公開済みであるものの鋭意追加機能の開発を続けており、今後も継続して開発する予定になっています。 QA エンジニアの大切な役割の1つとして、プロセス改善があります。ふりかえりはプロセス改善のアイデアを関係者全員で話し合うための肝となるアクティビティですので、規模の大小問わず取り入れたいものです。 この記事ではレセコン開発におけるプロジェクト体制構築時の黎明期から現在の成熟期に至るまでに行った、四半期毎のふりかえり手法や効果について、かいつまんでご紹介します。 プロジェクトの状況とふりかえりの進め方 まずレセコン開発プロジェクトのチーム体制についてご説明します。メンバーは、初期から現在まで総勢20〜25名前後（内訳：ディレクター3〜5名、カスタマーサクセス2〜4名、エンジニア10数名、QA エンジニア1〜2名）で取り組んでいます。 ※開発詳細については、 Tech Studio MATSUE オフィスのご紹介 からご覧いただけます！ 元々医療プラットフォーム本部では四半期に一度、個々のプロジェクトの垣根なくプロダクトチーム全体でのふりかえりを KPT（ Keep / Problem / Try ）で行うという習慣があります。そこで、レセコン開発のプロジェクトも時期を合わせてふりかえりを行うようにすればメンバーの気持ちと時間の調整がしやすいのではないか？ と考え、プロジェクトマネージャーに相談しながら各四半期の終わり頃に開催することとしました。 当プロジェクトには専任メンバーもいますが、多くのメンバーは他のプロジェクトとの兼務のためふりかえりへの時間の使い方と開催形式には気をつかいました。 特に開発メンバーの半数近くが別拠点（松江オフィス）に勤務していることもあり、東京オフィスメンバーとのコミュニケーションのため完全オンライン形式にする必要がありました（同じ拠点同士は対面で集まり、拠点間のみオンライン接続するというやり方もありますが、経験上個々の発言が拾いにくい等負の側面があることをわかっていたため、全員オンラインでの参加としました）。 具体的には次のように進めています。 ”今期の課題感” についてプロジェクトマネージャーとすり合わせ、その課題に合いそうなふりかえり手法を選定する（参加者の対象をどこまで広げるか、数名ずつのグループに分ける場合はどういう基準で分けるか等も相談） 候補に挙げた手法とタイムテーブルを Confluence に書き起こし、前日までに Slack で事前周知 Google Meet でオンライン開催する ふりかえり結果の要約 / 抜粋 / アクションプランを Confluence に追記し、参加者に Slack で報告 毎回以下の形式を守って執り行いました。 完全オンライン形式で開催 参加者の事前準備はほぼ無し ふりかえりイベント当日にかける時間は1時間だけ 一般的には四半期という長期間を対象とするふりかえりの場合、半日くらいかけて開催してもおかしくないと思うのですが、対象者全員が空いている時間帯を確保するのもなかなか難しく「1時間以内でやり切り最大の効果をあげること」を自分に課していました。 具体例① 「象、死んだ魚、嘔吐」 開催時期：初期（2022年6月） 参加メンバー：12名 まだ「ふりかえりをこうしていこう！」とも決めていなかった頃の、最初に行ったふりかえりは「 象、死んだ魚、嘔吐 」という手法を採用しました。 Airbnb 創業者が考案したコミュニケーション改善の手法で、以下の3要素から構成されています。 「象」…存在しないかのように扱われるが、誰もが知っている事実。 「死んだ魚」…過去に起こったこと（悪臭と腐敗）を乗り越えて、将来への期待を設定する。 「嘔吐」…普段は言わないこと、言うのを控えていることなどをぶっちゃけて話す。 最初期のためチーム全体としても遠慮し合うような雰囲気がまだうっすらとあり、松江と東京の物理的な距離感も相まって「もう全員でぶっちゃけて話そうよ！」という思いでこの手法を選びました（個人的にも気になっていた手法でした）。 少し前に行ったプロダクトチーム全体のふりかえりから、現在のチームは「良い面も悪い面もコミュニケーションのあり方がキーポイントになっていそう」という推測が出ていたことも背景にありました。 「象」「死んだ魚」「嘔吐」それぞれでボードを使用 「四半期毎の開催」と述べましたが、実はこの最初のチーム全員のふりかえりまではプロジェクト開始から半年経過しています。そのためレセコン開発プロジェクト全体としては初回のふりかえりということもあり、「そもそも何のためにふりかえりを行うのか」「このプロジェクトの目的（共通目標）は何か」という部分は特に丁寧に対話する時間をとりました。 ツールは Jamboard を使用し、心理的安全性を高めるためクローズドな状態にして「本当に何でも言える」環境をつくることに腐心しました。 結果、1時間のうち集中して話ができたのは30分程度ですが、かなりいろんなぶっちゃけ話ができたと思います。もちろんこのふりかえりだけが要因ではないですが、その後のプロジェクトメンバー内のコミュニケーションは徐々に滑らかになっていってるな、チームビルディングという意味でも効果があったかなと感じました。 具体例② 「ポジティブふりかえりマッピング」 開催時期：初回リリース後（2023年3月） 参加メンバー：25名 初回リリース後の運用期間を経て次の大型リリースの準備を進めていく中で、関わる人数やロールも一段と増えた時期でした。これまではふりかえりに参加していなかったカスタマーサクセス等のメンバーも招待し、次の期へのキックオフを兼ねて明るい雰囲気で未来へつながっていくお話をしたく、ポジティブふりかえりマッピングを使うことにしました。 この手法は、はじめに「どんな道をたどったにせよ、当時の知識・技術・能力・利用可能なリソース・状況の中で、みんなができる限り最高の仕事をしたはずです。それを心から信じます。」という声明を発表し、「あなたは⚪︎⚪︎プロジェクトにいましたね。どういう点が素晴らしかったですか？」と質問を続けるという作法で進みます。メンバーが次々と素晴らしい点を挙げていくので、みんなが嬉しく和やかな雰囲気になります。 当時のConfluence 参加メンバーも大人数になってきたので、5名ずつのグループをあらかじめつくっておき、グループ毎の Jamboard へ意見を記載してもらいました。持ち時間は10分です。時間短縮のためブレイクアウトルームはつくらず、25名全員がメインルームに参加したままの状態で各自ふせんをつくっていきます。 キックオフとして有用な場になるよう、この回のグループ編成は以下の点に配慮しました。 同じグループ内でなるべく職種が偏らないように 年齢（経験年数）も偏らないように とはいえまったく業務上の接点もないということがないように 次に各グループ毎に挙がった内容が近いふせんを寄せたり、ペンで囲んだりといったグルーピングを5分で行います。 最後に各グループの結果を全員で見ていき要約する時間を15分とります。 メンバーからは「プロジェクトの推進における各自の機動力、組織力が素晴らしい」「効率化のための仕組みが効いて次期稼働可能な状態までもっていけた」等の意見が挙がりました。 素晴らしい点をお互いに見つけて言語化することによって労いや協力の気持ちが思い出され、ふりかえりとしてもキックオフとしても良いイベントになったかなと思います。 とあるグループの最終形態 具体例③ 「温度計」 開催時期：成長期（2023年12月） 参加メンバー：19名 自社レセコンが稼働する医療機関数の更なる増加と診療報酬改定 2 に向けて、持続的なプロダクト開発とオペレーション改善のための話し合いを行いたい時期でした。 このふりかえりでは、以下の3点を重要課題と位置づけました。 良いところを伸ばす 問題を解消する 関係の質を高める この3点の目的にマッチする「温度計」という手法は、チームメンバーが「チームに起きていること」「チームに望むこと」を報告し合います。現在位置から今後に視点を向けることを意識するため、以下の3ステップで進めました。 感謝・興奮 気づき・興味 提案・希望・願望 「温度計」という名の通り、中央に温度計のイラストを配置します。本来は縦長の用紙下部に低温（よくないこと）、上部にいくほど高温（興奮や願望）のふせんを貼る、というルールになっていますが、オンライン画面上ではスクロールが必要な状況を避けたかったため、各ステップのふせんの色を変えることにより（青→黄色→ピンク）温度感を表現することにしました。 「感謝・興奮」は全員で1つのボードを使用し、ありがとうの気持ちが溢れました 「大変だけど楽しい期だった」「チーム感があった」「インフラチームのおかげで開発・不具合対応に集中できた」等の意見があがり、初期から比べると本当に良いチームになっているなと感じました。 またこの頃から「⚪︎⚪︎に関する勉強会 / 品評会をしてみたい」という意見も徐々に増えてきており、一部実現したものもありますが未だにやれていないジャンルもあり、熱が冷めないうちに何らかの形で達成することが今後の課題です。 まとめ ここまで、実際に行ったふりかえり事例を3つご紹介しました。 最後に、どのふりかえりでも共通して行っていたことを踏まえてまとめます。 ふりかえりをする意義を再認識し、場をつくる 前回のふりかえりをふりかえる 他のメンバーが挙げた意見に賛成や近い意見がある場合は、ドット投票を行う 以下に詳しくご説明します。 ふりかえりをする意義を再認識し、場をつくる メンバー全員が「ふりかえり」に慣れているわけではなく、経験が少ないメンバーもいることから、「なぜふりかえりをするのか？」という意義については毎回冒頭で触れて、気持ちをつくっていくということをしていました。毎回別の言葉で、「たいへんな時ほど立ち止まって周りをみることが、これからも一緒に走っていく仲間として大切」のようなお話をしました。 会の前半は説明のため私が1人で話している時間も長めで、オンラインでは参加者の反応がわかりづらくちょっとした無音の時間が続いてしまいがちです。特別にアイスブレイクの時間をとっていないこともあり自然に場を盛り上げていくために、参加メンバーには「環境的にミュート解除しても問題ない人はなるべく声出してください〜」「スタンプくださーい」等と促してわいわいしてもらいました。 前回のふりかえりをふりかえる 四半期毎にふりかえりをする、というリズムもできたので、毎回冒頭で「前回はこういうふりかえりをしましたね」という「ふりかえりのふりかえり」をするようにしています。 あまり時間もとれないのでさらっと触れる程度ですが、今から行うふりかえりの気持ちをつくる上でも重要なパートかなと思っています。 誰かが挙げた意見に賛成や近い意見がある場合は、ドット投票を行う 「ドット投票」もふりかえりの手法の1つですが、あらかじめマークとなるアイコンを準備しておき、それを各自コピーして共感した他の人のふせんの近くに貼ってもらいました。 これによりみんなの関心がある課題が明確になって時間も短縮でき、取り上げる議題に集中できます。 ドット投票の例 ふりかえり手法の選定について さて、私がなぜ毎回課題感に合わせて最適な（と思われる）ふりかえり手法を使うことができたのか、それはふりかえり＆ Miro エバンジェリストである びばさん の『 ふりかえりチートシート 』にかなりお世話になっているためです。 このシートには各ふりかえり手法がどの目的（解消したい課題）に適しているか詳細にマッピングされているので、「今回のふりかえりで解決 / 達成したいこと」を2〜3つ選定し、その中から合いそうな手法をピックアップして詳しく調べてから1時間でやり切れる形式に落とし込んでいきました。 また、課題によっては1つの手法に収めず、複数の手法を組み合わせて使うことも多いです。前述の「ドット投票」もそうですが、軽量な手法である「感謝」（自分が感謝すべき人たちのことを考え、精一杯の誠意を込めて「ありがとう」と言う）は他の手法と組み合わせてアイスブレイク的に使ったりもしました。 このように、毎回異なるふりかえり手法を取り入れることのできる柔軟な組織で一緒に働いてみたい！ と思った方はお気軽に カジュアル面談 をお申し込みください。 良いふりかえり事例を持っている、あるいはふりかえりの仕方に悩んでいる等とにかく語りたい方も一度お話ししてみましょう！ 最後までお読みいただき、ありがとうございました。 Reference&Thanks（ふりかえりの参考図書） ふりかえり読本 場作り編～ふりかえるその前に～ Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き Footnotes レセプトコンピュータ。レセプト（診療報酬明細書）を作成するためのコンピュータ。 https://clinics-cloud.com/column/64 ↩ 通常2年毎に行われる、医療行為に対する点数の見直し。 https://clinics-cloud.com/column/406 ↩

こんにちは。人材プラットフォーム本部プロダクト開発室 第五開発グループ所属の寺内です。 新卒からメドレーに入社して今年で 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 を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味を持っていただいた方からのご連絡をお待ちしております。 メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 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/