こんにちは、医療プラットフォーム本部・プロダクト開発室・第1開発グループ所属の加藤です。 オンライン診療・オンライン服薬指導アプリ「CLINICS」 の開発を担当しています。 今回は CLINICS で採用している Next.js と Server-side Rendering (SSR) についてお話ししたいと思います。 Next.js は昨今注目を集めている React ベースの Web フレームワークです。 これから Web フロントエンドの開発を始めるにあたって採用を検討している方も多いのではないでしょうか。 Next.js といえば React コンポーネントをサーバー上で実行して HTML を返す SSR に対応しているのが大きな特徴です。 SSR には様々なメリットがある一方で、採用にあたって自分たちのプロダクトに SSR は不要なのではないかといった懸念や Node.js の実行環境の運用コストを気にする声もよく耳にします。 この記事ではメドレーでの Next.js, SSR の採用事例を紹介しつつ、採用にあたって一般に懸念される点を実際に採用してみた上での所感も交えてお話しできればと思っています。 メドレーの医療プラットフォーム事業と CLINICS アプリについて まずはメドレーの医療プラットフォーム事業と CLINICS アプリについて簡単に紹介させてください。 メドレーの医療プラットフォーム事業は、2016年にオンライン診療システムとしてリリースされた 「CLINICS」 を原点としています。 当時は医療機関の方が操作する業務システム部分と患者さん向けの iOS/Android アプリとその Web 版が存在するという構成でした。 その後 CLINICS には電子カルテなどの様々な機能が追加され、現在ではオンライン診療に留まらず医療機関の様々な業務を支援するクラウド診療支援システムへと発展しています。 また、2020年にリリースされたかかりつけ薬局支援システム 「Pharms」 や2022年にリリースされたクラウド歯科支援システム 「Dentis」 もプロダクトのラインナップに加わり、より多くの医療機関の業務を支援するプラットフォームとしてサービスの規模を拡大しています。 医療機関向けの業務システムは医科・歯科・調剤薬局とそれぞれの業務特性に合わせてプロダクトが分かれている一方で、患者さん向けの機能はすべて CLINICS アプリに集約されています。 業務システムの機能拡充に伴って CLINICS アプリの機能も拡充されており、現在ではオンライン服薬指導機能や処方箋の事前送信機能など様々な機能が追加されています。 今回お話しするのはこの CLINICS アプリの Web 版 (以下、CLINICS) のフロントエンド開発についてです。 Next.js 採用のモチベーション CLINICS アプリはリリース以後続々と機能が拡張されてきたのですが、こうした開発を支えるため 2021年に大規模なリニューアルを実施しました。 特に Web 版はリニューアルのタイミングでフルスクラッチで実装し直す選択をしています。 リニューアル以前のトップページ 現在のトップページ リニューアル以前の CLINICS はログインの前後で実装が分かれており、この点がフルスクラッチでの実装を選択する大きなモチベーションとなりました。 CLINICS は開発当初から Ruby on Rails で開発されているのですが、患者さん向けのページは Rails のテンプレートエンジンを用いて実装されている部分と SPA として実装されている部分が混在していました。 医療機関の検索や詳細などの検索エンジンからの流入を確保したいページではテンプレートエンジンを用いて HTML を直接レスポンスする、ログインページや予約ページなどの操作性を重視したページでは SPA として実装されている、といった具合です。 こうしたテンプレートエンジンと SPA の併用構成では、ログインの前後で一貫したユーザー体験を提供するのは困難だと感じていました。 例えば、同じ機能がログイン前と後とで2つ存在する箇所もあり、ユーザーから見るとログインを挟んで UI が変わってしまい、あまり良いユーザー体験とは言えない状態でした。 もちろんこういった課題はログイン前後の両方のページの UI を丁寧に設計することで解決が可能ではありますが、異なる技術スタックで同じような機能を実装しつつ UI の一貫性を保つのは容易ではありません。 そういった背景からリニューアルではログイン前後での実装を一本化する方針を立てていました。 実装を一本化する上で SSR に対応している Next.js は非常に魅力的な選択肢でした。 SSR には初期表示のパフォーマンス向上などのメリットもあるのですが、採用にあたっては SEO 面でのメリットを重視していました。 近年では Google のクローラーが JavaScript を実行してくれるのですが、直接 HTML をレスポンスできるのであればその方がより確実だと判断しました。 これが Next.js を採用するに至った最大の理由です。 ちなみに、この当時は App Router がリリースされる前だったため、 Pages Router で開発を開始しました。 以降の内容も基本的に Pages Router を前提としてお話ししていきますが、 App Router や他のフレームワークを使用している場合でも SSR についての考え方は共通している部分が多いので少しでも参考にしていただけたら幸いです。 Server-side Rendering の仕組み Server-side Rendering (SSR) とは、Next.js や Remix などの React ベースのフレームワークが持つ機能のひとつです。 SSR という用語は昨今の React に関する話題の中ではよく耳にする言葉ですが、実は React の公式ドキュメントに SSR とは何かという記述は存在していません。 それでは React 本体にはサーバー環境向けの機能が存在しないのかというとそうではなく、React は コンポーネントから HTML を生成するための API を提供しています。 Next.js や Remix はこうした API を利用してサーバー環境で HTML を生成しつつブラウザ環境では従来の SPA のような振る舞いを実現する機能を提供しており、こうした機能には SSR という名前が付けられています。 例えば、Next.js の Pages Router では getServerSideProps を使用してリクエスト毎に HTML を生成する機能を SSR と呼んでいます。 各フレームワークによってサーバー側でのデータ取得の方法は異なりますが、React コンポーネントから HTML を生成する仕組みは共通しています。 サーバー上で HTML を生成すると言うとテンプレートエンジンなどを用いる場合と変わらないように感じられるかもしれませんが、SSR には ハイドレーション という仕組みが存在するのが大きな特徴です。 生成された HTML はクライアントにレスポンスされてブラウザ上で表示されるのですが、この時点ではイベントハンドラーが DOM にアタッチされておらず、ユーザーの操作に対して反応することができない状態です。 そこで React はブラウザ上で再度コンポーネントをレンダリングしてイベントハンドラーを DOM にアタッチします。 この処理はハイドレーションと呼ばれています。 ハイドレーションが行われるとアプリケーションはユーザー操作に反応することができるようになります。 アプリケーションによってはいわゆる Client-side Rendering (CSR) と呼ばれる useEffect によるデータの取得と追加の描画が行われる場合もあります。 さらに、ハイドレーションが行われた状態からページ遷移が行われる場合には history API が使用されます。 一連の流れをシーケンス図にすると以下のようになります。 このように SSR を使用しているアプリケーションでもハイドレーションが行われた後は従来の SPA と同様に振る舞います。 そのため、Context API や Redux などの状態管理ライブラリを使用してページを跨いで状態を共有することも可能です。 こういった特徴から考えると、SSR はこれまでの React と対立するものではなく、むしろその機能を一層強化するものと言えるでしょう。 CLINICS での活用事例の紹介 ここからは実際にどういった形で Next.js と SSR を利用しているのか、CLINICS の活用事例を紹介していきます。 CLINICS のシステム構成は以下のようになっています。 (実際にはもう少し複雑な構成を取っているのですが、今回の説明では簡略化しています) CLINICS の Next.js サーバーは固有のデータベースを持っておらず、必要なデータはすべてバックエンドの API から取得しています。 SSR の際には Next.js サーバーから、CSR の際にはブラウザから API にリクエストが送信されます。 セッション情報については API サーバー側で管理しており、Next.js サーバー側にはセッション情報を共有しない方針を取っています。 SEO 面でのメリットを重視していたため、SSR するのはログイン不要で閲覧可能なページのみで十分だろうと判断しました。 そのため、SSR をする際にはログイン不要で取得できる情報のみを表示し、ログインが必要な情報を表示する際には CSR を使用しています。 SSR を使用しているページでも部分的に CSR を組み合わせて使用しており、ページによっては SSR を用いずに全体が CSR で実装されているケースもあります。 感覚的には従来の SPA をベースとして部分的に SSR を組み合わせていると言っても良いかもしれません。 採用して良かったと感じている点 ここからは実際に Next.js を使ってみた所感を交えてお話ししていこうと思います。 まずは、Next.js を採用して良かったと感じている点についてです。 全体的な開発体験 フルスクラッチで実装し直す上で Next.js は良い選択だったと感じています。 Next.js というと SSR のイメージが強いかもしれませんが、SSR を抜きにしても SPA の開発に必要な要素は一通り備わっています。 Webpack やトランスパイラなどのビルドツールの設定がデフォルトで含まれており、React のプロジェクトを新規に立ち上げる際には非常に便利なフレームワークだと感じています。 CLINICS では CSS 関連で追加のライブラリを使用しているのを除けば、ほとんどの実装を Next.js と React の標準機能だけで開発しています。 SEO 面での扱いやすさ こちらは Next.js を採用するにあたって重視していた点なのですが、やはり SSR でサーバーから直接レスポンスを返せるという点で SEO 面では扱いやすいと感じています。 title タグや meta タグなどももちろんですが、HTTP ステータスコードも制御できるため、クローラーに意図を伝える伝統的な方法がそのまま使える点は非常に便利です。 SEO とは直接関係ありませんが、SNS でリンクがシェアされる際の OGP 用の meta タグを動的に生成したいといったケースへの対応も容易です。 とはいえ、近年は Google のクローラーも JavaScript を実行してくれるので SPA が必ずしも SEO 的に不利というわけではありません。 クローラーが JavaScript を理解する能力は年々向上しているので、適切に設計された SPA であれば SEO 的に問題ないというケースも多いようです。 こうしたクローラーの進歩や実装上のテクニックも踏まえると SSR の SEO 面でのメリットはあくまでその扱いやすさという観点で考えると良いかもしれません。 パフォーマンスの向上 SSR を取り入れるにあたってパフォーマンス面について特に意識していたわけではないのですが、実際に SSR を使ってみて FCP (First Contentful Paint) や LCP (Largest Contentful Paint) といった初期表示の速度を表す指標の改善に効果があるなと感じています。 CSR では JS でのデータ取得が完了して始めて LCP 要素が表示されるケースが多いため、JS ファイルのダウンロードや実行の分だけ FCP や LCP が遅延しやすい傾向にあります。 SSR ではこうした JS のダウンロードや実行の時間が減る分、初期表示のパフォーマンス改善が期待できます。 体感的にもローディングインジケーターの表示を挟まずにコンテンツが表示されるため、ユーザーにとってはより快適な体験となるのではないかと感じています。 また、SSR 以外にも Next.js は画像の最適化やコードスプリッティングなどのパフォーマンス向上に役立つ機能を多く提供しているため、安定したパフォーマンスの Web アプリケーションを開発する上では非常に心強い存在です。 セッション管理についての反省点 Next.js そのものについて不便に感じている点はあまりないのですが、SSR を取り入れるにあたってセッション管理についてはよく考えておくべきだったと反省している部分もあります。 従来の SPA であればセッション管理は API サーバーが管理するというのが一般的ですが、SSR を採用する場合では Next.js サーバーと API サーバーが存在するという構成になるケースが多いかと思います。 この場合、Next.js サーバーと API サーバーのどちらでセッションを管理するのか、セッション情報を共有するのか、共有するのであればどのような方法で共有するのかといった点で複数の選択肢が考えられます。 CLINICS では前述の通り API サーバーでセッションを管理して Next.js サーバーとの間でセッション情報を共有しない構成を採用しています。 こうした構成の都合で Next.js サーバーでセッション情報を扱うことができないため、ログイン済みのユーザー固有の情報は SSR することができず、CSR で取得して描画する必要があります。 このようにして SSR と CSR を組み合わせた場合、CSR で取得したデータを描画する際にレイアウトシフトが発生しやすくなります。 また、ログイン済みのユーザーに対しては検索結果をカスタマイズしたり並び替えたりといった要件への対応も難しくなってしまいます。 こういった面で SSR と CSR を組み合わせざるを得ない現状の認証構成には課題があると感じています。 こうした課題を解消するためにも、今後はセッション情報を Next.js サーバーと共有する構成へと変更し、CSR している部分を SSR する形に変更していきたいと考えています。 このように SSR を活用する場合には従来の SPA よりもセッション管理の選択肢が増えるため、セッション管理については特に慎重に考える必要があると感じています。 SSR を今は必要としていないというケースでも、将来的な導入に備えてセッション管理について少し考えを巡らせておくと良いかもしれません。 Next.js の採用を検討している方へ 最後に、これから Next.js を採用しようとしている方が気になっているのではないかと思われるポイントについてお話ししていこうと思います。 Next.js を採用するにあたって最も気になるポイントはやはり Node.js の実行環境の運用コストではないでしょうか。 Next.js では一部の例外を除けば SSR を使用するか否かに関わらず実行には Node.js サーバーが必要となります。 SSR は必要としていないが Next.js の様々な恩恵を受けたいという開発者にとっては Node.js サーバーの運用コストが気になるところかと思います。 CLINICS では AWS ECS/Fargate で Next.js サーバーを運用しているのですが、Node.js の実行環境を運用するコストは確かに発生しているものの、現状ではそれほど大きな負担には感じていません。 API サーバーが別で存在する構成では Next.js サーバーが担うのはルーティングに従って API サーバーからデータを取得して SSR するといった比較的シンプルな役割になります。 そのため、データベースを扱うような本格的なバックエンドに比べると運用の手間は低く抑えられている印象です。 どうしても Node.js の実行環境を持たずに運用したいという場合には Static Exports というビルド時に HTML を含む静的アセットを出力する機能の利用も検討してみると良いかもしれません。 ただし、機能面でいくつかの制約があるので、採用を検討する際にはよく確認しておくことをお勧めします。 どちらかと言えば Static Exports は静的なサイトを構築するのに向いている機能であり、動的なコンテンツを扱うようなアプリケーションにはあまり向いていないというのが正直な感想です。 従来の SPA に多く見られるようなビルド済みの JavaScript, CSS などの静的アセットを S3 などのストレージに配置して HTML はバックエンドのサーバーから配信するといった構成が想定されていない点も注意が必要かと思います。 また、Next.js の採用にあたって App Router に追従すべきかというのも悩ましいポイントです。 App Router は Next.js 13 で導入された新しいルーティングシステムで、Server Components/Actions などの React の新機能もサポートしている点が魅力ですが、リリースから日が浅くまだしばらくは様子を見たいと考えている方も多いのではないでしょうか。 現状 CLINICS ではまだ App Router への移行は考えておらず実際の使用感などをお話しすることはできないのですが、ドキュメントを読む限りでは Pages Router の扱いにくい部分がうまく改善されている印象はあります。 ただ、Pages Router のルーティング機能と完全な互換性がない点が移行を考える上で最大のネックだと感じています。 こういった移行のコストや Next.js 自体が App Router への移行を推奨していることを踏まえると、今から新規に開発を始めるのであれば App Router で開発を始めてしまった方が無難な選択かもしれません。 総じて、Node.js サーバーの運用コストが許容できるか、App Router や Server Components/Actions に魅力を感じるかといった点が Next.js の採用を検討する上でのポイントになるのではないでしょうか。 まとめ CLINICS では Next.js を採用しており、SSR と CSR を併用する形で比較的ライトに SSR を取り入れてフロントエンドの開発を進めています。 当初は SEO 面でのメリットを重視していましたが、実際に使ってみるとパフォーマンスの向上や開発体験の向上など様々なメリットを感じています。 セッション管理については課題を抱えている部分もありますが、今後はそういった部分を改善しより一層 SSR の恩恵を受けられるようにしていきたいと考えています。 Next.js の他にも Remix と React Router の統合 が発表されるなど、さらに SSR を活用しやすい環境が整いつつあるという点でも、SSR の今後は非常に楽しみな部分が多いと感じています。

はじめに こんにちは。 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 ↩

はじめに こんにちは。 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 ↩

はじめに こんにちは。 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 を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味を持っていただいた方からのご連絡をお待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 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/

こんにちは。医療プラットフォーム本部プロダクト開発室 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