こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。 メドレーは、2024 年 11 月 23 日に九段坂上 KS ビルにて開催される JSConf JP 2024 にプレミアムスポンサーとして協賛します。 今回は、来週末に控えている JSConf JP 2024 で発表するスポンサーワークショップの内容について紹介します。 JSConf JP 2024 とは JSConf JP は、一般社団法人 Japan Node.js Association が主催する JavaScript の祭典です。 国内はもちろん、海外からも Web 開発者を招き、合計 4 トラックで Web 開発に関連する多数のセッションが予定されています。 公式サイト： https://jsconf.jp/2024/ スポンサーワークショップでは React コンポーネント設計について発表します 16:00 からトラック D にて、 クラウド診療支援システム CLINICS の開発で実践している React コンポーネント設計について、開発体制や医療業務システムの観点を踏まえて紹介します。 徹底解剖！医療業務システムの React コンポーネント設計 - 株式会社メドレー | JSConf JP 【ワークショップタイトル】 徹底解剖！医療業務システムの React コンポーネント設計 【ワークショップ詳細】 医療業務システムの Web フロントエンド開発では、高い安全性の要求に応えつつ、複雑化する医療業務に対して診療効率改善につながる質の高いユーザー体験を提供することが求められます。 加えて、長期利用を見据えた保守性の維持も重要です。 これらの要求に応えるため、私たちは約 4 年間の継続的なアーキテクチャ改善を通して React コンポーネント設計を確立してきました。 本セッションでは、メドレーの開発体制の背景を交えながら、クラウド診療支援システム CLINICS の Web フロントエンド開発で実践している React コンポーネント設計を紹介します。 具体的には次の内容を予定しています： コンポーネントレイヤーと分割粒度 独立性の高い複合コンポーネント設計とデザインパターン 代表的なフロントエンドロジックの分類とそれぞれの実装手法 クロスファンクショナル（非職能別）開発チームにおける Storybook 駆動開発の活用 開発速度と品質を両立するためのテスト戦略 発表予定内容の一部：コンポーネント分割粒度の紹介 ブースでメドレーのエンジニアとお話しましょう トラック D がある 2F の Communication Area にブースを出展します。 ブースでは、メドレーのプロダクトや使用技術、開発組織について、エンジニアとざっくばらんに交流できる場を設ける予定です。 休憩エリアの近くになっていますので、セッションの合間などにぜひお立ち寄りください。 おわりに 最後までお読み頂きありがとうございました。 当日のブースやワークショップでみなさまとお会いできることを楽しみにしております！

こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。 メドレーは、2024 年 11 月 23 日に九段坂上 KS ビルにて開催される JSConf JP 2024 にプレミアムスポンサーとして協賛します。 今回は、来週末に控えている JSConf JP 2024 で発表するスポンサーワークショップの内容について紹介します。 JSConf JP 2024 とは JSConf JP は、一般社団法人 Japan Node.js Association が主催する JavaScript の祭典です。 国内はもちろん、海外からも Web 開発者を招き、合計 4 トラックで Web 開発に関連する多数のセッションが予定されています。 公式サイト： https://jsconf.jp/2024/ スポンサーワークショップでは React コンポーネント設計について発表します 16:00 からトラック D にて、 クラウド診療支援システム CLINICS の開発で実践している React コンポーネント設計について、開発体制や医療業務システムの観点を踏まえて紹介します。 徹底解剖！医療業務システムの React コンポーネント設計 - 株式会社メドレー | JSConf JP 【ワークショップタイトル】 徹底解剖！医療業務システムの React コンポーネント設計 【ワークショップ詳細】 医療業務システムの Web フロントエンド開発では、高い安全性の要求に応えつつ、複雑化する医療業務に対して診療効率改善につながる質の高いユーザー体験を提供することが求められます。 加えて、長期利用を見据えた保守性の維持も重要です。 これらの要求に応えるため、私たちは約 4 年間の継続的なアーキテクチャ改善を通して React コンポーネント設計を確立してきました。 本セッションでは、メドレーの開発体制の背景を交えながら、クラウド診療支援システム CLINICS の Web フロントエンド開発で実践している React コンポーネント設計を紹介します。 具体的には次の内容を予定しています： コンポーネントレイヤーと分割粒度 独立性の高い複合コンポーネント設計とデザインパターン 代表的なフロントエンドロジックの分類とそれぞれの実装手法 クロスファンクショナル（非職能別）開発チームにおける Storybook 駆動開発の活用 開発速度と品質を両立するためのテスト戦略 発表予定内容の一部：コンポーネント分割粒度の紹介 ブースでメドレーのエンジニアとお話しましょう トラック D がある 2F の Communication Area にブースを出展します。 ブースでは、メドレーのプロダクトや使用技術、開発組織について、エンジニアとざっくばらんに交流できる場を設ける予定です。 休憩エリアの近くになっていますので、セッションの合間などにぜひお立ち寄りください。 おわりに 最後までお読み頂きありがとうございました。 当日のブースやワークショップでみなさまとお会いできることを楽しみにしております！

こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。 メドレーは、2024 年 11 月 23 日に九段坂上 KS ビルにて開催される JSConf JP 2024 にプレミアムスポンサーとして協賛します。 今回は、来週末に控えている JSConf JP 2024 で発表するスポンサーワークショップの内容について紹介します。 JSConf JP 2024 とは JSConf JP は、一般社団法人 Japan Node.js Association が主催する JavaScript の祭典です。 国内はもちろん、海外からも Web 開発者を招き、合計 4 トラックで Web 開発に関連する多数のセッションが予定されています。 公式サイト： https://jsconf.jp/2024/ スポンサーワークショップでは React コンポーネント設計について発表します 16:00 からトラック D にて、 クラウド診療支援システム CLINICS の開発で実践している React コンポーネント設計について、開発体制や医療業務システムの観点を踏まえて紹介します。 徹底解剖！医療業務システムの React コンポーネント設計 - 株式会社メドレー | JSConf JP 【ワークショップタイトル】 徹底解剖！医療業務システムの React コンポーネント設計 【ワークショップ詳細】 医療業務システムの Web フロントエンド開発では、高い安全性の要求に応えつつ、複雑化する医療業務に対して診療効率改善につながる質の高いユーザー体験を提供することが求められます。 加えて、長期利用を見据えた保守性の維持も重要です。 これらの要求に応えるため、私たちは約 4 年間の継続的なアーキテクチャ改善を通して React コンポーネント設計を確立してきました。 本セッションでは、メドレーの開発体制の背景を交えながら、クラウド診療支援システム CLINICS の Web フロントエンド開発で実践している React コンポーネント設計を紹介します。 具体的には次の内容を予定しています： コンポーネントレイヤーと分割粒度 独立性の高い複合コンポーネント設計とデザインパターン 代表的なフロントエンドロジックの分類とそれぞれの実装手法 クロスファンクショナル（非職能別）開発チームにおける Storybook 駆動開発の活用 開発速度と品質を両立するためのテスト戦略 発表予定内容の一部：コンポーネント分割粒度の紹介 ブースでメドレーのエンジニアとお話しましょう トラック D がある 2F の Communication Area にブースを出展します。 ブースでは、メドレーのプロダクトや使用技術、開発組織について、エンジニアとざっくばらんに交流できる場を設ける予定です。 休憩エリアの近くになっていますので、セッションの合間などにぜひお立ち寄りください。 おわりに 最後までお読み頂きありがとうございました。 当日のブースやワークショップでみなさまとお会いできることを楽しみにしております！

こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。 メドレーは、2024 年 11 月 23 日に九段坂上 KS ビルにて開催される JSConf JP 2024 にプレミアムスポンサーとして協賛します。 今回は、来週末に控えている JSConf JP 2024 で発表するスポンサーワークショップの内容について紹介します。 JSConf JP 2024 とは JSConf JP は、一般社団法人 Japan Node.js Association が主催する JavaScript の祭典です。 国内はもちろん、海外からも Web 開発者を招き、合計 4 トラックで Web 開発に関連する多数のセッションが予定されています。 公式サイト： https://jsconf.jp/2024/ スポンサーワークショップでは React コンポーネント設計について発表します 16:00 からトラック D にて、 クラウド診療支援システム CLINICS の開発で実践している React コンポーネント設計について、開発体制や医療業務システムの観点を踏まえて紹介します。 徹底解剖！医療業務システムの React コンポーネント設計 - 株式会社メドレー | JSConf JP 【ワークショップタイトル】 徹底解剖！医療業務システムの React コンポーネント設計 【ワークショップ詳細】 医療業務システムの Web フロントエンド開発では、高い安全性の要求に応えつつ、複雑化する医療業務に対して診療効率改善につながる質の高いユーザー体験を提供することが求められます。 加えて、長期利用を見据えた保守性の維持も重要です。 これらの要求に応えるため、私たちは約 4 年間の継続的なアーキテクチャ改善を通して React コンポーネント設計を確立してきました。 本セッションでは、メドレーの開発体制の背景を交えながら、クラウド診療支援システム CLINICS の Web フロントエンド開発で実践している React コンポーネント設計を紹介します。 具体的には次の内容を予定しています： コンポーネントレイヤーと分割粒度 独立性の高い複合コンポーネント設計とデザインパターン 代表的なフロントエンドロジックの分類とそれぞれの実装手法 クロスファンクショナル（非職能別）開発チームにおける Storybook 駆動開発の活用 開発速度と品質を両立するためのテスト戦略 発表予定内容の一部：コンポーネント分割粒度の紹介 ブースでメドレーのエンジニアとお話しましょう トラック D がある 2F の Communication Area にブースを出展します。 ブースでは、メドレーのプロダクトや使用技術、開発組織について、エンジニアとざっくばらんに交流できる場を設ける予定です。 休憩エリアの近くになっていますので、セッションの合間などにぜひお立ち寄りください。 おわりに 最後までお読み頂きありがとうございました。 当日のブースやワークショップでみなさまとお会いできることを楽しみにしております！

こんにちは。 かかりつけ薬局支援システム「Pharms」 の開発を担当している熊本です。先日、 総合医療アプリ「CLINICS」 の薬局検索機能のパフォーマンスを OpenSearch の導入により改善しましたので、その経緯と結果について話していきたいと思います。 医療プラットフォームのプロダクト紹介と構成 まずは私が所属する医療プラットフォーム（以下、医療 PF）のプロダクトをご紹介します。オンライン診療をはじめ様々な医療体験を提供する患者・生活者向けのプロダクトと、医療機関における業務効率と患者体験の向上を支援する事業者向けのプロダクトがあります。プロダクト間のデータ連携に関しては、患者統合基盤というプロダクトによって実現しています。 患者情報やその医療情報に関するデータに関しては患者統合基盤で保持していますが、薬局店舗のリストや営業時間など調剤薬局店舗に関するデータに関しては Pharms 側で保持しています。本記事では、この調剤薬局店舗に関するデータを扱う Pharms の API についてお話しします。 CLINICS の薬局検索機能 CLINICS にはお薬手帳や、お薬辞典、薬局検索など薬局に関する機能がいくつか存在します。 本記事ではその内の薬局検索機能についてお話しするため、簡単にご紹介します。 薬局名で検索できるのはもちろんのこと、マップの範囲検索や市区町村、受付日時などで絞り込むことでご自身の都合にあった薬局を探すことが可能です。 病院等で処方箋を受け取った後に、この薬局検索機能を使ってお薬を受け取りたい薬局を探し、その薬局に対して CLINICS から事前に処方箋を送信しておくことができます。待ち時間なくお薬を受け取ることができるので個人的にも愛用しています！ 他にも検索条件はいくつかあるのですが、オンラインで服薬指導を受けた際には Uber Eats により当日中にお薬を配達してくれる機能もあるので、当日配達に対応しているかどうかで絞り込むことも可能です。 この検索機能のバックエンドを Pharms の API が担っており、内部的には検索エンジンを使わず RDB による絞り込みで実現していました。 潜在課題の表層化 先ほどご紹介したように薬局検索機能はとても便利なのですが、 Pharms の事業成長に伴い以下のような課題も徐々に出てきました。 データ量と検索トラフィックが増加してきた データ量の増加に伴い検索時のレスポンスが遅くなり患者のユーザビリティが悪化してきた 検索条件の増加に伴い SQL クエリが複雑になり、変更難易度が上がり開発・運用の工数が肥大化してきた 潜在的な課題を認識しつつも何とか開発・運用を続けてきたのですが、複雑な組み合わせの検索をクローラーなどにより集中的に実行された場合、処理コストの高い SQL クエリが大量に発行されてしまいレイテンシ悪化が起きるようになってしまいました。 患者側のメトリクスは患者統合基盤チームでもモニタリングしていることもあり、患者統合基盤チームと連携してレイテンシ悪化の原因調査や対応策の検討に取り組み、迅速に一次対応を打つことができました。 異なる開発チームでも必要に応じて連携しながら課題解決に取り組めるところは弊社の特徴 かなと改めて感じました。 しかし、サーバの強化や SQL クエリの改善で対処していたものの、あくまで暫定的な対応であり、対応工数・インフラコストなども鑑みると恒久対応の優先度が上がってきました。 課題の対応に向けて 上述の課題の他に、開発プロセスの改善や品質向上に向けた取り組みなど、今後の機能開発を見据えて、一度足元の強化が必要という議論が Pharms 開発チームであったため、薬局検索機能のパフォーマンス改善に限らず「開発基盤改善」としてプロジェクトを発足し、集中的にチーム課題に向き合うことになりました。 ここに関しては、 プロダクトマネージャーと技術課題に関する目線合わせがスムーズにできた ことも、プロジェクトが早いタイミングで発足した一因であると思います。 Pharms の開発チームにおいてはプロダクトマネージャーが事業部出身であるため、開発計画を練る際には プロダクトマネージャー/テックリード がそれぞれ 攻め（KPI の達成を担うもの）/守り（事故リスクを減らすもの） の観点でやりたいことを列挙しフラットに議論する体制をとっています。普段から守りの観点も重視されている上で、既にユーザビリティに悪影響を及ぼしていることや、その影響範囲・対応工数など諸々を鑑みて意思決定が行われました。 対応 パフォーマンス問題への対応は2つの観点で行うこととし、現状課題の根本解決に向けて OpenSearch の導入を、再発防止と継続的な改善に向けてモニタリングの強化を行うことにしました。 OpenSearch の導入 設計・実装 OpenSearch を導入することになるのですが、他いくつかのプロダクトで導入実績があったことや、現状の技術構成に対する親和性、個人的にも過去に別プロダクトで導入経験があったことなどを踏まえて導入自体は非常に早い段階で決定しました。 まずは設計にも関わってくるのでどれくらいのレスポンスを目標とするか等の受け入れ要件を定め、その後 index の設計に移りました。 基本的には既存の検索条件に合わせたシンプルな設計になったのですが、予約枠の表現に関しては頭を悩まされました。 というのも、「準備でき次第」のような検索条件に関しては、営業時間内かどうかに加え、その枠が予約で埋まっていないかどうかも見る必要があり、その表現やリアルタイム性を加味して設計を行いました。 index の設計が終わった後は粛々と既存の検索ロジックを OpenSearch のクエリに置き換え、検索に関連するテーブルが更新される箇所に OpenSearch のドキュメントを更新する処理を追加していきました。 検証 実装後はデグレチェックと負荷耐久性の観点で検証を行いました。 医療 PF 内の QA エンジニアと連携し、各検索条件の組み合わせにおいて期待通りの結果が返却されるかどうかを検証しました。パターンが多かったのでテストケースの作成から実施まで協力してもらい助かりました。おかげさまで私としては Pharms の店舗画面や CLINICS を操作した際に正しく OpenSearch のドキュメントが更新されるかどうかの確認であったり、後述する負荷試験に集中的に取り組むことができました。 負荷試験は、検証環境に本番相当のデータ量を用意した上で、過去に最もレイテンシが悪化した際のリクエスト頻度を少し上回る頻度でリクエストを一定時間かけ続け、 AWSのトラブルシューティング などを参考にして基準を十分にクリアできるかどうかの観点で行いました。 リリース 諸々の検証をクリアしてリリースを迎えるのですが、ここでも少しだけ工夫した点をご紹介します。 一点目は Feature Flag を利用していつでも以前のロジック（OpenSearch を使わない検索）に戻せるようにしていた点です。念入りに検証したものの Pharms としては初めての OpenSearch 導入だったので、不測の自体が起きた場合でもデプロイなしにいつでも切り戻せるようにしていました。 二点目は index のエイリアス設定です。マッピングの変更などに伴い index の再構築を行う際にダウンタイムが発生しないようにエイリアスの設定をしていました。一般的なベストプラクティスだとは思いますが、ここに限らず過去の知見を活かしながら開発進行できたのは良かったかなと思います。 モニタリング強化 これまで OpenSearch 導入の話をしてきましたが、今後も継続してパフォーマンス劣化をより精度高く、迅速に検知できるようにするためにモニタリングも強化しました。 インフラ側は主に CloudWatch を使い、アプリケーション側は主に Datadog を使ってアラート設定を追加しました。 これまでも主要メトリクスに関しては設定していたのですが、今回調査・対応した知見を活かして、より詳細かつ網羅的に整備しました。 また、アラートが上がる前に気づけるようにするための取り組みとして、隔週で各メトリクスのトレンド監視をする会を設けており、CPU使用率などが徐々に悪化していないかを見るようにしています。 結果 結果として、薬局検索機能のパフォーマンスに関してはレイテンシが約90%も改善しました。 パフォーマンスを大幅に改善しユーザビリティを向上させられただけでなく、これまで CloudWatch Logs に流れていた巨大な SQL クエリのログを削減することができたので AWS のコスト改善にも繋がりました。 また、メトリクスのトレンド監視によりアラートが上がるその手前で怪しい動きを見つけることができ、実際に早期対応することができています。 まとめ 今回は CLINICS における薬局検索機能のパフォーマンス改善について、プロジェクト発足の背景からクロージングに至るまでの過程をご紹介しました。 Pharms 開発チームは少数体制なのですが、今回のように QA チームや患者統合基盤チームなど周りを柔軟に巻き込んだ動き方ができて非常に面白いです。また、プロダクトマネージャーなど非エンジニアの方とも建設的にそれぞれの観点で対等に議論ができる点も弊社の大きな特徴です。 メドレーは絶賛エンジニア募集中ですので、弊社の取り組みに興味を持っていただいた方やもっと話を聞いてみたいと思った方は是非ご連絡ください！最後まで読んでいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。 かかりつけ薬局支援システム「Pharms」 の開発を担当している熊本です。先日、 総合医療アプリ「CLINICS」 の薬局検索機能のパフォーマンスを OpenSearch の導入により改善しましたので、その経緯と結果について話していきたいと思います。 医療プラットフォームのプロダクト紹介と構成 まずは私が所属する医療プラットフォーム（以下、医療 PF）のプロダクトをご紹介します。オンライン診療をはじめ様々な医療体験を提供する患者・生活者向けのプロダクトと、医療機関における業務効率と患者体験の向上を支援する事業者向けのプロダクトがあります。プロダクト間のデータ連携に関しては、患者統合基盤というプロダクトによって実現しています。 患者情報やその医療情報に関するデータに関しては患者統合基盤で保持していますが、薬局店舗のリストや営業時間など調剤薬局店舗に関するデータに関しては Pharms 側で保持しています。本記事では、この調剤薬局店舗に関するデータを扱う Pharms の API についてお話しします。 CLINICS の薬局検索機能 CLINICS にはお薬手帳や、お薬辞典、薬局検索など薬局に関する機能がいくつか存在します。 本記事ではその内の薬局検索機能についてお話しするため、簡単にご紹介します。 薬局名で検索できるのはもちろんのこと、マップの範囲検索や市区町村、受付日時などで絞り込むことでご自身の都合にあった薬局を探すことが可能です。 病院等で処方箋を受け取った後に、この薬局検索機能を使ってお薬を受け取りたい薬局を探し、その薬局に対して CLINICS から事前に処方箋を送信しておくことができます。待ち時間なくお薬を受け取ることができるので個人的にも愛用しています！ 他にも検索条件はいくつかあるのですが、オンラインで服薬指導を受けた際には Uber Eats により当日中にお薬を配達してくれる機能もあるので、当日配達に対応しているかどうかで絞り込むことも可能です。 この検索機能のバックエンドを Pharms の API が担っており、内部的には検索エンジンを使わず RDB による絞り込みで実現していました。 潜在課題の表層化 先ほどご紹介したように薬局検索機能はとても便利なのですが、 Pharms の事業成長に伴い以下のような課題も徐々に出てきました。 データ量と検索トラフィックが増加してきた データ量の増加に伴い検索時のレスポンスが遅くなり患者のユーザビリティが悪化してきた 検索条件の増加に伴い SQL クエリが複雑になり、変更難易度が上がり開発・運用の工数が肥大化してきた 潜在的な課題を認識しつつも何とか開発・運用を続けてきたのですが、複雑な組み合わせの検索をクローラーなどにより集中的に実行された場合、処理コストの高い SQL クエリが大量に発行されてしまいレイテンシ悪化が起きるようになってしまいました。 患者側のメトリクスは患者統合基盤チームでもモニタリングしていることもあり、患者統合基盤チームと連携してレイテンシ悪化の原因調査や対応策の検討に取り組み、迅速に一次対応を打つことができました。 異なる開発チームでも必要に応じて連携しながら課題解決に取り組めるところは弊社の特徴 かなと改めて感じました。 しかし、サーバの強化や SQL クエリの改善で対処していたものの、あくまで暫定的な対応であり、対応工数・インフラコストなども鑑みると恒久対応の優先度が上がってきました。 課題の対応に向けて 上述の課題の他に、開発プロセスの改善や品質向上に向けた取り組みなど、今後の機能開発を見据えて、一度足元の強化が必要という議論が Pharms 開発チームであったため、薬局検索機能のパフォーマンス改善に限らず「開発基盤改善」としてプロジェクトを発足し、集中的にチーム課題に向き合うことになりました。 ここに関しては、 プロダクトマネージャーと技術課題に関する目線合わせがスムーズにできた ことも、プロジェクトが早いタイミングで発足した一因であると思います。 Pharms の開発チームにおいてはプロダクトマネージャーが事業部出身であるため、開発計画を練る際には プロダクトマネージャー/テックリード がそれぞれ 攻め（KPI の達成を担うもの）/守り（事故リスクを減らすもの） の観点でやりたいことを列挙しフラットに議論する体制をとっています。普段から守りの観点も重視されている上で、既にユーザビリティに悪影響を及ぼしていることや、その影響範囲・対応工数など諸々を鑑みて意思決定が行われました。 対応 パフォーマンス問題への対応は2つの観点で行うこととし、現状課題の根本解決に向けて OpenSearch の導入を、再発防止と継続的な改善に向けてモニタリングの強化を行うことにしました。 OpenSearch の導入 設計・実装 OpenSearch を導入することになるのですが、他いくつかのプロダクトで導入実績があったことや、現状の技術構成に対する親和性、個人的にも過去に別プロダクトで導入経験があったことなどを踏まえて導入自体は非常に早い段階で決定しました。 まずは設計にも関わってくるのでどれくらいのレスポンスを目標とするか等の受け入れ要件を定め、その後 index の設計に移りました。 基本的には既存の検索条件に合わせたシンプルな設計になったのですが、予約枠の表現に関しては頭を悩まされました。 というのも、「準備でき次第」のような検索条件に関しては、営業時間内かどうかに加え、その枠が予約で埋まっていないかどうかも見る必要があり、その表現やリアルタイム性を加味して設計を行いました。 index の設計が終わった後は粛々と既存の検索ロジックを OpenSearch のクエリに置き換え、検索に関連するテーブルが更新される箇所に OpenSearch のドキュメントを更新する処理を追加していきました。 検証 実装後はデグレチェックと負荷耐久性の観点で検証を行いました。 医療 PF 内の QA エンジニアと連携し、各検索条件の組み合わせにおいて期待通りの結果が返却されるかどうかを検証しました。パターンが多かったのでテストケースの作成から実施まで協力してもらい助かりました。おかげさまで私としては Pharms の店舗画面や CLINICS を操作した際に正しく OpenSearch のドキュメントが更新されるかどうかの確認であったり、後述する負荷試験に集中的に取り組むことができました。 負荷試験は、検証環境に本番相当のデータ量を用意した上で、過去に最もレイテンシが悪化した際のリクエスト頻度を少し上回る頻度でリクエストを一定時間かけ続け、 AWSのトラブルシューティング などを参考にして基準を十分にクリアできるかどうかの観点で行いました。 リリース 諸々の検証をクリアしてリリースを迎えるのですが、ここでも少しだけ工夫した点をご紹介します。 一点目は Feature Flag を利用していつでも以前のロジック（OpenSearch を使わない検索）に戻せるようにしていた点です。念入りに検証したものの Pharms としては初めての OpenSearch 導入だったので、不測の自体が起きた場合でもデプロイなしにいつでも切り戻せるようにしていました。 二点目は index のエイリアス設定です。マッピングの変更などに伴い index の再構築を行う際にダウンタイムが発生しないようにエイリアスの設定をしていました。一般的なベストプラクティスだとは思いますが、ここに限らず過去の知見を活かしながら開発進行できたのは良かったかなと思います。 モニタリング強化 これまで OpenSearch 導入の話をしてきましたが、今後も継続してパフォーマンス劣化をより精度高く、迅速に検知できるようにするためにモニタリングも強化しました。 インフラ側は主に CloudWatch を使い、アプリケーション側は主に Datadog を使ってアラート設定を追加しました。 これまでも主要メトリクスに関しては設定していたのですが、今回調査・対応した知見を活かして、より詳細かつ網羅的に整備しました。 また、アラートが上がる前に気づけるようにするための取り組みとして、隔週で各メトリクスのトレンド監視をする会を設けており、CPU使用率などが徐々に悪化していないかを見るようにしています。 結果 結果として、薬局検索機能のパフォーマンスに関してはレイテンシが約90%も改善しました。 パフォーマンスを大幅に改善しユーザビリティを向上させられただけでなく、これまで CloudWatch Logs に流れていた巨大な SQL クエリのログを削減することができたので AWS のコスト改善にも繋がりました。 また、メトリクスのトレンド監視によりアラートが上がるその手前で怪しい動きを見つけることができ、実際に早期対応することができています。 まとめ 今回は CLINICS における薬局検索機能のパフォーマンス改善について、プロジェクト発足の背景からクロージングに至るまでの過程をご紹介しました。 Pharms 開発チームは少数体制なのですが、今回のように QA チームや患者統合基盤チームなど周りを柔軟に巻き込んだ動き方ができて非常に面白いです。また、プロダクトマネージャーなど非エンジニアの方とも建設的にそれぞれの観点で対等に議論ができる点も弊社の大きな特徴です。 メドレーは絶賛エンジニア募集中ですので、弊社の取り組みに興味を持っていただいた方やもっと話を聞いてみたいと思った方は是非ご連絡ください！最後まで読んでいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。 かかりつけ薬局支援システム「Pharms」 の開発を担当している熊本です。先日、 総合医療アプリ「CLINICS」 の薬局検索機能のパフォーマンスを OpenSearch の導入により改善しましたので、その経緯と結果について話していきたいと思います。 医療プラットフォームのプロダクト紹介と構成 まずは私が所属する医療プラットフォーム（以下、医療 PF）のプロダクトをご紹介します。オンライン診療をはじめ様々な医療体験を提供する患者・生活者向けのプロダクトと、医療機関における業務効率と患者体験の向上を支援する事業者向けのプロダクトがあります。プロダクト間のデータ連携に関しては、患者統合基盤というプロダクトによって実現しています。 患者情報やその医療情報に関するデータに関しては患者統合基盤で保持していますが、薬局店舗のリストや営業時間など調剤薬局店舗に関するデータに関しては Pharms 側で保持しています。本記事では、この調剤薬局店舗に関するデータを扱う Pharms の API についてお話しします。 CLINICS の薬局検索機能 CLINICS にはお薬手帳や、お薬辞典、薬局検索など薬局に関する機能がいくつか存在します。 本記事ではその内の薬局検索機能についてお話しするため、簡単にご紹介します。 薬局名で検索できるのはもちろんのこと、マップの範囲検索や市区町村、受付日時などで絞り込むことでご自身の都合にあった薬局を探すことが可能です。 病院等で処方箋を受け取った後に、この薬局検索機能を使ってお薬を受け取りたい薬局を探し、その薬局に対して CLINICS から事前に処方箋を送信しておくことができます。待ち時間なくお薬を受け取ることができるので個人的にも愛用しています！ 他にも検索条件はいくつかあるのですが、オンラインで服薬指導を受けた際には Uber Eats により当日中にお薬を配達してくれる機能もあるので、当日配達に対応しているかどうかで絞り込むことも可能です。 この検索機能のバックエンドを Pharms の API が担っており、内部的には検索エンジンを使わず RDB による絞り込みで実現していました。 潜在課題の表層化 先ほどご紹介したように薬局検索機能はとても便利なのですが、 Pharms の事業成長に伴い以下のような課題も徐々に出てきました。 データ量と検索トラフィックが増加してきた データ量の増加に伴い検索時のレスポンスが遅くなり患者のユーザビリティが悪化してきた 検索条件の増加に伴い SQL クエリが複雑になり、変更難易度が上がり開発・運用の工数が肥大化してきた 潜在的な課題を認識しつつも何とか開発・運用を続けてきたのですが、複雑な組み合わせの検索をクローラーなどにより集中的に実行された場合、処理コストの高い SQL クエリが大量に発行されてしまいレイテンシ悪化が起きるようになってしまいました。 患者側のメトリクスは患者統合基盤チームでもモニタリングしていることもあり、患者統合基盤チームと連携してレイテンシ悪化の原因調査や対応策の検討に取り組み、迅速に一次対応を打つことができました。 異なる開発チームでも必要に応じて連携しながら課題解決に取り組めるところは弊社の特徴 かなと改めて感じました。 しかし、サーバの強化や SQL クエリの改善で対処していたものの、あくまで暫定的な対応であり、対応工数・インフラコストなども鑑みると恒久対応の優先度が上がってきました。 課題の対応に向けて 上述の課題の他に、開発プロセスの改善や品質向上に向けた取り組みなど、今後の機能開発を見据えて、一度足元の強化が必要という議論が Pharms 開発チームであったため、薬局検索機能のパフォーマンス改善に限らず「開発基盤改善」としてプロジェクトを発足し、集中的にチーム課題に向き合うことになりました。 ここに関しては、 プロダクトマネージャーと技術課題に関する目線合わせがスムーズにできた ことも、プロジェクトが早いタイミングで発足した一因であると思います。 Pharms の開発チームにおいてはプロダクトマネージャーが事業部出身であるため、開発計画を練る際には プロダクトマネージャー/テックリード がそれぞれ 攻め（KPI の達成を担うもの）/守り（事故リスクを減らすもの） の観点でやりたいことを列挙しフラットに議論する体制をとっています。普段から守りの観点も重視されている上で、既にユーザビリティに悪影響を及ぼしていることや、その影響範囲・対応工数など諸々を鑑みて意思決定が行われました。 対応 パフォーマンス問題への対応は2つの観点で行うこととし、現状課題の根本解決に向けて OpenSearch の導入を、再発防止と継続的な改善に向けてモニタリングの強化を行うことにしました。 OpenSearch の導入 設計・実装 OpenSearch を導入することになるのですが、他いくつかのプロダクトで導入実績があったことや、現状の技術構成に対する親和性、個人的にも過去に別プロダクトで導入経験があったことなどを踏まえて導入自体は非常に早い段階で決定しました。 まずは設計にも関わってくるのでどれくらいのレスポンスを目標とするか等の受け入れ要件を定め、その後 index の設計に移りました。 基本的には既存の検索条件に合わせたシンプルな設計になったのですが、予約枠の表現に関しては頭を悩まされました。 というのも、「準備でき次第」のような検索条件に関しては、営業時間内かどうかに加え、その枠が予約で埋まっていないかどうかも見る必要があり、その表現やリアルタイム性を加味して設計を行いました。 index の設計が終わった後は粛々と既存の検索ロジックを OpenSearch のクエリに置き換え、検索に関連するテーブルが更新される箇所に OpenSearch のドキュメントを更新する処理を追加していきました。 検証 実装後はデグレチェックと負荷耐久性の観点で検証を行いました。 医療 PF 内の QA エンジニアと連携し、各検索条件の組み合わせにおいて期待通りの結果が返却されるかどうかを検証しました。パターンが多かったのでテストケースの作成から実施まで協力してもらい助かりました。おかげさまで私としては Pharms の店舗画面や CLINICS を操作した際に正しく OpenSearch のドキュメントが更新されるかどうかの確認であったり、後述する負荷試験に集中的に取り組むことができました。 負荷試験は、検証環境に本番相当のデータ量を用意した上で、過去に最もレイテンシが悪化した際のリクエスト頻度を少し上回る頻度でリクエストを一定時間かけ続け、 AWSのトラブルシューティング などを参考にして基準を十分にクリアできるかどうかの観点で行いました。 リリース 諸々の検証をクリアしてリリースを迎えるのですが、ここでも少しだけ工夫した点をご紹介します。 一点目は Feature Flag を利用していつでも以前のロジック（OpenSearch を使わない検索）に戻せるようにしていた点です。念入りに検証したものの Pharms としては初めての OpenSearch 導入だったので、不測の自体が起きた場合でもデプロイなしにいつでも切り戻せるようにしていました。 二点目は index のエイリアス設定です。マッピングの変更などに伴い index の再構築を行う際にダウンタイムが発生しないようにエイリアスの設定をしていました。一般的なベストプラクティスだとは思いますが、ここに限らず過去の知見を活かしながら開発進行できたのは良かったかなと思います。 モニタリング強化 これまで OpenSearch 導入の話をしてきましたが、今後も継続してパフォーマンス劣化をより精度高く、迅速に検知できるようにするためにモニタリングも強化しました。 インフラ側は主に CloudWatch を使い、アプリケーション側は主に Datadog を使ってアラート設定を追加しました。 これまでも主要メトリクスに関しては設定していたのですが、今回調査・対応した知見を活かして、より詳細かつ網羅的に整備しました。 また、アラートが上がる前に気づけるようにするための取り組みとして、隔週で各メトリクスのトレンド監視をする会を設けており、CPU使用率などが徐々に悪化していないかを見るようにしています。 結果 結果として、薬局検索機能のパフォーマンスに関してはレイテンシが約90%も改善しました。 パフォーマンスを大幅に改善しユーザビリティを向上させられただけでなく、これまで CloudWatch Logs に流れていた巨大な SQL クエリのログを削減することができたので AWS のコスト改善にも繋がりました。 また、メトリクスのトレンド監視によりアラートが上がるその手前で怪しい動きを見つけることができ、実際に早期対応することができています。 まとめ 今回は CLINICS における薬局検索機能のパフォーマンス改善について、プロジェクト発足の背景からクロージングに至るまでの過程をご紹介しました。 Pharms 開発チームは少数体制なのですが、今回のように QA チームや患者統合基盤チームなど周りを柔軟に巻き込んだ動き方ができて非常に面白いです。また、プロダクトマネージャーなど非エンジニアの方とも建設的にそれぞれの観点で対等に議論ができる点も弊社の大きな特徴です。 メドレーは絶賛エンジニア募集中ですので、弊社の取り組みに興味を持っていただいた方やもっと話を聞いてみたいと思った方は是非ご連絡ください！最後まで読んでいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。 かかりつけ薬局支援システム「Pharms」 の開発を担当している熊本です。先日、 総合医療アプリ「CLINICS」 の薬局検索機能のパフォーマンスを OpenSearch の導入により改善しましたので、その経緯と結果について話していきたいと思います。 医療プラットフォームのプロダクト紹介と構成 まずは私が所属する医療プラットフォーム（以下、医療 PF）のプロダクトをご紹介します。オンライン診療をはじめ様々な医療体験を提供する患者・生活者向けのプロダクトと、医療機関における業務効率と患者体験の向上を支援する事業者向けのプロダクトがあります。プロダクト間のデータ連携に関しては、患者統合基盤というプロダクトによって実現しています。 患者情報やその医療情報に関するデータに関しては患者統合基盤で保持していますが、薬局店舗のリストや営業時間など調剤薬局店舗に関するデータに関しては Pharms 側で保持しています。本記事では、この調剤薬局店舗に関するデータを扱う Pharms の API についてお話しします。 CLINICS の薬局検索機能 CLINICS にはお薬手帳や、お薬辞典、薬局検索など薬局に関する機能がいくつか存在します。 本記事ではその内の薬局検索機能についてお話しするため、簡単にご紹介します。 薬局名で検索できるのはもちろんのこと、マップの範囲検索や市区町村、受付日時などで絞り込むことでご自身の都合にあった薬局を探すことが可能です。 病院等で処方箋を受け取った後に、この薬局検索機能を使ってお薬を受け取りたい薬局を探し、その薬局に対して CLINICS から事前に処方箋を送信しておくことができます。待ち時間なくお薬を受け取ることができるので個人的にも愛用しています！ 他にも検索条件はいくつかあるのですが、オンラインで服薬指導を受けた際には Uber Eats により当日中にお薬を配達してくれる機能もあるので、当日配達に対応しているかどうかで絞り込むことも可能です。 この検索機能のバックエンドを Pharms の API が担っており、内部的には検索エンジンを使わず RDB による絞り込みで実現していました。 潜在課題の表層化 先ほどご紹介したように薬局検索機能はとても便利なのですが、 Pharms の事業成長に伴い以下のような課題も徐々に出てきました。 データ量と検索トラフィックが増加してきた データ量の増加に伴い検索時のレスポンスが遅くなり患者のユーザビリティが悪化してきた 検索条件の増加に伴い SQL クエリが複雑になり、変更難易度が上がり開発・運用の工数が肥大化してきた 潜在的な課題を認識しつつも何とか開発・運用を続けてきたのですが、複雑な組み合わせの検索をクローラーなどにより集中的に実行された場合、処理コストの高い SQL クエリが大量に発行されてしまいレイテンシ悪化が起きるようになってしまいました。 患者側のメトリクスは患者統合基盤チームでもモニタリングしていることもあり、患者統合基盤チームと連携してレイテンシ悪化の原因調査や対応策の検討に取り組み、迅速に一次対応を打つことができました。 異なる開発チームでも必要に応じて連携しながら課題解決に取り組めるところは弊社の特徴 かなと改めて感じました。 しかし、サーバの強化や SQL クエリの改善で対処していたものの、あくまで暫定的な対応であり、対応工数・インフラコストなども鑑みると恒久対応の優先度が上がってきました。 課題の対応に向けて 上述の課題の他に、開発プロセスの改善や品質向上に向けた取り組みなど、今後の機能開発を見据えて、一度足元の強化が必要という議論が Pharms 開発チームであったため、薬局検索機能のパフォーマンス改善に限らず「開発基盤改善」としてプロジェクトを発足し、集中的にチーム課題に向き合うことになりました。 ここに関しては、 プロダクトマネージャーと技術課題に関する目線合わせがスムーズにできた ことも、プロジェクトが早いタイミングで発足した一因であると思います。 Pharms の開発チームにおいてはプロダクトマネージャーが事業部出身であるため、開発計画を練る際には プロダクトマネージャー/テックリード がそれぞれ 攻め（KPI の達成を担うもの）/守り（事故リスクを減らすもの） の観点でやりたいことを列挙しフラットに議論する体制をとっています。普段から守りの観点も重視されている上で、既にユーザビリティに悪影響を及ぼしていることや、その影響範囲・対応工数など諸々を鑑みて意思決定が行われました。 対応 パフォーマンス問題への対応は2つの観点で行うこととし、現状課題の根本解決に向けて OpenSearch の導入を、再発防止と継続的な改善に向けてモニタリングの強化を行うことにしました。 OpenSearch の導入 設計・実装 OpenSearch を導入することになるのですが、他いくつかのプロダクトで導入実績があったことや、現状の技術構成に対する親和性、個人的にも過去に別プロダクトで導入経験があったことなどを踏まえて導入自体は非常に早い段階で決定しました。 まずは設計にも関わってくるのでどれくらいのレスポンスを目標とするか等の受け入れ要件を定め、その後 index の設計に移りました。 基本的には既存の検索条件に合わせたシンプルな設計になったのですが、予約枠の表現に関しては頭を悩まされました。 というのも、「準備でき次第」のような検索条件に関しては、営業時間内かどうかに加え、その枠が予約で埋まっていないかどうかも見る必要があり、その表現やリアルタイム性を加味して設計を行いました。 index の設計が終わった後は粛々と既存の検索ロジックを OpenSearch のクエリに置き換え、検索に関連するテーブルが更新される箇所に OpenSearch のドキュメントを更新する処理を追加していきました。 検証 実装後はデグレチェックと負荷耐久性の観点で検証を行いました。 医療 PF 内の QA エンジニアと連携し、各検索条件の組み合わせにおいて期待通りの結果が返却されるかどうかを検証しました。パターンが多かったのでテストケースの作成から実施まで協力してもらい助かりました。おかげさまで私としては Pharms の店舗画面や CLINICS を操作した際に正しく OpenSearch のドキュメントが更新されるかどうかの確認であったり、後述する負荷試験に集中的に取り組むことができました。 負荷試験は、検証環境に本番相当のデータ量を用意した上で、過去に最もレイテンシが悪化した際のリクエスト頻度を少し上回る頻度でリクエストを一定時間かけ続け、 AWSのトラブルシューティング などを参考にして基準を十分にクリアできるかどうかの観点で行いました。 リリース 諸々の検証をクリアしてリリースを迎えるのですが、ここでも少しだけ工夫した点をご紹介します。 一点目は Feature Flag を利用していつでも以前のロジック（OpenSearch を使わない検索）に戻せるようにしていた点です。念入りに検証したものの Pharms としては初めての OpenSearch 導入だったので、不測の自体が起きた場合でもデプロイなしにいつでも切り戻せるようにしていました。 二点目は index のエイリアス設定です。マッピングの変更などに伴い index の再構築を行う際にダウンタイムが発生しないようにエイリアスの設定をしていました。一般的なベストプラクティスだとは思いますが、ここに限らず過去の知見を活かしながら開発進行できたのは良かったかなと思います。 モニタリング強化 これまで OpenSearch 導入の話をしてきましたが、今後も継続してパフォーマンス劣化をより精度高く、迅速に検知できるようにするためにモニタリングも強化しました。 インフラ側は主に CloudWatch を使い、アプリケーション側は主に Datadog を使ってアラート設定を追加しました。 これまでも主要メトリクスに関しては設定していたのですが、今回調査・対応した知見を活かして、より詳細かつ網羅的に整備しました。 また、アラートが上がる前に気づけるようにするための取り組みとして、隔週で各メトリクスのトレンド監視をする会を設けており、CPU使用率などが徐々に悪化していないかを見るようにしています。 結果 結果として、薬局検索機能のパフォーマンスに関してはレイテンシが約90%も改善しました。 パフォーマンスを大幅に改善しユーザビリティを向上させられただけでなく、これまで CloudWatch Logs に流れていた巨大な SQL クエリのログを削減することができたので AWS のコスト改善にも繋がりました。 また、メトリクスのトレンド監視によりアラートが上がるその手前で怪しい動きを見つけることができ、実際に早期対応することができています。 まとめ 今回は CLINICS における薬局検索機能のパフォーマンス改善について、プロジェクト発足の背景からクロージングに至るまでの過程をご紹介しました。 Pharms 開発チームは少数体制なのですが、今回のように QA チームや患者統合基盤チームなど周りを柔軟に巻き込んだ動き方ができて非常に面白いです。また、プロダクトマネージャーなど非エンジニアの方とも建設的にそれぞれの観点で対等に議論ができる点も弊社の大きな特徴です。 メドレーは絶賛エンジニア募集中ですので、弊社の取り組みに興味を持っていただいた方やもっと話を聞いてみたいと思った方は是非ご連絡ください！最後まで読んでいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。 かかりつけ薬局支援システム「Pharms」 の開発を担当している熊本です。先日、 総合医療アプリ「CLINICS」 の薬局検索機能のパフォーマンスを OpenSearch の導入により改善しましたので、その経緯と結果について話していきたいと思います。 医療プラットフォームのプロダクト紹介と構成 まずは私が所属する医療プラットフォーム（以下、医療 PF）のプロダクトをご紹介します。オンライン診療をはじめ様々な医療体験を提供する患者・生活者向けのプロダクトと、医療機関における業務効率と患者体験の向上を支援する事業者向けのプロダクトがあります。プロダクト間のデータ連携に関しては、患者統合基盤というプロダクトによって実現しています。 患者情報やその医療情報に関するデータに関しては患者統合基盤で保持していますが、薬局店舗のリストや営業時間など調剤薬局店舗に関するデータに関しては Pharms 側で保持しています。本記事では、この調剤薬局店舗に関するデータを扱う Pharms の API についてお話しします。 CLINICS の薬局検索機能 CLINICS にはお薬手帳や、お薬辞典、薬局検索など薬局に関する機能がいくつか存在します。 本記事ではその内の薬局検索機能についてお話しするため、簡単にご紹介します。 薬局名で検索できるのはもちろんのこと、マップの範囲検索や市区町村、受付日時などで絞り込むことでご自身の都合にあった薬局を探すことが可能です。 病院等で処方箋を受け取った後に、この薬局検索機能を使ってお薬を受け取りたい薬局を探し、その薬局に対して CLINICS から事前に処方箋を送信しておくことができます。待ち時間なくお薬を受け取ることができるので個人的にも愛用しています！ 他にも検索条件はいくつかあるのですが、オンラインで服薬指導を受けた際には Uber Eats により当日中にお薬を配達してくれる機能もあるので、当日配達に対応しているかどうかで絞り込むことも可能です。 この検索機能のバックエンドを Pharms の API が担っており、内部的には検索エンジンを使わず RDB による絞り込みで実現していました。 潜在課題の表層化 先ほどご紹介したように薬局検索機能はとても便利なのですが、 Pharms の事業成長に伴い以下のような課題も徐々に出てきました。 データ量と検索トラフィックが増加してきた データ量の増加に伴い検索時のレスポンスが遅くなり患者のユーザビリティが悪化してきた 検索条件の増加に伴い SQL クエリが複雑になり、変更難易度が上がり開発・運用の工数が肥大化してきた 潜在的な課題を認識しつつも何とか開発・運用を続けてきたのですが、複雑な組み合わせの検索をクローラーなどにより集中的に実行された場合、処理コストの高い SQL クエリが大量に発行されてしまいレイテンシ悪化が起きるようになってしまいました。 患者側のメトリクスは患者統合基盤チームでもモニタリングしていることもあり、患者統合基盤チームと連携してレイテンシ悪化の原因調査や対応策の検討に取り組み、迅速に一次対応を打つことができました。 異なる開発チームでも必要に応じて連携しながら課題解決に取り組めるところは弊社の特徴 かなと改めて感じました。 しかし、サーバの強化や SQL クエリの改善で対処していたものの、あくまで暫定的な対応であり、対応工数・インフラコストなども鑑みると恒久対応の優先度が上がってきました。 課題の対応に向けて 上述の課題の他に、開発プロセスの改善や品質向上に向けた取り組みなど、今後の機能開発を見据えて、一度足元の強化が必要という議論が Pharms 開発チームであったため、薬局検索機能のパフォーマンス改善に限らず「開発基盤改善」としてプロジェクトを発足し、集中的にチーム課題に向き合うことになりました。 ここに関しては、 プロダクトマネージャーと技術課題に関する目線合わせがスムーズにできた ことも、プロジェクトが早いタイミングで発足した一因であると思います。 Pharms の開発チームにおいてはプロダクトマネージャーが事業部出身であるため、開発計画を練る際には プロダクトマネージャー/テックリード がそれぞれ 攻め（KPI の達成を担うもの）/守り（事故リスクを減らすもの） の観点でやりたいことを列挙しフラットに議論する体制をとっています。普段から守りの観点も重視されている上で、既にユーザビリティに悪影響を及ぼしていることや、その影響範囲・対応工数など諸々を鑑みて意思決定が行われました。 対応 パフォーマンス問題への対応は2つの観点で行うこととし、現状課題の根本解決に向けて OpenSearch の導入を、再発防止と継続的な改善に向けてモニタリングの強化を行うことにしました。 OpenSearch の導入 設計・実装 OpenSearch を導入することになるのですが、他いくつかのプロダクトで導入実績があったことや、現状の技術構成に対する親和性、個人的にも過去に別プロダクトで導入経験があったことなどを踏まえて導入自体は非常に早い段階で決定しました。 まずは設計にも関わってくるのでどれくらいのレスポンスを目標とするか等の受け入れ要件を定め、その後 index の設計に移りました。 基本的には既存の検索条件に合わせたシンプルな設計になったのですが、予約枠の表現に関しては頭を悩まされました。 というのも、「準備でき次第」のような検索条件に関しては、営業時間内かどうかに加え、その枠が予約で埋まっていないかどうかも見る必要があり、その表現やリアルタイム性を加味して設計を行いました。 index の設計が終わった後は粛々と既存の検索ロジックを OpenSearch のクエリに置き換え、検索に関連するテーブルが更新される箇所に OpenSearch のドキュメントを更新する処理を追加していきました。 検証 実装後はデグレチェックと負荷耐久性の観点で検証を行いました。 医療 PF 内の QA エンジニアと連携し、各検索条件の組み合わせにおいて期待通りの結果が返却されるかどうかを検証しました。パターンが多かったのでテストケースの作成から実施まで協力してもらい助かりました。おかげさまで私としては Pharms の店舗画面や CLINICS を操作した際に正しく OpenSearch のドキュメントが更新されるかどうかの確認であったり、後述する負荷試験に集中的に取り組むことができました。 負荷試験は、検証環境に本番相当のデータ量を用意した上で、過去に最もレイテンシが悪化した際のリクエスト頻度を少し上回る頻度でリクエストを一定時間かけ続け、 AWSのトラブルシューティング などを参考にして基準を十分にクリアできるかどうかの観点で行いました。 リリース 諸々の検証をクリアしてリリースを迎えるのですが、ここでも少しだけ工夫した点をご紹介します。 一点目は Feature Flag を利用していつでも以前のロジック（OpenSearch を使わない検索）に戻せるようにしていた点です。念入りに検証したものの Pharms としては初めての OpenSearch 導入だったので、不測の自体が起きた場合でもデプロイなしにいつでも切り戻せるようにしていました。 二点目は index のエイリアス設定です。マッピングの変更などに伴い index の再構築を行う際にダウンタイムが発生しないようにエイリアスの設定をしていました。一般的なベストプラクティスだとは思いますが、ここに限らず過去の知見を活かしながら開発進行できたのは良かったかなと思います。 モニタリング強化 これまで OpenSearch 導入の話をしてきましたが、今後も継続してパフォーマンス劣化をより精度高く、迅速に検知できるようにするためにモニタリングも強化しました。 インフラ側は主に CloudWatch を使い、アプリケーション側は主に Datadog を使ってアラート設定を追加しました。 これまでも主要メトリクスに関しては設定していたのですが、今回調査・対応した知見を活かして、より詳細かつ網羅的に整備しました。 また、アラートが上がる前に気づけるようにするための取り組みとして、隔週で各メトリクスのトレンド監視をする会を設けており、CPU使用率などが徐々に悪化していないかを見るようにしています。 結果 結果として、薬局検索機能のパフォーマンスに関してはレイテンシが約90%も改善しました。 パフォーマンスを大幅に改善しユーザビリティを向上させられただけでなく、これまで CloudWatch Logs に流れていた巨大な SQL クエリのログを削減することができたので AWS のコスト改善にも繋がりました。 また、メトリクスのトレンド監視によりアラートが上がるその手前で怪しい動きを見つけることができ、実際に早期対応することができています。 まとめ 今回は CLINICS における薬局検索機能のパフォーマンス改善について、プロジェクト発足の背景からクロージングに至るまでの過程をご紹介しました。 Pharms 開発チームは少数体制なのですが、今回のように QA チームや患者統合基盤チームなど周りを柔軟に巻き込んだ動き方ができて非常に面白いです。また、プロダクトマネージャーなど非エンジニアの方とも建設的にそれぞれの観点で対等に議論ができる点も弊社の大きな特徴です。 メドレーは絶賛エンジニア募集中ですので、弊社の取り組みに興味を持っていただいた方やもっと話を聞いてみたいと思った方は是非ご連絡ください！最後まで読んでいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。 かかりつけ薬局支援システム「Pharms」 の開発を担当している熊本です。先日、 総合医療アプリ「CLINICS」 の薬局検索機能のパフォーマンスを OpenSearch の導入により改善しましたので、その経緯と結果について話していきたいと思います。 医療プラットフォームのプロダクト紹介と構成 まずは私が所属する医療プラットフォーム（以下、医療 PF）のプロダクトをご紹介します。オンライン診療をはじめ様々な医療体験を提供する患者・生活者向けのプロダクトと、医療機関における業務効率と患者体験の向上を支援する事業者向けのプロダクトがあります。プロダクト間のデータ連携に関しては、患者統合基盤というプロダクトによって実現しています。 患者情報やその医療情報に関するデータに関しては患者統合基盤で保持していますが、薬局店舗のリストや営業時間など調剤薬局店舗に関するデータに関しては Pharms 側で保持しています。本記事では、この調剤薬局店舗に関するデータを扱う Pharms の API についてお話しします。 CLINICS の薬局検索機能 CLINICS にはお薬手帳や、お薬辞典、薬局検索など薬局に関する機能がいくつか存在します。 本記事ではその内の薬局検索機能についてお話しするため、簡単にご紹介します。 薬局名で検索できるのはもちろんのこと、マップの範囲検索や市区町村、受付日時などで絞り込むことでご自身の都合にあった薬局を探すことが可能です。 病院等で処方箋を受け取った後に、この薬局検索機能を使ってお薬を受け取りたい薬局を探し、その薬局に対して CLINICS から事前に処方箋を送信しておくことができます。待ち時間なくお薬を受け取ることができるので個人的にも愛用しています！ 他にも検索条件はいくつかあるのですが、オンラインで服薬指導を受けた際には Uber Eats により当日中にお薬を配達してくれる機能もあるので、当日配達に対応しているかどうかで絞り込むことも可能です。 この検索機能のバックエンドを Pharms の API が担っており、内部的には検索エンジンを使わず RDB による絞り込みで実現していました。 潜在課題の表層化 先ほどご紹介したように薬局検索機能はとても便利なのですが、 Pharms の事業成長に伴い以下のような課題も徐々に出てきました。 データ量と検索トラフィックが増加してきた データ量の増加に伴い検索時のレスポンスが遅くなり患者のユーザビリティが悪化してきた 検索条件の増加に伴い SQL クエリが複雑になり、変更難易度が上がり開発・運用の工数が肥大化してきた 潜在的な課題を認識しつつも何とか開発・運用を続けてきたのですが、複雑な組み合わせの検索をクローラーなどにより集中的に実行された場合、処理コストの高い SQL クエリが大量に発行されてしまいレイテンシ悪化が起きるようになってしまいました。 患者側のメトリクスは患者統合基盤チームでもモニタリングしていることもあり、患者統合基盤チームと連携してレイテンシ悪化の原因調査や対応策の検討に取り組み、迅速に一次対応を打つことができました。 異なる開発チームでも必要に応じて連携しながら課題解決に取り組めるところは弊社の特徴 かなと改めて感じました。 しかし、サーバの強化や SQL クエリの改善で対処していたものの、あくまで暫定的な対応であり、対応工数・インフラコストなども鑑みると恒久対応の優先度が上がってきました。 課題の対応に向けて 上述の課題の他に、開発プロセスの改善や品質向上に向けた取り組みなど、今後の機能開発を見据えて、一度足元の強化が必要という議論が Pharms 開発チームであったため、薬局検索機能のパフォーマンス改善に限らず「開発基盤改善」としてプロジェクトを発足し、集中的にチーム課題に向き合うことになりました。 ここに関しては、 プロダクトマネージャーと技術課題に関する目線合わせがスムーズにできた ことも、プロジェクトが早いタイミングで発足した一因であると思います。 Pharms の開発チームにおいてはプロダクトマネージャーが事業部出身であるため、開発計画を練る際には プロダクトマネージャー/テックリード がそれぞれ 攻め（KPI の達成を担うもの）/守り（事故リスクを減らすもの） の観点でやりたいことを列挙しフラットに議論する体制をとっています。普段から守りの観点も重視されている上で、既にユーザビリティに悪影響を及ぼしていることや、その影響範囲・対応工数など諸々を鑑みて意思決定が行われました。 対応 パフォーマンス問題への対応は2つの観点で行うこととし、現状課題の根本解決に向けて OpenSearch の導入を、再発防止と継続的な改善に向けてモニタリングの強化を行うことにしました。 OpenSearch の導入 設計・実装 OpenSearch を導入することになるのですが、他いくつかのプロダクトで導入実績があったことや、現状の技術構成に対する親和性、個人的にも過去に別プロダクトで導入経験があったことなどを踏まえて導入自体は非常に早い段階で決定しました。 まずは設計にも関わってくるのでどれくらいのレスポンスを目標とするか等の受け入れ要件を定め、その後 index の設計に移りました。 基本的には既存の検索条件に合わせたシンプルな設計になったのですが、予約枠の表現に関しては頭を悩まされました。 というのも、「準備でき次第」のような検索条件に関しては、営業時間内かどうかに加え、その枠が予約で埋まっていないかどうかも見る必要があり、その表現やリアルタイム性を加味して設計を行いました。 index の設計が終わった後は粛々と既存の検索ロジックを OpenSearch のクエリに置き換え、検索に関連するテーブルが更新される箇所に OpenSearch のドキュメントを更新する処理を追加していきました。 検証 実装後はデグレチェックと負荷耐久性の観点で検証を行いました。 医療 PF 内の QA エンジニアと連携し、各検索条件の組み合わせにおいて期待通りの結果が返却されるかどうかを検証しました。パターンが多かったのでテストケースの作成から実施まで協力してもらい助かりました。おかげさまで私としては Pharms の店舗画面や CLINICS を操作した際に正しく OpenSearch のドキュメントが更新されるかどうかの確認であったり、後述する負荷試験に集中的に取り組むことができました。 負荷試験は、検証環境に本番相当のデータ量を用意した上で、過去に最もレイテンシが悪化した際のリクエスト頻度を少し上回る頻度でリクエストを一定時間かけ続け、 AWSのトラブルシューティング などを参考にして基準を十分にクリアできるかどうかの観点で行いました。 リリース 諸々の検証をクリアしてリリースを迎えるのですが、ここでも少しだけ工夫した点をご紹介します。 一点目は Feature Flag を利用していつでも以前のロジック（OpenSearch を使わない検索）に戻せるようにしていた点です。念入りに検証したものの Pharms としては初めての OpenSearch 導入だったので、不測の自体が起きた場合でもデプロイなしにいつでも切り戻せるようにしていました。 二点目は index のエイリアス設定です。マッピングの変更などに伴い index の再構築を行う際にダウンタイムが発生しないようにエイリアスの設定をしていました。一般的なベストプラクティスだとは思いますが、ここに限らず過去の知見を活かしながら開発進行できたのは良かったかなと思います。 モニタリング強化 これまで OpenSearch 導入の話をしてきましたが、今後も継続してパフォーマンス劣化をより精度高く、迅速に検知できるようにするためにモニタリングも強化しました。 インフラ側は主に CloudWatch を使い、アプリケーション側は主に Datadog を使ってアラート設定を追加しました。 これまでも主要メトリクスに関しては設定していたのですが、今回調査・対応した知見を活かして、より詳細かつ網羅的に整備しました。 また、アラートが上がる前に気づけるようにするための取り組みとして、隔週で各メトリクスのトレンド監視をする会を設けており、CPU使用率などが徐々に悪化していないかを見るようにしています。 結果 結果として、薬局検索機能のパフォーマンスに関してはレイテンシが約90%も改善しました。 パフォーマンスを大幅に改善しユーザビリティを向上させられただけでなく、これまで CloudWatch Logs に流れていた巨大な SQL クエリのログを削減することができたので AWS のコスト改善にも繋がりました。 また、メトリクスのトレンド監視によりアラートが上がるその手前で怪しい動きを見つけることができ、実際に早期対応することができています。 まとめ 今回は CLINICS における薬局検索機能のパフォーマンス改善について、プロジェクト発足の背景からクロージングに至るまでの過程をご紹介しました。 Pharms 開発チームは少数体制なのですが、今回のように QA チームや患者統合基盤チームなど周りを柔軟に巻き込んだ動き方ができて非常に面白いです。また、プロダクトマネージャーなど非エンジニアの方とも建設的にそれぞれの観点で対等に議論ができる点も弊社の大きな特徴です。 メドレーは絶賛エンジニア募集中ですので、弊社の取り組みに興味を持っていただいた方やもっと話を聞いてみたいと思った方は是非ご連絡ください！最後まで読んでいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。 かかりつけ薬局支援システム「Pharms」 の開発を担当している熊本です。先日、 総合医療アプリ「CLINICS」 の薬局検索機能のパフォーマンスを OpenSearch の導入により改善しましたので、その経緯と結果について話していきたいと思います。 医療プラットフォームのプロダクト紹介と構成 まずは私が所属する医療プラットフォーム（以下、医療 PF）のプロダクトをご紹介します。オンライン診療をはじめ様々な医療体験を提供する患者・生活者向けのプロダクトと、医療機関における業務効率と患者体験の向上を支援する事業者向けのプロダクトがあります。プロダクト間のデータ連携に関しては、患者統合基盤というプロダクトによって実現しています。 患者情報やその医療情報に関するデータに関しては患者統合基盤で保持していますが、薬局店舗のリストや営業時間など調剤薬局店舗に関するデータに関しては Pharms 側で保持しています。本記事では、この調剤薬局店舗に関するデータを扱う Pharms の API についてお話しします。 CLINICS の薬局検索機能 CLINICS にはお薬手帳や、お薬辞典、薬局検索など薬局に関する機能がいくつか存在します。 本記事ではその内の薬局検索機能についてお話しするため、簡単にご紹介します。 薬局名で検索できるのはもちろんのこと、マップの範囲検索や市区町村、受付日時などで絞り込むことでご自身の都合にあった薬局を探すことが可能です。 病院等で処方箋を受け取った後に、この薬局検索機能を使ってお薬を受け取りたい薬局を探し、その薬局に対して CLINICS から事前に処方箋を送信しておくことができます。待ち時間なくお薬を受け取ることができるので個人的にも愛用しています！ 他にも検索条件はいくつかあるのですが、オンラインで服薬指導を受けた際には Uber Eats により当日中にお薬を配達してくれる機能もあるので、当日配達に対応しているかどうかで絞り込むことも可能です。 この検索機能のバックエンドを Pharms の API が担っており、内部的には検索エンジンを使わず RDB による絞り込みで実現していました。 潜在課題の表層化 先ほどご紹介したように薬局検索機能はとても便利なのですが、 Pharms の事業成長に伴い以下のような課題も徐々に出てきました。 データ量と検索トラフィックが増加してきた データ量の増加に伴い検索時のレスポンスが遅くなり患者のユーザビリティが悪化してきた 検索条件の増加に伴い SQL クエリが複雑になり、変更難易度が上がり開発・運用の工数が肥大化してきた 潜在的な課題を認識しつつも何とか開発・運用を続けてきたのですが、複雑な組み合わせの検索をクローラーなどにより集中的に実行された場合、処理コストの高い SQL クエリが大量に発行されてしまいレイテンシ悪化が起きるようになってしまいました。 患者側のメトリクスは患者統合基盤チームでもモニタリングしていることもあり、患者統合基盤チームと連携してレイテンシ悪化の原因調査や対応策の検討に取り組み、迅速に一次対応を打つことができました。 異なる開発チームでも必要に応じて連携しながら課題解決に取り組めるところは弊社の特徴 かなと改めて感じました。 しかし、サーバの強化や SQL クエリの改善で対処していたものの、あくまで暫定的な対応であり、対応工数・インフラコストなども鑑みると恒久対応の優先度が上がってきました。 課題の対応に向けて 上述の課題の他に、開発プロセスの改善や品質向上に向けた取り組みなど、今後の機能開発を見据えて、一度足元の強化が必要という議論が Pharms 開発チームであったため、薬局検索機能のパフォーマンス改善に限らず「開発基盤改善」としてプロジェクトを発足し、集中的にチーム課題に向き合うことになりました。 ここに関しては、 プロダクトマネージャーと技術課題に関する目線合わせがスムーズにできた ことも、プロジェクトが早いタイミングで発足した一因であると思います。 Pharms の開発チームにおいてはプロダクトマネージャーが事業部出身であるため、開発計画を練る際には プロダクトマネージャー/テックリード がそれぞれ 攻め（KPI の達成を担うもの）/守り（事故リスクを減らすもの） の観点でやりたいことを列挙しフラットに議論する体制をとっています。普段から守りの観点も重視されている上で、既にユーザビリティに悪影響を及ぼしていることや、その影響範囲・対応工数など諸々を鑑みて意思決定が行われました。 対応 パフォーマンス問題への対応は2つの観点で行うこととし、現状課題の根本解決に向けて OpenSearch の導入を、再発防止と継続的な改善に向けてモニタリングの強化を行うことにしました。 OpenSearch の導入 設計・実装 OpenSearch を導入することになるのですが、他いくつかのプロダクトで導入実績があったことや、現状の技術構成に対する親和性、個人的にも過去に別プロダクトで導入経験があったことなどを踏まえて導入自体は非常に早い段階で決定しました。 まずは設計にも関わってくるのでどれくらいのレスポンスを目標とするか等の受け入れ要件を定め、その後 index の設計に移りました。 基本的には既存の検索条件に合わせたシンプルな設計になったのですが、予約枠の表現に関しては頭を悩まされました。 というのも、「準備でき次第」のような検索条件に関しては、営業時間内かどうかに加え、その枠が予約で埋まっていないかどうかも見る必要があり、その表現やリアルタイム性を加味して設計を行いました。 index の設計が終わった後は粛々と既存の検索ロジックを OpenSearch のクエリに置き換え、検索に関連するテーブルが更新される箇所に OpenSearch のドキュメントを更新する処理を追加していきました。 検証 実装後はデグレチェックと負荷耐久性の観点で検証を行いました。 医療 PF 内の QA エンジニアと連携し、各検索条件の組み合わせにおいて期待通りの結果が返却されるかどうかを検証しました。パターンが多かったのでテストケースの作成から実施まで協力してもらい助かりました。おかげさまで私としては Pharms の店舗画面や CLINICS を操作した際に正しく OpenSearch のドキュメントが更新されるかどうかの確認であったり、後述する負荷試験に集中的に取り組むことができました。 負荷試験は、検証環境に本番相当のデータ量を用意した上で、過去に最もレイテンシが悪化した際のリクエスト頻度を少し上回る頻度でリクエストを一定時間かけ続け、 AWSのトラブルシューティング などを参考にして基準を十分にクリアできるかどうかの観点で行いました。 リリース 諸々の検証をクリアしてリリースを迎えるのですが、ここでも少しだけ工夫した点をご紹介します。 一点目は Feature Flag を利用していつでも以前のロジック（OpenSearch を使わない検索）に戻せるようにしていた点です。念入りに検証したものの Pharms としては初めての OpenSearch 導入だったので、不測の自体が起きた場合でもデプロイなしにいつでも切り戻せるようにしていました。 二点目は index のエイリアス設定です。マッピングの変更などに伴い index の再構築を行う際にダウンタイムが発生しないようにエイリアスの設定をしていました。一般的なベストプラクティスだとは思いますが、ここに限らず過去の知見を活かしながら開発進行できたのは良かったかなと思います。 モニタリング強化 これまで OpenSearch 導入の話をしてきましたが、今後も継続してパフォーマンス劣化をより精度高く、迅速に検知できるようにするためにモニタリングも強化しました。 インフラ側は主に CloudWatch を使い、アプリケーション側は主に Datadog を使ってアラート設定を追加しました。 これまでも主要メトリクスに関しては設定していたのですが、今回調査・対応した知見を活かして、より詳細かつ網羅的に整備しました。 また、アラートが上がる前に気づけるようにするための取り組みとして、隔週で各メトリクスのトレンド監視をする会を設けており、CPU使用率などが徐々に悪化していないかを見るようにしています。 結果 結果として、薬局検索機能のパフォーマンスに関してはレイテンシが約90%も改善しました。 パフォーマンスを大幅に改善しユーザビリティを向上させられただけでなく、これまで CloudWatch Logs に流れていた巨大な SQL クエリのログを削減することができたので AWS のコスト改善にも繋がりました。 また、メトリクスのトレンド監視によりアラートが上がるその手前で怪しい動きを見つけることができ、実際に早期対応することができています。 まとめ 今回は CLINICS における薬局検索機能のパフォーマンス改善について、プロジェクト発足の背景からクロージングに至るまでの過程をご紹介しました。 Pharms 開発チームは少数体制なのですが、今回のように QA チームや患者統合基盤チームなど周りを柔軟に巻き込んだ動き方ができて非常に面白いです。また、プロダクトマネージャーなど非エンジニアの方とも建設的にそれぞれの観点で対等に議論ができる点も弊社の大きな特徴です。 メドレーは絶賛エンジニア募集中ですので、弊社の取り組みに興味を持っていただいた方やもっと話を聞いてみたいと思った方は是非ご連絡ください！最後まで読んでいただき、ありがとうございました。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。 かかりつけ薬局支援システム「Pharms」 の開発を担当している熊本です。先日、 総合医療アプリ「CLINICS」 の薬局検索機能のパフォーマンスを OpenSearch の導入により改善しましたので、その経緯と結果について話していきたいと思います。 医療プラットフォームのプロダクト紹介と構成 まずは私が所属する医療プラットフォーム（以下、医療 PF）のプロダクトをご紹介します。オンライン診療をはじめ様々な医療体験を提供する患者・生活者向けのプロダクトと、医療機関における業務効率と患者体験の向上を支援する事業者向けのプロダクトがあります。プロダクト間のデータ連携に関しては、患者統合基盤というプロダクトによって実現しています。 患者情報やその医療情報に関するデータに関しては患者統合基盤で保持していますが、薬局店舗のリストや営業時間など調剤薬局店舗に関するデータに関しては Pharms 側で保持しています。本記事では、この調剤薬局店舗に関するデータを扱う Pharms の API についてお話しします。 CLINICS の薬局検索機能 CLINICS にはお薬手帳や、お薬辞典、薬局検索など薬局に関する機能がいくつか存在します。 本記事ではその内の薬局検索機能についてお話しするため、簡単にご紹介します。 薬局名で検索できるのはもちろんのこと、マップの範囲検索や市区町村、受付日時などで絞り込むことでご自身の都合にあった薬局を探すことが可能です。 病院等で処方箋を受け取った後に、この薬局検索機能を使ってお薬を受け取りたい薬局を探し、その薬局に対して CLINICS から事前に処方箋を送信しておくことができます。待ち時間なくお薬を受け取ることができるので個人的にも愛用しています！ 他にも検索条件はいくつかあるのですが、オンラインで服薬指導を受けた際には Uber Eats により当日中にお薬を配達してくれる機能もあるので、当日配達に対応しているかどうかで絞り込むことも可能です。 この検索機能のバックエンドを Pharms の API が担っており、内部的には検索エンジンを使わず RDB による絞り込みで実現していました。 潜在課題の表層化 先ほどご紹介したように薬局検索機能はとても便利なのですが、 Pharms の事業成長に伴い以下のような課題も徐々に出てきました。 データ量と検索トラフィックが増加してきた データ量の増加に伴い検索時のレスポンスが遅くなり患者のユーザビリティが悪化してきた 検索条件の増加に伴い SQL クエリが複雑になり、変更難易度が上がり開発・運用の工数が肥大化してきた 潜在的な課題を認識しつつも何とか開発・運用を続けてきたのですが、複雑な組み合わせの検索をクローラーなどにより集中的に実行された場合、処理コストの高い SQL クエリが大量に発行されてしまいレイテンシ悪化が起きるようになってしまいました。 患者側のメトリクスは患者統合基盤チームでもモニタリングしていることもあり、患者統合基盤チームと連携してレイテンシ悪化の原因調査や対応策の検討に取り組み、迅速に一次対応を打つことができました。 異なる開発チームでも必要に応じて連携しながら課題解決に取り組めるところは弊社の特徴 かなと改めて感じました。 しかし、サーバの強化や SQL クエリの改善で対処していたものの、あくまで暫定的な対応であり、対応工数・インフラコストなども鑑みると恒久対応の優先度が上がってきました。 課題の対応に向けて 上述の課題の他に、開発プロセスの改善や品質向上に向けた取り組みなど、今後の機能開発を見据えて、一度足元の強化が必要という議論が Pharms 開発チームであったため、薬局検索機能のパフォーマンス改善に限らず「開発基盤改善」としてプロジェクトを発足し、集中的にチーム課題に向き合うことになりました。 ここに関しては、 プロダクトマネージャーと技術課題に関する目線合わせがスムーズにできた ことも、プロジェクトが早いタイミングで発足した一因であると思います。 Pharms の開発チームにおいてはプロダクトマネージャーが事業部出身であるため、開発計画を練る際には プロダクトマネージャー/テックリード がそれぞれ 攻め（KPI の達成を担うもの）/守り（事故リスクを減らすもの） の観点でやりたいことを列挙しフラットに議論する体制をとっています。普段から守りの観点も重視されている上で、既にユーザビリティに悪影響を及ぼしていることや、その影響範囲・対応工数など諸々を鑑みて意思決定が行われました。 対応 パフォーマンス問題への対応は2つの観点で行うこととし、現状課題の根本解決に向けて OpenSearch の導入を、再発防止と継続的な改善に向けてモニタリングの強化を行うことにしました。 OpenSearch の導入 設計・実装 OpenSearch を導入することになるのですが、他いくつかのプロダクトで導入実績があったことや、現状の技術構成に対する親和性、個人的にも過去に別プロダクトで導入経験があったことなどを踏まえて導入自体は非常に早い段階で決定しました。 まずは設計にも関わってくるのでどれくらいのレスポンスを目標とするか等の受け入れ要件を定め、その後 index の設計に移りました。 基本的には既存の検索条件に合わせたシンプルな設計になったのですが、予約枠の表現に関しては頭を悩まされました。 というのも、「準備でき次第」のような検索条件に関しては、営業時間内かどうかに加え、その枠が予約で埋まっていないかどうかも見る必要があり、その表現やリアルタイム性を加味して設計を行いました。 index の設計が終わった後は粛々と既存の検索ロジックを OpenSearch のクエリに置き換え、検索に関連するテーブルが更新される箇所に OpenSearch のドキュメントを更新する処理を追加していきました。 検証 実装後はデグレチェックと負荷耐久性の観点で検証を行いました。 医療 PF 内の QA エンジニアと連携し、各検索条件の組み合わせにおいて期待通りの結果が返却されるかどうかを検証しました。パターンが多かったのでテストケースの作成から実施まで協力してもらい助かりました。おかげさまで私としては Pharms の店舗画面や CLINICS を操作した際に正しく OpenSearch のドキュメントが更新されるかどうかの確認であったり、後述する負荷試験に集中的に取り組むことができました。 負荷試験は、検証環境に本番相当のデータ量を用意した上で、過去に最もレイテンシが悪化した際のリクエスト頻度を少し上回る頻度でリクエストを一定時間かけ続け、 AWSのトラブルシューティング などを参考にして基準を十分にクリアできるかどうかの観点で行いました。 リリース 諸々の検証をクリアしてリリースを迎えるのですが、ここでも少しだけ工夫した点をご紹介します。 一点目は Feature Flag を利用していつでも以前のロジック（OpenSearch を使わない検索）に戻せるようにしていた点です。念入りに検証したものの Pharms としては初めての OpenSearch 導入だったので、不測の自体が起きた場合でもデプロイなしにいつでも切り戻せるようにしていました。 二点目は index のエイリアス設定です。マッピングの変更などに伴い index の再構築を行う際にダウンタイムが発生しないようにエイリアスの設定をしていました。一般的なベストプラクティスだとは思いますが、ここに限らず過去の知見を活かしながら開発進行できたのは良かったかなと思います。 モニタリング強化 これまで OpenSearch 導入の話をしてきましたが、今後も継続してパフォーマンス劣化をより精度高く、迅速に検知できるようにするためにモニタリングも強化しました。 インフラ側は主に CloudWatch を使い、アプリケーション側は主に Datadog を使ってアラート設定を追加しました。 これまでも主要メトリクスに関しては設定していたのですが、今回調査・対応した知見を活かして、より詳細かつ網羅的に整備しました。 また、アラートが上がる前に気づけるようにするための取り組みとして、隔週で各メトリクスのトレンド監視をする会を設けており、CPU使用率などが徐々に悪化していないかを見るようにしています。 結果 結果として、薬局検索機能のパフォーマンスに関してはレイテンシが約90%も改善しました。 パフォーマンスを大幅に改善しユーザビリティを向上させられただけでなく、これまで CloudWatch Logs に流れていた巨大な SQL クエリのログを削減することができたので AWS のコスト改善にも繋がりました。 また、メトリクスのトレンド監視によりアラートが上がるその手前で怪しい動きを見つけることができ、実際に早期対応することができています。 まとめ 今回は CLINICS における薬局検索機能のパフォーマンス改善について、プロジェクト発足の背景からクロージングに至るまでの過程をご紹介しました。 Pharms 開発チームは少数体制なのですが、今回のように QA チームや患者統合基盤チームなど周りを柔軟に巻き込んだ動き方ができて非常に面白いです。また、プロダクトマネージャーなど非エンジニアの方とも建設的にそれぞれの観点で対等に議論ができる点も弊社の大きな特徴です。 メドレーは絶賛エンジニア募集中ですので、弊社の取り組みに興味を持っていただいた方やもっと話を聞いてみたいと思った方は是非ご連絡ください！最後まで読んでいただき、ありがとうございました。 https://www.medley.jp/jobs/

こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！ さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催された「 DroidKaigi 2024 」にゴールドスポンサーとして協賛させていただきました。 DroidKaigi は、 今年で 10 年目を迎える Android カンファレンス です。国内外から Android エンジニアが集い、幅広い内容のセッションとともに、Android 技術情報の共有とコミュニケーションが行われています。 そんな歴史あるカンファレンスですが、メドレーがブースを出すのは今年が初めて。採用担当・広報・ネイティブアプリエンジニアなど総勢 7 名で参加し、様々なセッションを聞いたり、多くのエンジニアとの交流を深めることができました。 今回は、参加した社員の感想をもとに、DroidKaigi 2024 の様子をお伝えします！ 会場の様子 DroidKaigi 2024 は、たくさんの人で溢れた、非常に賑やかなカンファレンスでした！ こちらはオープニングの様子。朝の時点で、かなりの人数が集まっていることがわかると思います。 軽食やコーヒーの提供があったり、ネイルブースに、プリクラまで、様々な企画が行われていました。ネイルブースでは、Android のキャラクターとロゴを使ったネイルを施していただきました！ また、DroidKaigi 2024 では、名札にシールを貼って、自分の興味分野を示すことができます。他の参加者の方と話す場面でも、このシールを見ながら技術の話ができ、とても良い取り組みだなと思いました。 私の作った名札はこんな感じです。私は React Native でクロスプラットフォーム開発をしているので、React Native のシールも欲しかったです。残念！ DroidKaigi 2024 で最も賑やかだったのが、1 日目の夜に開催されたアフターパーティーです。たくさんのお食事が並ぶ中、立食形式で参加者同士が自由に交流できるイベントでした。かなり広いスペースが確保されていたのですが、それでもかなり混雑しているほどの盛況ぶり！ 私も参加し、様々な企業の方とお話しすることができました。 また、メドレーは iOSDC Japan 2024 でもスポンサーをさせていただきました（詳細は こちら ）が、iOSDC と最も違うところは、国際色ではないかと思います。iOSDC では日本語でのセッションのみでしたが、DroidKaigi では英語のセッションがあったり、ブースでも英語や韓国語で話しかけられることがありました！ 多様な人がいるからこそ、新しい出会いや学びもより多く得られたのではないかと思います。 メドレーブースの様子 メドレーブースでは、iOSDC 同様、メドレーが展開するアプリの紹介と、アンケートパネルを用いて参加者の方々に医療体験に関するお悩みを伺いました。 DroidKaigi 2024 での最終結果はこちら！ 1 位　待ち時間が長い！ 2 位　何科に通えば良いかわからない！ 3 位　病院探しに時間がかかる・オンラインで予約したい iOSDC の時と似たような結果になりました！やはりみなさん同じような悩みを抱えていらっしゃるようです。 メドレーでは、 これらの課題を解決するべく、様々なプロダクト・サービスを展開しています 。上位にランクインした課題は、患者向けに提供しているオンライン診療・服薬指導アプリ「 CLINICS 」（以降、CLINICS アプリ）で以下のような機能を提供することで解決を目指しています。現地では実際に画面を見せながら、機能の説明を行いました。 待ち時間が長い！ CLINICS アプリを使ってオンラインで診療を受けることができます CLINICS アプリを使って事前に問診票に回答したり、CLINICS アプリでキャッシュレス決済を行うことでも、待ち時間を減らすことができます 何科に通えば良いかわからない！ CLINICS アプリで気になる症状を選択し設問に回答すると、考えられる病気と診療科を紹介します 病院探しに時間がかかる・オンラインで予約したい CLINICS アプリから、さまざまな条件で病院を探し、そのまま予約をすることができます また、オンライン服薬指導や、Amazon ファーマシーとの連携、処方薬の配送などについてもお話ししました。その他にも、モバイルアプリの開発体制や、オンラインビデオ通話の実現方法など、技術的な面でもたくさんのご質問をいただきました。 CLINICS アプリについて説明していくと、「めちゃくちゃ良いですね！」といった反応をいただける反面、「つまりはまだまだ知られていないな」ということを痛感します。もっともっとメドレーの、そして提供しているサービスやプロダクトの認知度を上げていくために、様々な取り組みをしていかなければいけませんね。 セッションやブース DroidKaigi 2024 では、48 のセッションと、30 以上のスポンサーブースが設置されていました。メドレー社員が参加したものの中から、いくつかピックアップしてご紹介します。 セッション：宣言的 UI を学ぶ際に知っておくべき重要なコンセプト SwiftUI 、 Jetpack Compose 、React Native の実装を通して、宣言的 UI がどのようなコンセプトを持っているかを紹介していました。それぞれ異なるツールキットですが、 宣言的 UI という観点から見ると確かに同じ思想をしている なと感じることができました。 (詳細ページは こちら ) セッション：起動時間で差をつけろ！アプリ起動パフォーマンス改善！ アプリの起動、と一口に言っても、プロセスがない状態から起動するケースもあれば、バックグラウンドでプロセスが実行されているケースなど様々な起動方法があります。このセッションでは、 アプリの起動にどのような種類があるか、そしてそれぞれのケースでどのような処理が行われるのかを整理 した上で、起動時間の計測方法や改善方法などを、具体例を通じて示していました。今まで起動時間は計測したことがなかったので、これを気にチャレンジしてみたいです。 (詳細ページは こちら ) セッション：Android View から Jetpack Compose へ 〜Jetpack Compose 移行のすゝめ〜 タイトルの通り、 Jetpack Compose 移行に関するお話 で、 具体的な移行の事例も交えながら説明 されていました。メドレーでも Jetpack Compose を導入しており、その際に苦労した、Jetpack Compose の自由度の高さなども話題に上がっていました。 これから Jetpack Compose へ移行していく人にはとてもわかりやすい発表内容でした。 (詳細ページは こちら ) ブース：株式会社ゆめみ DroidKaigi ならでは！と思ったブースが、株式会社ゆめみさんのブースです。 Android アプリの開発では Android Studio という IDE が使われることが多いのですが、Android Studio はバージョン名が動物の名前になっています。その動物たちを、リリース順に並び替えよう！というものです（なお、各動物を英語で表した時の頭文字がアルファベット順になるように選ばれているので、全動物を完璧に英訳できればその方針でもクリアできます。） 私もチャレンジしてみましたが、2 箇所間違えてしまいました……難しい！ みなさんは分かりましたか？ 終わりに メドレーはこれからも、医療ヘルスケアの未来を作るために、アプリを始めとした様々なプロダクト・サービスを開発し提供していきます。 最後に改めて、DroidKaigi 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、お疲れ様でした、そしてありがとうございました！ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースなどで興味を持っていただいた方はご連絡いただければと思います！カジュアル面談など実施可能ですので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！ さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催された「 DroidKaigi 2024 」にゴールドスポンサーとして協賛させていただきました。 DroidKaigi は、 今年で 10 年目を迎える Android カンファレンス です。国内外から Android エンジニアが集い、幅広い内容のセッションとともに、Android 技術情報の共有とコミュニケーションが行われています。 そんな歴史あるカンファレンスですが、メドレーがブースを出すのは今年が初めて。採用担当・広報・ネイティブアプリエンジニアなど総勢 7 名で参加し、様々なセッションを聞いたり、多くのエンジニアとの交流を深めることができました。 今回は、参加した社員の感想をもとに、DroidKaigi 2024 の様子をお伝えします！ 会場の様子 DroidKaigi 2024 は、たくさんの人で溢れた、非常に賑やかなカンファレンスでした！ こちらはオープニングの様子。朝の時点で、かなりの人数が集まっていることがわかると思います。 軽食やコーヒーの提供があったり、ネイルブースに、プリクラまで、様々な企画が行われていました。ネイルブースでは、Android のキャラクターとロゴを使ったネイルを施していただきました！ また、DroidKaigi 2024 では、名札にシールを貼って、自分の興味分野を示すことができます。他の参加者の方と話す場面でも、このシールを見ながら技術の話ができ、とても良い取り組みだなと思いました。 私の作った名札はこんな感じです。私は React Native でクロスプラットフォーム開発をしているので、React Native のシールも欲しかったです。残念！ DroidKaigi 2024 で最も賑やかだったのが、1 日目の夜に開催されたアフターパーティーです。たくさんのお食事が並ぶ中、立食形式で参加者同士が自由に交流できるイベントでした。かなり広いスペースが確保されていたのですが、それでもかなり混雑しているほどの盛況ぶり！ 私も参加し、様々な企業の方とお話しすることができました。 また、メドレーは iOSDC Japan 2024 でもスポンサーをさせていただきました（詳細は こちら ）が、iOSDC と最も違うところは、国際色ではないかと思います。iOSDC では日本語でのセッションのみでしたが、DroidKaigi では英語のセッションがあったり、ブースでも英語や韓国語で話しかけられることがありました！ 多様な人がいるからこそ、新しい出会いや学びもより多く得られたのではないかと思います。 メドレーブースの様子 メドレーブースでは、iOSDC 同様、メドレーが展開するアプリの紹介と、アンケートパネルを用いて参加者の方々に医療体験に関するお悩みを伺いました。 DroidKaigi 2024 での最終結果はこちら！ 1 位　待ち時間が長い！ 2 位　何科に通えば良いかわからない！ 3 位　病院探しに時間がかかる・オンラインで予約したい iOSDC の時と似たような結果になりました！やはりみなさん同じような悩みを抱えていらっしゃるようです。 メドレーでは、 これらの課題を解決するべく、様々なプロダクト・サービスを展開しています 。上位にランクインした課題は、患者向けに提供しているオンライン診療・服薬指導アプリ「 CLINICS 」（以降、CLINICS アプリ）で以下のような機能を提供することで解決を目指しています。現地では実際に画面を見せながら、機能の説明を行いました。 待ち時間が長い！ CLINICS アプリを使ってオンラインで診療を受けることができます CLINICS アプリを使って事前に問診票に回答したり、CLINICS アプリでキャッシュレス決済を行うことでも、待ち時間を減らすことができます 何科に通えば良いかわからない！ CLINICS アプリで気になる症状を選択し設問に回答すると、考えられる病気と診療科を紹介します 病院探しに時間がかかる・オンラインで予約したい CLINICS アプリから、さまざまな条件で病院を探し、そのまま予約をすることができます また、オンライン服薬指導や、Amazon ファーマシーとの連携、処方薬の配送などについてもお話ししました。その他にも、モバイルアプリの開発体制や、オンラインビデオ通話の実現方法など、技術的な面でもたくさんのご質問をいただきました。 CLINICS アプリについて説明していくと、「めちゃくちゃ良いですね！」といった反応をいただける反面、「つまりはまだまだ知られていないな」ということを痛感します。もっともっとメドレーの、そして提供しているサービスやプロダクトの認知度を上げていくために、様々な取り組みをしていかなければいけませんね。 セッションやブース DroidKaigi 2024 では、48 のセッションと、30 以上のスポンサーブースが設置されていました。メドレー社員が参加したものの中から、いくつかピックアップしてご紹介します。 セッション：宣言的 UI を学ぶ際に知っておくべき重要なコンセプト SwiftUI 、 Jetpack Compose 、React Native の実装を通して、宣言的 UI がどのようなコンセプトを持っているかを紹介していました。それぞれ異なるツールキットですが、 宣言的 UI という観点から見ると確かに同じ思想をしている なと感じることができました。 (詳細ページは こちら ) セッション：起動時間で差をつけろ！アプリ起動パフォーマンス改善！ アプリの起動、と一口に言っても、プロセスがない状態から起動するケースもあれば、バックグラウンドでプロセスが実行されているケースなど様々な起動方法があります。このセッションでは、 アプリの起動にどのような種類があるか、そしてそれぞれのケースでどのような処理が行われるのかを整理 した上で、起動時間の計測方法や改善方法などを、具体例を通じて示していました。今まで起動時間は計測したことがなかったので、これを気にチャレンジしてみたいです。 (詳細ページは こちら ) セッション：Android View から Jetpack Compose へ 〜Jetpack Compose 移行のすゝめ〜 タイトルの通り、 Jetpack Compose 移行に関するお話 で、 具体的な移行の事例も交えながら説明 されていました。メドレーでも Jetpack Compose を導入しており、その際に苦労した、Jetpack Compose の自由度の高さなども話題に上がっていました。 これから Jetpack Compose へ移行していく人にはとてもわかりやすい発表内容でした。 (詳細ページは こちら ) ブース：株式会社ゆめみ DroidKaigi ならでは！と思ったブースが、株式会社ゆめみさんのブースです。 Android アプリの開発では Android Studio という IDE が使われることが多いのですが、Android Studio はバージョン名が動物の名前になっています。その動物たちを、リリース順に並び替えよう！というものです（なお、各動物を英語で表した時の頭文字がアルファベット順になるように選ばれているので、全動物を完璧に英訳できればその方針でもクリアできます。） 私もチャレンジしてみましたが、2 箇所間違えてしまいました……難しい！ みなさんは分かりましたか？ 終わりに メドレーはこれからも、医療ヘルスケアの未来を作るために、アプリを始めとした様々なプロダクト・サービスを開発し提供していきます。 最後に改めて、DroidKaigi 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、お疲れ様でした、そしてありがとうございました！ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースなどで興味を持っていただいた方はご連絡いただければと思います！カジュアル面談など実施可能ですので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！ さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催された「 DroidKaigi 2024 」にゴールドスポンサーとして協賛させていただきました。 DroidKaigi は、 今年で 10 年目を迎える Android カンファレンス です。国内外から Android エンジニアが集い、幅広い内容のセッションとともに、Android 技術情報の共有とコミュニケーションが行われています。 そんな歴史あるカンファレンスですが、メドレーがブースを出すのは今年が初めて。採用担当・広報・ネイティブアプリエンジニアなど総勢 7 名で参加し、様々なセッションを聞いたり、多くのエンジニアとの交流を深めることができました。 今回は、参加した社員の感想をもとに、DroidKaigi 2024 の様子をお伝えします！ 会場の様子 DroidKaigi 2024 は、たくさんの人で溢れた、非常に賑やかなカンファレンスでした！ こちらはオープニングの様子。朝の時点で、かなりの人数が集まっていることがわかると思います。 軽食やコーヒーの提供があったり、ネイルブースに、プリクラまで、様々な企画が行われていました。ネイルブースでは、Android のキャラクターとロゴを使ったネイルを施していただきました！ また、DroidKaigi 2024 では、名札にシールを貼って、自分の興味分野を示すことができます。他の参加者の方と話す場面でも、このシールを見ながら技術の話ができ、とても良い取り組みだなと思いました。 私の作った名札はこんな感じです。私は React Native でクロスプラットフォーム開発をしているので、React Native のシールも欲しかったです。残念！ DroidKaigi 2024 で最も賑やかだったのが、1 日目の夜に開催されたアフターパーティーです。たくさんのお食事が並ぶ中、立食形式で参加者同士が自由に交流できるイベントでした。かなり広いスペースが確保されていたのですが、それでもかなり混雑しているほどの盛況ぶり！ 私も参加し、様々な企業の方とお話しすることができました。 また、メドレーは iOSDC Japan 2024 でもスポンサーをさせていただきました（詳細は こちら ）が、iOSDC と最も違うところは、国際色ではないかと思います。iOSDC では日本語でのセッションのみでしたが、DroidKaigi では英語のセッションがあったり、ブースでも英語や韓国語で話しかけられることがありました！ 多様な人がいるからこそ、新しい出会いや学びもより多く得られたのではないかと思います。 メドレーブースの様子 メドレーブースでは、iOSDC 同様、メドレーが展開するアプリの紹介と、アンケートパネルを用いて参加者の方々に医療体験に関するお悩みを伺いました。 DroidKaigi 2024 での最終結果はこちら！ 1 位　待ち時間が長い！ 2 位　何科に通えば良いかわからない！ 3 位　病院探しに時間がかかる・オンラインで予約したい iOSDC の時と似たような結果になりました！やはりみなさん同じような悩みを抱えていらっしゃるようです。 メドレーでは、 これらの課題を解決するべく、様々なプロダクト・サービスを展開しています 。上位にランクインした課題は、患者向けに提供しているオンライン診療・服薬指導アプリ「 CLINICS 」（以降、CLINICS アプリ）で以下のような機能を提供することで解決を目指しています。現地では実際に画面を見せながら、機能の説明を行いました。 待ち時間が長い！ CLINICS アプリを使ってオンラインで診療を受けることができます CLINICS アプリを使って事前に問診票に回答したり、CLINICS アプリでキャッシュレス決済を行うことでも、待ち時間を減らすことができます 何科に通えば良いかわからない！ CLINICS アプリで気になる症状を選択し設問に回答すると、考えられる病気と診療科を紹介します 病院探しに時間がかかる・オンラインで予約したい CLINICS アプリから、さまざまな条件で病院を探し、そのまま予約をすることができます また、オンライン服薬指導や、Amazon ファーマシーとの連携、処方薬の配送などについてもお話ししました。その他にも、モバイルアプリの開発体制や、オンラインビデオ通話の実現方法など、技術的な面でもたくさんのご質問をいただきました。 CLINICS アプリについて説明していくと、「めちゃくちゃ良いですね！」といった反応をいただける反面、「つまりはまだまだ知られていないな」ということを痛感します。もっともっとメドレーの、そして提供しているサービスやプロダクトの認知度を上げていくために、様々な取り組みをしていかなければいけませんね。 セッションやブース DroidKaigi 2024 では、48 のセッションと、30 以上のスポンサーブースが設置されていました。メドレー社員が参加したものの中から、いくつかピックアップしてご紹介します。 セッション：宣言的 UI を学ぶ際に知っておくべき重要なコンセプト SwiftUI 、 Jetpack Compose 、React Native の実装を通して、宣言的 UI がどのようなコンセプトを持っているかを紹介していました。それぞれ異なるツールキットですが、 宣言的 UI という観点から見ると確かに同じ思想をしている なと感じることができました。 (詳細ページは こちら ) セッション：起動時間で差をつけろ！アプリ起動パフォーマンス改善！ アプリの起動、と一口に言っても、プロセスがない状態から起動するケースもあれば、バックグラウンドでプロセスが実行されているケースなど様々な起動方法があります。このセッションでは、 アプリの起動にどのような種類があるか、そしてそれぞれのケースでどのような処理が行われるのかを整理 した上で、起動時間の計測方法や改善方法などを、具体例を通じて示していました。今まで起動時間は計測したことがなかったので、これを気にチャレンジしてみたいです。 (詳細ページは こちら ) セッション：Android View から Jetpack Compose へ 〜Jetpack Compose 移行のすゝめ〜 タイトルの通り、 Jetpack Compose 移行に関するお話 で、 具体的な移行の事例も交えながら説明 されていました。メドレーでも Jetpack Compose を導入しており、その際に苦労した、Jetpack Compose の自由度の高さなども話題に上がっていました。 これから Jetpack Compose へ移行していく人にはとてもわかりやすい発表内容でした。 (詳細ページは こちら ) ブース：株式会社ゆめみ DroidKaigi ならでは！と思ったブースが、株式会社ゆめみさんのブースです。 Android アプリの開発では Android Studio という IDE が使われることが多いのですが、Android Studio はバージョン名が動物の名前になっています。その動物たちを、リリース順に並び替えよう！というものです（なお、各動物を英語で表した時の頭文字がアルファベット順になるように選ばれているので、全動物を完璧に英訳できればその方針でもクリアできます。） 私もチャレンジしてみましたが、2 箇所間違えてしまいました……難しい！ みなさんは分かりましたか？ 終わりに メドレーはこれからも、医療ヘルスケアの未来を作るために、アプリを始めとした様々なプロダクト・サービスを開発し提供していきます。 最後に改めて、DroidKaigi 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、お疲れ様でした、そしてありがとうございました！ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースなどで興味を持っていただいた方はご連絡いただければと思います！カジュアル面談など実施可能ですので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！ さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催された「 DroidKaigi 2024 」にゴールドスポンサーとして協賛させていただきました。 DroidKaigi は、 今年で 10 年目を迎える Android カンファレンス です。国内外から Android エンジニアが集い、幅広い内容のセッションとともに、Android 技術情報の共有とコミュニケーションが行われています。 そんな歴史あるカンファレンスですが、メドレーがブースを出すのは今年が初めて。採用担当・広報・ネイティブアプリエンジニアなど総勢 7 名で参加し、様々なセッションを聞いたり、多くのエンジニアとの交流を深めることができました。 今回は、参加した社員の感想をもとに、DroidKaigi 2024 の様子をお伝えします！ 会場の様子 DroidKaigi 2024 は、たくさんの人で溢れた、非常に賑やかなカンファレンスでした！ こちらはオープニングの様子。朝の時点で、かなりの人数が集まっていることがわかると思います。 軽食やコーヒーの提供があったり、ネイルブースに、プリクラまで、様々な企画が行われていました。ネイルブースでは、Android のキャラクターとロゴを使ったネイルを施していただきました！ また、DroidKaigi 2024 では、名札にシールを貼って、自分の興味分野を示すことができます。他の参加者の方と話す場面でも、このシールを見ながら技術の話ができ、とても良い取り組みだなと思いました。 私の作った名札はこんな感じです。私は React Native でクロスプラットフォーム開発をしているので、React Native のシールも欲しかったです。残念！ DroidKaigi 2024 で最も賑やかだったのが、1 日目の夜に開催されたアフターパーティーです。たくさんのお食事が並ぶ中、立食形式で参加者同士が自由に交流できるイベントでした。かなり広いスペースが確保されていたのですが、それでもかなり混雑しているほどの盛況ぶり！ 私も参加し、様々な企業の方とお話しすることができました。 また、メドレーは iOSDC Japan 2024 でもスポンサーをさせていただきました（詳細は こちら ）が、iOSDC と最も違うところは、国際色ではないかと思います。iOSDC では日本語でのセッションのみでしたが、DroidKaigi では英語のセッションがあったり、ブースでも英語や韓国語で話しかけられることがありました！ 多様な人がいるからこそ、新しい出会いや学びもより多く得られたのではないかと思います。 メドレーブースの様子 メドレーブースでは、iOSDC 同様、メドレーが展開するアプリの紹介と、アンケートパネルを用いて参加者の方々に医療体験に関するお悩みを伺いました。 DroidKaigi 2024 での最終結果はこちら！ 1 位　待ち時間が長い！ 2 位　何科に通えば良いかわからない！ 3 位　病院探しに時間がかかる・オンラインで予約したい iOSDC の時と似たような結果になりました！やはりみなさん同じような悩みを抱えていらっしゃるようです。 メドレーでは、 これらの課題を解決するべく、様々なプロダクト・サービスを展開しています 。上位にランクインした課題は、患者向けに提供しているオンライン診療・服薬指導アプリ「 CLINICS 」（以降、CLINICS アプリ）で以下のような機能を提供することで解決を目指しています。現地では実際に画面を見せながら、機能の説明を行いました。 待ち時間が長い！ CLINICS アプリを使ってオンラインで診療を受けることができます CLINICS アプリを使って事前に問診票に回答したり、CLINICS アプリでキャッシュレス決済を行うことでも、待ち時間を減らすことができます 何科に通えば良いかわからない！ CLINICS アプリで気になる症状を選択し設問に回答すると、考えられる病気と診療科を紹介します 病院探しに時間がかかる・オンラインで予約したい CLINICS アプリから、さまざまな条件で病院を探し、そのまま予約をすることができます また、オンライン服薬指導や、Amazon ファーマシーとの連携、処方薬の配送などについてもお話ししました。その他にも、モバイルアプリの開発体制や、オンラインビデオ通話の実現方法など、技術的な面でもたくさんのご質問をいただきました。 CLINICS アプリについて説明していくと、「めちゃくちゃ良いですね！」といった反応をいただける反面、「つまりはまだまだ知られていないな」ということを痛感します。もっともっとメドレーの、そして提供しているサービスやプロダクトの認知度を上げていくために、様々な取り組みをしていかなければいけませんね。 セッションやブース DroidKaigi 2024 では、48 のセッションと、30 以上のスポンサーブースが設置されていました。メドレー社員が参加したものの中から、いくつかピックアップしてご紹介します。 セッション：宣言的 UI を学ぶ際に知っておくべき重要なコンセプト SwiftUI 、 Jetpack Compose 、React Native の実装を通して、宣言的 UI がどのようなコンセプトを持っているかを紹介していました。それぞれ異なるツールキットですが、 宣言的 UI という観点から見ると確かに同じ思想をしている なと感じることができました。 (詳細ページは こちら ) セッション：起動時間で差をつけろ！アプリ起動パフォーマンス改善！ アプリの起動、と一口に言っても、プロセスがない状態から起動するケースもあれば、バックグラウンドでプロセスが実行されているケースなど様々な起動方法があります。このセッションでは、 アプリの起動にどのような種類があるか、そしてそれぞれのケースでどのような処理が行われるのかを整理 した上で、起動時間の計測方法や改善方法などを、具体例を通じて示していました。今まで起動時間は計測したことがなかったので、これを気にチャレンジしてみたいです。 (詳細ページは こちら ) セッション：Android View から Jetpack Compose へ 〜Jetpack Compose 移行のすゝめ〜 タイトルの通り、 Jetpack Compose 移行に関するお話 で、 具体的な移行の事例も交えながら説明 されていました。メドレーでも Jetpack Compose を導入しており、その際に苦労した、Jetpack Compose の自由度の高さなども話題に上がっていました。 これから Jetpack Compose へ移行していく人にはとてもわかりやすい発表内容でした。 (詳細ページは こちら ) ブース：株式会社ゆめみ DroidKaigi ならでは！と思ったブースが、株式会社ゆめみさんのブースです。 Android アプリの開発では Android Studio という IDE が使われることが多いのですが、Android Studio はバージョン名が動物の名前になっています。その動物たちを、リリース順に並び替えよう！というものです（なお、各動物を英語で表した時の頭文字がアルファベット順になるように選ばれているので、全動物を完璧に英訳できればその方針でもクリアできます。） 私もチャレンジしてみましたが、2 箇所間違えてしまいました……難しい！ みなさんは分かりましたか？ 終わりに メドレーはこれからも、医療ヘルスケアの未来を作るために、アプリを始めとした様々なプロダクト・サービスを開発し提供していきます。 最後に改めて、DroidKaigi 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、お疲れ様でした、そしてありがとうございました！ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースなどで興味を持っていただいた方はご連絡いただければと思います！カジュアル面談など実施可能ですので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！ さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催された「 DroidKaigi 2024 」にゴールドスポンサーとして協賛させていただきました。 DroidKaigi は、 今年で 10 年目を迎える Android カンファレンス です。国内外から Android エンジニアが集い、幅広い内容のセッションとともに、Android 技術情報の共有とコミュニケーションが行われています。 そんな歴史あるカンファレンスですが、メドレーがブースを出すのは今年が初めて。採用担当・広報・ネイティブアプリエンジニアなど総勢 7 名で参加し、様々なセッションを聞いたり、多くのエンジニアとの交流を深めることができました。 今回は、参加した社員の感想をもとに、DroidKaigi 2024 の様子をお伝えします！ 会場の様子 DroidKaigi 2024 は、たくさんの人で溢れた、非常に賑やかなカンファレンスでした！ こちらはオープニングの様子。朝の時点で、かなりの人数が集まっていることがわかると思います。 軽食やコーヒーの提供があったり、ネイルブースに、プリクラまで、様々な企画が行われていました。ネイルブースでは、Android のキャラクターとロゴを使ったネイルを施していただきました！ また、DroidKaigi 2024 では、名札にシールを貼って、自分の興味分野を示すことができます。他の参加者の方と話す場面でも、このシールを見ながら技術の話ができ、とても良い取り組みだなと思いました。 私の作った名札はこんな感じです。私は React Native でクロスプラットフォーム開発をしているので、React Native のシールも欲しかったです。残念！ DroidKaigi 2024 で最も賑やかだったのが、1 日目の夜に開催されたアフターパーティーです。たくさんのお食事が並ぶ中、立食形式で参加者同士が自由に交流できるイベントでした。かなり広いスペースが確保されていたのですが、それでもかなり混雑しているほどの盛況ぶり！ 私も参加し、様々な企業の方とお話しすることができました。 また、メドレーは iOSDC Japan 2024 でもスポンサーをさせていただきました（詳細は こちら ）が、iOSDC と最も違うところは、国際色ではないかと思います。iOSDC では日本語でのセッションのみでしたが、DroidKaigi では英語のセッションがあったり、ブースでも英語や韓国語で話しかけられることがありました！ 多様な人がいるからこそ、新しい出会いや学びもより多く得られたのではないかと思います。 メドレーブースの様子 メドレーブースでは、iOSDC 同様、メドレーが展開するアプリの紹介と、アンケートパネルを用いて参加者の方々に医療体験に関するお悩みを伺いました。 DroidKaigi 2024 での最終結果はこちら！ 1 位　待ち時間が長い！ 2 位　何科に通えば良いかわからない！ 3 位　病院探しに時間がかかる・オンラインで予約したい iOSDC の時と似たような結果になりました！やはりみなさん同じような悩みを抱えていらっしゃるようです。 メドレーでは、 これらの課題を解決するべく、様々なプロダクト・サービスを展開しています 。上位にランクインした課題は、患者向けに提供しているオンライン診療・服薬指導アプリ「 CLINICS 」（以降、CLINICS アプリ）で以下のような機能を提供することで解決を目指しています。現地では実際に画面を見せながら、機能の説明を行いました。 待ち時間が長い！ CLINICS アプリを使ってオンラインで診療を受けることができます CLINICS アプリを使って事前に問診票に回答したり、CLINICS アプリでキャッシュレス決済を行うことでも、待ち時間を減らすことができます 何科に通えば良いかわからない！ CLINICS アプリで気になる症状を選択し設問に回答すると、考えられる病気と診療科を紹介します 病院探しに時間がかかる・オンラインで予約したい CLINICS アプリから、さまざまな条件で病院を探し、そのまま予約をすることができます また、オンライン服薬指導や、Amazon ファーマシーとの連携、処方薬の配送などについてもお話ししました。その他にも、モバイルアプリの開発体制や、オンラインビデオ通話の実現方法など、技術的な面でもたくさんのご質問をいただきました。 CLINICS アプリについて説明していくと、「めちゃくちゃ良いですね！」といった反応をいただける反面、「つまりはまだまだ知られていないな」ということを痛感します。もっともっとメドレーの、そして提供しているサービスやプロダクトの認知度を上げていくために、様々な取り組みをしていかなければいけませんね。 セッションやブース DroidKaigi 2024 では、48 のセッションと、30 以上のスポンサーブースが設置されていました。メドレー社員が参加したものの中から、いくつかピックアップしてご紹介します。 セッション：宣言的 UI を学ぶ際に知っておくべき重要なコンセプト SwiftUI 、 Jetpack Compose 、React Native の実装を通して、宣言的 UI がどのようなコンセプトを持っているかを紹介していました。それぞれ異なるツールキットですが、 宣言的 UI という観点から見ると確かに同じ思想をしている なと感じることができました。 (詳細ページは こちら ) セッション：起動時間で差をつけろ！アプリ起動パフォーマンス改善！ アプリの起動、と一口に言っても、プロセスがない状態から起動するケースもあれば、バックグラウンドでプロセスが実行されているケースなど様々な起動方法があります。このセッションでは、 アプリの起動にどのような種類があるか、そしてそれぞれのケースでどのような処理が行われるのかを整理 した上で、起動時間の計測方法や改善方法などを、具体例を通じて示していました。今まで起動時間は計測したことがなかったので、これを気にチャレンジしてみたいです。 (詳細ページは こちら ) セッション：Android View から Jetpack Compose へ 〜Jetpack Compose 移行のすゝめ〜 タイトルの通り、 Jetpack Compose 移行に関するお話 で、 具体的な移行の事例も交えながら説明 されていました。メドレーでも Jetpack Compose を導入しており、その際に苦労した、Jetpack Compose の自由度の高さなども話題に上がっていました。 これから Jetpack Compose へ移行していく人にはとてもわかりやすい発表内容でした。 (詳細ページは こちら ) ブース：株式会社ゆめみ DroidKaigi ならでは！と思ったブースが、株式会社ゆめみさんのブースです。 Android アプリの開発では Android Studio という IDE が使われることが多いのですが、Android Studio はバージョン名が動物の名前になっています。その動物たちを、リリース順に並び替えよう！というものです（なお、各動物を英語で表した時の頭文字がアルファベット順になるように選ばれているので、全動物を完璧に英訳できればその方針でもクリアできます。） 私もチャレンジしてみましたが、2 箇所間違えてしまいました……難しい！ みなさんは分かりましたか？ 終わりに メドレーはこれからも、医療ヘルスケアの未来を作るために、アプリを始めとした様々なプロダクト・サービスを開発し提供していきます。 最後に改めて、DroidKaigi 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、お疲れ様でした、そしてありがとうございました！ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースなどで興味を持っていただいた方はご連絡いただければと思います！カジュアル面談など実施可能ですので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！ さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催された「 DroidKaigi 2024 」にゴールドスポンサーとして協賛させていただきました。 DroidKaigi は、 今年で 10 年目を迎える Android カンファレンス です。国内外から Android エンジニアが集い、幅広い内容のセッションとともに、Android 技術情報の共有とコミュニケーションが行われています。 そんな歴史あるカンファレンスですが、メドレーがブースを出すのは今年が初めて。採用担当・広報・ネイティブアプリエンジニアなど総勢 7 名で参加し、様々なセッションを聞いたり、多くのエンジニアとの交流を深めることができました。 今回は、参加した社員の感想をもとに、DroidKaigi 2024 の様子をお伝えします！ 会場の様子 DroidKaigi 2024 は、たくさんの人で溢れた、非常に賑やかなカンファレンスでした！ こちらはオープニングの様子。朝の時点で、かなりの人数が集まっていることがわかると思います。 軽食やコーヒーの提供があったり、ネイルブースに、プリクラまで、様々な企画が行われていました。ネイルブースでは、Android のキャラクターとロゴを使ったネイルを施していただきました！ また、DroidKaigi 2024 では、名札にシールを貼って、自分の興味分野を示すことができます。他の参加者の方と話す場面でも、このシールを見ながら技術の話ができ、とても良い取り組みだなと思いました。 私の作った名札はこんな感じです。私は React Native でクロスプラットフォーム開発をしているので、React Native のシールも欲しかったです。残念！ DroidKaigi 2024 で最も賑やかだったのが、1 日目の夜に開催されたアフターパーティーです。たくさんのお食事が並ぶ中、立食形式で参加者同士が自由に交流できるイベントでした。かなり広いスペースが確保されていたのですが、それでもかなり混雑しているほどの盛況ぶり！ 私も参加し、様々な企業の方とお話しすることができました。 また、メドレーは iOSDC Japan 2024 でもスポンサーをさせていただきました（詳細は こちら ）が、iOSDC と最も違うところは、国際色ではないかと思います。iOSDC では日本語でのセッションのみでしたが、DroidKaigi では英語のセッションがあったり、ブースでも英語や韓国語で話しかけられることがありました！ 多様な人がいるからこそ、新しい出会いや学びもより多く得られたのではないかと思います。 メドレーブースの様子 メドレーブースでは、iOSDC 同様、メドレーが展開するアプリの紹介と、アンケートパネルを用いて参加者の方々に医療体験に関するお悩みを伺いました。 DroidKaigi 2024 での最終結果はこちら！ 1 位　待ち時間が長い！ 2 位　何科に通えば良いかわからない！ 3 位　病院探しに時間がかかる・オンラインで予約したい iOSDC の時と似たような結果になりました！やはりみなさん同じような悩みを抱えていらっしゃるようです。 メドレーでは、 これらの課題を解決するべく、様々なプロダクト・サービスを展開しています 。上位にランクインした課題は、患者向けに提供しているオンライン診療・服薬指導アプリ「 CLINICS 」（以降、CLINICS アプリ）で以下のような機能を提供することで解決を目指しています。現地では実際に画面を見せながら、機能の説明を行いました。 待ち時間が長い！ CLINICS アプリを使ってオンラインで診療を受けることができます CLINICS アプリを使って事前に問診票に回答したり、CLINICS アプリでキャッシュレス決済を行うことでも、待ち時間を減らすことができます 何科に通えば良いかわからない！ CLINICS アプリで気になる症状を選択し設問に回答すると、考えられる病気と診療科を紹介します 病院探しに時間がかかる・オンラインで予約したい CLINICS アプリから、さまざまな条件で病院を探し、そのまま予約をすることができます また、オンライン服薬指導や、Amazon ファーマシーとの連携、処方薬の配送などについてもお話ししました。その他にも、モバイルアプリの開発体制や、オンラインビデオ通話の実現方法など、技術的な面でもたくさんのご質問をいただきました。 CLINICS アプリについて説明していくと、「めちゃくちゃ良いですね！」といった反応をいただける反面、「つまりはまだまだ知られていないな」ということを痛感します。もっともっとメドレーの、そして提供しているサービスやプロダクトの認知度を上げていくために、様々な取り組みをしていかなければいけませんね。 セッションやブース DroidKaigi 2024 では、48 のセッションと、30 以上のスポンサーブースが設置されていました。メドレー社員が参加したものの中から、いくつかピックアップしてご紹介します。 セッション：宣言的 UI を学ぶ際に知っておくべき重要なコンセプト SwiftUI 、 Jetpack Compose 、React Native の実装を通して、宣言的 UI がどのようなコンセプトを持っているかを紹介していました。それぞれ異なるツールキットですが、 宣言的 UI という観点から見ると確かに同じ思想をしている なと感じることができました。 (詳細ページは こちら ) セッション：起動時間で差をつけろ！アプリ起動パフォーマンス改善！ アプリの起動、と一口に言っても、プロセスがない状態から起動するケースもあれば、バックグラウンドでプロセスが実行されているケースなど様々な起動方法があります。このセッションでは、 アプリの起動にどのような種類があるか、そしてそれぞれのケースでどのような処理が行われるのかを整理 した上で、起動時間の計測方法や改善方法などを、具体例を通じて示していました。今まで起動時間は計測したことがなかったので、これを気にチャレンジしてみたいです。 (詳細ページは こちら ) セッション：Android View から Jetpack Compose へ 〜Jetpack Compose 移行のすゝめ〜 タイトルの通り、 Jetpack Compose 移行に関するお話 で、 具体的な移行の事例も交えながら説明 されていました。メドレーでも Jetpack Compose を導入しており、その際に苦労した、Jetpack Compose の自由度の高さなども話題に上がっていました。 これから Jetpack Compose へ移行していく人にはとてもわかりやすい発表内容でした。 (詳細ページは こちら ) ブース：株式会社ゆめみ DroidKaigi ならでは！と思ったブースが、株式会社ゆめみさんのブースです。 Android アプリの開発では Android Studio という IDE が使われることが多いのですが、Android Studio はバージョン名が動物の名前になっています。その動物たちを、リリース順に並び替えよう！というものです（なお、各動物を英語で表した時の頭文字がアルファベット順になるように選ばれているので、全動物を完璧に英訳できればその方針でもクリアできます。） 私もチャレンジしてみましたが、2 箇所間違えてしまいました……難しい！ みなさんは分かりましたか？ 終わりに メドレーはこれからも、医療ヘルスケアの未来を作るために、アプリを始めとした様々なプロダクト・サービスを開発し提供していきます。 最後に改めて、DroidKaigi 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、お疲れ様でした、そしてありがとうございました！ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースなどで興味を持っていただいた方はご連絡いただければと思います！カジュアル面談など実施可能ですので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！ さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催された「 DroidKaigi 2024 」にゴールドスポンサーとして協賛させていただきました。 DroidKaigi は、 今年で 10 年目を迎える Android カンファレンス です。国内外から Android エンジニアが集い、幅広い内容のセッションとともに、Android 技術情報の共有とコミュニケーションが行われています。 そんな歴史あるカンファレンスですが、メドレーがブースを出すのは今年が初めて。採用担当・広報・ネイティブアプリエンジニアなど総勢 7 名で参加し、様々なセッションを聞いたり、多くのエンジニアとの交流を深めることができました。 今回は、参加した社員の感想をもとに、DroidKaigi 2024 の様子をお伝えします！ 会場の様子 DroidKaigi 2024 は、たくさんの人で溢れた、非常に賑やかなカンファレンスでした！ こちらはオープニングの様子。朝の時点で、かなりの人数が集まっていることがわかると思います。 軽食やコーヒーの提供があったり、ネイルブースに、プリクラまで、様々な企画が行われていました。ネイルブースでは、Android のキャラクターとロゴを使ったネイルを施していただきました！ また、DroidKaigi 2024 では、名札にシールを貼って、自分の興味分野を示すことができます。他の参加者の方と話す場面でも、このシールを見ながら技術の話ができ、とても良い取り組みだなと思いました。 私の作った名札はこんな感じです。私は React Native でクロスプラットフォーム開発をしているので、React Native のシールも欲しかったです。残念！ DroidKaigi 2024 で最も賑やかだったのが、1 日目の夜に開催されたアフターパーティーです。たくさんのお食事が並ぶ中、立食形式で参加者同士が自由に交流できるイベントでした。かなり広いスペースが確保されていたのですが、それでもかなり混雑しているほどの盛況ぶり！ 私も参加し、様々な企業の方とお話しすることができました。 また、メドレーは iOSDC Japan 2024 でもスポンサーをさせていただきました（詳細は こちら ）が、iOSDC と最も違うところは、国際色ではないかと思います。iOSDC では日本語でのセッションのみでしたが、DroidKaigi では英語のセッションがあったり、ブースでも英語や韓国語で話しかけられることがありました！ 多様な人がいるからこそ、新しい出会いや学びもより多く得られたのではないかと思います。 メドレーブースの様子 メドレーブースでは、iOSDC 同様、メドレーが展開するアプリの紹介と、アンケートパネルを用いて参加者の方々に医療体験に関するお悩みを伺いました。 DroidKaigi 2024 での最終結果はこちら！ 1 位　待ち時間が長い！ 2 位　何科に通えば良いかわからない！ 3 位　病院探しに時間がかかる・オンラインで予約したい iOSDC の時と似たような結果になりました！やはりみなさん同じような悩みを抱えていらっしゃるようです。 メドレーでは、 これらの課題を解決するべく、様々なプロダクト・サービスを展開しています 。上位にランクインした課題は、患者向けに提供しているオンライン診療・服薬指導アプリ「 CLINICS 」（以降、CLINICS アプリ）で以下のような機能を提供することで解決を目指しています。現地では実際に画面を見せながら、機能の説明を行いました。 待ち時間が長い！ CLINICS アプリを使ってオンラインで診療を受けることができます CLINICS アプリを使って事前に問診票に回答したり、CLINICS アプリでキャッシュレス決済を行うことでも、待ち時間を減らすことができます 何科に通えば良いかわからない！ CLINICS アプリで気になる症状を選択し設問に回答すると、考えられる病気と診療科を紹介します 病院探しに時間がかかる・オンラインで予約したい CLINICS アプリから、さまざまな条件で病院を探し、そのまま予約をすることができます また、オンライン服薬指導や、Amazon ファーマシーとの連携、処方薬の配送などについてもお話ししました。その他にも、モバイルアプリの開発体制や、オンラインビデオ通話の実現方法など、技術的な面でもたくさんのご質問をいただきました。 CLINICS アプリについて説明していくと、「めちゃくちゃ良いですね！」といった反応をいただける反面、「つまりはまだまだ知られていないな」ということを痛感します。もっともっとメドレーの、そして提供しているサービスやプロダクトの認知度を上げていくために、様々な取り組みをしていかなければいけませんね。 セッションやブース DroidKaigi 2024 では、48 のセッションと、30 以上のスポンサーブースが設置されていました。メドレー社員が参加したものの中から、いくつかピックアップしてご紹介します。 セッション：宣言的 UI を学ぶ際に知っておくべき重要なコンセプト SwiftUI 、 Jetpack Compose 、React Native の実装を通して、宣言的 UI がどのようなコンセプトを持っているかを紹介していました。それぞれ異なるツールキットですが、 宣言的 UI という観点から見ると確かに同じ思想をしている なと感じることができました。 (詳細ページは こちら ) セッション：起動時間で差をつけろ！アプリ起動パフォーマンス改善！ アプリの起動、と一口に言っても、プロセスがない状態から起動するケースもあれば、バックグラウンドでプロセスが実行されているケースなど様々な起動方法があります。このセッションでは、 アプリの起動にどのような種類があるか、そしてそれぞれのケースでどのような処理が行われるのかを整理 した上で、起動時間の計測方法や改善方法などを、具体例を通じて示していました。今まで起動時間は計測したことがなかったので、これを気にチャレンジしてみたいです。 (詳細ページは こちら ) セッション：Android View から Jetpack Compose へ 〜Jetpack Compose 移行のすゝめ〜 タイトルの通り、 Jetpack Compose 移行に関するお話 で、 具体的な移行の事例も交えながら説明 されていました。メドレーでも Jetpack Compose を導入しており、その際に苦労した、Jetpack Compose の自由度の高さなども話題に上がっていました。 これから Jetpack Compose へ移行していく人にはとてもわかりやすい発表内容でした。 (詳細ページは こちら ) ブース：株式会社ゆめみ DroidKaigi ならでは！と思ったブースが、株式会社ゆめみさんのブースです。 Android アプリの開発では Android Studio という IDE が使われることが多いのですが、Android Studio はバージョン名が動物の名前になっています。その動物たちを、リリース順に並び替えよう！というものです（なお、各動物を英語で表した時の頭文字がアルファベット順になるように選ばれているので、全動物を完璧に英訳できればその方針でもクリアできます。） 私もチャレンジしてみましたが、2 箇所間違えてしまいました……難しい！ みなさんは分かりましたか？ 終わりに メドレーはこれからも、医療ヘルスケアの未来を作るために、アプリを始めとした様々なプロダクト・サービスを開発し提供していきます。 最後に改めて、DroidKaigi 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、お疲れ様でした、そしてありがとうございました！ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースなどで興味を持っていただいた方はご連絡いただければと思います！カジュアル面談など実施可能ですので、お気軽にお問い合わせください！ メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp

こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！ さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催された「 DroidKaigi 2024 」にゴールドスポンサーとして協賛させていただきました。 DroidKaigi は、 今年で 10 年目を迎える Android カンファレンス です。国内外から Android エンジニアが集い、幅広い内容のセッションとともに、Android 技術情報の共有とコミュニケーションが行われています。 そんな歴史あるカンファレンスですが、メドレーがブースを出すのは今年が初めて。採用担当・広報・ネイティブアプリエンジニアなど総勢 7 名で参加し、様々なセッションを聞いたり、多くのエンジニアとの交流を深めることができました。 今回は、参加した社員の感想をもとに、DroidKaigi 2024 の様子をお伝えします！ 会場の様子 DroidKaigi 2024 は、たくさんの人で溢れた、非常に賑やかなカンファレンスでした！ こちらはオープニングの様子。朝の時点で、かなりの人数が集まっていることがわかると思います。 軽食やコーヒーの提供があったり、ネイルブースに、プリクラまで、様々な企画が行われていました。ネイルブースでは、Android のキャラクターとロゴを使ったネイルを施していただきました！ また、DroidKaigi 2024 では、名札にシールを貼って、自分の興味分野を示すことができます。他の参加者の方と話す場面でも、このシールを見ながら技術の話ができ、とても良い取り組みだなと思いました。 私の作った名札はこんな感じです。私は React Native でクロスプラットフォーム開発をしているので、React Native のシールも欲しかったです。残念！ DroidKaigi 2024 で最も賑やかだったのが、1 日目の夜に開催されたアフターパーティーです。たくさんのお食事が並ぶ中、立食形式で参加者同士が自由に交流できるイベントでした。かなり広いスペースが確保されていたのですが、それでもかなり混雑しているほどの盛況ぶり！ 私も参加し、様々な企業の方とお話しすることができました。 また、メドレーは iOSDC Japan 2024 でもスポンサーをさせていただきました（詳細は こちら ）が、iOSDC と最も違うところは、国際色ではないかと思います。iOSDC では日本語でのセッションのみでしたが、DroidKaigi では英語のセッションがあったり、ブースでも英語や韓国語で話しかけられることがありました！ 多様な人がいるからこそ、新しい出会いや学びもより多く得られたのではないかと思います。 メドレーブースの様子 メドレーブースでは、iOSDC 同様、メドレーが展開するアプリの紹介と、アンケートパネルを用いて参加者の方々に医療体験に関するお悩みを伺いました。 DroidKaigi 2024 での最終結果はこちら！ 1 位　待ち時間が長い！ 2 位　何科に通えば良いかわからない！ 3 位　病院探しに時間がかかる・オンラインで予約したい iOSDC の時と似たような結果になりました！やはりみなさん同じような悩みを抱えていらっしゃるようです。 メドレーでは、 これらの課題を解決するべく、様々なプロダクト・サービスを展開しています 。上位にランクインした課題は、患者向けに提供しているオンライン診療・服薬指導アプリ「 CLINICS 」（以降、CLINICS アプリ）で以下のような機能を提供することで解決を目指しています。現地では実際に画面を見せながら、機能の説明を行いました。 待ち時間が長い！ CLINICS アプリを使ってオンラインで診療を受けることができます CLINICS アプリを使って事前に問診票に回答したり、CLINICS アプリでキャッシュレス決済を行うことでも、待ち時間を減らすことができます 何科に通えば良いかわからない！ CLINICS アプリで気になる症状を選択し設問に回答すると、考えられる病気と診療科を紹介します 病院探しに時間がかかる・オンラインで予約したい CLINICS アプリから、さまざまな条件で病院を探し、そのまま予約をすることができます また、オンライン服薬指導や、Amazon ファーマシーとの連携、処方薬の配送などについてもお話ししました。その他にも、モバイルアプリの開発体制や、オンラインビデオ通話の実現方法など、技術的な面でもたくさんのご質問をいただきました。 CLINICS アプリについて説明していくと、「めちゃくちゃ良いですね！」といった反応をいただける反面、「つまりはまだまだ知られていないな」ということを痛感します。もっともっとメドレーの、そして提供しているサービスやプロダクトの認知度を上げていくために、様々な取り組みをしていかなければいけませんね。 セッションやブース DroidKaigi 2024 では、48 のセッションと、30 以上のスポンサーブースが設置されていました。メドレー社員が参加したものの中から、いくつかピックアップしてご紹介します。 セッション：宣言的 UI を学ぶ際に知っておくべき重要なコンセプト SwiftUI 、 Jetpack Compose 、React Native の実装を通して、宣言的 UI がどのようなコンセプトを持っているかを紹介していました。それぞれ異なるツールキットですが、 宣言的 UI という観点から見ると確かに同じ思想をしている なと感じることができました。 (詳細ページは こちら ) セッション：起動時間で差をつけろ！アプリ起動パフォーマンス改善！ アプリの起動、と一口に言っても、プロセスがない状態から起動するケースもあれば、バックグラウンドでプロセスが実行されているケースなど様々な起動方法があります。このセッションでは、 アプリの起動にどのような種類があるか、そしてそれぞれのケースでどのような処理が行われるのかを整理 した上で、起動時間の計測方法や改善方法などを、具体例を通じて示していました。今まで起動時間は計測したことがなかったので、これを気にチャレンジしてみたいです。 (詳細ページは こちら ) セッション：Android View から Jetpack Compose へ 〜Jetpack Compose 移行のすゝめ〜 タイトルの通り、 Jetpack Compose 移行に関するお話 で、 具体的な移行の事例も交えながら説明 されていました。メドレーでも Jetpack Compose を導入しており、その際に苦労した、Jetpack Compose の自由度の高さなども話題に上がっていました。 これから Jetpack Compose へ移行していく人にはとてもわかりやすい発表内容でした。 (詳細ページは こちら ) ブース：株式会社ゆめみ DroidKaigi ならでは！と思ったブースが、株式会社ゆめみさんのブースです。 Android アプリの開発では Android Studio という IDE が使われることが多いのですが、Android Studio はバージョン名が動物の名前になっています。その動物たちを、リリース順に並び替えよう！というものです（なお、各動物を英語で表した時の頭文字がアルファベット順になるように選ばれているので、全動物を完璧に英訳できればその方針でもクリアできます。） 私もチャレンジしてみましたが、2 箇所間違えてしまいました……難しい！ みなさんは分かりましたか？ 終わりに メドレーはこれからも、医療ヘルスケアの未来を作るために、アプリを始めとした様々なプロダクト・サービスを開発し提供していきます。 最後に改めて、DroidKaigi 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、お疲れ様でした、そしてありがとうございました！ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースなどで興味を持っていただいた方はご連絡いただければと思います！カジュアル面談など実施可能ですので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp