はじめに みなさん、こんにちは。エンジニアの新居です。今回は今年の 3 月にリリースされた Dentis のサブカルテ機能について、開発したメンバーに話を聞いてみました! 対談メンバー紹介 Dentis 開発メンバーの紹介 新居 : よろしくお願いします。早速ですが、メドレーに入社するまでや、入ってからどんな事をしていたのかを話してもらえればと思います。 前田 : CLINICS のリリース前から、ロゴデザインや UI デザインに携わったのがきっかけでメドレーに入社しました。入社してからは、CLINICS アプリや CLINICS カルテ、薬局向けシステム Pharms などのプロダクトをこのメンバーと一緒に開発していました。今は歯科医院向けの Dentis のデザインや企画、プロモーションなどに関わっています。 前田さん 大岡 : ソーシャルゲームを 6~7 年開発していたのですが、人材プラットフォームの CTO である稲本が中学の同級生で、彼の記事を読んだのがきっかけでメドレーに入社しました。入社してからは CLINICS カルテや iOS アプリの開発などをやっていました。その後は前田と同じで Pharms の開発をしてから、現在は Dentis を開発しています。他には電子処方箋の実証事業の開発などもしていたりしました。現在は Web のフロントエンド中心に開発をしています。 大岡さん 宮内 : 元同僚が働いていたので、メドレーにリファラルで入社しました。CLINICS オンライン診療の立ち上げをやった後は他の 2 人と同じで Pharms の開発をして、現在は Dentis の開発という感じです。今は主にサーバサイドの開発を中心に業務をしています。 Dentis について Dentis 誕生まで 新居 : ありがとうございました。では、Dentis についてお聞きしたいのですが、どんなきっかけで作られたサービスなんですか? 前田 : 当初は、CLINICS カルテをベースとした歯科医院向けの予約システムを開発していたのですが、歯科レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）のソースコードを 取得 するタイミングも重なり、予約システムだけではなく、レセコン一体型のシステムとして、本格的に開発をスタートしました。 詳しくは こちらの記事 を参照ください。 新居 : なるほど。そんな形で開発が始まった Dentis ですが、コロナ禍で途中で 作り直していますよね 。再開してからは 1 から開発したんですか? 前田 : はい、CLINICS をベースに開発していたものの、歯科医院へのヒアリングなどを実施、調査をしていくうちに医科と歯科では業務オペレーションが異なり予約システムとしては不十分な機能だったことが判明して。特に予約部分などはコンセプトから考え直して UI を一から作り直しました。 宮内 : 途中で Pharms を開発してリリースしたことにより、そこで使った設計や技術などを応用できたというプラスの側面もあり、再度作り直しています。 Next.js を導入したりなどですね。 大岡 : 以前の Dentis はパイロット版として提供をしていたこともあり、しっかり作り変える後押しになったかもしれないです。 新居 : そうすると開発自体も以前よりも、やりやすくもなったんですね。スムーズに開発できるようになったおかげで、 特許 も取得できる UI ができたわけですね。 Dentis のアーキテクチャについて 新居 : 現在の Dentis のアーキテクチャはどんなものになっているんでしょう。 宮内 : サーバサイドは Rails アプリケーションになっています。そこにプラスして GraphQL を使用しています。フロントエンドは Next.js と Apollo を使って GraphQL にアクセスするという形で全て AWS 上に乗っているという感じですね。 新居 : オーソドックスな構成になっているんですね。何か使いづらいなどはないですか? 大岡 : 使いづらいということはないんですが、フロントエンド側でデータをオーバフェッチしている所があるんで、そこは見直さないといけないと思っているところです。 新居 : フロントエンドの状態管理はどのようにしているんですか? 大岡 : Recoil を使っています。ですが、ライブラリの持続可能性を考えて別の方法に移行したほうがよいなとは考えているところですね…。 サブカルテ機能の開発 サブカルテ機能とは 新居 : では今回のメインの話である サブカルテ 機能について、お話を伺えればと思いますが、そもそもサブカルテとはどんなものなんでしょうか。 前田 : 歯科特有の機能になると思うのですが、カルテに記録しない患者に関する情報、たとえばレントゲンや口腔写真などのファイル管理や文書管理などをデジタル化する機能です。デジタルで管理することで、写真やファイルを保管する場所を確保する必要がなくなり、院内空間を有効活用することもできますよね。また、Dentis にあって他社にない機能としては「アクティビティ」でしょうか。院内のスタッフ間で情報共有ができる機能で、Dentis を活用いただいている歯科医院から好評をいただいている機能のひとつです。 普通は院内でスタッフの情報共有をする場合は、紙カルテなどに直接書き込みするのですが、Slack のようなタイムライン形式で情報共有できリアクションなども取れるようにしているのが「アクティビティ」機能になります。 宮内 : 歯科医院は歯科医師以外にも、歯科衛生士や歯科助手など多数の人達が連携して治療にあたるチーム医療をしているので、このような使い方をしているようです。またサブカルテの内容としては医院独自になっているようなので、Dentis のサブカルテは様々な使い方をリサーチして一般的に使いやすいであろうという形にしています。 新居 : アクティビティなどは、今の形に落ち着くまで機能を考えるのは大変そうですね。 前田 : はい、最初は Markdown を書いていけるような Wiki のような形も考えていたりしたので、タイムライン形式に落ち着くまでは試行錯誤しました。医院のコミュニケーションの仕方によって使用率も違いますが、結構使ってくださっていますね。 大岡 : 画像ファイルにメモなどを残している医院などもあるようで、ワークフローによって使いやすい方を選んでいるようです。 前田 : Dentis は医院のペーパーレス化を促進するプロダクトなので、使い方としては様々ですが紙でのワークフローの感覚でそのまま、もっと便利に使えるという部分を重視しています。 サブカルテ機能の開発背景 新居 : そんなサブカルテ機能ですが、開発しようとなった背景としてはどんなものがあったんでしょうか。 前田 : Dentis では「シームレスにつながる」というのをひとつのコンセプトとして設計しているのですが、予約〜カルテ〜会計まで機能的につなげても、業務フローとしてはどうしても隙間が生じていて、シームレスにつながってない事に気づいたんですよね。院内スタッフ間でのちょっとしたコミュニケーションもデジタルで管理できれば、その隙間を埋め、歯科医院の DX 化を推進できるのではないかと思い、サブカルテの開発を始めました。先程も言ったように、ペーパーレス化を促進という目的にも合致していましたしね。 技術的に難しかった部分 新居 : 技術的に困難なところなどはありましたか? 大岡 : 手書きメモと組写真機能(撮影した口腔内の画像を 5 枚や 10 枚で組み合わせて表示する歯科の画像表示形式)を Chrome と iPad / Mac Safari に対応させるのは難しかったかもしれません。 どれかに対応させると、どれかが上手く表示できないなどがあったので。 宮内 : 画像の表示ライブラリを途中で変更したりしましたよね。 大岡 : 最初は Konva というライブラリだったんですが、ゆっくりペンを動かすと、滑らかな線が書けないという問題が発生しまして…。 Fabric.js を使うように変更しました。 サブカルテ機能を作ったことによるプロダクトへの良い効果 新居 : ありがとうございます。サブカルテ機能は今の形になるまで、どのような検討をしたんでしょうか。 前田 : 元々ファイル管理機能などは既に Dentis であった機能だったんです。そこは活かしつつも、求められる他の機能は何かというところを考えていきながら、様々なサブカルテの活用事例もリサーチしながら、今の形に落ち着いたという感じです。 大岡 : 副産物としては今まで Dentis にはなかった「患者詳細」という画面をこのサブカルテ機能を入れるために拡張していったので、その後のオンライン資格確認などへ展開しやすいという状態になりました。情報設計を見直せたおかげです。 前田 : サブカルテ起点で患者検索もさらに詳細にできたりしたので、そうした副産物も大変良かったです。 サブカルテ機能追加による反響 新居 : 医院からはサブカルテの追加により何か反響はあったんでしょうか。 前田 : ネガティブな意見はあまりないですし、むしろ「追加機能としてこういうのが欲しい」というご意見をいただくので、結構使っていただけていると思います。 宮内 : ちょっと興味深かったのが、承認ボタンが欲しいというご意見がありました。医院のワークフローとして、医師以外の方が行なおうとする処置などを「アクティビティ」上で医師に承認してもらうというフローのようです。すぐに導入できるかというとちょっと分からないのですが。 Dentis チームにマッチするメンバー 新居 : ありがとうございます。最後にそんな Dentis チームで一緒に働いてみたいと思うような方はどんな人でしょうか。 前田 : 高齢化が進んでおり、そろそろ若い人に来てほしいですね（笑） 宮内 : どの領域の開発メンバーでも現在は少人数で運営しているので、入ってほしいなとは思います…。一番欲しいというメンバーでいうと「歯科レセコンに精通した開発者」の方ですかね。 新居 : なかなかハードルが高そうな経験ですね（笑） 本日はありがとうございました! さいごに Dentis のサブカルテ機能の開発について、開発者に聞いてみました。歯科には歯科独自のワークフローがあり、紙の運用が重視されてきた風潮の中で、業務オペレーションをふまえて開発していくユーザーファーストな開発者の発想やそれを実現する技術アプローチなど、とても面白い開発をしているなと話を聞いていて思いました。 Dentis の開発チームはベテラン揃いなので、彼らと肩を並べて働くことで、自身の成長を加速させる絶好の機会になると思います。 Dentis の開発に興味を持った方はぜひご連絡お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。今回は今年の 3 月にリリースされた Dentis のサブカルテ機能について、開発したメンバーに話を聞いてみました! 対談メンバー紹介 Dentis 開発メンバーの紹介 新居 : よろしくお願いします。早速ですが、メドレーに入社するまでや、入ってからどんな事をしていたのかを話してもらえればと思います。 前田 : CLINICS のリリース前から、ロゴデザインや UI デザインに携わったのがきっかけでメドレーに入社しました。入社してからは、CLINICS アプリや CLINICS カルテ、薬局向けシステム Pharms などのプロダクトをこのメンバーと一緒に開発していました。今は歯科医院向けの Dentis のデザインや企画、プロモーションなどに関わっています。 前田さん 大岡 : ソーシャルゲームを 6~7 年開発していたのですが、人材プラットフォームの CTO である稲本が中学の同級生で、彼の記事を読んだのがきっかけでメドレーに入社しました。入社してからは CLINICS カルテや iOS アプリの開発などをやっていました。その後は前田と同じで Pharms の開発をしてから、現在は Dentis を開発しています。他には電子処方箋の実証事業の開発などもしていたりしました。現在は Web のフロントエンド中心に開発をしています。 大岡さん 宮内 : 元同僚が働いていたので、メドレーにリファラルで入社しました。CLINICS オンライン診療の立ち上げをやった後は他の 2 人と同じで Pharms の開発をして、現在は Dentis の開発という感じです。今は主にサーバサイドの開発を中心に業務をしています。 Dentis について Dentis 誕生まで 新居 : ありがとうございました。では、Dentis についてお聞きしたいのですが、どんなきっかけで作られたサービスなんですか? 前田 : 当初は、CLINICS カルテをベースとした歯科医院向けの予約システムを開発していたのですが、歯科レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）のソースコードを 取得 するタイミングも重なり、予約システムだけではなく、レセコン一体型のシステムとして、本格的に開発をスタートしました。 詳しくは こちらの記事 を参照ください。 新居 : なるほど。そんな形で開発が始まった Dentis ですが、コロナ禍で途中で 作り直していますよね 。再開してからは 1 から開発したんですか? 前田 : はい、CLINICS をベースに開発していたものの、歯科医院へのヒアリングなどを実施、調査をしていくうちに医科と歯科では業務オペレーションが異なり予約システムとしては不十分な機能だったことが判明して。特に予約部分などはコンセプトから考え直して UI を一から作り直しました。 宮内 : 途中で Pharms を開発してリリースしたことにより、そこで使った設計や技術などを応用できたというプラスの側面もあり、再度作り直しています。 Next.js を導入したりなどですね。 大岡 : 以前の Dentis はパイロット版として提供をしていたこともあり、しっかり作り変える後押しになったかもしれないです。 新居 : そうすると開発自体も以前よりも、やりやすくもなったんですね。スムーズに開発できるようになったおかげで、 特許 も取得できる UI ができたわけですね。 Dentis のアーキテクチャについて 新居 : 現在の Dentis のアーキテクチャはどんなものになっているんでしょう。 宮内 : サーバサイドは Rails アプリケーションになっています。そこにプラスして GraphQL を使用しています。フロントエンドは Next.js と Apollo を使って GraphQL にアクセスするという形で全て AWS 上に乗っているという感じですね。 新居 : オーソドックスな構成になっているんですね。何か使いづらいなどはないですか? 大岡 : 使いづらいということはないんですが、フロントエンド側でデータをオーバフェッチしている所があるんで、そこは見直さないといけないと思っているところです。 新居 : フロントエンドの状態管理はどのようにしているんですか? 大岡 : Recoil を使っています。ですが、ライブラリの持続可能性を考えて別の方法に移行したほうがよいなとは考えているところですね…。 サブカルテ機能の開発 サブカルテ機能とは 新居 : では今回のメインの話である サブカルテ 機能について、お話を伺えればと思いますが、そもそもサブカルテとはどんなものなんでしょうか。 前田 : 歯科特有の機能になると思うのですが、カルテに記録しない患者に関する情報、たとえばレントゲンや口腔写真などのファイル管理や文書管理などをデジタル化する機能です。デジタルで管理することで、写真やファイルを保管する場所を確保する必要がなくなり、院内空間を有効活用することもできますよね。また、Dentis にあって他社にない機能としては「アクティビティ」でしょうか。院内のスタッフ間で情報共有ができる機能で、Dentis を活用いただいている歯科医院から好評をいただいている機能のひとつです。 普通は院内でスタッフの情報共有をする場合は、紙カルテなどに直接書き込みするのですが、Slack のようなタイムライン形式で情報共有できリアクションなども取れるようにしているのが「アクティビティ」機能になります。 宮内 : 歯科医院は歯科医師以外にも、歯科衛生士や歯科助手など多数の人達が連携して治療にあたるチーム医療をしているので、このような使い方をしているようです。またサブカルテの内容としては医院独自になっているようなので、Dentis のサブカルテは様々な使い方をリサーチして一般的に使いやすいであろうという形にしています。 新居 : アクティビティなどは、今の形に落ち着くまで機能を考えるのは大変そうですね。 前田 : はい、最初は Markdown を書いていけるような Wiki のような形も考えていたりしたので、タイムライン形式に落ち着くまでは試行錯誤しました。医院のコミュニケーションの仕方によって使用率も違いますが、結構使ってくださっていますね。 大岡 : 画像ファイルにメモなどを残している医院などもあるようで、ワークフローによって使いやすい方を選んでいるようです。 前田 : Dentis は医院のペーパーレス化を促進するプロダクトなので、使い方としては様々ですが紙でのワークフローの感覚でそのまま、もっと便利に使えるという部分を重視しています。 サブカルテ機能の開発背景 新居 : そんなサブカルテ機能ですが、開発しようとなった背景としてはどんなものがあったんでしょうか。 前田 : Dentis では「シームレスにつながる」というのをひとつのコンセプトとして設計しているのですが、予約〜カルテ〜会計まで機能的につなげても、業務フローとしてはどうしても隙間が生じていて、シームレスにつながってない事に気づいたんですよね。院内スタッフ間でのちょっとしたコミュニケーションもデジタルで管理できれば、その隙間を埋め、歯科医院の DX 化を推進できるのではないかと思い、サブカルテの開発を始めました。先程も言ったように、ペーパーレス化を促進という目的にも合致していましたしね。 技術的に難しかった部分 新居 : 技術的に困難なところなどはありましたか? 大岡 : 手書きメモと組写真機能(撮影した口腔内の画像を 5 枚や 10 枚で組み合わせて表示する歯科の画像表示形式)を Chrome と iPad / Mac Safari に対応させるのは難しかったかもしれません。 どれかに対応させると、どれかが上手く表示できないなどがあったので。 宮内 : 画像の表示ライブラリを途中で変更したりしましたよね。 大岡 : 最初は Konva というライブラリだったんですが、ゆっくりペンを動かすと、滑らかな線が書けないという問題が発生しまして…。 Fabric.js を使うように変更しました。 サブカルテ機能を作ったことによるプロダクトへの良い効果 新居 : ありがとうございます。サブカルテ機能は今の形になるまで、どのような検討をしたんでしょうか。 前田 : 元々ファイル管理機能などは既に Dentis であった機能だったんです。そこは活かしつつも、求められる他の機能は何かというところを考えていきながら、様々なサブカルテの活用事例もリサーチしながら、今の形に落ち着いたという感じです。 大岡 : 副産物としては今まで Dentis にはなかった「患者詳細」という画面をこのサブカルテ機能を入れるために拡張していったので、その後のオンライン資格確認などへ展開しやすいという状態になりました。情報設計を見直せたおかげです。 前田 : サブカルテ起点で患者検索もさらに詳細にできたりしたので、そうした副産物も大変良かったです。 サブカルテ機能追加による反響 新居 : 医院からはサブカルテの追加により何か反響はあったんでしょうか。 前田 : ネガティブな意見はあまりないですし、むしろ「追加機能としてこういうのが欲しい」というご意見をいただくので、結構使っていただけていると思います。 宮内 : ちょっと興味深かったのが、承認ボタンが欲しいというご意見がありました。医院のワークフローとして、医師以外の方が行なおうとする処置などを「アクティビティ」上で医師に承認してもらうというフローのようです。すぐに導入できるかというとちょっと分からないのですが。 Dentis チームにマッチするメンバー 新居 : ありがとうございます。最後にそんな Dentis チームで一緒に働いてみたいと思うような方はどんな人でしょうか。 前田 : 高齢化が進んでおり、そろそろ若い人に来てほしいですね（笑） 宮内 : どの領域の開発メンバーでも現在は少人数で運営しているので、入ってほしいなとは思います…。一番欲しいというメンバーでいうと「歯科レセコンに精通した開発者」の方ですかね。 新居 : なかなかハードルが高そうな経験ですね（笑） 本日はありがとうございました! さいごに Dentis のサブカルテ機能の開発について、開発者に聞いてみました。歯科には歯科独自のワークフローがあり、紙の運用が重視されてきた風潮の中で、業務オペレーションをふまえて開発していくユーザーファーストな開発者の発想やそれを実現する技術アプローチなど、とても面白い開発をしているなと話を聞いていて思いました。 Dentis の開発チームはベテラン揃いなので、彼らと肩を並べて働くことで、自身の成長を加速させる絶好の機会になると思います。 Dentis の開発に興味を持った方はぜひご連絡お待ちしております。 https://www.medley.jp/jobs/

はじめに みなさん、こんにちは。エンジニアの新居です。今回は今年の 3 月にリリースされた Dentis のサブカルテ機能について、開発したメンバーに話を聞いてみました! 対談メンバー紹介 Dentis 開発メンバーの紹介 新居 : よろしくお願いします。早速ですが、メドレーに入社するまでや、入ってからどんな事をしていたのかを話してもらえればと思います。 前田 : CLINICS のリリース前から、ロゴデザインや UI デザインに携わったのがきっかけでメドレーに入社しました。入社してからは、CLINICS アプリや CLINICS カルテ、薬局向けシステム Pharms などのプロダクトをこのメンバーと一緒に開発していました。今は歯科医院向けの Dentis のデザインや企画、プロモーションなどに関わっています。 前田さん 大岡 : ソーシャルゲームを 6~7 年開発していたのですが、人材プラットフォームの CTO である稲本が中学の同級生で、彼の記事を読んだのがきっかけでメドレーに入社しました。入社してからは CLINICS カルテや iOS アプリの開発などをやっていました。その後は前田と同じで Pharms の開発をしてから、現在は Dentis を開発しています。他には電子処方箋の実証事業の開発などもしていたりしました。現在は Web のフロントエンド中心に開発をしています。 大岡さん 宮内 : 元同僚が働いていたので、メドレーにリファラルで入社しました。CLINICS オンライン診療の立ち上げをやった後は他の 2 人と同じで Pharms の開発をして、現在は Dentis の開発という感じです。今は主にサーバサイドの開発を中心に業務をしています。 Dentis について Dentis 誕生まで 新居 : ありがとうございました。では、Dentis についてお聞きしたいのですが、どんなきっかけで作られたサービスなんですか? 前田 : 当初は、CLINICS カルテをベースとした歯科医院向けの予約システムを開発していたのですが、歯科レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）のソースコードを 取得 するタイミングも重なり、予約システムだけではなく、レセコン一体型のシステムとして、本格的に開発をスタートしました。 詳しくは こちらの記事 を参照ください。 新居 : なるほど。そんな形で開発が始まった Dentis ですが、コロナ禍で途中で 作り直していますよね 。再開してからは 1 から開発したんですか? 前田 : はい、CLINICS をベースに開発していたものの、歯科医院へのヒアリングなどを実施、調査をしていくうちに医科と歯科では業務オペレーションが異なり予約システムとしては不十分な機能だったことが判明して。特に予約部分などはコンセプトから考え直して UI を一から作り直しました。 宮内 : 途中で Pharms を開発してリリースしたことにより、そこで使った設計や技術などを応用できたというプラスの側面もあり、再度作り直しています。 Next.js を導入したりなどですね。 大岡 : 以前の Dentis はパイロット版として提供をしていたこともあり、しっかり作り変える後押しになったかもしれないです。 新居 : そうすると開発自体も以前よりも、やりやすくもなったんですね。スムーズに開発できるようになったおかげで、 特許 も取得できる UI ができたわけですね。 Dentis のアーキテクチャについて 新居 : 現在の Dentis のアーキテクチャはどんなものになっているんでしょう。 宮内 : サーバサイドは Rails アプリケーションになっています。そこにプラスして GraphQL を使用しています。フロントエンドは Next.js と Apollo を使って GraphQL にアクセスするという形で全て AWS 上に乗っているという感じですね。 新居 : オーソドックスな構成になっているんですね。何か使いづらいなどはないですか? 大岡 : 使いづらいということはないんですが、フロントエンド側でデータをオーバフェッチしている所があるんで、そこは見直さないといけないと思っているところです。 新居 : フロントエンドの状態管理はどのようにしているんですか? 大岡 : Recoil を使っています。ですが、ライブラリの持続可能性を考えて別の方法に移行したほうがよいなとは考えているところですね…。 サブカルテ機能の開発 サブカルテ機能とは 新居 : では今回のメインの話である サブカルテ 機能について、お話を伺えればと思いますが、そもそもサブカルテとはどんなものなんでしょうか。 前田 : 歯科特有の機能になると思うのですが、カルテに記録しない患者に関する情報、たとえばレントゲンや口腔写真などのファイル管理や文書管理などをデジタル化する機能です。デジタルで管理することで、写真やファイルを保管する場所を確保する必要がなくなり、院内空間を有効活用することもできますよね。また、Dentis にあって他社にない機能としては「アクティビティ」でしょうか。院内のスタッフ間で情報共有ができる機能で、Dentis を活用いただいている歯科医院から好評をいただいている機能のひとつです。 普通は院内でスタッフの情報共有をする場合は、紙カルテなどに直接書き込みするのですが、Slack のようなタイムライン形式で情報共有できリアクションなども取れるようにしているのが「アクティビティ」機能になります。 宮内 : 歯科医院は歯科医師以外にも、歯科衛生士や歯科助手など多数の人達が連携して治療にあたるチーム医療をしているので、このような使い方をしているようです。またサブカルテの内容としては医院独自になっているようなので、Dentis のサブカルテは様々な使い方をリサーチして一般的に使いやすいであろうという形にしています。 新居 : アクティビティなどは、今の形に落ち着くまで機能を考えるのは大変そうですね。 前田 : はい、最初は Markdown を書いていけるような Wiki のような形も考えていたりしたので、タイムライン形式に落ち着くまでは試行錯誤しました。医院のコミュニケーションの仕方によって使用率も違いますが、結構使ってくださっていますね。 大岡 : 画像ファイルにメモなどを残している医院などもあるようで、ワークフローによって使いやすい方を選んでいるようです。 前田 : Dentis は医院のペーパーレス化を促進するプロダクトなので、使い方としては様々ですが紙でのワークフローの感覚でそのまま、もっと便利に使えるという部分を重視しています。 サブカルテ機能の開発背景 新居 : そんなサブカルテ機能ですが、開発しようとなった背景としてはどんなものがあったんでしょうか。 前田 : Dentis では「シームレスにつながる」というのをひとつのコンセプトとして設計しているのですが、予約〜カルテ〜会計まで機能的につなげても、業務フローとしてはどうしても隙間が生じていて、シームレスにつながってない事に気づいたんですよね。院内スタッフ間でのちょっとしたコミュニケーションもデジタルで管理できれば、その隙間を埋め、歯科医院の DX 化を推進できるのではないかと思い、サブカルテの開発を始めました。先程も言ったように、ペーパーレス化を促進という目的にも合致していましたしね。 技術的に難しかった部分 新居 : 技術的に困難なところなどはありましたか? 大岡 : 手書きメモと組写真機能(撮影した口腔内の画像を 5 枚や 10 枚で組み合わせて表示する歯科の画像表示形式)を Chrome と iPad / Mac Safari に対応させるのは難しかったかもしれません。 どれかに対応させると、どれかが上手く表示できないなどがあったので。 宮内 : 画像の表示ライブラリを途中で変更したりしましたよね。 大岡 : 最初は Konva というライブラリだったんですが、ゆっくりペンを動かすと、滑らかな線が書けないという問題が発生しまして…。 Fabric.js を使うように変更しました。 サブカルテ機能を作ったことによるプロダクトへの良い効果 新居 : ありがとうございます。サブカルテ機能は今の形になるまで、どのような検討をしたんでしょうか。 前田 : 元々ファイル管理機能などは既に Dentis であった機能だったんです。そこは活かしつつも、求められる他の機能は何かというところを考えていきながら、様々なサブカルテの活用事例もリサーチしながら、今の形に落ち着いたという感じです。 大岡 : 副産物としては今まで Dentis にはなかった「患者詳細」という画面をこのサブカルテ機能を入れるために拡張していったので、その後のオンライン資格確認などへ展開しやすいという状態になりました。情報設計を見直せたおかげです。 前田 : サブカルテ起点で患者検索もさらに詳細にできたりしたので、そうした副産物も大変良かったです。 サブカルテ機能追加による反響 新居 : 医院からはサブカルテの追加により何か反響はあったんでしょうか。 前田 : ネガティブな意見はあまりないですし、むしろ「追加機能としてこういうのが欲しい」というご意見をいただくので、結構使っていただけていると思います。 宮内 : ちょっと興味深かったのが、承認ボタンが欲しいというご意見がありました。医院のワークフローとして、医師以外の方が行なおうとする処置などを「アクティビティ」上で医師に承認してもらうというフローのようです。すぐに導入できるかというとちょっと分からないのですが。 Dentis チームにマッチするメンバー 新居 : ありがとうございます。最後にそんな Dentis チームで一緒に働いてみたいと思うような方はどんな人でしょうか。 前田 : 高齢化が進んでおり、そろそろ若い人に来てほしいですね（笑） 宮内 : どの領域の開発メンバーでも現在は少人数で運営しているので、入ってほしいなとは思います…。一番欲しいというメンバーでいうと「歯科レセコンに精通した開発者」の方ですかね。 新居 : なかなかハードルが高そうな経験ですね（笑） 本日はありがとうございました! さいごに Dentis のサブカルテ機能の開発について、開発者に聞いてみました。歯科には歯科独自のワークフローがあり、紙の運用が重視されてきた風潮の中で、業務オペレーションをふまえて開発していくユーザーファーストな開発者の発想やそれを実現する技術アプローチなど、とても面白い開発をしているなと話を聞いていて思いました。 Dentis の開発チームはベテラン揃いなので、彼らと肩を並べて働くことで、自身の成長を加速させる絶好の機会になると思います。 Dentis の開発に興味を持った方はぜひご連絡お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。今回は今年の 3 月にリリースされた Dentis のサブカルテ機能について、開発したメンバーに話を聞いてみました! 対談メンバー紹介 Dentis 開発メンバーの紹介 新居 : よろしくお願いします。早速ですが、メドレーに入社するまでや、入ってからどんな事をしていたのかを話してもらえればと思います。 前田 : CLINICS のリリース前から、ロゴデザインや UI デザインに携わったのがきっかけでメドレーに入社しました。入社してからは、CLINICS アプリや CLINICS カルテ、薬局向けシステム Pharms などのプロダクトをこのメンバーと一緒に開発していました。今は歯科医院向けの Dentis のデザインや企画、プロモーションなどに関わっています。 前田さん 大岡 : ソーシャルゲームを 6~7 年開発していたのですが、人材プラットフォームの CTO である稲本が中学の同級生で、彼の記事を読んだのがきっかけでメドレーに入社しました。入社してからは CLINICS カルテや iOS アプリの開発などをやっていました。その後は前田と同じで Pharms の開発をしてから、現在は Dentis を開発しています。他には電子処方箋の実証事業の開発などもしていたりしました。現在は Web のフロントエンド中心に開発をしています。 大岡さん 宮内 : 元同僚が働いていたので、メドレーにリファラルで入社しました。CLINICS オンライン診療の立ち上げをやった後は他の 2 人と同じで Pharms の開発をして、現在は Dentis の開発という感じです。今は主にサーバサイドの開発を中心に業務をしています。 Dentis について Dentis 誕生まで 新居 : ありがとうございました。では、Dentis についてお聞きしたいのですが、どんなきっかけで作られたサービスなんですか? 前田 : 当初は、CLINICS カルテをベースとした歯科医院向けの予約システムを開発していたのですが、歯科レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）のソースコードを 取得 するタイミングも重なり、予約システムだけではなく、レセコン一体型のシステムとして、本格的に開発をスタートしました。 詳しくは こちらの記事 を参照ください。 新居 : なるほど。そんな形で開発が始まった Dentis ですが、コロナ禍で途中で 作り直していますよね 。再開してからは 1 から開発したんですか? 前田 : はい、CLINICS をベースに開発していたものの、歯科医院へのヒアリングなどを実施、調査をしていくうちに医科と歯科では業務オペレーションが異なり予約システムとしては不十分な機能だったことが判明して。特に予約部分などはコンセプトから考え直して UI を一から作り直しました。 宮内 : 途中で Pharms を開発してリリースしたことにより、そこで使った設計や技術などを応用できたというプラスの側面もあり、再度作り直しています。 Next.js を導入したりなどですね。 大岡 : 以前の Dentis はパイロット版として提供をしていたこともあり、しっかり作り変える後押しになったかもしれないです。 新居 : そうすると開発自体も以前よりも、やりやすくもなったんですね。スムーズに開発できるようになったおかげで、 特許 も取得できる UI ができたわけですね。 Dentis のアーキテクチャについて 新居 : 現在の Dentis のアーキテクチャはどんなものになっているんでしょう。 宮内 : サーバサイドは Rails アプリケーションになっています。そこにプラスして GraphQL を使用しています。フロントエンドは Next.js と Apollo を使って GraphQL にアクセスするという形で全て AWS 上に乗っているという感じですね。 新居 : オーソドックスな構成になっているんですね。何か使いづらいなどはないですか? 大岡 : 使いづらいということはないんですが、フロントエンド側でデータをオーバフェッチしている所があるんで、そこは見直さないといけないと思っているところです。 新居 : フロントエンドの状態管理はどのようにしているんですか? 大岡 : Recoil を使っています。ですが、ライブラリの持続可能性を考えて別の方法に移行したほうがよいなとは考えているところですね…。 サブカルテ機能の開発 サブカルテ機能とは 新居 : では今回のメインの話である サブカルテ 機能について、お話を伺えればと思いますが、そもそもサブカルテとはどんなものなんでしょうか。 前田 : 歯科特有の機能になると思うのですが、カルテに記録しない患者に関する情報、たとえばレントゲンや口腔写真などのファイル管理や文書管理などをデジタル化する機能です。デジタルで管理することで、写真やファイルを保管する場所を確保する必要がなくなり、院内空間を有効活用することもできますよね。また、Dentis にあって他社にない機能としては「アクティビティ」でしょうか。院内のスタッフ間で情報共有ができる機能で、Dentis を活用いただいている歯科医院から好評をいただいている機能のひとつです。 普通は院内でスタッフの情報共有をする場合は、紙カルテなどに直接書き込みするのですが、Slack のようなタイムライン形式で情報共有できリアクションなども取れるようにしているのが「アクティビティ」機能になります。 宮内 : 歯科医院は歯科医師以外にも、歯科衛生士や歯科助手など多数の人達が連携して治療にあたるチーム医療をしているので、このような使い方をしているようです。またサブカルテの内容としては医院独自になっているようなので、Dentis のサブカルテは様々な使い方をリサーチして一般的に使いやすいであろうという形にしています。 新居 : アクティビティなどは、今の形に落ち着くまで機能を考えるのは大変そうですね。 前田 : はい、最初は Markdown を書いていけるような Wiki のような形も考えていたりしたので、タイムライン形式に落ち着くまでは試行錯誤しました。医院のコミュニケーションの仕方によって使用率も違いますが、結構使ってくださっていますね。 大岡 : 画像ファイルにメモなどを残している医院などもあるようで、ワークフローによって使いやすい方を選んでいるようです。 前田 : Dentis は医院のペーパーレス化を促進するプロダクトなので、使い方としては様々ですが紙でのワークフローの感覚でそのまま、もっと便利に使えるという部分を重視しています。 サブカルテ機能の開発背景 新居 : そんなサブカルテ機能ですが、開発しようとなった背景としてはどんなものがあったんでしょうか。 前田 : Dentis では「シームレスにつながる」というのをひとつのコンセプトとして設計しているのですが、予約〜カルテ〜会計まで機能的につなげても、業務フローとしてはどうしても隙間が生じていて、シームレスにつながってない事に気づいたんですよね。院内スタッフ間でのちょっとしたコミュニケーションもデジタルで管理できれば、その隙間を埋め、歯科医院の DX 化を推進できるのではないかと思い、サブカルテの開発を始めました。先程も言ったように、ペーパーレス化を促進という目的にも合致していましたしね。 技術的に難しかった部分 新居 : 技術的に困難なところなどはありましたか? 大岡 : 手書きメモと組写真機能(撮影した口腔内の画像を 5 枚や 10 枚で組み合わせて表示する歯科の画像表示形式)を Chrome と iPad / Mac Safari に対応させるのは難しかったかもしれません。 どれかに対応させると、どれかが上手く表示できないなどがあったので。 宮内 : 画像の表示ライブラリを途中で変更したりしましたよね。 大岡 : 最初は Konva というライブラリだったんですが、ゆっくりペンを動かすと、滑らかな線が書けないという問題が発生しまして…。 Fabric.js を使うように変更しました。 サブカルテ機能を作ったことによるプロダクトへの良い効果 新居 : ありがとうございます。サブカルテ機能は今の形になるまで、どのような検討をしたんでしょうか。 前田 : 元々ファイル管理機能などは既に Dentis であった機能だったんです。そこは活かしつつも、求められる他の機能は何かというところを考えていきながら、様々なサブカルテの活用事例もリサーチしながら、今の形に落ち着いたという感じです。 大岡 : 副産物としては今まで Dentis にはなかった「患者詳細」という画面をこのサブカルテ機能を入れるために拡張していったので、その後のオンライン資格確認などへ展開しやすいという状態になりました。情報設計を見直せたおかげです。 前田 : サブカルテ起点で患者検索もさらに詳細にできたりしたので、そうした副産物も大変良かったです。 サブカルテ機能追加による反響 新居 : 医院からはサブカルテの追加により何か反響はあったんでしょうか。 前田 : ネガティブな意見はあまりないですし、むしろ「追加機能としてこういうのが欲しい」というご意見をいただくので、結構使っていただけていると思います。 宮内 : ちょっと興味深かったのが、承認ボタンが欲しいというご意見がありました。医院のワークフローとして、医師以外の方が行なおうとする処置などを「アクティビティ」上で医師に承認してもらうというフローのようです。すぐに導入できるかというとちょっと分からないのですが。 Dentis チームにマッチするメンバー 新居 : ありがとうございます。最後にそんな Dentis チームで一緒に働いてみたいと思うような方はどんな人でしょうか。 前田 : 高齢化が進んでおり、そろそろ若い人に来てほしいですね（笑） 宮内 : どの領域の開発メンバーでも現在は少人数で運営しているので、入ってほしいなとは思います…。一番欲しいというメンバーでいうと「歯科レセコンに精通した開発者」の方ですかね。 新居 : なかなかハードルが高そうな経験ですね（笑） 本日はありがとうございました! さいごに Dentis のサブカルテ機能の開発について、開発者に聞いてみました。歯科には歯科独自のワークフローがあり、紙の運用が重視されてきた風潮の中で、業務オペレーションをふまえて開発していくユーザーファーストな開発者の発想やそれを実現する技術アプローチなど、とても面白い開発をしているなと話を聞いていて思いました。 Dentis の開発チームはベテラン揃いなので、彼らと肩を並べて働くことで、自身の成長を加速させる絶好の機会になると思います。 Dentis の開発に興味を持った方はぜひご連絡お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。メドレーでは医療プラットフォームで患者が使う「CLINICS」アプリを iOS / Android / Web で開発・運営しています。日々、患者が便利に使えるように改善をしていますが、特徴として エンジニアがプロダクトマネージャー(以下、PdM)と一緒に数値を見ながら、改善を行なっている という点が挙げられます。 今回は「CLINICS」アプリを開発している吉岡さんに、どのような開発フローで改善を行なっているのかをインタビューしてみました。 自己紹介 吉岡さん 医療 PF プロダクト開発室第一開発グループグロースチームにて患者向けアプリ「CLINICS」の開発業務を担当。主に薬局に関する機能開発を行っている。大学の専攻は物理で、大学途中からプログラミングを始めた。その後、 大学 4 年から長期インターンで開発に取り組み、Ruby on Rails や React.js など主に Web 開発を経験したあと 2022 年に新卒でメドレー入社。 吉岡さん メドレーに入社した理由 メドレーに入社するまでの経歴 山田 : よろしくお願いします。早速ですが、学生時代からメドレーに入社するまでの経歴をお話いただけますか? 吉岡 : 学生時代は物理学を専攻していましたが、途中からプログラミングを始めました。そのまま Web 開発をしている企業で長期インターンをして Ruby on Rails(以下、RoR) や React.js を使った開発経験を経てメドレーに入社しました。 山田 : 物理学を専攻していたということですが、授業でプログラミングをしていたんですか? 吉岡 : いえ、コロナ禍に入り、ちょうど予定していたオーロラ観察のためのフィンランド行きが無くなってしまったということがありまして。予定が無くなり 時間ができたので「何か始めてみよう」ということでプログラミングを始めた というのが最初のきっかけでした。プログラミング自体は前から気になっていたので、手を出してみたという次第です。 山田 : そうだったんですね! ではコロナ禍にならずに旅行に行くことになっていたら…。 吉岡 : はい、プログラミングしておらず入社もしていなかったかもしれないです(笑) なぜメドレーに入社しようと思ったのか 山田 : そんな吉岡さんは、どうしてメドレーに入社を決めたんですか? 吉岡 : まず最初にメドレーの「医療ヘルスケアの未来をつくる」という ミッションに共感したというのが大きい要因 です。また プロダクトファーストな考え方をしつつ、プロダクト開発への取り組み方が長期で課題に対してじっくりとアプローチ をするという姿勢がとても良いと感じたのも理由になります。 山田 : 入社前に受けた印象と実際に入社後に感じた印象のギャップなどはありますか? 吉岡 : プロダクト開発に関しては特に感じてはいないです。技術スタックについては入社前には RoR と React.js という Web アプリの技術スタックを自分は持っていたので、入社後もその部分のギャップはないかな?と思って入社したのですが、今の配属は患者アプリということで iOS / Android のネイティブアプリの技術に触ることにもなるので、そこの部分がギャップといえばギャップになります。 山田 : 入社前は Web エンジニアとしてだけ業務すると思っていたけど、入ったらネイティブアプリエンジニアとしての業務もあったという話ですね(笑) 吉岡 : そうなりますね(笑) ただ、 iOS / Android を触っていくうちに新しい技術に対する自分のキャッチアップ力には自信が付きました 。「初見の iOS ・ Android でもキャッチアップして開発できたから、他の未知領域もキャッチアップしていけるだろう」という感覚が強くなりましたね。 取り組んでいる業務について 山田 : それでは吉岡さんは現在のチームでどのような業務を担当しているか、聞かせてください。 吉岡 : はい。自分は患者アプリの開発を担当しています。患者さんの日々の通院や服薬を助けるということを目的として、オンライン診療・薬局への処方箋送付・お薬手帳などがこの患者アプリに含まれている機能になります。チームとしては自分は「グロースチーム」というチームに所属しています。主に既存機能の UI / UX の改善であったり、お薬手帳など患者が日常的にアプリを使ってもらえるような機能開発を担当しています。 チーム構成としてはデザイナー兼 PdM 1 人・ PdM 1 人・エンジニアが自分を含め 3 人という構成になっています。施策の規模によるのですが、小さいものであれば 1 人で iOS / Android / Web の 3 プラットフォームを開発しますし、ある程度の規模の施策であれば、それぞれ 1 プラットフォームずつエンジニアがアサインされて開発するようになっています。PdM の方はそれぞれの施策につき 1 人で担当されていることが多いです。 エンジニアはそれぞれ得意としているプラットフォームが分かれているので、プルリクエストを適宜レビューしてもらったり、不明な部分を質問したりという感じで開発していきます。 チームの定例は、毎日 30 分の夕会があり、そこで困り事があったら相談したり、共有するべき事を話したりという感じでやっています。その他は適宜、施策のキックオフだったり、自分が分からないことがあったりしたら周りに聞いたりということはしています。 お薬手帳改善プロジェクト お薬手帳とは、どんな機能か 山田 : ありがとうございます。では、本題となりますが、吉岡さんは「お薬手帳改善プロジェクト」というプロジェクトのメインのエンジニアとして担当をされていたということで、そちらのお話を聞いていきたいと思います。まず前提として「お薬手帳」の機能はどんなものなんでしょうか。 吉岡 : 皆さんも調剤薬局に行くと「お薬手帳をお持ちですか」と聞かれると思いますが、 その機能をアプリ化して便利 にしたものになります。 例えば、今まで自分が服用してきた薬についての履歴を参照できるようになります。また単に履歴だけではなく、服用した薬の副作用やアレルギー歴なども記録できるので、自分に合わない薬などを避け処方してもらえるようになるものです。この機能は調剤薬局で処方される薬だけではなく、市販薬についても記録できます。 また、患者アプリでのお薬手帳は QR コードで処方された薬を登録できるという機能と、薬の飲み忘れを防ぐため服用時間に通知を端末に送付する「服用アラーム」という機能も存在しています。 山田 : なるほど。では「お薬手帳改善プロジェクト」はどのような事を目的としていたプロジェクトだったんでしょうか。 吉岡 : 全体の目的として**「お薬手帳」機能を日常的に使っていただく患者数を増加させるために、UX の向上**を目指していました。私が担当した施策は、その中でも薬の飲み忘れを防止するための「服用アラーム」は使っていただいている患者の割合が低かったため、こちらの機能をもっと使ってもらうように改善すれば、必然的に日常的に「患者アプリ」を使う患者数も増えるだろうという背景のもと行われました。 既存の「服用アラーム」の課題 山田 : 「服用アラーム」はもともとそれ程には使われていない機能だったんですか? 吉岡 : もちろん使っていただいている患者数としては一定数いらっしゃったんですが、期待しているほどには多くなかったという感じでした。そこで使っていただけていない理由や背景を PdM が事前に分析などした結果として以下のような課題が浮き彫り になってきました。 そもそも「服用アラーム」機能を知らなかった 知っていても「服用アラーム」機能の使い方が分からない 「服用アラーム」機能を設定していても通知が届かない場合があった そこで、これらの課題を整理して以下のような順番で改善を行なっていくことにしました。 服用アラーム設定の UI 改善 服用アラームの通知が届かない問題の解消 お薬登録から服用アラームの登録導線の改善 こうして、課題から実装方針までをまず決めていきました。 服用アラーム設定の UI 改善 山田 : 方針の内、最初の服用アラーム設定の UI 改善はどのように行なっていったんでしょうか。 吉岡 : まず、PdM が主体となりユーザーインタビューを行なった結果や、ユーザーサポートの問い合わせ傾向の分析をした結果、 服用アラーム設定の画面でこちらが意図した通りに使ってもらえていないという事実が分かりました 。UI 上でユーザーに少し混乱を招いてしまっていました。 そこで、その概念や設定フローを整理して UI に反映させて、混乱を少なくするように改善を行ないました。 山田 : ちゃんとこちらの概念が正しく UI に反映するようにしたということですね。 服用アラームの通知が届かない問題の解消 吉岡 : はい。これでまず設定が正しくできないという状態が解消されたので、次のステップに進むことにしました。次は正しく設定しているのにも関わらず、一部のユーザーに通知が設定通りに来ない場合があったのを解消しました。こちらの方で特にエラーなどは検知できなかったので、 PdM と仮説を立てて検証 していきました。 山田 : なるほど。どのような仮説だったんですか? 吉岡 : そもそもユーザーが Push 通知を実はオンにしていないのではないかという仮説です。そこで、仮説検証のためまずデータを取って実際どの位のユーザーが Push 通知をオンにしているかを調査したのですが、予想以上に多くのユーザーが Push 通知をオンにしていませんでした。仮説が正しいものだと証明されたので、 Push 通知の許諾を促すための改善を行ないました 。この施策の結果として 2 倍以上のユーザーが Push 通知をオンにしてくれたので、 「服用アラーム」の通知が届かないという問い合わせが減少 しました。 山田 : かなり効果的な施策になったようですね。工数的にはそこまでかからずに実現できたんですか? 吉岡 : はい、工数はあまりかかってないので、結果を見るとコストパフォーマンスが良い施策になったと思います。 服用アラームの登録導線の改善 吉岡 : ここまでで、下準備が整ったので「服用アラーム」自体を実際にさらにユーザーに使ってもらうための施策として、登録までの導線を改善することにしました。今まではお薬を登録するか、お薬と服用アラームを同時に登録するか選べたのですが、お薬手帳への薬の登録後に「服用アラーム」の設定を促す導線を表示するように改善しました。理由としては、 薬の登録をしてから「服用アラーム」の登録をしたユーザーの割合を調べてみたところ、大多数のユーザーが設定をしていなかったことが分かった からです。 山田 : かなりの方が「服用アラーム」を設定せずにいたのは驚きですね。ユーザーはなぜ設定していなかったんですか? 吉岡 : 改善以前の UI では、薬を登録をするためのボタンがあり、その下に「服用アラーム」設定ボタンが並列で設置されていました。 開発側としては、お薬登録と同時に服用アラームを設定する導線がユーザーには分かりやすいだろうと考えていました。しかし、フタを開けてみると登録数が増えないことになっていました。 良く考えると 当たり前だったんですが、開発側としてみれば「服用アラーム」という名前の機能については自明で「こういう動きをする機能だろう」というのが分かった上で、導線として認識していたんです。しかし、ユーザー側の視点とすると最初にこの画面を見て思うことは「服用アラームってなんなんだろう?」という疑問で、「良く分からないからお薬の登録だけしよう」という心理になってしまっていたようなんです。 登録導線改善前の UI 山田 : 確かに説明がないまま「服用アラーム」と言われると、まずは「何だこれ?」となりそうです。それでは、どんな改善を行なって、この課題に対処したんですか? 吉岡 : 先程もお話した、薬の登録から「服用アラーム」設定までのデータを PdM と一緒に検討した結果、一番多くアラームの設定をしてもらえるパターンとしては薬の登録をしたのと同時に設定しているということが分かりました。 ですので、 導線は今までの「薬の登録」+「服用アラーム」ではなく「薬の登録」→「服用アラームの説明と設定」という形に変更 しました。この改善によって、まずは薬の登録をしたいというニーズを満たし、次に「服用アラーム」とはどんな機能なのかを伝え、最後に「服用アラーム」の設定をしてもらうという、ユーザーにとって自然な流れになるように改善しました。 登録導線改善後の UI 山田 : 説明も入ってちゃんとユーザーに便利な機能だということも分かってもらえるようにしたんですね。こちらの改善施策の効果はどんな感じだったんですか? 吉岡 : こちらの施策は改善の前後で 2 倍近く「服用アラーム」を設定してくれるユーザーが増えました。この改善も効果的なものになったんじゃないかと考えています。 お薬手帳改善プロジェクトで苦労した部分 山田 : お薬手帳改善プロジェクトでは PdM と二人三脚でデータを取りながら、仮説を立てて改善していくプロセスで結果に繋げていると感じたのですが、このプロジェクトで苦労した部分は何かありますか? 吉岡 : 技術的に難易度が高いという改善ではなかったのですが、個人的に苦労した点としては iOS / Android それぞれのプラットフォームで Push 通知に関する仕様が当たり前ですが全然違うので、 詳しいメンバーにアドバイスをもらいながら通知に関してキャッチアップする必要があった点が、大変 ではありました。 山田 : これまであまり Push 通知周りの実装の経験を持っていない中だと、各プラットフォームに合わせて実装するのはちょっと大変ですよね。 吉岡 : もちろん、公式ドキュメントも充実しているので、そうしたものを調べたり、最終レビューとしては各プラットフォームの知見が深いエンジニアに見てもらったりもしたので、キャッチアップもしやすくはありましたけども。 その他に ネイティブアプリの開発で必要な知識などは、当たり前ですが書籍などで勉強 などはした上で、局地的にこうした Push 通知などに取り組んだ感じではあります。 お薬手帳改善プロジェクトで学んだこと・やりがいと思ったところ 山田 : 今回の一連のプロジェクトで吉岡さんが学んだ部分として、どんなものがありましたか? 吉岡 : エンジニアリングというと、一般的な印象として難しい実装をして結果を出すという感じに思いがちですが、今回のプロジェクトの施策のように、そこまで工数をかけない実装であっても、 数字を見つつ仮説をちゃんと立てながら本質的な改善をすると結果にちゃんと結びつく んだということが、実感できたという点は大きいです。 また、今回のプロジェクトの主となる目的としては「服用アラームを使ってくれるユーザーを増やす」というものでしたが、そこに至るまでの 準備をちゃんとしておかないと結局ユーザーにとって真に使いやすいものにならない ので、こうした下準備をして丁寧に改善することの大切さというのが分かりました。 山田 : ちゃんと足場を固めて、長期的な視点も入れて改善をしていくというのは、プロダクトの価値を出す上で大事な事ですよね。それでは今回のプロジェクトでのやりがいに思った部分はどんな部分ですか? 吉岡 : ストアを見るとレビューで星 3 をつけていたユーザーの方が改善後に星 5 のレビューにしてくれているのを見たりすると**「ユーザーのために本当にやって良かったな」**と感じます。レビューだけではなく、数字は継続的に見ているので、その数字が向上しているのを観測できたら同じようにやりがいがあると思いました。 目指すエンジニア像 山田 : ここまで吉岡さんが、関わったプロジェクトについて聞いてきましたが、これからどんなエンジニアになっていきたいかという将来像はどんな風に考えているんでしょうか。 吉岡 : まずは同じチームの中の周りのエンジニアの方達を目標としたいなと思っております。具体的には他のエンジニアの皆さんの 課題解決能力の高さ を身に付けていきたいと思っています。 技術面でもプロダクト面でも、ちゃんと状況を分析して「こうすれば良いんではないか」という提案をさっとされたりしています。またその提案自体も複数出しつつ、それぞれのメリット・デメリットを提示してベストなやり方を選んでいる方ばかりなので、そうした部分を参考にしていきたいですね。 山田 : どのようにそうした能力を高めていこうと考えているんですか? 吉岡 : まずは普通に技術力を高めるというのはやっていかないといけないプロセスだとは思っています。 iOS / Android の開発もそうですし、データ構造などもちゃんと考えて実装が必要になったりする部分もあるので、サーバサイドなどもあるタイミングでちゃんとやっていきたいと考えています。 その上で、周りのエンジニアの方達と同じ考え方や、やり方を参考にしながら自身の課題に対処していく…ということを繰り返し経験していくことかなと考えています。 チームで一緒に働いていきたいエンジニア像 山田 : 最後になりますが、吉岡さんはどんなエンジニアと一緒に働いてみたいと考えていますか? 吉岡 : そうですね…。今のチームだと PdM とエンジニアが二人三脚で開発を進めていくというスタイルとなっていますので、そこで PdM が言うことだけをやるというのではなく、 ちゃんと自身の意見を持ってプロダクトをより良くしていくという意識を持っているエンジニア の方と一緒に働きたいです。 色々な施策をする上で、PdM の方とちゃんと役割分担をしつつも、最終目標としてはプロダクトを良くする。その為に PdM を含めエンジニア以外のカスタマーサポートなど他の職種の方へのリスペクトが欠かせないのではないかと思いますので、そうした事も自然とできる方が良いです。 山田 : とても大事な意識ですね。本日はありがとうございました! 最後に 新卒 2 年目ながらユーザーへの価値提供をするために、一連のプロジェクトをメインに担当している吉岡さん。インタビューをしていてメドレーの他のプロダクトのエンジニアにも通じる考え方で真摯に開発をしている様子が伺えました。 メドレーでは今回のように、データドリブンでユーザーへ価値を提供する開発をしていくネイティブアプリエンジニアも絶賛募集していますので、ご興味がある方はぜひカジュアルにお話からしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。メドレーでは医療プラットフォームで患者が使う「CLINICS」アプリを iOS / Android / Web で開発・運営しています。日々、患者が便利に使えるように改善をしていますが、特徴として エンジニアがプロダクトマネージャー(以下、PdM)と一緒に数値を見ながら、改善を行なっている という点が挙げられます。 今回は「CLINICS」アプリを開発している吉岡さんに、どのような開発フローで改善を行なっているのかをインタビューしてみました。 自己紹介 吉岡さん 医療 PF プロダクト開発室第一開発グループグロースチームにて患者向けアプリ「CLINICS」の開発業務を担当。主に薬局に関する機能開発を行っている。大学の専攻は物理で、大学途中からプログラミングを始めた。その後、 大学 4 年から長期インターンで開発に取り組み、Ruby on Rails や React.js など主に Web 開発を経験したあと 2022 年に新卒でメドレー入社。 吉岡さん メドレーに入社した理由 メドレーに入社するまでの経歴 山田 : よろしくお願いします。早速ですが、学生時代からメドレーに入社するまでの経歴をお話いただけますか? 吉岡 : 学生時代は物理学を専攻していましたが、途中からプログラミングを始めました。そのまま Web 開発をしている企業で長期インターンをして Ruby on Rails(以下、RoR) や React.js を使った開発経験を経てメドレーに入社しました。 山田 : 物理学を専攻していたということですが、授業でプログラミングをしていたんですか? 吉岡 : いえ、コロナ禍に入り、ちょうど予定していたオーロラ観察のためのフィンランド行きが無くなってしまったということがありまして。予定が無くなり 時間ができたので「何か始めてみよう」ということでプログラミングを始めた というのが最初のきっかけでした。プログラミング自体は前から気になっていたので、手を出してみたという次第です。 山田 : そうだったんですね! ではコロナ禍にならずに旅行に行くことになっていたら…。 吉岡 : はい、プログラミングしておらず入社もしていなかったかもしれないです(笑) なぜメドレーに入社しようと思ったのか 山田 : そんな吉岡さんは、どうしてメドレーに入社を決めたんですか? 吉岡 : まず最初にメドレーの「医療ヘルスケアの未来をつくる」という ミッションに共感したというのが大きい要因 です。また プロダクトファーストな考え方をしつつ、プロダクト開発への取り組み方が長期で課題に対してじっくりとアプローチ をするという姿勢がとても良いと感じたのも理由になります。 山田 : 入社前に受けた印象と実際に入社後に感じた印象のギャップなどはありますか? 吉岡 : プロダクト開発に関しては特に感じてはいないです。技術スタックについては入社前には RoR と React.js という Web アプリの技術スタックを自分は持っていたので、入社後もその部分のギャップはないかな?と思って入社したのですが、今の配属は患者アプリということで iOS / Android のネイティブアプリの技術に触ることにもなるので、そこの部分がギャップといえばギャップになります。 山田 : 入社前は Web エンジニアとしてだけ業務すると思っていたけど、入ったらネイティブアプリエンジニアとしての業務もあったという話ですね(笑) 吉岡 : そうなりますね(笑) ただ、 iOS / Android を触っていくうちに新しい技術に対する自分のキャッチアップ力には自信が付きました 。「初見の iOS ・ Android でもキャッチアップして開発できたから、他の未知領域もキャッチアップしていけるだろう」という感覚が強くなりましたね。 取り組んでいる業務について 山田 : それでは吉岡さんは現在のチームでどのような業務を担当しているか、聞かせてください。 吉岡 : はい。自分は患者アプリの開発を担当しています。患者さんの日々の通院や服薬を助けるということを目的として、オンライン診療・薬局への処方箋送付・お薬手帳などがこの患者アプリに含まれている機能になります。チームとしては自分は「グロースチーム」というチームに所属しています。主に既存機能の UI / UX の改善であったり、お薬手帳など患者が日常的にアプリを使ってもらえるような機能開発を担当しています。 チーム構成としてはデザイナー兼 PdM 1 人・ PdM 1 人・エンジニアが自分を含め 3 人という構成になっています。施策の規模によるのですが、小さいものであれば 1 人で iOS / Android / Web の 3 プラットフォームを開発しますし、ある程度の規模の施策であれば、それぞれ 1 プラットフォームずつエンジニアがアサインされて開発するようになっています。PdM の方はそれぞれの施策につき 1 人で担当されていることが多いです。 エンジニアはそれぞれ得意としているプラットフォームが分かれているので、プルリクエストを適宜レビューしてもらったり、不明な部分を質問したりという感じで開発していきます。 チームの定例は、毎日 30 分の夕会があり、そこで困り事があったら相談したり、共有するべき事を話したりという感じでやっています。その他は適宜、施策のキックオフだったり、自分が分からないことがあったりしたら周りに聞いたりということはしています。 お薬手帳改善プロジェクト お薬手帳とは、どんな機能か 山田 : ありがとうございます。では、本題となりますが、吉岡さんは「お薬手帳改善プロジェクト」というプロジェクトのメインのエンジニアとして担当をされていたということで、そちらのお話を聞いていきたいと思います。まず前提として「お薬手帳」の機能はどんなものなんでしょうか。 吉岡 : 皆さんも調剤薬局に行くと「お薬手帳をお持ちですか」と聞かれると思いますが、 その機能をアプリ化して便利 にしたものになります。 例えば、今まで自分が服用してきた薬についての履歴を参照できるようになります。また単に履歴だけではなく、服用した薬の副作用やアレルギー歴なども記録できるので、自分に合わない薬などを避け処方してもらえるようになるものです。この機能は調剤薬局で処方される薬だけではなく、市販薬についても記録できます。 また、患者アプリでのお薬手帳は QR コードで処方された薬を登録できるという機能と、薬の飲み忘れを防ぐため服用時間に通知を端末に送付する「服用アラーム」という機能も存在しています。 山田 : なるほど。では「お薬手帳改善プロジェクト」はどのような事を目的としていたプロジェクトだったんでしょうか。 吉岡 : 全体の目的として**「お薬手帳」機能を日常的に使っていただく患者数を増加させるために、UX の向上**を目指していました。私が担当した施策は、その中でも薬の飲み忘れを防止するための「服用アラーム」は使っていただいている患者の割合が低かったため、こちらの機能をもっと使ってもらうように改善すれば、必然的に日常的に「患者アプリ」を使う患者数も増えるだろうという背景のもと行われました。 既存の「服用アラーム」の課題 山田 : 「服用アラーム」はもともとそれ程には使われていない機能だったんですか? 吉岡 : もちろん使っていただいている患者数としては一定数いらっしゃったんですが、期待しているほどには多くなかったという感じでした。そこで使っていただけていない理由や背景を PdM が事前に分析などした結果として以下のような課題が浮き彫り になってきました。 そもそも「服用アラーム」機能を知らなかった 知っていても「服用アラーム」機能の使い方が分からない 「服用アラーム」機能を設定していても通知が届かない場合があった そこで、これらの課題を整理して以下のような順番で改善を行なっていくことにしました。 服用アラーム設定の UI 改善 服用アラームの通知が届かない問題の解消 お薬登録から服用アラームの登録導線の改善 こうして、課題から実装方針までをまず決めていきました。 服用アラーム設定の UI 改善 山田 : 方針の内、最初の服用アラーム設定の UI 改善はどのように行なっていったんでしょうか。 吉岡 : まず、PdM が主体となりユーザーインタビューを行なった結果や、ユーザーサポートの問い合わせ傾向の分析をした結果、 服用アラーム設定の画面でこちらが意図した通りに使ってもらえていないという事実が分かりました 。UI 上でユーザーに少し混乱を招いてしまっていました。 そこで、その概念や設定フローを整理して UI に反映させて、混乱を少なくするように改善を行ないました。 山田 : ちゃんとこちらの概念が正しく UI に反映するようにしたということですね。 服用アラームの通知が届かない問題の解消 吉岡 : はい。これでまず設定が正しくできないという状態が解消されたので、次のステップに進むことにしました。次は正しく設定しているのにも関わらず、一部のユーザーに通知が設定通りに来ない場合があったのを解消しました。こちらの方で特にエラーなどは検知できなかったので、 PdM と仮説を立てて検証 していきました。 山田 : なるほど。どのような仮説だったんですか? 吉岡 : そもそもユーザーが Push 通知を実はオンにしていないのではないかという仮説です。そこで、仮説検証のためまずデータを取って実際どの位のユーザーが Push 通知をオンにしているかを調査したのですが、予想以上に多くのユーザーが Push 通知をオンにしていませんでした。仮説が正しいものだと証明されたので、 Push 通知の許諾を促すための改善を行ないました 。この施策の結果として 2 倍以上のユーザーが Push 通知をオンにしてくれたので、 「服用アラーム」の通知が届かないという問い合わせが減少 しました。 山田 : かなり効果的な施策になったようですね。工数的にはそこまでかからずに実現できたんですか? 吉岡 : はい、工数はあまりかかってないので、結果を見るとコストパフォーマンスが良い施策になったと思います。 服用アラームの登録導線の改善 吉岡 : ここまでで、下準備が整ったので「服用アラーム」自体を実際にさらにユーザーに使ってもらうための施策として、登録までの導線を改善することにしました。今まではお薬を登録するか、お薬と服用アラームを同時に登録するか選べたのですが、お薬手帳への薬の登録後に「服用アラーム」の設定を促す導線を表示するように改善しました。理由としては、 薬の登録をしてから「服用アラーム」の登録をしたユーザーの割合を調べてみたところ、大多数のユーザーが設定をしていなかったことが分かった からです。 山田 : かなりの方が「服用アラーム」を設定せずにいたのは驚きですね。ユーザーはなぜ設定していなかったんですか? 吉岡 : 改善以前の UI では、薬を登録をするためのボタンがあり、その下に「服用アラーム」設定ボタンが並列で設置されていました。 開発側としては、お薬登録と同時に服用アラームを設定する導線がユーザーには分かりやすいだろうと考えていました。しかし、フタを開けてみると登録数が増えないことになっていました。 良く考えると 当たり前だったんですが、開発側としてみれば「服用アラーム」という名前の機能については自明で「こういう動きをする機能だろう」というのが分かった上で、導線として認識していたんです。しかし、ユーザー側の視点とすると最初にこの画面を見て思うことは「服用アラームってなんなんだろう?」という疑問で、「良く分からないからお薬の登録だけしよう」という心理になってしまっていたようなんです。 登録導線改善前の UI 山田 : 確かに説明がないまま「服用アラーム」と言われると、まずは「何だこれ?」となりそうです。それでは、どんな改善を行なって、この課題に対処したんですか? 吉岡 : 先程もお話した、薬の登録から「服用アラーム」設定までのデータを PdM と一緒に検討した結果、一番多くアラームの設定をしてもらえるパターンとしては薬の登録をしたのと同時に設定しているということが分かりました。 ですので、 導線は今までの「薬の登録」+「服用アラーム」ではなく「薬の登録」→「服用アラームの説明と設定」という形に変更 しました。この改善によって、まずは薬の登録をしたいというニーズを満たし、次に「服用アラーム」とはどんな機能なのかを伝え、最後に「服用アラーム」の設定をしてもらうという、ユーザーにとって自然な流れになるように改善しました。 登録導線改善後の UI 山田 : 説明も入ってちゃんとユーザーに便利な機能だということも分かってもらえるようにしたんですね。こちらの改善施策の効果はどんな感じだったんですか? 吉岡 : こちらの施策は改善の前後で 2 倍近く「服用アラーム」を設定してくれるユーザーが増えました。この改善も効果的なものになったんじゃないかと考えています。 お薬手帳改善プロジェクトで苦労した部分 山田 : お薬手帳改善プロジェクトでは PdM と二人三脚でデータを取りながら、仮説を立てて改善していくプロセスで結果に繋げていると感じたのですが、このプロジェクトで苦労した部分は何かありますか? 吉岡 : 技術的に難易度が高いという改善ではなかったのですが、個人的に苦労した点としては iOS / Android それぞれのプラットフォームで Push 通知に関する仕様が当たり前ですが全然違うので、 詳しいメンバーにアドバイスをもらいながら通知に関してキャッチアップする必要があった点が、大変 ではありました。 山田 : これまであまり Push 通知周りの実装の経験を持っていない中だと、各プラットフォームに合わせて実装するのはちょっと大変ですよね。 吉岡 : もちろん、公式ドキュメントも充実しているので、そうしたものを調べたり、最終レビューとしては各プラットフォームの知見が深いエンジニアに見てもらったりもしたので、キャッチアップもしやすくはありましたけども。 その他に ネイティブアプリの開発で必要な知識などは、当たり前ですが書籍などで勉強 などはした上で、局地的にこうした Push 通知などに取り組んだ感じではあります。 お薬手帳改善プロジェクトで学んだこと・やりがいと思ったところ 山田 : 今回の一連のプロジェクトで吉岡さんが学んだ部分として、どんなものがありましたか? 吉岡 : エンジニアリングというと、一般的な印象として難しい実装をして結果を出すという感じに思いがちですが、今回のプロジェクトの施策のように、そこまで工数をかけない実装であっても、 数字を見つつ仮説をちゃんと立てながら本質的な改善をすると結果にちゃんと結びつく んだということが、実感できたという点は大きいです。 また、今回のプロジェクトの主となる目的としては「服用アラームを使ってくれるユーザーを増やす」というものでしたが、そこに至るまでの 準備をちゃんとしておかないと結局ユーザーにとって真に使いやすいものにならない ので、こうした下準備をして丁寧に改善することの大切さというのが分かりました。 山田 : ちゃんと足場を固めて、長期的な視点も入れて改善をしていくというのは、プロダクトの価値を出す上で大事な事ですよね。それでは今回のプロジェクトでのやりがいに思った部分はどんな部分ですか? 吉岡 : ストアを見るとレビューで星 3 をつけていたユーザーの方が改善後に星 5 のレビューにしてくれているのを見たりすると**「ユーザーのために本当にやって良かったな」**と感じます。レビューだけではなく、数字は継続的に見ているので、その数字が向上しているのを観測できたら同じようにやりがいがあると思いました。 目指すエンジニア像 山田 : ここまで吉岡さんが、関わったプロジェクトについて聞いてきましたが、これからどんなエンジニアになっていきたいかという将来像はどんな風に考えているんでしょうか。 吉岡 : まずは同じチームの中の周りのエンジニアの方達を目標としたいなと思っております。具体的には他のエンジニアの皆さんの 課題解決能力の高さ を身に付けていきたいと思っています。 技術面でもプロダクト面でも、ちゃんと状況を分析して「こうすれば良いんではないか」という提案をさっとされたりしています。またその提案自体も複数出しつつ、それぞれのメリット・デメリットを提示してベストなやり方を選んでいる方ばかりなので、そうした部分を参考にしていきたいですね。 山田 : どのようにそうした能力を高めていこうと考えているんですか? 吉岡 : まずは普通に技術力を高めるというのはやっていかないといけないプロセスだとは思っています。 iOS / Android の開発もそうですし、データ構造などもちゃんと考えて実装が必要になったりする部分もあるので、サーバサイドなどもあるタイミングでちゃんとやっていきたいと考えています。 その上で、周りのエンジニアの方達と同じ考え方や、やり方を参考にしながら自身の課題に対処していく…ということを繰り返し経験していくことかなと考えています。 チームで一緒に働いていきたいエンジニア像 山田 : 最後になりますが、吉岡さんはどんなエンジニアと一緒に働いてみたいと考えていますか? 吉岡 : そうですね…。今のチームだと PdM とエンジニアが二人三脚で開発を進めていくというスタイルとなっていますので、そこで PdM が言うことだけをやるというのではなく、 ちゃんと自身の意見を持ってプロダクトをより良くしていくという意識を持っているエンジニア の方と一緒に働きたいです。 色々な施策をする上で、PdM の方とちゃんと役割分担をしつつも、最終目標としてはプロダクトを良くする。その為に PdM を含めエンジニア以外のカスタマーサポートなど他の職種の方へのリスペクトが欠かせないのではないかと思いますので、そうした事も自然とできる方が良いです。 山田 : とても大事な意識ですね。本日はありがとうございました! 最後に 新卒 2 年目ながらユーザーへの価値提供をするために、一連のプロジェクトをメインに担当している吉岡さん。インタビューをしていてメドレーの他のプロダクトのエンジニアにも通じる考え方で真摯に開発をしている様子が伺えました。 メドレーでは今回のように、データドリブンでユーザーへ価値を提供する開発をしていくネイティブアプリエンジニアも絶賛募集していますので、ご興味がある方はぜひカジュアルにお話からしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。メドレーでは医療プラットフォームで患者が使う「CLINICS」アプリを iOS / Android / Web で開発・運営しています。日々、患者が便利に使えるように改善をしていますが、特徴として エンジニアがプロダクトマネージャー(以下、PdM)と一緒に数値を見ながら、改善を行なっている という点が挙げられます。 今回は「CLINICS」アプリを開発している吉岡さんに、どのような開発フローで改善を行なっているのかをインタビューしてみました。 自己紹介 吉岡さん 医療 PF プロダクト開発室第一開発グループグロースチームにて患者向けアプリ「CLINICS」の開発業務を担当。主に薬局に関する機能開発を行っている。大学の専攻は物理で、大学途中からプログラミングを始めた。その後、 大学 4 年から長期インターンで開発に取り組み、Ruby on Rails や React.js など主に Web 開発を経験したあと 2022 年に新卒でメドレー入社。 吉岡さん メドレーに入社した理由 メドレーに入社するまでの経歴 山田 : よろしくお願いします。早速ですが、学生時代からメドレーに入社するまでの経歴をお話いただけますか? 吉岡 : 学生時代は物理学を専攻していましたが、途中からプログラミングを始めました。そのまま Web 開発をしている企業で長期インターンをして Ruby on Rails(以下、RoR) や React.js を使った開発経験を経てメドレーに入社しました。 山田 : 物理学を専攻していたということですが、授業でプログラミングをしていたんですか? 吉岡 : いえ、コロナ禍に入り、ちょうど予定していたオーロラ観察のためのフィンランド行きが無くなってしまったということがありまして。予定が無くなり 時間ができたので「何か始めてみよう」ということでプログラミングを始めた というのが最初のきっかけでした。プログラミング自体は前から気になっていたので、手を出してみたという次第です。 山田 : そうだったんですね! ではコロナ禍にならずに旅行に行くことになっていたら…。 吉岡 : はい、プログラミングしておらず入社もしていなかったかもしれないです(笑) なぜメドレーに入社しようと思ったのか 山田 : そんな吉岡さんは、どうしてメドレーに入社を決めたんですか? 吉岡 : まず最初にメドレーの「医療ヘルスケアの未来をつくる」という ミッションに共感したというのが大きい要因 です。また プロダクトファーストな考え方をしつつ、プロダクト開発への取り組み方が長期で課題に対してじっくりとアプローチ をするという姿勢がとても良いと感じたのも理由になります。 山田 : 入社前に受けた印象と実際に入社後に感じた印象のギャップなどはありますか? 吉岡 : プロダクト開発に関しては特に感じてはいないです。技術スタックについては入社前には RoR と React.js という Web アプリの技術スタックを自分は持っていたので、入社後もその部分のギャップはないかな?と思って入社したのですが、今の配属は患者アプリということで iOS / Android のネイティブアプリの技術に触ることにもなるので、そこの部分がギャップといえばギャップになります。 山田 : 入社前は Web エンジニアとしてだけ業務すると思っていたけど、入ったらネイティブアプリエンジニアとしての業務もあったという話ですね(笑) 吉岡 : そうなりますね(笑) ただ、 iOS / Android を触っていくうちに新しい技術に対する自分のキャッチアップ力には自信が付きました 。「初見の iOS ・ Android でもキャッチアップして開発できたから、他の未知領域もキャッチアップしていけるだろう」という感覚が強くなりましたね。 取り組んでいる業務について 山田 : それでは吉岡さんは現在のチームでどのような業務を担当しているか、聞かせてください。 吉岡 : はい。自分は患者アプリの開発を担当しています。患者さんの日々の通院や服薬を助けるということを目的として、オンライン診療・薬局への処方箋送付・お薬手帳などがこの患者アプリに含まれている機能になります。チームとしては自分は「グロースチーム」というチームに所属しています。主に既存機能の UI / UX の改善であったり、お薬手帳など患者が日常的にアプリを使ってもらえるような機能開発を担当しています。 チーム構成としてはデザイナー兼 PdM 1 人・ PdM 1 人・エンジニアが自分を含め 3 人という構成になっています。施策の規模によるのですが、小さいものであれば 1 人で iOS / Android / Web の 3 プラットフォームを開発しますし、ある程度の規模の施策であれば、それぞれ 1 プラットフォームずつエンジニアがアサインされて開発するようになっています。PdM の方はそれぞれの施策につき 1 人で担当されていることが多いです。 エンジニアはそれぞれ得意としているプラットフォームが分かれているので、プルリクエストを適宜レビューしてもらったり、不明な部分を質問したりという感じで開発していきます。 チームの定例は、毎日 30 分の夕会があり、そこで困り事があったら相談したり、共有するべき事を話したりという感じでやっています。その他は適宜、施策のキックオフだったり、自分が分からないことがあったりしたら周りに聞いたりということはしています。 お薬手帳改善プロジェクト お薬手帳とは、どんな機能か 山田 : ありがとうございます。では、本題となりますが、吉岡さんは「お薬手帳改善プロジェクト」というプロジェクトのメインのエンジニアとして担当をされていたということで、そちらのお話を聞いていきたいと思います。まず前提として「お薬手帳」の機能はどんなものなんでしょうか。 吉岡 : 皆さんも調剤薬局に行くと「お薬手帳をお持ちですか」と聞かれると思いますが、 その機能をアプリ化して便利 にしたものになります。 例えば、今まで自分が服用してきた薬についての履歴を参照できるようになります。また単に履歴だけではなく、服用した薬の副作用やアレルギー歴なども記録できるので、自分に合わない薬などを避け処方してもらえるようになるものです。この機能は調剤薬局で処方される薬だけではなく、市販薬についても記録できます。 また、患者アプリでのお薬手帳は QR コードで処方された薬を登録できるという機能と、薬の飲み忘れを防ぐため服用時間に通知を端末に送付する「服用アラーム」という機能も存在しています。 山田 : なるほど。では「お薬手帳改善プロジェクト」はどのような事を目的としていたプロジェクトだったんでしょうか。 吉岡 : 全体の目的として**「お薬手帳」機能を日常的に使っていただく患者数を増加させるために、UX の向上**を目指していました。私が担当した施策は、その中でも薬の飲み忘れを防止するための「服用アラーム」は使っていただいている患者の割合が低かったため、こちらの機能をもっと使ってもらうように改善すれば、必然的に日常的に「患者アプリ」を使う患者数も増えるだろうという背景のもと行われました。 既存の「服用アラーム」の課題 山田 : 「服用アラーム」はもともとそれ程には使われていない機能だったんですか? 吉岡 : もちろん使っていただいている患者数としては一定数いらっしゃったんですが、期待しているほどには多くなかったという感じでした。そこで使っていただけていない理由や背景を PdM が事前に分析などした結果として以下のような課題が浮き彫り になってきました。 そもそも「服用アラーム」機能を知らなかった 知っていても「服用アラーム」機能の使い方が分からない 「服用アラーム」機能を設定していても通知が届かない場合があった そこで、これらの課題を整理して以下のような順番で改善を行なっていくことにしました。 服用アラーム設定の UI 改善 服用アラームの通知が届かない問題の解消 お薬登録から服用アラームの登録導線の改善 こうして、課題から実装方針までをまず決めていきました。 服用アラーム設定の UI 改善 山田 : 方針の内、最初の服用アラーム設定の UI 改善はどのように行なっていったんでしょうか。 吉岡 : まず、PdM が主体となりユーザーインタビューを行なった結果や、ユーザーサポートの問い合わせ傾向の分析をした結果、 服用アラーム設定の画面でこちらが意図した通りに使ってもらえていないという事実が分かりました 。UI 上でユーザーに少し混乱を招いてしまっていました。 そこで、その概念や設定フローを整理して UI に反映させて、混乱を少なくするように改善を行ないました。 山田 : ちゃんとこちらの概念が正しく UI に反映するようにしたということですね。 服用アラームの通知が届かない問題の解消 吉岡 : はい。これでまず設定が正しくできないという状態が解消されたので、次のステップに進むことにしました。次は正しく設定しているのにも関わらず、一部のユーザーに通知が設定通りに来ない場合があったのを解消しました。こちらの方で特にエラーなどは検知できなかったので、 PdM と仮説を立てて検証 していきました。 山田 : なるほど。どのような仮説だったんですか? 吉岡 : そもそもユーザーが Push 通知を実はオンにしていないのではないかという仮説です。そこで、仮説検証のためまずデータを取って実際どの位のユーザーが Push 通知をオンにしているかを調査したのですが、予想以上に多くのユーザーが Push 通知をオンにしていませんでした。仮説が正しいものだと証明されたので、 Push 通知の許諾を促すための改善を行ないました 。この施策の結果として 2 倍以上のユーザーが Push 通知をオンにしてくれたので、 「服用アラーム」の通知が届かないという問い合わせが減少 しました。 山田 : かなり効果的な施策になったようですね。工数的にはそこまでかからずに実現できたんですか? 吉岡 : はい、工数はあまりかかってないので、結果を見るとコストパフォーマンスが良い施策になったと思います。 服用アラームの登録導線の改善 吉岡 : ここまでで、下準備が整ったので「服用アラーム」自体を実際にさらにユーザーに使ってもらうための施策として、登録までの導線を改善することにしました。今まではお薬を登録するか、お薬と服用アラームを同時に登録するか選べたのですが、お薬手帳への薬の登録後に「服用アラーム」の設定を促す導線を表示するように改善しました。理由としては、 薬の登録をしてから「服用アラーム」の登録をしたユーザーの割合を調べてみたところ、大多数のユーザーが設定をしていなかったことが分かった からです。 山田 : かなりの方が「服用アラーム」を設定せずにいたのは驚きですね。ユーザーはなぜ設定していなかったんですか? 吉岡 : 改善以前の UI では、薬を登録をするためのボタンがあり、その下に「服用アラーム」設定ボタンが並列で設置されていました。 開発側としては、お薬登録と同時に服用アラームを設定する導線がユーザーには分かりやすいだろうと考えていました。しかし、フタを開けてみると登録数が増えないことになっていました。 良く考えると 当たり前だったんですが、開発側としてみれば「服用アラーム」という名前の機能については自明で「こういう動きをする機能だろう」というのが分かった上で、導線として認識していたんです。しかし、ユーザー側の視点とすると最初にこの画面を見て思うことは「服用アラームってなんなんだろう?」という疑問で、「良く分からないからお薬の登録だけしよう」という心理になってしまっていたようなんです。 登録導線改善前の UI 山田 : 確かに説明がないまま「服用アラーム」と言われると、まずは「何だこれ?」となりそうです。それでは、どんな改善を行なって、この課題に対処したんですか? 吉岡 : 先程もお話した、薬の登録から「服用アラーム」設定までのデータを PdM と一緒に検討した結果、一番多くアラームの設定をしてもらえるパターンとしては薬の登録をしたのと同時に設定しているということが分かりました。 ですので、 導線は今までの「薬の登録」+「服用アラーム」ではなく「薬の登録」→「服用アラームの説明と設定」という形に変更 しました。この改善によって、まずは薬の登録をしたいというニーズを満たし、次に「服用アラーム」とはどんな機能なのかを伝え、最後に「服用アラーム」の設定をしてもらうという、ユーザーにとって自然な流れになるように改善しました。 登録導線改善後の UI 山田 : 説明も入ってちゃんとユーザーに便利な機能だということも分かってもらえるようにしたんですね。こちらの改善施策の効果はどんな感じだったんですか? 吉岡 : こちらの施策は改善の前後で 2 倍近く「服用アラーム」を設定してくれるユーザーが増えました。この改善も効果的なものになったんじゃないかと考えています。 お薬手帳改善プロジェクトで苦労した部分 山田 : お薬手帳改善プロジェクトでは PdM と二人三脚でデータを取りながら、仮説を立てて改善していくプロセスで結果に繋げていると感じたのですが、このプロジェクトで苦労した部分は何かありますか? 吉岡 : 技術的に難易度が高いという改善ではなかったのですが、個人的に苦労した点としては iOS / Android それぞれのプラットフォームで Push 通知に関する仕様が当たり前ですが全然違うので、 詳しいメンバーにアドバイスをもらいながら通知に関してキャッチアップする必要があった点が、大変 ではありました。 山田 : これまであまり Push 通知周りの実装の経験を持っていない中だと、各プラットフォームに合わせて実装するのはちょっと大変ですよね。 吉岡 : もちろん、公式ドキュメントも充実しているので、そうしたものを調べたり、最終レビューとしては各プラットフォームの知見が深いエンジニアに見てもらったりもしたので、キャッチアップもしやすくはありましたけども。 その他に ネイティブアプリの開発で必要な知識などは、当たり前ですが書籍などで勉強 などはした上で、局地的にこうした Push 通知などに取り組んだ感じではあります。 お薬手帳改善プロジェクトで学んだこと・やりがいと思ったところ 山田 : 今回の一連のプロジェクトで吉岡さんが学んだ部分として、どんなものがありましたか? 吉岡 : エンジニアリングというと、一般的な印象として難しい実装をして結果を出すという感じに思いがちですが、今回のプロジェクトの施策のように、そこまで工数をかけない実装であっても、 数字を見つつ仮説をちゃんと立てながら本質的な改善をすると結果にちゃんと結びつく んだということが、実感できたという点は大きいです。 また、今回のプロジェクトの主となる目的としては「服用アラームを使ってくれるユーザーを増やす」というものでしたが、そこに至るまでの 準備をちゃんとしておかないと結局ユーザーにとって真に使いやすいものにならない ので、こうした下準備をして丁寧に改善することの大切さというのが分かりました。 山田 : ちゃんと足場を固めて、長期的な視点も入れて改善をしていくというのは、プロダクトの価値を出す上で大事な事ですよね。それでは今回のプロジェクトでのやりがいに思った部分はどんな部分ですか? 吉岡 : ストアを見るとレビューで星 3 をつけていたユーザーの方が改善後に星 5 のレビューにしてくれているのを見たりすると**「ユーザーのために本当にやって良かったな」**と感じます。レビューだけではなく、数字は継続的に見ているので、その数字が向上しているのを観測できたら同じようにやりがいがあると思いました。 目指すエンジニア像 山田 : ここまで吉岡さんが、関わったプロジェクトについて聞いてきましたが、これからどんなエンジニアになっていきたいかという将来像はどんな風に考えているんでしょうか。 吉岡 : まずは同じチームの中の周りのエンジニアの方達を目標としたいなと思っております。具体的には他のエンジニアの皆さんの 課題解決能力の高さ を身に付けていきたいと思っています。 技術面でもプロダクト面でも、ちゃんと状況を分析して「こうすれば良いんではないか」という提案をさっとされたりしています。またその提案自体も複数出しつつ、それぞれのメリット・デメリットを提示してベストなやり方を選んでいる方ばかりなので、そうした部分を参考にしていきたいですね。 山田 : どのようにそうした能力を高めていこうと考えているんですか? 吉岡 : まずは普通に技術力を高めるというのはやっていかないといけないプロセスだとは思っています。 iOS / Android の開発もそうですし、データ構造などもちゃんと考えて実装が必要になったりする部分もあるので、サーバサイドなどもあるタイミングでちゃんとやっていきたいと考えています。 その上で、周りのエンジニアの方達と同じ考え方や、やり方を参考にしながら自身の課題に対処していく…ということを繰り返し経験していくことかなと考えています。 チームで一緒に働いていきたいエンジニア像 山田 : 最後になりますが、吉岡さんはどんなエンジニアと一緒に働いてみたいと考えていますか? 吉岡 : そうですね…。今のチームだと PdM とエンジニアが二人三脚で開発を進めていくというスタイルとなっていますので、そこで PdM が言うことだけをやるというのではなく、 ちゃんと自身の意見を持ってプロダクトをより良くしていくという意識を持っているエンジニア の方と一緒に働きたいです。 色々な施策をする上で、PdM の方とちゃんと役割分担をしつつも、最終目標としてはプロダクトを良くする。その為に PdM を含めエンジニア以外のカスタマーサポートなど他の職種の方へのリスペクトが欠かせないのではないかと思いますので、そうした事も自然とできる方が良いです。 山田 : とても大事な意識ですね。本日はありがとうございました! 最後に 新卒 2 年目ながらユーザーへの価値提供をするために、一連のプロジェクトをメインに担当している吉岡さん。インタビューをしていてメドレーの他のプロダクトのエンジニアにも通じる考え方で真摯に開発をしている様子が伺えました。 メドレーでは今回のように、データドリブンでユーザーへ価値を提供する開発をしていくネイティブアプリエンジニアも絶賛募集していますので、ご興味がある方はぜひカジュアルにお話からしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。メドレーでは医療プラットフォームで患者が使う「CLINICS」アプリを iOS / Android / Web で開発・運営しています。日々、患者が便利に使えるように改善をしていますが、特徴として エンジニアがプロダクトマネージャー(以下、PdM)と一緒に数値を見ながら、改善を行なっている という点が挙げられます。 今回は「CLINICS」アプリを開発している吉岡さんに、どのような開発フローで改善を行なっているのかをインタビューしてみました。 自己紹介 吉岡さん 医療 PF プロダクト開発室第一開発グループグロースチームにて患者向けアプリ「CLINICS」の開発業務を担当。主に薬局に関する機能開発を行っている。大学の専攻は物理で、大学途中からプログラミングを始めた。その後、 大学 4 年から長期インターンで開発に取り組み、Ruby on Rails や React.js など主に Web 開発を経験したあと 2022 年に新卒でメドレー入社。 吉岡さん メドレーに入社した理由 メドレーに入社するまでの経歴 山田 : よろしくお願いします。早速ですが、学生時代からメドレーに入社するまでの経歴をお話いただけますか? 吉岡 : 学生時代は物理学を専攻していましたが、途中からプログラミングを始めました。そのまま Web 開発をしている企業で長期インターンをして Ruby on Rails(以下、RoR) や React.js を使った開発経験を経てメドレーに入社しました。 山田 : 物理学を専攻していたということですが、授業でプログラミングをしていたんですか? 吉岡 : いえ、コロナ禍に入り、ちょうど予定していたオーロラ観察のためのフィンランド行きが無くなってしまったということがありまして。予定が無くなり 時間ができたので「何か始めてみよう」ということでプログラミングを始めた というのが最初のきっかけでした。プログラミング自体は前から気になっていたので、手を出してみたという次第です。 山田 : そうだったんですね! ではコロナ禍にならずに旅行に行くことになっていたら…。 吉岡 : はい、プログラミングしておらず入社もしていなかったかもしれないです(笑) なぜメドレーに入社しようと思ったのか 山田 : そんな吉岡さんは、どうしてメドレーに入社を決めたんですか? 吉岡 : まず最初にメドレーの「医療ヘルスケアの未来をつくる」という ミッションに共感したというのが大きい要因 です。また プロダクトファーストな考え方をしつつ、プロダクト開発への取り組み方が長期で課題に対してじっくりとアプローチ をするという姿勢がとても良いと感じたのも理由になります。 山田 : 入社前に受けた印象と実際に入社後に感じた印象のギャップなどはありますか? 吉岡 : プロダクト開発に関しては特に感じてはいないです。技術スタックについては入社前には RoR と React.js という Web アプリの技術スタックを自分は持っていたので、入社後もその部分のギャップはないかな?と思って入社したのですが、今の配属は患者アプリということで iOS / Android のネイティブアプリの技術に触ることにもなるので、そこの部分がギャップといえばギャップになります。 山田 : 入社前は Web エンジニアとしてだけ業務すると思っていたけど、入ったらネイティブアプリエンジニアとしての業務もあったという話ですね(笑) 吉岡 : そうなりますね(笑) ただ、 iOS / Android を触っていくうちに新しい技術に対する自分のキャッチアップ力には自信が付きました 。「初見の iOS ・ Android でもキャッチアップして開発できたから、他の未知領域もキャッチアップしていけるだろう」という感覚が強くなりましたね。 取り組んでいる業務について 山田 : それでは吉岡さんは現在のチームでどのような業務を担当しているか、聞かせてください。 吉岡 : はい。自分は患者アプリの開発を担当しています。患者さんの日々の通院や服薬を助けるということを目的として、オンライン診療・薬局への処方箋送付・お薬手帳などがこの患者アプリに含まれている機能になります。チームとしては自分は「グロースチーム」というチームに所属しています。主に既存機能の UI / UX の改善であったり、お薬手帳など患者が日常的にアプリを使ってもらえるような機能開発を担当しています。 チーム構成としてはデザイナー兼 PdM 1 人・ PdM 1 人・エンジニアが自分を含め 3 人という構成になっています。施策の規模によるのですが、小さいものであれば 1 人で iOS / Android / Web の 3 プラットフォームを開発しますし、ある程度の規模の施策であれば、それぞれ 1 プラットフォームずつエンジニアがアサインされて開発するようになっています。PdM の方はそれぞれの施策につき 1 人で担当されていることが多いです。 エンジニアはそれぞれ得意としているプラットフォームが分かれているので、プルリクエストを適宜レビューしてもらったり、不明な部分を質問したりという感じで開発していきます。 チームの定例は、毎日 30 分の夕会があり、そこで困り事があったら相談したり、共有するべき事を話したりという感じでやっています。その他は適宜、施策のキックオフだったり、自分が分からないことがあったりしたら周りに聞いたりということはしています。 お薬手帳改善プロジェクト お薬手帳とは、どんな機能か 山田 : ありがとうございます。では、本題となりますが、吉岡さんは「お薬手帳改善プロジェクト」というプロジェクトのメインのエンジニアとして担当をされていたということで、そちらのお話を聞いていきたいと思います。まず前提として「お薬手帳」の機能はどんなものなんでしょうか。 吉岡 : 皆さんも調剤薬局に行くと「お薬手帳をお持ちですか」と聞かれると思いますが、 その機能をアプリ化して便利 にしたものになります。 例えば、今まで自分が服用してきた薬についての履歴を参照できるようになります。また単に履歴だけではなく、服用した薬の副作用やアレルギー歴なども記録できるので、自分に合わない薬などを避け処方してもらえるようになるものです。この機能は調剤薬局で処方される薬だけではなく、市販薬についても記録できます。 また、患者アプリでのお薬手帳は QR コードで処方された薬を登録できるという機能と、薬の飲み忘れを防ぐため服用時間に通知を端末に送付する「服用アラーム」という機能も存在しています。 山田 : なるほど。では「お薬手帳改善プロジェクト」はどのような事を目的としていたプロジェクトだったんでしょうか。 吉岡 : 全体の目的として**「お薬手帳」機能を日常的に使っていただく患者数を増加させるために、UX の向上**を目指していました。私が担当した施策は、その中でも薬の飲み忘れを防止するための「服用アラーム」は使っていただいている患者の割合が低かったため、こちらの機能をもっと使ってもらうように改善すれば、必然的に日常的に「患者アプリ」を使う患者数も増えるだろうという背景のもと行われました。 既存の「服用アラーム」の課題 山田 : 「服用アラーム」はもともとそれ程には使われていない機能だったんですか? 吉岡 : もちろん使っていただいている患者数としては一定数いらっしゃったんですが、期待しているほどには多くなかったという感じでした。そこで使っていただけていない理由や背景を PdM が事前に分析などした結果として以下のような課題が浮き彫り になってきました。 そもそも「服用アラーム」機能を知らなかった 知っていても「服用アラーム」機能の使い方が分からない 「服用アラーム」機能を設定していても通知が届かない場合があった そこで、これらの課題を整理して以下のような順番で改善を行なっていくことにしました。 服用アラーム設定の UI 改善 服用アラームの通知が届かない問題の解消 お薬登録から服用アラームの登録導線の改善 こうして、課題から実装方針までをまず決めていきました。 服用アラーム設定の UI 改善 山田 : 方針の内、最初の服用アラーム設定の UI 改善はどのように行なっていったんでしょうか。 吉岡 : まず、PdM が主体となりユーザーインタビューを行なった結果や、ユーザーサポートの問い合わせ傾向の分析をした結果、 服用アラーム設定の画面でこちらが意図した通りに使ってもらえていないという事実が分かりました 。UI 上でユーザーに少し混乱を招いてしまっていました。 そこで、その概念や設定フローを整理して UI に反映させて、混乱を少なくするように改善を行ないました。 山田 : ちゃんとこちらの概念が正しく UI に反映するようにしたということですね。 服用アラームの通知が届かない問題の解消 吉岡 : はい。これでまず設定が正しくできないという状態が解消されたので、次のステップに進むことにしました。次は正しく設定しているのにも関わらず、一部のユーザーに通知が設定通りに来ない場合があったのを解消しました。こちらの方で特にエラーなどは検知できなかったので、 PdM と仮説を立てて検証 していきました。 山田 : なるほど。どのような仮説だったんですか? 吉岡 : そもそもユーザーが Push 通知を実はオンにしていないのではないかという仮説です。そこで、仮説検証のためまずデータを取って実際どの位のユーザーが Push 通知をオンにしているかを調査したのですが、予想以上に多くのユーザーが Push 通知をオンにしていませんでした。仮説が正しいものだと証明されたので、 Push 通知の許諾を促すための改善を行ないました 。この施策の結果として 2 倍以上のユーザーが Push 通知をオンにしてくれたので、 「服用アラーム」の通知が届かないという問い合わせが減少 しました。 山田 : かなり効果的な施策になったようですね。工数的にはそこまでかからずに実現できたんですか? 吉岡 : はい、工数はあまりかかってないので、結果を見るとコストパフォーマンスが良い施策になったと思います。 服用アラームの登録導線の改善 吉岡 : ここまでで、下準備が整ったので「服用アラーム」自体を実際にさらにユーザーに使ってもらうための施策として、登録までの導線を改善することにしました。今まではお薬を登録するか、お薬と服用アラームを同時に登録するか選べたのですが、お薬手帳への薬の登録後に「服用アラーム」の設定を促す導線を表示するように改善しました。理由としては、 薬の登録をしてから「服用アラーム」の登録をしたユーザーの割合を調べてみたところ、大多数のユーザーが設定をしていなかったことが分かった からです。 山田 : かなりの方が「服用アラーム」を設定せずにいたのは驚きですね。ユーザーはなぜ設定していなかったんですか? 吉岡 : 改善以前の UI では、薬を登録をするためのボタンがあり、その下に「服用アラーム」設定ボタンが並列で設置されていました。 開発側としては、お薬登録と同時に服用アラームを設定する導線がユーザーには分かりやすいだろうと考えていました。しかし、フタを開けてみると登録数が増えないことになっていました。 良く考えると 当たり前だったんですが、開発側としてみれば「服用アラーム」という名前の機能については自明で「こういう動きをする機能だろう」というのが分かった上で、導線として認識していたんです。しかし、ユーザー側の視点とすると最初にこの画面を見て思うことは「服用アラームってなんなんだろう?」という疑問で、「良く分からないからお薬の登録だけしよう」という心理になってしまっていたようなんです。 登録導線改善前の UI 山田 : 確かに説明がないまま「服用アラーム」と言われると、まずは「何だこれ?」となりそうです。それでは、どんな改善を行なって、この課題に対処したんですか? 吉岡 : 先程もお話した、薬の登録から「服用アラーム」設定までのデータを PdM と一緒に検討した結果、一番多くアラームの設定をしてもらえるパターンとしては薬の登録をしたのと同時に設定しているということが分かりました。 ですので、 導線は今までの「薬の登録」+「服用アラーム」ではなく「薬の登録」→「服用アラームの説明と設定」という形に変更 しました。この改善によって、まずは薬の登録をしたいというニーズを満たし、次に「服用アラーム」とはどんな機能なのかを伝え、最後に「服用アラーム」の設定をしてもらうという、ユーザーにとって自然な流れになるように改善しました。 登録導線改善後の UI 山田 : 説明も入ってちゃんとユーザーに便利な機能だということも分かってもらえるようにしたんですね。こちらの改善施策の効果はどんな感じだったんですか? 吉岡 : こちらの施策は改善の前後で 2 倍近く「服用アラーム」を設定してくれるユーザーが増えました。この改善も効果的なものになったんじゃないかと考えています。 お薬手帳改善プロジェクトで苦労した部分 山田 : お薬手帳改善プロジェクトでは PdM と二人三脚でデータを取りながら、仮説を立てて改善していくプロセスで結果に繋げていると感じたのですが、このプロジェクトで苦労した部分は何かありますか? 吉岡 : 技術的に難易度が高いという改善ではなかったのですが、個人的に苦労した点としては iOS / Android それぞれのプラットフォームで Push 通知に関する仕様が当たり前ですが全然違うので、 詳しいメンバーにアドバイスをもらいながら通知に関してキャッチアップする必要があった点が、大変 ではありました。 山田 : これまであまり Push 通知周りの実装の経験を持っていない中だと、各プラットフォームに合わせて実装するのはちょっと大変ですよね。 吉岡 : もちろん、公式ドキュメントも充実しているので、そうしたものを調べたり、最終レビューとしては各プラットフォームの知見が深いエンジニアに見てもらったりもしたので、キャッチアップもしやすくはありましたけども。 その他に ネイティブアプリの開発で必要な知識などは、当たり前ですが書籍などで勉強 などはした上で、局地的にこうした Push 通知などに取り組んだ感じではあります。 お薬手帳改善プロジェクトで学んだこと・やりがいと思ったところ 山田 : 今回の一連のプロジェクトで吉岡さんが学んだ部分として、どんなものがありましたか? 吉岡 : エンジニアリングというと、一般的な印象として難しい実装をして結果を出すという感じに思いがちですが、今回のプロジェクトの施策のように、そこまで工数をかけない実装であっても、 数字を見つつ仮説をちゃんと立てながら本質的な改善をすると結果にちゃんと結びつく んだということが、実感できたという点は大きいです。 また、今回のプロジェクトの主となる目的としては「服用アラームを使ってくれるユーザーを増やす」というものでしたが、そこに至るまでの 準備をちゃんとしておかないと結局ユーザーにとって真に使いやすいものにならない ので、こうした下準備をして丁寧に改善することの大切さというのが分かりました。 山田 : ちゃんと足場を固めて、長期的な視点も入れて改善をしていくというのは、プロダクトの価値を出す上で大事な事ですよね。それでは今回のプロジェクトでのやりがいに思った部分はどんな部分ですか? 吉岡 : ストアを見るとレビューで星 3 をつけていたユーザーの方が改善後に星 5 のレビューにしてくれているのを見たりすると**「ユーザーのために本当にやって良かったな」**と感じます。レビューだけではなく、数字は継続的に見ているので、その数字が向上しているのを観測できたら同じようにやりがいがあると思いました。 目指すエンジニア像 山田 : ここまで吉岡さんが、関わったプロジェクトについて聞いてきましたが、これからどんなエンジニアになっていきたいかという将来像はどんな風に考えているんでしょうか。 吉岡 : まずは同じチームの中の周りのエンジニアの方達を目標としたいなと思っております。具体的には他のエンジニアの皆さんの 課題解決能力の高さ を身に付けていきたいと思っています。 技術面でもプロダクト面でも、ちゃんと状況を分析して「こうすれば良いんではないか」という提案をさっとされたりしています。またその提案自体も複数出しつつ、それぞれのメリット・デメリットを提示してベストなやり方を選んでいる方ばかりなので、そうした部分を参考にしていきたいですね。 山田 : どのようにそうした能力を高めていこうと考えているんですか? 吉岡 : まずは普通に技術力を高めるというのはやっていかないといけないプロセスだとは思っています。 iOS / Android の開発もそうですし、データ構造などもちゃんと考えて実装が必要になったりする部分もあるので、サーバサイドなどもあるタイミングでちゃんとやっていきたいと考えています。 その上で、周りのエンジニアの方達と同じ考え方や、やり方を参考にしながら自身の課題に対処していく…ということを繰り返し経験していくことかなと考えています。 チームで一緒に働いていきたいエンジニア像 山田 : 最後になりますが、吉岡さんはどんなエンジニアと一緒に働いてみたいと考えていますか? 吉岡 : そうですね…。今のチームだと PdM とエンジニアが二人三脚で開発を進めていくというスタイルとなっていますので、そこで PdM が言うことだけをやるというのではなく、 ちゃんと自身の意見を持ってプロダクトをより良くしていくという意識を持っているエンジニア の方と一緒に働きたいです。 色々な施策をする上で、PdM の方とちゃんと役割分担をしつつも、最終目標としてはプロダクトを良くする。その為に PdM を含めエンジニア以外のカスタマーサポートなど他の職種の方へのリスペクトが欠かせないのではないかと思いますので、そうした事も自然とできる方が良いです。 山田 : とても大事な意識ですね。本日はありがとうございました! 最後に 新卒 2 年目ながらユーザーへの価値提供をするために、一連のプロジェクトをメインに担当している吉岡さん。インタビューをしていてメドレーの他のプロダクトのエンジニアにも通じる考え方で真摯に開発をしている様子が伺えました。 メドレーでは今回のように、データドリブンでユーザーへ価値を提供する開発をしていくネイティブアプリエンジニアも絶賛募集していますので、ご興味がある方はぜひカジュアルにお話からしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。メドレーでは医療プラットフォームで患者が使う「CLINICS」アプリを iOS / Android / Web で開発・運営しています。日々、患者が便利に使えるように改善をしていますが、特徴として エンジニアがプロダクトマネージャー(以下、PdM)と一緒に数値を見ながら、改善を行なっている という点が挙げられます。 今回は「CLINICS」アプリを開発している吉岡さんに、どのような開発フローで改善を行なっているのかをインタビューしてみました。 自己紹介 吉岡さん 医療 PF プロダクト開発室第一開発グループグロースチームにて患者向けアプリ「CLINICS」の開発業務を担当。主に薬局に関する機能開発を行っている。大学の専攻は物理で、大学途中からプログラミングを始めた。その後、 大学 4 年から長期インターンで開発に取り組み、Ruby on Rails や React.js など主に Web 開発を経験したあと 2022 年に新卒でメドレー入社。 吉岡さん メドレーに入社した理由 メドレーに入社するまでの経歴 山田 : よろしくお願いします。早速ですが、学生時代からメドレーに入社するまでの経歴をお話いただけますか? 吉岡 : 学生時代は物理学を専攻していましたが、途中からプログラミングを始めました。そのまま Web 開発をしている企業で長期インターンをして Ruby on Rails(以下、RoR) や React.js を使った開発経験を経てメドレーに入社しました。 山田 : 物理学を専攻していたということですが、授業でプログラミングをしていたんですか? 吉岡 : いえ、コロナ禍に入り、ちょうど予定していたオーロラ観察のためのフィンランド行きが無くなってしまったということがありまして。予定が無くなり 時間ができたので「何か始めてみよう」ということでプログラミングを始めた というのが最初のきっかけでした。プログラミング自体は前から気になっていたので、手を出してみたという次第です。 山田 : そうだったんですね! ではコロナ禍にならずに旅行に行くことになっていたら…。 吉岡 : はい、プログラミングしておらず入社もしていなかったかもしれないです(笑) なぜメドレーに入社しようと思ったのか 山田 : そんな吉岡さんは、どうしてメドレーに入社を決めたんですか? 吉岡 : まず最初にメドレーの「医療ヘルスケアの未来をつくる」という ミッションに共感したというのが大きい要因 です。また プロダクトファーストな考え方をしつつ、プロダクト開発への取り組み方が長期で課題に対してじっくりとアプローチ をするという姿勢がとても良いと感じたのも理由になります。 山田 : 入社前に受けた印象と実際に入社後に感じた印象のギャップなどはありますか? 吉岡 : プロダクト開発に関しては特に感じてはいないです。技術スタックについては入社前には RoR と React.js という Web アプリの技術スタックを自分は持っていたので、入社後もその部分のギャップはないかな?と思って入社したのですが、今の配属は患者アプリということで iOS / Android のネイティブアプリの技術に触ることにもなるので、そこの部分がギャップといえばギャップになります。 山田 : 入社前は Web エンジニアとしてだけ業務すると思っていたけど、入ったらネイティブアプリエンジニアとしての業務もあったという話ですね(笑) 吉岡 : そうなりますね(笑) ただ、 iOS / Android を触っていくうちに新しい技術に対する自分のキャッチアップ力には自信が付きました 。「初見の iOS ・ Android でもキャッチアップして開発できたから、他の未知領域もキャッチアップしていけるだろう」という感覚が強くなりましたね。 取り組んでいる業務について 山田 : それでは吉岡さんは現在のチームでどのような業務を担当しているか、聞かせてください。 吉岡 : はい。自分は患者アプリの開発を担当しています。患者さんの日々の通院や服薬を助けるということを目的として、オンライン診療・薬局への処方箋送付・お薬手帳などがこの患者アプリに含まれている機能になります。チームとしては自分は「グロースチーム」というチームに所属しています。主に既存機能の UI / UX の改善であったり、お薬手帳など患者が日常的にアプリを使ってもらえるような機能開発を担当しています。 チーム構成としてはデザイナー兼 PdM 1 人・ PdM 1 人・エンジニアが自分を含め 3 人という構成になっています。施策の規模によるのですが、小さいものであれば 1 人で iOS / Android / Web の 3 プラットフォームを開発しますし、ある程度の規模の施策であれば、それぞれ 1 プラットフォームずつエンジニアがアサインされて開発するようになっています。PdM の方はそれぞれの施策につき 1 人で担当されていることが多いです。 エンジニアはそれぞれ得意としているプラットフォームが分かれているので、プルリクエストを適宜レビューしてもらったり、不明な部分を質問したりという感じで開発していきます。 チームの定例は、毎日 30 分の夕会があり、そこで困り事があったら相談したり、共有するべき事を話したりという感じでやっています。その他は適宜、施策のキックオフだったり、自分が分からないことがあったりしたら周りに聞いたりということはしています。 お薬手帳改善プロジェクト お薬手帳とは、どんな機能か 山田 : ありがとうございます。では、本題となりますが、吉岡さんは「お薬手帳改善プロジェクト」というプロジェクトのメインのエンジニアとして担当をされていたということで、そちらのお話を聞いていきたいと思います。まず前提として「お薬手帳」の機能はどんなものなんでしょうか。 吉岡 : 皆さんも調剤薬局に行くと「お薬手帳をお持ちですか」と聞かれると思いますが、 その機能をアプリ化して便利 にしたものになります。 例えば、今まで自分が服用してきた薬についての履歴を参照できるようになります。また単に履歴だけではなく、服用した薬の副作用やアレルギー歴なども記録できるので、自分に合わない薬などを避け処方してもらえるようになるものです。この機能は調剤薬局で処方される薬だけではなく、市販薬についても記録できます。 また、患者アプリでのお薬手帳は QR コードで処方された薬を登録できるという機能と、薬の飲み忘れを防ぐため服用時間に通知を端末に送付する「服用アラーム」という機能も存在しています。 山田 : なるほど。では「お薬手帳改善プロジェクト」はどのような事を目的としていたプロジェクトだったんでしょうか。 吉岡 : 全体の目的として**「お薬手帳」機能を日常的に使っていただく患者数を増加させるために、UX の向上**を目指していました。私が担当した施策は、その中でも薬の飲み忘れを防止するための「服用アラーム」は使っていただいている患者の割合が低かったため、こちらの機能をもっと使ってもらうように改善すれば、必然的に日常的に「患者アプリ」を使う患者数も増えるだろうという背景のもと行われました。 既存の「服用アラーム」の課題 山田 : 「服用アラーム」はもともとそれ程には使われていない機能だったんですか? 吉岡 : もちろん使っていただいている患者数としては一定数いらっしゃったんですが、期待しているほどには多くなかったという感じでした。そこで使っていただけていない理由や背景を PdM が事前に分析などした結果として以下のような課題が浮き彫り になってきました。 そもそも「服用アラーム」機能を知らなかった 知っていても「服用アラーム」機能の使い方が分からない 「服用アラーム」機能を設定していても通知が届かない場合があった そこで、これらの課題を整理して以下のような順番で改善を行なっていくことにしました。 服用アラーム設定の UI 改善 服用アラームの通知が届かない問題の解消 お薬登録から服用アラームの登録導線の改善 こうして、課題から実装方針までをまず決めていきました。 服用アラーム設定の UI 改善 山田 : 方針の内、最初の服用アラーム設定の UI 改善はどのように行なっていったんでしょうか。 吉岡 : まず、PdM が主体となりユーザーインタビューを行なった結果や、ユーザーサポートの問い合わせ傾向の分析をした結果、 服用アラーム設定の画面でこちらが意図した通りに使ってもらえていないという事実が分かりました 。UI 上でユーザーに少し混乱を招いてしまっていました。 そこで、その概念や設定フローを整理して UI に反映させて、混乱を少なくするように改善を行ないました。 山田 : ちゃんとこちらの概念が正しく UI に反映するようにしたということですね。 服用アラームの通知が届かない問題の解消 吉岡 : はい。これでまず設定が正しくできないという状態が解消されたので、次のステップに進むことにしました。次は正しく設定しているのにも関わらず、一部のユーザーに通知が設定通りに来ない場合があったのを解消しました。こちらの方で特にエラーなどは検知できなかったので、 PdM と仮説を立てて検証 していきました。 山田 : なるほど。どのような仮説だったんですか? 吉岡 : そもそもユーザーが Push 通知を実はオンにしていないのではないかという仮説です。そこで、仮説検証のためまずデータを取って実際どの位のユーザーが Push 通知をオンにしているかを調査したのですが、予想以上に多くのユーザーが Push 通知をオンにしていませんでした。仮説が正しいものだと証明されたので、 Push 通知の許諾を促すための改善を行ないました 。この施策の結果として 2 倍以上のユーザーが Push 通知をオンにしてくれたので、 「服用アラーム」の通知が届かないという問い合わせが減少 しました。 山田 : かなり効果的な施策になったようですね。工数的にはそこまでかからずに実現できたんですか? 吉岡 : はい、工数はあまりかかってないので、結果を見るとコストパフォーマンスが良い施策になったと思います。 服用アラームの登録導線の改善 吉岡 : ここまでで、下準備が整ったので「服用アラーム」自体を実際にさらにユーザーに使ってもらうための施策として、登録までの導線を改善することにしました。今まではお薬を登録するか、お薬と服用アラームを同時に登録するか選べたのですが、お薬手帳への薬の登録後に「服用アラーム」の設定を促す導線を表示するように改善しました。理由としては、 薬の登録をしてから「服用アラーム」の登録をしたユーザーの割合を調べてみたところ、大多数のユーザーが設定をしていなかったことが分かった からです。 山田 : かなりの方が「服用アラーム」を設定せずにいたのは驚きですね。ユーザーはなぜ設定していなかったんですか? 吉岡 : 改善以前の UI では、薬を登録をするためのボタンがあり、その下に「服用アラーム」設定ボタンが並列で設置されていました。 開発側としては、お薬登録と同時に服用アラームを設定する導線がユーザーには分かりやすいだろうと考えていました。しかし、フタを開けてみると登録数が増えないことになっていました。 良く考えると 当たり前だったんですが、開発側としてみれば「服用アラーム」という名前の機能については自明で「こういう動きをする機能だろう」というのが分かった上で、導線として認識していたんです。しかし、ユーザー側の視点とすると最初にこの画面を見て思うことは「服用アラームってなんなんだろう?」という疑問で、「良く分からないからお薬の登録だけしよう」という心理になってしまっていたようなんです。 登録導線改善前の UI 山田 : 確かに説明がないまま「服用アラーム」と言われると、まずは「何だこれ?」となりそうです。それでは、どんな改善を行なって、この課題に対処したんですか? 吉岡 : 先程もお話した、薬の登録から「服用アラーム」設定までのデータを PdM と一緒に検討した結果、一番多くアラームの設定をしてもらえるパターンとしては薬の登録をしたのと同時に設定しているということが分かりました。 ですので、 導線は今までの「薬の登録」+「服用アラーム」ではなく「薬の登録」→「服用アラームの説明と設定」という形に変更 しました。この改善によって、まずは薬の登録をしたいというニーズを満たし、次に「服用アラーム」とはどんな機能なのかを伝え、最後に「服用アラーム」の設定をしてもらうという、ユーザーにとって自然な流れになるように改善しました。 登録導線改善後の UI 山田 : 説明も入ってちゃんとユーザーに便利な機能だということも分かってもらえるようにしたんですね。こちらの改善施策の効果はどんな感じだったんですか? 吉岡 : こちらの施策は改善の前後で 2 倍近く「服用アラーム」を設定してくれるユーザーが増えました。この改善も効果的なものになったんじゃないかと考えています。 お薬手帳改善プロジェクトで苦労した部分 山田 : お薬手帳改善プロジェクトでは PdM と二人三脚でデータを取りながら、仮説を立てて改善していくプロセスで結果に繋げていると感じたのですが、このプロジェクトで苦労した部分は何かありますか? 吉岡 : 技術的に難易度が高いという改善ではなかったのですが、個人的に苦労した点としては iOS / Android それぞれのプラットフォームで Push 通知に関する仕様が当たり前ですが全然違うので、 詳しいメンバーにアドバイスをもらいながら通知に関してキャッチアップする必要があった点が、大変 ではありました。 山田 : これまであまり Push 通知周りの実装の経験を持っていない中だと、各プラットフォームに合わせて実装するのはちょっと大変ですよね。 吉岡 : もちろん、公式ドキュメントも充実しているので、そうしたものを調べたり、最終レビューとしては各プラットフォームの知見が深いエンジニアに見てもらったりもしたので、キャッチアップもしやすくはありましたけども。 その他に ネイティブアプリの開発で必要な知識などは、当たり前ですが書籍などで勉強 などはした上で、局地的にこうした Push 通知などに取り組んだ感じではあります。 お薬手帳改善プロジェクトで学んだこと・やりがいと思ったところ 山田 : 今回の一連のプロジェクトで吉岡さんが学んだ部分として、どんなものがありましたか? 吉岡 : エンジニアリングというと、一般的な印象として難しい実装をして結果を出すという感じに思いがちですが、今回のプロジェクトの施策のように、そこまで工数をかけない実装であっても、 数字を見つつ仮説をちゃんと立てながら本質的な改善をすると結果にちゃんと結びつく んだということが、実感できたという点は大きいです。 また、今回のプロジェクトの主となる目的としては「服用アラームを使ってくれるユーザーを増やす」というものでしたが、そこに至るまでの 準備をちゃんとしておかないと結局ユーザーにとって真に使いやすいものにならない ので、こうした下準備をして丁寧に改善することの大切さというのが分かりました。 山田 : ちゃんと足場を固めて、長期的な視点も入れて改善をしていくというのは、プロダクトの価値を出す上で大事な事ですよね。それでは今回のプロジェクトでのやりがいに思った部分はどんな部分ですか? 吉岡 : ストアを見るとレビューで星 3 をつけていたユーザーの方が改善後に星 5 のレビューにしてくれているのを見たりすると**「ユーザーのために本当にやって良かったな」**と感じます。レビューだけではなく、数字は継続的に見ているので、その数字が向上しているのを観測できたら同じようにやりがいがあると思いました。 目指すエンジニア像 山田 : ここまで吉岡さんが、関わったプロジェクトについて聞いてきましたが、これからどんなエンジニアになっていきたいかという将来像はどんな風に考えているんでしょうか。 吉岡 : まずは同じチームの中の周りのエンジニアの方達を目標としたいなと思っております。具体的には他のエンジニアの皆さんの 課題解決能力の高さ を身に付けていきたいと思っています。 技術面でもプロダクト面でも、ちゃんと状況を分析して「こうすれば良いんではないか」という提案をさっとされたりしています。またその提案自体も複数出しつつ、それぞれのメリット・デメリットを提示してベストなやり方を選んでいる方ばかりなので、そうした部分を参考にしていきたいですね。 山田 : どのようにそうした能力を高めていこうと考えているんですか? 吉岡 : まずは普通に技術力を高めるというのはやっていかないといけないプロセスだとは思っています。 iOS / Android の開発もそうですし、データ構造などもちゃんと考えて実装が必要になったりする部分もあるので、サーバサイドなどもあるタイミングでちゃんとやっていきたいと考えています。 その上で、周りのエンジニアの方達と同じ考え方や、やり方を参考にしながら自身の課題に対処していく…ということを繰り返し経験していくことかなと考えています。 チームで一緒に働いていきたいエンジニア像 山田 : 最後になりますが、吉岡さんはどんなエンジニアと一緒に働いてみたいと考えていますか? 吉岡 : そうですね…。今のチームだと PdM とエンジニアが二人三脚で開発を進めていくというスタイルとなっていますので、そこで PdM が言うことだけをやるというのではなく、 ちゃんと自身の意見を持ってプロダクトをより良くしていくという意識を持っているエンジニア の方と一緒に働きたいです。 色々な施策をする上で、PdM の方とちゃんと役割分担をしつつも、最終目標としてはプロダクトを良くする。その為に PdM を含めエンジニア以外のカスタマーサポートなど他の職種の方へのリスペクトが欠かせないのではないかと思いますので、そうした事も自然とできる方が良いです。 山田 : とても大事な意識ですね。本日はありがとうございました! 最後に 新卒 2 年目ながらユーザーへの価値提供をするために、一連のプロジェクトをメインに担当している吉岡さん。インタビューをしていてメドレーの他のプロダクトのエンジニアにも通じる考え方で真摯に開発をしている様子が伺えました。 メドレーでは今回のように、データドリブンでユーザーへ価値を提供する開発をしていくネイティブアプリエンジニアも絶賛募集していますので、ご興味がある方はぜひカジュアルにお話からしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。メドレーでは医療プラットフォームで患者が使う「CLINICS」アプリを iOS / Android / Web で開発・運営しています。日々、患者が便利に使えるように改善をしていますが、特徴として エンジニアがプロダクトマネージャー(以下、PdM)と一緒に数値を見ながら、改善を行なっている という点が挙げられます。 今回は「CLINICS」アプリを開発している吉岡さんに、どのような開発フローで改善を行なっているのかをインタビューしてみました。 自己紹介 吉岡さん 医療 PF プロダクト開発室第一開発グループグロースチームにて患者向けアプリ「CLINICS」の開発業務を担当。主に薬局に関する機能開発を行っている。大学の専攻は物理で、大学途中からプログラミングを始めた。その後、 大学 4 年から長期インターンで開発に取り組み、Ruby on Rails や React.js など主に Web 開発を経験したあと 2022 年に新卒でメドレー入社。 吉岡さん メドレーに入社した理由 メドレーに入社するまでの経歴 山田 : よろしくお願いします。早速ですが、学生時代からメドレーに入社するまでの経歴をお話いただけますか? 吉岡 : 学生時代は物理学を専攻していましたが、途中からプログラミングを始めました。そのまま Web 開発をしている企業で長期インターンをして Ruby on Rails(以下、RoR) や React.js を使った開発経験を経てメドレーに入社しました。 山田 : 物理学を専攻していたということですが、授業でプログラミングをしていたんですか? 吉岡 : いえ、コロナ禍に入り、ちょうど予定していたオーロラ観察のためのフィンランド行きが無くなってしまったということがありまして。予定が無くなり 時間ができたので「何か始めてみよう」ということでプログラミングを始めた というのが最初のきっかけでした。プログラミング自体は前から気になっていたので、手を出してみたという次第です。 山田 : そうだったんですね! ではコロナ禍にならずに旅行に行くことになっていたら…。 吉岡 : はい、プログラミングしておらず入社もしていなかったかもしれないです(笑) なぜメドレーに入社しようと思ったのか 山田 : そんな吉岡さんは、どうしてメドレーに入社を決めたんですか? 吉岡 : まず最初にメドレーの「医療ヘルスケアの未来をつくる」という ミッションに共感したというのが大きい要因 です。また プロダクトファーストな考え方をしつつ、プロダクト開発への取り組み方が長期で課題に対してじっくりとアプローチ をするという姿勢がとても良いと感じたのも理由になります。 山田 : 入社前に受けた印象と実際に入社後に感じた印象のギャップなどはありますか? 吉岡 : プロダクト開発に関しては特に感じてはいないです。技術スタックについては入社前には RoR と React.js という Web アプリの技術スタックを自分は持っていたので、入社後もその部分のギャップはないかな?と思って入社したのですが、今の配属は患者アプリということで iOS / Android のネイティブアプリの技術に触ることにもなるので、そこの部分がギャップといえばギャップになります。 山田 : 入社前は Web エンジニアとしてだけ業務すると思っていたけど、入ったらネイティブアプリエンジニアとしての業務もあったという話ですね(笑) 吉岡 : そうなりますね(笑) ただ、 iOS / Android を触っていくうちに新しい技術に対する自分のキャッチアップ力には自信が付きました 。「初見の iOS ・ Android でもキャッチアップして開発できたから、他の未知領域もキャッチアップしていけるだろう」という感覚が強くなりましたね。 取り組んでいる業務について 山田 : それでは吉岡さんは現在のチームでどのような業務を担当しているか、聞かせてください。 吉岡 : はい。自分は患者アプリの開発を担当しています。患者さんの日々の通院や服薬を助けるということを目的として、オンライン診療・薬局への処方箋送付・お薬手帳などがこの患者アプリに含まれている機能になります。チームとしては自分は「グロースチーム」というチームに所属しています。主に既存機能の UI / UX の改善であったり、お薬手帳など患者が日常的にアプリを使ってもらえるような機能開発を担当しています。 チーム構成としてはデザイナー兼 PdM 1 人・ PdM 1 人・エンジニアが自分を含め 3 人という構成になっています。施策の規模によるのですが、小さいものであれば 1 人で iOS / Android / Web の 3 プラットフォームを開発しますし、ある程度の規模の施策であれば、それぞれ 1 プラットフォームずつエンジニアがアサインされて開発するようになっています。PdM の方はそれぞれの施策につき 1 人で担当されていることが多いです。 エンジニアはそれぞれ得意としているプラットフォームが分かれているので、プルリクエストを適宜レビューしてもらったり、不明な部分を質問したりという感じで開発していきます。 チームの定例は、毎日 30 分の夕会があり、そこで困り事があったら相談したり、共有するべき事を話したりという感じでやっています。その他は適宜、施策のキックオフだったり、自分が分からないことがあったりしたら周りに聞いたりということはしています。 お薬手帳改善プロジェクト お薬手帳とは、どんな機能か 山田 : ありがとうございます。では、本題となりますが、吉岡さんは「お薬手帳改善プロジェクト」というプロジェクトのメインのエンジニアとして担当をされていたということで、そちらのお話を聞いていきたいと思います。まず前提として「お薬手帳」の機能はどんなものなんでしょうか。 吉岡 : 皆さんも調剤薬局に行くと「お薬手帳をお持ちですか」と聞かれると思いますが、 その機能をアプリ化して便利 にしたものになります。 例えば、今まで自分が服用してきた薬についての履歴を参照できるようになります。また単に履歴だけではなく、服用した薬の副作用やアレルギー歴なども記録できるので、自分に合わない薬などを避け処方してもらえるようになるものです。この機能は調剤薬局で処方される薬だけではなく、市販薬についても記録できます。 また、患者アプリでのお薬手帳は QR コードで処方された薬を登録できるという機能と、薬の飲み忘れを防ぐため服用時間に通知を端末に送付する「服用アラーム」という機能も存在しています。 山田 : なるほど。では「お薬手帳改善プロジェクト」はどのような事を目的としていたプロジェクトだったんでしょうか。 吉岡 : 全体の目的として**「お薬手帳」機能を日常的に使っていただく患者数を増加させるために、UX の向上**を目指していました。私が担当した施策は、その中でも薬の飲み忘れを防止するための「服用アラーム」は使っていただいている患者の割合が低かったため、こちらの機能をもっと使ってもらうように改善すれば、必然的に日常的に「患者アプリ」を使う患者数も増えるだろうという背景のもと行われました。 既存の「服用アラーム」の課題 山田 : 「服用アラーム」はもともとそれ程には使われていない機能だったんですか? 吉岡 : もちろん使っていただいている患者数としては一定数いらっしゃったんですが、期待しているほどには多くなかったという感じでした。そこで使っていただけていない理由や背景を PdM が事前に分析などした結果として以下のような課題が浮き彫り になってきました。 そもそも「服用アラーム」機能を知らなかった 知っていても「服用アラーム」機能の使い方が分からない 「服用アラーム」機能を設定していても通知が届かない場合があった そこで、これらの課題を整理して以下のような順番で改善を行なっていくことにしました。 服用アラーム設定の UI 改善 服用アラームの通知が届かない問題の解消 お薬登録から服用アラームの登録導線の改善 こうして、課題から実装方針までをまず決めていきました。 服用アラーム設定の UI 改善 山田 : 方針の内、最初の服用アラーム設定の UI 改善はどのように行なっていったんでしょうか。 吉岡 : まず、PdM が主体となりユーザーインタビューを行なった結果や、ユーザーサポートの問い合わせ傾向の分析をした結果、 服用アラーム設定の画面でこちらが意図した通りに使ってもらえていないという事実が分かりました 。UI 上でユーザーに少し混乱を招いてしまっていました。 そこで、その概念や設定フローを整理して UI に反映させて、混乱を少なくするように改善を行ないました。 山田 : ちゃんとこちらの概念が正しく UI に反映するようにしたということですね。 服用アラームの通知が届かない問題の解消 吉岡 : はい。これでまず設定が正しくできないという状態が解消されたので、次のステップに進むことにしました。次は正しく設定しているのにも関わらず、一部のユーザーに通知が設定通りに来ない場合があったのを解消しました。こちらの方で特にエラーなどは検知できなかったので、 PdM と仮説を立てて検証 していきました。 山田 : なるほど。どのような仮説だったんですか? 吉岡 : そもそもユーザーが Push 通知を実はオンにしていないのではないかという仮説です。そこで、仮説検証のためまずデータを取って実際どの位のユーザーが Push 通知をオンにしているかを調査したのですが、予想以上に多くのユーザーが Push 通知をオンにしていませんでした。仮説が正しいものだと証明されたので、 Push 通知の許諾を促すための改善を行ないました 。この施策の結果として 2 倍以上のユーザーが Push 通知をオンにしてくれたので、 「服用アラーム」の通知が届かないという問い合わせが減少 しました。 山田 : かなり効果的な施策になったようですね。工数的にはそこまでかからずに実現できたんですか? 吉岡 : はい、工数はあまりかかってないので、結果を見るとコストパフォーマンスが良い施策になったと思います。 服用アラームの登録導線の改善 吉岡 : ここまでで、下準備が整ったので「服用アラーム」自体を実際にさらにユーザーに使ってもらうための施策として、登録までの導線を改善することにしました。今まではお薬を登録するか、お薬と服用アラームを同時に登録するか選べたのですが、お薬手帳への薬の登録後に「服用アラーム」の設定を促す導線を表示するように改善しました。理由としては、 薬の登録をしてから「服用アラーム」の登録をしたユーザーの割合を調べてみたところ、大多数のユーザーが設定をしていなかったことが分かった からです。 山田 : かなりの方が「服用アラーム」を設定せずにいたのは驚きですね。ユーザーはなぜ設定していなかったんですか? 吉岡 : 改善以前の UI では、薬を登録をするためのボタンがあり、その下に「服用アラーム」設定ボタンが並列で設置されていました。 開発側としては、お薬登録と同時に服用アラームを設定する導線がユーザーには分かりやすいだろうと考えていました。しかし、フタを開けてみると登録数が増えないことになっていました。 良く考えると 当たり前だったんですが、開発側としてみれば「服用アラーム」という名前の機能については自明で「こういう動きをする機能だろう」というのが分かった上で、導線として認識していたんです。しかし、ユーザー側の視点とすると最初にこの画面を見て思うことは「服用アラームってなんなんだろう?」という疑問で、「良く分からないからお薬の登録だけしよう」という心理になってしまっていたようなんです。 登録導線改善前の UI 山田 : 確かに説明がないまま「服用アラーム」と言われると、まずは「何だこれ?」となりそうです。それでは、どんな改善を行なって、この課題に対処したんですか? 吉岡 : 先程もお話した、薬の登録から「服用アラーム」設定までのデータを PdM と一緒に検討した結果、一番多くアラームの設定をしてもらえるパターンとしては薬の登録をしたのと同時に設定しているということが分かりました。 ですので、 導線は今までの「薬の登録」+「服用アラーム」ではなく「薬の登録」→「服用アラームの説明と設定」という形に変更 しました。この改善によって、まずは薬の登録をしたいというニーズを満たし、次に「服用アラーム」とはどんな機能なのかを伝え、最後に「服用アラーム」の設定をしてもらうという、ユーザーにとって自然な流れになるように改善しました。 登録導線改善後の UI 山田 : 説明も入ってちゃんとユーザーに便利な機能だということも分かってもらえるようにしたんですね。こちらの改善施策の効果はどんな感じだったんですか? 吉岡 : こちらの施策は改善の前後で 2 倍近く「服用アラーム」を設定してくれるユーザーが増えました。この改善も効果的なものになったんじゃないかと考えています。 お薬手帳改善プロジェクトで苦労した部分 山田 : お薬手帳改善プロジェクトでは PdM と二人三脚でデータを取りながら、仮説を立てて改善していくプロセスで結果に繋げていると感じたのですが、このプロジェクトで苦労した部分は何かありますか? 吉岡 : 技術的に難易度が高いという改善ではなかったのですが、個人的に苦労した点としては iOS / Android それぞれのプラットフォームで Push 通知に関する仕様が当たり前ですが全然違うので、 詳しいメンバーにアドバイスをもらいながら通知に関してキャッチアップする必要があった点が、大変 ではありました。 山田 : これまであまり Push 通知周りの実装の経験を持っていない中だと、各プラットフォームに合わせて実装するのはちょっと大変ですよね。 吉岡 : もちろん、公式ドキュメントも充実しているので、そうしたものを調べたり、最終レビューとしては各プラットフォームの知見が深いエンジニアに見てもらったりもしたので、キャッチアップもしやすくはありましたけども。 その他に ネイティブアプリの開発で必要な知識などは、当たり前ですが書籍などで勉強 などはした上で、局地的にこうした Push 通知などに取り組んだ感じではあります。 お薬手帳改善プロジェクトで学んだこと・やりがいと思ったところ 山田 : 今回の一連のプロジェクトで吉岡さんが学んだ部分として、どんなものがありましたか? 吉岡 : エンジニアリングというと、一般的な印象として難しい実装をして結果を出すという感じに思いがちですが、今回のプロジェクトの施策のように、そこまで工数をかけない実装であっても、 数字を見つつ仮説をちゃんと立てながら本質的な改善をすると結果にちゃんと結びつく んだということが、実感できたという点は大きいです。 また、今回のプロジェクトの主となる目的としては「服用アラームを使ってくれるユーザーを増やす」というものでしたが、そこに至るまでの 準備をちゃんとしておかないと結局ユーザーにとって真に使いやすいものにならない ので、こうした下準備をして丁寧に改善することの大切さというのが分かりました。 山田 : ちゃんと足場を固めて、長期的な視点も入れて改善をしていくというのは、プロダクトの価値を出す上で大事な事ですよね。それでは今回のプロジェクトでのやりがいに思った部分はどんな部分ですか? 吉岡 : ストアを見るとレビューで星 3 をつけていたユーザーの方が改善後に星 5 のレビューにしてくれているのを見たりすると**「ユーザーのために本当にやって良かったな」**と感じます。レビューだけではなく、数字は継続的に見ているので、その数字が向上しているのを観測できたら同じようにやりがいがあると思いました。 目指すエンジニア像 山田 : ここまで吉岡さんが、関わったプロジェクトについて聞いてきましたが、これからどんなエンジニアになっていきたいかという将来像はどんな風に考えているんでしょうか。 吉岡 : まずは同じチームの中の周りのエンジニアの方達を目標としたいなと思っております。具体的には他のエンジニアの皆さんの 課題解決能力の高さ を身に付けていきたいと思っています。 技術面でもプロダクト面でも、ちゃんと状況を分析して「こうすれば良いんではないか」という提案をさっとされたりしています。またその提案自体も複数出しつつ、それぞれのメリット・デメリットを提示してベストなやり方を選んでいる方ばかりなので、そうした部分を参考にしていきたいですね。 山田 : どのようにそうした能力を高めていこうと考えているんですか? 吉岡 : まずは普通に技術力を高めるというのはやっていかないといけないプロセスだとは思っています。 iOS / Android の開発もそうですし、データ構造などもちゃんと考えて実装が必要になったりする部分もあるので、サーバサイドなどもあるタイミングでちゃんとやっていきたいと考えています。 その上で、周りのエンジニアの方達と同じ考え方や、やり方を参考にしながら自身の課題に対処していく…ということを繰り返し経験していくことかなと考えています。 チームで一緒に働いていきたいエンジニア像 山田 : 最後になりますが、吉岡さんはどんなエンジニアと一緒に働いてみたいと考えていますか? 吉岡 : そうですね…。今のチームだと PdM とエンジニアが二人三脚で開発を進めていくというスタイルとなっていますので、そこで PdM が言うことだけをやるというのではなく、 ちゃんと自身の意見を持ってプロダクトをより良くしていくという意識を持っているエンジニア の方と一緒に働きたいです。 色々な施策をする上で、PdM の方とちゃんと役割分担をしつつも、最終目標としてはプロダクトを良くする。その為に PdM を含めエンジニア以外のカスタマーサポートなど他の職種の方へのリスペクトが欠かせないのではないかと思いますので、そうした事も自然とできる方が良いです。 山田 : とても大事な意識ですね。本日はありがとうございました! 最後に 新卒 2 年目ながらユーザーへの価値提供をするために、一連のプロジェクトをメインに担当している吉岡さん。インタビューをしていてメドレーの他のプロダクトのエンジニアにも通じる考え方で真摯に開発をしている様子が伺えました。 メドレーでは今回のように、データドリブンでユーザーへ価値を提供する開発をしていくネイティブアプリエンジニアも絶賛募集していますので、ご興味がある方はぜひカジュアルにお話からしましょう。 https://www.medley.jp/jobs/

はじめに みなさん、こんにちは。エンジニアの山田です。メドレーでは医療プラットフォームで患者が使う「CLINICS」アプリを iOS / Android / Web で開発・運営しています。日々、患者が便利に使えるように改善をしていますが、特徴として エンジニアがプロダクトマネージャー(以下、PdM)と一緒に数値を見ながら、改善を行なっている という点が挙げられます。 今回は「CLINICS」アプリを開発している吉岡さんに、どのような開発フローで改善を行なっているのかをインタビューしてみました。 自己紹介 吉岡さん 医療 PF プロダクト開発室第一開発グループグロースチームにて患者向けアプリ「CLINICS」の開発業務を担当。主に薬局に関する機能開発を行っている。大学の専攻は物理で、大学途中からプログラミングを始めた。その後、 大学 4 年から長期インターンで開発に取り組み、Ruby on Rails や React.js など主に Web 開発を経験したあと 2022 年に新卒でメドレー入社。 吉岡さん メドレーに入社した理由 メドレーに入社するまでの経歴 山田 : よろしくお願いします。早速ですが、学生時代からメドレーに入社するまでの経歴をお話いただけますか? 吉岡 : 学生時代は物理学を専攻していましたが、途中からプログラミングを始めました。そのまま Web 開発をしている企業で長期インターンをして Ruby on Rails(以下、RoR) や React.js を使った開発経験を経てメドレーに入社しました。 山田 : 物理学を専攻していたということですが、授業でプログラミングをしていたんですか? 吉岡 : いえ、コロナ禍に入り、ちょうど予定していたオーロラ観察のためのフィンランド行きが無くなってしまったということがありまして。予定が無くなり 時間ができたので「何か始めてみよう」ということでプログラミングを始めた というのが最初のきっかけでした。プログラミング自体は前から気になっていたので、手を出してみたという次第です。 山田 : そうだったんですね! ではコロナ禍にならずに旅行に行くことになっていたら…。 吉岡 : はい、プログラミングしておらず入社もしていなかったかもしれないです(笑) なぜメドレーに入社しようと思ったのか 山田 : そんな吉岡さんは、どうしてメドレーに入社を決めたんですか? 吉岡 : まず最初にメドレーの「医療ヘルスケアの未来をつくる」という ミッションに共感したというのが大きい要因 です。また プロダクトファーストな考え方をしつつ、プロダクト開発への取り組み方が長期で課題に対してじっくりとアプローチ をするという姿勢がとても良いと感じたのも理由になります。 山田 : 入社前に受けた印象と実際に入社後に感じた印象のギャップなどはありますか? 吉岡 : プロダクト開発に関しては特に感じてはいないです。技術スタックについては入社前には RoR と React.js という Web アプリの技術スタックを自分は持っていたので、入社後もその部分のギャップはないかな?と思って入社したのですが、今の配属は患者アプリということで iOS / Android のネイティブアプリの技術に触ることにもなるので、そこの部分がギャップといえばギャップになります。 山田 : 入社前は Web エンジニアとしてだけ業務すると思っていたけど、入ったらネイティブアプリエンジニアとしての業務もあったという話ですね(笑) 吉岡 : そうなりますね(笑) ただ、 iOS / Android を触っていくうちに新しい技術に対する自分のキャッチアップ力には自信が付きました 。「初見の iOS ・ Android でもキャッチアップして開発できたから、他の未知領域もキャッチアップしていけるだろう」という感覚が強くなりましたね。 取り組んでいる業務について 山田 : それでは吉岡さんは現在のチームでどのような業務を担当しているか、聞かせてください。 吉岡 : はい。自分は患者アプリの開発を担当しています。患者さんの日々の通院や服薬を助けるということを目的として、オンライン診療・薬局への処方箋送付・お薬手帳などがこの患者アプリに含まれている機能になります。チームとしては自分は「グロースチーム」というチームに所属しています。主に既存機能の UI / UX の改善であったり、お薬手帳など患者が日常的にアプリを使ってもらえるような機能開発を担当しています。 チーム構成としてはデザイナー兼 PdM 1 人・ PdM 1 人・エンジニアが自分を含め 3 人という構成になっています。施策の規模によるのですが、小さいものであれば 1 人で iOS / Android / Web の 3 プラットフォームを開発しますし、ある程度の規模の施策であれば、それぞれ 1 プラットフォームずつエンジニアがアサインされて開発するようになっています。PdM の方はそれぞれの施策につき 1 人で担当されていることが多いです。 エンジニアはそれぞれ得意としているプラットフォームが分かれているので、プルリクエストを適宜レビューしてもらったり、不明な部分を質問したりという感じで開発していきます。 チームの定例は、毎日 30 分の夕会があり、そこで困り事があったら相談したり、共有するべき事を話したりという感じでやっています。その他は適宜、施策のキックオフだったり、自分が分からないことがあったりしたら周りに聞いたりということはしています。 お薬手帳改善プロジェクト お薬手帳とは、どんな機能か 山田 : ありがとうございます。では、本題となりますが、吉岡さんは「お薬手帳改善プロジェクト」というプロジェクトのメインのエンジニアとして担当をされていたということで、そちらのお話を聞いていきたいと思います。まず前提として「お薬手帳」の機能はどんなものなんでしょうか。 吉岡 : 皆さんも調剤薬局に行くと「お薬手帳をお持ちですか」と聞かれると思いますが、 その機能をアプリ化して便利 にしたものになります。 例えば、今まで自分が服用してきた薬についての履歴を参照できるようになります。また単に履歴だけではなく、服用した薬の副作用やアレルギー歴なども記録できるので、自分に合わない薬などを避け処方してもらえるようになるものです。この機能は調剤薬局で処方される薬だけではなく、市販薬についても記録できます。 また、患者アプリでのお薬手帳は QR コードで処方された薬を登録できるという機能と、薬の飲み忘れを防ぐため服用時間に通知を端末に送付する「服用アラーム」という機能も存在しています。 山田 : なるほど。では「お薬手帳改善プロジェクト」はどのような事を目的としていたプロジェクトだったんでしょうか。 吉岡 : 全体の目的として**「お薬手帳」機能を日常的に使っていただく患者数を増加させるために、UX の向上**を目指していました。私が担当した施策は、その中でも薬の飲み忘れを防止するための「服用アラーム」は使っていただいている患者の割合が低かったため、こちらの機能をもっと使ってもらうように改善すれば、必然的に日常的に「患者アプリ」を使う患者数も増えるだろうという背景のもと行われました。 既存の「服用アラーム」の課題 山田 : 「服用アラーム」はもともとそれ程には使われていない機能だったんですか? 吉岡 : もちろん使っていただいている患者数としては一定数いらっしゃったんですが、期待しているほどには多くなかったという感じでした。そこで使っていただけていない理由や背景を PdM が事前に分析などした結果として以下のような課題が浮き彫り になってきました。 そもそも「服用アラーム」機能を知らなかった 知っていても「服用アラーム」機能の使い方が分からない 「服用アラーム」機能を設定していても通知が届かない場合があった そこで、これらの課題を整理して以下のような順番で改善を行なっていくことにしました。 服用アラーム設定の UI 改善 服用アラームの通知が届かない問題の解消 お薬登録から服用アラームの登録導線の改善 こうして、課題から実装方針までをまず決めていきました。 服用アラーム設定の UI 改善 山田 : 方針の内、最初の服用アラーム設定の UI 改善はどのように行なっていったんでしょうか。 吉岡 : まず、PdM が主体となりユーザーインタビューを行なった結果や、ユーザーサポートの問い合わせ傾向の分析をした結果、 服用アラーム設定の画面でこちらが意図した通りに使ってもらえていないという事実が分かりました 。UI 上でユーザーに少し混乱を招いてしまっていました。 そこで、その概念や設定フローを整理して UI に反映させて、混乱を少なくするように改善を行ないました。 山田 : ちゃんとこちらの概念が正しく UI に反映するようにしたということですね。 服用アラームの通知が届かない問題の解消 吉岡 : はい。これでまず設定が正しくできないという状態が解消されたので、次のステップに進むことにしました。次は正しく設定しているのにも関わらず、一部のユーザーに通知が設定通りに来ない場合があったのを解消しました。こちらの方で特にエラーなどは検知できなかったので、 PdM と仮説を立てて検証 していきました。 山田 : なるほど。どのような仮説だったんですか? 吉岡 : そもそもユーザーが Push 通知を実はオンにしていないのではないかという仮説です。そこで、仮説検証のためまずデータを取って実際どの位のユーザーが Push 通知をオンにしているかを調査したのですが、予想以上に多くのユーザーが Push 通知をオンにしていませんでした。仮説が正しいものだと証明されたので、 Push 通知の許諾を促すための改善を行ないました 。この施策の結果として 2 倍以上のユーザーが Push 通知をオンにしてくれたので、 「服用アラーム」の通知が届かないという問い合わせが減少 しました。 山田 : かなり効果的な施策になったようですね。工数的にはそこまでかからずに実現できたんですか? 吉岡 : はい、工数はあまりかかってないので、結果を見るとコストパフォーマンスが良い施策になったと思います。 服用アラームの登録導線の改善 吉岡 : ここまでで、下準備が整ったので「服用アラーム」自体を実際にさらにユーザーに使ってもらうための施策として、登録までの導線を改善することにしました。今まではお薬を登録するか、お薬と服用アラームを同時に登録するか選べたのですが、お薬手帳への薬の登録後に「服用アラーム」の設定を促す導線を表示するように改善しました。理由としては、 薬の登録をしてから「服用アラーム」の登録をしたユーザーの割合を調べてみたところ、大多数のユーザーが設定をしていなかったことが分かった からです。 山田 : かなりの方が「服用アラーム」を設定せずにいたのは驚きですね。ユーザーはなぜ設定していなかったんですか? 吉岡 : 改善以前の UI では、薬を登録をするためのボタンがあり、その下に「服用アラーム」設定ボタンが並列で設置されていました。 開発側としては、お薬登録と同時に服用アラームを設定する導線がユーザーには分かりやすいだろうと考えていました。しかし、フタを開けてみると登録数が増えないことになっていました。 良く考えると 当たり前だったんですが、開発側としてみれば「服用アラーム」という名前の機能については自明で「こういう動きをする機能だろう」というのが分かった上で、導線として認識していたんです。しかし、ユーザー側の視点とすると最初にこの画面を見て思うことは「服用アラームってなんなんだろう?」という疑問で、「良く分からないからお薬の登録だけしよう」という心理になってしまっていたようなんです。 登録導線改善前の UI 山田 : 確かに説明がないまま「服用アラーム」と言われると、まずは「何だこれ?」となりそうです。それでは、どんな改善を行なって、この課題に対処したんですか? 吉岡 : 先程もお話した、薬の登録から「服用アラーム」設定までのデータを PdM と一緒に検討した結果、一番多くアラームの設定をしてもらえるパターンとしては薬の登録をしたのと同時に設定しているということが分かりました。 ですので、 導線は今までの「薬の登録」+「服用アラーム」ではなく「薬の登録」→「服用アラームの説明と設定」という形に変更 しました。この改善によって、まずは薬の登録をしたいというニーズを満たし、次に「服用アラーム」とはどんな機能なのかを伝え、最後に「服用アラーム」の設定をしてもらうという、ユーザーにとって自然な流れになるように改善しました。 登録導線改善後の UI 山田 : 説明も入ってちゃんとユーザーに便利な機能だということも分かってもらえるようにしたんですね。こちらの改善施策の効果はどんな感じだったんですか? 吉岡 : こちらの施策は改善の前後で 2 倍近く「服用アラーム」を設定してくれるユーザーが増えました。この改善も効果的なものになったんじゃないかと考えています。 お薬手帳改善プロジェクトで苦労した部分 山田 : お薬手帳改善プロジェクトでは PdM と二人三脚でデータを取りながら、仮説を立てて改善していくプロセスで結果に繋げていると感じたのですが、このプロジェクトで苦労した部分は何かありますか? 吉岡 : 技術的に難易度が高いという改善ではなかったのですが、個人的に苦労した点としては iOS / Android それぞれのプラットフォームで Push 通知に関する仕様が当たり前ですが全然違うので、 詳しいメンバーにアドバイスをもらいながら通知に関してキャッチアップする必要があった点が、大変 ではありました。 山田 : これまであまり Push 通知周りの実装の経験を持っていない中だと、各プラットフォームに合わせて実装するのはちょっと大変ですよね。 吉岡 : もちろん、公式ドキュメントも充実しているので、そうしたものを調べたり、最終レビューとしては各プラットフォームの知見が深いエンジニアに見てもらったりもしたので、キャッチアップもしやすくはありましたけども。 その他に ネイティブアプリの開発で必要な知識などは、当たり前ですが書籍などで勉強 などはした上で、局地的にこうした Push 通知などに取り組んだ感じではあります。 お薬手帳改善プロジェクトで学んだこと・やりがいと思ったところ 山田 : 今回の一連のプロジェクトで吉岡さんが学んだ部分として、どんなものがありましたか? 吉岡 : エンジニアリングというと、一般的な印象として難しい実装をして結果を出すという感じに思いがちですが、今回のプロジェクトの施策のように、そこまで工数をかけない実装であっても、 数字を見つつ仮説をちゃんと立てながら本質的な改善をすると結果にちゃんと結びつく んだということが、実感できたという点は大きいです。 また、今回のプロジェクトの主となる目的としては「服用アラームを使ってくれるユーザーを増やす」というものでしたが、そこに至るまでの 準備をちゃんとしておかないと結局ユーザーにとって真に使いやすいものにならない ので、こうした下準備をして丁寧に改善することの大切さというのが分かりました。 山田 : ちゃんと足場を固めて、長期的な視点も入れて改善をしていくというのは、プロダクトの価値を出す上で大事な事ですよね。それでは今回のプロジェクトでのやりがいに思った部分はどんな部分ですか? 吉岡 : ストアを見るとレビューで星 3 をつけていたユーザーの方が改善後に星 5 のレビューにしてくれているのを見たりすると**「ユーザーのために本当にやって良かったな」**と感じます。レビューだけではなく、数字は継続的に見ているので、その数字が向上しているのを観測できたら同じようにやりがいがあると思いました。 目指すエンジニア像 山田 : ここまで吉岡さんが、関わったプロジェクトについて聞いてきましたが、これからどんなエンジニアになっていきたいかという将来像はどんな風に考えているんでしょうか。 吉岡 : まずは同じチームの中の周りのエンジニアの方達を目標としたいなと思っております。具体的には他のエンジニアの皆さんの 課題解決能力の高さ を身に付けていきたいと思っています。 技術面でもプロダクト面でも、ちゃんと状況を分析して「こうすれば良いんではないか」という提案をさっとされたりしています。またその提案自体も複数出しつつ、それぞれのメリット・デメリットを提示してベストなやり方を選んでいる方ばかりなので、そうした部分を参考にしていきたいですね。 山田 : どのようにそうした能力を高めていこうと考えているんですか? 吉岡 : まずは普通に技術力を高めるというのはやっていかないといけないプロセスだとは思っています。 iOS / Android の開発もそうですし、データ構造などもちゃんと考えて実装が必要になったりする部分もあるので、サーバサイドなどもあるタイミングでちゃんとやっていきたいと考えています。 その上で、周りのエンジニアの方達と同じ考え方や、やり方を参考にしながら自身の課題に対処していく…ということを繰り返し経験していくことかなと考えています。 チームで一緒に働いていきたいエンジニア像 山田 : 最後になりますが、吉岡さんはどんなエンジニアと一緒に働いてみたいと考えていますか? 吉岡 : そうですね…。今のチームだと PdM とエンジニアが二人三脚で開発を進めていくというスタイルとなっていますので、そこで PdM が言うことだけをやるというのではなく、 ちゃんと自身の意見を持ってプロダクトをより良くしていくという意識を持っているエンジニア の方と一緒に働きたいです。 色々な施策をする上で、PdM の方とちゃんと役割分担をしつつも、最終目標としてはプロダクトを良くする。その為に PdM を含めエンジニア以外のカスタマーサポートなど他の職種の方へのリスペクトが欠かせないのではないかと思いますので、そうした事も自然とできる方が良いです。 山田 : とても大事な意識ですね。本日はありがとうございました! 最後に 新卒 2 年目ながらユーザーへの価値提供をするために、一連のプロジェクトをメインに担当している吉岡さん。インタビューをしていてメドレーの他のプロダクトのエンジニアにも通じる考え方で真摯に開発をしている様子が伺えました。 メドレーでは今回のように、データドリブンでユーザーへ価値を提供する開発をしていくネイティブアプリエンジニアも絶賛募集していますので、ご興味がある方はぜひカジュアルにお話からしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。メドレーでは医療プラットフォームで患者が使う「CLINICS」アプリを iOS / Android / Web で開発・運営しています。日々、患者が便利に使えるように改善をしていますが、特徴として エンジニアがプロダクトマネージャー(以下、PdM)と一緒に数値を見ながら、改善を行なっている という点が挙げられます。 今回は「CLINICS」アプリを開発している吉岡さんに、どのような開発フローで改善を行なっているのかをインタビューしてみました。 自己紹介 吉岡さん 医療 PF プロダクト開発室第一開発グループグロースチームにて患者向けアプリ「CLINICS」の開発業務を担当。主に薬局に関する機能開発を行っている。大学の専攻は物理で、大学途中からプログラミングを始めた。その後、 大学 4 年から長期インターンで開発に取り組み、Ruby on Rails や React.js など主に Web 開発を経験したあと 2022 年に新卒でメドレー入社。 吉岡さん メドレーに入社した理由 メドレーに入社するまでの経歴 山田 : よろしくお願いします。早速ですが、学生時代からメドレーに入社するまでの経歴をお話いただけますか? 吉岡 : 学生時代は物理学を専攻していましたが、途中からプログラミングを始めました。そのまま Web 開発をしている企業で長期インターンをして Ruby on Rails(以下、RoR) や React.js を使った開発経験を経てメドレーに入社しました。 山田 : 物理学を専攻していたということですが、授業でプログラミングをしていたんですか? 吉岡 : いえ、コロナ禍に入り、ちょうど予定していたオーロラ観察のためのフィンランド行きが無くなってしまったということがありまして。予定が無くなり 時間ができたので「何か始めてみよう」ということでプログラミングを始めた というのが最初のきっかけでした。プログラミング自体は前から気になっていたので、手を出してみたという次第です。 山田 : そうだったんですね! ではコロナ禍にならずに旅行に行くことになっていたら…。 吉岡 : はい、プログラミングしておらず入社もしていなかったかもしれないです(笑) なぜメドレーに入社しようと思ったのか 山田 : そんな吉岡さんは、どうしてメドレーに入社を決めたんですか? 吉岡 : まず最初にメドレーの「医療ヘルスケアの未来をつくる」という ミッションに共感したというのが大きい要因 です。また プロダクトファーストな考え方をしつつ、プロダクト開発への取り組み方が長期で課題に対してじっくりとアプローチ をするという姿勢がとても良いと感じたのも理由になります。 山田 : 入社前に受けた印象と実際に入社後に感じた印象のギャップなどはありますか? 吉岡 : プロダクト開発に関しては特に感じてはいないです。技術スタックについては入社前には RoR と React.js という Web アプリの技術スタックを自分は持っていたので、入社後もその部分のギャップはないかな?と思って入社したのですが、今の配属は患者アプリということで iOS / Android のネイティブアプリの技術に触ることにもなるので、そこの部分がギャップといえばギャップになります。 山田 : 入社前は Web エンジニアとしてだけ業務すると思っていたけど、入ったらネイティブアプリエンジニアとしての業務もあったという話ですね(笑) 吉岡 : そうなりますね(笑) ただ、 iOS / Android を触っていくうちに新しい技術に対する自分のキャッチアップ力には自信が付きました 。「初見の iOS ・ Android でもキャッチアップして開発できたから、他の未知領域もキャッチアップしていけるだろう」という感覚が強くなりましたね。 取り組んでいる業務について 山田 : それでは吉岡さんは現在のチームでどのような業務を担当しているか、聞かせてください。 吉岡 : はい。自分は患者アプリの開発を担当しています。患者さんの日々の通院や服薬を助けるということを目的として、オンライン診療・薬局への処方箋送付・お薬手帳などがこの患者アプリに含まれている機能になります。チームとしては自分は「グロースチーム」というチームに所属しています。主に既存機能の UI / UX の改善であったり、お薬手帳など患者が日常的にアプリを使ってもらえるような機能開発を担当しています。 チーム構成としてはデザイナー兼 PdM 1 人・ PdM 1 人・エンジニアが自分を含め 3 人という構成になっています。施策の規模によるのですが、小さいものであれば 1 人で iOS / Android / Web の 3 プラットフォームを開発しますし、ある程度の規模の施策であれば、それぞれ 1 プラットフォームずつエンジニアがアサインされて開発するようになっています。PdM の方はそれぞれの施策につき 1 人で担当されていることが多いです。 エンジニアはそれぞれ得意としているプラットフォームが分かれているので、プルリクエストを適宜レビューしてもらったり、不明な部分を質問したりという感じで開発していきます。 チームの定例は、毎日 30 分の夕会があり、そこで困り事があったら相談したり、共有するべき事を話したりという感じでやっています。その他は適宜、施策のキックオフだったり、自分が分からないことがあったりしたら周りに聞いたりということはしています。 お薬手帳改善プロジェクト お薬手帳とは、どんな機能か 山田 : ありがとうございます。では、本題となりますが、吉岡さんは「お薬手帳改善プロジェクト」というプロジェクトのメインのエンジニアとして担当をされていたということで、そちらのお話を聞いていきたいと思います。まず前提として「お薬手帳」の機能はどんなものなんでしょうか。 吉岡 : 皆さんも調剤薬局に行くと「お薬手帳をお持ちですか」と聞かれると思いますが、 その機能をアプリ化して便利 にしたものになります。 例えば、今まで自分が服用してきた薬についての履歴を参照できるようになります。また単に履歴だけではなく、服用した薬の副作用やアレルギー歴なども記録できるので、自分に合わない薬などを避け処方してもらえるようになるものです。この機能は調剤薬局で処方される薬だけではなく、市販薬についても記録できます。 また、患者アプリでのお薬手帳は QR コードで処方された薬を登録できるという機能と、薬の飲み忘れを防ぐため服用時間に通知を端末に送付する「服用アラーム」という機能も存在しています。 山田 : なるほど。では「お薬手帳改善プロジェクト」はどのような事を目的としていたプロジェクトだったんでしょうか。 吉岡 : 全体の目的として**「お薬手帳」機能を日常的に使っていただく患者数を増加させるために、UX の向上**を目指していました。私が担当した施策は、その中でも薬の飲み忘れを防止するための「服用アラーム」は使っていただいている患者の割合が低かったため、こちらの機能をもっと使ってもらうように改善すれば、必然的に日常的に「患者アプリ」を使う患者数も増えるだろうという背景のもと行われました。 既存の「服用アラーム」の課題 山田 : 「服用アラーム」はもともとそれ程には使われていない機能だったんですか? 吉岡 : もちろん使っていただいている患者数としては一定数いらっしゃったんですが、期待しているほどには多くなかったという感じでした。そこで使っていただけていない理由や背景を PdM が事前に分析などした結果として以下のような課題が浮き彫り になってきました。 そもそも「服用アラーム」機能を知らなかった 知っていても「服用アラーム」機能の使い方が分からない 「服用アラーム」機能を設定していても通知が届かない場合があった そこで、これらの課題を整理して以下のような順番で改善を行なっていくことにしました。 服用アラーム設定の UI 改善 服用アラームの通知が届かない問題の解消 お薬登録から服用アラームの登録導線の改善 こうして、課題から実装方針までをまず決めていきました。 服用アラーム設定の UI 改善 山田 : 方針の内、最初の服用アラーム設定の UI 改善はどのように行なっていったんでしょうか。 吉岡 : まず、PdM が主体となりユーザーインタビューを行なった結果や、ユーザーサポートの問い合わせ傾向の分析をした結果、 服用アラーム設定の画面でこちらが意図した通りに使ってもらえていないという事実が分かりました 。UI 上でユーザーに少し混乱を招いてしまっていました。 そこで、その概念や設定フローを整理して UI に反映させて、混乱を少なくするように改善を行ないました。 山田 : ちゃんとこちらの概念が正しく UI に反映するようにしたということですね。 服用アラームの通知が届かない問題の解消 吉岡 : はい。これでまず設定が正しくできないという状態が解消されたので、次のステップに進むことにしました。次は正しく設定しているのにも関わらず、一部のユーザーに通知が設定通りに来ない場合があったのを解消しました。こちらの方で特にエラーなどは検知できなかったので、 PdM と仮説を立てて検証 していきました。 山田 : なるほど。どのような仮説だったんですか? 吉岡 : そもそもユーザーが Push 通知を実はオンにしていないのではないかという仮説です。そこで、仮説検証のためまずデータを取って実際どの位のユーザーが Push 通知をオンにしているかを調査したのですが、予想以上に多くのユーザーが Push 通知をオンにしていませんでした。仮説が正しいものだと証明されたので、 Push 通知の許諾を促すための改善を行ないました 。この施策の結果として 2 倍以上のユーザーが Push 通知をオンにしてくれたので、 「服用アラーム」の通知が届かないという問い合わせが減少 しました。 山田 : かなり効果的な施策になったようですね。工数的にはそこまでかからずに実現できたんですか? 吉岡 : はい、工数はあまりかかってないので、結果を見るとコストパフォーマンスが良い施策になったと思います。 服用アラームの登録導線の改善 吉岡 : ここまでで、下準備が整ったので「服用アラーム」自体を実際にさらにユーザーに使ってもらうための施策として、登録までの導線を改善することにしました。今まではお薬を登録するか、お薬と服用アラームを同時に登録するか選べたのですが、お薬手帳への薬の登録後に「服用アラーム」の設定を促す導線を表示するように改善しました。理由としては、 薬の登録をしてから「服用アラーム」の登録をしたユーザーの割合を調べてみたところ、大多数のユーザーが設定をしていなかったことが分かった からです。 山田 : かなりの方が「服用アラーム」を設定せずにいたのは驚きですね。ユーザーはなぜ設定していなかったんですか? 吉岡 : 改善以前の UI では、薬を登録をするためのボタンがあり、その下に「服用アラーム」設定ボタンが並列で設置されていました。 開発側としては、お薬登録と同時に服用アラームを設定する導線がユーザーには分かりやすいだろうと考えていました。しかし、フタを開けてみると登録数が増えないことになっていました。 良く考えると 当たり前だったんですが、開発側としてみれば「服用アラーム」という名前の機能については自明で「こういう動きをする機能だろう」というのが分かった上で、導線として認識していたんです。しかし、ユーザー側の視点とすると最初にこの画面を見て思うことは「服用アラームってなんなんだろう?」という疑問で、「良く分からないからお薬の登録だけしよう」という心理になってしまっていたようなんです。 登録導線改善前の UI 山田 : 確かに説明がないまま「服用アラーム」と言われると、まずは「何だこれ?」となりそうです。それでは、どんな改善を行なって、この課題に対処したんですか? 吉岡 : 先程もお話した、薬の登録から「服用アラーム」設定までのデータを PdM と一緒に検討した結果、一番多くアラームの設定をしてもらえるパターンとしては薬の登録をしたのと同時に設定しているということが分かりました。 ですので、 導線は今までの「薬の登録」+「服用アラーム」ではなく「薬の登録」→「服用アラームの説明と設定」という形に変更 しました。この改善によって、まずは薬の登録をしたいというニーズを満たし、次に「服用アラーム」とはどんな機能なのかを伝え、最後に「服用アラーム」の設定をしてもらうという、ユーザーにとって自然な流れになるように改善しました。 登録導線改善後の UI 山田 : 説明も入ってちゃんとユーザーに便利な機能だということも分かってもらえるようにしたんですね。こちらの改善施策の効果はどんな感じだったんですか? 吉岡 : こちらの施策は改善の前後で 2 倍近く「服用アラーム」を設定してくれるユーザーが増えました。この改善も効果的なものになったんじゃないかと考えています。 お薬手帳改善プロジェクトで苦労した部分 山田 : お薬手帳改善プロジェクトでは PdM と二人三脚でデータを取りながら、仮説を立てて改善していくプロセスで結果に繋げていると感じたのですが、このプロジェクトで苦労した部分は何かありますか? 吉岡 : 技術的に難易度が高いという改善ではなかったのですが、個人的に苦労した点としては iOS / Android それぞれのプラットフォームで Push 通知に関する仕様が当たり前ですが全然違うので、 詳しいメンバーにアドバイスをもらいながら通知に関してキャッチアップする必要があった点が、大変 ではありました。 山田 : これまであまり Push 通知周りの実装の経験を持っていない中だと、各プラットフォームに合わせて実装するのはちょっと大変ですよね。 吉岡 : もちろん、公式ドキュメントも充実しているので、そうしたものを調べたり、最終レビューとしては各プラットフォームの知見が深いエンジニアに見てもらったりもしたので、キャッチアップもしやすくはありましたけども。 その他に ネイティブアプリの開発で必要な知識などは、当たり前ですが書籍などで勉強 などはした上で、局地的にこうした Push 通知などに取り組んだ感じではあります。 お薬手帳改善プロジェクトで学んだこと・やりがいと思ったところ 山田 : 今回の一連のプロジェクトで吉岡さんが学んだ部分として、どんなものがありましたか? 吉岡 : エンジニアリングというと、一般的な印象として難しい実装をして結果を出すという感じに思いがちですが、今回のプロジェクトの施策のように、そこまで工数をかけない実装であっても、 数字を見つつ仮説をちゃんと立てながら本質的な改善をすると結果にちゃんと結びつく んだということが、実感できたという点は大きいです。 また、今回のプロジェクトの主となる目的としては「服用アラームを使ってくれるユーザーを増やす」というものでしたが、そこに至るまでの 準備をちゃんとしておかないと結局ユーザーにとって真に使いやすいものにならない ので、こうした下準備をして丁寧に改善することの大切さというのが分かりました。 山田 : ちゃんと足場を固めて、長期的な視点も入れて改善をしていくというのは、プロダクトの価値を出す上で大事な事ですよね。それでは今回のプロジェクトでのやりがいに思った部分はどんな部分ですか? 吉岡 : ストアを見るとレビューで星 3 をつけていたユーザーの方が改善後に星 5 のレビューにしてくれているのを見たりすると**「ユーザーのために本当にやって良かったな」**と感じます。レビューだけではなく、数字は継続的に見ているので、その数字が向上しているのを観測できたら同じようにやりがいがあると思いました。 目指すエンジニア像 山田 : ここまで吉岡さんが、関わったプロジェクトについて聞いてきましたが、これからどんなエンジニアになっていきたいかという将来像はどんな風に考えているんでしょうか。 吉岡 : まずは同じチームの中の周りのエンジニアの方達を目標としたいなと思っております。具体的には他のエンジニアの皆さんの 課題解決能力の高さ を身に付けていきたいと思っています。 技術面でもプロダクト面でも、ちゃんと状況を分析して「こうすれば良いんではないか」という提案をさっとされたりしています。またその提案自体も複数出しつつ、それぞれのメリット・デメリットを提示してベストなやり方を選んでいる方ばかりなので、そうした部分を参考にしていきたいですね。 山田 : どのようにそうした能力を高めていこうと考えているんですか? 吉岡 : まずは普通に技術力を高めるというのはやっていかないといけないプロセスだとは思っています。 iOS / Android の開発もそうですし、データ構造などもちゃんと考えて実装が必要になったりする部分もあるので、サーバサイドなどもあるタイミングでちゃんとやっていきたいと考えています。 その上で、周りのエンジニアの方達と同じ考え方や、やり方を参考にしながら自身の課題に対処していく…ということを繰り返し経験していくことかなと考えています。 チームで一緒に働いていきたいエンジニア像 山田 : 最後になりますが、吉岡さんはどんなエンジニアと一緒に働いてみたいと考えていますか? 吉岡 : そうですね…。今のチームだと PdM とエンジニアが二人三脚で開発を進めていくというスタイルとなっていますので、そこで PdM が言うことだけをやるというのではなく、 ちゃんと自身の意見を持ってプロダクトをより良くしていくという意識を持っているエンジニア の方と一緒に働きたいです。 色々な施策をする上で、PdM の方とちゃんと役割分担をしつつも、最終目標としてはプロダクトを良くする。その為に PdM を含めエンジニア以外のカスタマーサポートなど他の職種の方へのリスペクトが欠かせないのではないかと思いますので、そうした事も自然とできる方が良いです。 山田 : とても大事な意識ですね。本日はありがとうございました! 最後に 新卒 2 年目ながらユーザーへの価値提供をするために、一連のプロジェクトをメインに担当している吉岡さん。インタビューをしていてメドレーの他のプロダクトのエンジニアにも通じる考え方で真摯に開発をしている様子が伺えました。 メドレーでは今回のように、データドリブンでユーザーへ価値を提供する開発をしていくネイティブアプリエンジニアも絶賛募集していますので、ご興味がある方はぜひカジュアルにお話からしましょう。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 人材プラットフォーム本部プロダクト開発室第一開発グループの阪本です。 毎日夕方になっても 30 度を超えるような猛暑が続く中、皆さんはいかがお過ごしでしょうか？ 今まで何度も紹介させていただきましたが、私は阪神タイガースのファンです。 今年は第二次岡田政権の 1 年目、開幕からの好調を維持し交流戦までは首位独走。交流戦明けに一時的に首位を明け渡す事態になりましたが、8 月に入り破竹の 2 桁連勝で首位奪還どころか独走状態という最高のシーズンを迎えております。 投手は元々良いチームではありましたが、今年は課題であった守備と出塁率に改善が見られ 普通にやれば勝てる チームに近づいたというのが大きいのではないでしょうか。 この記事が公開される頃には優勝マジックが点灯し、18 年振りの「あれ」まで秒読みとなっていることでしょう。待ちに待ったその瞬間まで、あと少しです。 さて、現在私は SRE Unit リーダの立場で主に ジョブメドレー の安定稼働に向けた取り組みに日々取り組んでいます。 今回はチーム内で抱える課題と、それを解決するための取り組みについて紹介させていただきます。 SRE Unit が取り組んでいる課題 SRE Unit の業務は 運用/メンテナンス 障害対応 アカウント管理 環境整備 と多岐に渡り、ジョブメドレーを含めた大小 5 システムを対象として 4 名のメンバーで推進しています。 この中でも最近の SRE Unit での業務の大半を占めるものがリソースのバージョン追従対応ですが、明確な期限が存在する上に対象システム/リソースは多いといった特徴があるため、計画的に行動しないと突発業務が発生した際に期限内の対応が困難になります。 特に AWS といったマネージドサービス系はアップデートが強制的にスケジューリングされるため、こちら側の都合を挟む余地はありません。 こういった事態にならないために行なっている SRE Unit での この先に何が起こるのか？ という「予測/計画」と、 計画を阻害する要因 となる「突発作業の削減」の 2 軸の取り組みについて紹介します。 バージョン追従対応とは？ まずは前情報としてバージョン追従作業というものがどういったものなのかを説明します。 これはシステムが利用しているサーバ/データベースといったリソースのサポート期限終了 (EOL:End Of Life) までに最新バージョンに引き上げることを指します。 EOL を迎えたリソースは公式でのサポート終了を意味するものであるため、以降発生するバグや脆弱性に対しての修正対応が期待できない状態になります。 バージョンアップ対応を行わない場合、運良くバグや脆弱性の問題が発生しなければソフトウェア的に動作の継続は可能ですが、これに関連するライブラリなども古いバージョンのサポートを切るタイミングが出てくるので遅かれ早かれ影響は出てきます。 また AWS のマネージドサービス (ex.RDS/ElastiCache/OpenSearch) では、サポート期限の終了に伴い強制的に最新バージョンへの更新がスケジュールされます。 「最新バージョンへと更新してくれる」、その言葉だけ見ると素晴らしいものですが、もちろん更新中に発生するダウンタイムや接続するアプリケーションに対する影響まで面倒は見てくれません。 そのため、マネージドだろうが非マネージドだろうがバージョンアップ対応は必ず行う必要があると言うことです。 作業の内容 この作業は単純にリソースのバージョンアップをするだけで済む作業ではありません。 前述でのダウンタイムやバージョン間による変更差分によりアプリケーションが今まで通り動いているかを保証する必要があるため、下記をセットで実施することでシステム稼働を担保しています。 新旧バージョンの変更履歴を把握 変更によるアプリケーション影響の把握 アプリケーションの動作チェック 負荷チェック 移行計画の策定 移行作業の実施 取り組み 1.予測/計画 これらの作業は決して少ない工数では無く、システムやリソースの増加に伴って作業量も増えていく一方です。 AWS であれば EOL 通知はメール等で行われるため今までは通知が来てから計画を立てるというフローを採っていましたが、対象システムの増加に伴うリソース増により上記内容を期限内に消化するのが困難になってきています。 さらに RDS for MySQL に関してはバージョンあたりのサポート期限が短縮傾向にあるため、一度バージョンを上げればこの先数年は安泰といった状態でも無くなってきています。 この状態を踏まえて、2023 年からは通知が来る前に先手を打つ方針に切り替えました。 いつ何が起きるのか？（どれがいつ EOL を迎えるのか？）を事前に把握し、それを元に逆算し計画をすることで無駄の無い行動を目指すというものです。 対象リソースのリストアップ まずは各システムが利用するリソースのバージョンと EOL をリストアップし、自分たちが抱えるシステムとリソースの全量とそれらのバージョンがどういった状態なのかを把握します。 ここから各バージョンの EOL 時期を収集することになるのですが、幸いバージョン EOL については個々の公式サイトで明記されていることが多いので把握はそれほど難しくはありませんでした。 ex.) Ruby Java AWS RDS/MySQL AWS といったマネージドサービスに対しては公式の EOL と必ずしもイコールにはなりませんが、マネージドサービス側が公式 EOL より期限が早いことは無いので、公式 EOL を期限として考えるようにしています。 また公式サイトが見つからない/明記されていないといったものが稀にあり、それらは endoflife.date というサイトを活用しました。 優先度の決定 リストアップした時点でかなりの量に及ぶため、ここから対応優先度を決定します。 最優先とすべきポイントとしては、期限を迎えると強制的にバージョンアップされてしまうマネージドサービス系のリソースです。 これらについては切られた期限に対する猶予は基本与えられないため、優先度が一番高いものと考えます。 次点として EC2 に自前でインストールするようなリソースが続きます。これは最悪 EOL を迎えても動作は継続できるため、上記よりは優先度を下げています。 後はこれらの 優先度/EOL の 2 軸で対応順を検討し、2023 年の年間スケジュールに落とし込みました。 効果 2023 年 8 月の時点で、AWS のマネージドサービス系のリソースについては通知を受ける前にバージョン追従作業を済ませることができています。 特に 2023 年 10 月に EOL を迎える RDS の MySQL5.7 → MySQL8.0 対応は大変大きな規模の作業になりましたが、対象 4 サービス、DB インスタンス十数台を 2023 年 7 月に無事すべて切り替えることができました。 途中 AWS では OpenSearch や ElastiCache の緊急セキュリティアップデート対応が突発で入りましたが、全ての計画において先手というバッファを見込んでいたため予定を大きく狂わせず完了することができています。 取り組み 2.突発作業の削減 先程は計画を立てて無駄のない行動を目指すことを目的としていましたが、どれだけ予測や計画の精度を上げた所で突発作業はどうしても発生します。 社内からの要因であれば対処の仕方もありますが、外部要因となると予測も対応も困難であるものが多くなります。 特に「何も変更していないのに急に動かなくなった！」が一番脅威で、OS 仕様変更や外部ライブラリの廃止に伴うものがチームの実績として多く感じています。 こういった外部要因による事象を発生させにくい状態にするため、以下の対策を行っています。 PrivateGem サーバの構築 ジョブメドレーは Ruby で動くアプリケーションですが、外部ライブラリとして多数の Gem を併用しています。 この Gem がある日突然リポジトリから削除され bundle install が通らず起動しない、といったことが稀にありました。 バージョンアップで対応できるものであればまだ良いのですが、そもそも廃止といった状況だと対応の長期化は必至。 そういった事態を避けるため Geminabox にて PrivateGem サーバを構築しました。 このサーバは RubyGems 向けの Proxy/キャッシュサーバ という位置づけで、このサーバ経由で RubyGems に Gem を取得すると同時にサーバ内にも Gem はキャッシュします。 キャッシュされた Gem については以降 RubyGems に再度取りに行くことは無いため、RubyGems 上で取得できない事態が発生しても喫緊の対応が必要な状況にはなりません。 動作環境の Docker イメージ化 とある Python によるプログラムを対象としているのですが OS/Python バージョン/Pip ライブラリ の兼ね合いがとても厳しく、少しでもバージョンにズレが生じると動作不良を起こし対応に回るといったことが年〜半年に一度発生していました。 動作環境としては プログラム開始時に EC2 起動 コードのダウンロード ライブラリのインストール プログラム実行 プログラム終了後に EC2 停止 という形態を取っていましたが、それぞれのステップに於いて毎度同じ環境になる保証がない状態というのが大きな課題でした。 具体的には EC2 の起動時は Amazon Linux 2 の仕様で Python のバージョンが変わって動かない、ライブラリのインストールではバージョン固定が甘くある日バージョンが変わって動かなくなる、といったことが起こる再現性の低い仕組みで組まれている状態です。 そこで、毎回同じ動作環境を維持するための取り組みとして Docker イメージによる環境の固定化を行いました。 これは Docker イメージによって OS を固定した上でイメージ内にコード/ライブラリまでを含めてしまうもので、OS 起動からプログラムの起動まですべて同じ状態になるようにしました。 また副産物としてプログラム起動までのステップが短縮され、プログラム起動までのオーバヘッドの短縮にも繋げることができました。 効果 双方の仕組みの導入により、今年は対象システム回りでの突発作業は発生しない状態を維持できています。 最後に 今回は SRE Unit の業務の一つであるバージョン追従対応についてフォーカスを当てて紹介しましたが、抱える業務は他にも多数あります。 我々 SRE Unit の目的はサイトの安定稼働/信頼性を維持することであり、今回のようなバージョンアップはその中の一部でしかありません。この他にも負荷の監視やパフォーマンスチューニング、障害対応などを取り組むべきことは山ほどあります。 まだチームの人数は決して多くは無いこの現状で、いかにアイデア/技術/仕組み化によって効率的に動けるか切磋琢磨し、より安定したサービスを提供できるように日々取り組んでいます。 もしこれらの取り組みに興味のある方は、是非我々と一緒に働きませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 人材プラットフォーム本部プロダクト開発室第一開発グループの阪本です。 毎日夕方になっても 30 度を超えるような猛暑が続く中、皆さんはいかがお過ごしでしょうか？ 今まで何度も紹介させていただきましたが、私は阪神タイガースのファンです。 今年は第二次岡田政権の 1 年目、開幕からの好調を維持し交流戦までは首位独走。交流戦明けに一時的に首位を明け渡す事態になりましたが、8 月に入り破竹の 2 桁連勝で首位奪還どころか独走状態という最高のシーズンを迎えております。 投手は元々良いチームではありましたが、今年は課題であった守備と出塁率に改善が見られ 普通にやれば勝てる チームに近づいたというのが大きいのではないでしょうか。 この記事が公開される頃には優勝マジックが点灯し、18 年振りの「あれ」まで秒読みとなっていることでしょう。待ちに待ったその瞬間まで、あと少しです。 さて、現在私は SRE Unit リーダの立場で主に ジョブメドレー の安定稼働に向けた取り組みに日々取り組んでいます。 今回はチーム内で抱える課題と、それを解決するための取り組みについて紹介させていただきます。 SRE Unit が取り組んでいる課題 SRE Unit の業務は 運用/メンテナンス 障害対応 アカウント管理 環境整備 と多岐に渡り、ジョブメドレーを含めた大小 5 システムを対象として 4 名のメンバーで推進しています。 この中でも最近の SRE Unit での業務の大半を占めるものがリソースのバージョン追従対応ですが、明確な期限が存在する上に対象システム/リソースは多いといった特徴があるため、計画的に行動しないと突発業務が発生した際に期限内の対応が困難になります。 特に AWS といったマネージドサービス系はアップデートが強制的にスケジューリングされるため、こちら側の都合を挟む余地はありません。 こういった事態にならないために行なっている SRE Unit での この先に何が起こるのか？ という「予測/計画」と、 計画を阻害する要因 となる「突発作業の削減」の 2 軸の取り組みについて紹介します。 バージョン追従対応とは？ まずは前情報としてバージョン追従作業というものがどういったものなのかを説明します。 これはシステムが利用しているサーバ/データベースといったリソースのサポート期限終了 (EOL:End Of Life) までに最新バージョンに引き上げることを指します。 EOL を迎えたリソースは公式でのサポート終了を意味するものであるため、以降発生するバグや脆弱性に対しての修正対応が期待できない状態になります。 バージョンアップ対応を行わない場合、運良くバグや脆弱性の問題が発生しなければソフトウェア的に動作の継続は可能ですが、これに関連するライブラリなども古いバージョンのサポートを切るタイミングが出てくるので遅かれ早かれ影響は出てきます。 また AWS のマネージドサービス (ex.RDS/ElastiCache/OpenSearch) では、サポート期限の終了に伴い強制的に最新バージョンへの更新がスケジュールされます。 「最新バージョンへと更新してくれる」、その言葉だけ見ると素晴らしいものですが、もちろん更新中に発生するダウンタイムや接続するアプリケーションに対する影響まで面倒は見てくれません。 そのため、マネージドだろうが非マネージドだろうがバージョンアップ対応は必ず行う必要があると言うことです。 作業の内容 この作業は単純にリソースのバージョンアップをするだけで済む作業ではありません。 前述でのダウンタイムやバージョン間による変更差分によりアプリケーションが今まで通り動いているかを保証する必要があるため、下記をセットで実施することでシステム稼働を担保しています。 新旧バージョンの変更履歴を把握 変更によるアプリケーション影響の把握 アプリケーションの動作チェック 負荷チェック 移行計画の策定 移行作業の実施 取り組み 1.予測/計画 これらの作業は決して少ない工数では無く、システムやリソースの増加に伴って作業量も増えていく一方です。 AWS であれば EOL 通知はメール等で行われるため今までは通知が来てから計画を立てるというフローを採っていましたが、対象システムの増加に伴うリソース増により上記内容を期限内に消化するのが困難になってきています。 さらに RDS for MySQL に関してはバージョンあたりのサポート期限が短縮傾向にあるため、一度バージョンを上げればこの先数年は安泰といった状態でも無くなってきています。 この状態を踏まえて、2023 年からは通知が来る前に先手を打つ方針に切り替えました。 いつ何が起きるのか？（どれがいつ EOL を迎えるのか？）を事前に把握し、それを元に逆算し計画をすることで無駄の無い行動を目指すというものです。 対象リソースのリストアップ まずは各システムが利用するリソースのバージョンと EOL をリストアップし、自分たちが抱えるシステムとリソースの全量とそれらのバージョンがどういった状態なのかを把握します。 ここから各バージョンの EOL 時期を収集することになるのですが、幸いバージョン EOL については個々の公式サイトで明記されていることが多いので把握はそれほど難しくはありませんでした。 ex.) Ruby Java AWS RDS/MySQL AWS といったマネージドサービスに対しては公式の EOL と必ずしもイコールにはなりませんが、マネージドサービス側が公式 EOL より期限が早いことは無いので、公式 EOL を期限として考えるようにしています。 また公式サイトが見つからない/明記されていないといったものが稀にあり、それらは endoflife.date というサイトを活用しました。 優先度の決定 リストアップした時点でかなりの量に及ぶため、ここから対応優先度を決定します。 最優先とすべきポイントとしては、期限を迎えると強制的にバージョンアップされてしまうマネージドサービス系のリソースです。 これらについては切られた期限に対する猶予は基本与えられないため、優先度が一番高いものと考えます。 次点として EC2 に自前でインストールするようなリソースが続きます。これは最悪 EOL を迎えても動作は継続できるため、上記よりは優先度を下げています。 後はこれらの 優先度/EOL の 2 軸で対応順を検討し、2023 年の年間スケジュールに落とし込みました。 効果 2023 年 8 月の時点で、AWS のマネージドサービス系のリソースについては通知を受ける前にバージョン追従作業を済ませることができています。 特に 2023 年 10 月に EOL を迎える RDS の MySQL5.7 → MySQL8.0 対応は大変大きな規模の作業になりましたが、対象 4 サービス、DB インスタンス十数台を 2023 年 7 月に無事すべて切り替えることができました。 途中 AWS では OpenSearch や ElastiCache の緊急セキュリティアップデート対応が突発で入りましたが、全ての計画において先手というバッファを見込んでいたため予定を大きく狂わせず完了することができています。 取り組み 2.突発作業の削減 先程は計画を立てて無駄のない行動を目指すことを目的としていましたが、どれだけ予測や計画の精度を上げた所で突発作業はどうしても発生します。 社内からの要因であれば対処の仕方もありますが、外部要因となると予測も対応も困難であるものが多くなります。 特に「何も変更していないのに急に動かなくなった！」が一番脅威で、OS 仕様変更や外部ライブラリの廃止に伴うものがチームの実績として多く感じています。 こういった外部要因による事象を発生させにくい状態にするため、以下の対策を行っています。 PrivateGem サーバの構築 ジョブメドレーは Ruby で動くアプリケーションですが、外部ライブラリとして多数の Gem を併用しています。 この Gem がある日突然リポジトリから削除され bundle install が通らず起動しない、といったことが稀にありました。 バージョンアップで対応できるものであればまだ良いのですが、そもそも廃止といった状況だと対応の長期化は必至。 そういった事態を避けるため Geminabox にて PrivateGem サーバを構築しました。 このサーバは RubyGems 向けの Proxy/キャッシュサーバ という位置づけで、このサーバ経由で RubyGems に Gem を取得すると同時にサーバ内にも Gem はキャッシュします。 キャッシュされた Gem については以降 RubyGems に再度取りに行くことは無いため、RubyGems 上で取得できない事態が発生しても喫緊の対応が必要な状況にはなりません。 動作環境の Docker イメージ化 とある Python によるプログラムを対象としているのですが OS/Python バージョン/Pip ライブラリ の兼ね合いがとても厳しく、少しでもバージョンにズレが生じると動作不良を起こし対応に回るといったことが年〜半年に一度発生していました。 動作環境としては プログラム開始時に EC2 起動 コードのダウンロード ライブラリのインストール プログラム実行 プログラム終了後に EC2 停止 という形態を取っていましたが、それぞれのステップに於いて毎度同じ環境になる保証がない状態というのが大きな課題でした。 具体的には EC2 の起動時は Amazon Linux 2 の仕様で Python のバージョンが変わって動かない、ライブラリのインストールではバージョン固定が甘くある日バージョンが変わって動かなくなる、といったことが起こる再現性の低い仕組みで組まれている状態です。 そこで、毎回同じ動作環境を維持するための取り組みとして Docker イメージによる環境の固定化を行いました。 これは Docker イメージによって OS を固定した上でイメージ内にコード/ライブラリまでを含めてしまうもので、OS 起動からプログラムの起動まですべて同じ状態になるようにしました。 また副産物としてプログラム起動までのステップが短縮され、プログラム起動までのオーバヘッドの短縮にも繋げることができました。 効果 双方の仕組みの導入により、今年は対象システム回りでの突発作業は発生しない状態を維持できています。 最後に 今回は SRE Unit の業務の一つであるバージョン追従対応についてフォーカスを当てて紹介しましたが、抱える業務は他にも多数あります。 我々 SRE Unit の目的はサイトの安定稼働/信頼性を維持することであり、今回のようなバージョンアップはその中の一部でしかありません。この他にも負荷の監視やパフォーマンスチューニング、障害対応などを取り組むべきことは山ほどあります。 まだチームの人数は決して多くは無いこの現状で、いかにアイデア/技術/仕組み化によって効率的に動けるか切磋琢磨し、より安定したサービスを提供できるように日々取り組んでいます。 もしこれらの取り組みに興味のある方は、是非我々と一緒に働きませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 人材プラットフォーム本部プロダクト開発室第一開発グループの阪本です。 毎日夕方になっても 30 度を超えるような猛暑が続く中、皆さんはいかがお過ごしでしょうか？ 今まで何度も紹介させていただきましたが、私は阪神タイガースのファンです。 今年は第二次岡田政権の 1 年目、開幕からの好調を維持し交流戦までは首位独走。交流戦明けに一時的に首位を明け渡す事態になりましたが、8 月に入り破竹の 2 桁連勝で首位奪還どころか独走状態という最高のシーズンを迎えております。 投手は元々良いチームではありましたが、今年は課題であった守備と出塁率に改善が見られ 普通にやれば勝てる チームに近づいたというのが大きいのではないでしょうか。 この記事が公開される頃には優勝マジックが点灯し、18 年振りの「あれ」まで秒読みとなっていることでしょう。待ちに待ったその瞬間まで、あと少しです。 さて、現在私は SRE Unit リーダの立場で主に ジョブメドレー の安定稼働に向けた取り組みに日々取り組んでいます。 今回はチーム内で抱える課題と、それを解決するための取り組みについて紹介させていただきます。 SRE Unit が取り組んでいる課題 SRE Unit の業務は 運用/メンテナンス 障害対応 アカウント管理 環境整備 と多岐に渡り、ジョブメドレーを含めた大小 5 システムを対象として 4 名のメンバーで推進しています。 この中でも最近の SRE Unit での業務の大半を占めるものがリソースのバージョン追従対応ですが、明確な期限が存在する上に対象システム/リソースは多いといった特徴があるため、計画的に行動しないと突発業務が発生した際に期限内の対応が困難になります。 特に AWS といったマネージドサービス系はアップデートが強制的にスケジューリングされるため、こちら側の都合を挟む余地はありません。 こういった事態にならないために行なっている SRE Unit での この先に何が起こるのか？ という「予測/計画」と、 計画を阻害する要因 となる「突発作業の削減」の 2 軸の取り組みについて紹介します。 バージョン追従対応とは？ まずは前情報としてバージョン追従作業というものがどういったものなのかを説明します。 これはシステムが利用しているサーバ/データベースといったリソースのサポート期限終了 (EOL:End Of Life) までに最新バージョンに引き上げることを指します。 EOL を迎えたリソースは公式でのサポート終了を意味するものであるため、以降発生するバグや脆弱性に対しての修正対応が期待できない状態になります。 バージョンアップ対応を行わない場合、運良くバグや脆弱性の問題が発生しなければソフトウェア的に動作の継続は可能ですが、これに関連するライブラリなども古いバージョンのサポートを切るタイミングが出てくるので遅かれ早かれ影響は出てきます。 また AWS のマネージドサービス (ex.RDS/ElastiCache/OpenSearch) では、サポート期限の終了に伴い強制的に最新バージョンへの更新がスケジュールされます。 「最新バージョンへと更新してくれる」、その言葉だけ見ると素晴らしいものですが、もちろん更新中に発生するダウンタイムや接続するアプリケーションに対する影響まで面倒は見てくれません。 そのため、マネージドだろうが非マネージドだろうがバージョンアップ対応は必ず行う必要があると言うことです。 作業の内容 この作業は単純にリソースのバージョンアップをするだけで済む作業ではありません。 前述でのダウンタイムやバージョン間による変更差分によりアプリケーションが今まで通り動いているかを保証する必要があるため、下記をセットで実施することでシステム稼働を担保しています。 新旧バージョンの変更履歴を把握 変更によるアプリケーション影響の把握 アプリケーションの動作チェック 負荷チェック 移行計画の策定 移行作業の実施 取り組み 1.予測/計画 これらの作業は決して少ない工数では無く、システムやリソースの増加に伴って作業量も増えていく一方です。 AWS であれば EOL 通知はメール等で行われるため今までは通知が来てから計画を立てるというフローを採っていましたが、対象システムの増加に伴うリソース増により上記内容を期限内に消化するのが困難になってきています。 さらに RDS for MySQL に関してはバージョンあたりのサポート期限が短縮傾向にあるため、一度バージョンを上げればこの先数年は安泰といった状態でも無くなってきています。 この状態を踏まえて、2023 年からは通知が来る前に先手を打つ方針に切り替えました。 いつ何が起きるのか？（どれがいつ EOL を迎えるのか？）を事前に把握し、それを元に逆算し計画をすることで無駄の無い行動を目指すというものです。 対象リソースのリストアップ まずは各システムが利用するリソースのバージョンと EOL をリストアップし、自分たちが抱えるシステムとリソースの全量とそれらのバージョンがどういった状態なのかを把握します。 ここから各バージョンの EOL 時期を収集することになるのですが、幸いバージョン EOL については個々の公式サイトで明記されていることが多いので把握はそれほど難しくはありませんでした。 ex.) Ruby Java AWS RDS/MySQL AWS といったマネージドサービスに対しては公式の EOL と必ずしもイコールにはなりませんが、マネージドサービス側が公式 EOL より期限が早いことは無いので、公式 EOL を期限として考えるようにしています。 また公式サイトが見つからない/明記されていないといったものが稀にあり、それらは endoflife.date というサイトを活用しました。 優先度の決定 リストアップした時点でかなりの量に及ぶため、ここから対応優先度を決定します。 最優先とすべきポイントとしては、期限を迎えると強制的にバージョンアップされてしまうマネージドサービス系のリソースです。 これらについては切られた期限に対する猶予は基本与えられないため、優先度が一番高いものと考えます。 次点として EC2 に自前でインストールするようなリソースが続きます。これは最悪 EOL を迎えても動作は継続できるため、上記よりは優先度を下げています。 後はこれらの 優先度/EOL の 2 軸で対応順を検討し、2023 年の年間スケジュールに落とし込みました。 効果 2023 年 8 月の時点で、AWS のマネージドサービス系のリソースについては通知を受ける前にバージョン追従作業を済ませることができています。 特に 2023 年 10 月に EOL を迎える RDS の MySQL5.7 → MySQL8.0 対応は大変大きな規模の作業になりましたが、対象 4 サービス、DB インスタンス十数台を 2023 年 7 月に無事すべて切り替えることができました。 途中 AWS では OpenSearch や ElastiCache の緊急セキュリティアップデート対応が突発で入りましたが、全ての計画において先手というバッファを見込んでいたため予定を大きく狂わせず完了することができています。 取り組み 2.突発作業の削減 先程は計画を立てて無駄のない行動を目指すことを目的としていましたが、どれだけ予測や計画の精度を上げた所で突発作業はどうしても発生します。 社内からの要因であれば対処の仕方もありますが、外部要因となると予測も対応も困難であるものが多くなります。 特に「何も変更していないのに急に動かなくなった！」が一番脅威で、OS 仕様変更や外部ライブラリの廃止に伴うものがチームの実績として多く感じています。 こういった外部要因による事象を発生させにくい状態にするため、以下の対策を行っています。 PrivateGem サーバの構築 ジョブメドレーは Ruby で動くアプリケーションですが、外部ライブラリとして多数の Gem を併用しています。 この Gem がある日突然リポジトリから削除され bundle install が通らず起動しない、といったことが稀にありました。 バージョンアップで対応できるものであればまだ良いのですが、そもそも廃止といった状況だと対応の長期化は必至。 そういった事態を避けるため Geminabox にて PrivateGem サーバを構築しました。 このサーバは RubyGems 向けの Proxy/キャッシュサーバ という位置づけで、このサーバ経由で RubyGems に Gem を取得すると同時にサーバ内にも Gem はキャッシュします。 キャッシュされた Gem については以降 RubyGems に再度取りに行くことは無いため、RubyGems 上で取得できない事態が発生しても喫緊の対応が必要な状況にはなりません。 動作環境の Docker イメージ化 とある Python によるプログラムを対象としているのですが OS/Python バージョン/Pip ライブラリ の兼ね合いがとても厳しく、少しでもバージョンにズレが生じると動作不良を起こし対応に回るといったことが年〜半年に一度発生していました。 動作環境としては プログラム開始時に EC2 起動 コードのダウンロード ライブラリのインストール プログラム実行 プログラム終了後に EC2 停止 という形態を取っていましたが、それぞれのステップに於いて毎度同じ環境になる保証がない状態というのが大きな課題でした。 具体的には EC2 の起動時は Amazon Linux 2 の仕様で Python のバージョンが変わって動かない、ライブラリのインストールではバージョン固定が甘くある日バージョンが変わって動かなくなる、といったことが起こる再現性の低い仕組みで組まれている状態です。 そこで、毎回同じ動作環境を維持するための取り組みとして Docker イメージによる環境の固定化を行いました。 これは Docker イメージによって OS を固定した上でイメージ内にコード/ライブラリまでを含めてしまうもので、OS 起動からプログラムの起動まですべて同じ状態になるようにしました。 また副産物としてプログラム起動までのステップが短縮され、プログラム起動までのオーバヘッドの短縮にも繋げることができました。 効果 双方の仕組みの導入により、今年は対象システム回りでの突発作業は発生しない状態を維持できています。 最後に 今回は SRE Unit の業務の一つであるバージョン追従対応についてフォーカスを当てて紹介しましたが、抱える業務は他にも多数あります。 我々 SRE Unit の目的はサイトの安定稼働/信頼性を維持することであり、今回のようなバージョンアップはその中の一部でしかありません。この他にも負荷の監視やパフォーマンスチューニング、障害対応などを取り組むべきことは山ほどあります。 まだチームの人数は決して多くは無いこの現状で、いかにアイデア/技術/仕組み化によって効率的に動けるか切磋琢磨し、より安定したサービスを提供できるように日々取り組んでいます。 もしこれらの取り組みに興味のある方は、是非我々と一緒に働きませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 人材プラットフォーム本部プロダクト開発室第一開発グループの阪本です。 毎日夕方になっても 30 度を超えるような猛暑が続く中、皆さんはいかがお過ごしでしょうか？ 今まで何度も紹介させていただきましたが、私は阪神タイガースのファンです。 今年は第二次岡田政権の 1 年目、開幕からの好調を維持し交流戦までは首位独走。交流戦明けに一時的に首位を明け渡す事態になりましたが、8 月に入り破竹の 2 桁連勝で首位奪還どころか独走状態という最高のシーズンを迎えております。 投手は元々良いチームではありましたが、今年は課題であった守備と出塁率に改善が見られ 普通にやれば勝てる チームに近づいたというのが大きいのではないでしょうか。 この記事が公開される頃には優勝マジックが点灯し、18 年振りの「あれ」まで秒読みとなっていることでしょう。待ちに待ったその瞬間まで、あと少しです。 さて、現在私は SRE Unit リーダの立場で主に ジョブメドレー の安定稼働に向けた取り組みに日々取り組んでいます。 今回はチーム内で抱える課題と、それを解決するための取り組みについて紹介させていただきます。 SRE Unit が取り組んでいる課題 SRE Unit の業務は 運用/メンテナンス 障害対応 アカウント管理 環境整備 と多岐に渡り、ジョブメドレーを含めた大小 5 システムを対象として 4 名のメンバーで推進しています。 この中でも最近の SRE Unit での業務の大半を占めるものがリソースのバージョン追従対応ですが、明確な期限が存在する上に対象システム/リソースは多いといった特徴があるため、計画的に行動しないと突発業務が発生した際に期限内の対応が困難になります。 特に AWS といったマネージドサービス系はアップデートが強制的にスケジューリングされるため、こちら側の都合を挟む余地はありません。 こういった事態にならないために行なっている SRE Unit での この先に何が起こるのか？ という「予測/計画」と、 計画を阻害する要因 となる「突発作業の削減」の 2 軸の取り組みについて紹介します。 バージョン追従対応とは？ まずは前情報としてバージョン追従作業というものがどういったものなのかを説明します。 これはシステムが利用しているサーバ/データベースといったリソースのサポート期限終了 (EOL:End Of Life) までに最新バージョンに引き上げることを指します。 EOL を迎えたリソースは公式でのサポート終了を意味するものであるため、以降発生するバグや脆弱性に対しての修正対応が期待できない状態になります。 バージョンアップ対応を行わない場合、運良くバグや脆弱性の問題が発生しなければソフトウェア的に動作の継続は可能ですが、これに関連するライブラリなども古いバージョンのサポートを切るタイミングが出てくるので遅かれ早かれ影響は出てきます。 また AWS のマネージドサービス (ex.RDS/ElastiCache/OpenSearch) では、サポート期限の終了に伴い強制的に最新バージョンへの更新がスケジュールされます。 「最新バージョンへと更新してくれる」、その言葉だけ見ると素晴らしいものですが、もちろん更新中に発生するダウンタイムや接続するアプリケーションに対する影響まで面倒は見てくれません。 そのため、マネージドだろうが非マネージドだろうがバージョンアップ対応は必ず行う必要があると言うことです。 作業の内容 この作業は単純にリソースのバージョンアップをするだけで済む作業ではありません。 前述でのダウンタイムやバージョン間による変更差分によりアプリケーションが今まで通り動いているかを保証する必要があるため、下記をセットで実施することでシステム稼働を担保しています。 新旧バージョンの変更履歴を把握 変更によるアプリケーション影響の把握 アプリケーションの動作チェック 負荷チェック 移行計画の策定 移行作業の実施 取り組み 1.予測/計画 これらの作業は決して少ない工数では無く、システムやリソースの増加に伴って作業量も増えていく一方です。 AWS であれば EOL 通知はメール等で行われるため今までは通知が来てから計画を立てるというフローを採っていましたが、対象システムの増加に伴うリソース増により上記内容を期限内に消化するのが困難になってきています。 さらに RDS for MySQL に関してはバージョンあたりのサポート期限が短縮傾向にあるため、一度バージョンを上げればこの先数年は安泰といった状態でも無くなってきています。 この状態を踏まえて、2023 年からは通知が来る前に先手を打つ方針に切り替えました。 いつ何が起きるのか？（どれがいつ EOL を迎えるのか？）を事前に把握し、それを元に逆算し計画をすることで無駄の無い行動を目指すというものです。 対象リソースのリストアップ まずは各システムが利用するリソースのバージョンと EOL をリストアップし、自分たちが抱えるシステムとリソースの全量とそれらのバージョンがどういった状態なのかを把握します。 ここから各バージョンの EOL 時期を収集することになるのですが、幸いバージョン EOL については個々の公式サイトで明記されていることが多いので把握はそれほど難しくはありませんでした。 ex.) Ruby Java AWS RDS/MySQL AWS といったマネージドサービスに対しては公式の EOL と必ずしもイコールにはなりませんが、マネージドサービス側が公式 EOL より期限が早いことは無いので、公式 EOL を期限として考えるようにしています。 また公式サイトが見つからない/明記されていないといったものが稀にあり、それらは endoflife.date というサイトを活用しました。 優先度の決定 リストアップした時点でかなりの量に及ぶため、ここから対応優先度を決定します。 最優先とすべきポイントとしては、期限を迎えると強制的にバージョンアップされてしまうマネージドサービス系のリソースです。 これらについては切られた期限に対する猶予は基本与えられないため、優先度が一番高いものと考えます。 次点として EC2 に自前でインストールするようなリソースが続きます。これは最悪 EOL を迎えても動作は継続できるため、上記よりは優先度を下げています。 後はこれらの 優先度/EOL の 2 軸で対応順を検討し、2023 年の年間スケジュールに落とし込みました。 効果 2023 年 8 月の時点で、AWS のマネージドサービス系のリソースについては通知を受ける前にバージョン追従作業を済ませることができています。 特に 2023 年 10 月に EOL を迎える RDS の MySQL5.7 → MySQL8.0 対応は大変大きな規模の作業になりましたが、対象 4 サービス、DB インスタンス十数台を 2023 年 7 月に無事すべて切り替えることができました。 途中 AWS では OpenSearch や ElastiCache の緊急セキュリティアップデート対応が突発で入りましたが、全ての計画において先手というバッファを見込んでいたため予定を大きく狂わせず完了することができています。 取り組み 2.突発作業の削減 先程は計画を立てて無駄のない行動を目指すことを目的としていましたが、どれだけ予測や計画の精度を上げた所で突発作業はどうしても発生します。 社内からの要因であれば対処の仕方もありますが、外部要因となると予測も対応も困難であるものが多くなります。 特に「何も変更していないのに急に動かなくなった！」が一番脅威で、OS 仕様変更や外部ライブラリの廃止に伴うものがチームの実績として多く感じています。 こういった外部要因による事象を発生させにくい状態にするため、以下の対策を行っています。 PrivateGem サーバの構築 ジョブメドレーは Ruby で動くアプリケーションですが、外部ライブラリとして多数の Gem を併用しています。 この Gem がある日突然リポジトリから削除され bundle install が通らず起動しない、といったことが稀にありました。 バージョンアップで対応できるものであればまだ良いのですが、そもそも廃止といった状況だと対応の長期化は必至。 そういった事態を避けるため Geminabox にて PrivateGem サーバを構築しました。 このサーバは RubyGems 向けの Proxy/キャッシュサーバ という位置づけで、このサーバ経由で RubyGems に Gem を取得すると同時にサーバ内にも Gem はキャッシュします。 キャッシュされた Gem については以降 RubyGems に再度取りに行くことは無いため、RubyGems 上で取得できない事態が発生しても喫緊の対応が必要な状況にはなりません。 動作環境の Docker イメージ化 とある Python によるプログラムを対象としているのですが OS/Python バージョン/Pip ライブラリ の兼ね合いがとても厳しく、少しでもバージョンにズレが生じると動作不良を起こし対応に回るといったことが年〜半年に一度発生していました。 動作環境としては プログラム開始時に EC2 起動 コードのダウンロード ライブラリのインストール プログラム実行 プログラム終了後に EC2 停止 という形態を取っていましたが、それぞれのステップに於いて毎度同じ環境になる保証がない状態というのが大きな課題でした。 具体的には EC2 の起動時は Amazon Linux 2 の仕様で Python のバージョンが変わって動かない、ライブラリのインストールではバージョン固定が甘くある日バージョンが変わって動かなくなる、といったことが起こる再現性の低い仕組みで組まれている状態です。 そこで、毎回同じ動作環境を維持するための取り組みとして Docker イメージによる環境の固定化を行いました。 これは Docker イメージによって OS を固定した上でイメージ内にコード/ライブラリまでを含めてしまうもので、OS 起動からプログラムの起動まですべて同じ状態になるようにしました。 また副産物としてプログラム起動までのステップが短縮され、プログラム起動までのオーバヘッドの短縮にも繋げることができました。 効果 双方の仕組みの導入により、今年は対象システム回りでの突発作業は発生しない状態を維持できています。 最後に 今回は SRE Unit の業務の一つであるバージョン追従対応についてフォーカスを当てて紹介しましたが、抱える業務は他にも多数あります。 我々 SRE Unit の目的はサイトの安定稼働/信頼性を維持することであり、今回のようなバージョンアップはその中の一部でしかありません。この他にも負荷の監視やパフォーマンスチューニング、障害対応などを取り組むべきことは山ほどあります。 まだチームの人数は決して多くは無いこの現状で、いかにアイデア/技術/仕組み化によって効率的に動けるか切磋琢磨し、より安定したサービスを提供できるように日々取り組んでいます。 もしこれらの取り組みに興味のある方は、是非我々と一緒に働きませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 人材プラットフォーム本部プロダクト開発室第一開発グループの阪本です。 毎日夕方になっても 30 度を超えるような猛暑が続く中、皆さんはいかがお過ごしでしょうか？ 今まで何度も紹介させていただきましたが、私は阪神タイガースのファンです。 今年は第二次岡田政権の 1 年目、開幕からの好調を維持し交流戦までは首位独走。交流戦明けに一時的に首位を明け渡す事態になりましたが、8 月に入り破竹の 2 桁連勝で首位奪還どころか独走状態という最高のシーズンを迎えております。 投手は元々良いチームではありましたが、今年は課題であった守備と出塁率に改善が見られ 普通にやれば勝てる チームに近づいたというのが大きいのではないでしょうか。 この記事が公開される頃には優勝マジックが点灯し、18 年振りの「あれ」まで秒読みとなっていることでしょう。待ちに待ったその瞬間まで、あと少しです。 さて、現在私は SRE Unit リーダの立場で主に ジョブメドレー の安定稼働に向けた取り組みに日々取り組んでいます。 今回はチーム内で抱える課題と、それを解決するための取り組みについて紹介させていただきます。 SRE Unit が取り組んでいる課題 SRE Unit の業務は 運用/メンテナンス 障害対応 アカウント管理 環境整備 と多岐に渡り、ジョブメドレーを含めた大小 5 システムを対象として 4 名のメンバーで推進しています。 この中でも最近の SRE Unit での業務の大半を占めるものがリソースのバージョン追従対応ですが、明確な期限が存在する上に対象システム/リソースは多いといった特徴があるため、計画的に行動しないと突発業務が発生した際に期限内の対応が困難になります。 特に AWS といったマネージドサービス系はアップデートが強制的にスケジューリングされるため、こちら側の都合を挟む余地はありません。 こういった事態にならないために行なっている SRE Unit での この先に何が起こるのか？ という「予測/計画」と、 計画を阻害する要因 となる「突発作業の削減」の 2 軸の取り組みについて紹介します。 バージョン追従対応とは？ まずは前情報としてバージョン追従作業というものがどういったものなのかを説明します。 これはシステムが利用しているサーバ/データベースといったリソースのサポート期限終了 (EOL:End Of Life) までに最新バージョンに引き上げることを指します。 EOL を迎えたリソースは公式でのサポート終了を意味するものであるため、以降発生するバグや脆弱性に対しての修正対応が期待できない状態になります。 バージョンアップ対応を行わない場合、運良くバグや脆弱性の問題が発生しなければソフトウェア的に動作の継続は可能ですが、これに関連するライブラリなども古いバージョンのサポートを切るタイミングが出てくるので遅かれ早かれ影響は出てきます。 また AWS のマネージドサービス (ex.RDS/ElastiCache/OpenSearch) では、サポート期限の終了に伴い強制的に最新バージョンへの更新がスケジュールされます。 「最新バージョンへと更新してくれる」、その言葉だけ見ると素晴らしいものですが、もちろん更新中に発生するダウンタイムや接続するアプリケーションに対する影響まで面倒は見てくれません。 そのため、マネージドだろうが非マネージドだろうがバージョンアップ対応は必ず行う必要があると言うことです。 作業の内容 この作業は単純にリソースのバージョンアップをするだけで済む作業ではありません。 前述でのダウンタイムやバージョン間による変更差分によりアプリケーションが今まで通り動いているかを保証する必要があるため、下記をセットで実施することでシステム稼働を担保しています。 新旧バージョンの変更履歴を把握 変更によるアプリケーション影響の把握 アプリケーションの動作チェック 負荷チェック 移行計画の策定 移行作業の実施 取り組み 1.予測/計画 これらの作業は決して少ない工数では無く、システムやリソースの増加に伴って作業量も増えていく一方です。 AWS であれば EOL 通知はメール等で行われるため今までは通知が来てから計画を立てるというフローを採っていましたが、対象システムの増加に伴うリソース増により上記内容を期限内に消化するのが困難になってきています。 さらに RDS for MySQL に関してはバージョンあたりのサポート期限が短縮傾向にあるため、一度バージョンを上げればこの先数年は安泰といった状態でも無くなってきています。 この状態を踏まえて、2023 年からは通知が来る前に先手を打つ方針に切り替えました。 いつ何が起きるのか？（どれがいつ EOL を迎えるのか？）を事前に把握し、それを元に逆算し計画をすることで無駄の無い行動を目指すというものです。 対象リソースのリストアップ まずは各システムが利用するリソースのバージョンと EOL をリストアップし、自分たちが抱えるシステムとリソースの全量とそれらのバージョンがどういった状態なのかを把握します。 ここから各バージョンの EOL 時期を収集することになるのですが、幸いバージョン EOL については個々の公式サイトで明記されていることが多いので把握はそれほど難しくはありませんでした。 ex.) Ruby Java AWS RDS/MySQL AWS といったマネージドサービスに対しては公式の EOL と必ずしもイコールにはなりませんが、マネージドサービス側が公式 EOL より期限が早いことは無いので、公式 EOL を期限として考えるようにしています。 また公式サイトが見つからない/明記されていないといったものが稀にあり、それらは endoflife.date というサイトを活用しました。 優先度の決定 リストアップした時点でかなりの量に及ぶため、ここから対応優先度を決定します。 最優先とすべきポイントとしては、期限を迎えると強制的にバージョンアップされてしまうマネージドサービス系のリソースです。 これらについては切られた期限に対する猶予は基本与えられないため、優先度が一番高いものと考えます。 次点として EC2 に自前でインストールするようなリソースが続きます。これは最悪 EOL を迎えても動作は継続できるため、上記よりは優先度を下げています。 後はこれらの 優先度/EOL の 2 軸で対応順を検討し、2023 年の年間スケジュールに落とし込みました。 効果 2023 年 8 月の時点で、AWS のマネージドサービス系のリソースについては通知を受ける前にバージョン追従作業を済ませることができています。 特に 2023 年 10 月に EOL を迎える RDS の MySQL5.7 → MySQL8.0 対応は大変大きな規模の作業になりましたが、対象 4 サービス、DB インスタンス十数台を 2023 年 7 月に無事すべて切り替えることができました。 途中 AWS では OpenSearch や ElastiCache の緊急セキュリティアップデート対応が突発で入りましたが、全ての計画において先手というバッファを見込んでいたため予定を大きく狂わせず完了することができています。 取り組み 2.突発作業の削減 先程は計画を立てて無駄のない行動を目指すことを目的としていましたが、どれだけ予測や計画の精度を上げた所で突発作業はどうしても発生します。 社内からの要因であれば対処の仕方もありますが、外部要因となると予測も対応も困難であるものが多くなります。 特に「何も変更していないのに急に動かなくなった！」が一番脅威で、OS 仕様変更や外部ライブラリの廃止に伴うものがチームの実績として多く感じています。 こういった外部要因による事象を発生させにくい状態にするため、以下の対策を行っています。 PrivateGem サーバの構築 ジョブメドレーは Ruby で動くアプリケーションですが、外部ライブラリとして多数の Gem を併用しています。 この Gem がある日突然リポジトリから削除され bundle install が通らず起動しない、といったことが稀にありました。 バージョンアップで対応できるものであればまだ良いのですが、そもそも廃止といった状況だと対応の長期化は必至。 そういった事態を避けるため Geminabox にて PrivateGem サーバを構築しました。 このサーバは RubyGems 向けの Proxy/キャッシュサーバ という位置づけで、このサーバ経由で RubyGems に Gem を取得すると同時にサーバ内にも Gem はキャッシュします。 キャッシュされた Gem については以降 RubyGems に再度取りに行くことは無いため、RubyGems 上で取得できない事態が発生しても喫緊の対応が必要な状況にはなりません。 動作環境の Docker イメージ化 とある Python によるプログラムを対象としているのですが OS/Python バージョン/Pip ライブラリ の兼ね合いがとても厳しく、少しでもバージョンにズレが生じると動作不良を起こし対応に回るといったことが年〜半年に一度発生していました。 動作環境としては プログラム開始時に EC2 起動 コードのダウンロード ライブラリのインストール プログラム実行 プログラム終了後に EC2 停止 という形態を取っていましたが、それぞれのステップに於いて毎度同じ環境になる保証がない状態というのが大きな課題でした。 具体的には EC2 の起動時は Amazon Linux 2 の仕様で Python のバージョンが変わって動かない、ライブラリのインストールではバージョン固定が甘くある日バージョンが変わって動かなくなる、といったことが起こる再現性の低い仕組みで組まれている状態です。 そこで、毎回同じ動作環境を維持するための取り組みとして Docker イメージによる環境の固定化を行いました。 これは Docker イメージによって OS を固定した上でイメージ内にコード/ライブラリまでを含めてしまうもので、OS 起動からプログラムの起動まですべて同じ状態になるようにしました。 また副産物としてプログラム起動までのステップが短縮され、プログラム起動までのオーバヘッドの短縮にも繋げることができました。 効果 双方の仕組みの導入により、今年は対象システム回りでの突発作業は発生しない状態を維持できています。 最後に 今回は SRE Unit の業務の一つであるバージョン追従対応についてフォーカスを当てて紹介しましたが、抱える業務は他にも多数あります。 我々 SRE Unit の目的はサイトの安定稼働/信頼性を維持することであり、今回のようなバージョンアップはその中の一部でしかありません。この他にも負荷の監視やパフォーマンスチューニング、障害対応などを取り組むべきことは山ほどあります。 まだチームの人数は決して多くは無いこの現状で、いかにアイデア/技術/仕組み化によって効率的に動けるか切磋琢磨し、より安定したサービスを提供できるように日々取り組んでいます。 もしこれらの取り組みに興味のある方は、是非我々と一緒に働きませんか？ https://www.medley.jp/jobs/

はじめに こんにちは。 人材プラットフォーム本部プロダクト開発室第一開発グループの阪本です。 毎日夕方になっても 30 度を超えるような猛暑が続く中、皆さんはいかがお過ごしでしょうか？ 今まで何度も紹介させていただきましたが、私は阪神タイガースのファンです。 今年は第二次岡田政権の 1 年目、開幕からの好調を維持し交流戦までは首位独走。交流戦明けに一時的に首位を明け渡す事態になりましたが、8 月に入り破竹の 2 桁連勝で首位奪還どころか独走状態という最高のシーズンを迎えております。 投手は元々良いチームではありましたが、今年は課題であった守備と出塁率に改善が見られ 普通にやれば勝てる チームに近づいたというのが大きいのではないでしょうか。 この記事が公開される頃には優勝マジックが点灯し、18 年振りの「あれ」まで秒読みとなっていることでしょう。待ちに待ったその瞬間まで、あと少しです。 さて、現在私は SRE Unit リーダの立場で主に ジョブメドレー の安定稼働に向けた取り組みに日々取り組んでいます。 今回はチーム内で抱える課題と、それを解決するための取り組みについて紹介させていただきます。 SRE Unit が取り組んでいる課題 SRE Unit の業務は 運用/メンテナンス 障害対応 アカウント管理 環境整備 と多岐に渡り、ジョブメドレーを含めた大小 5 システムを対象として 4 名のメンバーで推進しています。 この中でも最近の SRE Unit での業務の大半を占めるものがリソースのバージョン追従対応ですが、明確な期限が存在する上に対象システム/リソースは多いといった特徴があるため、計画的に行動しないと突発業務が発生した際に期限内の対応が困難になります。 特に AWS といったマネージドサービス系はアップデートが強制的にスケジューリングされるため、こちら側の都合を挟む余地はありません。 こういった事態にならないために行なっている SRE Unit での この先に何が起こるのか？ という「予測/計画」と、 計画を阻害する要因 となる「突発作業の削減」の 2 軸の取り組みについて紹介します。 バージョン追従対応とは？ まずは前情報としてバージョン追従作業というものがどういったものなのかを説明します。 これはシステムが利用しているサーバ/データベースといったリソースのサポート期限終了 (EOL:End Of Life) までに最新バージョンに引き上げることを指します。 EOL を迎えたリソースは公式でのサポート終了を意味するものであるため、以降発生するバグや脆弱性に対しての修正対応が期待できない状態になります。 バージョンアップ対応を行わない場合、運良くバグや脆弱性の問題が発生しなければソフトウェア的に動作の継続は可能ですが、これに関連するライブラリなども古いバージョンのサポートを切るタイミングが出てくるので遅かれ早かれ影響は出てきます。 また AWS のマネージドサービス (ex.RDS/ElastiCache/OpenSearch) では、サポート期限の終了に伴い強制的に最新バージョンへの更新がスケジュールされます。 「最新バージョンへと更新してくれる」、その言葉だけ見ると素晴らしいものですが、もちろん更新中に発生するダウンタイムや接続するアプリケーションに対する影響まで面倒は見てくれません。 そのため、マネージドだろうが非マネージドだろうがバージョンアップ対応は必ず行う必要があると言うことです。 作業の内容 この作業は単純にリソースのバージョンアップをするだけで済む作業ではありません。 前述でのダウンタイムやバージョン間による変更差分によりアプリケーションが今まで通り動いているかを保証する必要があるため、下記をセットで実施することでシステム稼働を担保しています。 新旧バージョンの変更履歴を把握 変更によるアプリケーション影響の把握 アプリケーションの動作チェック 負荷チェック 移行計画の策定 移行作業の実施 取り組み 1.予測/計画 これらの作業は決して少ない工数では無く、システムやリソースの増加に伴って作業量も増えていく一方です。 AWS であれば EOL 通知はメール等で行われるため今までは通知が来てから計画を立てるというフローを採っていましたが、対象システムの増加に伴うリソース増により上記内容を期限内に消化するのが困難になってきています。 さらに RDS for MySQL に関してはバージョンあたりのサポート期限が短縮傾向にあるため、一度バージョンを上げればこの先数年は安泰といった状態でも無くなってきています。 この状態を踏まえて、2023 年からは通知が来る前に先手を打つ方針に切り替えました。 いつ何が起きるのか？（どれがいつ EOL を迎えるのか？）を事前に把握し、それを元に逆算し計画をすることで無駄の無い行動を目指すというものです。 対象リソースのリストアップ まずは各システムが利用するリソースのバージョンと EOL をリストアップし、自分たちが抱えるシステムとリソースの全量とそれらのバージョンがどういった状態なのかを把握します。 ここから各バージョンの EOL 時期を収集することになるのですが、幸いバージョン EOL については個々の公式サイトで明記されていることが多いので把握はそれほど難しくはありませんでした。 ex.) Ruby Java AWS RDS/MySQL AWS といったマネージドサービスに対しては公式の EOL と必ずしもイコールにはなりませんが、マネージドサービス側が公式 EOL より期限が早いことは無いので、公式 EOL を期限として考えるようにしています。 また公式サイトが見つからない/明記されていないといったものが稀にあり、それらは endoflife.date というサイトを活用しました。 優先度の決定 リストアップした時点でかなりの量に及ぶため、ここから対応優先度を決定します。 最優先とすべきポイントとしては、期限を迎えると強制的にバージョンアップされてしまうマネージドサービス系のリソースです。 これらについては切られた期限に対する猶予は基本与えられないため、優先度が一番高いものと考えます。 次点として EC2 に自前でインストールするようなリソースが続きます。これは最悪 EOL を迎えても動作は継続できるため、上記よりは優先度を下げています。 後はこれらの 優先度/EOL の 2 軸で対応順を検討し、2023 年の年間スケジュールに落とし込みました。 効果 2023 年 8 月の時点で、AWS のマネージドサービス系のリソースについては通知を受ける前にバージョン追従作業を済ませることができています。 特に 2023 年 10 月に EOL を迎える RDS の MySQL5.7 → MySQL8.0 対応は大変大きな規模の作業になりましたが、対象 4 サービス、DB インスタンス十数台を 2023 年 7 月に無事すべて切り替えることができました。 途中 AWS では OpenSearch や ElastiCache の緊急セキュリティアップデート対応が突発で入りましたが、全ての計画において先手というバッファを見込んでいたため予定を大きく狂わせず完了することができています。 取り組み 2.突発作業の削減 先程は計画を立てて無駄のない行動を目指すことを目的としていましたが、どれだけ予測や計画の精度を上げた所で突発作業はどうしても発生します。 社内からの要因であれば対処の仕方もありますが、外部要因となると予測も対応も困難であるものが多くなります。 特に「何も変更していないのに急に動かなくなった！」が一番脅威で、OS 仕様変更や外部ライブラリの廃止に伴うものがチームの実績として多く感じています。 こういった外部要因による事象を発生させにくい状態にするため、以下の対策を行っています。 PrivateGem サーバの構築 ジョブメドレーは Ruby で動くアプリケーションですが、外部ライブラリとして多数の Gem を併用しています。 この Gem がある日突然リポジトリから削除され bundle install が通らず起動しない、といったことが稀にありました。 バージョンアップで対応できるものであればまだ良いのですが、そもそも廃止といった状況だと対応の長期化は必至。 そういった事態を避けるため Geminabox にて PrivateGem サーバを構築しました。 このサーバは RubyGems 向けの Proxy/キャッシュサーバ という位置づけで、このサーバ経由で RubyGems に Gem を取得すると同時にサーバ内にも Gem はキャッシュします。 キャッシュされた Gem については以降 RubyGems に再度取りに行くことは無いため、RubyGems 上で取得できない事態が発生しても喫緊の対応が必要な状況にはなりません。 動作環境の Docker イメージ化 とある Python によるプログラムを対象としているのですが OS/Python バージョン/Pip ライブラリ の兼ね合いがとても厳しく、少しでもバージョンにズレが生じると動作不良を起こし対応に回るといったことが年〜半年に一度発生していました。 動作環境としては プログラム開始時に EC2 起動 コードのダウンロード ライブラリのインストール プログラム実行 プログラム終了後に EC2 停止 という形態を取っていましたが、それぞれのステップに於いて毎度同じ環境になる保証がない状態というのが大きな課題でした。 具体的には EC2 の起動時は Amazon Linux 2 の仕様で Python のバージョンが変わって動かない、ライブラリのインストールではバージョン固定が甘くある日バージョンが変わって動かなくなる、といったことが起こる再現性の低い仕組みで組まれている状態です。 そこで、毎回同じ動作環境を維持するための取り組みとして Docker イメージによる環境の固定化を行いました。 これは Docker イメージによって OS を固定した上でイメージ内にコード/ライブラリまでを含めてしまうもので、OS 起動からプログラムの起動まですべて同じ状態になるようにしました。 また副産物としてプログラム起動までのステップが短縮され、プログラム起動までのオーバヘッドの短縮にも繋げることができました。 効果 双方の仕組みの導入により、今年は対象システム回りでの突発作業は発生しない状態を維持できています。 最後に 今回は SRE Unit の業務の一つであるバージョン追従対応についてフォーカスを当てて紹介しましたが、抱える業務は他にも多数あります。 我々 SRE Unit の目的はサイトの安定稼働/信頼性を維持することであり、今回のようなバージョンアップはその中の一部でしかありません。この他にも負荷の監視やパフォーマンスチューニング、障害対応などを取り組むべきことは山ほどあります。 まだチームの人数は決して多くは無いこの現状で、いかにアイデア/技術/仕組み化によって効率的に動けるか切磋琢磨し、より安定したサービスを提供できるように日々取り組んでいます。 もしこれらの取り組みに興味のある方は、是非我々と一緒に働きませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 人材プラットフォーム本部プロダクト開発室第一開発グループの阪本です。 毎日夕方になっても 30 度を超えるような猛暑が続く中、皆さんはいかがお過ごしでしょうか？ 今まで何度も紹介させていただきましたが、私は阪神タイガースのファンです。 今年は第二次岡田政権の 1 年目、開幕からの好調を維持し交流戦までは首位独走。交流戦明けに一時的に首位を明け渡す事態になりましたが、8 月に入り破竹の 2 桁連勝で首位奪還どころか独走状態という最高のシーズンを迎えております。 投手は元々良いチームではありましたが、今年は課題であった守備と出塁率に改善が見られ 普通にやれば勝てる チームに近づいたというのが大きいのではないでしょうか。 この記事が公開される頃には優勝マジックが点灯し、18 年振りの「あれ」まで秒読みとなっていることでしょう。待ちに待ったその瞬間まで、あと少しです。 さて、現在私は SRE Unit リーダの立場で主に ジョブメドレー の安定稼働に向けた取り組みに日々取り組んでいます。 今回はチーム内で抱える課題と、それを解決するための取り組みについて紹介させていただきます。 SRE Unit が取り組んでいる課題 SRE Unit の業務は 運用/メンテナンス 障害対応 アカウント管理 環境整備 と多岐に渡り、ジョブメドレーを含めた大小 5 システムを対象として 4 名のメンバーで推進しています。 この中でも最近の SRE Unit での業務の大半を占めるものがリソースのバージョン追従対応ですが、明確な期限が存在する上に対象システム/リソースは多いといった特徴があるため、計画的に行動しないと突発業務が発生した際に期限内の対応が困難になります。 特に AWS といったマネージドサービス系はアップデートが強制的にスケジューリングされるため、こちら側の都合を挟む余地はありません。 こういった事態にならないために行なっている SRE Unit での この先に何が起こるのか？ という「予測/計画」と、 計画を阻害する要因 となる「突発作業の削減」の 2 軸の取り組みについて紹介します。 バージョン追従対応とは？ まずは前情報としてバージョン追従作業というものがどういったものなのかを説明します。 これはシステムが利用しているサーバ/データベースといったリソースのサポート期限終了 (EOL:End Of Life) までに最新バージョンに引き上げることを指します。 EOL を迎えたリソースは公式でのサポート終了を意味するものであるため、以降発生するバグや脆弱性に対しての修正対応が期待できない状態になります。 バージョンアップ対応を行わない場合、運良くバグや脆弱性の問題が発生しなければソフトウェア的に動作の継続は可能ですが、これに関連するライブラリなども古いバージョンのサポートを切るタイミングが出てくるので遅かれ早かれ影響は出てきます。 また AWS のマネージドサービス (ex.RDS/ElastiCache/OpenSearch) では、サポート期限の終了に伴い強制的に最新バージョンへの更新がスケジュールされます。 「最新バージョンへと更新してくれる」、その言葉だけ見ると素晴らしいものですが、もちろん更新中に発生するダウンタイムや接続するアプリケーションに対する影響まで面倒は見てくれません。 そのため、マネージドだろうが非マネージドだろうがバージョンアップ対応は必ず行う必要があると言うことです。 作業の内容 この作業は単純にリソースのバージョンアップをするだけで済む作業ではありません。 前述でのダウンタイムやバージョン間による変更差分によりアプリケーションが今まで通り動いているかを保証する必要があるため、下記をセットで実施することでシステム稼働を担保しています。 新旧バージョンの変更履歴を把握 変更によるアプリケーション影響の把握 アプリケーションの動作チェック 負荷チェック 移行計画の策定 移行作業の実施 取り組み 1.予測/計画 これらの作業は決して少ない工数では無く、システムやリソースの増加に伴って作業量も増えていく一方です。 AWS であれば EOL 通知はメール等で行われるため今までは通知が来てから計画を立てるというフローを採っていましたが、対象システムの増加に伴うリソース増により上記内容を期限内に消化するのが困難になってきています。 さらに RDS for MySQL に関してはバージョンあたりのサポート期限が短縮傾向にあるため、一度バージョンを上げればこの先数年は安泰といった状態でも無くなってきています。 この状態を踏まえて、2023 年からは通知が来る前に先手を打つ方針に切り替えました。 いつ何が起きるのか？（どれがいつ EOL を迎えるのか？）を事前に把握し、それを元に逆算し計画をすることで無駄の無い行動を目指すというものです。 対象リソースのリストアップ まずは各システムが利用するリソースのバージョンと EOL をリストアップし、自分たちが抱えるシステムとリソースの全量とそれらのバージョンがどういった状態なのかを把握します。 ここから各バージョンの EOL 時期を収集することになるのですが、幸いバージョン EOL については個々の公式サイトで明記されていることが多いので把握はそれほど難しくはありませんでした。 ex.) Ruby Java AWS RDS/MySQL AWS といったマネージドサービスに対しては公式の EOL と必ずしもイコールにはなりませんが、マネージドサービス側が公式 EOL より期限が早いことは無いので、公式 EOL を期限として考えるようにしています。 また公式サイトが見つからない/明記されていないといったものが稀にあり、それらは endoflife.date というサイトを活用しました。 優先度の決定 リストアップした時点でかなりの量に及ぶため、ここから対応優先度を決定します。 最優先とすべきポイントとしては、期限を迎えると強制的にバージョンアップされてしまうマネージドサービス系のリソースです。 これらについては切られた期限に対する猶予は基本与えられないため、優先度が一番高いものと考えます。 次点として EC2 に自前でインストールするようなリソースが続きます。これは最悪 EOL を迎えても動作は継続できるため、上記よりは優先度を下げています。 後はこれらの 優先度/EOL の 2 軸で対応順を検討し、2023 年の年間スケジュールに落とし込みました。 効果 2023 年 8 月の時点で、AWS のマネージドサービス系のリソースについては通知を受ける前にバージョン追従作業を済ませることができています。 特に 2023 年 10 月に EOL を迎える RDS の MySQL5.7 → MySQL8.0 対応は大変大きな規模の作業になりましたが、対象 4 サービス、DB インスタンス十数台を 2023 年 7 月に無事すべて切り替えることができました。 途中 AWS では OpenSearch や ElastiCache の緊急セキュリティアップデート対応が突発で入りましたが、全ての計画において先手というバッファを見込んでいたため予定を大きく狂わせず完了することができています。 取り組み 2.突発作業の削減 先程は計画を立てて無駄のない行動を目指すことを目的としていましたが、どれだけ予測や計画の精度を上げた所で突発作業はどうしても発生します。 社内からの要因であれば対処の仕方もありますが、外部要因となると予測も対応も困難であるものが多くなります。 特に「何も変更していないのに急に動かなくなった！」が一番脅威で、OS 仕様変更や外部ライブラリの廃止に伴うものがチームの実績として多く感じています。 こういった外部要因による事象を発生させにくい状態にするため、以下の対策を行っています。 PrivateGem サーバの構築 ジョブメドレーは Ruby で動くアプリケーションですが、外部ライブラリとして多数の Gem を併用しています。 この Gem がある日突然リポジトリから削除され bundle install が通らず起動しない、といったことが稀にありました。 バージョンアップで対応できるものであればまだ良いのですが、そもそも廃止といった状況だと対応の長期化は必至。 そういった事態を避けるため Geminabox にて PrivateGem サーバを構築しました。 このサーバは RubyGems 向けの Proxy/キャッシュサーバ という位置づけで、このサーバ経由で RubyGems に Gem を取得すると同時にサーバ内にも Gem はキャッシュします。 キャッシュされた Gem については以降 RubyGems に再度取りに行くことは無いため、RubyGems 上で取得できない事態が発生しても喫緊の対応が必要な状況にはなりません。 動作環境の Docker イメージ化 とある Python によるプログラムを対象としているのですが OS/Python バージョン/Pip ライブラリ の兼ね合いがとても厳しく、少しでもバージョンにズレが生じると動作不良を起こし対応に回るといったことが年〜半年に一度発生していました。 動作環境としては プログラム開始時に EC2 起動 コードのダウンロード ライブラリのインストール プログラム実行 プログラム終了後に EC2 停止 という形態を取っていましたが、それぞれのステップに於いて毎度同じ環境になる保証がない状態というのが大きな課題でした。 具体的には EC2 の起動時は Amazon Linux 2 の仕様で Python のバージョンが変わって動かない、ライブラリのインストールではバージョン固定が甘くある日バージョンが変わって動かなくなる、といったことが起こる再現性の低い仕組みで組まれている状態です。 そこで、毎回同じ動作環境を維持するための取り組みとして Docker イメージによる環境の固定化を行いました。 これは Docker イメージによって OS を固定した上でイメージ内にコード/ライブラリまでを含めてしまうもので、OS 起動からプログラムの起動まですべて同じ状態になるようにしました。 また副産物としてプログラム起動までのステップが短縮され、プログラム起動までのオーバヘッドの短縮にも繋げることができました。 効果 双方の仕組みの導入により、今年は対象システム回りでの突発作業は発生しない状態を維持できています。 最後に 今回は SRE Unit の業務の一つであるバージョン追従対応についてフォーカスを当てて紹介しましたが、抱える業務は他にも多数あります。 我々 SRE Unit の目的はサイトの安定稼働/信頼性を維持することであり、今回のようなバージョンアップはその中の一部でしかありません。この他にも負荷の監視やパフォーマンスチューニング、障害対応などを取り組むべきことは山ほどあります。 まだチームの人数は決して多くは無いこの現状で、いかにアイデア/技術/仕組み化によって効率的に動けるか切磋琢磨し、より安定したサービスを提供できるように日々取り組んでいます。 もしこれらの取り組みに興味のある方は、是非我々と一緒に働きませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 人材プラットフォーム本部プロダクト開発室第一開発グループの阪本です。 毎日夕方になっても 30 度を超えるような猛暑が続く中、皆さんはいかがお過ごしでしょうか？ 今まで何度も紹介させていただきましたが、私は阪神タイガースのファンです。 今年は第二次岡田政権の 1 年目、開幕からの好調を維持し交流戦までは首位独走。交流戦明けに一時的に首位を明け渡す事態になりましたが、8 月に入り破竹の 2 桁連勝で首位奪還どころか独走状態という最高のシーズンを迎えております。 投手は元々良いチームではありましたが、今年は課題であった守備と出塁率に改善が見られ 普通にやれば勝てる チームに近づいたというのが大きいのではないでしょうか。 この記事が公開される頃には優勝マジックが点灯し、18 年振りの「あれ」まで秒読みとなっていることでしょう。待ちに待ったその瞬間まで、あと少しです。 さて、現在私は SRE Unit リーダの立場で主に ジョブメドレー の安定稼働に向けた取り組みに日々取り組んでいます。 今回はチーム内で抱える課題と、それを解決するための取り組みについて紹介させていただきます。 SRE Unit が取り組んでいる課題 SRE Unit の業務は 運用/メンテナンス 障害対応 アカウント管理 環境整備 と多岐に渡り、ジョブメドレーを含めた大小 5 システムを対象として 4 名のメンバーで推進しています。 この中でも最近の SRE Unit での業務の大半を占めるものがリソースのバージョン追従対応ですが、明確な期限が存在する上に対象システム/リソースは多いといった特徴があるため、計画的に行動しないと突発業務が発生した際に期限内の対応が困難になります。 特に AWS といったマネージドサービス系はアップデートが強制的にスケジューリングされるため、こちら側の都合を挟む余地はありません。 こういった事態にならないために行なっている SRE Unit での この先に何が起こるのか？ という「予測/計画」と、 計画を阻害する要因 となる「突発作業の削減」の 2 軸の取り組みについて紹介します。 バージョン追従対応とは？ まずは前情報としてバージョン追従作業というものがどういったものなのかを説明します。 これはシステムが利用しているサーバ/データベースといったリソースのサポート期限終了 (EOL:End Of Life) までに最新バージョンに引き上げることを指します。 EOL を迎えたリソースは公式でのサポート終了を意味するものであるため、以降発生するバグや脆弱性に対しての修正対応が期待できない状態になります。 バージョンアップ対応を行わない場合、運良くバグや脆弱性の問題が発生しなければソフトウェア的に動作の継続は可能ですが、これに関連するライブラリなども古いバージョンのサポートを切るタイミングが出てくるので遅かれ早かれ影響は出てきます。 また AWS のマネージドサービス (ex.RDS/ElastiCache/OpenSearch) では、サポート期限の終了に伴い強制的に最新バージョンへの更新がスケジュールされます。 「最新バージョンへと更新してくれる」、その言葉だけ見ると素晴らしいものですが、もちろん更新中に発生するダウンタイムや接続するアプリケーションに対する影響まで面倒は見てくれません。 そのため、マネージドだろうが非マネージドだろうがバージョンアップ対応は必ず行う必要があると言うことです。 作業の内容 この作業は単純にリソースのバージョンアップをするだけで済む作業ではありません。 前述でのダウンタイムやバージョン間による変更差分によりアプリケーションが今まで通り動いているかを保証する必要があるため、下記をセットで実施することでシステム稼働を担保しています。 新旧バージョンの変更履歴を把握 変更によるアプリケーション影響の把握 アプリケーションの動作チェック 負荷チェック 移行計画の策定 移行作業の実施 取り組み 1.予測/計画 これらの作業は決して少ない工数では無く、システムやリソースの増加に伴って作業量も増えていく一方です。 AWS であれば EOL 通知はメール等で行われるため今までは通知が来てから計画を立てるというフローを採っていましたが、対象システムの増加に伴うリソース増により上記内容を期限内に消化するのが困難になってきています。 さらに RDS for MySQL に関してはバージョンあたりのサポート期限が短縮傾向にあるため、一度バージョンを上げればこの先数年は安泰といった状態でも無くなってきています。 この状態を踏まえて、2023 年からは通知が来る前に先手を打つ方針に切り替えました。 いつ何が起きるのか？（どれがいつ EOL を迎えるのか？）を事前に把握し、それを元に逆算し計画をすることで無駄の無い行動を目指すというものです。 対象リソースのリストアップ まずは各システムが利用するリソースのバージョンと EOL をリストアップし、自分たちが抱えるシステムとリソースの全量とそれらのバージョンがどういった状態なのかを把握します。 ここから各バージョンの EOL 時期を収集することになるのですが、幸いバージョン EOL については個々の公式サイトで明記されていることが多いので把握はそれほど難しくはありませんでした。 ex.) Ruby Java AWS RDS/MySQL AWS といったマネージドサービスに対しては公式の EOL と必ずしもイコールにはなりませんが、マネージドサービス側が公式 EOL より期限が早いことは無いので、公式 EOL を期限として考えるようにしています。 また公式サイトが見つからない/明記されていないといったものが稀にあり、それらは endoflife.date というサイトを活用しました。 優先度の決定 リストアップした時点でかなりの量に及ぶため、ここから対応優先度を決定します。 最優先とすべきポイントとしては、期限を迎えると強制的にバージョンアップされてしまうマネージドサービス系のリソースです。 これらについては切られた期限に対する猶予は基本与えられないため、優先度が一番高いものと考えます。 次点として EC2 に自前でインストールするようなリソースが続きます。これは最悪 EOL を迎えても動作は継続できるため、上記よりは優先度を下げています。 後はこれらの 優先度/EOL の 2 軸で対応順を検討し、2023 年の年間スケジュールに落とし込みました。 効果 2023 年 8 月の時点で、AWS のマネージドサービス系のリソースについては通知を受ける前にバージョン追従作業を済ませることができています。 特に 2023 年 10 月に EOL を迎える RDS の MySQL5.7 → MySQL8.0 対応は大変大きな規模の作業になりましたが、対象 4 サービス、DB インスタンス十数台を 2023 年 7 月に無事すべて切り替えることができました。 途中 AWS では OpenSearch や ElastiCache の緊急セキュリティアップデート対応が突発で入りましたが、全ての計画において先手というバッファを見込んでいたため予定を大きく狂わせず完了することができています。 取り組み 2.突発作業の削減 先程は計画を立てて無駄のない行動を目指すことを目的としていましたが、どれだけ予測や計画の精度を上げた所で突発作業はどうしても発生します。 社内からの要因であれば対処の仕方もありますが、外部要因となると予測も対応も困難であるものが多くなります。 特に「何も変更していないのに急に動かなくなった！」が一番脅威で、OS 仕様変更や外部ライブラリの廃止に伴うものがチームの実績として多く感じています。 こういった外部要因による事象を発生させにくい状態にするため、以下の対策を行っています。 PrivateGem サーバの構築 ジョブメドレーは Ruby で動くアプリケーションですが、外部ライブラリとして多数の Gem を併用しています。 この Gem がある日突然リポジトリから削除され bundle install が通らず起動しない、といったことが稀にありました。 バージョンアップで対応できるものであればまだ良いのですが、そもそも廃止といった状況だと対応の長期化は必至。 そういった事態を避けるため Geminabox にて PrivateGem サーバを構築しました。 このサーバは RubyGems 向けの Proxy/キャッシュサーバ という位置づけで、このサーバ経由で RubyGems に Gem を取得すると同時にサーバ内にも Gem はキャッシュします。 キャッシュされた Gem については以降 RubyGems に再度取りに行くことは無いため、RubyGems 上で取得できない事態が発生しても喫緊の対応が必要な状況にはなりません。 動作環境の Docker イメージ化 とある Python によるプログラムを対象としているのですが OS/Python バージョン/Pip ライブラリ の兼ね合いがとても厳しく、少しでもバージョンにズレが生じると動作不良を起こし対応に回るといったことが年〜半年に一度発生していました。 動作環境としては プログラム開始時に EC2 起動 コードのダウンロード ライブラリのインストール プログラム実行 プログラム終了後に EC2 停止 という形態を取っていましたが、それぞれのステップに於いて毎度同じ環境になる保証がない状態というのが大きな課題でした。 具体的には EC2 の起動時は Amazon Linux 2 の仕様で Python のバージョンが変わって動かない、ライブラリのインストールではバージョン固定が甘くある日バージョンが変わって動かなくなる、といったことが起こる再現性の低い仕組みで組まれている状態です。 そこで、毎回同じ動作環境を維持するための取り組みとして Docker イメージによる環境の固定化を行いました。 これは Docker イメージによって OS を固定した上でイメージ内にコード/ライブラリまでを含めてしまうもので、OS 起動からプログラムの起動まですべて同じ状態になるようにしました。 また副産物としてプログラム起動までのステップが短縮され、プログラム起動までのオーバヘッドの短縮にも繋げることができました。 効果 双方の仕組みの導入により、今年は対象システム回りでの突発作業は発生しない状態を維持できています。 最後に 今回は SRE Unit の業務の一つであるバージョン追従対応についてフォーカスを当てて紹介しましたが、抱える業務は他にも多数あります。 我々 SRE Unit の目的はサイトの安定稼働/信頼性を維持することであり、今回のようなバージョンアップはその中の一部でしかありません。この他にも負荷の監視やパフォーマンスチューニング、障害対応などを取り組むべきことは山ほどあります。 まだチームの人数は決して多くは無いこの現状で、いかにアイデア/技術/仕組み化によって効率的に動けるか切磋琢磨し、より安定したサービスを提供できるように日々取り組んでいます。 もしこれらの取り組みに興味のある方は、是非我々と一緒に働きませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp