はじめに エンジニアの山田です。 弊社の ニュースリリース にあるのですが、ジョブメドレーアカデミー(以下、アカデミー)では Azure OpenAI Service の GPT モデルを駆使した新機能「 研修作成アシスタント 」をリリースしています。 この生成 AI を活用した機能により研修作成担当者の作業時間を 75%軽減し、業務効率化に寄与するものになっています。 今回はこの研修作成アシスタントの開発について、担当した二人に話を聞きました。 インタビュイー紹介 岸田さん SES 企業で業務システム開発、オフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。アカデミーのプロダクトに関する各施策を統括して管理している。 徳永さん 2022 年メドレーに新卒入社。 入社時からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。現在は自身も開発をしながら開発のリードにも挑戦している。 左: 岸田さん 右: 徳永さん ジョブメドレーアカデミーのサービス概要 ── 今回アカデミーで採用した生成 AI を用いた新機能について話をしていきたいと思います。その前にアカデミーについてはこのブログでも何度か取り上げていますが、改めてアカデミーというプロダクトがどのようなサービス内容なのか教えてもらってもよいでしょうか? 岸田 : アカデミーの概要としては、現在「介護」「障がい福祉」「訪問歯科」「在宅調剤」という **4 つの業種に対応した「オンライン動画研修サービス」**となります。 研修については、導入してくださっている顧客である介護施設側が、1 つ 1 つ研修内容に合わせてアカデミーに登録されている動画を組み合わせてカリキュラムを決めていき、職員の方たちはそれらの動画を見て、研修を受けてレポートを書いたりできるプロダクトになります。これに付随して研修そのものを計画したり管理できたりする、というとイメージしやすいでしょうか。 ── 介護施設の研修業務を効率化するというプロダクトですね。どのようなミッションを持って、開発しているんですか? 岸田 : 大前提として、提供している 研修によって施設で働く人のスキルアップに役立たせる 、という目的があります。それ以外では BtoB のサービスなので 介護施設の事業効率化という点も重要視 しています。本来、施設の本業は「介護」になるので、そこに本質的には関係しないような管理業務などは、アカデミーを使うことによって効率的に作業ができるようになる、というところを目指しています。 最近の業務内容 ── 介護施設が「介護」以外に時間を取られているという課題を解決するプロダクトなんですね。そんなアカデミーでお二人は現在どのような業務をされているのでしょう。 徳永 : 私は直近はチームとしてアカデミーの機能の一番コアな部分である研修システムの割り当ての改修をしています。今までは、施設職員への研修割り当ての機能が、小規模の施設だと少し使い勝手が悪く自由度が高くない機能だったんですが、その割り当て自由度を高めるためにコードレベルでばっさりと書き換えをするというプロジェクトを エンジニア 7 人 + プロダクトマネージャ 1 人で進めており、そのプロジェクトの開発リード をしています。 最初は 5 人で始めたプロジェクトでしたが、プロジェクト自体のボリュームも増えてきて現在の人数になりました。このプロジェクトは 11 月中のリリース予定になっています。 ── かなり大きい規模のプロジェクトのリードをされているんですね! 岸田さんはいかがですか? 岸田 : 私は最近は開発に直接携わるよりも、プロダクト全体の方針決めなどをメインの業務にしています。次のクォーターではどんな開発をするべきか、来年はどのようにプロダクトを発展させていくかなどを考えるという仕事ですね。他にはアカデミーに在籍しているプロダクトマネージャ達の企画の精査だとか、コードレビューなどをしています。 ── メンバーのピープルマネジメントなどは引き続きやっていらっしゃるんですか? 岸田 : はい、そちらも引き続きやっています。全員の 1on1 などは最近は他のリードの方にお願いしていたりもします。 徳永 : 現在のプロジェクトのメンバーの 1on1 は自分が担当させてもらっていることが多いです。主に話をする内容は開発に関する提案やディスカッションになります。 生成 AI を活用した研修作成アシスタントについて 機能の概要について ── ありがとうございます。最近のお二人のお仕事が分かったところで、本題である生成 AI を利用した「研修作成アシスタント」機能についてお話を伺えればと思います。ニュースリリースにも書いてあるのですが、こちらの機能の説明をざっくりとお願いしてよいでしょうか。 岸田 : 先程のサービス説明のときにもお話したのですが、研修を考えるときには施設の方は「どういった研修にするか」を考える必要があります。「どんなテーマの研修にするか」「今月は制度で決まっているから、この研修をしないといけない」など色々な理由はあるんですが、テーマが決まって研修を実施するまでに「テーマに合った動画を探して選択する」というプロセスが入ります。 プロセスとしては他に「いつ誰に受けてもらうか決める」などもあるのですが、 研修カリキュラムを作成する一番のペインは「テーマに合った動画を探して選択する」という部分 なんです。 今までは、この「動画を選択する機能」としては以下の 2 つをプロダクトとしては用意していました。 メドレー社内で選定された動画を研修のプリセットとして使える機能（頻出する研修のみ） 一つひとつ動画を選んでオリジナルな研修を作成する機能 この 2 つだと 0 か 100 かみたいな形で中間となる 50 にあたる機能がなく、ここに相当する セミオーダーメイドのような機能が欲しいというのが以前からプロダクトで抱えていたニーズ だったんです。 今回提供した「研修作成アシスタント」機能では、 大まかにどんな研修をやりたいかを研修名として入力してもらえれば、そこから生成 AI が「研修で具体的に学んでほしいこと」（研修の目的）や、「目的にマッチする動画」を提案 してくれます。 管理者の方には生成 AI が提案してくる内容を取捨選択・訂正していただく形になっています。 これによって既存の機能が抱えていた「多様なニーズへの対応ができない」「研修作成に時間がかかり過ぎる」という両方の課題を解決する機能というイメージです。 そもそもこの機能を開発した理由 ── 「研修作成アシスタント」ですが、元々はどういった経緯で開発をすることになったんでしょうか。 岸田 : アカデミーのサービスとしてのウリの 1 つでもあるんですが、動画を内製していてその数も 6,500 本以上に上ります。多くの場合 1 つの研修につき 5 本ほどの動画を設定するのですが、 数千本の動画の中から研修にぴったりと合った動画を見つけ出すのは大変な作業 でした。 徳永 : 研修を作るのに一番大事なのが動画選びなのは間違いないのですが、その他にも研修の目標を考えるのも同じくらい大事です。そもそも目標がないと、受講者もどういう背景でやる研修なのかが分からなかったり、 「目標設定をして研修をする」ことが介護保険の加算要件に入っている場合もある ので、この目標設定は大事なんですが、こちらも 1 から考えるとなると中々に苦労する部分だったりしていました。 ── 研修動画を選ぶのも、目標設定をするのも今までコストがかかっていたということですね。 徳永 : こららのコストを何とか減らせないかというところが開発の立脚点になっています。研修名だけは考えてもらえれば、あとはこちらで自動生成して提案しますよという形になれば、 プロダクトが便利になるなという予感 がありました。 アカデミーのサービス特性と ChatGPT の相性の良さ ── 実際に作業時間を 75%削減する機能となっており便利になっていますもんね。この機能の開発に ChatGPT を使っていますが、どうして ChatGPT を選んだんですか? 徳永 : この機能を作ろうと動き出したのが、2023 年 3 月くらいだったのですが、時期的にちょうど GPT-4 が出るか出ないかというところでした。ですので、Google Bard など他の選択肢がそもそもなかった状態だったというのが理由の 1 つであります。 あとは Azure のほうは生成系 AI を使っても、こちらのデータは学習に使われない環境を提供していて、プライバシーの側面も考えると、しっかりと業務で使える環境が整っていたのが ChatGPT だった…という感じでしたので、選びました。 ── こうした新しい技術へ向き合う姿勢という点ではどういったものがありましたか? 徳永 : 今回特に ChatGPT など生成 AI が盛り上がってきたタイミングで、このまま行くと 生成 AI が使われていないと事業としても不利になっていくタイミングが来る んじゃないかなと考えました。一度触れてみて、技術の進化の分岐点ではないかと感じたので、このタイミングでちゃんと社内の効率化みたいなものをやりたいと最初は考えていました。 ── 社内でオペレーションをする方向けの機能を最初は考えていたということでしょうか。 岸田 : そうです。アカデミーでは動画は内製しているため、企画の素案作りだとか動画の説明文を生成することなどを最初は考えていたんですが、アカデミーのプロダクトとして価値を高めるため**「社内ではなくて顧客向けの機能にしても良いのでないか」**と思い直したんです。 こうした点も考えると、生成 AI の導入によるデメリットというものがメリットに比べて限りなく少ないという判断ができましたので、元々課題として考えていた研修生成に使うことを決めました。 徳永 : 最初は日本でも生成 AI をプロダクトに取り込んでいるのは数件程度ということもあったので、さっと取り入れてしまったほうがメリットがあると感じました。 研修作成アシスタントができるまで ── 最初はどんな感じで企画など進行したんでしょう? 徳永 : 最初は現在アカデミーで感じる課題に対して生成 AI でどのようなソリューションが出せるのかを思考実験という感じで Confluence （社内 wiki）にいくつか並行してまとめていきました。その中で一番費用対効果が高いというか、生成 AI を使わない従来の技術だと一番太刀打ちができない課題が「研修作成アシスタント」の機能でした。 岸田 : 生成 AI を使わない場合のアプローチは考えてはいたんですが、結局のところ 検索を高性能にしていくか、おすすめをパッケージングするくらいしか効率的に動画を探す方法が見出せずにいました 。 ── 動画の検索を高性能にということだと…検索に使うメタ情報をちゃんと用意して…というような手段になりそうですね。 徳永 : アカデミーの動画だと説明文などが、必要最低限しか記録されていないことが多く、動画内の情報を取ってくるのも難しかったのです。ですので、中々コストがかかってきて改善が現実的じゃなかったんですが**「生成 AI を使えばこの問題を解決できそう」という感触がありました**。 ── なるほど、一番解決が難しい問題を生成 AI でコストを最小限で解決できそうということだったんですね。こうした企画から実際に実装するまではどんな進行をしたんですか? 岸田 : 最初は徳永さんと、もう 1 名のエンジニアとで 1 週間くらい検証作業をしていました。実際にちゃんとできるのかや、精度として顧客が満足するくらいまで出せるのかなどを検証していました。 ある程度行けそうという目星が立ったのですが、その途中で先程の動画の説明文不足が、障害になるというのも分かってきました。これを解決するために Google の Speech-to-Text を使って動画内の文字起こしを自動でできるようにしてメタ情報を作るようにしたり、ベクトル検索ができるような外部サービスを導入した んです。それだけだと精度が低かったので、生成したメタ情報をさらに ChatGPT で整形するような方式を取りました。 これらを DB に入れてベクトル検索をかけるようにして検索時に目標やタイトルと関連付けて検索できるようにしたという流れです。 ── なるほど 3 段構えくらいで機能を実現しているんですね。 徳永 : とはいえ生成 AI は API の出力結果が若干不安定だったりするので、どこで最初はエラーが出たのかというのが分かりにくかったりしたので苦労しました。検索も今の形になるまでは OpenSearch の全文検索を使ったりしたんですが、検索精度が低かったりして紆余曲折はありました。そこから今の形式になり精度を高めて、合計 1 ヶ月くらいでチューニングまで含めてリリースしたという感じです。 今回のプロジェクトでの経験で学んだこと ── 今回のプロジェクトで良い経験だったと思う点はどんなものがありますか? 徳永 : 今回はあまり先行事例もないですし、調査と検証を繰り返していました。途中で色々問題も出たりしたのですが、やっぱり 未知の状態で物事を進めるにはひたすら PDCA を回していくのが一番良いんだなということを学びました 。 元々大学での研究が対話 AI などだったので、言語モデルをどう扱えばよいかなどの知識があったのは良かったなと思いましたね。 ── では今回のプロジェクトに適任だったんですね! 岸田 : あと学んだことではないですが、今回のプロジェクトの副産物としてベクトル化した動画の メタ情報が手に入ったんで、これを発展させてまたユーザへ価値提供できる機能が作れるなというのは良かった点 でした。 今後のアカデミーの技術的な方向性 ── これから解決していきたいアカデミーの技術的な課題のようなものってありますか? 岸田 : 今回初めてプロダクトに生成 AI を導入しましたが、 プロダクトの他の機能にも取り入れることができないかなどは導入前よりスムーズに考えられるようになったので、ぜひ検討していきたい です。また、発展してディベロッパーエクスペリエンスの向上などに使えないかなども考えたいと思います。 徳永 : ちょっと話が AI ではなくなりますが、アカデミーのコードベースは DDD を行いつつ開発しているのですが、こちらの構造を もっと最適化し、新しくアサインされたエンジニアもよりスムーズに開発できるようにしたい なとは考えています。 ── ありがとうございました! さいごに 元々アカデミー開発チームは、責任を持ってチャレンジしていこうという雰囲気があったと思うのですが、今回の ChatGPT を使った機能開発にもそうしたチームの雰囲気が良く作用しているなとインタビューをしていて感じました。 また生成 AI の導入も「新しくブームになりそうだから取り入れる」という考えではなく「日頃から解決を考えていた課題を解決できそうだ」という視点から導入していたのが印象的でした。 こんな雰囲気のアカデミー開発チームに興味が出た方は、ぜひカジュアルにお話しましょう! https://www.medley.jp/jobs/

はじめに エンジニアの山田です。 弊社の ニュースリリース にあるのですが、ジョブメドレーアカデミー(以下、アカデミー)では Azure OpenAI Service の GPT モデルを駆使した新機能「 研修作成アシスタント 」をリリースしています。 この生成 AI を活用した機能により研修作成担当者の作業時間を 75%軽減し、業務効率化に寄与するものになっています。 今回はこの研修作成アシスタントの開発について、担当した二人に話を聞きました。 インタビュイー紹介 岸田さん SES 企業で業務システム開発、オフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。アカデミーのプロダクトに関する各施策を統括して管理している。 徳永さん 2022 年メドレーに新卒入社。 入社時からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。現在は自身も開発をしながら開発のリードにも挑戦している。 左: 岸田さん 右: 徳永さん ジョブメドレーアカデミーのサービス概要 ── 今回アカデミーで採用した生成 AI を用いた新機能について話をしていきたいと思います。その前にアカデミーについてはこのブログでも何度か取り上げていますが、改めてアカデミーというプロダクトがどのようなサービス内容なのか教えてもらってもよいでしょうか? 岸田 : アカデミーの概要としては、現在「介護」「障がい福祉」「訪問歯科」「在宅調剤」という **4 つの業種に対応した「オンライン動画研修サービス」**となります。 研修については、導入してくださっている顧客である介護施設側が、1 つ 1 つ研修内容に合わせてアカデミーに登録されている動画を組み合わせてカリキュラムを決めていき、職員の方たちはそれらの動画を見て、研修を受けてレポートを書いたりできるプロダクトになります。これに付随して研修そのものを計画したり管理できたりする、というとイメージしやすいでしょうか。 ── 介護施設の研修業務を効率化するというプロダクトですね。どのようなミッションを持って、開発しているんですか? 岸田 : 大前提として、提供している 研修によって施設で働く人のスキルアップに役立たせる 、という目的があります。それ以外では BtoB のサービスなので 介護施設の事業効率化という点も重要視 しています。本来、施設の本業は「介護」になるので、そこに本質的には関係しないような管理業務などは、アカデミーを使うことによって効率的に作業ができるようになる、というところを目指しています。 最近の業務内容 ── 介護施設が「介護」以外に時間を取られているという課題を解決するプロダクトなんですね。そんなアカデミーでお二人は現在どのような業務をされているのでしょう。 徳永 : 私は直近はチームとしてアカデミーの機能の一番コアな部分である研修システムの割り当ての改修をしています。今までは、施設職員への研修割り当ての機能が、小規模の施設だと少し使い勝手が悪く自由度が高くない機能だったんですが、その割り当て自由度を高めるためにコードレベルでばっさりと書き換えをするというプロジェクトを エンジニア 7 人 + プロダクトマネージャ 1 人で進めており、そのプロジェクトの開発リード をしています。 最初は 5 人で始めたプロジェクトでしたが、プロジェクト自体のボリュームも増えてきて現在の人数になりました。このプロジェクトは 11 月中のリリース予定になっています。 ── かなり大きい規模のプロジェクトのリードをされているんですね! 岸田さんはいかがですか? 岸田 : 私は最近は開発に直接携わるよりも、プロダクト全体の方針決めなどをメインの業務にしています。次のクォーターではどんな開発をするべきか、来年はどのようにプロダクトを発展させていくかなどを考えるという仕事ですね。他にはアカデミーに在籍しているプロダクトマネージャ達の企画の精査だとか、コードレビューなどをしています。 ── メンバーのピープルマネジメントなどは引き続きやっていらっしゃるんですか? 岸田 : はい、そちらも引き続きやっています。全員の 1on1 などは最近は他のリードの方にお願いしていたりもします。 徳永 : 現在のプロジェクトのメンバーの 1on1 は自分が担当させてもらっていることが多いです。主に話をする内容は開発に関する提案やディスカッションになります。 生成 AI を活用した研修作成アシスタントについて 機能の概要について ── ありがとうございます。最近のお二人のお仕事が分かったところで、本題である生成 AI を利用した「研修作成アシスタント」機能についてお話を伺えればと思います。ニュースリリースにも書いてあるのですが、こちらの機能の説明をざっくりとお願いしてよいでしょうか。 岸田 : 先程のサービス説明のときにもお話したのですが、研修を考えるときには施設の方は「どういった研修にするか」を考える必要があります。「どんなテーマの研修にするか」「今月は制度で決まっているから、この研修をしないといけない」など色々な理由はあるんですが、テーマが決まって研修を実施するまでに「テーマに合った動画を探して選択する」というプロセスが入ります。 プロセスとしては他に「いつ誰に受けてもらうか決める」などもあるのですが、 研修カリキュラムを作成する一番のペインは「テーマに合った動画を探して選択する」という部分 なんです。 今までは、この「動画を選択する機能」としては以下の 2 つをプロダクトとしては用意していました。 メドレー社内で選定された動画を研修のプリセットとして使える機能（頻出する研修のみ） 一つひとつ動画を選んでオリジナルな研修を作成する機能 この 2 つだと 0 か 100 かみたいな形で中間となる 50 にあたる機能がなく、ここに相当する セミオーダーメイドのような機能が欲しいというのが以前からプロダクトで抱えていたニーズ だったんです。 今回提供した「研修作成アシスタント」機能では、 大まかにどんな研修をやりたいかを研修名として入力してもらえれば、そこから生成 AI が「研修で具体的に学んでほしいこと」（研修の目的）や、「目的にマッチする動画」を提案 してくれます。 管理者の方には生成 AI が提案してくる内容を取捨選択・訂正していただく形になっています。 これによって既存の機能が抱えていた「多様なニーズへの対応ができない」「研修作成に時間がかかり過ぎる」という両方の課題を解決する機能というイメージです。 そもそもこの機能を開発した理由 ── 「研修作成アシスタント」ですが、元々はどういった経緯で開発をすることになったんでしょうか。 岸田 : アカデミーのサービスとしてのウリの 1 つでもあるんですが、動画を内製していてその数も 6,500 本以上に上ります。多くの場合 1 つの研修につき 5 本ほどの動画を設定するのですが、 数千本の動画の中から研修にぴったりと合った動画を見つけ出すのは大変な作業 でした。 徳永 : 研修を作るのに一番大事なのが動画選びなのは間違いないのですが、その他にも研修の目標を考えるのも同じくらい大事です。そもそも目標がないと、受講者もどういう背景でやる研修なのかが分からなかったり、 「目標設定をして研修をする」ことが介護保険の加算要件に入っている場合もある ので、この目標設定は大事なんですが、こちらも 1 から考えるとなると中々に苦労する部分だったりしていました。 ── 研修動画を選ぶのも、目標設定をするのも今までコストがかかっていたということですね。 徳永 : こららのコストを何とか減らせないかというところが開発の立脚点になっています。研修名だけは考えてもらえれば、あとはこちらで自動生成して提案しますよという形になれば、 プロダクトが便利になるなという予感 がありました。 アカデミーのサービス特性と ChatGPT の相性の良さ ── 実際に作業時間を 75%削減する機能となっており便利になっていますもんね。この機能の開発に ChatGPT を使っていますが、どうして ChatGPT を選んだんですか? 徳永 : この機能を作ろうと動き出したのが、2023 年 3 月くらいだったのですが、時期的にちょうど GPT-4 が出るか出ないかというところでした。ですので、Google Bard など他の選択肢がそもそもなかった状態だったというのが理由の 1 つであります。 あとは Azure のほうは生成系 AI を使っても、こちらのデータは学習に使われない環境を提供していて、プライバシーの側面も考えると、しっかりと業務で使える環境が整っていたのが ChatGPT だった…という感じでしたので、選びました。 ── こうした新しい技術へ向き合う姿勢という点ではどういったものがありましたか? 徳永 : 今回特に ChatGPT など生成 AI が盛り上がってきたタイミングで、このまま行くと 生成 AI が使われていないと事業としても不利になっていくタイミングが来る んじゃないかなと考えました。一度触れてみて、技術の進化の分岐点ではないかと感じたので、このタイミングでちゃんと社内の効率化みたいなものをやりたいと最初は考えていました。 ── 社内でオペレーションをする方向けの機能を最初は考えていたということでしょうか。 岸田 : そうです。アカデミーでは動画は内製しているため、企画の素案作りだとか動画の説明文を生成することなどを最初は考えていたんですが、アカデミーのプロダクトとして価値を高めるため**「社内ではなくて顧客向けの機能にしても良いのでないか」**と思い直したんです。 こうした点も考えると、生成 AI の導入によるデメリットというものがメリットに比べて限りなく少ないという判断ができましたので、元々課題として考えていた研修生成に使うことを決めました。 徳永 : 最初は日本でも生成 AI をプロダクトに取り込んでいるのは数件程度ということもあったので、さっと取り入れてしまったほうがメリットがあると感じました。 研修作成アシスタントができるまで ── 最初はどんな感じで企画など進行したんでしょう? 徳永 : 最初は現在アカデミーで感じる課題に対して生成 AI でどのようなソリューションが出せるのかを思考実験という感じで Confluence （社内 wiki）にいくつか並行してまとめていきました。その中で一番費用対効果が高いというか、生成 AI を使わない従来の技術だと一番太刀打ちができない課題が「研修作成アシスタント」の機能でした。 岸田 : 生成 AI を使わない場合のアプローチは考えてはいたんですが、結局のところ 検索を高性能にしていくか、おすすめをパッケージングするくらいしか効率的に動画を探す方法が見出せずにいました 。 ── 動画の検索を高性能にということだと…検索に使うメタ情報をちゃんと用意して…というような手段になりそうですね。 徳永 : アカデミーの動画だと説明文などが、必要最低限しか記録されていないことが多く、動画内の情報を取ってくるのも難しかったのです。ですので、中々コストがかかってきて改善が現実的じゃなかったんですが**「生成 AI を使えばこの問題を解決できそう」という感触がありました**。 ── なるほど、一番解決が難しい問題を生成 AI でコストを最小限で解決できそうということだったんですね。こうした企画から実際に実装するまではどんな進行をしたんですか? 岸田 : 最初は徳永さんと、もう 1 名のエンジニアとで 1 週間くらい検証作業をしていました。実際にちゃんとできるのかや、精度として顧客が満足するくらいまで出せるのかなどを検証していました。 ある程度行けそうという目星が立ったのですが、その途中で先程の動画の説明文不足が、障害になるというのも分かってきました。これを解決するために Google の Speech-to-Text を使って動画内の文字起こしを自動でできるようにしてメタ情報を作るようにしたり、ベクトル検索ができるような外部サービスを導入した んです。それだけだと精度が低かったので、生成したメタ情報をさらに ChatGPT で整形するような方式を取りました。 これらを DB に入れてベクトル検索をかけるようにして検索時に目標やタイトルと関連付けて検索できるようにしたという流れです。 ── なるほど 3 段構えくらいで機能を実現しているんですね。 徳永 : とはいえ生成 AI は API の出力結果が若干不安定だったりするので、どこで最初はエラーが出たのかというのが分かりにくかったりしたので苦労しました。検索も今の形になるまでは OpenSearch の全文検索を使ったりしたんですが、検索精度が低かったりして紆余曲折はありました。そこから今の形式になり精度を高めて、合計 1 ヶ月くらいでチューニングまで含めてリリースしたという感じです。 今回のプロジェクトでの経験で学んだこと ── 今回のプロジェクトで良い経験だったと思う点はどんなものがありますか? 徳永 : 今回はあまり先行事例もないですし、調査と検証を繰り返していました。途中で色々問題も出たりしたのですが、やっぱり 未知の状態で物事を進めるにはひたすら PDCA を回していくのが一番良いんだなということを学びました 。 元々大学での研究が対話 AI などだったので、言語モデルをどう扱えばよいかなどの知識があったのは良かったなと思いましたね。 ── では今回のプロジェクトに適任だったんですね! 岸田 : あと学んだことではないですが、今回のプロジェクトの副産物としてベクトル化した動画の メタ情報が手に入ったんで、これを発展させてまたユーザへ価値提供できる機能が作れるなというのは良かった点 でした。 今後のアカデミーの技術的な方向性 ── これから解決していきたいアカデミーの技術的な課題のようなものってありますか? 岸田 : 今回初めてプロダクトに生成 AI を導入しましたが、 プロダクトの他の機能にも取り入れることができないかなどは導入前よりスムーズに考えられるようになったので、ぜひ検討していきたい です。また、発展してディベロッパーエクスペリエンスの向上などに使えないかなども考えたいと思います。 徳永 : ちょっと話が AI ではなくなりますが、アカデミーのコードベースは DDD を行いつつ開発しているのですが、こちらの構造を もっと最適化し、新しくアサインされたエンジニアもよりスムーズに開発できるようにしたい なとは考えています。 ── ありがとうございました! さいごに 元々アカデミー開発チームは、責任を持ってチャレンジしていこうという雰囲気があったと思うのですが、今回の ChatGPT を使った機能開発にもそうしたチームの雰囲気が良く作用しているなとインタビューをしていて感じました。 また生成 AI の導入も「新しくブームになりそうだから取り入れる」という考えではなく「日頃から解決を考えていた課題を解決できそうだ」という視点から導入していたのが印象的でした。 こんな雰囲気のアカデミー開発チームに興味が出た方は、ぜひカジュアルにお話しましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに エンジニアの山田です。 弊社の ニュースリリース にあるのですが、ジョブメドレーアカデミー(以下、アカデミー)では Azure OpenAI Service の GPT モデルを駆使した新機能「 研修作成アシスタント 」をリリースしています。 この生成 AI を活用した機能により研修作成担当者の作業時間を 75%軽減し、業務効率化に寄与するものになっています。 今回はこの研修作成アシスタントの開発について、担当した二人に話を聞きました。 インタビュイー紹介 岸田さん SES 企業で業務システム開発、オフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。アカデミーのプロダクトに関する各施策を統括して管理している。 徳永さん 2022 年メドレーに新卒入社。 入社時からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。現在は自身も開発をしながら開発のリードにも挑戦している。 左: 岸田さん 右: 徳永さん ジョブメドレーアカデミーのサービス概要 ── 今回アカデミーで採用した生成 AI を用いた新機能について話をしていきたいと思います。その前にアカデミーについてはこのブログでも何度か取り上げていますが、改めてアカデミーというプロダクトがどのようなサービス内容なのか教えてもらってもよいでしょうか? 岸田 : アカデミーの概要としては、現在「介護」「障がい福祉」「訪問歯科」「在宅調剤」という **4 つの業種に対応した「オンライン動画研修サービス」**となります。 研修については、導入してくださっている顧客である介護施設側が、1 つ 1 つ研修内容に合わせてアカデミーに登録されている動画を組み合わせてカリキュラムを決めていき、職員の方たちはそれらの動画を見て、研修を受けてレポートを書いたりできるプロダクトになります。これに付随して研修そのものを計画したり管理できたりする、というとイメージしやすいでしょうか。 ── 介護施設の研修業務を効率化するというプロダクトですね。どのようなミッションを持って、開発しているんですか? 岸田 : 大前提として、提供している 研修によって施設で働く人のスキルアップに役立たせる 、という目的があります。それ以外では BtoB のサービスなので 介護施設の事業効率化という点も重要視 しています。本来、施設の本業は「介護」になるので、そこに本質的には関係しないような管理業務などは、アカデミーを使うことによって効率的に作業ができるようになる、というところを目指しています。 最近の業務内容 ── 介護施設が「介護」以外に時間を取られているという課題を解決するプロダクトなんですね。そんなアカデミーでお二人は現在どのような業務をされているのでしょう。 徳永 : 私は直近はチームとしてアカデミーの機能の一番コアな部分である研修システムの割り当ての改修をしています。今までは、施設職員への研修割り当ての機能が、小規模の施設だと少し使い勝手が悪く自由度が高くない機能だったんですが、その割り当て自由度を高めるためにコードレベルでばっさりと書き換えをするというプロジェクトを エンジニア 7 人 + プロダクトマネージャ 1 人で進めており、そのプロジェクトの開発リード をしています。 最初は 5 人で始めたプロジェクトでしたが、プロジェクト自体のボリュームも増えてきて現在の人数になりました。このプロジェクトは 11 月中のリリース予定になっています。 ── かなり大きい規模のプロジェクトのリードをされているんですね! 岸田さんはいかがですか? 岸田 : 私は最近は開発に直接携わるよりも、プロダクト全体の方針決めなどをメインの業務にしています。次のクォーターではどんな開発をするべきか、来年はどのようにプロダクトを発展させていくかなどを考えるという仕事ですね。他にはアカデミーに在籍しているプロダクトマネージャ達の企画の精査だとか、コードレビューなどをしています。 ── メンバーのピープルマネジメントなどは引き続きやっていらっしゃるんですか? 岸田 : はい、そちらも引き続きやっています。全員の 1on1 などは最近は他のリードの方にお願いしていたりもします。 徳永 : 現在のプロジェクトのメンバーの 1on1 は自分が担当させてもらっていることが多いです。主に話をする内容は開発に関する提案やディスカッションになります。 生成 AI を活用した研修作成アシスタントについて 機能の概要について ── ありがとうございます。最近のお二人のお仕事が分かったところで、本題である生成 AI を利用した「研修作成アシスタント」機能についてお話を伺えればと思います。ニュースリリースにも書いてあるのですが、こちらの機能の説明をざっくりとお願いしてよいでしょうか。 岸田 : 先程のサービス説明のときにもお話したのですが、研修を考えるときには施設の方は「どういった研修にするか」を考える必要があります。「どんなテーマの研修にするか」「今月は制度で決まっているから、この研修をしないといけない」など色々な理由はあるんですが、テーマが決まって研修を実施するまでに「テーマに合った動画を探して選択する」というプロセスが入ります。 プロセスとしては他に「いつ誰に受けてもらうか決める」などもあるのですが、 研修カリキュラムを作成する一番のペインは「テーマに合った動画を探して選択する」という部分 なんです。 今までは、この「動画を選択する機能」としては以下の 2 つをプロダクトとしては用意していました。 メドレー社内で選定された動画を研修のプリセットとして使える機能（頻出する研修のみ） 一つひとつ動画を選んでオリジナルな研修を作成する機能 この 2 つだと 0 か 100 かみたいな形で中間となる 50 にあたる機能がなく、ここに相当する セミオーダーメイドのような機能が欲しいというのが以前からプロダクトで抱えていたニーズ だったんです。 今回提供した「研修作成アシスタント」機能では、 大まかにどんな研修をやりたいかを研修名として入力してもらえれば、そこから生成 AI が「研修で具体的に学んでほしいこと」（研修の目的）や、「目的にマッチする動画」を提案 してくれます。 管理者の方には生成 AI が提案してくる内容を取捨選択・訂正していただく形になっています。 これによって既存の機能が抱えていた「多様なニーズへの対応ができない」「研修作成に時間がかかり過ぎる」という両方の課題を解決する機能というイメージです。 そもそもこの機能を開発した理由 ── 「研修作成アシスタント」ですが、元々はどういった経緯で開発をすることになったんでしょうか。 岸田 : アカデミーのサービスとしてのウリの 1 つでもあるんですが、動画を内製していてその数も 6,500 本以上に上ります。多くの場合 1 つの研修につき 5 本ほどの動画を設定するのですが、 数千本の動画の中から研修にぴったりと合った動画を見つけ出すのは大変な作業 でした。 徳永 : 研修を作るのに一番大事なのが動画選びなのは間違いないのですが、その他にも研修の目標を考えるのも同じくらい大事です。そもそも目標がないと、受講者もどういう背景でやる研修なのかが分からなかったり、 「目標設定をして研修をする」ことが介護保険の加算要件に入っている場合もある ので、この目標設定は大事なんですが、こちらも 1 から考えるとなると中々に苦労する部分だったりしていました。 ── 研修動画を選ぶのも、目標設定をするのも今までコストがかかっていたということですね。 徳永 : こららのコストを何とか減らせないかというところが開発の立脚点になっています。研修名だけは考えてもらえれば、あとはこちらで自動生成して提案しますよという形になれば、 プロダクトが便利になるなという予感 がありました。 アカデミーのサービス特性と ChatGPT の相性の良さ ── 実際に作業時間を 75%削減する機能となっており便利になっていますもんね。この機能の開発に ChatGPT を使っていますが、どうして ChatGPT を選んだんですか? 徳永 : この機能を作ろうと動き出したのが、2023 年 3 月くらいだったのですが、時期的にちょうど GPT-4 が出るか出ないかというところでした。ですので、Google Bard など他の選択肢がそもそもなかった状態だったというのが理由の 1 つであります。 あとは Azure のほうは生成系 AI を使っても、こちらのデータは学習に使われない環境を提供していて、プライバシーの側面も考えると、しっかりと業務で使える環境が整っていたのが ChatGPT だった…という感じでしたので、選びました。 ── こうした新しい技術へ向き合う姿勢という点ではどういったものがありましたか? 徳永 : 今回特に ChatGPT など生成 AI が盛り上がってきたタイミングで、このまま行くと 生成 AI が使われていないと事業としても不利になっていくタイミングが来る んじゃないかなと考えました。一度触れてみて、技術の進化の分岐点ではないかと感じたので、このタイミングでちゃんと社内の効率化みたいなものをやりたいと最初は考えていました。 ── 社内でオペレーションをする方向けの機能を最初は考えていたということでしょうか。 岸田 : そうです。アカデミーでは動画は内製しているため、企画の素案作りだとか動画の説明文を生成することなどを最初は考えていたんですが、アカデミーのプロダクトとして価値を高めるため**「社内ではなくて顧客向けの機能にしても良いのでないか」**と思い直したんです。 こうした点も考えると、生成 AI の導入によるデメリットというものがメリットに比べて限りなく少ないという判断ができましたので、元々課題として考えていた研修生成に使うことを決めました。 徳永 : 最初は日本でも生成 AI をプロダクトに取り込んでいるのは数件程度ということもあったので、さっと取り入れてしまったほうがメリットがあると感じました。 研修作成アシスタントができるまで ── 最初はどんな感じで企画など進行したんでしょう? 徳永 : 最初は現在アカデミーで感じる課題に対して生成 AI でどのようなソリューションが出せるのかを思考実験という感じで Confluence （社内 wiki）にいくつか並行してまとめていきました。その中で一番費用対効果が高いというか、生成 AI を使わない従来の技術だと一番太刀打ちができない課題が「研修作成アシスタント」の機能でした。 岸田 : 生成 AI を使わない場合のアプローチは考えてはいたんですが、結局のところ 検索を高性能にしていくか、おすすめをパッケージングするくらいしか効率的に動画を探す方法が見出せずにいました 。 ── 動画の検索を高性能にということだと…検索に使うメタ情報をちゃんと用意して…というような手段になりそうですね。 徳永 : アカデミーの動画だと説明文などが、必要最低限しか記録されていないことが多く、動画内の情報を取ってくるのも難しかったのです。ですので、中々コストがかかってきて改善が現実的じゃなかったんですが**「生成 AI を使えばこの問題を解決できそう」という感触がありました**。 ── なるほど、一番解決が難しい問題を生成 AI でコストを最小限で解決できそうということだったんですね。こうした企画から実際に実装するまではどんな進行をしたんですか? 岸田 : 最初は徳永さんと、もう 1 名のエンジニアとで 1 週間くらい検証作業をしていました。実際にちゃんとできるのかや、精度として顧客が満足するくらいまで出せるのかなどを検証していました。 ある程度行けそうという目星が立ったのですが、その途中で先程の動画の説明文不足が、障害になるというのも分かってきました。これを解決するために Google の Speech-to-Text を使って動画内の文字起こしを自動でできるようにしてメタ情報を作るようにしたり、ベクトル検索ができるような外部サービスを導入した んです。それだけだと精度が低かったので、生成したメタ情報をさらに ChatGPT で整形するような方式を取りました。 これらを DB に入れてベクトル検索をかけるようにして検索時に目標やタイトルと関連付けて検索できるようにしたという流れです。 ── なるほど 3 段構えくらいで機能を実現しているんですね。 徳永 : とはいえ生成 AI は API の出力結果が若干不安定だったりするので、どこで最初はエラーが出たのかというのが分かりにくかったりしたので苦労しました。検索も今の形になるまでは OpenSearch の全文検索を使ったりしたんですが、検索精度が低かったりして紆余曲折はありました。そこから今の形式になり精度を高めて、合計 1 ヶ月くらいでチューニングまで含めてリリースしたという感じです。 今回のプロジェクトでの経験で学んだこと ── 今回のプロジェクトで良い経験だったと思う点はどんなものがありますか? 徳永 : 今回はあまり先行事例もないですし、調査と検証を繰り返していました。途中で色々問題も出たりしたのですが、やっぱり 未知の状態で物事を進めるにはひたすら PDCA を回していくのが一番良いんだなということを学びました 。 元々大学での研究が対話 AI などだったので、言語モデルをどう扱えばよいかなどの知識があったのは良かったなと思いましたね。 ── では今回のプロジェクトに適任だったんですね! 岸田 : あと学んだことではないですが、今回のプロジェクトの副産物としてベクトル化した動画の メタ情報が手に入ったんで、これを発展させてまたユーザへ価値提供できる機能が作れるなというのは良かった点 でした。 今後のアカデミーの技術的な方向性 ── これから解決していきたいアカデミーの技術的な課題のようなものってありますか? 岸田 : 今回初めてプロダクトに生成 AI を導入しましたが、 プロダクトの他の機能にも取り入れることができないかなどは導入前よりスムーズに考えられるようになったので、ぜひ検討していきたい です。また、発展してディベロッパーエクスペリエンスの向上などに使えないかなども考えたいと思います。 徳永 : ちょっと話が AI ではなくなりますが、アカデミーのコードベースは DDD を行いつつ開発しているのですが、こちらの構造を もっと最適化し、新しくアサインされたエンジニアもよりスムーズに開発できるようにしたい なとは考えています。 ── ありがとうございました! さいごに 元々アカデミー開発チームは、責任を持ってチャレンジしていこうという雰囲気があったと思うのですが、今回の ChatGPT を使った機能開発にもそうしたチームの雰囲気が良く作用しているなとインタビューをしていて感じました。 また生成 AI の導入も「新しくブームになりそうだから取り入れる」という考えではなく「日頃から解決を考えていた課題を解決できそうだ」という視点から導入していたのが印象的でした。 こんな雰囲気のアカデミー開発チームに興味が出た方は、ぜひカジュアルにお話しましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに エンジニアの山田です。 弊社の ニュースリリース にあるのですが、ジョブメドレーアカデミー(以下、アカデミー)では Azure OpenAI Service の GPT モデルを駆使した新機能「 研修作成アシスタント 」をリリースしています。 この生成 AI を活用した機能により研修作成担当者の作業時間を 75%軽減し、業務効率化に寄与するものになっています。 今回はこの研修作成アシスタントの開発について、担当した二人に話を聞きました。 インタビュイー紹介 岸田さん SES 企業で業務システム開発、オフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。アカデミーのプロダクトに関する各施策を統括して管理している。 徳永さん 2022 年メドレーに新卒入社。 入社時からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。現在は自身も開発をしながら開発のリードにも挑戦している。 左: 岸田さん 右: 徳永さん ジョブメドレーアカデミーのサービス概要 ── 今回アカデミーで採用した生成 AI を用いた新機能について話をしていきたいと思います。その前にアカデミーについてはこのブログでも何度か取り上げていますが、改めてアカデミーというプロダクトがどのようなサービス内容なのか教えてもらってもよいでしょうか? 岸田 : アカデミーの概要としては、現在「介護」「障がい福祉」「訪問歯科」「在宅調剤」という **4 つの業種に対応した「オンライン動画研修サービス」**となります。 研修については、導入してくださっている顧客である介護施設側が、1 つ 1 つ研修内容に合わせてアカデミーに登録されている動画を組み合わせてカリキュラムを決めていき、職員の方たちはそれらの動画を見て、研修を受けてレポートを書いたりできるプロダクトになります。これに付随して研修そのものを計画したり管理できたりする、というとイメージしやすいでしょうか。 ── 介護施設の研修業務を効率化するというプロダクトですね。どのようなミッションを持って、開発しているんですか? 岸田 : 大前提として、提供している 研修によって施設で働く人のスキルアップに役立たせる 、という目的があります。それ以外では BtoB のサービスなので 介護施設の事業効率化という点も重要視 しています。本来、施設の本業は「介護」になるので、そこに本質的には関係しないような管理業務などは、アカデミーを使うことによって効率的に作業ができるようになる、というところを目指しています。 最近の業務内容 ── 介護施設が「介護」以外に時間を取られているという課題を解決するプロダクトなんですね。そんなアカデミーでお二人は現在どのような業務をされているのでしょう。 徳永 : 私は直近はチームとしてアカデミーの機能の一番コアな部分である研修システムの割り当ての改修をしています。今までは、施設職員への研修割り当ての機能が、小規模の施設だと少し使い勝手が悪く自由度が高くない機能だったんですが、その割り当て自由度を高めるためにコードレベルでばっさりと書き換えをするというプロジェクトを エンジニア 7 人 + プロダクトマネージャ 1 人で進めており、そのプロジェクトの開発リード をしています。 最初は 5 人で始めたプロジェクトでしたが、プロジェクト自体のボリュームも増えてきて現在の人数になりました。このプロジェクトは 11 月中のリリース予定になっています。 ── かなり大きい規模のプロジェクトのリードをされているんですね! 岸田さんはいかがですか? 岸田 : 私は最近は開発に直接携わるよりも、プロダクト全体の方針決めなどをメインの業務にしています。次のクォーターではどんな開発をするべきか、来年はどのようにプロダクトを発展させていくかなどを考えるという仕事ですね。他にはアカデミーに在籍しているプロダクトマネージャ達の企画の精査だとか、コードレビューなどをしています。 ── メンバーのピープルマネジメントなどは引き続きやっていらっしゃるんですか? 岸田 : はい、そちらも引き続きやっています。全員の 1on1 などは最近は他のリードの方にお願いしていたりもします。 徳永 : 現在のプロジェクトのメンバーの 1on1 は自分が担当させてもらっていることが多いです。主に話をする内容は開発に関する提案やディスカッションになります。 生成 AI を活用した研修作成アシスタントについて 機能の概要について ── ありがとうございます。最近のお二人のお仕事が分かったところで、本題である生成 AI を利用した「研修作成アシスタント」機能についてお話を伺えればと思います。ニュースリリースにも書いてあるのですが、こちらの機能の説明をざっくりとお願いしてよいでしょうか。 岸田 : 先程のサービス説明のときにもお話したのですが、研修を考えるときには施設の方は「どういった研修にするか」を考える必要があります。「どんなテーマの研修にするか」「今月は制度で決まっているから、この研修をしないといけない」など色々な理由はあるんですが、テーマが決まって研修を実施するまでに「テーマに合った動画を探して選択する」というプロセスが入ります。 プロセスとしては他に「いつ誰に受けてもらうか決める」などもあるのですが、 研修カリキュラムを作成する一番のペインは「テーマに合った動画を探して選択する」という部分 なんです。 今までは、この「動画を選択する機能」としては以下の 2 つをプロダクトとしては用意していました。 メドレー社内で選定された動画を研修のプリセットとして使える機能（頻出する研修のみ） 一つひとつ動画を選んでオリジナルな研修を作成する機能 この 2 つだと 0 か 100 かみたいな形で中間となる 50 にあたる機能がなく、ここに相当する セミオーダーメイドのような機能が欲しいというのが以前からプロダクトで抱えていたニーズ だったんです。 今回提供した「研修作成アシスタント」機能では、 大まかにどんな研修をやりたいかを研修名として入力してもらえれば、そこから生成 AI が「研修で具体的に学んでほしいこと」（研修の目的）や、「目的にマッチする動画」を提案 してくれます。 管理者の方には生成 AI が提案してくる内容を取捨選択・訂正していただく形になっています。 これによって既存の機能が抱えていた「多様なニーズへの対応ができない」「研修作成に時間がかかり過ぎる」という両方の課題を解決する機能というイメージです。 そもそもこの機能を開発した理由 ── 「研修作成アシスタント」ですが、元々はどういった経緯で開発をすることになったんでしょうか。 岸田 : アカデミーのサービスとしてのウリの 1 つでもあるんですが、動画を内製していてその数も 6,500 本以上に上ります。多くの場合 1 つの研修につき 5 本ほどの動画を設定するのですが、 数千本の動画の中から研修にぴったりと合った動画を見つけ出すのは大変な作業 でした。 徳永 : 研修を作るのに一番大事なのが動画選びなのは間違いないのですが、その他にも研修の目標を考えるのも同じくらい大事です。そもそも目標がないと、受講者もどういう背景でやる研修なのかが分からなかったり、 「目標設定をして研修をする」ことが介護保険の加算要件に入っている場合もある ので、この目標設定は大事なんですが、こちらも 1 から考えるとなると中々に苦労する部分だったりしていました。 ── 研修動画を選ぶのも、目標設定をするのも今までコストがかかっていたということですね。 徳永 : こららのコストを何とか減らせないかというところが開発の立脚点になっています。研修名だけは考えてもらえれば、あとはこちらで自動生成して提案しますよという形になれば、 プロダクトが便利になるなという予感 がありました。 アカデミーのサービス特性と ChatGPT の相性の良さ ── 実際に作業時間を 75%削減する機能となっており便利になっていますもんね。この機能の開発に ChatGPT を使っていますが、どうして ChatGPT を選んだんですか? 徳永 : この機能を作ろうと動き出したのが、2023 年 3 月くらいだったのですが、時期的にちょうど GPT-4 が出るか出ないかというところでした。ですので、Google Bard など他の選択肢がそもそもなかった状態だったというのが理由の 1 つであります。 あとは Azure のほうは生成系 AI を使っても、こちらのデータは学習に使われない環境を提供していて、プライバシーの側面も考えると、しっかりと業務で使える環境が整っていたのが ChatGPT だった…という感じでしたので、選びました。 ── こうした新しい技術へ向き合う姿勢という点ではどういったものがありましたか? 徳永 : 今回特に ChatGPT など生成 AI が盛り上がってきたタイミングで、このまま行くと 生成 AI が使われていないと事業としても不利になっていくタイミングが来る んじゃないかなと考えました。一度触れてみて、技術の進化の分岐点ではないかと感じたので、このタイミングでちゃんと社内の効率化みたいなものをやりたいと最初は考えていました。 ── 社内でオペレーションをする方向けの機能を最初は考えていたということでしょうか。 岸田 : そうです。アカデミーでは動画は内製しているため、企画の素案作りだとか動画の説明文を生成することなどを最初は考えていたんですが、アカデミーのプロダクトとして価値を高めるため**「社内ではなくて顧客向けの機能にしても良いのでないか」**と思い直したんです。 こうした点も考えると、生成 AI の導入によるデメリットというものがメリットに比べて限りなく少ないという判断ができましたので、元々課題として考えていた研修生成に使うことを決めました。 徳永 : 最初は日本でも生成 AI をプロダクトに取り込んでいるのは数件程度ということもあったので、さっと取り入れてしまったほうがメリットがあると感じました。 研修作成アシスタントができるまで ── 最初はどんな感じで企画など進行したんでしょう? 徳永 : 最初は現在アカデミーで感じる課題に対して生成 AI でどのようなソリューションが出せるのかを思考実験という感じで Confluence （社内 wiki）にいくつか並行してまとめていきました。その中で一番費用対効果が高いというか、生成 AI を使わない従来の技術だと一番太刀打ちができない課題が「研修作成アシスタント」の機能でした。 岸田 : 生成 AI を使わない場合のアプローチは考えてはいたんですが、結局のところ 検索を高性能にしていくか、おすすめをパッケージングするくらいしか効率的に動画を探す方法が見出せずにいました 。 ── 動画の検索を高性能にということだと…検索に使うメタ情報をちゃんと用意して…というような手段になりそうですね。 徳永 : アカデミーの動画だと説明文などが、必要最低限しか記録されていないことが多く、動画内の情報を取ってくるのも難しかったのです。ですので、中々コストがかかってきて改善が現実的じゃなかったんですが**「生成 AI を使えばこの問題を解決できそう」という感触がありました**。 ── なるほど、一番解決が難しい問題を生成 AI でコストを最小限で解決できそうということだったんですね。こうした企画から実際に実装するまではどんな進行をしたんですか? 岸田 : 最初は徳永さんと、もう 1 名のエンジニアとで 1 週間くらい検証作業をしていました。実際にちゃんとできるのかや、精度として顧客が満足するくらいまで出せるのかなどを検証していました。 ある程度行けそうという目星が立ったのですが、その途中で先程の動画の説明文不足が、障害になるというのも分かってきました。これを解決するために Google の Speech-to-Text を使って動画内の文字起こしを自動でできるようにしてメタ情報を作るようにしたり、ベクトル検索ができるような外部サービスを導入した んです。それだけだと精度が低かったので、生成したメタ情報をさらに ChatGPT で整形するような方式を取りました。 これらを DB に入れてベクトル検索をかけるようにして検索時に目標やタイトルと関連付けて検索できるようにしたという流れです。 ── なるほど 3 段構えくらいで機能を実現しているんですね。 徳永 : とはいえ生成 AI は API の出力結果が若干不安定だったりするので、どこで最初はエラーが出たのかというのが分かりにくかったりしたので苦労しました。検索も今の形になるまでは OpenSearch の全文検索を使ったりしたんですが、検索精度が低かったりして紆余曲折はありました。そこから今の形式になり精度を高めて、合計 1 ヶ月くらいでチューニングまで含めてリリースしたという感じです。 今回のプロジェクトでの経験で学んだこと ── 今回のプロジェクトで良い経験だったと思う点はどんなものがありますか? 徳永 : 今回はあまり先行事例もないですし、調査と検証を繰り返していました。途中で色々問題も出たりしたのですが、やっぱり 未知の状態で物事を進めるにはひたすら PDCA を回していくのが一番良いんだなということを学びました 。 元々大学での研究が対話 AI などだったので、言語モデルをどう扱えばよいかなどの知識があったのは良かったなと思いましたね。 ── では今回のプロジェクトに適任だったんですね! 岸田 : あと学んだことではないですが、今回のプロジェクトの副産物としてベクトル化した動画の メタ情報が手に入ったんで、これを発展させてまたユーザへ価値提供できる機能が作れるなというのは良かった点 でした。 今後のアカデミーの技術的な方向性 ── これから解決していきたいアカデミーの技術的な課題のようなものってありますか? 岸田 : 今回初めてプロダクトに生成 AI を導入しましたが、 プロダクトの他の機能にも取り入れることができないかなどは導入前よりスムーズに考えられるようになったので、ぜひ検討していきたい です。また、発展してディベロッパーエクスペリエンスの向上などに使えないかなども考えたいと思います。 徳永 : ちょっと話が AI ではなくなりますが、アカデミーのコードベースは DDD を行いつつ開発しているのですが、こちらの構造を もっと最適化し、新しくアサインされたエンジニアもよりスムーズに開発できるようにしたい なとは考えています。 ── ありがとうございました! さいごに 元々アカデミー開発チームは、責任を持ってチャレンジしていこうという雰囲気があったと思うのですが、今回の ChatGPT を使った機能開発にもそうしたチームの雰囲気が良く作用しているなとインタビューをしていて感じました。 また生成 AI の導入も「新しくブームになりそうだから取り入れる」という考えではなく「日頃から解決を考えていた課題を解決できそうだ」という視点から導入していたのが印象的でした。 こんな雰囲気のアカデミー開発チームに興味が出た方は、ぜひカジュアルにお話しましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 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

はじめに みなさん、こんにちは。エンジニアの新居です。今回は今年の 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

はじめに みなさん、こんにちは。エンジニアの新居です。今回は今年の 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

はじめに みなさん、こんにちは。エンジニアの新居です。今回は今年の 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