はじめに みなさん、こんにちは。エンジニアの新居です。今回は 2022 年新卒入社したエンジニア達にインタビューした記事をお送りします。 この 1 年で彼らがどのような業務を経験してきたのかや、リアルな現在の立ち位置などをお伝えしたいと考えています。 それでは、ご覧ください! 自己紹介 飯田さん 研修後は ジョブメドレー で顧客向けの機能開発を担当。その後 シゴトーク でインフラ領域を中心にリニューアルに従事する。現在は Jobley で施策の開発やインフラ周りまで幅広く業務を担当。 飯田さん 岡田さん 研修後はジョブメドレーでの開発業務を担当後、シゴトークへ。ジョブメドレーとの連携強化のプロジェクトなど経験し、現在はシゴトークの開発全般を担当。 岡田さん 徳永さん 研修後は ジョブメドレーアカデミー に配属。プロダクト改善などを担当しつつ、直近では生成 AI を使った機能の開発やバックエンドからモバイルまで幅広い開発に従事。 徳永さん 古川さん 研修後は Pharms に配属。フロントエンドからインフラまで幅広く担当。小規模施策の開発に始まり現在は中規模施策のプロジェクトリードをしながら開発を行なう。 古川さん 村上さん 研修後は CLINICS に配属。電子カルテ関連の開発を経て、現在は中規模施策のプロジェクトリードをしながら開発を行なう。 村上さん 吉岡さん 研修後は 患者アプリ CLINICS に配属。Web アプリとネイティブアプリの機能開発を担当した後、CLINICS に配属。現在は定常改善や、フロントエンドの大規模改修などに従事。 吉岡さん ファーストキャリアとしてメドレーを選んだ理由について ── まずはファーストキャリアにメドレーへ入社を決めた理由をお伺いしていきたいと思います。 飯田 : 元々ベンチャー気質が高いことを軸に会社選びをしていました。新卒入社の社員が多数いるような規模が大きい会社だと、自分がその中に埋もれてしまい、自由度が高い動きができなさそうだと考えていたからです。メドレーは新卒が少ないのでその辺りはマッチしていました。医療という領域に関しても、 日常生活に関わるところで社会に貢献できるような領域が良いなと考えていたことや、家族が看護師をやっていることもあり医療業界の課題を身近に感じられ、医療に対して興味があった ことが理由になっています。 岡田 : 自分の体調が悪くなることが昔から多かったためヘルスケア業界に興味があったのですが、そこに近い業界だったのがひとつの理由です。また会社のミッションがとても分かりやすかったというのがあります。他社に比べて、メドレーは 世の中を良くしてくという会社のビジョンに、ちゃんと基づいてプロダクトを開発している んだなというのが具体的に分かって一貫性を感じられたのが大きいです。 他には、「エンジニア」という職種だともちろん技術分野が専門領域になっていくわけですが、その領域に閉じず、プロダクトを中心に課題解決する上でエンジニアリング以外のことも考えながら開発をしているプロダクトファーストな考えも魅力的でした。 徳永 : 自分は岡田くんのように特にヘルスケア領域に興味があったということはなかったんです。どちらかというと、 エンジニアとしてこれから働いていく上で自分が大切にしたい志向や価値観というのが、メドレーのエンジニアの方達と話をしていく中でマッチする なと感じたのが大きいです。 それまでも色々な会社さんとの選考をしていたんですが、メドレーのエンジニアは「本質を追い求める」という姿勢の元、エンジニアリングが好きで、それをプロダクトへ還元していくという部分が自分のフィーリングにあったという感じでした。 ── フィーリングに合ったということですが、他にもマッチすると思った部分はありましたか? 徳永 : エンジニアの雰囲気も大人な感じの方が多く、体育会系の「気合と根性で頑張る」という進め方ではなく、合理的に物事を進めるために必要なコミュニケーションをきちんと取っていくところなどが魅力でした。そうした部分も含めて自分が働いている将来というのが想像できました。 古川 : 自分は親が薬剤師で医療分野に元々興味があり、医療 x IT という軸で就活をしていく過程でメドレーを知ったのが最初の出会いでした。お話を聞いていくうちに「課題解決のためのプロダクト作り」という点が非常に魅力に感じました。社会を良くするためにプロダクトを良くしていこうという姿勢で会社に一体感が生まれているのが、すごく良いなと。 会社に限らないかもしれないですが、組織も人が多くなってくるとやっぱり方向性が少しずつズレていくという感じになりがちだと思うんですが、メドレーの場合は 会社として「医療業界をもっと良くしていくための事業をしていく」という軸が通っている のを感じて、最終的にはこの部分に惹かれて入社を決めました。 あとは、上場企業という「安心感」もファーストキャリアの選択に影響しました。 岡田 : 自分も新卒入社の社員目線だと、入社する会社の安定感というのは重要だと思っていました。 村上 : 就活する前は特定の業界に限らず色々な会社を見ていました。学生時代に様々な業界のエンジニアインターンやアルバイトなどしていたのですが、その過程で「せっかく正社員で働くなら、より社会的意義がある事業をやるべきだな」と感じました。そうした意識で就活に臨んで 自分が興味を持って取り組めそうなのは医療業界だなと思った のが最初のきっかけでした。 メドレーは選考の中で、技術領域を問わずに開発できることなどがマッチすると感じたのと、サービスが医療機関だけでなく患者側も充実しているということも入社の決め手になりました。自分が患者になることも多いので、とても課題が分かりやすかったんです。 吉岡 : 自分も元々エンタメなどの領域より、医療や教育、金融領域を中心に就活をしていました。中でもメドレーの「医療ヘルスケアの未来をつくる」というミッションへの自分の共感度が非常に高かったのが、入社の理由でした。日本の医療制度をきちんと維持するためのプロダクトを作っていくんだという姿勢が非常に良かったです。 またさきほどの話にも出ていましたが、 医療機関のためのプロダクトと患者のためのプロダクトという両面へのアプローチをしている のも決め手でした。やはり医療費の問題などは医療機関だけへのアプローチでは解決できないと思うので、そういう意味でも一貫性が感じられて良かったです。 現在のチーム内での役割について ── では次に現在のチームでの皆さんの役割や動き方、チームメンバーとの関わり方について聞いていきたいと思います。 飯田 : 現在 Jobley の開発チームではエンジニアが 4 人いるのですが、その内 2 人がプロダクト施策の立案を行ないつつ、自分を含む残りの 2 人が実装をメインにして開発を行なっています。状況に合わせ PM 兼任のエンジニアと実装担当のエンジニアとで二人三脚で開発をしたり、単独での開発を行なったりと柔軟に対応していってます。 チームメンバーとの関わりという点では、 エンジニアチームだけで開発するということはなく、セールスやカスタマーサクセスの方たちと一緒に要件を詰めていく ことが最近は多いです。そのためセールスの業務フローなどもキャッチアップする必要があるので大変ですが、面白くやりがいを感じるところでもありますね。 岡田 : シゴトークでは、PM とエンジニアの二人三脚という体制で開発をしています。PM と日々要件を刷り合わせながら、実装は自分が行なっていていくというスタイルです。Pull Request のレビューだけは元々シゴトークを開発されていたエンジニアの方々にお願いしています。 また、例えばプロダクトのセキュリティ強化の取り組みやアプリの認証機能の一新、QA 環境の整備など、自分が普段触れない領域の施策を行った際はスキルアップを実感できました。ライブラリのアップデートや、リファクタリングなども 裁量を持ってやらせてもらっています 。 徳永 : ジョブメドレーアカデミーはジョブメドレーや CLINICS に比べると小規模なチーム構成となっています。エンジニアが 7 人、PM が 3 人、プロダクトオーナーが 1 人という体制で開発をしてるのですが、 良い意味で新卒入社エンジニアとして裁量を持って開発をさせてもらっています 。 開発チームも徐々に大きくなっているので、タスクを上手く回すための仕組みを考えたり、チームを上手く機能させるために朝会の構成を変更してみたり。技術的な部分では CI/CD など開発全体に関わる分野についても、任せてもらっています。 また ニュースリリース にもなりましたが、社内で初めての 生成 AI を使った機能の開発 は、プロダクトオーナーと自分の 2 人が中心になって進めていきました。 開発に入る前段階でロジカルに「こういった課題をこの機能で解決していく」ということが伝えられれば、ある程度技術的に実験的なものも導入することができる環境です 。 古川 : Pharms では現在エンジニアが 4 人、PM 1 人、デザイナーが 1 人というのが中心メンバーとなっています。Pharms は現在色々と機能拡大をしていっているのですが、エンジニアが 4 人なので本当に全員で何でもやっていくという感じで開発しています。とはいえ、メンバー各々で得意分野は違うので、得意なところは積極的に拾いに行く感じです。 自分はと言うと、得意分野のインフラ部分に関してはほとんど任せてもらっており、自分からの発信で先輩のテックリードエンジニアの方とすり合わせしながら色々な施策を行なっています。その他にもクォーター毎に数個は中・大規模な施策が計画されるので、そうしたもののいくつかのリードをさせてもらったりしています。ですので、 アプリケーションの開発という面でもプロジェクトを上手く進行させるという面でも、とても楽しく業務をしています 。 村上 : CLINICS ではまず「基幹」と「周辺」とざっくり 2 つのチームに分かれており、「基幹」が主にレセコン(レセプトコンピュータの略。医療施設から健康保険組合などの支払い機関に対し、診療報酬を請求するために、電子カルテと連動してレセプトと呼ばれる診療報酬明細書を作成するシステム)とのやりとりを、「周辺」では予約や問診、資格確認など CLINICS と患者との接点となるシステム、という形で担当業務が分かれています。自分はずっと基幹チームにアサインされています。チーム全対応のエンジニアの内訳はアプリケーション担当が 6~7 人、インフラ担当が 3 人ほどになっています。 現在は大きなプロジェクトが 1 つ進行していて、既存のレセコンをメドレーで新規開発しているレセコンに移行するというものですが、その中に 中規模なプロジェクトが複数平行して進んでいて、その内のいくつかを自分がリード させてもらっています。 リードしているプロジェクトの進行管理やチームメンバー間での問題共有方法などを考えているのですが、この辺りは挑戦できる幅が広く、難しいですが面白いと感じています。課題についてプロジェクトに限定せず、他のシステムや進捗状況に影響がないかを配慮する必要があり、そうした視点で適切に異なる立場の関係者を巻き込むことで、より包括的な解決策を導き出そうと意識をしています。 吉岡 : 自分は今は村上と一緒のチームで業務をしているんですが、レセコンなどの部分というよりは、先程の話の「周辺」の開発をすることが多いです。基本的に平行して複数のプロジェクトが走っており、それぞれのプロジェクトでディレクター 1 人、エンジニア数人、他にデザイナーという形で進めていくことが多いです。 大まかにディレクターが要件などをまとめたものをベースとして、その後にデザイナーやエンジニアも入って要件定義などをしていき、徐々に形にしていくという事が多いですね。 ── お二人で組んで仕事をすることもあるんですか? 村上 : はい、とても多いです。 進行しているプロジェクトの他にも、定常改善やバグ改修などのタスクがありますが、そうしたタスクを「どのタイミングで」「どの優先度で」対応していくかなどをチーム内で議論してから実施するので。 吉岡 : プロジェクトやそうしたタスクとは別に、エンジニア主導で大規模なリファクタリングなども行なっています。担当しているプロジェクトの他にそうしたものを手がけていて、一緒になることが多いです。 入社してメドレーの文化を強く意識した出来事 ── メドレーで働いている中で、特に文化を強く感じたエピソードなど聞いてみたいです。 飯田 : 開発に関係する人全員が「プロダクト志向が強い」ということでしょうか。具体的には、開発の要件定義段階から全員関わるので、もちろんビジネスサイドの方からも「こうした方が良いのではないか」というアイデアは出てきますが、開発サイドからも「どういう機能が一番ユーザに価値を届けられるか」という視点で一緒になって考えるんです。そもそもどういった課題を解決するものなのかという基礎の部分から一緒に考えていくのがメドレーでは当たり前になっているという感じがします。 開発サイドもビジネスサイドも同じ方向を向いているので、提案などもちゃんとロジカルで筋が通っているものであれば通るというのは、すごく意見しがいがある と思います。そのための相談なんかも、もちろんしやすいですし、とても良い文化だなと感じています。 岡田 : 開発にあたって PM が 施策などを Issue として立ててくれるのですが、言語化が行き届いていて何が問題で、どうして実施するのか、その影響なんかがすごく分かりやすいという点はメドレーが大事にしている「ドキュメントドリブン」という文化を感じます。 そのような環境なので、大抵のことは最低限の文章のやり取りだけでスムーズに進みますし、上手くいかない状況になっても善後策などが立てやすくなっていると思います。 徳永 : メドレーは新卒入社の社員数は少ないので、中途入社の方がほとんどという環境です。入社してすぐは「自分の意見は通るのかな」とか「自分より後に入社した経験年数が長い中途入社の方とどう付き合おう」などが心配でした。でも メドレーでは「建設的に進める」という文化があるので、立場に関係なく議論できる環境があるので、とても仕事がしやすい です。自分の意見が例え間違っていたとしても議論が起きるということは、認識がズレていたということだからと軌道修正もできるので本当に働きやすいです。 また、とても良いなと思ったのが、部署や職種に関わらず Confluence の情報に誰でもアクセスできるという文化ですね。秘匿情報以外は基本的に全て Confluence でオープンになっているおかげで、自分とは直接関係ない部署の現在の動きなどがキャッチアップできるので、そういった人たちとコミュニケーションを取るときにもすごく助かります。 古川 : 徳永とかぶるところがあるんですが、「建設的に進める」という部分は非常にメドレーらしさを感じる文化です。例えば PM が「施策をこうしましょう」となっても、自分が「このフローってこうなった方が良いですよね」という意見を言えるし、そこを起点に 議論に発展してより良いものを作っていけるというのは本当に素晴らしい と感じています。 実際に自分がリードしていた施策の中でもエンジニア・ デザイナー・ PM ・カスタマーサクセスという立場が違うメンバー同士で改めて薬局の業務フローを整理しなおして、より良い仕様にできたりということがありました。 機能リリース後もちゃんと「あるべき姿」を目指して改善をできたりしたので、こういう考え方はとても仕事がしやすいです。 村上 : 自分からは「組織水準を高める」という文化について言及させてください。自分が関わっている電子カルテやレセコンという領域は深い業務知識が必要で、初めて関わった人からすると、そもそもどういうフローで機能が使われているかとか、特定の場合に何でこうなるんだろうというところが、理解しづらいんです。でも、自分のチームは新卒・中途問わず、まだ深いドメイン知識がない、といった状態からでも入って活躍しやすい環境だというのを感じています。 いきなり専門の業務知識が必要な開発というのはやはり難しいので、そうした部分と直接は関係しない周辺領域の開発から始めてもらって、徐々に電子カルテやレセコンに直接関係する開発に入ってもらえるようなオンボーディングができています。開発の中で、あるべき姿について議論になったりで色々なメンバーと話をしていくので、 医療業務のキャッチアップはかなりしやすい環境 だと思います。 もうひとつ「長期のカスタマー価値を追求する」という部分も文化を感じていて、主にマネージャーを含め、短期的な KPI に沿った開発よりも、長期的に顧客への価値提供に寄与できる開発を優先していくという意識が非常に強いのが良いと感じます。 特に今現在、社内で開発が進んでいる新規レセコンの開発については強く思いますね。 吉岡 : 自分が強く感じているメドレーの文化としては「ドキュメントドリブン」です。ミーティングなども、こういうことの結論を得るために協議する、というのが明確に分かる資料を事前に用意して行います。ですので、「これ何の時間だっけ?」みたいな状態になりにくいのが良いです。 あとは ミーティングによる同期的、Slack や Confluence などによる非同期のコミュニケーションを適材適所で全員が使いわけているので、そもそもコミュニケーションで無駄な行き違いのようなものも、ほとんど無い のも、仕事がしやすいと思っています。 もうひとつは、自分もやはりプロダクト志向の強さというところを感じています。現在はディレクターなどと一緒に開発をしていく体制になっているんですが、UI や顧客体験なども含めてエンジニアでも、ちゃんとプロダクトとしての理想の姿を考えて開発するという姿勢がとても強いです。自分の専門ではない領域でもきちんと考えながら開発をしていくので、やりがいがあります。 これからメドレーに入社する方へのメッセージ ── では最後になりますが、特に新卒でメドレーの入社を考えている方へのメッセージなどあれば、お伺いしたいです。 飯田 : そうですね、「先輩が新卒に対してとても期待してくれている」というのは伝えたいと思います。自分の場合、研修が終わって 3 ヶ月経ったぐらいで、シゴトークのインフラ環境を全部刷新するという大きなプロジェクトのリードを任せてもらえたんです。もちろん SRE の先輩などと協力しつつ進めたものだったんですが、 研修終わってすぐにそんな大きなプロジェクトを裁量持って進められるような環境なので、すごくやりがいがあります 。 岡田 : 稲本(人材プラットフォーム CTO)が「新卒だから」みたいな接し方をせずに、いちエンジニアとして接してくれているのは個人的に嬉しいポイントです。また 責任を持った上で裁量持って自由に動いていける業務環境があるのが、すごく良い です。ちゃんとプロダクトの事を考えて開発をしたい人にはおすすめできる環境だと思います。 徳永 : 新卒の良いところは「同期」感を持てるところかなと思います。今もランチ等でこのメンバーと技術的なところなどを気軽に相談できるのはとても良いです。 切磋琢磨していく環境じゃないかなと思っているので、そうした環境を求めるならすごく良い と思います。 古川 : 受け身で仕事を行うのではなく、ガツガツと自分の方から求めにいく姿勢の人には、すごくマッチする会社だと思います。せっかく裁量持って業務を進めることができる環境なので、 遠慮せずにがんがんと物事進めることができる人には最高 なんじゃないかと考えています。 自分はインフラだけではなくて、サーバやフロントエンドも開発していきたいと考えているんですが、小規模なプロジェクトであれば全て行える環境なため、自分一人でプロジェクトを完結することができるのは、性に合っているなと思ってます。周りのサポートや先輩との壁打ちなどはちゃんとやってもらえるので、とても勉強になり成長できると思います。 村上 : メドレーで開発をしていくについれて、医療ドメインという領域で自分が関わっていることが人の役に立っているんだなというのが日々実感できるところは良いです。特に色々な医療機関のサポートができるというプロダクトに関わっているので、直接医療機関やその先にいる患者さんの 役に立っているという実感は、正直 1 年目で感じられるものではないと思っていたので、良い驚き です。 また大きいデータを取り扱うという経験ができているのも貴重だなと感じています。現在のプロダクトでは契約医療機関も非常に多いですし、その大量のデータの設計を変更したりというところを、裁量持って実施できるのは良い経験になっています。 吉岡 : メドレーの「プロダクト志向」を持っている先輩エンジニアと働けるというのはとても良い経験だと思っています。一般的にはエンジニアは技術さえあればという感じになりやすかったりすると思うのですが、メドレーではもちろん新しい技術なども使いながら、それを いかにプロダクトやその先のユーザへの価値提供に繋げるかを考えている方が集っている ので、そういう思考でプロダクト開発ができているのはすごく勉強になります。 ── ありがとうございました! 本当に 1 年で皆さんが濃い業務経験を積んでいるのが分かるインタビューになりました。 さいごに それぞれ異なるチームや業務内容ですが、新卒エンジニアでも裁量を持って業務に臨めることや、プロダクトの重要な部分の開発にどんどん関わっていけることが伝わるインタビューとなりました。 メドレーは新卒入社のエンジニアも積極的に募集していますので、今回気になったという方はお気軽にカジュアル面談をしましょう! https://open.talentio.com/r/1/c/medley/pages/54863

はじめに みなさん、こんにちは。エンジニアの新居です。今回は 2022 年新卒入社したエンジニア達にインタビューした記事をお送りします。 この 1 年で彼らがどのような業務を経験してきたのかや、リアルな現在の立ち位置などをお伝えしたいと考えています。 それでは、ご覧ください! 自己紹介 飯田さん 研修後は ジョブメドレー で顧客向けの機能開発を担当。その後 シゴトーク でインフラ領域を中心にリニューアルに従事する。現在は Jobley で施策の開発やインフラ周りまで幅広く業務を担当。 飯田さん 岡田さん 研修後はジョブメドレーでの開発業務を担当後、シゴトークへ。ジョブメドレーとの連携強化のプロジェクトなど経験し、現在はシゴトークの開発全般を担当。 岡田さん 徳永さん 研修後は ジョブメドレーアカデミー に配属。プロダクト改善などを担当しつつ、直近では生成 AI を使った機能の開発やバックエンドからモバイルまで幅広い開発に従事。 徳永さん 古川さん 研修後は Pharms に配属。フロントエンドからインフラまで幅広く担当。小規模施策の開発に始まり現在は中規模施策のプロジェクトリードをしながら開発を行なう。 古川さん 村上さん 研修後は CLINICS に配属。電子カルテ関連の開発を経て、現在は中規模施策のプロジェクトリードをしながら開発を行なう。 村上さん 吉岡さん 研修後は 患者アプリ CLINICS に配属。Web アプリとネイティブアプリの機能開発を担当した後、CLINICS に配属。現在は定常改善や、フロントエンドの大規模改修などに従事。 吉岡さん ファーストキャリアとしてメドレーを選んだ理由について ── まずはファーストキャリアにメドレーへ入社を決めた理由をお伺いしていきたいと思います。 飯田 : 元々ベンチャー気質が高いことを軸に会社選びをしていました。新卒入社の社員が多数いるような規模が大きい会社だと、自分がその中に埋もれてしまい、自由度が高い動きができなさそうだと考えていたからです。メドレーは新卒が少ないのでその辺りはマッチしていました。医療という領域に関しても、 日常生活に関わるところで社会に貢献できるような領域が良いなと考えていたことや、家族が看護師をやっていることもあり医療業界の課題を身近に感じられ、医療に対して興味があった ことが理由になっています。 岡田 : 自分の体調が悪くなることが昔から多かったためヘルスケア業界に興味があったのですが、そこに近い業界だったのがひとつの理由です。また会社のミッションがとても分かりやすかったというのがあります。他社に比べて、メドレーは 世の中を良くしてくという会社のビジョンに、ちゃんと基づいてプロダクトを開発している んだなというのが具体的に分かって一貫性を感じられたのが大きいです。 他には、「エンジニア」という職種だともちろん技術分野が専門領域になっていくわけですが、その領域に閉じず、プロダクトを中心に課題解決する上でエンジニアリング以外のことも考えながら開発をしているプロダクトファーストな考えも魅力的でした。 徳永 : 自分は岡田くんのように特にヘルスケア領域に興味があったということはなかったんです。どちらかというと、 エンジニアとしてこれから働いていく上で自分が大切にしたい志向や価値観というのが、メドレーのエンジニアの方達と話をしていく中でマッチする なと感じたのが大きいです。 それまでも色々な会社さんとの選考をしていたんですが、メドレーのエンジニアは「本質を追い求める」という姿勢の元、エンジニアリングが好きで、それをプロダクトへ還元していくという部分が自分のフィーリングにあったという感じでした。 ── フィーリングに合ったということですが、他にもマッチすると思った部分はありましたか? 徳永 : エンジニアの雰囲気も大人な感じの方が多く、体育会系の「気合と根性で頑張る」という進め方ではなく、合理的に物事を進めるために必要なコミュニケーションをきちんと取っていくところなどが魅力でした。そうした部分も含めて自分が働いている将来というのが想像できました。 古川 : 自分は親が薬剤師で医療分野に元々興味があり、医療 x IT という軸で就活をしていく過程でメドレーを知ったのが最初の出会いでした。お話を聞いていくうちに「課題解決のためのプロダクト作り」という点が非常に魅力に感じました。社会を良くするためにプロダクトを良くしていこうという姿勢で会社に一体感が生まれているのが、すごく良いなと。 会社に限らないかもしれないですが、組織も人が多くなってくるとやっぱり方向性が少しずつズレていくという感じになりがちだと思うんですが、メドレーの場合は 会社として「医療業界をもっと良くしていくための事業をしていく」という軸が通っている のを感じて、最終的にはこの部分に惹かれて入社を決めました。 あとは、上場企業という「安心感」もファーストキャリアの選択に影響しました。 岡田 : 自分も新卒入社の社員目線だと、入社する会社の安定感というのは重要だと思っていました。 村上 : 就活する前は特定の業界に限らず色々な会社を見ていました。学生時代に様々な業界のエンジニアインターンやアルバイトなどしていたのですが、その過程で「せっかく正社員で働くなら、より社会的意義がある事業をやるべきだな」と感じました。そうした意識で就活に臨んで 自分が興味を持って取り組めそうなのは医療業界だなと思った のが最初のきっかけでした。 メドレーは選考の中で、技術領域を問わずに開発できることなどがマッチすると感じたのと、サービスが医療機関だけでなく患者側も充実しているということも入社の決め手になりました。自分が患者になることも多いので、とても課題が分かりやすかったんです。 吉岡 : 自分も元々エンタメなどの領域より、医療や教育、金融領域を中心に就活をしていました。中でもメドレーの「医療ヘルスケアの未来をつくる」というミッションへの自分の共感度が非常に高かったのが、入社の理由でした。日本の医療制度をきちんと維持するためのプロダクトを作っていくんだという姿勢が非常に良かったです。 またさきほどの話にも出ていましたが、 医療機関のためのプロダクトと患者のためのプロダクトという両面へのアプローチをしている のも決め手でした。やはり医療費の問題などは医療機関だけへのアプローチでは解決できないと思うので、そういう意味でも一貫性が感じられて良かったです。 現在のチーム内での役割について ── では次に現在のチームでの皆さんの役割や動き方、チームメンバーとの関わり方について聞いていきたいと思います。 飯田 : 現在 Jobley の開発チームではエンジニアが 4 人いるのですが、その内 2 人がプロダクト施策の立案を行ないつつ、自分を含む残りの 2 人が実装をメインにして開発を行なっています。状況に合わせ PM 兼任のエンジニアと実装担当のエンジニアとで二人三脚で開発をしたり、単独での開発を行なったりと柔軟に対応していってます。 チームメンバーとの関わりという点では、 エンジニアチームだけで開発するということはなく、セールスやカスタマーサクセスの方たちと一緒に要件を詰めていく ことが最近は多いです。そのためセールスの業務フローなどもキャッチアップする必要があるので大変ですが、面白くやりがいを感じるところでもありますね。 岡田 : シゴトークでは、PM とエンジニアの二人三脚という体制で開発をしています。PM と日々要件を刷り合わせながら、実装は自分が行なっていていくというスタイルです。Pull Request のレビューだけは元々シゴトークを開発されていたエンジニアの方々にお願いしています。 また、例えばプロダクトのセキュリティ強化の取り組みやアプリの認証機能の一新、QA 環境の整備など、自分が普段触れない領域の施策を行った際はスキルアップを実感できました。ライブラリのアップデートや、リファクタリングなども 裁量を持ってやらせてもらっています 。 徳永 : ジョブメドレーアカデミーはジョブメドレーや CLINICS に比べると小規模なチーム構成となっています。エンジニアが 7 人、PM が 3 人、プロダクトオーナーが 1 人という体制で開発をしてるのですが、 良い意味で新卒入社エンジニアとして裁量を持って開発をさせてもらっています 。 開発チームも徐々に大きくなっているので、タスクを上手く回すための仕組みを考えたり、チームを上手く機能させるために朝会の構成を変更してみたり。技術的な部分では CI/CD など開発全体に関わる分野についても、任せてもらっています。 また ニュースリリース にもなりましたが、社内で初めての 生成 AI を使った機能の開発 は、プロダクトオーナーと自分の 2 人が中心になって進めていきました。 開発に入る前段階でロジカルに「こういった課題をこの機能で解決していく」ということが伝えられれば、ある程度技術的に実験的なものも導入することができる環境です 。 古川 : Pharms では現在エンジニアが 4 人、PM 1 人、デザイナーが 1 人というのが中心メンバーとなっています。Pharms は現在色々と機能拡大をしていっているのですが、エンジニアが 4 人なので本当に全員で何でもやっていくという感じで開発しています。とはいえ、メンバー各々で得意分野は違うので、得意なところは積極的に拾いに行く感じです。 自分はと言うと、得意分野のインフラ部分に関してはほとんど任せてもらっており、自分からの発信で先輩のテックリードエンジニアの方とすり合わせしながら色々な施策を行なっています。その他にもクォーター毎に数個は中・大規模な施策が計画されるので、そうしたもののいくつかのリードをさせてもらったりしています。ですので、 アプリケーションの開発という面でもプロジェクトを上手く進行させるという面でも、とても楽しく業務をしています 。 村上 : CLINICS ではまず「基幹」と「周辺」とざっくり 2 つのチームに分かれており、「基幹」が主にレセコン(レセプトコンピュータの略。医療施設から健康保険組合などの支払い機関に対し、診療報酬を請求するために、電子カルテと連動してレセプトと呼ばれる診療報酬明細書を作成するシステム)とのやりとりを、「周辺」では予約や問診、資格確認など CLINICS と患者との接点となるシステム、という形で担当業務が分かれています。自分はずっと基幹チームにアサインされています。チーム全対応のエンジニアの内訳はアプリケーション担当が 6~7 人、インフラ担当が 3 人ほどになっています。 現在は大きなプロジェクトが 1 つ進行していて、既存のレセコンをメドレーで新規開発しているレセコンに移行するというものですが、その中に 中規模なプロジェクトが複数平行して進んでいて、その内のいくつかを自分がリード させてもらっています。 リードしているプロジェクトの進行管理やチームメンバー間での問題共有方法などを考えているのですが、この辺りは挑戦できる幅が広く、難しいですが面白いと感じています。課題についてプロジェクトに限定せず、他のシステムや進捗状況に影響がないかを配慮する必要があり、そうした視点で適切に異なる立場の関係者を巻き込むことで、より包括的な解決策を導き出そうと意識をしています。 吉岡 : 自分は今は村上と一緒のチームで業務をしているんですが、レセコンなどの部分というよりは、先程の話の「周辺」の開発をすることが多いです。基本的に平行して複数のプロジェクトが走っており、それぞれのプロジェクトでディレクター 1 人、エンジニア数人、他にデザイナーという形で進めていくことが多いです。 大まかにディレクターが要件などをまとめたものをベースとして、その後にデザイナーやエンジニアも入って要件定義などをしていき、徐々に形にしていくという事が多いですね。 ── お二人で組んで仕事をすることもあるんですか? 村上 : はい、とても多いです。 進行しているプロジェクトの他にも、定常改善やバグ改修などのタスクがありますが、そうしたタスクを「どのタイミングで」「どの優先度で」対応していくかなどをチーム内で議論してから実施するので。 吉岡 : プロジェクトやそうしたタスクとは別に、エンジニア主導で大規模なリファクタリングなども行なっています。担当しているプロジェクトの他にそうしたものを手がけていて、一緒になることが多いです。 入社してメドレーの文化を強く意識した出来事 ── メドレーで働いている中で、特に文化を強く感じたエピソードなど聞いてみたいです。 飯田 : 開発に関係する人全員が「プロダクト志向が強い」ということでしょうか。具体的には、開発の要件定義段階から全員関わるので、もちろんビジネスサイドの方からも「こうした方が良いのではないか」というアイデアは出てきますが、開発サイドからも「どういう機能が一番ユーザに価値を届けられるか」という視点で一緒になって考えるんです。そもそもどういった課題を解決するものなのかという基礎の部分から一緒に考えていくのがメドレーでは当たり前になっているという感じがします。 開発サイドもビジネスサイドも同じ方向を向いているので、提案などもちゃんとロジカルで筋が通っているものであれば通るというのは、すごく意見しがいがある と思います。そのための相談なんかも、もちろんしやすいですし、とても良い文化だなと感じています。 岡田 : 開発にあたって PM が 施策などを Issue として立ててくれるのですが、言語化が行き届いていて何が問題で、どうして実施するのか、その影響なんかがすごく分かりやすいという点はメドレーが大事にしている「ドキュメントドリブン」という文化を感じます。 そのような環境なので、大抵のことは最低限の文章のやり取りだけでスムーズに進みますし、上手くいかない状況になっても善後策などが立てやすくなっていると思います。 徳永 : メドレーは新卒入社の社員数は少ないので、中途入社の方がほとんどという環境です。入社してすぐは「自分の意見は通るのかな」とか「自分より後に入社した経験年数が長い中途入社の方とどう付き合おう」などが心配でした。でも メドレーでは「建設的に進める」という文化があるので、立場に関係なく議論できる環境があるので、とても仕事がしやすい です。自分の意見が例え間違っていたとしても議論が起きるということは、認識がズレていたということだからと軌道修正もできるので本当に働きやすいです。 また、とても良いなと思ったのが、部署や職種に関わらず Confluence の情報に誰でもアクセスできるという文化ですね。秘匿情報以外は基本的に全て Confluence でオープンになっているおかげで、自分とは直接関係ない部署の現在の動きなどがキャッチアップできるので、そういった人たちとコミュニケーションを取るときにもすごく助かります。 古川 : 徳永とかぶるところがあるんですが、「建設的に進める」という部分は非常にメドレーらしさを感じる文化です。例えば PM が「施策をこうしましょう」となっても、自分が「このフローってこうなった方が良いですよね」という意見を言えるし、そこを起点に 議論に発展してより良いものを作っていけるというのは本当に素晴らしい と感じています。 実際に自分がリードしていた施策の中でもエンジニア・ デザイナー・ PM ・カスタマーサクセスという立場が違うメンバー同士で改めて薬局の業務フローを整理しなおして、より良い仕様にできたりということがありました。 機能リリース後もちゃんと「あるべき姿」を目指して改善をできたりしたので、こういう考え方はとても仕事がしやすいです。 村上 : 自分からは「組織水準を高める」という文化について言及させてください。自分が関わっている電子カルテやレセコンという領域は深い業務知識が必要で、初めて関わった人からすると、そもそもどういうフローで機能が使われているかとか、特定の場合に何でこうなるんだろうというところが、理解しづらいんです。でも、自分のチームは新卒・中途問わず、まだ深いドメイン知識がない、といった状態からでも入って活躍しやすい環境だというのを感じています。 いきなり専門の業務知識が必要な開発というのはやはり難しいので、そうした部分と直接は関係しない周辺領域の開発から始めてもらって、徐々に電子カルテやレセコンに直接関係する開発に入ってもらえるようなオンボーディングができています。開発の中で、あるべき姿について議論になったりで色々なメンバーと話をしていくので、 医療業務のキャッチアップはかなりしやすい環境 だと思います。 もうひとつ「長期のカスタマー価値を追求する」という部分も文化を感じていて、主にマネージャーを含め、短期的な KPI に沿った開発よりも、長期的に顧客への価値提供に寄与できる開発を優先していくという意識が非常に強いのが良いと感じます。 特に今現在、社内で開発が進んでいる新規レセコンの開発については強く思いますね。 吉岡 : 自分が強く感じているメドレーの文化としては「ドキュメントドリブン」です。ミーティングなども、こういうことの結論を得るために協議する、というのが明確に分かる資料を事前に用意して行います。ですので、「これ何の時間だっけ?」みたいな状態になりにくいのが良いです。 あとは ミーティングによる同期的、Slack や Confluence などによる非同期のコミュニケーションを適材適所で全員が使いわけているので、そもそもコミュニケーションで無駄な行き違いのようなものも、ほとんど無い のも、仕事がしやすいと思っています。 もうひとつは、自分もやはりプロダクト志向の強さというところを感じています。現在はディレクターなどと一緒に開発をしていく体制になっているんですが、UI や顧客体験なども含めてエンジニアでも、ちゃんとプロダクトとしての理想の姿を考えて開発するという姿勢がとても強いです。自分の専門ではない領域でもきちんと考えながら開発をしていくので、やりがいがあります。 これからメドレーに入社する方へのメッセージ ── では最後になりますが、特に新卒でメドレーの入社を考えている方へのメッセージなどあれば、お伺いしたいです。 飯田 : そうですね、「先輩が新卒に対してとても期待してくれている」というのは伝えたいと思います。自分の場合、研修が終わって 3 ヶ月経ったぐらいで、シゴトークのインフラ環境を全部刷新するという大きなプロジェクトのリードを任せてもらえたんです。もちろん SRE の先輩などと協力しつつ進めたものだったんですが、 研修終わってすぐにそんな大きなプロジェクトを裁量持って進められるような環境なので、すごくやりがいがあります 。 岡田 : 稲本(人材プラットフォーム CTO)が「新卒だから」みたいな接し方をせずに、いちエンジニアとして接してくれているのは個人的に嬉しいポイントです。また 責任を持った上で裁量持って自由に動いていける業務環境があるのが、すごく良い です。ちゃんとプロダクトの事を考えて開発をしたい人にはおすすめできる環境だと思います。 徳永 : 新卒の良いところは「同期」感を持てるところかなと思います。今もランチ等でこのメンバーと技術的なところなどを気軽に相談できるのはとても良いです。 切磋琢磨していく環境じゃないかなと思っているので、そうした環境を求めるならすごく良い と思います。 古川 : 受け身で仕事を行うのではなく、ガツガツと自分の方から求めにいく姿勢の人には、すごくマッチする会社だと思います。せっかく裁量持って業務を進めることができる環境なので、 遠慮せずにがんがんと物事進めることができる人には最高 なんじゃないかと考えています。 自分はインフラだけではなくて、サーバやフロントエンドも開発していきたいと考えているんですが、小規模なプロジェクトであれば全て行える環境なため、自分一人でプロジェクトを完結することができるのは、性に合っているなと思ってます。周りのサポートや先輩との壁打ちなどはちゃんとやってもらえるので、とても勉強になり成長できると思います。 村上 : メドレーで開発をしていくについれて、医療ドメインという領域で自分が関わっていることが人の役に立っているんだなというのが日々実感できるところは良いです。特に色々な医療機関のサポートができるというプロダクトに関わっているので、直接医療機関やその先にいる患者さんの 役に立っているという実感は、正直 1 年目で感じられるものではないと思っていたので、良い驚き です。 また大きいデータを取り扱うという経験ができているのも貴重だなと感じています。現在のプロダクトでは契約医療機関も非常に多いですし、その大量のデータの設計を変更したりというところを、裁量持って実施できるのは良い経験になっています。 吉岡 : メドレーの「プロダクト志向」を持っている先輩エンジニアと働けるというのはとても良い経験だと思っています。一般的にはエンジニアは技術さえあればという感じになりやすかったりすると思うのですが、メドレーではもちろん新しい技術なども使いながら、それを いかにプロダクトやその先のユーザへの価値提供に繋げるかを考えている方が集っている ので、そういう思考でプロダクト開発ができているのはすごく勉強になります。 ── ありがとうございました! 本当に 1 年で皆さんが濃い業務経験を積んでいるのが分かるインタビューになりました。 さいごに それぞれ異なるチームや業務内容ですが、新卒エンジニアでも裁量を持って業務に臨めることや、プロダクトの重要な部分の開発にどんどん関わっていけることが伝わるインタビューとなりました。 メドレーは新卒入社のエンジニアも積極的に募集していますので、今回気になったという方はお気軽にカジュアル面談をしましょう! open.talentio.com open.talentio.com

はじめに みなさん、こんにちは。エンジニアの新居です。今回は 2022 年新卒入社したエンジニア達にインタビューした記事をお送りします。 この 1 年で彼らがどのような業務を経験してきたのかや、リアルな現在の立ち位置などをお伝えしたいと考えています。 それでは、ご覧ください! 自己紹介 飯田さん 研修後は ジョブメドレー で顧客向けの機能開発を担当。その後 シゴトーク でインフラ領域を中心にリニューアルに従事する。現在は Jobley で施策の開発やインフラ周りまで幅広く業務を担当。 飯田さん 岡田さん 研修後はジョブメドレーでの開発業務を担当後、シゴトークへ。ジョブメドレーとの連携強化のプロジェクトなど経験し、現在はシゴトークの開発全般を担当。 岡田さん 徳永さん 研修後は ジョブメドレーアカデミー に配属。プロダクト改善などを担当しつつ、直近では生成 AI を使った機能の開発やバックエンドからモバイルまで幅広い開発に従事。 徳永さん 古川さん 研修後は Pharms に配属。フロントエンドからインフラまで幅広く担当。小規模施策の開発に始まり現在は中規模施策のプロジェクトリードをしながら開発を行なう。 古川さん 村上さん 研修後は CLINICS に配属。電子カルテ関連の開発を経て、現在は中規模施策のプロジェクトリードをしながら開発を行なう。 村上さん 吉岡さん 研修後は 患者アプリ CLINICS に配属。Web アプリとネイティブアプリの機能開発を担当した後、CLINICS に配属。現在は定常改善や、フロントエンドの大規模改修などに従事。 吉岡さん ファーストキャリアとしてメドレーを選んだ理由について ── まずはファーストキャリアにメドレーへ入社を決めた理由をお伺いしていきたいと思います。 飯田 : 元々ベンチャー気質が高いことを軸に会社選びをしていました。新卒入社の社員が多数いるような規模が大きい会社だと、自分がその中に埋もれてしまい、自由度が高い動きができなさそうだと考えていたからです。メドレーは新卒が少ないのでその辺りはマッチしていました。医療という領域に関しても、 日常生活に関わるところで社会に貢献できるような領域が良いなと考えていたことや、家族が看護師をやっていることもあり医療業界の課題を身近に感じられ、医療に対して興味があった ことが理由になっています。 岡田 : 自分の体調が悪くなることが昔から多かったためヘルスケア業界に興味があったのですが、そこに近い業界だったのがひとつの理由です。また会社のミッションがとても分かりやすかったというのがあります。他社に比べて、メドレーは 世の中を良くしてくという会社のビジョンに、ちゃんと基づいてプロダクトを開発している んだなというのが具体的に分かって一貫性を感じられたのが大きいです。 他には、「エンジニア」という職種だともちろん技術分野が専門領域になっていくわけですが、その領域に閉じず、プロダクトを中心に課題解決する上でエンジニアリング以外のことも考えながら開発をしているプロダクトファーストな考えも魅力的でした。 徳永 : 自分は岡田くんのように特にヘルスケア領域に興味があったということはなかったんです。どちらかというと、 エンジニアとしてこれから働いていく上で自分が大切にしたい志向や価値観というのが、メドレーのエンジニアの方達と話をしていく中でマッチする なと感じたのが大きいです。 それまでも色々な会社さんとの選考をしていたんですが、メドレーのエンジニアは「本質を追い求める」という姿勢の元、エンジニアリングが好きで、それをプロダクトへ還元していくという部分が自分のフィーリングにあったという感じでした。 ── フィーリングに合ったということですが、他にもマッチすると思った部分はありましたか? 徳永 : エンジニアの雰囲気も大人な感じの方が多く、体育会系の「気合と根性で頑張る」という進め方ではなく、合理的に物事を進めるために必要なコミュニケーションをきちんと取っていくところなどが魅力でした。そうした部分も含めて自分が働いている将来というのが想像できました。 古川 : 自分は親が薬剤師で医療分野に元々興味があり、医療 x IT という軸で就活をしていく過程でメドレーを知ったのが最初の出会いでした。お話を聞いていくうちに「課題解決のためのプロダクト作り」という点が非常に魅力に感じました。社会を良くするためにプロダクトを良くしていこうという姿勢で会社に一体感が生まれているのが、すごく良いなと。 会社に限らないかもしれないですが、組織も人が多くなってくるとやっぱり方向性が少しずつズレていくという感じになりがちだと思うんですが、メドレーの場合は 会社として「医療業界をもっと良くしていくための事業をしていく」という軸が通っている のを感じて、最終的にはこの部分に惹かれて入社を決めました。 あとは、上場企業という「安心感」もファーストキャリアの選択に影響しました。 岡田 : 自分も新卒入社の社員目線だと、入社する会社の安定感というのは重要だと思っていました。 村上 : 就活する前は特定の業界に限らず色々な会社を見ていました。学生時代に様々な業界のエンジニアインターンやアルバイトなどしていたのですが、その過程で「せっかく正社員で働くなら、より社会的意義がある事業をやるべきだな」と感じました。そうした意識で就活に臨んで 自分が興味を持って取り組めそうなのは医療業界だなと思った のが最初のきっかけでした。 メドレーは選考の中で、技術領域を問わずに開発できることなどがマッチすると感じたのと、サービスが医療機関だけでなく患者側も充実しているということも入社の決め手になりました。自分が患者になることも多いので、とても課題が分かりやすかったんです。 吉岡 : 自分も元々エンタメなどの領域より、医療や教育、金融領域を中心に就活をしていました。中でもメドレーの「医療ヘルスケアの未来をつくる」というミッションへの自分の共感度が非常に高かったのが、入社の理由でした。日本の医療制度をきちんと維持するためのプロダクトを作っていくんだという姿勢が非常に良かったです。 またさきほどの話にも出ていましたが、 医療機関のためのプロダクトと患者のためのプロダクトという両面へのアプローチをしている のも決め手でした。やはり医療費の問題などは医療機関だけへのアプローチでは解決できないと思うので、そういう意味でも一貫性が感じられて良かったです。 現在のチーム内での役割について ── では次に現在のチームでの皆さんの役割や動き方、チームメンバーとの関わり方について聞いていきたいと思います。 飯田 : 現在 Jobley の開発チームではエンジニアが 4 人いるのですが、その内 2 人がプロダクト施策の立案を行ないつつ、自分を含む残りの 2 人が実装をメインにして開発を行なっています。状況に合わせ PM 兼任のエンジニアと実装担当のエンジニアとで二人三脚で開発をしたり、単独での開発を行なったりと柔軟に対応していってます。 チームメンバーとの関わりという点では、 エンジニアチームだけで開発するということはなく、セールスやカスタマーサクセスの方たちと一緒に要件を詰めていく ことが最近は多いです。そのためセールスの業務フローなどもキャッチアップする必要があるので大変ですが、面白くやりがいを感じるところでもありますね。 岡田 : シゴトークでは、PM とエンジニアの二人三脚という体制で開発をしています。PM と日々要件を刷り合わせながら、実装は自分が行なっていていくというスタイルです。Pull Request のレビューだけは元々シゴトークを開発されていたエンジニアの方々にお願いしています。 また、例えばプロダクトのセキュリティ強化の取り組みやアプリの認証機能の一新、QA 環境の整備など、自分が普段触れない領域の施策を行った際はスキルアップを実感できました。ライブラリのアップデートや、リファクタリングなども 裁量を持ってやらせてもらっています 。 徳永 : ジョブメドレーアカデミーはジョブメドレーや CLINICS に比べると小規模なチーム構成となっています。エンジニアが 7 人、PM が 3 人、プロダクトオーナーが 1 人という体制で開発をしてるのですが、 良い意味で新卒入社エンジニアとして裁量を持って開発をさせてもらっています 。 開発チームも徐々に大きくなっているので、タスクを上手く回すための仕組みを考えたり、チームを上手く機能させるために朝会の構成を変更してみたり。技術的な部分では CI/CD など開発全体に関わる分野についても、任せてもらっています。 また ニュースリリース にもなりましたが、社内で初めての 生成 AI を使った機能の開発 は、プロダクトオーナーと自分の 2 人が中心になって進めていきました。 開発に入る前段階でロジカルに「こういった課題をこの機能で解決していく」ということが伝えられれば、ある程度技術的に実験的なものも導入することができる環境です 。 古川 : Pharms では現在エンジニアが 4 人、PM 1 人、デザイナーが 1 人というのが中心メンバーとなっています。Pharms は現在色々と機能拡大をしていっているのですが、エンジニアが 4 人なので本当に全員で何でもやっていくという感じで開発しています。とはいえ、メンバー各々で得意分野は違うので、得意なところは積極的に拾いに行く感じです。 自分はと言うと、得意分野のインフラ部分に関してはほとんど任せてもらっており、自分からの発信で先輩のテックリードエンジニアの方とすり合わせしながら色々な施策を行なっています。その他にもクォーター毎に数個は中・大規模な施策が計画されるので、そうしたもののいくつかのリードをさせてもらったりしています。ですので、 アプリケーションの開発という面でもプロジェクトを上手く進行させるという面でも、とても楽しく業務をしています 。 村上 : CLINICS ではまず「基幹」と「周辺」とざっくり 2 つのチームに分かれており、「基幹」が主にレセコン(レセプトコンピュータの略。医療施設から健康保険組合などの支払い機関に対し、診療報酬を請求するために、電子カルテと連動してレセプトと呼ばれる診療報酬明細書を作成するシステム)とのやりとりを、「周辺」では予約や問診、資格確認など CLINICS と患者との接点となるシステム、という形で担当業務が分かれています。自分はずっと基幹チームにアサインされています。チーム全対応のエンジニアの内訳はアプリケーション担当が 6~7 人、インフラ担当が 3 人ほどになっています。 現在は大きなプロジェクトが 1 つ進行していて、既存のレセコンをメドレーで新規開発しているレセコンに移行するというものですが、その中に 中規模なプロジェクトが複数平行して進んでいて、その内のいくつかを自分がリード させてもらっています。 リードしているプロジェクトの進行管理やチームメンバー間での問題共有方法などを考えているのですが、この辺りは挑戦できる幅が広く、難しいですが面白いと感じています。課題についてプロジェクトに限定せず、他のシステムや進捗状況に影響がないかを配慮する必要があり、そうした視点で適切に異なる立場の関係者を巻き込むことで、より包括的な解決策を導き出そうと意識をしています。 吉岡 : 自分は今は村上と一緒のチームで業務をしているんですが、レセコンなどの部分というよりは、先程の話の「周辺」の開発をすることが多いです。基本的に平行して複数のプロジェクトが走っており、それぞれのプロジェクトでディレクター 1 人、エンジニア数人、他にデザイナーという形で進めていくことが多いです。 大まかにディレクターが要件などをまとめたものをベースとして、その後にデザイナーやエンジニアも入って要件定義などをしていき、徐々に形にしていくという事が多いですね。 ── お二人で組んで仕事をすることもあるんですか? 村上 : はい、とても多いです。 進行しているプロジェクトの他にも、定常改善やバグ改修などのタスクがありますが、そうしたタスクを「どのタイミングで」「どの優先度で」対応していくかなどをチーム内で議論してから実施するので。 吉岡 : プロジェクトやそうしたタスクとは別に、エンジニア主導で大規模なリファクタリングなども行なっています。担当しているプロジェクトの他にそうしたものを手がけていて、一緒になることが多いです。 入社してメドレーの文化を強く意識した出来事 ── メドレーで働いている中で、特に文化を強く感じたエピソードなど聞いてみたいです。 飯田 : 開発に関係する人全員が「プロダクト志向が強い」ということでしょうか。具体的には、開発の要件定義段階から全員関わるので、もちろんビジネスサイドの方からも「こうした方が良いのではないか」というアイデアは出てきますが、開発サイドからも「どういう機能が一番ユーザに価値を届けられるか」という視点で一緒になって考えるんです。そもそもどういった課題を解決するものなのかという基礎の部分から一緒に考えていくのがメドレーでは当たり前になっているという感じがします。 開発サイドもビジネスサイドも同じ方向を向いているので、提案などもちゃんとロジカルで筋が通っているものであれば通るというのは、すごく意見しがいがある と思います。そのための相談なんかも、もちろんしやすいですし、とても良い文化だなと感じています。 岡田 : 開発にあたって PM が 施策などを Issue として立ててくれるのですが、言語化が行き届いていて何が問題で、どうして実施するのか、その影響なんかがすごく分かりやすいという点はメドレーが大事にしている「ドキュメントドリブン」という文化を感じます。 そのような環境なので、大抵のことは最低限の文章のやり取りだけでスムーズに進みますし、上手くいかない状況になっても善後策などが立てやすくなっていると思います。 徳永 : メドレーは新卒入社の社員数は少ないので、中途入社の方がほとんどという環境です。入社してすぐは「自分の意見は通るのかな」とか「自分より後に入社した経験年数が長い中途入社の方とどう付き合おう」などが心配でした。でも メドレーでは「建設的に進める」という文化があるので、立場に関係なく議論できる環境があるので、とても仕事がしやすい です。自分の意見が例え間違っていたとしても議論が起きるということは、認識がズレていたということだからと軌道修正もできるので本当に働きやすいです。 また、とても良いなと思ったのが、部署や職種に関わらず Confluence の情報に誰でもアクセスできるという文化ですね。秘匿情報以外は基本的に全て Confluence でオープンになっているおかげで、自分とは直接関係ない部署の現在の動きなどがキャッチアップできるので、そういった人たちとコミュニケーションを取るときにもすごく助かります。 古川 : 徳永とかぶるところがあるんですが、「建設的に進める」という部分は非常にメドレーらしさを感じる文化です。例えば PM が「施策をこうしましょう」となっても、自分が「このフローってこうなった方が良いですよね」という意見を言えるし、そこを起点に 議論に発展してより良いものを作っていけるというのは本当に素晴らしい と感じています。 実際に自分がリードしていた施策の中でもエンジニア・ デザイナー・ PM ・カスタマーサクセスという立場が違うメンバー同士で改めて薬局の業務フローを整理しなおして、より良い仕様にできたりということがありました。 機能リリース後もちゃんと「あるべき姿」を目指して改善をできたりしたので、こういう考え方はとても仕事がしやすいです。 村上 : 自分からは「組織水準を高める」という文化について言及させてください。自分が関わっている電子カルテやレセコンという領域は深い業務知識が必要で、初めて関わった人からすると、そもそもどういうフローで機能が使われているかとか、特定の場合に何でこうなるんだろうというところが、理解しづらいんです。でも、自分のチームは新卒・中途問わず、まだ深いドメイン知識がない、といった状態からでも入って活躍しやすい環境だというのを感じています。 いきなり専門の業務知識が必要な開発というのはやはり難しいので、そうした部分と直接は関係しない周辺領域の開発から始めてもらって、徐々に電子カルテやレセコンに直接関係する開発に入ってもらえるようなオンボーディングができています。開発の中で、あるべき姿について議論になったりで色々なメンバーと話をしていくので、 医療業務のキャッチアップはかなりしやすい環境 だと思います。 もうひとつ「長期のカスタマー価値を追求する」という部分も文化を感じていて、主にマネージャーを含め、短期的な KPI に沿った開発よりも、長期的に顧客への価値提供に寄与できる開発を優先していくという意識が非常に強いのが良いと感じます。 特に今現在、社内で開発が進んでいる新規レセコンの開発については強く思いますね。 吉岡 : 自分が強く感じているメドレーの文化としては「ドキュメントドリブン」です。ミーティングなども、こういうことの結論を得るために協議する、というのが明確に分かる資料を事前に用意して行います。ですので、「これ何の時間だっけ?」みたいな状態になりにくいのが良いです。 あとは ミーティングによる同期的、Slack や Confluence などによる非同期のコミュニケーションを適材適所で全員が使いわけているので、そもそもコミュニケーションで無駄な行き違いのようなものも、ほとんど無い のも、仕事がしやすいと思っています。 もうひとつは、自分もやはりプロダクト志向の強さというところを感じています。現在はディレクターなどと一緒に開発をしていく体制になっているんですが、UI や顧客体験なども含めてエンジニアでも、ちゃんとプロダクトとしての理想の姿を考えて開発するという姿勢がとても強いです。自分の専門ではない領域でもきちんと考えながら開発をしていくので、やりがいがあります。 これからメドレーに入社する方へのメッセージ ── では最後になりますが、特に新卒でメドレーの入社を考えている方へのメッセージなどあれば、お伺いしたいです。 飯田 : そうですね、「先輩が新卒に対してとても期待してくれている」というのは伝えたいと思います。自分の場合、研修が終わって 3 ヶ月経ったぐらいで、シゴトークのインフラ環境を全部刷新するという大きなプロジェクトのリードを任せてもらえたんです。もちろん SRE の先輩などと協力しつつ進めたものだったんですが、 研修終わってすぐにそんな大きなプロジェクトを裁量持って進められるような環境なので、すごくやりがいがあります 。 岡田 : 稲本(人材プラットフォーム CTO)が「新卒だから」みたいな接し方をせずに、いちエンジニアとして接してくれているのは個人的に嬉しいポイントです。また 責任を持った上で裁量持って自由に動いていける業務環境があるのが、すごく良い です。ちゃんとプロダクトの事を考えて開発をしたい人にはおすすめできる環境だと思います。 徳永 : 新卒の良いところは「同期」感を持てるところかなと思います。今もランチ等でこのメンバーと技術的なところなどを気軽に相談できるのはとても良いです。 切磋琢磨していく環境じゃないかなと思っているので、そうした環境を求めるならすごく良い と思います。 古川 : 受け身で仕事を行うのではなく、ガツガツと自分の方から求めにいく姿勢の人には、すごくマッチする会社だと思います。せっかく裁量持って業務を進めることができる環境なので、 遠慮せずにがんがんと物事進めることができる人には最高 なんじゃないかと考えています。 自分はインフラだけではなくて、サーバやフロントエンドも開発していきたいと考えているんですが、小規模なプロジェクトであれば全て行える環境なため、自分一人でプロジェクトを完結することができるのは、性に合っているなと思ってます。周りのサポートや先輩との壁打ちなどはちゃんとやってもらえるので、とても勉強になり成長できると思います。 村上 : メドレーで開発をしていくについれて、医療ドメインという領域で自分が関わっていることが人の役に立っているんだなというのが日々実感できるところは良いです。特に色々な医療機関のサポートができるというプロダクトに関わっているので、直接医療機関やその先にいる患者さんの 役に立っているという実感は、正直 1 年目で感じられるものではないと思っていたので、良い驚き です。 また大きいデータを取り扱うという経験ができているのも貴重だなと感じています。現在のプロダクトでは契約医療機関も非常に多いですし、その大量のデータの設計を変更したりというところを、裁量持って実施できるのは良い経験になっています。 吉岡 : メドレーの「プロダクト志向」を持っている先輩エンジニアと働けるというのはとても良い経験だと思っています。一般的にはエンジニアは技術さえあればという感じになりやすかったりすると思うのですが、メドレーではもちろん新しい技術なども使いながら、それを いかにプロダクトやその先のユーザへの価値提供に繋げるかを考えている方が集っている ので、そういう思考でプロダクト開発ができているのはすごく勉強になります。 ── ありがとうございました! 本当に 1 年で皆さんが濃い業務経験を積んでいるのが分かるインタビューになりました。 さいごに それぞれ異なるチームや業務内容ですが、新卒エンジニアでも裁量を持って業務に臨めることや、プロダクトの重要な部分の開発にどんどん関わっていけることが伝わるインタビューとなりました。 メドレーは新卒入社のエンジニアも積極的に募集していますので、今回気になったという方はお気軽にカジュアル面談をしましょう! open.talentio.com open.talentio.com

はじめに みなさん、こんにちは。エンジニアの新居です。今回は 2022 年新卒入社したエンジニア達にインタビューした記事をお送りします。 この 1 年で彼らがどのような業務を経験してきたのかや、リアルな現在の立ち位置などをお伝えしたいと考えています。 それでは、ご覧ください! 自己紹介 飯田さん 研修後は ジョブメドレー で顧客向けの機能開発を担当。その後 シゴトーク でインフラ領域を中心にリニューアルに従事する。現在は Jobley で施策の開発やインフラ周りまで幅広く業務を担当。 飯田さん 岡田さん 研修後はジョブメドレーでの開発業務を担当後、シゴトークへ。ジョブメドレーとの連携強化のプロジェクトなど経験し、現在はシゴトークの開発全般を担当。 岡田さん 徳永さん 研修後は ジョブメドレーアカデミー に配属。プロダクト改善などを担当しつつ、直近では生成 AI を使った機能の開発やバックエンドからモバイルまで幅広い開発に従事。 徳永さん 古川さん 研修後は Pharms に配属。フロントエンドからインフラまで幅広く担当。小規模施策の開発に始まり現在は中規模施策のプロジェクトリードをしながら開発を行なう。 古川さん 村上さん 研修後は CLINICS に配属。電子カルテ関連の開発を経て、現在は中規模施策のプロジェクトリードをしながら開発を行なう。 村上さん 吉岡さん 研修後は 患者アプリ CLINICS に配属。Web アプリとネイティブアプリの機能開発を担当した後、CLINICS に配属。現在は定常改善や、フロントエンドの大規模改修などに従事。 吉岡さん ファーストキャリアとしてメドレーを選んだ理由について ── まずはファーストキャリアにメドレーへ入社を決めた理由をお伺いしていきたいと思います。 飯田 : 元々ベンチャー気質が高いことを軸に会社選びをしていました。新卒入社の社員が多数いるような規模が大きい会社だと、自分がその中に埋もれてしまい、自由度が高い動きができなさそうだと考えていたからです。メドレーは新卒が少ないのでその辺りはマッチしていました。医療という領域に関しても、 日常生活に関わるところで社会に貢献できるような領域が良いなと考えていたことや、家族が看護師をやっていることもあり医療業界の課題を身近に感じられ、医療に対して興味があった ことが理由になっています。 岡田 : 自分の体調が悪くなることが昔から多かったためヘルスケア業界に興味があったのですが、そこに近い業界だったのがひとつの理由です。また会社のミッションがとても分かりやすかったというのがあります。他社に比べて、メドレーは 世の中を良くしてくという会社のビジョンに、ちゃんと基づいてプロダクトを開発している んだなというのが具体的に分かって一貫性を感じられたのが大きいです。 他には、「エンジニア」という職種だともちろん技術分野が専門領域になっていくわけですが、その領域に閉じず、プロダクトを中心に課題解決する上でエンジニアリング以外のことも考えながら開発をしているプロダクトファーストな考えも魅力的でした。 徳永 : 自分は岡田くんのように特にヘルスケア領域に興味があったということはなかったんです。どちらかというと、 エンジニアとしてこれから働いていく上で自分が大切にしたい志向や価値観というのが、メドレーのエンジニアの方達と話をしていく中でマッチする なと感じたのが大きいです。 それまでも色々な会社さんとの選考をしていたんですが、メドレーのエンジニアは「本質を追い求める」という姿勢の元、エンジニアリングが好きで、それをプロダクトへ還元していくという部分が自分のフィーリングにあったという感じでした。 ── フィーリングに合ったということですが、他にもマッチすると思った部分はありましたか? 徳永 : エンジニアの雰囲気も大人な感じの方が多く、体育会系の「気合と根性で頑張る」という進め方ではなく、合理的に物事を進めるために必要なコミュニケーションをきちんと取っていくところなどが魅力でした。そうした部分も含めて自分が働いている将来というのが想像できました。 古川 : 自分は親が薬剤師で医療分野に元々興味があり、医療 x IT という軸で就活をしていく過程でメドレーを知ったのが最初の出会いでした。お話を聞いていくうちに「課題解決のためのプロダクト作り」という点が非常に魅力に感じました。社会を良くするためにプロダクトを良くしていこうという姿勢で会社に一体感が生まれているのが、すごく良いなと。 会社に限らないかもしれないですが、組織も人が多くなってくるとやっぱり方向性が少しずつズレていくという感じになりがちだと思うんですが、メドレーの場合は 会社として「医療業界をもっと良くしていくための事業をしていく」という軸が通っている のを感じて、最終的にはこの部分に惹かれて入社を決めました。 あとは、上場企業という「安心感」もファーストキャリアの選択に影響しました。 岡田 : 自分も新卒入社の社員目線だと、入社する会社の安定感というのは重要だと思っていました。 村上 : 就活する前は特定の業界に限らず色々な会社を見ていました。学生時代に様々な業界のエンジニアインターンやアルバイトなどしていたのですが、その過程で「せっかく正社員で働くなら、より社会的意義がある事業をやるべきだな」と感じました。そうした意識で就活に臨んで 自分が興味を持って取り組めそうなのは医療業界だなと思った のが最初のきっかけでした。 メドレーは選考の中で、技術領域を問わずに開発できることなどがマッチすると感じたのと、サービスが医療機関だけでなく患者側も充実しているということも入社の決め手になりました。自分が患者になることも多いので、とても課題が分かりやすかったんです。 吉岡 : 自分も元々エンタメなどの領域より、医療や教育、金融領域を中心に就活をしていました。中でもメドレーの「医療ヘルスケアの未来をつくる」というミッションへの自分の共感度が非常に高かったのが、入社の理由でした。日本の医療制度をきちんと維持するためのプロダクトを作っていくんだという姿勢が非常に良かったです。 またさきほどの話にも出ていましたが、 医療機関のためのプロダクトと患者のためのプロダクトという両面へのアプローチをしている のも決め手でした。やはり医療費の問題などは医療機関だけへのアプローチでは解決できないと思うので、そういう意味でも一貫性が感じられて良かったです。 現在のチーム内での役割について ── では次に現在のチームでの皆さんの役割や動き方、チームメンバーとの関わり方について聞いていきたいと思います。 飯田 : 現在 Jobley の開発チームではエンジニアが 4 人いるのですが、その内 2 人がプロダクト施策の立案を行ないつつ、自分を含む残りの 2 人が実装をメインにして開発を行なっています。状況に合わせ PM 兼任のエンジニアと実装担当のエンジニアとで二人三脚で開発をしたり、単独での開発を行なったりと柔軟に対応していってます。 チームメンバーとの関わりという点では、 エンジニアチームだけで開発するということはなく、セールスやカスタマーサクセスの方たちと一緒に要件を詰めていく ことが最近は多いです。そのためセールスの業務フローなどもキャッチアップする必要があるので大変ですが、面白くやりがいを感じるところでもありますね。 岡田 : シゴトークでは、PM とエンジニアの二人三脚という体制で開発をしています。PM と日々要件を刷り合わせながら、実装は自分が行なっていていくというスタイルです。Pull Request のレビューだけは元々シゴトークを開発されていたエンジニアの方々にお願いしています。 また、例えばプロダクトのセキュリティ強化の取り組みやアプリの認証機能の一新、QA 環境の整備など、自分が普段触れない領域の施策を行った際はスキルアップを実感できました。ライブラリのアップデートや、リファクタリングなども 裁量を持ってやらせてもらっています 。 徳永 : ジョブメドレーアカデミーはジョブメドレーや CLINICS に比べると小規模なチーム構成となっています。エンジニアが 7 人、PM が 3 人、プロダクトオーナーが 1 人という体制で開発をしてるのですが、 良い意味で新卒入社エンジニアとして裁量を持って開発をさせてもらっています 。 開発チームも徐々に大きくなっているので、タスクを上手く回すための仕組みを考えたり、チームを上手く機能させるために朝会の構成を変更してみたり。技術的な部分では CI/CD など開発全体に関わる分野についても、任せてもらっています。 また ニュースリリース にもなりましたが、社内で初めての 生成 AI を使った機能の開発 は、プロダクトオーナーと自分の 2 人が中心になって進めていきました。 開発に入る前段階でロジカルに「こういった課題をこの機能で解決していく」ということが伝えられれば、ある程度技術的に実験的なものも導入することができる環境です 。 古川 : Pharms では現在エンジニアが 4 人、PM 1 人、デザイナーが 1 人というのが中心メンバーとなっています。Pharms は現在色々と機能拡大をしていっているのですが、エンジニアが 4 人なので本当に全員で何でもやっていくという感じで開発しています。とはいえ、メンバー各々で得意分野は違うので、得意なところは積極的に拾いに行く感じです。 自分はと言うと、得意分野のインフラ部分に関してはほとんど任せてもらっており、自分からの発信で先輩のテックリードエンジニアの方とすり合わせしながら色々な施策を行なっています。その他にもクォーター毎に数個は中・大規模な施策が計画されるので、そうしたもののいくつかのリードをさせてもらったりしています。ですので、 アプリケーションの開発という面でもプロジェクトを上手く進行させるという面でも、とても楽しく業務をしています 。 村上 : CLINICS ではまず「基幹」と「周辺」とざっくり 2 つのチームに分かれており、「基幹」が主にレセコン(レセプトコンピュータの略。医療施設から健康保険組合などの支払い機関に対し、診療報酬を請求するために、電子カルテと連動してレセプトと呼ばれる診療報酬明細書を作成するシステム)とのやりとりを、「周辺」では予約や問診、資格確認など CLINICS と患者との接点となるシステム、という形で担当業務が分かれています。自分はずっと基幹チームにアサインされています。チーム全対応のエンジニアの内訳はアプリケーション担当が 6~7 人、インフラ担当が 3 人ほどになっています。 現在は大きなプロジェクトが 1 つ進行していて、既存のレセコンをメドレーで新規開発しているレセコンに移行するというものですが、その中に 中規模なプロジェクトが複数平行して進んでいて、その内のいくつかを自分がリード させてもらっています。 リードしているプロジェクトの進行管理やチームメンバー間での問題共有方法などを考えているのですが、この辺りは挑戦できる幅が広く、難しいですが面白いと感じています。課題についてプロジェクトに限定せず、他のシステムや進捗状況に影響がないかを配慮する必要があり、そうした視点で適切に異なる立場の関係者を巻き込むことで、より包括的な解決策を導き出そうと意識をしています。 吉岡 : 自分は今は村上と一緒のチームで業務をしているんですが、レセコンなどの部分というよりは、先程の話の「周辺」の開発をすることが多いです。基本的に平行して複数のプロジェクトが走っており、それぞれのプロジェクトでディレクター 1 人、エンジニア数人、他にデザイナーという形で進めていくことが多いです。 大まかにディレクターが要件などをまとめたものをベースとして、その後にデザイナーやエンジニアも入って要件定義などをしていき、徐々に形にしていくという事が多いですね。 ── お二人で組んで仕事をすることもあるんですか? 村上 : はい、とても多いです。 進行しているプロジェクトの他にも、定常改善やバグ改修などのタスクがありますが、そうしたタスクを「どのタイミングで」「どの優先度で」対応していくかなどをチーム内で議論してから実施するので。 吉岡 : プロジェクトやそうしたタスクとは別に、エンジニア主導で大規模なリファクタリングなども行なっています。担当しているプロジェクトの他にそうしたものを手がけていて、一緒になることが多いです。 入社してメドレーの文化を強く意識した出来事 ── メドレーで働いている中で、特に文化を強く感じたエピソードなど聞いてみたいです。 飯田 : 開発に関係する人全員が「プロダクト志向が強い」ということでしょうか。具体的には、開発の要件定義段階から全員関わるので、もちろんビジネスサイドの方からも「こうした方が良いのではないか」というアイデアは出てきますが、開発サイドからも「どういう機能が一番ユーザに価値を届けられるか」という視点で一緒になって考えるんです。そもそもどういった課題を解決するものなのかという基礎の部分から一緒に考えていくのがメドレーでは当たり前になっているという感じがします。 開発サイドもビジネスサイドも同じ方向を向いているので、提案などもちゃんとロジカルで筋が通っているものであれば通るというのは、すごく意見しがいがある と思います。そのための相談なんかも、もちろんしやすいですし、とても良い文化だなと感じています。 岡田 : 開発にあたって PM が 施策などを Issue として立ててくれるのですが、言語化が行き届いていて何が問題で、どうして実施するのか、その影響なんかがすごく分かりやすいという点はメドレーが大事にしている「ドキュメントドリブン」という文化を感じます。 そのような環境なので、大抵のことは最低限の文章のやり取りだけでスムーズに進みますし、上手くいかない状況になっても善後策などが立てやすくなっていると思います。 徳永 : メドレーは新卒入社の社員数は少ないので、中途入社の方がほとんどという環境です。入社してすぐは「自分の意見は通るのかな」とか「自分より後に入社した経験年数が長い中途入社の方とどう付き合おう」などが心配でした。でも メドレーでは「建設的に進める」という文化があるので、立場に関係なく議論できる環境があるので、とても仕事がしやすい です。自分の意見が例え間違っていたとしても議論が起きるということは、認識がズレていたということだからと軌道修正もできるので本当に働きやすいです。 また、とても良いなと思ったのが、部署や職種に関わらず Confluence の情報に誰でもアクセスできるという文化ですね。秘匿情報以外は基本的に全て Confluence でオープンになっているおかげで、自分とは直接関係ない部署の現在の動きなどがキャッチアップできるので、そういった人たちとコミュニケーションを取るときにもすごく助かります。 古川 : 徳永とかぶるところがあるんですが、「建設的に進める」という部分は非常にメドレーらしさを感じる文化です。例えば PM が「施策をこうしましょう」となっても、自分が「このフローってこうなった方が良いですよね」という意見を言えるし、そこを起点に 議論に発展してより良いものを作っていけるというのは本当に素晴らしい と感じています。 実際に自分がリードしていた施策の中でもエンジニア・ デザイナー・ PM ・カスタマーサクセスという立場が違うメンバー同士で改めて薬局の業務フローを整理しなおして、より良い仕様にできたりということがありました。 機能リリース後もちゃんと「あるべき姿」を目指して改善をできたりしたので、こういう考え方はとても仕事がしやすいです。 村上 : 自分からは「組織水準を高める」という文化について言及させてください。自分が関わっている電子カルテやレセコンという領域は深い業務知識が必要で、初めて関わった人からすると、そもそもどういうフローで機能が使われているかとか、特定の場合に何でこうなるんだろうというところが、理解しづらいんです。でも、自分のチームは新卒・中途問わず、まだ深いドメイン知識がない、といった状態からでも入って活躍しやすい環境だというのを感じています。 いきなり専門の業務知識が必要な開発というのはやはり難しいので、そうした部分と直接は関係しない周辺領域の開発から始めてもらって、徐々に電子カルテやレセコンに直接関係する開発に入ってもらえるようなオンボーディングができています。開発の中で、あるべき姿について議論になったりで色々なメンバーと話をしていくので、 医療業務のキャッチアップはかなりしやすい環境 だと思います。 もうひとつ「長期のカスタマー価値を追求する」という部分も文化を感じていて、主にマネージャーを含め、短期的な KPI に沿った開発よりも、長期的に顧客への価値提供に寄与できる開発を優先していくという意識が非常に強いのが良いと感じます。 特に今現在、社内で開発が進んでいる新規レセコンの開発については強く思いますね。 吉岡 : 自分が強く感じているメドレーの文化としては「ドキュメントドリブン」です。ミーティングなども、こういうことの結論を得るために協議する、というのが明確に分かる資料を事前に用意して行います。ですので、「これ何の時間だっけ?」みたいな状態になりにくいのが良いです。 あとは ミーティングによる同期的、Slack や Confluence などによる非同期のコミュニケーションを適材適所で全員が使いわけているので、そもそもコミュニケーションで無駄な行き違いのようなものも、ほとんど無い のも、仕事がしやすいと思っています。 もうひとつは、自分もやはりプロダクト志向の強さというところを感じています。現在はディレクターなどと一緒に開発をしていく体制になっているんですが、UI や顧客体験なども含めてエンジニアでも、ちゃんとプロダクトとしての理想の姿を考えて開発するという姿勢がとても強いです。自分の専門ではない領域でもきちんと考えながら開発をしていくので、やりがいがあります。 これからメドレーに入社する方へのメッセージ ── では最後になりますが、特に新卒でメドレーの入社を考えている方へのメッセージなどあれば、お伺いしたいです。 飯田 : そうですね、「先輩が新卒に対してとても期待してくれている」というのは伝えたいと思います。自分の場合、研修が終わって 3 ヶ月経ったぐらいで、シゴトークのインフラ環境を全部刷新するという大きなプロジェクトのリードを任せてもらえたんです。もちろん SRE の先輩などと協力しつつ進めたものだったんですが、 研修終わってすぐにそんな大きなプロジェクトを裁量持って進められるような環境なので、すごくやりがいがあります 。 岡田 : 稲本(人材プラットフォーム CTO)が「新卒だから」みたいな接し方をせずに、いちエンジニアとして接してくれているのは個人的に嬉しいポイントです。また 責任を持った上で裁量持って自由に動いていける業務環境があるのが、すごく良い です。ちゃんとプロダクトの事を考えて開発をしたい人にはおすすめできる環境だと思います。 徳永 : 新卒の良いところは「同期」感を持てるところかなと思います。今もランチ等でこのメンバーと技術的なところなどを気軽に相談できるのはとても良いです。 切磋琢磨していく環境じゃないかなと思っているので、そうした環境を求めるならすごく良い と思います。 古川 : 受け身で仕事を行うのではなく、ガツガツと自分の方から求めにいく姿勢の人には、すごくマッチする会社だと思います。せっかく裁量持って業務を進めることができる環境なので、 遠慮せずにがんがんと物事進めることができる人には最高 なんじゃないかと考えています。 自分はインフラだけではなくて、サーバやフロントエンドも開発していきたいと考えているんですが、小規模なプロジェクトであれば全て行える環境なため、自分一人でプロジェクトを完結することができるのは、性に合っているなと思ってます。周りのサポートや先輩との壁打ちなどはちゃんとやってもらえるので、とても勉強になり成長できると思います。 村上 : メドレーで開発をしていくについれて、医療ドメインという領域で自分が関わっていることが人の役に立っているんだなというのが日々実感できるところは良いです。特に色々な医療機関のサポートができるというプロダクトに関わっているので、直接医療機関やその先にいる患者さんの 役に立っているという実感は、正直 1 年目で感じられるものではないと思っていたので、良い驚き です。 また大きいデータを取り扱うという経験ができているのも貴重だなと感じています。現在のプロダクトでは契約医療機関も非常に多いですし、その大量のデータの設計を変更したりというところを、裁量持って実施できるのは良い経験になっています。 吉岡 : メドレーの「プロダクト志向」を持っている先輩エンジニアと働けるというのはとても良い経験だと思っています。一般的にはエンジニアは技術さえあればという感じになりやすかったりすると思うのですが、メドレーではもちろん新しい技術なども使いながら、それを いかにプロダクトやその先のユーザへの価値提供に繋げるかを考えている方が集っている ので、そういう思考でプロダクト開発ができているのはすごく勉強になります。 ── ありがとうございました! 本当に 1 年で皆さんが濃い業務経験を積んでいるのが分かるインタビューになりました。 さいごに それぞれ異なるチームや業務内容ですが、新卒エンジニアでも裁量を持って業務に臨めることや、プロダクトの重要な部分の開発にどんどん関わっていけることが伝わるインタビューとなりました。 メドレーは新卒入社のエンジニアも積極的に募集していますので、今回気になったという方はお気軽にカジュアル面談をしましょう! open.talentio.com open.talentio.com

はじめに 自己紹介 はじめまして。人材プラットフォーム本部プロダクト開発室第一開発グループの田中です。 私は、2023 年の 4 月に新卒エンジニアとして入社し、日本最大級の医療介護求人サイト「 ジョブメドレー 」のフロントエンドとバックエンドの開発を担当しています。 学生時代は情報系ではなく、経済学を専攻していました。プログラミングには大学の授業で出会い、主にデータ分析に用いる R や Python を触っていました。そのため Web アプリケーションの開発は行っていませんでした。 エンジニアという職業に興味を持ったきっかけは、大学院時代に参加したインターンでした。インターン先の会社ではエンジニアが誰もいなかったのですが、開発未経験の私に機械学習を使ったアプリの PoC を作れという、かなり破天荒な経験をしたためです。今ではとてもレアな経験だったと思いますが、試行錯誤しながら何かを作ることに興奮を覚えたのを今でも鮮明に覚えています。 メドレー に入社した理由は、大きな社会課題に取り組んでいる、触れられる技術がフロントエンド・バックエンドのように領域に限られていないなどありましたが、一番大きな理由は「 技術はあくまで手段であり、顧客への価値提供を目的にしている 」という考えに共感したことです。入社してまだ日は浅いですが、この考えは随所で感じられます。 大学近くのビーチの夕焼け 入社から初プロジェクトまで さて、今回の記事では新卒エンジニアの私が初めて携わったプロジェクトの紹介を通して、メドレーでは新卒エンジニアが入社後にどのような働き方をしてるか伝えることができればと思います。 入社してから研修を終えて、配属後 1 ヶ月半くらいは主にプロダクトの定常改善系のタスクに取り組みながら、仕事のリズムを覚えていきました。 その後、今回紹介するプロジェクトに初めてアサインされました。この時点でプロジェクトで主に使用するスキルセットのフロントエンドは、新卒研修で学んだ程度でした。そのような状態の新卒でも、経験をたくさん積ませてもらえる良い環境だということもお伝えできればと思っています。 プロジェクトで解決する課題と解決策 まず、今回担当したプロジェクトが発足した背景となる課題と、その課題を解決するために提供した新機能について紹介します。このプロジェクトについては、 ニュースリリース も公開していますので、合わせてご覧ください。 ユーザーの抱える課題 これまで「ジョブメドレー」では顧客が求人を作成する際に、フォーム形式で募集要項を記入する形式となっていました。記入の自由度が高いことから、法令やガイドライン等で定められた項目を漏れなく記載することや、事業所の魅力を効果的に伝える工夫が必要であり、顧客にとっては大きな負担になっていました。 フォーム形式の求人作成機能のイメージ 社内オペレーションの観点で見ると、求人が掲載基準を満たしているのか、入力された文章から読み取り確認する業務に時間がかかっていました。 そこで、顧客と社内オペレーションの双方が感じている課題を解決するプロジェクトが発足し、私も参画しました。 ユーザー目線の解決策 顧客と社内オペレーションの双方の課題を解決するため、求人作成プロセスをより直感的かつ効率的に改善しました。具体的には、従来のフォーム入力方式から、対話式の質問と回答を通じて求人を作成できる機能を導入しました。この改善により、顧客は簡単に、迷うことなく掲載基準に沿った求人を作成しやすくなりました。 さらに、文章作成の労力を軽減するために、 ChatGPT を活用した提案機能も導入しました。この機能を通じて、顧客は入力した内容に基づき、求職者の目に止まりやすい求人タイトルや訴求文を ChatGPT から提案してもらえます。これにより、求人原稿作成にかかる手間や煩雑さが軽減され、専任の採用担当がいない事業所でも採用活動を効率的に進めることができ、迅速な人材の確保へとつながります。社内オペレーションの観点でも、掲載基準を満たしているかを確認する業務の時間短縮が期待できます。 質問形式の求人作成補助機能のイメージ ChatGPT の導入有無に関しては社内でも協議され、文章生成に ChatGPT を用いることで顧客の作業コストを下げられるのであれば導入しようという意思決定がありました。流行っている技術だから導入するのではなく、 顧客への価値提供のために新しい技術を導入する 考えが現れた意思決定だと思います。 技術スタック 今回のプロジェクトでは次のような技術スタックで開発を行いました。フロントエンドは React を使用し状態管理ライブラリとして React Hooks を選択しました。従来の求人作成機能では Redux で状態管理を行っていましたが、プロダクト全体の方針として今後 React Hooks を使用していく方針であったことと、実装のスピードを早めるために React Hooks を採用しました。 ChatGPT を用いた部分に関しては、顧客からのリクエストを受けて発行したトークンを保存するために Amazon DynamoDB を使用しました。DynamoDB に保存したトークンのバリデーションと GPT へプロンプトを渡し、提案の受け取り・返却する部分は AWS Lambda function に任せていました。GPT 本体は Azure OpenAI Service を利用する構成でした。Azure OpenAI Service を採用した理由は、顧客情報や入力内容が学習に使用されることがなくプライバシー面でのリスクを回避できるためでした。 文章生成機能の構成イメージ プロジェクトへの関わり 今回のプロジェクトのメンバー構成はエンジニア 3 人、デザイナー 1 人、PM 1 人という構成でした。開発には約 3 ヶ月の期間を要しました。 プロジェクト初期 私自身のプロジェクトへの関わり方としては、プロジェクト初期段階からフロントエンドの実装タスクが中心でした。その中でスタイルの実装に関してはオーナーシップを持たせていただきました。今回のプロジェクトで作成する UI コンポーネントでは、似たようなものが複数あったため、できるだけ拡張性を持たせ使い回せるように意識して設計していました。仕事のサイクルとしては、デザイナーが作ったデザインを元に、細かい仕様を調整して実装し、デザインレビューをしてもらうサイクルを回していました。 ただ、React などをキャッチアップしながらの実装だったため、他のエンジニアより実装に時間がかかってしまっていました。適宜先輩エンジニアに質問しながら進めていましたが、いくつかのタスクは巻き取ってもらうことになるなど、悔しい気持ちを覚えたプロジェクト初期でした。 プロジェクト中盤以降 プロジェクト中盤あたりで一つエンジニアとしての仕事の向き合い方に変化がありました。プロジェクトのスケジュールがタイトだったのも相まって、プロジェクト初期ではとりあえず実装して早くタスクを終わらせることに注力していました。しかし、時間がかかっても良いから一つ一つ丁寧にコードを追って理解することに努めようと先輩エンジニアにアドバイスをいただきました。 そこから、理解に注力することで思考がクリアになり、結果的に実装スピードが上がっていきました。また、実装以外にも目を向ける余裕が生まれ、仕様について PM やデザイナーに提案することもできました。プロジェクト中盤以降は自信を持ってタスクに取り組むことができ、終盤には他のエンジニアのタスクを巻き取ることができるまでになりました。 プロジェクトの中では、プロンプトの改善タスクも任せてもらえました。内容としては意図しない回答を弾く改善でしたが、AWS Lambda を触るなど、必要があればクラウドサービスを触る機会もあると感じました。 ChatGPT による提案機能のイメージ さいごに プロジェクトを振り返って 新機能がリリースされて数ヶ月経ちましたが、定めている KPI を達成し、結果が現れていることがとても嬉しいです。一例として、顧客が新機能で求人を作成してから社内での審査を経て掲載に至るまでの日数が、従来の作成方法と比べて半分以下と大幅に削減されています。 チームとしては今回のプロジェクトの進め方について振り返りを行いました。PM 、デザイナー、エンジニアそれぞれが次のプロジェクトをより良く遂行する提案を出し合い、今回のプロジェクトの経験が無駄にならないようにしています。現在、私自身はエンジニア一人の新しいプロジェクトを任されていますが、この時の振り返りでの反省をタスク分解やスケジュール策定に役立てられています。 個人的には今回のプロジェクトを通して、フロントエンドの技術習得はもちろんのこと、プロジェクトメンバーとのコミュニケーションで文章の構造化や画像に編集を加えるなどの工夫を加えることでコミュニケーションコストを下げることができるといった技術以外のことも学ぶことができました。 またプロジェクトを通して、若手のエンジニアが成長できる環境だと肌で感じました。配属後まもなくプロジェクトに参画させてもらえることや必要に応じて様々な技術を触らせてもらえることはもちろんのことですが、分からないことを聞きやすくしてくれる雰囲気や手を上げたら挑戦させてもらえる環境は贅沢に感じるほどです。 このような成長できる環境で若手時代を過ごしたい新卒エンジニアの方や、技術はあくまで手段であり、顧客への価値提供を目的にしているチームで働きたいエンジニアの方を絶賛募集していますので、ご興味がある方はぜひカジュアルにお話から始めてみませんか。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 自己紹介 はじめまして。人材プラットフォーム本部プロダクト開発室第一開発グループの田中です。 私は、2023 年の 4 月に新卒エンジニアとして入社し、日本最大級の医療介護求人サイト「 ジョブメドレー 」のフロントエンドとバックエンドの開発を担当しています。 学生時代は情報系ではなく、経済学を専攻していました。プログラミングには大学の授業で出会い、主にデータ分析に用いる R や Python を触っていました。そのため Web アプリケーションの開発は行っていませんでした。 エンジニアという職業に興味を持ったきっかけは、大学院時代に参加したインターンでした。インターン先の会社ではエンジニアが誰もいなかったのですが、開発未経験の私に機械学習を使ったアプリの PoC を作れという、かなり破天荒な経験をしたためです。今ではとてもレアな経験だったと思いますが、試行錯誤しながら何かを作ることに興奮を覚えたのを今でも鮮明に覚えています。 メドレー に入社した理由は、大きな社会課題に取り組んでいる、触れられる技術がフロントエンド・バックエンドのように領域に限られていないなどありましたが、一番大きな理由は「 技術はあくまで手段であり、顧客への価値提供を目的にしている 」という考えに共感したことです。入社してまだ日は浅いですが、この考えは随所で感じられます。 大学近くのビーチの夕焼け 入社から初プロジェクトまで さて、今回の記事では新卒エンジニアの私が初めて携わったプロジェクトの紹介を通して、メドレーでは新卒エンジニアが入社後にどのような働き方をしてるか伝えることができればと思います。 入社してから研修を終えて、配属後 1 ヶ月半くらいは主にプロダクトの定常改善系のタスクに取り組みながら、仕事のリズムを覚えていきました。 その後、今回紹介するプロジェクトに初めてアサインされました。この時点でプロジェクトで主に使用するスキルセットのフロントエンドは、新卒研修で学んだ程度でした。そのような状態の新卒でも、経験をたくさん積ませてもらえる良い環境だということもお伝えできればと思っています。 プロジェクトで解決する課題と解決策 まず、今回担当したプロジェクトが発足した背景となる課題と、その課題を解決するために提供した新機能について紹介します。このプロジェクトについては、 ニュースリリース も公開していますので、合わせてご覧ください。 ユーザーの抱える課題 これまで「ジョブメドレー」では顧客が求人を作成する際に、フォーム形式で募集要項を記入する形式となっていました。記入の自由度が高いことから、法令やガイドライン等で定められた項目を漏れなく記載することや、事業所の魅力を効果的に伝える工夫が必要であり、顧客にとっては大きな負担になっていました。 フォーム形式の求人作成機能のイメージ 社内オペレーションの観点で見ると、求人が掲載基準を満たしているのか、入力された文章から読み取り確認する業務に時間がかかっていました。 そこで、顧客と社内オペレーションの双方が感じている課題を解決するプロジェクトが発足し、私も参画しました。 ユーザー目線の解決策 顧客と社内オペレーションの双方の課題を解決するため、求人作成プロセスをより直感的かつ効率的に改善しました。具体的には、従来のフォーム入力方式から、対話式の質問と回答を通じて求人を作成できる機能を導入しました。この改善により、顧客は簡単に、迷うことなく掲載基準に沿った求人を作成しやすくなりました。 さらに、文章作成の労力を軽減するために、 ChatGPT を活用した提案機能も導入しました。この機能を通じて、顧客は入力した内容に基づき、求職者の目に止まりやすい求人タイトルや訴求文を ChatGPT から提案してもらえます。これにより、求人原稿作成にかかる手間や煩雑さが軽減され、専任の採用担当がいない事業所でも採用活動を効率的に進めることができ、迅速な人材の確保へとつながります。社内オペレーションの観点でも、掲載基準を満たしているかを確認する業務の時間短縮が期待できます。 質問形式の求人作成補助機能のイメージ ChatGPT の導入有無に関しては社内でも協議され、文章生成に ChatGPT を用いることで顧客の作業コストを下げられるのであれば導入しようという意思決定がありました。流行っている技術だから導入するのではなく、 顧客への価値提供のために新しい技術を導入する 考えが現れた意思決定だと思います。 技術スタック 今回のプロジェクトでは次のような技術スタックで開発を行いました。フロントエンドは React を使用し状態管理ライブラリとして React Hooks を選択しました。従来の求人作成機能では Redux で状態管理を行っていましたが、プロダクト全体の方針として今後 React Hooks を使用していく方針であったことと、実装のスピードを早めるために React Hooks を採用しました。 ChatGPT を用いた部分に関しては、顧客からのリクエストを受けて発行したトークンを保存するために Amazon DynamoDB を使用しました。DynamoDB に保存したトークンのバリデーションと GPT へプロンプトを渡し、提案の受け取り・返却する部分は AWS Lambda function に任せていました。GPT 本体は Azure OpenAI Service を利用する構成でした。Azure OpenAI Service を採用した理由は、顧客情報や入力内容が学習に使用されることがなくプライバシー面でのリスクを回避できるためでした。 文章生成機能の構成イメージ プロジェクトへの関わり 今回のプロジェクトのメンバー構成はエンジニア 3 人、デザイナー 1 人、PM 1 人という構成でした。開発には約 3 ヶ月の期間を要しました。 プロジェクト初期 私自身のプロジェクトへの関わり方としては、プロジェクト初期段階からフロントエンドの実装タスクが中心でした。その中でスタイルの実装に関してはオーナーシップを持たせていただきました。今回のプロジェクトで作成する UI コンポーネントでは、似たようなものが複数あったため、できるだけ拡張性を持たせ使い回せるように意識して設計していました。仕事のサイクルとしては、デザイナーが作ったデザインを元に、細かい仕様を調整して実装し、デザインレビューをしてもらうサイクルを回していました。 ただ、React などをキャッチアップしながらの実装だったため、他のエンジニアより実装に時間がかかってしまっていました。適宜先輩エンジニアに質問しながら進めていましたが、いくつかのタスクは巻き取ってもらうことになるなど、悔しい気持ちを覚えたプロジェクト初期でした。 プロジェクト中盤以降 プロジェクト中盤あたりで一つエンジニアとしての仕事の向き合い方に変化がありました。プロジェクトのスケジュールがタイトだったのも相まって、プロジェクト初期ではとりあえず実装して早くタスクを終わらせることに注力していました。しかし、時間がかかっても良いから一つ一つ丁寧にコードを追って理解することに努めようと先輩エンジニアにアドバイスをいただきました。 そこから、理解に注力することで思考がクリアになり、結果的に実装スピードが上がっていきました。また、実装以外にも目を向ける余裕が生まれ、仕様について PM やデザイナーに提案することもできました。プロジェクト中盤以降は自信を持ってタスクに取り組むことができ、終盤には他のエンジニアのタスクを巻き取ることができるまでになりました。 プロジェクトの中では、プロンプトの改善タスクも任せてもらえました。内容としては意図しない回答を弾く改善でしたが、AWS Lambda を触るなど、必要があればクラウドサービスを触る機会もあると感じました。 ChatGPT による提案機能のイメージ さいごに プロジェクトを振り返って 新機能がリリースされて数ヶ月経ちましたが、定めている KPI を達成し、結果が現れていることがとても嬉しいです。一例として、顧客が新機能で求人を作成してから社内での審査を経て掲載に至るまでの日数が、従来の作成方法と比べて半分以下と大幅に削減されています。 チームとしては今回のプロジェクトの進め方について振り返りを行いました。PM 、デザイナー、エンジニアそれぞれが次のプロジェクトをより良く遂行する提案を出し合い、今回のプロジェクトの経験が無駄にならないようにしています。現在、私自身はエンジニア一人の新しいプロジェクトを任されていますが、この時の振り返りでの反省をタスク分解やスケジュール策定に役立てられています。 個人的には今回のプロジェクトを通して、フロントエンドの技術習得はもちろんのこと、プロジェクトメンバーとのコミュニケーションで文章の構造化や画像に編集を加えるなどの工夫を加えることでコミュニケーションコストを下げることができるといった技術以外のことも学ぶことができました。 またプロジェクトを通して、若手のエンジニアが成長できる環境だと肌で感じました。配属後まもなくプロジェクトに参画させてもらえることや必要に応じて様々な技術を触らせてもらえることはもちろんのことですが、分からないことを聞きやすくしてくれる雰囲気や手を上げたら挑戦させてもらえる環境は贅沢に感じるほどです。 このような成長できる環境で若手時代を過ごしたい新卒エンジニアの方や、技術はあくまで手段であり、顧客への価値提供を目的にしているチームで働きたいエンジニアの方を絶賛募集していますので、ご興味がある方はぜひカジュアルにお話から始めてみませんか。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 自己紹介 はじめまして。人材プラットフォーム本部プロダクト開発室第一開発グループの田中です。 私は、2023 年の 4 月に新卒エンジニアとして入社し、日本最大級の医療介護求人サイト「 ジョブメドレー 」のフロントエンドとバックエンドの開発を担当しています。 学生時代は情報系ではなく、経済学を専攻していました。プログラミングには大学の授業で出会い、主にデータ分析に用いる R や Python を触っていました。そのため Web アプリケーションの開発は行っていませんでした。 エンジニアという職業に興味を持ったきっかけは、大学院時代に参加したインターンでした。インターン先の会社ではエンジニアが誰もいなかったのですが、開発未経験の私に機械学習を使ったアプリの PoC を作れという、かなり破天荒な経験をしたためです。今ではとてもレアな経験だったと思いますが、試行錯誤しながら何かを作ることに興奮を覚えたのを今でも鮮明に覚えています。 メドレー に入社した理由は、大きな社会課題に取り組んでいる、触れられる技術がフロントエンド・バックエンドのように領域に限られていないなどありましたが、一番大きな理由は「 技術はあくまで手段であり、顧客への価値提供を目的にしている 」という考えに共感したことです。入社してまだ日は浅いですが、この考えは随所で感じられます。 大学近くのビーチの夕焼け 入社から初プロジェクトまで さて、今回の記事では新卒エンジニアの私が初めて携わったプロジェクトの紹介を通して、メドレーでは新卒エンジニアが入社後にどのような働き方をしてるか伝えることができればと思います。 入社してから研修を終えて、配属後 1 ヶ月半くらいは主にプロダクトの定常改善系のタスクに取り組みながら、仕事のリズムを覚えていきました。 その後、今回紹介するプロジェクトに初めてアサインされました。この時点でプロジェクトで主に使用するスキルセットのフロントエンドは、新卒研修で学んだ程度でした。そのような状態の新卒でも、経験をたくさん積ませてもらえる良い環境だということもお伝えできればと思っています。 プロジェクトで解決する課題と解決策 まず、今回担当したプロジェクトが発足した背景となる課題と、その課題を解決するために提供した新機能について紹介します。このプロジェクトについては、 ニュースリリース も公開していますので、合わせてご覧ください。 ユーザーの抱える課題 これまで「ジョブメドレー」では顧客が求人を作成する際に、フォーム形式で募集要項を記入する形式となっていました。記入の自由度が高いことから、法令やガイドライン等で定められた項目を漏れなく記載することや、事業所の魅力を効果的に伝える工夫が必要であり、顧客にとっては大きな負担になっていました。 フォーム形式の求人作成機能のイメージ 社内オペレーションの観点で見ると、求人が掲載基準を満たしているのか、入力された文章から読み取り確認する業務に時間がかかっていました。 そこで、顧客と社内オペレーションの双方が感じている課題を解決するプロジェクトが発足し、私も参画しました。 ユーザー目線の解決策 顧客と社内オペレーションの双方の課題を解決するため、求人作成プロセスをより直感的かつ効率的に改善しました。具体的には、従来のフォーム入力方式から、対話式の質問と回答を通じて求人を作成できる機能を導入しました。この改善により、顧客は簡単に、迷うことなく掲載基準に沿った求人を作成しやすくなりました。 さらに、文章作成の労力を軽減するために、 ChatGPT を活用した提案機能も導入しました。この機能を通じて、顧客は入力した内容に基づき、求職者の目に止まりやすい求人タイトルや訴求文を ChatGPT から提案してもらえます。これにより、求人原稿作成にかかる手間や煩雑さが軽減され、専任の採用担当がいない事業所でも採用活動を効率的に進めることができ、迅速な人材の確保へとつながります。社内オペレーションの観点でも、掲載基準を満たしているかを確認する業務の時間短縮が期待できます。 質問形式の求人作成補助機能のイメージ ChatGPT の導入有無に関しては社内でも協議され、文章生成に ChatGPT を用いることで顧客の作業コストを下げられるのであれば導入しようという意思決定がありました。流行っている技術だから導入するのではなく、 顧客への価値提供のために新しい技術を導入する 考えが現れた意思決定だと思います。 技術スタック 今回のプロジェクトでは次のような技術スタックで開発を行いました。フロントエンドは React を使用し状態管理ライブラリとして React Hooks を選択しました。従来の求人作成機能では Redux で状態管理を行っていましたが、プロダクト全体の方針として今後 React Hooks を使用していく方針であったことと、実装のスピードを早めるために React Hooks を採用しました。 ChatGPT を用いた部分に関しては、顧客からのリクエストを受けて発行したトークンを保存するために Amazon DynamoDB を使用しました。DynamoDB に保存したトークンのバリデーションと GPT へプロンプトを渡し、提案の受け取り・返却する部分は AWS Lambda function に任せていました。GPT 本体は Azure OpenAI Service を利用する構成でした。Azure OpenAI Service を採用した理由は、顧客情報や入力内容が学習に使用されることがなくプライバシー面でのリスクを回避できるためでした。 文章生成機能の構成イメージ プロジェクトへの関わり 今回のプロジェクトのメンバー構成はエンジニア 3 人、デザイナー 1 人、PM 1 人という構成でした。開発には約 3 ヶ月の期間を要しました。 プロジェクト初期 私自身のプロジェクトへの関わり方としては、プロジェクト初期段階からフロントエンドの実装タスクが中心でした。その中でスタイルの実装に関してはオーナーシップを持たせていただきました。今回のプロジェクトで作成する UI コンポーネントでは、似たようなものが複数あったため、できるだけ拡張性を持たせ使い回せるように意識して設計していました。仕事のサイクルとしては、デザイナーが作ったデザインを元に、細かい仕様を調整して実装し、デザインレビューをしてもらうサイクルを回していました。 ただ、React などをキャッチアップしながらの実装だったため、他のエンジニアより実装に時間がかかってしまっていました。適宜先輩エンジニアに質問しながら進めていましたが、いくつかのタスクは巻き取ってもらうことになるなど、悔しい気持ちを覚えたプロジェクト初期でした。 プロジェクト中盤以降 プロジェクト中盤あたりで一つエンジニアとしての仕事の向き合い方に変化がありました。プロジェクトのスケジュールがタイトだったのも相まって、プロジェクト初期ではとりあえず実装して早くタスクを終わらせることに注力していました。しかし、時間がかかっても良いから一つ一つ丁寧にコードを追って理解することに努めようと先輩エンジニアにアドバイスをいただきました。 そこから、理解に注力することで思考がクリアになり、結果的に実装スピードが上がっていきました。また、実装以外にも目を向ける余裕が生まれ、仕様について PM やデザイナーに提案することもできました。プロジェクト中盤以降は自信を持ってタスクに取り組むことができ、終盤には他のエンジニアのタスクを巻き取ることができるまでになりました。 プロジェクトの中では、プロンプトの改善タスクも任せてもらえました。内容としては意図しない回答を弾く改善でしたが、AWS Lambda を触るなど、必要があればクラウドサービスを触る機会もあると感じました。 ChatGPT による提案機能のイメージ さいごに プロジェクトを振り返って 新機能がリリースされて数ヶ月経ちましたが、定めている KPI を達成し、結果が現れていることがとても嬉しいです。一例として、顧客が新機能で求人を作成してから社内での審査を経て掲載に至るまでの日数が、従来の作成方法と比べて半分以下と大幅に削減されています。 チームとしては今回のプロジェクトの進め方について振り返りを行いました。PM 、デザイナー、エンジニアそれぞれが次のプロジェクトをより良く遂行する提案を出し合い、今回のプロジェクトの経験が無駄にならないようにしています。現在、私自身はエンジニア一人の新しいプロジェクトを任されていますが、この時の振り返りでの反省をタスク分解やスケジュール策定に役立てられています。 個人的には今回のプロジェクトを通して、フロントエンドの技術習得はもちろんのこと、プロジェクトメンバーとのコミュニケーションで文章の構造化や画像に編集を加えるなどの工夫を加えることでコミュニケーションコストを下げることができるといった技術以外のことも学ぶことができました。 またプロジェクトを通して、若手のエンジニアが成長できる環境だと肌で感じました。配属後まもなくプロジェクトに参画させてもらえることや必要に応じて様々な技術を触らせてもらえることはもちろんのことですが、分からないことを聞きやすくしてくれる雰囲気や手を上げたら挑戦させてもらえる環境は贅沢に感じるほどです。 このような成長できる環境で若手時代を過ごしたい新卒エンジニアの方や、技術はあくまで手段であり、顧客への価値提供を目的にしているチームで働きたいエンジニアの方を絶賛募集していますので、ご興味がある方はぜひカジュアルにお話から始めてみませんか。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 自己紹介 はじめまして。人材プラットフォーム本部プロダクト開発室第一開発グループの田中です。 私は、2023 年の 4 月に新卒エンジニアとして入社し、日本最大級の医療介護求人サイト「 ジョブメドレー 」のフロントエンドとバックエンドの開発を担当しています。 学生時代は情報系ではなく、経済学を専攻していました。プログラミングには大学の授業で出会い、主にデータ分析に用いる R や Python を触っていました。そのため Web アプリケーションの開発は行っていませんでした。 エンジニアという職業に興味を持ったきっかけは、大学院時代に参加したインターンでした。インターン先の会社ではエンジニアが誰もいなかったのですが、開発未経験の私に機械学習を使ったアプリの PoC を作れという、かなり破天荒な経験をしたためです。今ではとてもレアな経験だったと思いますが、試行錯誤しながら何かを作ることに興奮を覚えたのを今でも鮮明に覚えています。 メドレー に入社した理由は、大きな社会課題に取り組んでいる、触れられる技術がフロントエンド・バックエンドのように領域に限られていないなどありましたが、一番大きな理由は「 技術はあくまで手段であり、顧客への価値提供を目的にしている 」という考えに共感したことです。入社してまだ日は浅いですが、この考えは随所で感じられます。 大学近くのビーチの夕焼け 入社から初プロジェクトまで さて、今回の記事では新卒エンジニアの私が初めて携わったプロジェクトの紹介を通して、メドレーでは新卒エンジニアが入社後にどのような働き方をしてるか伝えることができればと思います。 入社してから研修を終えて、配属後 1 ヶ月半くらいは主にプロダクトの定常改善系のタスクに取り組みながら、仕事のリズムを覚えていきました。 その後、今回紹介するプロジェクトに初めてアサインされました。この時点でプロジェクトで主に使用するスキルセットのフロントエンドは、新卒研修で学んだ程度でした。そのような状態の新卒でも、経験をたくさん積ませてもらえる良い環境だということもお伝えできればと思っています。 プロジェクトで解決する課題と解決策 まず、今回担当したプロジェクトが発足した背景となる課題と、その課題を解決するために提供した新機能について紹介します。このプロジェクトについては、 ニュースリリース も公開していますので、合わせてご覧ください。 ユーザーの抱える課題 これまで「ジョブメドレー」では顧客が求人を作成する際に、フォーム形式で募集要項を記入する形式となっていました。記入の自由度が高いことから、法令やガイドライン等で定められた項目を漏れなく記載することや、事業所の魅力を効果的に伝える工夫が必要であり、顧客にとっては大きな負担になっていました。 フォーム形式の求人作成機能のイメージ 社内オペレーションの観点で見ると、求人が掲載基準を満たしているのか、入力された文章から読み取り確認する業務に時間がかかっていました。 そこで、顧客と社内オペレーションの双方が感じている課題を解決するプロジェクトが発足し、私も参画しました。 ユーザー目線の解決策 顧客と社内オペレーションの双方の課題を解決するため、求人作成プロセスをより直感的かつ効率的に改善しました。具体的には、従来のフォーム入力方式から、対話式の質問と回答を通じて求人を作成できる機能を導入しました。この改善により、顧客は簡単に、迷うことなく掲載基準に沿った求人を作成しやすくなりました。 さらに、文章作成の労力を軽減するために、 ChatGPT を活用した提案機能も導入しました。この機能を通じて、顧客は入力した内容に基づき、求職者の目に止まりやすい求人タイトルや訴求文を ChatGPT から提案してもらえます。これにより、求人原稿作成にかかる手間や煩雑さが軽減され、専任の採用担当がいない事業所でも採用活動を効率的に進めることができ、迅速な人材の確保へとつながります。社内オペレーションの観点でも、掲載基準を満たしているかを確認する業務の時間短縮が期待できます。 質問形式の求人作成補助機能のイメージ ChatGPT の導入有無に関しては社内でも協議され、文章生成に ChatGPT を用いることで顧客の作業コストを下げられるのであれば導入しようという意思決定がありました。流行っている技術だから導入するのではなく、 顧客への価値提供のために新しい技術を導入する 考えが現れた意思決定だと思います。 技術スタック 今回のプロジェクトでは次のような技術スタックで開発を行いました。フロントエンドは React を使用し状態管理ライブラリとして React Hooks を選択しました。従来の求人作成機能では Redux で状態管理を行っていましたが、プロダクト全体の方針として今後 React Hooks を使用していく方針であったことと、実装のスピードを早めるために React Hooks を採用しました。 ChatGPT を用いた部分に関しては、顧客からのリクエストを受けて発行したトークンを保存するために Amazon DynamoDB を使用しました。DynamoDB に保存したトークンのバリデーションと GPT へプロンプトを渡し、提案の受け取り・返却する部分は AWS Lambda function に任せていました。GPT 本体は Azure OpenAI Service を利用する構成でした。Azure OpenAI Service を採用した理由は、顧客情報や入力内容が学習に使用されることがなくプライバシー面でのリスクを回避できるためでした。 文章生成機能の構成イメージ プロジェクトへの関わり 今回のプロジェクトのメンバー構成はエンジニア 3 人、デザイナー 1 人、PM 1 人という構成でした。開発には約 3 ヶ月の期間を要しました。 プロジェクト初期 私自身のプロジェクトへの関わり方としては、プロジェクト初期段階からフロントエンドの実装タスクが中心でした。その中でスタイルの実装に関してはオーナーシップを持たせていただきました。今回のプロジェクトで作成する UI コンポーネントでは、似たようなものが複数あったため、できるだけ拡張性を持たせ使い回せるように意識して設計していました。仕事のサイクルとしては、デザイナーが作ったデザインを元に、細かい仕様を調整して実装し、デザインレビューをしてもらうサイクルを回していました。 ただ、React などをキャッチアップしながらの実装だったため、他のエンジニアより実装に時間がかかってしまっていました。適宜先輩エンジニアに質問しながら進めていましたが、いくつかのタスクは巻き取ってもらうことになるなど、悔しい気持ちを覚えたプロジェクト初期でした。 プロジェクト中盤以降 プロジェクト中盤あたりで一つエンジニアとしての仕事の向き合い方に変化がありました。プロジェクトのスケジュールがタイトだったのも相まって、プロジェクト初期ではとりあえず実装して早くタスクを終わらせることに注力していました。しかし、時間がかかっても良いから一つ一つ丁寧にコードを追って理解することに努めようと先輩エンジニアにアドバイスをいただきました。 そこから、理解に注力することで思考がクリアになり、結果的に実装スピードが上がっていきました。また、実装以外にも目を向ける余裕が生まれ、仕様について PM やデザイナーに提案することもできました。プロジェクト中盤以降は自信を持ってタスクに取り組むことができ、終盤には他のエンジニアのタスクを巻き取ることができるまでになりました。 プロジェクトの中では、プロンプトの改善タスクも任せてもらえました。内容としては意図しない回答を弾く改善でしたが、AWS Lambda を触るなど、必要があればクラウドサービスを触る機会もあると感じました。 ChatGPT による提案機能のイメージ さいごに プロジェクトを振り返って 新機能がリリースされて数ヶ月経ちましたが、定めている KPI を達成し、結果が現れていることがとても嬉しいです。一例として、顧客が新機能で求人を作成してから社内での審査を経て掲載に至るまでの日数が、従来の作成方法と比べて半分以下と大幅に削減されています。 チームとしては今回のプロジェクトの進め方について振り返りを行いました。PM 、デザイナー、エンジニアそれぞれが次のプロジェクトをより良く遂行する提案を出し合い、今回のプロジェクトの経験が無駄にならないようにしています。現在、私自身はエンジニア一人の新しいプロジェクトを任されていますが、この時の振り返りでの反省をタスク分解やスケジュール策定に役立てられています。 個人的には今回のプロジェクトを通して、フロントエンドの技術習得はもちろんのこと、プロジェクトメンバーとのコミュニケーションで文章の構造化や画像に編集を加えるなどの工夫を加えることでコミュニケーションコストを下げることができるといった技術以外のことも学ぶことができました。 またプロジェクトを通して、若手のエンジニアが成長できる環境だと肌で感じました。配属後まもなくプロジェクトに参画させてもらえることや必要に応じて様々な技術を触らせてもらえることはもちろんのことですが、分からないことを聞きやすくしてくれる雰囲気や手を上げたら挑戦させてもらえる環境は贅沢に感じるほどです。 このような成長できる環境で若手時代を過ごしたい新卒エンジニアの方や、技術はあくまで手段であり、顧客への価値提供を目的にしているチームで働きたいエンジニアの方を絶賛募集していますので、ご興味がある方はぜひカジュアルにお話から始めてみませんか。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 自己紹介 はじめまして。人材プラットフォーム本部プロダクト開発室第一開発グループの田中です。 私は、2023 年の 4 月に新卒エンジニアとして入社し、日本最大級の医療介護求人サイト「 ジョブメドレー 」のフロントエンドとバックエンドの開発を担当しています。 学生時代は情報系ではなく、経済学を専攻していました。プログラミングには大学の授業で出会い、主にデータ分析に用いる R や Python を触っていました。そのため Web アプリケーションの開発は行っていませんでした。 エンジニアという職業に興味を持ったきっかけは、大学院時代に参加したインターンでした。インターン先の会社ではエンジニアが誰もいなかったのですが、開発未経験の私に機械学習を使ったアプリの PoC を作れという、かなり破天荒な経験をしたためです。今ではとてもレアな経験だったと思いますが、試行錯誤しながら何かを作ることに興奮を覚えたのを今でも鮮明に覚えています。 メドレー に入社した理由は、大きな社会課題に取り組んでいる、触れられる技術がフロントエンド・バックエンドのように領域に限られていないなどありましたが、一番大きな理由は「 技術はあくまで手段であり、顧客への価値提供を目的にしている 」という考えに共感したことです。入社してまだ日は浅いですが、この考えは随所で感じられます。 大学近くのビーチの夕焼け 入社から初プロジェクトまで さて、今回の記事では新卒エンジニアの私が初めて携わったプロジェクトの紹介を通して、メドレーでは新卒エンジニアが入社後にどのような働き方をしてるか伝えることができればと思います。 入社してから研修を終えて、配属後 1 ヶ月半くらいは主にプロダクトの定常改善系のタスクに取り組みながら、仕事のリズムを覚えていきました。 その後、今回紹介するプロジェクトに初めてアサインされました。この時点でプロジェクトで主に使用するスキルセットのフロントエンドは、新卒研修で学んだ程度でした。そのような状態の新卒でも、経験をたくさん積ませてもらえる良い環境だということもお伝えできればと思っています。 プロジェクトで解決する課題と解決策 まず、今回担当したプロジェクトが発足した背景となる課題と、その課題を解決するために提供した新機能について紹介します。このプロジェクトについては、 ニュースリリース も公開していますので、合わせてご覧ください。 ユーザーの抱える課題 これまで「ジョブメドレー」では顧客が求人を作成する際に、フォーム形式で募集要項を記入する形式となっていました。記入の自由度が高いことから、法令やガイドライン等で定められた項目を漏れなく記載することや、事業所の魅力を効果的に伝える工夫が必要であり、顧客にとっては大きな負担になっていました。 フォーム形式の求人作成機能のイメージ 社内オペレーションの観点で見ると、求人が掲載基準を満たしているのか、入力された文章から読み取り確認する業務に時間がかかっていました。 そこで、顧客と社内オペレーションの双方が感じている課題を解決するプロジェクトが発足し、私も参画しました。 ユーザー目線の解決策 顧客と社内オペレーションの双方の課題を解決するため、求人作成プロセスをより直感的かつ効率的に改善しました。具体的には、従来のフォーム入力方式から、対話式の質問と回答を通じて求人を作成できる機能を導入しました。この改善により、顧客は簡単に、迷うことなく掲載基準に沿った求人を作成しやすくなりました。 さらに、文章作成の労力を軽減するために、 ChatGPT を活用した提案機能も導入しました。この機能を通じて、顧客は入力した内容に基づき、求職者の目に止まりやすい求人タイトルや訴求文を ChatGPT から提案してもらえます。これにより、求人原稿作成にかかる手間や煩雑さが軽減され、専任の採用担当がいない事業所でも採用活動を効率的に進めることができ、迅速な人材の確保へとつながります。社内オペレーションの観点でも、掲載基準を満たしているかを確認する業務の時間短縮が期待できます。 質問形式の求人作成補助機能のイメージ ChatGPT の導入有無に関しては社内でも協議され、文章生成に ChatGPT を用いることで顧客の作業コストを下げられるのであれば導入しようという意思決定がありました。流行っている技術だから導入するのではなく、 顧客への価値提供のために新しい技術を導入する 考えが現れた意思決定だと思います。 技術スタック 今回のプロジェクトでは次のような技術スタックで開発を行いました。フロントエンドは React を使用し状態管理ライブラリとして React Hooks を選択しました。従来の求人作成機能では Redux で状態管理を行っていましたが、プロダクト全体の方針として今後 React Hooks を使用していく方針であったことと、実装のスピードを早めるために React Hooks を採用しました。 ChatGPT を用いた部分に関しては、顧客からのリクエストを受けて発行したトークンを保存するために Amazon DynamoDB を使用しました。DynamoDB に保存したトークンのバリデーションと GPT へプロンプトを渡し、提案の受け取り・返却する部分は AWS Lambda function に任せていました。GPT 本体は Azure OpenAI Service を利用する構成でした。Azure OpenAI Service を採用した理由は、顧客情報や入力内容が学習に使用されることがなくプライバシー面でのリスクを回避できるためでした。 文章生成機能の構成イメージ プロジェクトへの関わり 今回のプロジェクトのメンバー構成はエンジニア 3 人、デザイナー 1 人、PM 1 人という構成でした。開発には約 3 ヶ月の期間を要しました。 プロジェクト初期 私自身のプロジェクトへの関わり方としては、プロジェクト初期段階からフロントエンドの実装タスクが中心でした。その中でスタイルの実装に関してはオーナーシップを持たせていただきました。今回のプロジェクトで作成する UI コンポーネントでは、似たようなものが複数あったため、できるだけ拡張性を持たせ使い回せるように意識して設計していました。仕事のサイクルとしては、デザイナーが作ったデザインを元に、細かい仕様を調整して実装し、デザインレビューをしてもらうサイクルを回していました。 ただ、React などをキャッチアップしながらの実装だったため、他のエンジニアより実装に時間がかかってしまっていました。適宜先輩エンジニアに質問しながら進めていましたが、いくつかのタスクは巻き取ってもらうことになるなど、悔しい気持ちを覚えたプロジェクト初期でした。 プロジェクト中盤以降 プロジェクト中盤あたりで一つエンジニアとしての仕事の向き合い方に変化がありました。プロジェクトのスケジュールがタイトだったのも相まって、プロジェクト初期ではとりあえず実装して早くタスクを終わらせることに注力していました。しかし、時間がかかっても良いから一つ一つ丁寧にコードを追って理解することに努めようと先輩エンジニアにアドバイスをいただきました。 そこから、理解に注力することで思考がクリアになり、結果的に実装スピードが上がっていきました。また、実装以外にも目を向ける余裕が生まれ、仕様について PM やデザイナーに提案することもできました。プロジェクト中盤以降は自信を持ってタスクに取り組むことができ、終盤には他のエンジニアのタスクを巻き取ることができるまでになりました。 プロジェクトの中では、プロンプトの改善タスクも任せてもらえました。内容としては意図しない回答を弾く改善でしたが、AWS Lambda を触るなど、必要があればクラウドサービスを触る機会もあると感じました。 ChatGPT による提案機能のイメージ さいごに プロジェクトを振り返って 新機能がリリースされて数ヶ月経ちましたが、定めている KPI を達成し、結果が現れていることがとても嬉しいです。一例として、顧客が新機能で求人を作成してから社内での審査を経て掲載に至るまでの日数が、従来の作成方法と比べて半分以下と大幅に削減されています。 チームとしては今回のプロジェクトの進め方について振り返りを行いました。PM 、デザイナー、エンジニアそれぞれが次のプロジェクトをより良く遂行する提案を出し合い、今回のプロジェクトの経験が無駄にならないようにしています。現在、私自身はエンジニア一人の新しいプロジェクトを任されていますが、この時の振り返りでの反省をタスク分解やスケジュール策定に役立てられています。 個人的には今回のプロジェクトを通して、フロントエンドの技術習得はもちろんのこと、プロジェクトメンバーとのコミュニケーションで文章の構造化や画像に編集を加えるなどの工夫を加えることでコミュニケーションコストを下げることができるといった技術以外のことも学ぶことができました。 またプロジェクトを通して、若手のエンジニアが成長できる環境だと肌で感じました。配属後まもなくプロジェクトに参画させてもらえることや必要に応じて様々な技術を触らせてもらえることはもちろんのことですが、分からないことを聞きやすくしてくれる雰囲気や手を上げたら挑戦させてもらえる環境は贅沢に感じるほどです。 このような成長できる環境で若手時代を過ごしたい新卒エンジニアの方や、技術はあくまで手段であり、顧客への価値提供を目的にしているチームで働きたいエンジニアの方を絶賛募集していますので、ご興味がある方はぜひカジュアルにお話から始めてみませんか。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 自己紹介 はじめまして。人材プラットフォーム本部プロダクト開発室第一開発グループの田中です。 私は、2023 年の 4 月に新卒エンジニアとして入社し、日本最大級の医療介護求人サイト「 ジョブメドレー 」のフロントエンドとバックエンドの開発を担当しています。 学生時代は情報系ではなく、経済学を専攻していました。プログラミングには大学の授業で出会い、主にデータ分析に用いる R や Python を触っていました。そのため Web アプリケーションの開発は行っていませんでした。 エンジニアという職業に興味を持ったきっかけは、大学院時代に参加したインターンでした。インターン先の会社ではエンジニアが誰もいなかったのですが、開発未経験の私に機械学習を使ったアプリの PoC を作れという、かなり破天荒な経験をしたためです。今ではとてもレアな経験だったと思いますが、試行錯誤しながら何かを作ることに興奮を覚えたのを今でも鮮明に覚えています。 メドレー に入社した理由は、大きな社会課題に取り組んでいる、触れられる技術がフロントエンド・バックエンドのように領域に限られていないなどありましたが、一番大きな理由は「 技術はあくまで手段であり、顧客への価値提供を目的にしている 」という考えに共感したことです。入社してまだ日は浅いですが、この考えは随所で感じられます。 大学近くのビーチの夕焼け 入社から初プロジェクトまで さて、今回の記事では新卒エンジニアの私が初めて携わったプロジェクトの紹介を通して、メドレーでは新卒エンジニアが入社後にどのような働き方をしてるか伝えることができればと思います。 入社してから研修を終えて、配属後 1 ヶ月半くらいは主にプロダクトの定常改善系のタスクに取り組みながら、仕事のリズムを覚えていきました。 その後、今回紹介するプロジェクトに初めてアサインされました。この時点でプロジェクトで主に使用するスキルセットのフロントエンドは、新卒研修で学んだ程度でした。そのような状態の新卒でも、経験をたくさん積ませてもらえる良い環境だということもお伝えできればと思っています。 プロジェクトで解決する課題と解決策 まず、今回担当したプロジェクトが発足した背景となる課題と、その課題を解決するために提供した新機能について紹介します。このプロジェクトについては、 ニュースリリース も公開していますので、合わせてご覧ください。 ユーザーの抱える課題 これまで「ジョブメドレー」では顧客が求人を作成する際に、フォーム形式で募集要項を記入する形式となっていました。記入の自由度が高いことから、法令やガイドライン等で定められた項目を漏れなく記載することや、事業所の魅力を効果的に伝える工夫が必要であり、顧客にとっては大きな負担になっていました。 フォーム形式の求人作成機能のイメージ 社内オペレーションの観点で見ると、求人が掲載基準を満たしているのか、入力された文章から読み取り確認する業務に時間がかかっていました。 そこで、顧客と社内オペレーションの双方が感じている課題を解決するプロジェクトが発足し、私も参画しました。 ユーザー目線の解決策 顧客と社内オペレーションの双方の課題を解決するため、求人作成プロセスをより直感的かつ効率的に改善しました。具体的には、従来のフォーム入力方式から、対話式の質問と回答を通じて求人を作成できる機能を導入しました。この改善により、顧客は簡単に、迷うことなく掲載基準に沿った求人を作成しやすくなりました。 さらに、文章作成の労力を軽減するために、 ChatGPT を活用した提案機能も導入しました。この機能を通じて、顧客は入力した内容に基づき、求職者の目に止まりやすい求人タイトルや訴求文を ChatGPT から提案してもらえます。これにより、求人原稿作成にかかる手間や煩雑さが軽減され、専任の採用担当がいない事業所でも採用活動を効率的に進めることができ、迅速な人材の確保へとつながります。社内オペレーションの観点でも、掲載基準を満たしているかを確認する業務の時間短縮が期待できます。 質問形式の求人作成補助機能のイメージ ChatGPT の導入有無に関しては社内でも協議され、文章生成に ChatGPT を用いることで顧客の作業コストを下げられるのであれば導入しようという意思決定がありました。流行っている技術だから導入するのではなく、 顧客への価値提供のために新しい技術を導入する 考えが現れた意思決定だと思います。 技術スタック 今回のプロジェクトでは次のような技術スタックで開発を行いました。フロントエンドは React を使用し状態管理ライブラリとして React Hooks を選択しました。従来の求人作成機能では Redux で状態管理を行っていましたが、プロダクト全体の方針として今後 React Hooks を使用していく方針であったことと、実装のスピードを早めるために React Hooks を採用しました。 ChatGPT を用いた部分に関しては、顧客からのリクエストを受けて発行したトークンを保存するために Amazon DynamoDB を使用しました。DynamoDB に保存したトークンのバリデーションと GPT へプロンプトを渡し、提案の受け取り・返却する部分は AWS Lambda function に任せていました。GPT 本体は Azure OpenAI Service を利用する構成でした。Azure OpenAI Service を採用した理由は、顧客情報や入力内容が学習に使用されることがなくプライバシー面でのリスクを回避できるためでした。 文章生成機能の構成イメージ プロジェクトへの関わり 今回のプロジェクトのメンバー構成はエンジニア 3 人、デザイナー 1 人、PM 1 人という構成でした。開発には約 3 ヶ月の期間を要しました。 プロジェクト初期 私自身のプロジェクトへの関わり方としては、プロジェクト初期段階からフロントエンドの実装タスクが中心でした。その中でスタイルの実装に関してはオーナーシップを持たせていただきました。今回のプロジェクトで作成する UI コンポーネントでは、似たようなものが複数あったため、できるだけ拡張性を持たせ使い回せるように意識して設計していました。仕事のサイクルとしては、デザイナーが作ったデザインを元に、細かい仕様を調整して実装し、デザインレビューをしてもらうサイクルを回していました。 ただ、React などをキャッチアップしながらの実装だったため、他のエンジニアより実装に時間がかかってしまっていました。適宜先輩エンジニアに質問しながら進めていましたが、いくつかのタスクは巻き取ってもらうことになるなど、悔しい気持ちを覚えたプロジェクト初期でした。 プロジェクト中盤以降 プロジェクト中盤あたりで一つエンジニアとしての仕事の向き合い方に変化がありました。プロジェクトのスケジュールがタイトだったのも相まって、プロジェクト初期ではとりあえず実装して早くタスクを終わらせることに注力していました。しかし、時間がかかっても良いから一つ一つ丁寧にコードを追って理解することに努めようと先輩エンジニアにアドバイスをいただきました。 そこから、理解に注力することで思考がクリアになり、結果的に実装スピードが上がっていきました。また、実装以外にも目を向ける余裕が生まれ、仕様について PM やデザイナーに提案することもできました。プロジェクト中盤以降は自信を持ってタスクに取り組むことができ、終盤には他のエンジニアのタスクを巻き取ることができるまでになりました。 プロジェクトの中では、プロンプトの改善タスクも任せてもらえました。内容としては意図しない回答を弾く改善でしたが、AWS Lambda を触るなど、必要があればクラウドサービスを触る機会もあると感じました。 ChatGPT による提案機能のイメージ さいごに プロジェクトを振り返って 新機能がリリースされて数ヶ月経ちましたが、定めている KPI を達成し、結果が現れていることがとても嬉しいです。一例として、顧客が新機能で求人を作成してから社内での審査を経て掲載に至るまでの日数が、従来の作成方法と比べて半分以下と大幅に削減されています。 チームとしては今回のプロジェクトの進め方について振り返りを行いました。PM 、デザイナー、エンジニアそれぞれが次のプロジェクトをより良く遂行する提案を出し合い、今回のプロジェクトの経験が無駄にならないようにしています。現在、私自身はエンジニア一人の新しいプロジェクトを任されていますが、この時の振り返りでの反省をタスク分解やスケジュール策定に役立てられています。 個人的には今回のプロジェクトを通して、フロントエンドの技術習得はもちろんのこと、プロジェクトメンバーとのコミュニケーションで文章の構造化や画像に編集を加えるなどの工夫を加えることでコミュニケーションコストを下げることができるといった技術以外のことも学ぶことができました。 またプロジェクトを通して、若手のエンジニアが成長できる環境だと肌で感じました。配属後まもなくプロジェクトに参画させてもらえることや必要に応じて様々な技術を触らせてもらえることはもちろんのことですが、分からないことを聞きやすくしてくれる雰囲気や手を上げたら挑戦させてもらえる環境は贅沢に感じるほどです。 このような成長できる環境で若手時代を過ごしたい新卒エンジニアの方や、技術はあくまで手段であり、顧客への価値提供を目的にしているチームで働きたいエンジニアの方を絶賛募集していますので、ご興味がある方はぜひカジュアルにお話から始めてみませんか。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 自己紹介 はじめまして。人材プラットフォーム本部プロダクト開発室第一開発グループの田中です。 私は、2023 年の 4 月に新卒エンジニアとして入社し、日本最大級の医療介護求人サイト「 ジョブメドレー 」のフロントエンドとバックエンドの開発を担当しています。 学生時代は情報系ではなく、経済学を専攻していました。プログラミングには大学の授業で出会い、主にデータ分析に用いる R や Python を触っていました。そのため Web アプリケーションの開発は行っていませんでした。 エンジニアという職業に興味を持ったきっかけは、大学院時代に参加したインターンでした。インターン先の会社ではエンジニアが誰もいなかったのですが、開発未経験の私に機械学習を使ったアプリの PoC を作れという、かなり破天荒な経験をしたためです。今ではとてもレアな経験だったと思いますが、試行錯誤しながら何かを作ることに興奮を覚えたのを今でも鮮明に覚えています。 メドレー に入社した理由は、大きな社会課題に取り組んでいる、触れられる技術がフロントエンド・バックエンドのように領域に限られていないなどありましたが、一番大きな理由は「 技術はあくまで手段であり、顧客への価値提供を目的にしている 」という考えに共感したことです。入社してまだ日は浅いですが、この考えは随所で感じられます。 大学近くのビーチの夕焼け 入社から初プロジェクトまで さて、今回の記事では新卒エンジニアの私が初めて携わったプロジェクトの紹介を通して、メドレーでは新卒エンジニアが入社後にどのような働き方をしてるか伝えることができればと思います。 入社してから研修を終えて、配属後 1 ヶ月半くらいは主にプロダクトの定常改善系のタスクに取り組みながら、仕事のリズムを覚えていきました。 その後、今回紹介するプロジェクトに初めてアサインされました。この時点でプロジェクトで主に使用するスキルセットのフロントエンドは、新卒研修で学んだ程度でした。そのような状態の新卒でも、経験をたくさん積ませてもらえる良い環境だということもお伝えできればと思っています。 プロジェクトで解決する課題と解決策 まず、今回担当したプロジェクトが発足した背景となる課題と、その課題を解決するために提供した新機能について紹介します。このプロジェクトについては、 ニュースリリース も公開していますので、合わせてご覧ください。 ユーザーの抱える課題 これまで「ジョブメドレー」では顧客が求人を作成する際に、フォーム形式で募集要項を記入する形式となっていました。記入の自由度が高いことから、法令やガイドライン等で定められた項目を漏れなく記載することや、事業所の魅力を効果的に伝える工夫が必要であり、顧客にとっては大きな負担になっていました。 フォーム形式の求人作成機能のイメージ 社内オペレーションの観点で見ると、求人が掲載基準を満たしているのか、入力された文章から読み取り確認する業務に時間がかかっていました。 そこで、顧客と社内オペレーションの双方が感じている課題を解決するプロジェクトが発足し、私も参画しました。 ユーザー目線の解決策 顧客と社内オペレーションの双方の課題を解決するため、求人作成プロセスをより直感的かつ効率的に改善しました。具体的には、従来のフォーム入力方式から、対話式の質問と回答を通じて求人を作成できる機能を導入しました。この改善により、顧客は簡単に、迷うことなく掲載基準に沿った求人を作成しやすくなりました。 さらに、文章作成の労力を軽減するために、 ChatGPT を活用した提案機能も導入しました。この機能を通じて、顧客は入力した内容に基づき、求職者の目に止まりやすい求人タイトルや訴求文を ChatGPT から提案してもらえます。これにより、求人原稿作成にかかる手間や煩雑さが軽減され、専任の採用担当がいない事業所でも採用活動を効率的に進めることができ、迅速な人材の確保へとつながります。社内オペレーションの観点でも、掲載基準を満たしているかを確認する業務の時間短縮が期待できます。 質問形式の求人作成補助機能のイメージ ChatGPT の導入有無に関しては社内でも協議され、文章生成に ChatGPT を用いることで顧客の作業コストを下げられるのであれば導入しようという意思決定がありました。流行っている技術だから導入するのではなく、 顧客への価値提供のために新しい技術を導入する 考えが現れた意思決定だと思います。 技術スタック 今回のプロジェクトでは次のような技術スタックで開発を行いました。フロントエンドは React を使用し状態管理ライブラリとして React Hooks を選択しました。従来の求人作成機能では Redux で状態管理を行っていましたが、プロダクト全体の方針として今後 React Hooks を使用していく方針であったことと、実装のスピードを早めるために React Hooks を採用しました。 ChatGPT を用いた部分に関しては、顧客からのリクエストを受けて発行したトークンを保存するために Amazon DynamoDB を使用しました。DynamoDB に保存したトークンのバリデーションと GPT へプロンプトを渡し、提案の受け取り・返却する部分は AWS Lambda function に任せていました。GPT 本体は Azure OpenAI Service を利用する構成でした。Azure OpenAI Service を採用した理由は、顧客情報や入力内容が学習に使用されることがなくプライバシー面でのリスクを回避できるためでした。 文章生成機能の構成イメージ プロジェクトへの関わり 今回のプロジェクトのメンバー構成はエンジニア 3 人、デザイナー 1 人、PM 1 人という構成でした。開発には約 3 ヶ月の期間を要しました。 プロジェクト初期 私自身のプロジェクトへの関わり方としては、プロジェクト初期段階からフロントエンドの実装タスクが中心でした。その中でスタイルの実装に関してはオーナーシップを持たせていただきました。今回のプロジェクトで作成する UI コンポーネントでは、似たようなものが複数あったため、できるだけ拡張性を持たせ使い回せるように意識して設計していました。仕事のサイクルとしては、デザイナーが作ったデザインを元に、細かい仕様を調整して実装し、デザインレビューをしてもらうサイクルを回していました。 ただ、React などをキャッチアップしながらの実装だったため、他のエンジニアより実装に時間がかかってしまっていました。適宜先輩エンジニアに質問しながら進めていましたが、いくつかのタスクは巻き取ってもらうことになるなど、悔しい気持ちを覚えたプロジェクト初期でした。 プロジェクト中盤以降 プロジェクト中盤あたりで一つエンジニアとしての仕事の向き合い方に変化がありました。プロジェクトのスケジュールがタイトだったのも相まって、プロジェクト初期ではとりあえず実装して早くタスクを終わらせることに注力していました。しかし、時間がかかっても良いから一つ一つ丁寧にコードを追って理解することに努めようと先輩エンジニアにアドバイスをいただきました。 そこから、理解に注力することで思考がクリアになり、結果的に実装スピードが上がっていきました。また、実装以外にも目を向ける余裕が生まれ、仕様について PM やデザイナーに提案することもできました。プロジェクト中盤以降は自信を持ってタスクに取り組むことができ、終盤には他のエンジニアのタスクを巻き取ることができるまでになりました。 プロジェクトの中では、プロンプトの改善タスクも任せてもらえました。内容としては意図しない回答を弾く改善でしたが、AWS Lambda を触るなど、必要があればクラウドサービスを触る機会もあると感じました。 ChatGPT による提案機能のイメージ さいごに プロジェクトを振り返って 新機能がリリースされて数ヶ月経ちましたが、定めている KPI を達成し、結果が現れていることがとても嬉しいです。一例として、顧客が新機能で求人を作成してから社内での審査を経て掲載に至るまでの日数が、従来の作成方法と比べて半分以下と大幅に削減されています。 チームとしては今回のプロジェクトの進め方について振り返りを行いました。PM 、デザイナー、エンジニアそれぞれが次のプロジェクトをより良く遂行する提案を出し合い、今回のプロジェクトの経験が無駄にならないようにしています。現在、私自身はエンジニア一人の新しいプロジェクトを任されていますが、この時の振り返りでの反省をタスク分解やスケジュール策定に役立てられています。 個人的には今回のプロジェクトを通して、フロントエンドの技術習得はもちろんのこと、プロジェクトメンバーとのコミュニケーションで文章の構造化や画像に編集を加えるなどの工夫を加えることでコミュニケーションコストを下げることができるといった技術以外のことも学ぶことができました。 またプロジェクトを通して、若手のエンジニアが成長できる環境だと肌で感じました。配属後まもなくプロジェクトに参画させてもらえることや必要に応じて様々な技術を触らせてもらえることはもちろんのことですが、分からないことを聞きやすくしてくれる雰囲気や手を上げたら挑戦させてもらえる環境は贅沢に感じるほどです。 このような成長できる環境で若手時代を過ごしたい新卒エンジニアの方や、技術はあくまで手段であり、顧客への価値提供を目的にしているチームで働きたいエンジニアの方を絶賛募集していますので、ご興味がある方はぜひカジュアルにお話から始めてみませんか。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 自己紹介 はじめまして。人材プラットフォーム本部プロダクト開発室第一開発グループの田中です。 私は、2023 年の 4 月に新卒エンジニアとして入社し、日本最大級の医療介護求人サイト「 ジョブメドレー 」のフロントエンドとバックエンドの開発を担当しています。 学生時代は情報系ではなく、経済学を専攻していました。プログラミングには大学の授業で出会い、主にデータ分析に用いる R や Python を触っていました。そのため Web アプリケーションの開発は行っていませんでした。 エンジニアという職業に興味を持ったきっかけは、大学院時代に参加したインターンでした。インターン先の会社ではエンジニアが誰もいなかったのですが、開発未経験の私に機械学習を使ったアプリの PoC を作れという、かなり破天荒な経験をしたためです。今ではとてもレアな経験だったと思いますが、試行錯誤しながら何かを作ることに興奮を覚えたのを今でも鮮明に覚えています。 メドレー に入社した理由は、大きな社会課題に取り組んでいる、触れられる技術がフロントエンド・バックエンドのように領域に限られていないなどありましたが、一番大きな理由は「 技術はあくまで手段であり、顧客への価値提供を目的にしている 」という考えに共感したことです。入社してまだ日は浅いですが、この考えは随所で感じられます。 大学近くのビーチの夕焼け 入社から初プロジェクトまで さて、今回の記事では新卒エンジニアの私が初めて携わったプロジェクトの紹介を通して、メドレーでは新卒エンジニアが入社後にどのような働き方をしてるか伝えることができればと思います。 入社してから研修を終えて、配属後 1 ヶ月半くらいは主にプロダクトの定常改善系のタスクに取り組みながら、仕事のリズムを覚えていきました。 その後、今回紹介するプロジェクトに初めてアサインされました。この時点でプロジェクトで主に使用するスキルセットのフロントエンドは、新卒研修で学んだ程度でした。そのような状態の新卒でも、経験をたくさん積ませてもらえる良い環境だということもお伝えできればと思っています。 プロジェクトで解決する課題と解決策 まず、今回担当したプロジェクトが発足した背景となる課題と、その課題を解決するために提供した新機能について紹介します。このプロジェクトについては、 ニュースリリース も公開していますので、合わせてご覧ください。 ユーザーの抱える課題 これまで「ジョブメドレー」では顧客が求人を作成する際に、フォーム形式で募集要項を記入する形式となっていました。記入の自由度が高いことから、法令やガイドライン等で定められた項目を漏れなく記載することや、事業所の魅力を効果的に伝える工夫が必要であり、顧客にとっては大きな負担になっていました。 フォーム形式の求人作成機能のイメージ 社内オペレーションの観点で見ると、求人が掲載基準を満たしているのか、入力された文章から読み取り確認する業務に時間がかかっていました。 そこで、顧客と社内オペレーションの双方が感じている課題を解決するプロジェクトが発足し、私も参画しました。 ユーザー目線の解決策 顧客と社内オペレーションの双方の課題を解決するため、求人作成プロセスをより直感的かつ効率的に改善しました。具体的には、従来のフォーム入力方式から、対話式の質問と回答を通じて求人を作成できる機能を導入しました。この改善により、顧客は簡単に、迷うことなく掲載基準に沿った求人を作成しやすくなりました。 さらに、文章作成の労力を軽減するために、 ChatGPT を活用した提案機能も導入しました。この機能を通じて、顧客は入力した内容に基づき、求職者の目に止まりやすい求人タイトルや訴求文を ChatGPT から提案してもらえます。これにより、求人原稿作成にかかる手間や煩雑さが軽減され、専任の採用担当がいない事業所でも採用活動を効率的に進めることができ、迅速な人材の確保へとつながります。社内オペレーションの観点でも、掲載基準を満たしているかを確認する業務の時間短縮が期待できます。 質問形式の求人作成補助機能のイメージ ChatGPT の導入有無に関しては社内でも協議され、文章生成に ChatGPT を用いることで顧客の作業コストを下げられるのであれば導入しようという意思決定がありました。流行っている技術だから導入するのではなく、 顧客への価値提供のために新しい技術を導入する 考えが現れた意思決定だと思います。 技術スタック 今回のプロジェクトでは次のような技術スタックで開発を行いました。フロントエンドは React を使用し状態管理ライブラリとして React Hooks を選択しました。従来の求人作成機能では Redux で状態管理を行っていましたが、プロダクト全体の方針として今後 React Hooks を使用していく方針であったことと、実装のスピードを早めるために React Hooks を採用しました。 ChatGPT を用いた部分に関しては、顧客からのリクエストを受けて発行したトークンを保存するために Amazon DynamoDB を使用しました。DynamoDB に保存したトークンのバリデーションと GPT へプロンプトを渡し、提案の受け取り・返却する部分は AWS Lambda function に任せていました。GPT 本体は Azure OpenAI Service を利用する構成でした。Azure OpenAI Service を採用した理由は、顧客情報や入力内容が学習に使用されることがなくプライバシー面でのリスクを回避できるためでした。 文章生成機能の構成イメージ プロジェクトへの関わり 今回のプロジェクトのメンバー構成はエンジニア 3 人、デザイナー 1 人、PM 1 人という構成でした。開発には約 3 ヶ月の期間を要しました。 プロジェクト初期 私自身のプロジェクトへの関わり方としては、プロジェクト初期段階からフロントエンドの実装タスクが中心でした。その中でスタイルの実装に関してはオーナーシップを持たせていただきました。今回のプロジェクトで作成する UI コンポーネントでは、似たようなものが複数あったため、できるだけ拡張性を持たせ使い回せるように意識して設計していました。仕事のサイクルとしては、デザイナーが作ったデザインを元に、細かい仕様を調整して実装し、デザインレビューをしてもらうサイクルを回していました。 ただ、React などをキャッチアップしながらの実装だったため、他のエンジニアより実装に時間がかかってしまっていました。適宜先輩エンジニアに質問しながら進めていましたが、いくつかのタスクは巻き取ってもらうことになるなど、悔しい気持ちを覚えたプロジェクト初期でした。 プロジェクト中盤以降 プロジェクト中盤あたりで一つエンジニアとしての仕事の向き合い方に変化がありました。プロジェクトのスケジュールがタイトだったのも相まって、プロジェクト初期ではとりあえず実装して早くタスクを終わらせることに注力していました。しかし、時間がかかっても良いから一つ一つ丁寧にコードを追って理解することに努めようと先輩エンジニアにアドバイスをいただきました。 そこから、理解に注力することで思考がクリアになり、結果的に実装スピードが上がっていきました。また、実装以外にも目を向ける余裕が生まれ、仕様について PM やデザイナーに提案することもできました。プロジェクト中盤以降は自信を持ってタスクに取り組むことができ、終盤には他のエンジニアのタスクを巻き取ることができるまでになりました。 プロジェクトの中では、プロンプトの改善タスクも任せてもらえました。内容としては意図しない回答を弾く改善でしたが、AWS Lambda を触るなど、必要があればクラウドサービスを触る機会もあると感じました。 ChatGPT による提案機能のイメージ さいごに プロジェクトを振り返って 新機能がリリースされて数ヶ月経ちましたが、定めている KPI を達成し、結果が現れていることがとても嬉しいです。一例として、顧客が新機能で求人を作成してから社内での審査を経て掲載に至るまでの日数が、従来の作成方法と比べて半分以下と大幅に削減されています。 チームとしては今回のプロジェクトの進め方について振り返りを行いました。PM 、デザイナー、エンジニアそれぞれが次のプロジェクトをより良く遂行する提案を出し合い、今回のプロジェクトの経験が無駄にならないようにしています。現在、私自身はエンジニア一人の新しいプロジェクトを任されていますが、この時の振り返りでの反省をタスク分解やスケジュール策定に役立てられています。 個人的には今回のプロジェクトを通して、フロントエンドの技術習得はもちろんのこと、プロジェクトメンバーとのコミュニケーションで文章の構造化や画像に編集を加えるなどの工夫を加えることでコミュニケーションコストを下げることができるといった技術以外のことも学ぶことができました。 またプロジェクトを通して、若手のエンジニアが成長できる環境だと肌で感じました。配属後まもなくプロジェクトに参画させてもらえることや必要に応じて様々な技術を触らせてもらえることはもちろんのことですが、分からないことを聞きやすくしてくれる雰囲気や手を上げたら挑戦させてもらえる環境は贅沢に感じるほどです。 このような成長できる環境で若手時代を過ごしたい新卒エンジニアの方や、技術はあくまで手段であり、顧客への価値提供を目的にしているチームで働きたいエンジニアの方を絶賛募集していますので、ご興味がある方はぜひカジュアルにお話から始めてみませんか。 https://www.medley.jp/jobs/

はじめに みなさん、こんにちは。エンジニアの古川です。 今回は CLINICS / Pharms 同時予約プロジェクト(以下、同時予約 Pj)というプロダクト横断で様々な部署が関わった開発プロジェクトについて、尽力された皆さんに座談会形式でお話を伺いました。 メドレーの医療プラットフォーム(以下、医療 PF)でどのようにこうした横断プロジェクトを完遂したのかの様子を皆さんに知ってもらえればと思います。 対談メンバー紹介 ── はじめに、皆さんの自己紹介をお願いします。 江藤 : 所属は医療 PF のプロダクト開発室の Pharms 開発チームです。 役割としては調剤薬局向けのシステムの Pharms のプロダクトオーナーを担っています。 経歴としては、2021 年の 1 月から Pharms のカスタマーサクセスとしてメドレーにジョインしまして、2023 年 1 月から開発チームに来ました。 これまでは事業側の経験が長く、営業全般や事業開発をメインでやってきたキャリアです。 このプロジェクトの PO としてリードする動きをしており、Pharms が担う調剤側のリードに加えて、全体の旗振りや調整等を主軸にやっていました。 江藤さん ── 江藤さんがプロジェクトの中心となって推進したんですね。 江藤 : 調剤ドメインの Pharms にとって事業インパクトがすごく大きい開発だったので、調剤ドメインが責任持ってやりましょう、という整理です。 小田 : 自分の所属も江藤さんと同じになります。 経歴は、2021 年 7 月にエンジニアとして入社し、これまでずっと Pharms の開発をやってます。 入社後はクライアント認証機能や法人担当者向けの本部機能などの機能開発を行ってきました。 昨年から Pharms のリードエンジニアとしてチーム全体を見つつ、Pharms の技術責任者として江藤さんと両輪で動くような形でプロジェクトの推進に関わっています。 小田さん 有馬 : 医療 PF プロダクト開発室、患者統合基盤チームに所属しています。患者統合基盤とは、CLINICS（患者アプリ）というアプリのバックエンドシステムであり、診療所や歯科医院、薬局向けのシステムとの連携基盤としても機能しているプロダクトになります。 経歴は、このメンバーの中では一番古く 2018 年 3 月に入社して、当初は CLINICS カルテの機能拡張の開発に参加し、PKI 基盤や CLINICS エージェントを始めとした他社システムとの連携基盤の開発を行っていました。2020 年くらいから患者統合基盤の立ち上げに参加して、現在に至ります。 有馬さん 酒井 : 入社は 2019 年 8 月なので、 5 年目となります。 デザイナーとして入社後 1 年間はジョブメドレーに在籍していました。その後オンライン診療が伸びてきた時期になり、CLINICS 側のデザイナーの人数が足りなくなったことがありまして、そこからは電子カルテを含めた CLINICS のデザイン全般を担当していました。去年から電子カルテ以外の業務領域の PdM として活動しています。軸足はデザイナーなのですがプロダクトのマネジメントみたいなこともし始めてます。 このプロジェクトにおいては、さっき江藤さんがおっしゃった通り、Pharms の価値向上が中心のプロジェクトなのでプロジェクトの一番大きいリードは江藤さんになるかと思うんですけど、CLINICS などの医科側のプロジェクトリードと言う立ち位置が僕になるかなと思います。 酒井さん 小島 : 医療 PF プロダクト開発室の QA グループに所属しています。QA グループのマネージャである 米山 さんのご紹介で 2022 年 4 月にメドレー３人目の QA エンジニアとして入社しました。主担当は CLINICS の予約機能を中心とした周辺領域です。ここまで酒井さんと一緒に働かせて頂く機会が多く、直近では予約方法を拡張する「リクエスト予約」機能の QA を担当しました。 同時予約に関しては、主に医科側の部分の QA から始まり、調剤側の QA も必要ということになり、最終的には全体の QA を担当しました。 小島さん 同時予約の機能や解決した課題 ── ありがとうございます。次に、今回の同時予約についてどういった機能で、どういった課題を解決するべきかをお話しいただきたいです。 江藤 : 機能としては、 CLINICS（患者アプリ）からオンライン診療を予約する際に、薬の受け取り先として薬局を事前指定できる機能 になっています。 この機能に関係するドメインは患者・医療機関・調剤薬局の３つです。 患者と医療機関のメリットとしては、薬の処方までの手間が減ることです。 オンライン診療では、患者が医療機関に直接訪問するわけではないので、薬を直接薬局に行って受け取るのか、薬局から配送を希望するのかといった薬の受け取り方を、医療機関と患者さんで口頭で話して決めてもらっており、確認に手間が発生していました。患者さんは口頭で話した内容に沿って、オンライン診療終了後に、薬局への予約を取っていました。 同時予約機能が実装されたことにより、診察の予約時にどの薬局でどういう受け取り方をしますという部分を患者さんが事前指定できるようになったので、 医療機関は事務的な話に時間をかけずに診察に集中でき、また患者さんから医師に口頭で追加説明しなくても希望通りに薬をもらえる、というフローに変更されたことが医療機関と患者のメリット だと思ってます。 同時予約機能のリリース前後でのフローの違い もう一つのドメインである調剤薬局については、前述のように診察の予約をする時に患者さんがメドレーのサービスである Pharms を使っている薬局から事前指定をできますので、 オンライン診療後に発行された処方箋の流入が増加します 。 調剤薬局の売り上げは処方箋の枚数 × 単価で大部分が決まりますので、この枚数を増やせるという観点では薬局にとってインパクトのある機能だと思っています。 ── 患者の体験も本当に良くなるし、患者と医療機関の無駄なコミュニケーションも減り、かつ薬局に対しても処方箋枚数が増えて、導線も楽に使えるようになっているというのが、今回のプロジェクトの肝になっている感じですね。これらを踏まえ、プロダクト間を横断して開発しないといけないというのが大変そうです。 開発プロジェクトについて ── どのようなチームがこの横断プロジェクトに関わっていたかを教えてください。 江藤 : 開発側で言うと４つのドメインになってます。 調剤、患者、医科、そして 患者統合基盤 です。患者統合基盤とは医療 PF の各ドメインに存在する業務システムと患者アプリを繋ぐ根幹となるプロダクトです。 ただ今回の機能は医療機関のオペレーションも変わるため、開発側でのみ完結するプロジェクトではないんですね。 いかに現場の運用に合わせつつ、体験を改善できるか？という視点で考えると、各事業側のカスタマーサクセスチームが重要になります 。特に医科と調剤のカスタマーサクセスチームとは、密に壁打ちをしながら開発を進めていました。 ── 今回のプロジェクトは特に事業部との関係性が重要な鍵だったんですね。 江藤 : そうですね。特に医療現場は業務が逼迫している場面も多いですので、例えば「ワンクリック増えます」「ここでページ遷移が増えます」といったことでも業務への影響が非常に大きくなります。 またオペレーショナルに現場を回している箇所も多く、プロダクト都合で勝手にこの方が良いよね、合理的だよね、と決めてプロダクトを作ってしまうと今までの現場オペレーションが崩れてしまい混乱を招くことがあります。 現場の習慣を理解し、我々が目指す姿と調整しながら最適解を出す のが、必須になってくる業界・業態だと思うので、その調整は事業部ともかなり気を遣ってやっていました。 ── 同時予約 Pj は、開発側がやろうということで始まったプロジェクトなんでしょうか? 江藤 : はい。これはメドレーのどのプロダクトもそうなのですが、事業責任者とプロダクト責任者がそれぞれおり、事業と開発の両観点から議論し、事業方針を決めていく、という体制をとっています。 Pharms を正しく成長させていくという観点で見ると、現フェーズでは処方箋をしっかりと調剤薬局に届けることが至上命題でした。サービスのあるべき姿とは？という観点で事業と開発両輪でやりましょうという形で決まったものになります。 横断プロジェクトで工夫をしたポイント ── 今回、横断で色々な開発プロダクトが関係してきますが、工夫した点とか気をつけた点など、どんなものがありましたか。 江藤 : 一番は各ドメインで追っている事業成果がかなり違っていましたので、その調整を時間をかけて擦り合わせした点です。 例えば、調剤の観点では処方箋をちゃんと薬局に届けるというのが、すごく重要な事業インパクトの大きい項目である一方で、医療の観点で見た時に、もちろん手間を減らすのはすごい重要ではあるんですが、医療ドメインとしてその改善に調剤と同規模のメリットを見出してもらえるかと言うと当然そうではなかったりします。 こうした部分で、ドメイン間でこのプロジェクトを達成した後に得られるメリットに差分が出てきます。メリットが大きい事業からしたら工数も大きく割けるのですが、メリットが弱い事業では同じだけ工数かけてやりましょう、という意思決定は難しいと思います。 そこで 本 Pj を通じて各ドメインではどういう事業成果を生むのか、そのために何の KPI を追うのか、を明確にしました 。事業的なメリットが多い調剤のために手伝ってくださいという形ではなく、各ドメインでどういうメリットを生んでいきますか？というところを揃えきるのが、すごく重要だったと思っています。 これを怠ると、メリットの弱い事業にとってはお手伝いみたいなプロジェクトになります。単純にエンジニアリングという部分でも面白いものにならないですよね。ですので、関係する全員でプロジェクトを実施することでどういう結果を得るのか?をちゃんと各ドメイン間で揃えました。 ── なるほど。そうするとそうした擦り合わせは江藤さんと酒井さんがやっていたんでしょうか。 酒井 : はい、僕のほうで行っていました。僕が初期のすり合わせ時に重視していたのは、スコープを適切に区切るという部分でした。調剤側の提供価値の最大化だけを追って初期から大きな機能追加を行うのではなく、変更による医科・患者・調剤へ与えるリスクや開発コストを抑えつつ、価値を最大化できる落とし所はどこか、という部分から刷り合わせしていきました。 メドレーが面白いなって思うのが、プロダクト単独で動いていくわけではなくて、 ペイシェントジャーニー(患者体験)を中心としてプロタクト群が存在しているところ です。 患者体験をより良く構築するためにそれぞれのプロダクトが動いていけるので、お手伝いというニュアンスじゃなく、プロダクトを超えてここはよくしていきましょうと言える文化があるところがいい部分かなと思いますし、やりがいがある部分かなと思います。 江藤 : 特に横断のプロジェクトだとこうした目的意識の統一に一番時間を使っても良いんじゃないかと考えています。ここが決まりさえすれば、後々迷った場合も目的に即した意思決定ができますし。ここを固めた後に各ドメインでの調整するという順番が大事だと思います。 ── 技術面で気をつけたポイントはどんなものがあったんでしょうか。 有馬 : 同時予約機能としてやりたいことはありつつ、診療所側の業務フローや患者の導線、今あるシステムの制約などを踏まえ、どのような形に落とし込めば 診療所も薬局も患者にとっても価値のある機能となるか がポイントです。 ですので、技術的な面と事業的な面を併せて考えながら、システム全体の要件を決めていくというのが最初に手がけた部分でした。 ── 機能を考える上で、全体を見据えた設計などをやっていくと思うんですが、今回はどこから着手されたんでしょうか?患者の導線だったり医療機関の業務フローなど把握した後に、取りかかった部分を聞きたいのですが。 有馬 : 同時予約におけるシステム全体の要件を固めていくと同時に、全体のシーケンスとステートマシンを作っていきました。各システム間の連携フローと、それにより生み出される予約や処方箋といったエンティティの状態遷移を決めていき、この状態の時はこういったことはできないとか、そういった辻褄を合わせるところをしっかりやっていったという感じですかね。 酒井 : 今回は、特に プロダクト横断の共通基盤として、各プロダクトでそれぞれ全く別物の仕組みやステータスを保有しているのを、共通化・抽象化するという業務が必要になる ので、すごく難しいし、難易度が高い部分だなと思っているんですけど、それを綺麗にシーケンス図に落とし込んだ有馬さんが凄いなと思いました。 江藤 : 基盤側で作っていただいたシーケンス図は UX の骨組みなんですよね。そこをいわゆる UX デザイナーが別途やるといった細分化をせず、実装の制限を加味しつつ、正しく運用を回すために、この体験を作るためにこのステータス遷移であるべきだよね、という部分を有馬さんがエンジニア観点で最初に作ってくれてるというのが、 メドレーのエンジニアのとても良い部分 だと思っています。技術だけでなく UX などにも必要であれば越境していける文化ですね。 同時予約 Pj 開発の実際 ── そうした初期フェーズを経て Pharms と CLINICS どちらの開発にも関わった小田さんに聞きたいのが、開発の流れの中でいわゆるリソース的な問題って大変だったと思うのですが、そこはどう解決したんでしょうか。 小田 : 先に Pharms 側の機能 を作ってその後に CLINICS の仕様を決めてもらってから CLINICS の開発に入る流れだったので開発が並行することはなかったです。ただ Pharms ではリードエンジニアという立場なので 、CLINICS の開発に入るための準備と、Pharms 側のレビューやフォローのリソース配分は自分で考えて、各タスクを実施する時間とタイミングを調整しながらやっていました。 一方で、この体制でも進めることができたのは Pharms チームの各メンバーが既に自走できる状態にあったので、そこに支えられたからこそできた かなと思ってます。 ── プロダクトも越境しながら開発するという文化はすごく良いと思ったのですが、ここはフローなどあったりしたんですか? 江藤 : 先程も話した通り Pharms として本プロジェクトの優先度は高かったのですが、CLINICS の事業計画やリソースを踏まえると医科側の実装着手が大きく遅れそうな見立てでした。そこで、小田さんを 医科側の開発にもアサインできたらリソース問題が解決できるのではと調整しました。医科側のエンジニアからのフォローアップは必要なので、その調整もしつつですが、開発を早められるなら良し、と開発チーム間で最終的に判断しました。 酒井 : 今まで触ってなかった CLINICS のシステムにも小田さんはガンガン切り込んでくださったので、元々 CLINICS の開発をやってたのではと思うくらいキャッチアップが早かったです。 ── プロダクトのグロースのためにリソース調整を成功させたという形だったんですね。プロダクト間の越境がしやすいような文化だったり、プロジェクトを成功させようという目線合わせが自然にできるのは良いですね。 チーム間という話でいえば QA は各チームに跨っての活動だと思いますが、その観点ではいかがですか? 小島 : 自分は開発が終盤に入ったタイミングでプロジェクトに合流しました。それまでは米山さんが QA として入っていたのですが、医科側でも検証すべきテスト観点が多数あった背景もあり、医科側の QA をメインで見る担当として参画しました。 後半に参画した背景もあり、そもそも処方箋送付という業務や Pharms プロダクトの仕様理解も浅い…という状態でしたが、 開発目的・要件定義・設計が詳細にドキュメント化されていたので、スムーズに検証に入ることができました 。検証の中で QA エンジニアとしても「この部分の仕様は見直した方が良くなる」というポイントがいくつか出てきたので、仕様の改善提案も行いました。後発参加でしたが、実際に取り入れてもらった改善も多いです。 メドレーのプロダクト開発の文化として QA エンジニアも 要件定義からレビューに参加したり、意見を言いつつプロダクトをより良くするための改善が行える ので、とても働きやすいですね。 ── 後から入っても動きやすいというのは、ドキュメントなどが整備されているからできたことだというのが分かりますね。横断プロジェクトだからこそ気がついた他のチームの良い点などあったりしますか? 酒井 : Pharms のプロジェクトってやりやすいな、と思ったのが KPI 設計がすごく明確なところだったという点でした。 色々紆余曲折あった結果ここに辿り着いてるという苦労を知ってはいるんですけど、今の KPI 設計ってやっぱりすごくシンプル で処方箋送信数ですとなると、そこから逆算した KPI を各 PF に振ればいいと言う体制だったので、すごくこれはやりやすかったポイントの一つかなと思います。 話す論点も結局そこっていう部分がすごくコミュニケーションコストが安くすんだ部分ではあるかなと思いました。 横断プロジェクトならではのエンジニアリング ── 全体の話から個別のドメインごとのエンジニアリングという点ではどのようなことをされていましたか? 小田 : 基本的には有馬さんのシーケンス図を元に開発を進めていました。CLINICS では A という状態になる、その時に B というアクションがあると Pharms では C という状態になるというように状態遷移が複雑だったため、設計時にあるべき姿に迷うことが多かったのですが、シーケンスに立ち返るとすぐにその疑問が解決するといった具合です。 有馬 : シーケンスの整合性や難しくなりすぎないように設計する ことには気をつけました。「同時予約」という言葉が先行するとついつい複雑な新機能のようなものを作りがちですが、診療所や薬局の予約機能、処方箋送信機能といった個々のパーツはもともとあるわけで、なるべくシンプルにそれらをつなぎ合わせられるように心がけました。 江藤 : 細かいプロダクト間の調整が必要になるので ちゃんと調剤の欲しい KPI も求めつつ、かつ現場のオペレーション品質を落とさないっていう観点で調整を各ドメインでやりました。 工夫したことでいうと、UX 調査を徹底したところでしょうか。 今回のサービスって業界的にみた時に新しいかというとそうではないんですよね。ですので、同業界の企業さんの各アプリの体験とか、自分でも結構色々使いながら体験してみましたし、それらをベースに逆に現状のうちの仕様を踏まえると、こういう風にうちでは実装しましょうみたいなところを色々やっていました。 小田 : エンジニアリングの観点でいうと、特に患者アプリチームとの API 連携の仕様調整と、開発の進め方は密に連携しながら進めました。先にこっちができてないと向こうも開発できない状態になるので、担当者同士でコミュニケーションとりつつ、工夫しながら進めていました。 酒井 : CLINICS で気にしてた部分はどちらかというと リスクとコストの部分、いかに最小化して価値を最大化するかが一番重要 かなと思っていたので、一番大事なのはやっぱり医科にとってどういう価値が出て、医科にとってどういうリスクが発生するかを考えてました。 例えば一番最初のすり合わせで薬局予約する時に日時まで確定させましょうという話もあったんですけど、そこまでスコープを広げなくてもメリットが出るのであれば、広げたくないですという話をしていました。 あとはリリースプランの策定とかかな？全医療機関に一斉に出すのではなく、まずは一部医療機関様だけに公開するリリース方式にしましょうみたいなところも含めてですかね。医科側で一旦テストをやって検証して、スムーズに機能が使えるところを確認したりするステップを設けましょうと安全策を取りながら進めました。 これはこのプロジェクトに関わらず、どんなプロジェクトでも一番重要でそこが後からひっくり返るのが一番手戻りになってくるので、そこは重要かなと思いながら進めてましたね。 小島 : QA 視点だと横断プロジェクトゆえにステートが本当に複雑で、メドレー入社後に経験したプロジェクトの中で検証の難易度が最も高かったですね。 ですが、皆さん仰られているように各ユースケースに対する設計が図でドキュメント化されていたので、テストケースとして転用できた部分も多くありました。有馬さんが作成した設計図があったからこそ漏れなくテストできた部分は大きいです。大勢が参加するプロジェクトにおいて、全員が認識合わせる上でも設計図は本当に大事だなと痛感しました。 工夫した点としては、小田さんは Pharms 開発のドメイン知識が豊富だったので、QA 時は Pharms 側をメインに見てもらいつつ、自分は CLINICS 側の QA を手厚く見るようにしました。どちらのドメインにも関係する契約プラン等の複雑な仕様は自分が担当しました。 QA 以外の面だと、リリースする上で必要な浮いたボールがあれば積極的に取りにいくようにしました。 例えば、これまで一部の医療機関様だけに機能リリースする場合、その後のフィードバック回収はメールや面談で個別に行っていましたが、日々の診療の中でお時間を確保頂くのが難しいという状況がありました。その結果、本 Pj においても全体リリースして問題ないか？の判断がしづらい時期がありました。 そこで Google フォームでアンケートを作成して短時間で回答できる形に切り替えました。結果的に 100% 回答を得ることができました。 アンケート結果から「従来機能より価値があり、院内オペレーションに組み込んで頂くコストもそこまで高くない」という点が評価できたので、自信を持って全体公開リリースに向けて GO 判定できました。** メドレーは役割に縛られずボールを任せて頂ける環境があるので、自分の専門領域以外のことも学べている**と思うことが多いです。 幸いリリース後も大きな不具合はないのでこれはもう皆さんのおかげですね。 同時予約 Pj を終えて ── では最後にこのプロジェクトの総括をしていだければ。 江藤 : 横断ではあるけど各ドメインでそれぞれのプロフェッショナルがちゃんと力を発揮してプロジェクトをやり切れたというのはすごく大きい資産でした。 医療 PF はアセットをたくさん持っているので、色々組み合わせると、他の会社だとできないけど、うちならできそうだね、みたいなことが色々ある んです。 なので、この後も横断プロジェクトは予定されていますが、それに先駆けてひとつやりきって、かつ僕らが欲しかった期待成果を現状出せているところを含めるとすごく良い一歩だったのかな、と思ってます。 次は品質を担保しつつ、もっとスピードを上げていきたいというのが観点として大きいですね。 ── なるほど。こうした横断プロジェクトもやっていく医療 PF ではどんなエンジニアがマッチするポイントでしょう? 有馬 : 技術と併せてユーザーへの価値提供も考えながらエンジニアリングしたい人がマッチするのではないかと思います。 ── 各プロダクトの持っている役割を踏まえて、俯瞰の視点で開発もしたいという方にはすごく魅力的ですね。本日はありがとうございました。 さいごに 同時予約 Pj について、プロジェクトを推進したメンバーに話を聞きましたが、複雑な要件を実現可能な形にして各チームで垣根を越えて開発をしている様子がとても印象的でした。特に医療 PF ではドメイン同士で有機的に結合していき、コラボレーションすることによりステークホルダーへの価値を高めているというのは、やりがいがあるのではないかと感じます。 このようなプロジェクトで力を発揮したいと思った方はぜひ、お気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの古川です。 今回は CLINICS / Pharms 同時予約プロジェクト(以下、同時予約 Pj)というプロダクト横断で様々な部署が関わった開発プロジェクトについて、尽力された皆さんに座談会形式でお話を伺いました。 メドレーの医療プラットフォーム(以下、医療 PF)でどのようにこうした横断プロジェクトを完遂したのかの様子を皆さんに知ってもらえればと思います。 対談メンバー紹介 ── はじめに、皆さんの自己紹介をお願いします。 江藤 : 所属は医療 PF のプロダクト開発室の Pharms 開発チームです。 役割としては調剤薬局向けのシステムの Pharms のプロダクトオーナーを担っています。 経歴としては、2021 年の 1 月から Pharms のカスタマーサクセスとしてメドレーにジョインしまして、2023 年 1 月から開発チームに来ました。 これまでは事業側の経験が長く、営業全般や事業開発をメインでやってきたキャリアです。 このプロジェクトの PO としてリードする動きをしており、Pharms が担う調剤側のリードに加えて、全体の旗振りや調整等を主軸にやっていました。 江藤さん ── 江藤さんがプロジェクトの中心となって推進したんですね。 江藤 : 調剤ドメインの Pharms にとって事業インパクトがすごく大きい開発だったので、調剤ドメインが責任持ってやりましょう、という整理です。 小田 : 自分の所属も江藤さんと同じになります。 経歴は、2021 年 7 月にエンジニアとして入社し、これまでずっと Pharms の開発をやってます。 入社後はクライアント認証機能や法人担当者向けの本部機能などの機能開発を行ってきました。 昨年から Pharms のリードエンジニアとしてチーム全体を見つつ、Pharms の技術責任者として江藤さんと両輪で動くような形でプロジェクトの推進に関わっています。 小田さん 有馬 : 医療 PF プロダクト開発室、患者統合基盤チームに所属しています。患者統合基盤とは、CLINICS（患者アプリ）というアプリのバックエンドシステムであり、診療所や歯科医院、薬局向けのシステムとの連携基盤としても機能しているプロダクトになります。 経歴は、このメンバーの中では一番古く 2018 年 3 月に入社して、当初は CLINICS カルテの機能拡張の開発に参加し、PKI 基盤や CLINICS エージェントを始めとした他社システムとの連携基盤の開発を行っていました。2020 年くらいから患者統合基盤の立ち上げに参加して、現在に至ります。 有馬さん 酒井 : 入社は 2019 年 8 月なので、 5 年目となります。 デザイナーとして入社後 1 年間はジョブメドレーに在籍していました。その後オンライン診療が伸びてきた時期になり、CLINICS 側のデザイナーの人数が足りなくなったことがありまして、そこからは電子カルテを含めた CLINICS のデザイン全般を担当していました。去年から電子カルテ以外の業務領域の PdM として活動しています。軸足はデザイナーなのですがプロダクトのマネジメントみたいなこともし始めてます。 このプロジェクトにおいては、さっき江藤さんがおっしゃった通り、Pharms の価値向上が中心のプロジェクトなのでプロジェクトの一番大きいリードは江藤さんになるかと思うんですけど、CLINICS などの医科側のプロジェクトリードと言う立ち位置が僕になるかなと思います。 酒井さん 小島 : 医療 PF プロダクト開発室の QA グループに所属しています。QA グループのマネージャである 米山 さんのご紹介で 2022 年 4 月にメドレー３人目の QA エンジニアとして入社しました。主担当は CLINICS の予約機能を中心とした周辺領域です。ここまで酒井さんと一緒に働かせて頂く機会が多く、直近では予約方法を拡張する「リクエスト予約」機能の QA を担当しました。 同時予約に関しては、主に医科側の部分の QA から始まり、調剤側の QA も必要ということになり、最終的には全体の QA を担当しました。 小島さん 同時予約の機能や解決した課題 ── ありがとうございます。次に、今回の同時予約についてどういった機能で、どういった課題を解決するべきかをお話しいただきたいです。 江藤 : 機能としては、 CLINICS（患者アプリ）からオンライン診療を予約する際に、薬の受け取り先として薬局を事前指定できる機能 になっています。 この機能に関係するドメインは患者・医療機関・調剤薬局の３つです。 患者と医療機関のメリットとしては、薬の処方までの手間が減ることです。 オンライン診療では、患者が医療機関に直接訪問するわけではないので、薬を直接薬局に行って受け取るのか、薬局から配送を希望するのかといった薬の受け取り方を、医療機関と患者さんで口頭で話して決めてもらっており、確認に手間が発生していました。患者さんは口頭で話した内容に沿って、オンライン診療終了後に、薬局への予約を取っていました。 同時予約機能が実装されたことにより、診察の予約時にどの薬局でどういう受け取り方をしますという部分を患者さんが事前指定できるようになったので、 医療機関は事務的な話に時間をかけずに診察に集中でき、また患者さんから医師に口頭で追加説明しなくても希望通りに薬をもらえる、というフローに変更されたことが医療機関と患者のメリット だと思ってます。 同時予約機能のリリース前後でのフローの違い もう一つのドメインである調剤薬局については、前述のように診察の予約をする時に患者さんがメドレーのサービスである Pharms を使っている薬局から事前指定をできますので、 オンライン診療後に発行された処方箋の流入が増加します 。 調剤薬局の売り上げは処方箋の枚数 × 単価で大部分が決まりますので、この枚数を増やせるという観点では薬局にとってインパクトのある機能だと思っています。 ── 患者の体験も本当に良くなるし、患者と医療機関の無駄なコミュニケーションも減り、かつ薬局に対しても処方箋枚数が増えて、導線も楽に使えるようになっているというのが、今回のプロジェクトの肝になっている感じですね。これらを踏まえ、プロダクト間を横断して開発しないといけないというのが大変そうです。 開発プロジェクトについて ── どのようなチームがこの横断プロジェクトに関わっていたかを教えてください。 江藤 : 開発側で言うと４つのドメインになってます。 調剤、患者、医科、そして 患者統合基盤 です。患者統合基盤とは医療 PF の各ドメインに存在する業務システムと患者アプリを繋ぐ根幹となるプロダクトです。 ただ今回の機能は医療機関のオペレーションも変わるため、開発側でのみ完結するプロジェクトではないんですね。 いかに現場の運用に合わせつつ、体験を改善できるか？という視点で考えると、各事業側のカスタマーサクセスチームが重要になります 。特に医科と調剤のカスタマーサクセスチームとは、密に壁打ちをしながら開発を進めていました。 ── 今回のプロジェクトは特に事業部との関係性が重要な鍵だったんですね。 江藤 : そうですね。特に医療現場は業務が逼迫している場面も多いですので、例えば「ワンクリック増えます」「ここでページ遷移が増えます」といったことでも業務への影響が非常に大きくなります。 またオペレーショナルに現場を回している箇所も多く、プロダクト都合で勝手にこの方が良いよね、合理的だよね、と決めてプロダクトを作ってしまうと今までの現場オペレーションが崩れてしまい混乱を招くことがあります。 現場の習慣を理解し、我々が目指す姿と調整しながら最適解を出す のが、必須になってくる業界・業態だと思うので、その調整は事業部ともかなり気を遣ってやっていました。 ── 同時予約 Pj は、開発側がやろうということで始まったプロジェクトなんでしょうか? 江藤 : はい。これはメドレーのどのプロダクトもそうなのですが、事業責任者とプロダクト責任者がそれぞれおり、事業と開発の両観点から議論し、事業方針を決めていく、という体制をとっています。 Pharms を正しく成長させていくという観点で見ると、現フェーズでは処方箋をしっかりと調剤薬局に届けることが至上命題でした。サービスのあるべき姿とは？という観点で事業と開発両輪でやりましょうという形で決まったものになります。 横断プロジェクトで工夫をしたポイント ── 今回、横断で色々な開発プロダクトが関係してきますが、工夫した点とか気をつけた点など、どんなものがありましたか。 江藤 : 一番は各ドメインで追っている事業成果がかなり違っていましたので、その調整を時間をかけて擦り合わせした点です。 例えば、調剤の観点では処方箋をちゃんと薬局に届けるというのが、すごく重要な事業インパクトの大きい項目である一方で、医療の観点で見た時に、もちろん手間を減らすのはすごい重要ではあるんですが、医療ドメインとしてその改善に調剤と同規模のメリットを見出してもらえるかと言うと当然そうではなかったりします。 こうした部分で、ドメイン間でこのプロジェクトを達成した後に得られるメリットに差分が出てきます。メリットが大きい事業からしたら工数も大きく割けるのですが、メリットが弱い事業では同じだけ工数かけてやりましょう、という意思決定は難しいと思います。 そこで 本 Pj を通じて各ドメインではどういう事業成果を生むのか、そのために何の KPI を追うのか、を明確にしました 。事業的なメリットが多い調剤のために手伝ってくださいという形ではなく、各ドメインでどういうメリットを生んでいきますか？というところを揃えきるのが、すごく重要だったと思っています。 これを怠ると、メリットの弱い事業にとってはお手伝いみたいなプロジェクトになります。単純にエンジニアリングという部分でも面白いものにならないですよね。ですので、関係する全員でプロジェクトを実施することでどういう結果を得るのか?をちゃんと各ドメイン間で揃えました。 ── なるほど。そうするとそうした擦り合わせは江藤さんと酒井さんがやっていたんでしょうか。 酒井 : はい、僕のほうで行っていました。僕が初期のすり合わせ時に重視していたのは、スコープを適切に区切るという部分でした。調剤側の提供価値の最大化だけを追って初期から大きな機能追加を行うのではなく、変更による医科・患者・調剤へ与えるリスクや開発コストを抑えつつ、価値を最大化できる落とし所はどこか、という部分から刷り合わせしていきました。 メドレーが面白いなって思うのが、プロダクト単独で動いていくわけではなくて、 ペイシェントジャーニー(患者体験)を中心としてプロタクト群が存在しているところ です。 患者体験をより良く構築するためにそれぞれのプロダクトが動いていけるので、お手伝いというニュアンスじゃなく、プロダクトを超えてここはよくしていきましょうと言える文化があるところがいい部分かなと思いますし、やりがいがある部分かなと思います。 江藤 : 特に横断のプロジェクトだとこうした目的意識の統一に一番時間を使っても良いんじゃないかと考えています。ここが決まりさえすれば、後々迷った場合も目的に即した意思決定ができますし。ここを固めた後に各ドメインでの調整するという順番が大事だと思います。 ── 技術面で気をつけたポイントはどんなものがあったんでしょうか。 有馬 : 同時予約機能としてやりたいことはありつつ、診療所側の業務フローや患者の導線、今あるシステムの制約などを踏まえ、どのような形に落とし込めば 診療所も薬局も患者にとっても価値のある機能となるか がポイントです。 ですので、技術的な面と事業的な面を併せて考えながら、システム全体の要件を決めていくというのが最初に手がけた部分でした。 ── 機能を考える上で、全体を見据えた設計などをやっていくと思うんですが、今回はどこから着手されたんでしょうか?患者の導線だったり医療機関の業務フローなど把握した後に、取りかかった部分を聞きたいのですが。 有馬 : 同時予約におけるシステム全体の要件を固めていくと同時に、全体のシーケンスとステートマシンを作っていきました。各システム間の連携フローと、それにより生み出される予約や処方箋といったエンティティの状態遷移を決めていき、この状態の時はこういったことはできないとか、そういった辻褄を合わせるところをしっかりやっていったという感じですかね。 酒井 : 今回は、特に プロダクト横断の共通基盤として、各プロダクトでそれぞれ全く別物の仕組みやステータスを保有しているのを、共通化・抽象化するという業務が必要になる ので、すごく難しいし、難易度が高い部分だなと思っているんですけど、それを綺麗にシーケンス図に落とし込んだ有馬さんが凄いなと思いました。 江藤 : 基盤側で作っていただいたシーケンス図は UX の骨組みなんですよね。そこをいわゆる UX デザイナーが別途やるといった細分化をせず、実装の制限を加味しつつ、正しく運用を回すために、この体験を作るためにこのステータス遷移であるべきだよね、という部分を有馬さんがエンジニア観点で最初に作ってくれてるというのが、 メドレーのエンジニアのとても良い部分 だと思っています。技術だけでなく UX などにも必要であれば越境していける文化ですね。 同時予約 Pj 開発の実際 ── そうした初期フェーズを経て Pharms と CLINICS どちらの開発にも関わった小田さんに聞きたいのが、開発の流れの中でいわゆるリソース的な問題って大変だったと思うのですが、そこはどう解決したんでしょうか。 小田 : 先に Pharms 側の機能 を作ってその後に CLINICS の仕様を決めてもらってから CLINICS の開発に入る流れだったので開発が並行することはなかったです。ただ Pharms ではリードエンジニアという立場なので 、CLINICS の開発に入るための準備と、Pharms 側のレビューやフォローのリソース配分は自分で考えて、各タスクを実施する時間とタイミングを調整しながらやっていました。 一方で、この体制でも進めることができたのは Pharms チームの各メンバーが既に自走できる状態にあったので、そこに支えられたからこそできた かなと思ってます。 ── プロダクトも越境しながら開発するという文化はすごく良いと思ったのですが、ここはフローなどあったりしたんですか? 江藤 : 先程も話した通り Pharms として本プロジェクトの優先度は高かったのですが、CLINICS の事業計画やリソースを踏まえると医科側の実装着手が大きく遅れそうな見立てでした。そこで、小田さんを 医科側の開発にもアサインできたらリソース問題が解決できるのではと調整しました。医科側のエンジニアからのフォローアップは必要なので、その調整もしつつですが、開発を早められるなら良し、と開発チーム間で最終的に判断しました。 酒井 : 今まで触ってなかった CLINICS のシステムにも小田さんはガンガン切り込んでくださったので、元々 CLINICS の開発をやってたのではと思うくらいキャッチアップが早かったです。 ── プロダクトのグロースのためにリソース調整を成功させたという形だったんですね。プロダクト間の越境がしやすいような文化だったり、プロジェクトを成功させようという目線合わせが自然にできるのは良いですね。 チーム間という話でいえば QA は各チームに跨っての活動だと思いますが、その観点ではいかがですか? 小島 : 自分は開発が終盤に入ったタイミングでプロジェクトに合流しました。それまでは米山さんが QA として入っていたのですが、医科側でも検証すべきテスト観点が多数あった背景もあり、医科側の QA をメインで見る担当として参画しました。 後半に参画した背景もあり、そもそも処方箋送付という業務や Pharms プロダクトの仕様理解も浅い…という状態でしたが、 開発目的・要件定義・設計が詳細にドキュメント化されていたので、スムーズに検証に入ることができました 。検証の中で QA エンジニアとしても「この部分の仕様は見直した方が良くなる」というポイントがいくつか出てきたので、仕様の改善提案も行いました。後発参加でしたが、実際に取り入れてもらった改善も多いです。 メドレーのプロダクト開発の文化として QA エンジニアも 要件定義からレビューに参加したり、意見を言いつつプロダクトをより良くするための改善が行える ので、とても働きやすいですね。 ── 後から入っても動きやすいというのは、ドキュメントなどが整備されているからできたことだというのが分かりますね。横断プロジェクトだからこそ気がついた他のチームの良い点などあったりしますか? 酒井 : Pharms のプロジェクトってやりやすいな、と思ったのが KPI 設計がすごく明確なところだったという点でした。 色々紆余曲折あった結果ここに辿り着いてるという苦労を知ってはいるんですけど、今の KPI 設計ってやっぱりすごくシンプル で処方箋送信数ですとなると、そこから逆算した KPI を各 PF に振ればいいと言う体制だったので、すごくこれはやりやすかったポイントの一つかなと思います。 話す論点も結局そこっていう部分がすごくコミュニケーションコストが安くすんだ部分ではあるかなと思いました。 横断プロジェクトならではのエンジニアリング ── 全体の話から個別のドメインごとのエンジニアリングという点ではどのようなことをされていましたか? 小田 : 基本的には有馬さんのシーケンス図を元に開発を進めていました。CLINICS では A という状態になる、その時に B というアクションがあると Pharms では C という状態になるというように状態遷移が複雑だったため、設計時にあるべき姿に迷うことが多かったのですが、シーケンスに立ち返るとすぐにその疑問が解決するといった具合です。 有馬 : シーケンスの整合性や難しくなりすぎないように設計する ことには気をつけました。「同時予約」という言葉が先行するとついつい複雑な新機能のようなものを作りがちですが、診療所や薬局の予約機能、処方箋送信機能といった個々のパーツはもともとあるわけで、なるべくシンプルにそれらをつなぎ合わせられるように心がけました。 江藤 : 細かいプロダクト間の調整が必要になるので ちゃんと調剤の欲しい KPI も求めつつ、かつ現場のオペレーション品質を落とさないっていう観点で調整を各ドメインでやりました。 工夫したことでいうと、UX 調査を徹底したところでしょうか。 今回のサービスって業界的にみた時に新しいかというとそうではないんですよね。ですので、同業界の企業さんの各アプリの体験とか、自分でも結構色々使いながら体験してみましたし、それらをベースに逆に現状のうちの仕様を踏まえると、こういう風にうちでは実装しましょうみたいなところを色々やっていました。 小田 : エンジニアリングの観点でいうと、特に患者アプリチームとの API 連携の仕様調整と、開発の進め方は密に連携しながら進めました。先にこっちができてないと向こうも開発できない状態になるので、担当者同士でコミュニケーションとりつつ、工夫しながら進めていました。 酒井 : CLINICS で気にしてた部分はどちらかというと リスクとコストの部分、いかに最小化して価値を最大化するかが一番重要 かなと思っていたので、一番大事なのはやっぱり医科にとってどういう価値が出て、医科にとってどういうリスクが発生するかを考えてました。 例えば一番最初のすり合わせで薬局予約する時に日時まで確定させましょうという話もあったんですけど、そこまでスコープを広げなくてもメリットが出るのであれば、広げたくないですという話をしていました。 あとはリリースプランの策定とかかな？全医療機関に一斉に出すのではなく、まずは一部医療機関様だけに公開するリリース方式にしましょうみたいなところも含めてですかね。医科側で一旦テストをやって検証して、スムーズに機能が使えるところを確認したりするステップを設けましょうと安全策を取りながら進めました。 これはこのプロジェクトに関わらず、どんなプロジェクトでも一番重要でそこが後からひっくり返るのが一番手戻りになってくるので、そこは重要かなと思いながら進めてましたね。 小島 : QA 視点だと横断プロジェクトゆえにステートが本当に複雑で、メドレー入社後に経験したプロジェクトの中で検証の難易度が最も高かったですね。 ですが、皆さん仰られているように各ユースケースに対する設計が図でドキュメント化されていたので、テストケースとして転用できた部分も多くありました。有馬さんが作成した設計図があったからこそ漏れなくテストできた部分は大きいです。大勢が参加するプロジェクトにおいて、全員が認識合わせる上でも設計図は本当に大事だなと痛感しました。 工夫した点としては、小田さんは Pharms 開発のドメイン知識が豊富だったので、QA 時は Pharms 側をメインに見てもらいつつ、自分は CLINICS 側の QA を手厚く見るようにしました。どちらのドメインにも関係する契約プラン等の複雑な仕様は自分が担当しました。 QA 以外の面だと、リリースする上で必要な浮いたボールがあれば積極的に取りにいくようにしました。 例えば、これまで一部の医療機関様だけに機能リリースする場合、その後のフィードバック回収はメールや面談で個別に行っていましたが、日々の診療の中でお時間を確保頂くのが難しいという状況がありました。その結果、本 Pj においても全体リリースして問題ないか？の判断がしづらい時期がありました。 そこで Google フォームでアンケートを作成して短時間で回答できる形に切り替えました。結果的に 100% 回答を得ることができました。 アンケート結果から「従来機能より価値があり、院内オペレーションに組み込んで頂くコストもそこまで高くない」という点が評価できたので、自信を持って全体公開リリースに向けて GO 判定できました。** メドレーは役割に縛られずボールを任せて頂ける環境があるので、自分の専門領域以外のことも学べている**と思うことが多いです。 幸いリリース後も大きな不具合はないのでこれはもう皆さんのおかげですね。 同時予約 Pj を終えて ── では最後にこのプロジェクトの総括をしていだければ。 江藤 : 横断ではあるけど各ドメインでそれぞれのプロフェッショナルがちゃんと力を発揮してプロジェクトをやり切れたというのはすごく大きい資産でした。 医療 PF はアセットをたくさん持っているので、色々組み合わせると、他の会社だとできないけど、うちならできそうだね、みたいなことが色々ある んです。 なので、この後も横断プロジェクトは予定されていますが、それに先駆けてひとつやりきって、かつ僕らが欲しかった期待成果を現状出せているところを含めるとすごく良い一歩だったのかな、と思ってます。 次は品質を担保しつつ、もっとスピードを上げていきたいというのが観点として大きいですね。 ── なるほど。こうした横断プロジェクトもやっていく医療 PF ではどんなエンジニアがマッチするポイントでしょう? 有馬 : 技術と併せてユーザーへの価値提供も考えながらエンジニアリングしたい人がマッチするのではないかと思います。 ── 各プロダクトの持っている役割を踏まえて、俯瞰の視点で開発もしたいという方にはすごく魅力的ですね。本日はありがとうございました。 さいごに 同時予約 Pj について、プロジェクトを推進したメンバーに話を聞きましたが、複雑な要件を実現可能な形にして各チームで垣根を越えて開発をしている様子がとても印象的でした。特に医療 PF ではドメイン同士で有機的に結合していき、コラボレーションすることによりステークホルダーへの価値を高めているというのは、やりがいがあるのではないかと感じます。 このようなプロジェクトで力を発揮したいと思った方はぜひ、お気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの古川です。 今回は CLINICS / Pharms 同時予約プロジェクト(以下、同時予約 Pj)というプロダクト横断で様々な部署が関わった開発プロジェクトについて、尽力された皆さんに座談会形式でお話を伺いました。 メドレーの医療プラットフォーム(以下、医療 PF)でどのようにこうした横断プロジェクトを完遂したのかの様子を皆さんに知ってもらえればと思います。 対談メンバー紹介 ── はじめに、皆さんの自己紹介をお願いします。 江藤 : 所属は医療 PF のプロダクト開発室の Pharms 開発チームです。 役割としては調剤薬局向けのシステムの Pharms のプロダクトオーナーを担っています。 経歴としては、2021 年の 1 月から Pharms のカスタマーサクセスとしてメドレーにジョインしまして、2023 年 1 月から開発チームに来ました。 これまでは事業側の経験が長く、営業全般や事業開発をメインでやってきたキャリアです。 このプロジェクトの PO としてリードする動きをしており、Pharms が担う調剤側のリードに加えて、全体の旗振りや調整等を主軸にやっていました。 江藤さん ── 江藤さんがプロジェクトの中心となって推進したんですね。 江藤 : 調剤ドメインの Pharms にとって事業インパクトがすごく大きい開発だったので、調剤ドメインが責任持ってやりましょう、という整理です。 小田 : 自分の所属も江藤さんと同じになります。 経歴は、2021 年 7 月にエンジニアとして入社し、これまでずっと Pharms の開発をやってます。 入社後はクライアント認証機能や法人担当者向けの本部機能などの機能開発を行ってきました。 昨年から Pharms のリードエンジニアとしてチーム全体を見つつ、Pharms の技術責任者として江藤さんと両輪で動くような形でプロジェクトの推進に関わっています。 小田さん 有馬 : 医療 PF プロダクト開発室、患者統合基盤チームに所属しています。患者統合基盤とは、CLINICS（患者アプリ）というアプリのバックエンドシステムであり、診療所や歯科医院、薬局向けのシステムとの連携基盤としても機能しているプロダクトになります。 経歴は、このメンバーの中では一番古く 2018 年 3 月に入社して、当初は CLINICS カルテの機能拡張の開発に参加し、PKI 基盤や CLINICS エージェントを始めとした他社システムとの連携基盤の開発を行っていました。2020 年くらいから患者統合基盤の立ち上げに参加して、現在に至ります。 有馬さん 酒井 : 入社は 2019 年 8 月なので、 5 年目となります。 デザイナーとして入社後 1 年間はジョブメドレーに在籍していました。その後オンライン診療が伸びてきた時期になり、CLINICS 側のデザイナーの人数が足りなくなったことがありまして、そこからは電子カルテを含めた CLINICS のデザイン全般を担当していました。去年から電子カルテ以外の業務領域の PdM として活動しています。軸足はデザイナーなのですがプロダクトのマネジメントみたいなこともし始めてます。 このプロジェクトにおいては、さっき江藤さんがおっしゃった通り、Pharms の価値向上が中心のプロジェクトなのでプロジェクトの一番大きいリードは江藤さんになるかと思うんですけど、CLINICS などの医科側のプロジェクトリードと言う立ち位置が僕になるかなと思います。 酒井さん 小島 : 医療 PF プロダクト開発室の QA グループに所属しています。QA グループのマネージャである 米山 さんのご紹介で 2022 年 4 月にメドレー３人目の QA エンジニアとして入社しました。主担当は CLINICS の予約機能を中心とした周辺領域です。ここまで酒井さんと一緒に働かせて頂く機会が多く、直近では予約方法を拡張する「リクエスト予約」機能の QA を担当しました。 同時予約に関しては、主に医科側の部分の QA から始まり、調剤側の QA も必要ということになり、最終的には全体の QA を担当しました。 小島さん 同時予約の機能や解決した課題 ── ありがとうございます。次に、今回の同時予約についてどういった機能で、どういった課題を解決するべきかをお話しいただきたいです。 江藤 : 機能としては、 CLINICS（患者アプリ）からオンライン診療を予約する際に、薬の受け取り先として薬局を事前指定できる機能 になっています。 この機能に関係するドメインは患者・医療機関・調剤薬局の３つです。 患者と医療機関のメリットとしては、薬の処方までの手間が減ることです。 オンライン診療では、患者が医療機関に直接訪問するわけではないので、薬を直接薬局に行って受け取るのか、薬局から配送を希望するのかといった薬の受け取り方を、医療機関と患者さんで口頭で話して決めてもらっており、確認に手間が発生していました。患者さんは口頭で話した内容に沿って、オンライン診療終了後に、薬局への予約を取っていました。 同時予約機能が実装されたことにより、診察の予約時にどの薬局でどういう受け取り方をしますという部分を患者さんが事前指定できるようになったので、 医療機関は事務的な話に時間をかけずに診察に集中でき、また患者さんから医師に口頭で追加説明しなくても希望通りに薬をもらえる、というフローに変更されたことが医療機関と患者のメリット だと思ってます。 同時予約機能のリリース前後でのフローの違い もう一つのドメインである調剤薬局については、前述のように診察の予約をする時に患者さんがメドレーのサービスである Pharms を使っている薬局から事前指定をできますので、 オンライン診療後に発行された処方箋の流入が増加します 。 調剤薬局の売り上げは処方箋の枚数 × 単価で大部分が決まりますので、この枚数を増やせるという観点では薬局にとってインパクトのある機能だと思っています。 ── 患者の体験も本当に良くなるし、患者と医療機関の無駄なコミュニケーションも減り、かつ薬局に対しても処方箋枚数が増えて、導線も楽に使えるようになっているというのが、今回のプロジェクトの肝になっている感じですね。これらを踏まえ、プロダクト間を横断して開発しないといけないというのが大変そうです。 開発プロジェクトについて ── どのようなチームがこの横断プロジェクトに関わっていたかを教えてください。 江藤 : 開発側で言うと４つのドメインになってます。 調剤、患者、医科、そして 患者統合基盤 です。患者統合基盤とは医療 PF の各ドメインに存在する業務システムと患者アプリを繋ぐ根幹となるプロダクトです。 ただ今回の機能は医療機関のオペレーションも変わるため、開発側でのみ完結するプロジェクトではないんですね。 いかに現場の運用に合わせつつ、体験を改善できるか？という視点で考えると、各事業側のカスタマーサクセスチームが重要になります 。特に医科と調剤のカスタマーサクセスチームとは、密に壁打ちをしながら開発を進めていました。 ── 今回のプロジェクトは特に事業部との関係性が重要な鍵だったんですね。 江藤 : そうですね。特に医療現場は業務が逼迫している場面も多いですので、例えば「ワンクリック増えます」「ここでページ遷移が増えます」といったことでも業務への影響が非常に大きくなります。 またオペレーショナルに現場を回している箇所も多く、プロダクト都合で勝手にこの方が良いよね、合理的だよね、と決めてプロダクトを作ってしまうと今までの現場オペレーションが崩れてしまい混乱を招くことがあります。 現場の習慣を理解し、我々が目指す姿と調整しながら最適解を出す のが、必須になってくる業界・業態だと思うので、その調整は事業部ともかなり気を遣ってやっていました。 ── 同時予約 Pj は、開発側がやろうということで始まったプロジェクトなんでしょうか? 江藤 : はい。これはメドレーのどのプロダクトもそうなのですが、事業責任者とプロダクト責任者がそれぞれおり、事業と開発の両観点から議論し、事業方針を決めていく、という体制をとっています。 Pharms を正しく成長させていくという観点で見ると、現フェーズでは処方箋をしっかりと調剤薬局に届けることが至上命題でした。サービスのあるべき姿とは？という観点で事業と開発両輪でやりましょうという形で決まったものになります。 横断プロジェクトで工夫をしたポイント ── 今回、横断で色々な開発プロダクトが関係してきますが、工夫した点とか気をつけた点など、どんなものがありましたか。 江藤 : 一番は各ドメインで追っている事業成果がかなり違っていましたので、その調整を時間をかけて擦り合わせした点です。 例えば、調剤の観点では処方箋をちゃんと薬局に届けるというのが、すごく重要な事業インパクトの大きい項目である一方で、医療の観点で見た時に、もちろん手間を減らすのはすごい重要ではあるんですが、医療ドメインとしてその改善に調剤と同規模のメリットを見出してもらえるかと言うと当然そうではなかったりします。 こうした部分で、ドメイン間でこのプロジェクトを達成した後に得られるメリットに差分が出てきます。メリットが大きい事業からしたら工数も大きく割けるのですが、メリットが弱い事業では同じだけ工数かけてやりましょう、という意思決定は難しいと思います。 そこで 本 Pj を通じて各ドメインではどういう事業成果を生むのか、そのために何の KPI を追うのか、を明確にしました 。事業的なメリットが多い調剤のために手伝ってくださいという形ではなく、各ドメインでどういうメリットを生んでいきますか？というところを揃えきるのが、すごく重要だったと思っています。 これを怠ると、メリットの弱い事業にとってはお手伝いみたいなプロジェクトになります。単純にエンジニアリングという部分でも面白いものにならないですよね。ですので、関係する全員でプロジェクトを実施することでどういう結果を得るのか?をちゃんと各ドメイン間で揃えました。 ── なるほど。そうするとそうした擦り合わせは江藤さんと酒井さんがやっていたんでしょうか。 酒井 : はい、僕のほうで行っていました。僕が初期のすり合わせ時に重視していたのは、スコープを適切に区切るという部分でした。調剤側の提供価値の最大化だけを追って初期から大きな機能追加を行うのではなく、変更による医科・患者・調剤へ与えるリスクや開発コストを抑えつつ、価値を最大化できる落とし所はどこか、という部分から刷り合わせしていきました。 メドレーが面白いなって思うのが、プロダクト単独で動いていくわけではなくて、 ペイシェントジャーニー(患者体験)を中心としてプロタクト群が存在しているところ です。 患者体験をより良く構築するためにそれぞれのプロダクトが動いていけるので、お手伝いというニュアンスじゃなく、プロダクトを超えてここはよくしていきましょうと言える文化があるところがいい部分かなと思いますし、やりがいがある部分かなと思います。 江藤 : 特に横断のプロジェクトだとこうした目的意識の統一に一番時間を使っても良いんじゃないかと考えています。ここが決まりさえすれば、後々迷った場合も目的に即した意思決定ができますし。ここを固めた後に各ドメインでの調整するという順番が大事だと思います。 ── 技術面で気をつけたポイントはどんなものがあったんでしょうか。 有馬 : 同時予約機能としてやりたいことはありつつ、診療所側の業務フローや患者の導線、今あるシステムの制約などを踏まえ、どのような形に落とし込めば 診療所も薬局も患者にとっても価値のある機能となるか がポイントです。 ですので、技術的な面と事業的な面を併せて考えながら、システム全体の要件を決めていくというのが最初に手がけた部分でした。 ── 機能を考える上で、全体を見据えた設計などをやっていくと思うんですが、今回はどこから着手されたんでしょうか?患者の導線だったり医療機関の業務フローなど把握した後に、取りかかった部分を聞きたいのですが。 有馬 : 同時予約におけるシステム全体の要件を固めていくと同時に、全体のシーケンスとステートマシンを作っていきました。各システム間の連携フローと、それにより生み出される予約や処方箋といったエンティティの状態遷移を決めていき、この状態の時はこういったことはできないとか、そういった辻褄を合わせるところをしっかりやっていったという感じですかね。 酒井 : 今回は、特に プロダクト横断の共通基盤として、各プロダクトでそれぞれ全く別物の仕組みやステータスを保有しているのを、共通化・抽象化するという業務が必要になる ので、すごく難しいし、難易度が高い部分だなと思っているんですけど、それを綺麗にシーケンス図に落とし込んだ有馬さんが凄いなと思いました。 江藤 : 基盤側で作っていただいたシーケンス図は UX の骨組みなんですよね。そこをいわゆる UX デザイナーが別途やるといった細分化をせず、実装の制限を加味しつつ、正しく運用を回すために、この体験を作るためにこのステータス遷移であるべきだよね、という部分を有馬さんがエンジニア観点で最初に作ってくれてるというのが、 メドレーのエンジニアのとても良い部分 だと思っています。技術だけでなく UX などにも必要であれば越境していける文化ですね。 同時予約 Pj 開発の実際 ── そうした初期フェーズを経て Pharms と CLINICS どちらの開発にも関わった小田さんに聞きたいのが、開発の流れの中でいわゆるリソース的な問題って大変だったと思うのですが、そこはどう解決したんでしょうか。 小田 : 先に Pharms 側の機能 を作ってその後に CLINICS の仕様を決めてもらってから CLINICS の開発に入る流れだったので開発が並行することはなかったです。ただ Pharms ではリードエンジニアという立場なので 、CLINICS の開発に入るための準備と、Pharms 側のレビューやフォローのリソース配分は自分で考えて、各タスクを実施する時間とタイミングを調整しながらやっていました。 一方で、この体制でも進めることができたのは Pharms チームの各メンバーが既に自走できる状態にあったので、そこに支えられたからこそできた かなと思ってます。 ── プロダクトも越境しながら開発するという文化はすごく良いと思ったのですが、ここはフローなどあったりしたんですか? 江藤 : 先程も話した通り Pharms として本プロジェクトの優先度は高かったのですが、CLINICS の事業計画やリソースを踏まえると医科側の実装着手が大きく遅れそうな見立てでした。そこで、小田さんを 医科側の開発にもアサインできたらリソース問題が解決できるのではと調整しました。医科側のエンジニアからのフォローアップは必要なので、その調整もしつつですが、開発を早められるなら良し、と開発チーム間で最終的に判断しました。 酒井 : 今まで触ってなかった CLINICS のシステムにも小田さんはガンガン切り込んでくださったので、元々 CLINICS の開発をやってたのではと思うくらいキャッチアップが早かったです。 ── プロダクトのグロースのためにリソース調整を成功させたという形だったんですね。プロダクト間の越境がしやすいような文化だったり、プロジェクトを成功させようという目線合わせが自然にできるのは良いですね。 チーム間という話でいえば QA は各チームに跨っての活動だと思いますが、その観点ではいかがですか? 小島 : 自分は開発が終盤に入ったタイミングでプロジェクトに合流しました。それまでは米山さんが QA として入っていたのですが、医科側でも検証すべきテスト観点が多数あった背景もあり、医科側の QA をメインで見る担当として参画しました。 後半に参画した背景もあり、そもそも処方箋送付という業務や Pharms プロダクトの仕様理解も浅い…という状態でしたが、 開発目的・要件定義・設計が詳細にドキュメント化されていたので、スムーズに検証に入ることができました 。検証の中で QA エンジニアとしても「この部分の仕様は見直した方が良くなる」というポイントがいくつか出てきたので、仕様の改善提案も行いました。後発参加でしたが、実際に取り入れてもらった改善も多いです。 メドレーのプロダクト開発の文化として QA エンジニアも 要件定義からレビューに参加したり、意見を言いつつプロダクトをより良くするための改善が行える ので、とても働きやすいですね。 ── 後から入っても動きやすいというのは、ドキュメントなどが整備されているからできたことだというのが分かりますね。横断プロジェクトだからこそ気がついた他のチームの良い点などあったりしますか? 酒井 : Pharms のプロジェクトってやりやすいな、と思ったのが KPI 設計がすごく明確なところだったという点でした。 色々紆余曲折あった結果ここに辿り着いてるという苦労を知ってはいるんですけど、今の KPI 設計ってやっぱりすごくシンプル で処方箋送信数ですとなると、そこから逆算した KPI を各 PF に振ればいいと言う体制だったので、すごくこれはやりやすかったポイントの一つかなと思います。 話す論点も結局そこっていう部分がすごくコミュニケーションコストが安くすんだ部分ではあるかなと思いました。 横断プロジェクトならではのエンジニアリング ── 全体の話から個別のドメインごとのエンジニアリングという点ではどのようなことをされていましたか? 小田 : 基本的には有馬さんのシーケンス図を元に開発を進めていました。CLINICS では A という状態になる、その時に B というアクションがあると Pharms では C という状態になるというように状態遷移が複雑だったため、設計時にあるべき姿に迷うことが多かったのですが、シーケンスに立ち返るとすぐにその疑問が解決するといった具合です。 有馬 : シーケンスの整合性や難しくなりすぎないように設計する ことには気をつけました。「同時予約」という言葉が先行するとついつい複雑な新機能のようなものを作りがちですが、診療所や薬局の予約機能、処方箋送信機能といった個々のパーツはもともとあるわけで、なるべくシンプルにそれらをつなぎ合わせられるように心がけました。 江藤 : 細かいプロダクト間の調整が必要になるので ちゃんと調剤の欲しい KPI も求めつつ、かつ現場のオペレーション品質を落とさないっていう観点で調整を各ドメインでやりました。 工夫したことでいうと、UX 調査を徹底したところでしょうか。 今回のサービスって業界的にみた時に新しいかというとそうではないんですよね。ですので、同業界の企業さんの各アプリの体験とか、自分でも結構色々使いながら体験してみましたし、それらをベースに逆に現状のうちの仕様を踏まえると、こういう風にうちでは実装しましょうみたいなところを色々やっていました。 小田 : エンジニアリングの観点でいうと、特に患者アプリチームとの API 連携の仕様調整と、開発の進め方は密に連携しながら進めました。先にこっちができてないと向こうも開発できない状態になるので、担当者同士でコミュニケーションとりつつ、工夫しながら進めていました。 酒井 : CLINICS で気にしてた部分はどちらかというと リスクとコストの部分、いかに最小化して価値を最大化するかが一番重要 かなと思っていたので、一番大事なのはやっぱり医科にとってどういう価値が出て、医科にとってどういうリスクが発生するかを考えてました。 例えば一番最初のすり合わせで薬局予約する時に日時まで確定させましょうという話もあったんですけど、そこまでスコープを広げなくてもメリットが出るのであれば、広げたくないですという話をしていました。 あとはリリースプランの策定とかかな？全医療機関に一斉に出すのではなく、まずは一部医療機関様だけに公開するリリース方式にしましょうみたいなところも含めてですかね。医科側で一旦テストをやって検証して、スムーズに機能が使えるところを確認したりするステップを設けましょうと安全策を取りながら進めました。 これはこのプロジェクトに関わらず、どんなプロジェクトでも一番重要でそこが後からひっくり返るのが一番手戻りになってくるので、そこは重要かなと思いながら進めてましたね。 小島 : QA 視点だと横断プロジェクトゆえにステートが本当に複雑で、メドレー入社後に経験したプロジェクトの中で検証の難易度が最も高かったですね。 ですが、皆さん仰られているように各ユースケースに対する設計が図でドキュメント化されていたので、テストケースとして転用できた部分も多くありました。有馬さんが作成した設計図があったからこそ漏れなくテストできた部分は大きいです。大勢が参加するプロジェクトにおいて、全員が認識合わせる上でも設計図は本当に大事だなと痛感しました。 工夫した点としては、小田さんは Pharms 開発のドメイン知識が豊富だったので、QA 時は Pharms 側をメインに見てもらいつつ、自分は CLINICS 側の QA を手厚く見るようにしました。どちらのドメインにも関係する契約プラン等の複雑な仕様は自分が担当しました。 QA 以外の面だと、リリースする上で必要な浮いたボールがあれば積極的に取りにいくようにしました。 例えば、これまで一部の医療機関様だけに機能リリースする場合、その後のフィードバック回収はメールや面談で個別に行っていましたが、日々の診療の中でお時間を確保頂くのが難しいという状況がありました。その結果、本 Pj においても全体リリースして問題ないか？の判断がしづらい時期がありました。 そこで Google フォームでアンケートを作成して短時間で回答できる形に切り替えました。結果的に 100% 回答を得ることができました。 アンケート結果から「従来機能より価値があり、院内オペレーションに組み込んで頂くコストもそこまで高くない」という点が評価できたので、自信を持って全体公開リリースに向けて GO 判定できました。** メドレーは役割に縛られずボールを任せて頂ける環境があるので、自分の専門領域以外のことも学べている**と思うことが多いです。 幸いリリース後も大きな不具合はないのでこれはもう皆さんのおかげですね。 同時予約 Pj を終えて ── では最後にこのプロジェクトの総括をしていだければ。 江藤 : 横断ではあるけど各ドメインでそれぞれのプロフェッショナルがちゃんと力を発揮してプロジェクトをやり切れたというのはすごく大きい資産でした。 医療 PF はアセットをたくさん持っているので、色々組み合わせると、他の会社だとできないけど、うちならできそうだね、みたいなことが色々ある んです。 なので、この後も横断プロジェクトは予定されていますが、それに先駆けてひとつやりきって、かつ僕らが欲しかった期待成果を現状出せているところを含めるとすごく良い一歩だったのかな、と思ってます。 次は品質を担保しつつ、もっとスピードを上げていきたいというのが観点として大きいですね。 ── なるほど。こうした横断プロジェクトもやっていく医療 PF ではどんなエンジニアがマッチするポイントでしょう? 有馬 : 技術と併せてユーザーへの価値提供も考えながらエンジニアリングしたい人がマッチするのではないかと思います。 ── 各プロダクトの持っている役割を踏まえて、俯瞰の視点で開発もしたいという方にはすごく魅力的ですね。本日はありがとうございました。 さいごに 同時予約 Pj について、プロジェクトを推進したメンバーに話を聞きましたが、複雑な要件を実現可能な形にして各チームで垣根を越えて開発をしている様子がとても印象的でした。特に医療 PF ではドメイン同士で有機的に結合していき、コラボレーションすることによりステークホルダーへの価値を高めているというのは、やりがいがあるのではないかと感じます。 このようなプロジェクトで力を発揮したいと思った方はぜひ、お気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの古川です。 今回は CLINICS / Pharms 同時予約プロジェクト(以下、同時予約 Pj)というプロダクト横断で様々な部署が関わった開発プロジェクトについて、尽力された皆さんに座談会形式でお話を伺いました。 メドレーの医療プラットフォーム(以下、医療 PF)でどのようにこうした横断プロジェクトを完遂したのかの様子を皆さんに知ってもらえればと思います。 対談メンバー紹介 ── はじめに、皆さんの自己紹介をお願いします。 江藤 : 所属は医療 PF のプロダクト開発室の Pharms 開発チームです。 役割としては調剤薬局向けのシステムの Pharms のプロダクトオーナーを担っています。 経歴としては、2021 年の 1 月から Pharms のカスタマーサクセスとしてメドレーにジョインしまして、2023 年 1 月から開発チームに来ました。 これまでは事業側の経験が長く、営業全般や事業開発をメインでやってきたキャリアです。 このプロジェクトの PO としてリードする動きをしており、Pharms が担う調剤側のリードに加えて、全体の旗振りや調整等を主軸にやっていました。 江藤さん ── 江藤さんがプロジェクトの中心となって推進したんですね。 江藤 : 調剤ドメインの Pharms にとって事業インパクトがすごく大きい開発だったので、調剤ドメインが責任持ってやりましょう、という整理です。 小田 : 自分の所属も江藤さんと同じになります。 経歴は、2021 年 7 月にエンジニアとして入社し、これまでずっと Pharms の開発をやってます。 入社後はクライアント認証機能や法人担当者向けの本部機能などの機能開発を行ってきました。 昨年から Pharms のリードエンジニアとしてチーム全体を見つつ、Pharms の技術責任者として江藤さんと両輪で動くような形でプロジェクトの推進に関わっています。 小田さん 有馬 : 医療 PF プロダクト開発室、患者統合基盤チームに所属しています。患者統合基盤とは、CLINICS（患者アプリ）というアプリのバックエンドシステムであり、診療所や歯科医院、薬局向けのシステムとの連携基盤としても機能しているプロダクトになります。 経歴は、このメンバーの中では一番古く 2018 年 3 月に入社して、当初は CLINICS カルテの機能拡張の開発に参加し、PKI 基盤や CLINICS エージェントを始めとした他社システムとの連携基盤の開発を行っていました。2020 年くらいから患者統合基盤の立ち上げに参加して、現在に至ります。 有馬さん 酒井 : 入社は 2019 年 8 月なので、 5 年目となります。 デザイナーとして入社後 1 年間はジョブメドレーに在籍していました。その後オンライン診療が伸びてきた時期になり、CLINICS 側のデザイナーの人数が足りなくなったことがありまして、そこからは電子カルテを含めた CLINICS のデザイン全般を担当していました。去年から電子カルテ以外の業務領域の PdM として活動しています。軸足はデザイナーなのですがプロダクトのマネジメントみたいなこともし始めてます。 このプロジェクトにおいては、さっき江藤さんがおっしゃった通り、Pharms の価値向上が中心のプロジェクトなのでプロジェクトの一番大きいリードは江藤さんになるかと思うんですけど、CLINICS などの医科側のプロジェクトリードと言う立ち位置が僕になるかなと思います。 酒井さん 小島 : 医療 PF プロダクト開発室の QA グループに所属しています。QA グループのマネージャである 米山 さんのご紹介で 2022 年 4 月にメドレー３人目の QA エンジニアとして入社しました。主担当は CLINICS の予約機能を中心とした周辺領域です。ここまで酒井さんと一緒に働かせて頂く機会が多く、直近では予約方法を拡張する「リクエスト予約」機能の QA を担当しました。 同時予約に関しては、主に医科側の部分の QA から始まり、調剤側の QA も必要ということになり、最終的には全体の QA を担当しました。 小島さん 同時予約の機能や解決した課題 ── ありがとうございます。次に、今回の同時予約についてどういった機能で、どういった課題を解決するべきかをお話しいただきたいです。 江藤 : 機能としては、 CLINICS（患者アプリ）からオンライン診療を予約する際に、薬の受け取り先として薬局を事前指定できる機能 になっています。 この機能に関係するドメインは患者・医療機関・調剤薬局の３つです。 患者と医療機関のメリットとしては、薬の処方までの手間が減ることです。 オンライン診療では、患者が医療機関に直接訪問するわけではないので、薬を直接薬局に行って受け取るのか、薬局から配送を希望するのかといった薬の受け取り方を、医療機関と患者さんで口頭で話して決めてもらっており、確認に手間が発生していました。患者さんは口頭で話した内容に沿って、オンライン診療終了後に、薬局への予約を取っていました。 同時予約機能が実装されたことにより、診察の予約時にどの薬局でどういう受け取り方をしますという部分を患者さんが事前指定できるようになったので、 医療機関は事務的な話に時間をかけずに診察に集中でき、また患者さんから医師に口頭で追加説明しなくても希望通りに薬をもらえる、というフローに変更されたことが医療機関と患者のメリット だと思ってます。 同時予約機能のリリース前後でのフローの違い もう一つのドメインである調剤薬局については、前述のように診察の予約をする時に患者さんがメドレーのサービスである Pharms を使っている薬局から事前指定をできますので、 オンライン診療後に発行された処方箋の流入が増加します 。 調剤薬局の売り上げは処方箋の枚数 × 単価で大部分が決まりますので、この枚数を増やせるという観点では薬局にとってインパクトのある機能だと思っています。 ── 患者の体験も本当に良くなるし、患者と医療機関の無駄なコミュニケーションも減り、かつ薬局に対しても処方箋枚数が増えて、導線も楽に使えるようになっているというのが、今回のプロジェクトの肝になっている感じですね。これらを踏まえ、プロダクト間を横断して開発しないといけないというのが大変そうです。 開発プロジェクトについて ── どのようなチームがこの横断プロジェクトに関わっていたかを教えてください。 江藤 : 開発側で言うと４つのドメインになってます。 調剤、患者、医科、そして 患者統合基盤 です。患者統合基盤とは医療 PF の各ドメインに存在する業務システムと患者アプリを繋ぐ根幹となるプロダクトです。 ただ今回の機能は医療機関のオペレーションも変わるため、開発側でのみ完結するプロジェクトではないんですね。 いかに現場の運用に合わせつつ、体験を改善できるか？という視点で考えると、各事業側のカスタマーサクセスチームが重要になります 。特に医科と調剤のカスタマーサクセスチームとは、密に壁打ちをしながら開発を進めていました。 ── 今回のプロジェクトは特に事業部との関係性が重要な鍵だったんですね。 江藤 : そうですね。特に医療現場は業務が逼迫している場面も多いですので、例えば「ワンクリック増えます」「ここでページ遷移が増えます」といったことでも業務への影響が非常に大きくなります。 またオペレーショナルに現場を回している箇所も多く、プロダクト都合で勝手にこの方が良いよね、合理的だよね、と決めてプロダクトを作ってしまうと今までの現場オペレーションが崩れてしまい混乱を招くことがあります。 現場の習慣を理解し、我々が目指す姿と調整しながら最適解を出す のが、必須になってくる業界・業態だと思うので、その調整は事業部ともかなり気を遣ってやっていました。 ── 同時予約 Pj は、開発側がやろうということで始まったプロジェクトなんでしょうか? 江藤 : はい。これはメドレーのどのプロダクトもそうなのですが、事業責任者とプロダクト責任者がそれぞれおり、事業と開発の両観点から議論し、事業方針を決めていく、という体制をとっています。 Pharms を正しく成長させていくという観点で見ると、現フェーズでは処方箋をしっかりと調剤薬局に届けることが至上命題でした。サービスのあるべき姿とは？という観点で事業と開発両輪でやりましょうという形で決まったものになります。 横断プロジェクトで工夫をしたポイント ── 今回、横断で色々な開発プロダクトが関係してきますが、工夫した点とか気をつけた点など、どんなものがありましたか。 江藤 : 一番は各ドメインで追っている事業成果がかなり違っていましたので、その調整を時間をかけて擦り合わせした点です。 例えば、調剤の観点では処方箋をちゃんと薬局に届けるというのが、すごく重要な事業インパクトの大きい項目である一方で、医療の観点で見た時に、もちろん手間を減らすのはすごい重要ではあるんですが、医療ドメインとしてその改善に調剤と同規模のメリットを見出してもらえるかと言うと当然そうではなかったりします。 こうした部分で、ドメイン間でこのプロジェクトを達成した後に得られるメリットに差分が出てきます。メリットが大きい事業からしたら工数も大きく割けるのですが、メリットが弱い事業では同じだけ工数かけてやりましょう、という意思決定は難しいと思います。 そこで 本 Pj を通じて各ドメインではどういう事業成果を生むのか、そのために何の KPI を追うのか、を明確にしました 。事業的なメリットが多い調剤のために手伝ってくださいという形ではなく、各ドメインでどういうメリットを生んでいきますか？というところを揃えきるのが、すごく重要だったと思っています。 これを怠ると、メリットの弱い事業にとってはお手伝いみたいなプロジェクトになります。単純にエンジニアリングという部分でも面白いものにならないですよね。ですので、関係する全員でプロジェクトを実施することでどういう結果を得るのか?をちゃんと各ドメイン間で揃えました。 ── なるほど。そうするとそうした擦り合わせは江藤さんと酒井さんがやっていたんでしょうか。 酒井 : はい、僕のほうで行っていました。僕が初期のすり合わせ時に重視していたのは、スコープを適切に区切るという部分でした。調剤側の提供価値の最大化だけを追って初期から大きな機能追加を行うのではなく、変更による医科・患者・調剤へ与えるリスクや開発コストを抑えつつ、価値を最大化できる落とし所はどこか、という部分から刷り合わせしていきました。 メドレーが面白いなって思うのが、プロダクト単独で動いていくわけではなくて、 ペイシェントジャーニー(患者体験)を中心としてプロタクト群が存在しているところ です。 患者体験をより良く構築するためにそれぞれのプロダクトが動いていけるので、お手伝いというニュアンスじゃなく、プロダクトを超えてここはよくしていきましょうと言える文化があるところがいい部分かなと思いますし、やりがいがある部分かなと思います。 江藤 : 特に横断のプロジェクトだとこうした目的意識の統一に一番時間を使っても良いんじゃないかと考えています。ここが決まりさえすれば、後々迷った場合も目的に即した意思決定ができますし。ここを固めた後に各ドメインでの調整するという順番が大事だと思います。 ── 技術面で気をつけたポイントはどんなものがあったんでしょうか。 有馬 : 同時予約機能としてやりたいことはありつつ、診療所側の業務フローや患者の導線、今あるシステムの制約などを踏まえ、どのような形に落とし込めば 診療所も薬局も患者にとっても価値のある機能となるか がポイントです。 ですので、技術的な面と事業的な面を併せて考えながら、システム全体の要件を決めていくというのが最初に手がけた部分でした。 ── 機能を考える上で、全体を見据えた設計などをやっていくと思うんですが、今回はどこから着手されたんでしょうか?患者の導線だったり医療機関の業務フローなど把握した後に、取りかかった部分を聞きたいのですが。 有馬 : 同時予約におけるシステム全体の要件を固めていくと同時に、全体のシーケンスとステートマシンを作っていきました。各システム間の連携フローと、それにより生み出される予約や処方箋といったエンティティの状態遷移を決めていき、この状態の時はこういったことはできないとか、そういった辻褄を合わせるところをしっかりやっていったという感じですかね。 酒井 : 今回は、特に プロダクト横断の共通基盤として、各プロダクトでそれぞれ全く別物の仕組みやステータスを保有しているのを、共通化・抽象化するという業務が必要になる ので、すごく難しいし、難易度が高い部分だなと思っているんですけど、それを綺麗にシーケンス図に落とし込んだ有馬さんが凄いなと思いました。 江藤 : 基盤側で作っていただいたシーケンス図は UX の骨組みなんですよね。そこをいわゆる UX デザイナーが別途やるといった細分化をせず、実装の制限を加味しつつ、正しく運用を回すために、この体験を作るためにこのステータス遷移であるべきだよね、という部分を有馬さんがエンジニア観点で最初に作ってくれてるというのが、 メドレーのエンジニアのとても良い部分 だと思っています。技術だけでなく UX などにも必要であれば越境していける文化ですね。 同時予約 Pj 開発の実際 ── そうした初期フェーズを経て Pharms と CLINICS どちらの開発にも関わった小田さんに聞きたいのが、開発の流れの中でいわゆるリソース的な問題って大変だったと思うのですが、そこはどう解決したんでしょうか。 小田 : 先に Pharms 側の機能 を作ってその後に CLINICS の仕様を決めてもらってから CLINICS の開発に入る流れだったので開発が並行することはなかったです。ただ Pharms ではリードエンジニアという立場なので 、CLINICS の開発に入るための準備と、Pharms 側のレビューやフォローのリソース配分は自分で考えて、各タスクを実施する時間とタイミングを調整しながらやっていました。 一方で、この体制でも進めることができたのは Pharms チームの各メンバーが既に自走できる状態にあったので、そこに支えられたからこそできた かなと思ってます。 ── プロダクトも越境しながら開発するという文化はすごく良いと思ったのですが、ここはフローなどあったりしたんですか? 江藤 : 先程も話した通り Pharms として本プロジェクトの優先度は高かったのですが、CLINICS の事業計画やリソースを踏まえると医科側の実装着手が大きく遅れそうな見立てでした。そこで、小田さんを 医科側の開発にもアサインできたらリソース問題が解決できるのではと調整しました。医科側のエンジニアからのフォローアップは必要なので、その調整もしつつですが、開発を早められるなら良し、と開発チーム間で最終的に判断しました。 酒井 : 今まで触ってなかった CLINICS のシステムにも小田さんはガンガン切り込んでくださったので、元々 CLINICS の開発をやってたのではと思うくらいキャッチアップが早かったです。 ── プロダクトのグロースのためにリソース調整を成功させたという形だったんですね。プロダクト間の越境がしやすいような文化だったり、プロジェクトを成功させようという目線合わせが自然にできるのは良いですね。 チーム間という話でいえば QA は各チームに跨っての活動だと思いますが、その観点ではいかがですか? 小島 : 自分は開発が終盤に入ったタイミングでプロジェクトに合流しました。それまでは米山さんが QA として入っていたのですが、医科側でも検証すべきテスト観点が多数あった背景もあり、医科側の QA をメインで見る担当として参画しました。 後半に参画した背景もあり、そもそも処方箋送付という業務や Pharms プロダクトの仕様理解も浅い…という状態でしたが、 開発目的・要件定義・設計が詳細にドキュメント化されていたので、スムーズに検証に入ることができました 。検証の中で QA エンジニアとしても「この部分の仕様は見直した方が良くなる」というポイントがいくつか出てきたので、仕様の改善提案も行いました。後発参加でしたが、実際に取り入れてもらった改善も多いです。 メドレーのプロダクト開発の文化として QA エンジニアも 要件定義からレビューに参加したり、意見を言いつつプロダクトをより良くするための改善が行える ので、とても働きやすいですね。 ── 後から入っても動きやすいというのは、ドキュメントなどが整備されているからできたことだというのが分かりますね。横断プロジェクトだからこそ気がついた他のチームの良い点などあったりしますか? 酒井 : Pharms のプロジェクトってやりやすいな、と思ったのが KPI 設計がすごく明確なところだったという点でした。 色々紆余曲折あった結果ここに辿り着いてるという苦労を知ってはいるんですけど、今の KPI 設計ってやっぱりすごくシンプル で処方箋送信数ですとなると、そこから逆算した KPI を各 PF に振ればいいと言う体制だったので、すごくこれはやりやすかったポイントの一つかなと思います。 話す論点も結局そこっていう部分がすごくコミュニケーションコストが安くすんだ部分ではあるかなと思いました。 横断プロジェクトならではのエンジニアリング ── 全体の話から個別のドメインごとのエンジニアリングという点ではどのようなことをされていましたか? 小田 : 基本的には有馬さんのシーケンス図を元に開発を進めていました。CLINICS では A という状態になる、その時に B というアクションがあると Pharms では C という状態になるというように状態遷移が複雑だったため、設計時にあるべき姿に迷うことが多かったのですが、シーケンスに立ち返るとすぐにその疑問が解決するといった具合です。 有馬 : シーケンスの整合性や難しくなりすぎないように設計する ことには気をつけました。「同時予約」という言葉が先行するとついつい複雑な新機能のようなものを作りがちですが、診療所や薬局の予約機能、処方箋送信機能といった個々のパーツはもともとあるわけで、なるべくシンプルにそれらをつなぎ合わせられるように心がけました。 江藤 : 細かいプロダクト間の調整が必要になるので ちゃんと調剤の欲しい KPI も求めつつ、かつ現場のオペレーション品質を落とさないっていう観点で調整を各ドメインでやりました。 工夫したことでいうと、UX 調査を徹底したところでしょうか。 今回のサービスって業界的にみた時に新しいかというとそうではないんですよね。ですので、同業界の企業さんの各アプリの体験とか、自分でも結構色々使いながら体験してみましたし、それらをベースに逆に現状のうちの仕様を踏まえると、こういう風にうちでは実装しましょうみたいなところを色々やっていました。 小田 : エンジニアリングの観点でいうと、特に患者アプリチームとの API 連携の仕様調整と、開発の進め方は密に連携しながら進めました。先にこっちができてないと向こうも開発できない状態になるので、担当者同士でコミュニケーションとりつつ、工夫しながら進めていました。 酒井 : CLINICS で気にしてた部分はどちらかというと リスクとコストの部分、いかに最小化して価値を最大化するかが一番重要 かなと思っていたので、一番大事なのはやっぱり医科にとってどういう価値が出て、医科にとってどういうリスクが発生するかを考えてました。 例えば一番最初のすり合わせで薬局予約する時に日時まで確定させましょうという話もあったんですけど、そこまでスコープを広げなくてもメリットが出るのであれば、広げたくないですという話をしていました。 あとはリリースプランの策定とかかな？全医療機関に一斉に出すのではなく、まずは一部医療機関様だけに公開するリリース方式にしましょうみたいなところも含めてですかね。医科側で一旦テストをやって検証して、スムーズに機能が使えるところを確認したりするステップを設けましょうと安全策を取りながら進めました。 これはこのプロジェクトに関わらず、どんなプロジェクトでも一番重要でそこが後からひっくり返るのが一番手戻りになってくるので、そこは重要かなと思いながら進めてましたね。 小島 : QA 視点だと横断プロジェクトゆえにステートが本当に複雑で、メドレー入社後に経験したプロジェクトの中で検証の難易度が最も高かったですね。 ですが、皆さん仰られているように各ユースケースに対する設計が図でドキュメント化されていたので、テストケースとして転用できた部分も多くありました。有馬さんが作成した設計図があったからこそ漏れなくテストできた部分は大きいです。大勢が参加するプロジェクトにおいて、全員が認識合わせる上でも設計図は本当に大事だなと痛感しました。 工夫した点としては、小田さんは Pharms 開発のドメイン知識が豊富だったので、QA 時は Pharms 側をメインに見てもらいつつ、自分は CLINICS 側の QA を手厚く見るようにしました。どちらのドメインにも関係する契約プラン等の複雑な仕様は自分が担当しました。 QA 以外の面だと、リリースする上で必要な浮いたボールがあれば積極的に取りにいくようにしました。 例えば、これまで一部の医療機関様だけに機能リリースする場合、その後のフィードバック回収はメールや面談で個別に行っていましたが、日々の診療の中でお時間を確保頂くのが難しいという状況がありました。その結果、本 Pj においても全体リリースして問題ないか？の判断がしづらい時期がありました。 そこで Google フォームでアンケートを作成して短時間で回答できる形に切り替えました。結果的に 100% 回答を得ることができました。 アンケート結果から「従来機能より価値があり、院内オペレーションに組み込んで頂くコストもそこまで高くない」という点が評価できたので、自信を持って全体公開リリースに向けて GO 判定できました。** メドレーは役割に縛られずボールを任せて頂ける環境があるので、自分の専門領域以外のことも学べている**と思うことが多いです。 幸いリリース後も大きな不具合はないのでこれはもう皆さんのおかげですね。 同時予約 Pj を終えて ── では最後にこのプロジェクトの総括をしていだければ。 江藤 : 横断ではあるけど各ドメインでそれぞれのプロフェッショナルがちゃんと力を発揮してプロジェクトをやり切れたというのはすごく大きい資産でした。 医療 PF はアセットをたくさん持っているので、色々組み合わせると、他の会社だとできないけど、うちならできそうだね、みたいなことが色々ある んです。 なので、この後も横断プロジェクトは予定されていますが、それに先駆けてひとつやりきって、かつ僕らが欲しかった期待成果を現状出せているところを含めるとすごく良い一歩だったのかな、と思ってます。 次は品質を担保しつつ、もっとスピードを上げていきたいというのが観点として大きいですね。 ── なるほど。こうした横断プロジェクトもやっていく医療 PF ではどんなエンジニアがマッチするポイントでしょう? 有馬 : 技術と併せてユーザーへの価値提供も考えながらエンジニアリングしたい人がマッチするのではないかと思います。 ── 各プロダクトの持っている役割を踏まえて、俯瞰の視点で開発もしたいという方にはすごく魅力的ですね。本日はありがとうございました。 さいごに 同時予約 Pj について、プロジェクトを推進したメンバーに話を聞きましたが、複雑な要件を実現可能な形にして各チームで垣根を越えて開発をしている様子がとても印象的でした。特に医療 PF ではドメイン同士で有機的に結合していき、コラボレーションすることによりステークホルダーへの価値を高めているというのは、やりがいがあるのではないかと感じます。 このようなプロジェクトで力を発揮したいと思った方はぜひ、お気軽にお話をしましょう! https://www.medley.jp/jobs/

はじめに みなさん、こんにちは。エンジニアの古川です。 今回は CLINICS / Pharms 同時予約プロジェクト(以下、同時予約 Pj)というプロダクト横断で様々な部署が関わった開発プロジェクトについて、尽力された皆さんに座談会形式でお話を伺いました。 メドレーの医療プラットフォーム(以下、医療 PF)でどのようにこうした横断プロジェクトを完遂したのかの様子を皆さんに知ってもらえればと思います。 対談メンバー紹介 ── はじめに、皆さんの自己紹介をお願いします。 江藤 : 所属は医療 PF のプロダクト開発室の Pharms 開発チームです。 役割としては調剤薬局向けのシステムの Pharms のプロダクトオーナーを担っています。 経歴としては、2021 年の 1 月から Pharms のカスタマーサクセスとしてメドレーにジョインしまして、2023 年 1 月から開発チームに来ました。 これまでは事業側の経験が長く、営業全般や事業開発をメインでやってきたキャリアです。 このプロジェクトの PO としてリードする動きをしており、Pharms が担う調剤側のリードに加えて、全体の旗振りや調整等を主軸にやっていました。 江藤さん ── 江藤さんがプロジェクトの中心となって推進したんですね。 江藤 : 調剤ドメインの Pharms にとって事業インパクトがすごく大きい開発だったので、調剤ドメインが責任持ってやりましょう、という整理です。 小田 : 自分の所属も江藤さんと同じになります。 経歴は、2021 年 7 月にエンジニアとして入社し、これまでずっと Pharms の開発をやってます。 入社後はクライアント認証機能や法人担当者向けの本部機能などの機能開発を行ってきました。 昨年から Pharms のリードエンジニアとしてチーム全体を見つつ、Pharms の技術責任者として江藤さんと両輪で動くような形でプロジェクトの推進に関わっています。 小田さん 有馬 : 医療 PF プロダクト開発室、患者統合基盤チームに所属しています。患者統合基盤とは、CLINICS（患者アプリ）というアプリのバックエンドシステムであり、診療所や歯科医院、薬局向けのシステムとの連携基盤としても機能しているプロダクトになります。 経歴は、このメンバーの中では一番古く 2018 年 3 月に入社して、当初は CLINICS カルテの機能拡張の開発に参加し、PKI 基盤や CLINICS エージェントを始めとした他社システムとの連携基盤の開発を行っていました。2020 年くらいから患者統合基盤の立ち上げに参加して、現在に至ります。 有馬さん 酒井 : 入社は 2019 年 8 月なので、 5 年目となります。 デザイナーとして入社後 1 年間はジョブメドレーに在籍していました。その後オンライン診療が伸びてきた時期になり、CLINICS 側のデザイナーの人数が足りなくなったことがありまして、そこからは電子カルテを含めた CLINICS のデザイン全般を担当していました。去年から電子カルテ以外の業務領域の PdM として活動しています。軸足はデザイナーなのですがプロダクトのマネジメントみたいなこともし始めてます。 このプロジェクトにおいては、さっき江藤さんがおっしゃった通り、Pharms の価値向上が中心のプロジェクトなのでプロジェクトの一番大きいリードは江藤さんになるかと思うんですけど、CLINICS などの医科側のプロジェクトリードと言う立ち位置が僕になるかなと思います。 酒井さん 小島 : 医療 PF プロダクト開発室の QA グループに所属しています。QA グループのマネージャである 米山 さんのご紹介で 2022 年 4 月にメドレー３人目の QA エンジニアとして入社しました。主担当は CLINICS の予約機能を中心とした周辺領域です。ここまで酒井さんと一緒に働かせて頂く機会が多く、直近では予約方法を拡張する「リクエスト予約」機能の QA を担当しました。 同時予約に関しては、主に医科側の部分の QA から始まり、調剤側の QA も必要ということになり、最終的には全体の QA を担当しました。 小島さん 同時予約の機能や解決した課題 ── ありがとうございます。次に、今回の同時予約についてどういった機能で、どういった課題を解決するべきかをお話しいただきたいです。 江藤 : 機能としては、 CLINICS（患者アプリ）からオンライン診療を予約する際に、薬の受け取り先として薬局を事前指定できる機能 になっています。 この機能に関係するドメインは患者・医療機関・調剤薬局の３つです。 患者と医療機関のメリットとしては、薬の処方までの手間が減ることです。 オンライン診療では、患者が医療機関に直接訪問するわけではないので、薬を直接薬局に行って受け取るのか、薬局から配送を希望するのかといった薬の受け取り方を、医療機関と患者さんで口頭で話して決めてもらっており、確認に手間が発生していました。患者さんは口頭で話した内容に沿って、オンライン診療終了後に、薬局への予約を取っていました。 同時予約機能が実装されたことにより、診察の予約時にどの薬局でどういう受け取り方をしますという部分を患者さんが事前指定できるようになったので、 医療機関は事務的な話に時間をかけずに診察に集中でき、また患者さんから医師に口頭で追加説明しなくても希望通りに薬をもらえる、というフローに変更されたことが医療機関と患者のメリット だと思ってます。 同時予約機能のリリース前後でのフローの違い もう一つのドメインである調剤薬局については、前述のように診察の予約をする時に患者さんがメドレーのサービスである Pharms を使っている薬局から事前指定をできますので、 オンライン診療後に発行された処方箋の流入が増加します 。 調剤薬局の売り上げは処方箋の枚数 × 単価で大部分が決まりますので、この枚数を増やせるという観点では薬局にとってインパクトのある機能だと思っています。 ── 患者の体験も本当に良くなるし、患者と医療機関の無駄なコミュニケーションも減り、かつ薬局に対しても処方箋枚数が増えて、導線も楽に使えるようになっているというのが、今回のプロジェクトの肝になっている感じですね。これらを踏まえ、プロダクト間を横断して開発しないといけないというのが大変そうです。 開発プロジェクトについて ── どのようなチームがこの横断プロジェクトに関わっていたかを教えてください。 江藤 : 開発側で言うと４つのドメインになってます。 調剤、患者、医科、そして 患者統合基盤 です。患者統合基盤とは医療 PF の各ドメインに存在する業務システムと患者アプリを繋ぐ根幹となるプロダクトです。 ただ今回の機能は医療機関のオペレーションも変わるため、開発側でのみ完結するプロジェクトではないんですね。 いかに現場の運用に合わせつつ、体験を改善できるか？という視点で考えると、各事業側のカスタマーサクセスチームが重要になります 。特に医科と調剤のカスタマーサクセスチームとは、密に壁打ちをしながら開発を進めていました。 ── 今回のプロジェクトは特に事業部との関係性が重要な鍵だったんですね。 江藤 : そうですね。特に医療現場は業務が逼迫している場面も多いですので、例えば「ワンクリック増えます」「ここでページ遷移が増えます」といったことでも業務への影響が非常に大きくなります。 またオペレーショナルに現場を回している箇所も多く、プロダクト都合で勝手にこの方が良いよね、合理的だよね、と決めてプロダクトを作ってしまうと今までの現場オペレーションが崩れてしまい混乱を招くことがあります。 現場の習慣を理解し、我々が目指す姿と調整しながら最適解を出す のが、必須になってくる業界・業態だと思うので、その調整は事業部ともかなり気を遣ってやっていました。 ── 同時予約 Pj は、開発側がやろうということで始まったプロジェクトなんでしょうか? 江藤 : はい。これはメドレーのどのプロダクトもそうなのですが、事業責任者とプロダクト責任者がそれぞれおり、事業と開発の両観点から議論し、事業方針を決めていく、という体制をとっています。 Pharms を正しく成長させていくという観点で見ると、現フェーズでは処方箋をしっかりと調剤薬局に届けることが至上命題でした。サービスのあるべき姿とは？という観点で事業と開発両輪でやりましょうという形で決まったものになります。 横断プロジェクトで工夫をしたポイント ── 今回、横断で色々な開発プロダクトが関係してきますが、工夫した点とか気をつけた点など、どんなものがありましたか。 江藤 : 一番は各ドメインで追っている事業成果がかなり違っていましたので、その調整を時間をかけて擦り合わせした点です。 例えば、調剤の観点では処方箋をちゃんと薬局に届けるというのが、すごく重要な事業インパクトの大きい項目である一方で、医療の観点で見た時に、もちろん手間を減らすのはすごい重要ではあるんですが、医療ドメインとしてその改善に調剤と同規模のメリットを見出してもらえるかと言うと当然そうではなかったりします。 こうした部分で、ドメイン間でこのプロジェクトを達成した後に得られるメリットに差分が出てきます。メリットが大きい事業からしたら工数も大きく割けるのですが、メリットが弱い事業では同じだけ工数かけてやりましょう、という意思決定は難しいと思います。 そこで 本 Pj を通じて各ドメインではどういう事業成果を生むのか、そのために何の KPI を追うのか、を明確にしました 。事業的なメリットが多い調剤のために手伝ってくださいという形ではなく、各ドメインでどういうメリットを生んでいきますか？というところを揃えきるのが、すごく重要だったと思っています。 これを怠ると、メリットの弱い事業にとってはお手伝いみたいなプロジェクトになります。単純にエンジニアリングという部分でも面白いものにならないですよね。ですので、関係する全員でプロジェクトを実施することでどういう結果を得るのか?をちゃんと各ドメイン間で揃えました。 ── なるほど。そうするとそうした擦り合わせは江藤さんと酒井さんがやっていたんでしょうか。 酒井 : はい、僕のほうで行っていました。僕が初期のすり合わせ時に重視していたのは、スコープを適切に区切るという部分でした。調剤側の提供価値の最大化だけを追って初期から大きな機能追加を行うのではなく、変更による医科・患者・調剤へ与えるリスクや開発コストを抑えつつ、価値を最大化できる落とし所はどこか、という部分から刷り合わせしていきました。 メドレーが面白いなって思うのが、プロダクト単独で動いていくわけではなくて、 ペイシェントジャーニー(患者体験)を中心としてプロタクト群が存在しているところ です。 患者体験をより良く構築するためにそれぞれのプロダクトが動いていけるので、お手伝いというニュアンスじゃなく、プロダクトを超えてここはよくしていきましょうと言える文化があるところがいい部分かなと思いますし、やりがいがある部分かなと思います。 江藤 : 特に横断のプロジェクトだとこうした目的意識の統一に一番時間を使っても良いんじゃないかと考えています。ここが決まりさえすれば、後々迷った場合も目的に即した意思決定ができますし。ここを固めた後に各ドメインでの調整するという順番が大事だと思います。 ── 技術面で気をつけたポイントはどんなものがあったんでしょうか。 有馬 : 同時予約機能としてやりたいことはありつつ、診療所側の業務フローや患者の導線、今あるシステムの制約などを踏まえ、どのような形に落とし込めば 診療所も薬局も患者にとっても価値のある機能となるか がポイントです。 ですので、技術的な面と事業的な面を併せて考えながら、システム全体の要件を決めていくというのが最初に手がけた部分でした。 ── 機能を考える上で、全体を見据えた設計などをやっていくと思うんですが、今回はどこから着手されたんでしょうか?患者の導線だったり医療機関の業務フローなど把握した後に、取りかかった部分を聞きたいのですが。 有馬 : 同時予約におけるシステム全体の要件を固めていくと同時に、全体のシーケンスとステートマシンを作っていきました。各システム間の連携フローと、それにより生み出される予約や処方箋といったエンティティの状態遷移を決めていき、この状態の時はこういったことはできないとか、そういった辻褄を合わせるところをしっかりやっていったという感じですかね。 酒井 : 今回は、特に プロダクト横断の共通基盤として、各プロダクトでそれぞれ全く別物の仕組みやステータスを保有しているのを、共通化・抽象化するという業務が必要になる ので、すごく難しいし、難易度が高い部分だなと思っているんですけど、それを綺麗にシーケンス図に落とし込んだ有馬さんが凄いなと思いました。 江藤 : 基盤側で作っていただいたシーケンス図は UX の骨組みなんですよね。そこをいわゆる UX デザイナーが別途やるといった細分化をせず、実装の制限を加味しつつ、正しく運用を回すために、この体験を作るためにこのステータス遷移であるべきだよね、という部分を有馬さんがエンジニア観点で最初に作ってくれてるというのが、 メドレーのエンジニアのとても良い部分 だと思っています。技術だけでなく UX などにも必要であれば越境していける文化ですね。 同時予約 Pj 開発の実際 ── そうした初期フェーズを経て Pharms と CLINICS どちらの開発にも関わった小田さんに聞きたいのが、開発の流れの中でいわゆるリソース的な問題って大変だったと思うのですが、そこはどう解決したんでしょうか。 小田 : 先に Pharms 側の機能 を作ってその後に CLINICS の仕様を決めてもらってから CLINICS の開発に入る流れだったので開発が並行することはなかったです。ただ Pharms ではリードエンジニアという立場なので 、CLINICS の開発に入るための準備と、Pharms 側のレビューやフォローのリソース配分は自分で考えて、各タスクを実施する時間とタイミングを調整しながらやっていました。 一方で、この体制でも進めることができたのは Pharms チームの各メンバーが既に自走できる状態にあったので、そこに支えられたからこそできた かなと思ってます。 ── プロダクトも越境しながら開発するという文化はすごく良いと思ったのですが、ここはフローなどあったりしたんですか? 江藤 : 先程も話した通り Pharms として本プロジェクトの優先度は高かったのですが、CLINICS の事業計画やリソースを踏まえると医科側の実装着手が大きく遅れそうな見立てでした。そこで、小田さんを 医科側の開発にもアサインできたらリソース問題が解決できるのではと調整しました。医科側のエンジニアからのフォローアップは必要なので、その調整もしつつですが、開発を早められるなら良し、と開発チーム間で最終的に判断しました。 酒井 : 今まで触ってなかった CLINICS のシステムにも小田さんはガンガン切り込んでくださったので、元々 CLINICS の開発をやってたのではと思うくらいキャッチアップが早かったです。 ── プロダクトのグロースのためにリソース調整を成功させたという形だったんですね。プロダクト間の越境がしやすいような文化だったり、プロジェクトを成功させようという目線合わせが自然にできるのは良いですね。 チーム間という話でいえば QA は各チームに跨っての活動だと思いますが、その観点ではいかがですか? 小島 : 自分は開発が終盤に入ったタイミングでプロジェクトに合流しました。それまでは米山さんが QA として入っていたのですが、医科側でも検証すべきテスト観点が多数あった背景もあり、医科側の QA をメインで見る担当として参画しました。 後半に参画した背景もあり、そもそも処方箋送付という業務や Pharms プロダクトの仕様理解も浅い…という状態でしたが、 開発目的・要件定義・設計が詳細にドキュメント化されていたので、スムーズに検証に入ることができました 。検証の中で QA エンジニアとしても「この部分の仕様は見直した方が良くなる」というポイントがいくつか出てきたので、仕様の改善提案も行いました。後発参加でしたが、実際に取り入れてもらった改善も多いです。 メドレーのプロダクト開発の文化として QA エンジニアも 要件定義からレビューに参加したり、意見を言いつつプロダクトをより良くするための改善が行える ので、とても働きやすいですね。 ── 後から入っても動きやすいというのは、ドキュメントなどが整備されているからできたことだというのが分かりますね。横断プロジェクトだからこそ気がついた他のチームの良い点などあったりしますか? 酒井 : Pharms のプロジェクトってやりやすいな、と思ったのが KPI 設計がすごく明確なところだったという点でした。 色々紆余曲折あった結果ここに辿り着いてるという苦労を知ってはいるんですけど、今の KPI 設計ってやっぱりすごくシンプル で処方箋送信数ですとなると、そこから逆算した KPI を各 PF に振ればいいと言う体制だったので、すごくこれはやりやすかったポイントの一つかなと思います。 話す論点も結局そこっていう部分がすごくコミュニケーションコストが安くすんだ部分ではあるかなと思いました。 横断プロジェクトならではのエンジニアリング ── 全体の話から個別のドメインごとのエンジニアリングという点ではどのようなことをされていましたか? 小田 : 基本的には有馬さんのシーケンス図を元に開発を進めていました。CLINICS では A という状態になる、その時に B というアクションがあると Pharms では C という状態になるというように状態遷移が複雑だったため、設計時にあるべき姿に迷うことが多かったのですが、シーケンスに立ち返るとすぐにその疑問が解決するといった具合です。 有馬 : シーケンスの整合性や難しくなりすぎないように設計する ことには気をつけました。「同時予約」という言葉が先行するとついつい複雑な新機能のようなものを作りがちですが、診療所や薬局の予約機能、処方箋送信機能といった個々のパーツはもともとあるわけで、なるべくシンプルにそれらをつなぎ合わせられるように心がけました。 江藤 : 細かいプロダクト間の調整が必要になるので ちゃんと調剤の欲しい KPI も求めつつ、かつ現場のオペレーション品質を落とさないっていう観点で調整を各ドメインでやりました。 工夫したことでいうと、UX 調査を徹底したところでしょうか。 今回のサービスって業界的にみた時に新しいかというとそうではないんですよね。ですので、同業界の企業さんの各アプリの体験とか、自分でも結構色々使いながら体験してみましたし、それらをベースに逆に現状のうちの仕様を踏まえると、こういう風にうちでは実装しましょうみたいなところを色々やっていました。 小田 : エンジニアリングの観点でいうと、特に患者アプリチームとの API 連携の仕様調整と、開発の進め方は密に連携しながら進めました。先にこっちができてないと向こうも開発できない状態になるので、担当者同士でコミュニケーションとりつつ、工夫しながら進めていました。 酒井 : CLINICS で気にしてた部分はどちらかというと リスクとコストの部分、いかに最小化して価値を最大化するかが一番重要 かなと思っていたので、一番大事なのはやっぱり医科にとってどういう価値が出て、医科にとってどういうリスクが発生するかを考えてました。 例えば一番最初のすり合わせで薬局予約する時に日時まで確定させましょうという話もあったんですけど、そこまでスコープを広げなくてもメリットが出るのであれば、広げたくないですという話をしていました。 あとはリリースプランの策定とかかな？全医療機関に一斉に出すのではなく、まずは一部医療機関様だけに公開するリリース方式にしましょうみたいなところも含めてですかね。医科側で一旦テストをやって検証して、スムーズに機能が使えるところを確認したりするステップを設けましょうと安全策を取りながら進めました。 これはこのプロジェクトに関わらず、どんなプロジェクトでも一番重要でそこが後からひっくり返るのが一番手戻りになってくるので、そこは重要かなと思いながら進めてましたね。 小島 : QA 視点だと横断プロジェクトゆえにステートが本当に複雑で、メドレー入社後に経験したプロジェクトの中で検証の難易度が最も高かったですね。 ですが、皆さん仰られているように各ユースケースに対する設計が図でドキュメント化されていたので、テストケースとして転用できた部分も多くありました。有馬さんが作成した設計図があったからこそ漏れなくテストできた部分は大きいです。大勢が参加するプロジェクトにおいて、全員が認識合わせる上でも設計図は本当に大事だなと痛感しました。 工夫した点としては、小田さんは Pharms 開発のドメイン知識が豊富だったので、QA 時は Pharms 側をメインに見てもらいつつ、自分は CLINICS 側の QA を手厚く見るようにしました。どちらのドメインにも関係する契約プラン等の複雑な仕様は自分が担当しました。 QA 以外の面だと、リリースする上で必要な浮いたボールがあれば積極的に取りにいくようにしました。 例えば、これまで一部の医療機関様だけに機能リリースする場合、その後のフィードバック回収はメールや面談で個別に行っていましたが、日々の診療の中でお時間を確保頂くのが難しいという状況がありました。その結果、本 Pj においても全体リリースして問題ないか？の判断がしづらい時期がありました。 そこで Google フォームでアンケートを作成して短時間で回答できる形に切り替えました。結果的に 100% 回答を得ることができました。 アンケート結果から「従来機能より価値があり、院内オペレーションに組み込んで頂くコストもそこまで高くない」という点が評価できたので、自信を持って全体公開リリースに向けて GO 判定できました。** メドレーは役割に縛られずボールを任せて頂ける環境があるので、自分の専門領域以外のことも学べている**と思うことが多いです。 幸いリリース後も大きな不具合はないのでこれはもう皆さんのおかげですね。 同時予約 Pj を終えて ── では最後にこのプロジェクトの総括をしていだければ。 江藤 : 横断ではあるけど各ドメインでそれぞれのプロフェッショナルがちゃんと力を発揮してプロジェクトをやり切れたというのはすごく大きい資産でした。 医療 PF はアセットをたくさん持っているので、色々組み合わせると、他の会社だとできないけど、うちならできそうだね、みたいなことが色々ある んです。 なので、この後も横断プロジェクトは予定されていますが、それに先駆けてひとつやりきって、かつ僕らが欲しかった期待成果を現状出せているところを含めるとすごく良い一歩だったのかな、と思ってます。 次は品質を担保しつつ、もっとスピードを上げていきたいというのが観点として大きいですね。 ── なるほど。こうした横断プロジェクトもやっていく医療 PF ではどんなエンジニアがマッチするポイントでしょう? 有馬 : 技術と併せてユーザーへの価値提供も考えながらエンジニアリングしたい人がマッチするのではないかと思います。 ── 各プロダクトの持っている役割を踏まえて、俯瞰の視点で開発もしたいという方にはすごく魅力的ですね。本日はありがとうございました。 さいごに 同時予約 Pj について、プロジェクトを推進したメンバーに話を聞きましたが、複雑な要件を実現可能な形にして各チームで垣根を越えて開発をしている様子がとても印象的でした。特に医療 PF ではドメイン同士で有機的に結合していき、コラボレーションすることによりステークホルダーへの価値を高めているというのは、やりがいがあるのではないかと感じます。 このようなプロジェクトで力を発揮したいと思った方はぜひ、お気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの古川です。 今回は CLINICS / Pharms 同時予約プロジェクト(以下、同時予約 Pj)というプロダクト横断で様々な部署が関わった開発プロジェクトについて、尽力された皆さんに座談会形式でお話を伺いました。 メドレーの医療プラットフォーム(以下、医療 PF)でどのようにこうした横断プロジェクトを完遂したのかの様子を皆さんに知ってもらえればと思います。 対談メンバー紹介 ── はじめに、皆さんの自己紹介をお願いします。 江藤 : 所属は医療 PF のプロダクト開発室の Pharms 開発チームです。 役割としては調剤薬局向けのシステムの Pharms のプロダクトオーナーを担っています。 経歴としては、2021 年の 1 月から Pharms のカスタマーサクセスとしてメドレーにジョインしまして、2023 年 1 月から開発チームに来ました。 これまでは事業側の経験が長く、営業全般や事業開発をメインでやってきたキャリアです。 このプロジェクトの PO としてリードする動きをしており、Pharms が担う調剤側のリードに加えて、全体の旗振りや調整等を主軸にやっていました。 江藤さん ── 江藤さんがプロジェクトの中心となって推進したんですね。 江藤 : 調剤ドメインの Pharms にとって事業インパクトがすごく大きい開発だったので、調剤ドメインが責任持ってやりましょう、という整理です。 小田 : 自分の所属も江藤さんと同じになります。 経歴は、2021 年 7 月にエンジニアとして入社し、これまでずっと Pharms の開発をやってます。 入社後はクライアント認証機能や法人担当者向けの本部機能などの機能開発を行ってきました。 昨年から Pharms のリードエンジニアとしてチーム全体を見つつ、Pharms の技術責任者として江藤さんと両輪で動くような形でプロジェクトの推進に関わっています。 小田さん 有馬 : 医療 PF プロダクト開発室、患者統合基盤チームに所属しています。患者統合基盤とは、CLINICS（患者アプリ）というアプリのバックエンドシステムであり、診療所や歯科医院、薬局向けのシステムとの連携基盤としても機能しているプロダクトになります。 経歴は、このメンバーの中では一番古く 2018 年 3 月に入社して、当初は CLINICS カルテの機能拡張の開発に参加し、PKI 基盤や CLINICS エージェントを始めとした他社システムとの連携基盤の開発を行っていました。2020 年くらいから患者統合基盤の立ち上げに参加して、現在に至ります。 有馬さん 酒井 : 入社は 2019 年 8 月なので、 5 年目となります。 デザイナーとして入社後 1 年間はジョブメドレーに在籍していました。その後オンライン診療が伸びてきた時期になり、CLINICS 側のデザイナーの人数が足りなくなったことがありまして、そこからは電子カルテを含めた CLINICS のデザイン全般を担当していました。去年から電子カルテ以外の業務領域の PdM として活動しています。軸足はデザイナーなのですがプロダクトのマネジメントみたいなこともし始めてます。 このプロジェクトにおいては、さっき江藤さんがおっしゃった通り、Pharms の価値向上が中心のプロジェクトなのでプロジェクトの一番大きいリードは江藤さんになるかと思うんですけど、CLINICS などの医科側のプロジェクトリードと言う立ち位置が僕になるかなと思います。 酒井さん 小島 : 医療 PF プロダクト開発室の QA グループに所属しています。QA グループのマネージャである 米山 さんのご紹介で 2022 年 4 月にメドレー３人目の QA エンジニアとして入社しました。主担当は CLINICS の予約機能を中心とした周辺領域です。ここまで酒井さんと一緒に働かせて頂く機会が多く、直近では予約方法を拡張する「リクエスト予約」機能の QA を担当しました。 同時予約に関しては、主に医科側の部分の QA から始まり、調剤側の QA も必要ということになり、最終的には全体の QA を担当しました。 小島さん 同時予約の機能や解決した課題 ── ありがとうございます。次に、今回の同時予約についてどういった機能で、どういった課題を解決するべきかをお話しいただきたいです。 江藤 : 機能としては、 CLINICS（患者アプリ）からオンライン診療を予約する際に、薬の受け取り先として薬局を事前指定できる機能 になっています。 この機能に関係するドメインは患者・医療機関・調剤薬局の３つです。 患者と医療機関のメリットとしては、薬の処方までの手間が減ることです。 オンライン診療では、患者が医療機関に直接訪問するわけではないので、薬を直接薬局に行って受け取るのか、薬局から配送を希望するのかといった薬の受け取り方を、医療機関と患者さんで口頭で話して決めてもらっており、確認に手間が発生していました。患者さんは口頭で話した内容に沿って、オンライン診療終了後に、薬局への予約を取っていました。 同時予約機能が実装されたことにより、診察の予約時にどの薬局でどういう受け取り方をしますという部分を患者さんが事前指定できるようになったので、 医療機関は事務的な話に時間をかけずに診察に集中でき、また患者さんから医師に口頭で追加説明しなくても希望通りに薬をもらえる、というフローに変更されたことが医療機関と患者のメリット だと思ってます。 同時予約機能のリリース前後でのフローの違い もう一つのドメインである調剤薬局については、前述のように診察の予約をする時に患者さんがメドレーのサービスである Pharms を使っている薬局から事前指定をできますので、 オンライン診療後に発行された処方箋の流入が増加します 。 調剤薬局の売り上げは処方箋の枚数 × 単価で大部分が決まりますので、この枚数を増やせるという観点では薬局にとってインパクトのある機能だと思っています。 ── 患者の体験も本当に良くなるし、患者と医療機関の無駄なコミュニケーションも減り、かつ薬局に対しても処方箋枚数が増えて、導線も楽に使えるようになっているというのが、今回のプロジェクトの肝になっている感じですね。これらを踏まえ、プロダクト間を横断して開発しないといけないというのが大変そうです。 開発プロジェクトについて ── どのようなチームがこの横断プロジェクトに関わっていたかを教えてください。 江藤 : 開発側で言うと４つのドメインになってます。 調剤、患者、医科、そして 患者統合基盤 です。患者統合基盤とは医療 PF の各ドメインに存在する業務システムと患者アプリを繋ぐ根幹となるプロダクトです。 ただ今回の機能は医療機関のオペレーションも変わるため、開発側でのみ完結するプロジェクトではないんですね。 いかに現場の運用に合わせつつ、体験を改善できるか？という視点で考えると、各事業側のカスタマーサクセスチームが重要になります 。特に医科と調剤のカスタマーサクセスチームとは、密に壁打ちをしながら開発を進めていました。 ── 今回のプロジェクトは特に事業部との関係性が重要な鍵だったんですね。 江藤 : そうですね。特に医療現場は業務が逼迫している場面も多いですので、例えば「ワンクリック増えます」「ここでページ遷移が増えます」といったことでも業務への影響が非常に大きくなります。 またオペレーショナルに現場を回している箇所も多く、プロダクト都合で勝手にこの方が良いよね、合理的だよね、と決めてプロダクトを作ってしまうと今までの現場オペレーションが崩れてしまい混乱を招くことがあります。 現場の習慣を理解し、我々が目指す姿と調整しながら最適解を出す のが、必須になってくる業界・業態だと思うので、その調整は事業部ともかなり気を遣ってやっていました。 ── 同時予約 Pj は、開発側がやろうということで始まったプロジェクトなんでしょうか? 江藤 : はい。これはメドレーのどのプロダクトもそうなのですが、事業責任者とプロダクト責任者がそれぞれおり、事業と開発の両観点から議論し、事業方針を決めていく、という体制をとっています。 Pharms を正しく成長させていくという観点で見ると、現フェーズでは処方箋をしっかりと調剤薬局に届けることが至上命題でした。サービスのあるべき姿とは？という観点で事業と開発両輪でやりましょうという形で決まったものになります。 横断プロジェクトで工夫をしたポイント ── 今回、横断で色々な開発プロダクトが関係してきますが、工夫した点とか気をつけた点など、どんなものがありましたか。 江藤 : 一番は各ドメインで追っている事業成果がかなり違っていましたので、その調整を時間をかけて擦り合わせした点です。 例えば、調剤の観点では処方箋をちゃんと薬局に届けるというのが、すごく重要な事業インパクトの大きい項目である一方で、医療の観点で見た時に、もちろん手間を減らすのはすごい重要ではあるんですが、医療ドメインとしてその改善に調剤と同規模のメリットを見出してもらえるかと言うと当然そうではなかったりします。 こうした部分で、ドメイン間でこのプロジェクトを達成した後に得られるメリットに差分が出てきます。メリットが大きい事業からしたら工数も大きく割けるのですが、メリットが弱い事業では同じだけ工数かけてやりましょう、という意思決定は難しいと思います。 そこで 本 Pj を通じて各ドメインではどういう事業成果を生むのか、そのために何の KPI を追うのか、を明確にしました 。事業的なメリットが多い調剤のために手伝ってくださいという形ではなく、各ドメインでどういうメリットを生んでいきますか？というところを揃えきるのが、すごく重要だったと思っています。 これを怠ると、メリットの弱い事業にとってはお手伝いみたいなプロジェクトになります。単純にエンジニアリングという部分でも面白いものにならないですよね。ですので、関係する全員でプロジェクトを実施することでどういう結果を得るのか?をちゃんと各ドメイン間で揃えました。 ── なるほど。そうするとそうした擦り合わせは江藤さんと酒井さんがやっていたんでしょうか。 酒井 : はい、僕のほうで行っていました。僕が初期のすり合わせ時に重視していたのは、スコープを適切に区切るという部分でした。調剤側の提供価値の最大化だけを追って初期から大きな機能追加を行うのではなく、変更による医科・患者・調剤へ与えるリスクや開発コストを抑えつつ、価値を最大化できる落とし所はどこか、という部分から刷り合わせしていきました。 メドレーが面白いなって思うのが、プロダクト単独で動いていくわけではなくて、 ペイシェントジャーニー(患者体験)を中心としてプロタクト群が存在しているところ です。 患者体験をより良く構築するためにそれぞれのプロダクトが動いていけるので、お手伝いというニュアンスじゃなく、プロダクトを超えてここはよくしていきましょうと言える文化があるところがいい部分かなと思いますし、やりがいがある部分かなと思います。 江藤 : 特に横断のプロジェクトだとこうした目的意識の統一に一番時間を使っても良いんじゃないかと考えています。ここが決まりさえすれば、後々迷った場合も目的に即した意思決定ができますし。ここを固めた後に各ドメインでの調整するという順番が大事だと思います。 ── 技術面で気をつけたポイントはどんなものがあったんでしょうか。 有馬 : 同時予約機能としてやりたいことはありつつ、診療所側の業務フローや患者の導線、今あるシステムの制約などを踏まえ、どのような形に落とし込めば 診療所も薬局も患者にとっても価値のある機能となるか がポイントです。 ですので、技術的な面と事業的な面を併せて考えながら、システム全体の要件を決めていくというのが最初に手がけた部分でした。 ── 機能を考える上で、全体を見据えた設計などをやっていくと思うんですが、今回はどこから着手されたんでしょうか?患者の導線だったり医療機関の業務フローなど把握した後に、取りかかった部分を聞きたいのですが。 有馬 : 同時予約におけるシステム全体の要件を固めていくと同時に、全体のシーケンスとステートマシンを作っていきました。各システム間の連携フローと、それにより生み出される予約や処方箋といったエンティティの状態遷移を決めていき、この状態の時はこういったことはできないとか、そういった辻褄を合わせるところをしっかりやっていったという感じですかね。 酒井 : 今回は、特に プロダクト横断の共通基盤として、各プロダクトでそれぞれ全く別物の仕組みやステータスを保有しているのを、共通化・抽象化するという業務が必要になる ので、すごく難しいし、難易度が高い部分だなと思っているんですけど、それを綺麗にシーケンス図に落とし込んだ有馬さんが凄いなと思いました。 江藤 : 基盤側で作っていただいたシーケンス図は UX の骨組みなんですよね。そこをいわゆる UX デザイナーが別途やるといった細分化をせず、実装の制限を加味しつつ、正しく運用を回すために、この体験を作るためにこのステータス遷移であるべきだよね、という部分を有馬さんがエンジニア観点で最初に作ってくれてるというのが、 メドレーのエンジニアのとても良い部分 だと思っています。技術だけでなく UX などにも必要であれば越境していける文化ですね。 同時予約 Pj 開発の実際 ── そうした初期フェーズを経て Pharms と CLINICS どちらの開発にも関わった小田さんに聞きたいのが、開発の流れの中でいわゆるリソース的な問題って大変だったと思うのですが、そこはどう解決したんでしょうか。 小田 : 先に Pharms 側の機能 を作ってその後に CLINICS の仕様を決めてもらってから CLINICS の開発に入る流れだったので開発が並行することはなかったです。ただ Pharms ではリードエンジニアという立場なので 、CLINICS の開発に入るための準備と、Pharms 側のレビューやフォローのリソース配分は自分で考えて、各タスクを実施する時間とタイミングを調整しながらやっていました。 一方で、この体制でも進めることができたのは Pharms チームの各メンバーが既に自走できる状態にあったので、そこに支えられたからこそできた かなと思ってます。 ── プロダクトも越境しながら開発するという文化はすごく良いと思ったのですが、ここはフローなどあったりしたんですか? 江藤 : 先程も話した通り Pharms として本プロジェクトの優先度は高かったのですが、CLINICS の事業計画やリソースを踏まえると医科側の実装着手が大きく遅れそうな見立てでした。そこで、小田さんを 医科側の開発にもアサインできたらリソース問題が解決できるのではと調整しました。医科側のエンジニアからのフォローアップは必要なので、その調整もしつつですが、開発を早められるなら良し、と開発チーム間で最終的に判断しました。 酒井 : 今まで触ってなかった CLINICS のシステムにも小田さんはガンガン切り込んでくださったので、元々 CLINICS の開発をやってたのではと思うくらいキャッチアップが早かったです。 ── プロダクトのグロースのためにリソース調整を成功させたという形だったんですね。プロダクト間の越境がしやすいような文化だったり、プロジェクトを成功させようという目線合わせが自然にできるのは良いですね。 チーム間という話でいえば QA は各チームに跨っての活動だと思いますが、その観点ではいかがですか? 小島 : 自分は開発が終盤に入ったタイミングでプロジェクトに合流しました。それまでは米山さんが QA として入っていたのですが、医科側でも検証すべきテスト観点が多数あった背景もあり、医科側の QA をメインで見る担当として参画しました。 後半に参画した背景もあり、そもそも処方箋送付という業務や Pharms プロダクトの仕様理解も浅い…という状態でしたが、 開発目的・要件定義・設計が詳細にドキュメント化されていたので、スムーズに検証に入ることができました 。検証の中で QA エンジニアとしても「この部分の仕様は見直した方が良くなる」というポイントがいくつか出てきたので、仕様の改善提案も行いました。後発参加でしたが、実際に取り入れてもらった改善も多いです。 メドレーのプロダクト開発の文化として QA エンジニアも 要件定義からレビューに参加したり、意見を言いつつプロダクトをより良くするための改善が行える ので、とても働きやすいですね。 ── 後から入っても動きやすいというのは、ドキュメントなどが整備されているからできたことだというのが分かりますね。横断プロジェクトだからこそ気がついた他のチームの良い点などあったりしますか? 酒井 : Pharms のプロジェクトってやりやすいな、と思ったのが KPI 設計がすごく明確なところだったという点でした。 色々紆余曲折あった結果ここに辿り着いてるという苦労を知ってはいるんですけど、今の KPI 設計ってやっぱりすごくシンプル で処方箋送信数ですとなると、そこから逆算した KPI を各 PF に振ればいいと言う体制だったので、すごくこれはやりやすかったポイントの一つかなと思います。 話す論点も結局そこっていう部分がすごくコミュニケーションコストが安くすんだ部分ではあるかなと思いました。 横断プロジェクトならではのエンジニアリング ── 全体の話から個別のドメインごとのエンジニアリングという点ではどのようなことをされていましたか? 小田 : 基本的には有馬さんのシーケンス図を元に開発を進めていました。CLINICS では A という状態になる、その時に B というアクションがあると Pharms では C という状態になるというように状態遷移が複雑だったため、設計時にあるべき姿に迷うことが多かったのですが、シーケンスに立ち返るとすぐにその疑問が解決するといった具合です。 有馬 : シーケンスの整合性や難しくなりすぎないように設計する ことには気をつけました。「同時予約」という言葉が先行するとついつい複雑な新機能のようなものを作りがちですが、診療所や薬局の予約機能、処方箋送信機能といった個々のパーツはもともとあるわけで、なるべくシンプルにそれらをつなぎ合わせられるように心がけました。 江藤 : 細かいプロダクト間の調整が必要になるので ちゃんと調剤の欲しい KPI も求めつつ、かつ現場のオペレーション品質を落とさないっていう観点で調整を各ドメインでやりました。 工夫したことでいうと、UX 調査を徹底したところでしょうか。 今回のサービスって業界的にみた時に新しいかというとそうではないんですよね。ですので、同業界の企業さんの各アプリの体験とか、自分でも結構色々使いながら体験してみましたし、それらをベースに逆に現状のうちの仕様を踏まえると、こういう風にうちでは実装しましょうみたいなところを色々やっていました。 小田 : エンジニアリングの観点でいうと、特に患者アプリチームとの API 連携の仕様調整と、開発の進め方は密に連携しながら進めました。先にこっちができてないと向こうも開発できない状態になるので、担当者同士でコミュニケーションとりつつ、工夫しながら進めていました。 酒井 : CLINICS で気にしてた部分はどちらかというと リスクとコストの部分、いかに最小化して価値を最大化するかが一番重要 かなと思っていたので、一番大事なのはやっぱり医科にとってどういう価値が出て、医科にとってどういうリスクが発生するかを考えてました。 例えば一番最初のすり合わせで薬局予約する時に日時まで確定させましょうという話もあったんですけど、そこまでスコープを広げなくてもメリットが出るのであれば、広げたくないですという話をしていました。 あとはリリースプランの策定とかかな？全医療機関に一斉に出すのではなく、まずは一部医療機関様だけに公開するリリース方式にしましょうみたいなところも含めてですかね。医科側で一旦テストをやって検証して、スムーズに機能が使えるところを確認したりするステップを設けましょうと安全策を取りながら進めました。 これはこのプロジェクトに関わらず、どんなプロジェクトでも一番重要でそこが後からひっくり返るのが一番手戻りになってくるので、そこは重要かなと思いながら進めてましたね。 小島 : QA 視点だと横断プロジェクトゆえにステートが本当に複雑で、メドレー入社後に経験したプロジェクトの中で検証の難易度が最も高かったですね。 ですが、皆さん仰られているように各ユースケースに対する設計が図でドキュメント化されていたので、テストケースとして転用できた部分も多くありました。有馬さんが作成した設計図があったからこそ漏れなくテストできた部分は大きいです。大勢が参加するプロジェクトにおいて、全員が認識合わせる上でも設計図は本当に大事だなと痛感しました。 工夫した点としては、小田さんは Pharms 開発のドメイン知識が豊富だったので、QA 時は Pharms 側をメインに見てもらいつつ、自分は CLINICS 側の QA を手厚く見るようにしました。どちらのドメインにも関係する契約プラン等の複雑な仕様は自分が担当しました。 QA 以外の面だと、リリースする上で必要な浮いたボールがあれば積極的に取りにいくようにしました。 例えば、これまで一部の医療機関様だけに機能リリースする場合、その後のフィードバック回収はメールや面談で個別に行っていましたが、日々の診療の中でお時間を確保頂くのが難しいという状況がありました。その結果、本 Pj においても全体リリースして問題ないか？の判断がしづらい時期がありました。 そこで Google フォームでアンケートを作成して短時間で回答できる形に切り替えました。結果的に 100% 回答を得ることができました。 アンケート結果から「従来機能より価値があり、院内オペレーションに組み込んで頂くコストもそこまで高くない」という点が評価できたので、自信を持って全体公開リリースに向けて GO 判定できました。** メドレーは役割に縛られずボールを任せて頂ける環境があるので、自分の専門領域以外のことも学べている**と思うことが多いです。 幸いリリース後も大きな不具合はないのでこれはもう皆さんのおかげですね。 同時予約 Pj を終えて ── では最後にこのプロジェクトの総括をしていだければ。 江藤 : 横断ではあるけど各ドメインでそれぞれのプロフェッショナルがちゃんと力を発揮してプロジェクトをやり切れたというのはすごく大きい資産でした。 医療 PF はアセットをたくさん持っているので、色々組み合わせると、他の会社だとできないけど、うちならできそうだね、みたいなことが色々ある んです。 なので、この後も横断プロジェクトは予定されていますが、それに先駆けてひとつやりきって、かつ僕らが欲しかった期待成果を現状出せているところを含めるとすごく良い一歩だったのかな、と思ってます。 次は品質を担保しつつ、もっとスピードを上げていきたいというのが観点として大きいですね。 ── なるほど。こうした横断プロジェクトもやっていく医療 PF ではどんなエンジニアがマッチするポイントでしょう? 有馬 : 技術と併せてユーザーへの価値提供も考えながらエンジニアリングしたい人がマッチするのではないかと思います。 ── 各プロダクトの持っている役割を踏まえて、俯瞰の視点で開発もしたいという方にはすごく魅力的ですね。本日はありがとうございました。 さいごに 同時予約 Pj について、プロジェクトを推進したメンバーに話を聞きましたが、複雑な要件を実現可能な形にして各チームで垣根を越えて開発をしている様子がとても印象的でした。特に医療 PF ではドメイン同士で有機的に結合していき、コラボレーションすることによりステークホルダーへの価値を高めているというのは、やりがいがあるのではないかと感じます。 このようなプロジェクトで力を発揮したいと思った方はぜひ、お気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの古川です。 今回は CLINICS / Pharms 同時予約プロジェクト(以下、同時予約 Pj)というプロダクト横断で様々な部署が関わった開発プロジェクトについて、尽力された皆さんに座談会形式でお話を伺いました。 メドレーの医療プラットフォーム(以下、医療 PF)でどのようにこうした横断プロジェクトを完遂したのかの様子を皆さんに知ってもらえればと思います。 対談メンバー紹介 ── はじめに、皆さんの自己紹介をお願いします。 江藤 : 所属は医療 PF のプロダクト開発室の Pharms 開発チームです。 役割としては調剤薬局向けのシステムの Pharms のプロダクトオーナーを担っています。 経歴としては、2021 年の 1 月から Pharms のカスタマーサクセスとしてメドレーにジョインしまして、2023 年 1 月から開発チームに来ました。 これまでは事業側の経験が長く、営業全般や事業開発をメインでやってきたキャリアです。 このプロジェクトの PO としてリードする動きをしており、Pharms が担う調剤側のリードに加えて、全体の旗振りや調整等を主軸にやっていました。 江藤さん ── 江藤さんがプロジェクトの中心となって推進したんですね。 江藤 : 調剤ドメインの Pharms にとって事業インパクトがすごく大きい開発だったので、調剤ドメインが責任持ってやりましょう、という整理です。 小田 : 自分の所属も江藤さんと同じになります。 経歴は、2021 年 7 月にエンジニアとして入社し、これまでずっと Pharms の開発をやってます。 入社後はクライアント認証機能や法人担当者向けの本部機能などの機能開発を行ってきました。 昨年から Pharms のリードエンジニアとしてチーム全体を見つつ、Pharms の技術責任者として江藤さんと両輪で動くような形でプロジェクトの推進に関わっています。 小田さん 有馬 : 医療 PF プロダクト開発室、患者統合基盤チームに所属しています。患者統合基盤とは、CLINICS（患者アプリ）というアプリのバックエンドシステムであり、診療所や歯科医院、薬局向けのシステムとの連携基盤としても機能しているプロダクトになります。 経歴は、このメンバーの中では一番古く 2018 年 3 月に入社して、当初は CLINICS カルテの機能拡張の開発に参加し、PKI 基盤や CLINICS エージェントを始めとした他社システムとの連携基盤の開発を行っていました。2020 年くらいから患者統合基盤の立ち上げに参加して、現在に至ります。 有馬さん 酒井 : 入社は 2019 年 8 月なので、 5 年目となります。 デザイナーとして入社後 1 年間はジョブメドレーに在籍していました。その後オンライン診療が伸びてきた時期になり、CLINICS 側のデザイナーの人数が足りなくなったことがありまして、そこからは電子カルテを含めた CLINICS のデザイン全般を担当していました。去年から電子カルテ以外の業務領域の PdM として活動しています。軸足はデザイナーなのですがプロダクトのマネジメントみたいなこともし始めてます。 このプロジェクトにおいては、さっき江藤さんがおっしゃった通り、Pharms の価値向上が中心のプロジェクトなのでプロジェクトの一番大きいリードは江藤さんになるかと思うんですけど、CLINICS などの医科側のプロジェクトリードと言う立ち位置が僕になるかなと思います。 酒井さん 小島 : 医療 PF プロダクト開発室の QA グループに所属しています。QA グループのマネージャである 米山 さんのご紹介で 2022 年 4 月にメドレー３人目の QA エンジニアとして入社しました。主担当は CLINICS の予約機能を中心とした周辺領域です。ここまで酒井さんと一緒に働かせて頂く機会が多く、直近では予約方法を拡張する「リクエスト予約」機能の QA を担当しました。 同時予約に関しては、主に医科側の部分の QA から始まり、調剤側の QA も必要ということになり、最終的には全体の QA を担当しました。 小島さん 同時予約の機能や解決した課題 ── ありがとうございます。次に、今回の同時予約についてどういった機能で、どういった課題を解決するべきかをお話しいただきたいです。 江藤 : 機能としては、 CLINICS（患者アプリ）からオンライン診療を予約する際に、薬の受け取り先として薬局を事前指定できる機能 になっています。 この機能に関係するドメインは患者・医療機関・調剤薬局の３つです。 患者と医療機関のメリットとしては、薬の処方までの手間が減ることです。 オンライン診療では、患者が医療機関に直接訪問するわけではないので、薬を直接薬局に行って受け取るのか、薬局から配送を希望するのかといった薬の受け取り方を、医療機関と患者さんで口頭で話して決めてもらっており、確認に手間が発生していました。患者さんは口頭で話した内容に沿って、オンライン診療終了後に、薬局への予約を取っていました。 同時予約機能が実装されたことにより、診察の予約時にどの薬局でどういう受け取り方をしますという部分を患者さんが事前指定できるようになったので、 医療機関は事務的な話に時間をかけずに診察に集中でき、また患者さんから医師に口頭で追加説明しなくても希望通りに薬をもらえる、というフローに変更されたことが医療機関と患者のメリット だと思ってます。 同時予約機能のリリース前後でのフローの違い もう一つのドメインである調剤薬局については、前述のように診察の予約をする時に患者さんがメドレーのサービスである Pharms を使っている薬局から事前指定をできますので、 オンライン診療後に発行された処方箋の流入が増加します 。 調剤薬局の売り上げは処方箋の枚数 × 単価で大部分が決まりますので、この枚数を増やせるという観点では薬局にとってインパクトのある機能だと思っています。 ── 患者の体験も本当に良くなるし、患者と医療機関の無駄なコミュニケーションも減り、かつ薬局に対しても処方箋枚数が増えて、導線も楽に使えるようになっているというのが、今回のプロジェクトの肝になっている感じですね。これらを踏まえ、プロダクト間を横断して開発しないといけないというのが大変そうです。 開発プロジェクトについて ── どのようなチームがこの横断プロジェクトに関わっていたかを教えてください。 江藤 : 開発側で言うと４つのドメインになってます。 調剤、患者、医科、そして 患者統合基盤 です。患者統合基盤とは医療 PF の各ドメインに存在する業務システムと患者アプリを繋ぐ根幹となるプロダクトです。 ただ今回の機能は医療機関のオペレーションも変わるため、開発側でのみ完結するプロジェクトではないんですね。 いかに現場の運用に合わせつつ、体験を改善できるか？という視点で考えると、各事業側のカスタマーサクセスチームが重要になります 。特に医科と調剤のカスタマーサクセスチームとは、密に壁打ちをしながら開発を進めていました。 ── 今回のプロジェクトは特に事業部との関係性が重要な鍵だったんですね。 江藤 : そうですね。特に医療現場は業務が逼迫している場面も多いですので、例えば「ワンクリック増えます」「ここでページ遷移が増えます」といったことでも業務への影響が非常に大きくなります。 またオペレーショナルに現場を回している箇所も多く、プロダクト都合で勝手にこの方が良いよね、合理的だよね、と決めてプロダクトを作ってしまうと今までの現場オペレーションが崩れてしまい混乱を招くことがあります。 現場の習慣を理解し、我々が目指す姿と調整しながら最適解を出す のが、必須になってくる業界・業態だと思うので、その調整は事業部ともかなり気を遣ってやっていました。 ── 同時予約 Pj は、開発側がやろうということで始まったプロジェクトなんでしょうか? 江藤 : はい。これはメドレーのどのプロダクトもそうなのですが、事業責任者とプロダクト責任者がそれぞれおり、事業と開発の両観点から議論し、事業方針を決めていく、という体制をとっています。 Pharms を正しく成長させていくという観点で見ると、現フェーズでは処方箋をしっかりと調剤薬局に届けることが至上命題でした。サービスのあるべき姿とは？という観点で事業と開発両輪でやりましょうという形で決まったものになります。 横断プロジェクトで工夫をしたポイント ── 今回、横断で色々な開発プロダクトが関係してきますが、工夫した点とか気をつけた点など、どんなものがありましたか。 江藤 : 一番は各ドメインで追っている事業成果がかなり違っていましたので、その調整を時間をかけて擦り合わせした点です。 例えば、調剤の観点では処方箋をちゃんと薬局に届けるというのが、すごく重要な事業インパクトの大きい項目である一方で、医療の観点で見た時に、もちろん手間を減らすのはすごい重要ではあるんですが、医療ドメインとしてその改善に調剤と同規模のメリットを見出してもらえるかと言うと当然そうではなかったりします。 こうした部分で、ドメイン間でこのプロジェクトを達成した後に得られるメリットに差分が出てきます。メリットが大きい事業からしたら工数も大きく割けるのですが、メリットが弱い事業では同じだけ工数かけてやりましょう、という意思決定は難しいと思います。 そこで 本 Pj を通じて各ドメインではどういう事業成果を生むのか、そのために何の KPI を追うのか、を明確にしました 。事業的なメリットが多い調剤のために手伝ってくださいという形ではなく、各ドメインでどういうメリットを生んでいきますか？というところを揃えきるのが、すごく重要だったと思っています。 これを怠ると、メリットの弱い事業にとってはお手伝いみたいなプロジェクトになります。単純にエンジニアリングという部分でも面白いものにならないですよね。ですので、関係する全員でプロジェクトを実施することでどういう結果を得るのか?をちゃんと各ドメイン間で揃えました。 ── なるほど。そうするとそうした擦り合わせは江藤さんと酒井さんがやっていたんでしょうか。 酒井 : はい、僕のほうで行っていました。僕が初期のすり合わせ時に重視していたのは、スコープを適切に区切るという部分でした。調剤側の提供価値の最大化だけを追って初期から大きな機能追加を行うのではなく、変更による医科・患者・調剤へ与えるリスクや開発コストを抑えつつ、価値を最大化できる落とし所はどこか、という部分から刷り合わせしていきました。 メドレーが面白いなって思うのが、プロダクト単独で動いていくわけではなくて、 ペイシェントジャーニー(患者体験)を中心としてプロタクト群が存在しているところ です。 患者体験をより良く構築するためにそれぞれのプロダクトが動いていけるので、お手伝いというニュアンスじゃなく、プロダクトを超えてここはよくしていきましょうと言える文化があるところがいい部分かなと思いますし、やりがいがある部分かなと思います。 江藤 : 特に横断のプロジェクトだとこうした目的意識の統一に一番時間を使っても良いんじゃないかと考えています。ここが決まりさえすれば、後々迷った場合も目的に即した意思決定ができますし。ここを固めた後に各ドメインでの調整するという順番が大事だと思います。 ── 技術面で気をつけたポイントはどんなものがあったんでしょうか。 有馬 : 同時予約機能としてやりたいことはありつつ、診療所側の業務フローや患者の導線、今あるシステムの制約などを踏まえ、どのような形に落とし込めば 診療所も薬局も患者にとっても価値のある機能となるか がポイントです。 ですので、技術的な面と事業的な面を併せて考えながら、システム全体の要件を決めていくというのが最初に手がけた部分でした。 ── 機能を考える上で、全体を見据えた設計などをやっていくと思うんですが、今回はどこから着手されたんでしょうか?患者の導線だったり医療機関の業務フローなど把握した後に、取りかかった部分を聞きたいのですが。 有馬 : 同時予約におけるシステム全体の要件を固めていくと同時に、全体のシーケンスとステートマシンを作っていきました。各システム間の連携フローと、それにより生み出される予約や処方箋といったエンティティの状態遷移を決めていき、この状態の時はこういったことはできないとか、そういった辻褄を合わせるところをしっかりやっていったという感じですかね。 酒井 : 今回は、特に プロダクト横断の共通基盤として、各プロダクトでそれぞれ全く別物の仕組みやステータスを保有しているのを、共通化・抽象化するという業務が必要になる ので、すごく難しいし、難易度が高い部分だなと思っているんですけど、それを綺麗にシーケンス図に落とし込んだ有馬さんが凄いなと思いました。 江藤 : 基盤側で作っていただいたシーケンス図は UX の骨組みなんですよね。そこをいわゆる UX デザイナーが別途やるといった細分化をせず、実装の制限を加味しつつ、正しく運用を回すために、この体験を作るためにこのステータス遷移であるべきだよね、という部分を有馬さんがエンジニア観点で最初に作ってくれてるというのが、 メドレーのエンジニアのとても良い部分 だと思っています。技術だけでなく UX などにも必要であれば越境していける文化ですね。 同時予約 Pj 開発の実際 ── そうした初期フェーズを経て Pharms と CLINICS どちらの開発にも関わった小田さんに聞きたいのが、開発の流れの中でいわゆるリソース的な問題って大変だったと思うのですが、そこはどう解決したんでしょうか。 小田 : 先に Pharms 側の機能 を作ってその後に CLINICS の仕様を決めてもらってから CLINICS の開発に入る流れだったので開発が並行することはなかったです。ただ Pharms ではリードエンジニアという立場なので 、CLINICS の開発に入るための準備と、Pharms 側のレビューやフォローのリソース配分は自分で考えて、各タスクを実施する時間とタイミングを調整しながらやっていました。 一方で、この体制でも進めることができたのは Pharms チームの各メンバーが既に自走できる状態にあったので、そこに支えられたからこそできた かなと思ってます。 ── プロダクトも越境しながら開発するという文化はすごく良いと思ったのですが、ここはフローなどあったりしたんですか? 江藤 : 先程も話した通り Pharms として本プロジェクトの優先度は高かったのですが、CLINICS の事業計画やリソースを踏まえると医科側の実装着手が大きく遅れそうな見立てでした。そこで、小田さんを 医科側の開発にもアサインできたらリソース問題が解決できるのではと調整しました。医科側のエンジニアからのフォローアップは必要なので、その調整もしつつですが、開発を早められるなら良し、と開発チーム間で最終的に判断しました。 酒井 : 今まで触ってなかった CLINICS のシステムにも小田さんはガンガン切り込んでくださったので、元々 CLINICS の開発をやってたのではと思うくらいキャッチアップが早かったです。 ── プロダクトのグロースのためにリソース調整を成功させたという形だったんですね。プロダクト間の越境がしやすいような文化だったり、プロジェクトを成功させようという目線合わせが自然にできるのは良いですね。 チーム間という話でいえば QA は各チームに跨っての活動だと思いますが、その観点ではいかがですか? 小島 : 自分は開発が終盤に入ったタイミングでプロジェクトに合流しました。それまでは米山さんが QA として入っていたのですが、医科側でも検証すべきテスト観点が多数あった背景もあり、医科側の QA をメインで見る担当として参画しました。 後半に参画した背景もあり、そもそも処方箋送付という業務や Pharms プロダクトの仕様理解も浅い…という状態でしたが、 開発目的・要件定義・設計が詳細にドキュメント化されていたので、スムーズに検証に入ることができました 。検証の中で QA エンジニアとしても「この部分の仕様は見直した方が良くなる」というポイントがいくつか出てきたので、仕様の改善提案も行いました。後発参加でしたが、実際に取り入れてもらった改善も多いです。 メドレーのプロダクト開発の文化として QA エンジニアも 要件定義からレビューに参加したり、意見を言いつつプロダクトをより良くするための改善が行える ので、とても働きやすいですね。 ── 後から入っても動きやすいというのは、ドキュメントなどが整備されているからできたことだというのが分かりますね。横断プロジェクトだからこそ気がついた他のチームの良い点などあったりしますか? 酒井 : Pharms のプロジェクトってやりやすいな、と思ったのが KPI 設計がすごく明確なところだったという点でした。 色々紆余曲折あった結果ここに辿り着いてるという苦労を知ってはいるんですけど、今の KPI 設計ってやっぱりすごくシンプル で処方箋送信数ですとなると、そこから逆算した KPI を各 PF に振ればいいと言う体制だったので、すごくこれはやりやすかったポイントの一つかなと思います。 話す論点も結局そこっていう部分がすごくコミュニケーションコストが安くすんだ部分ではあるかなと思いました。 横断プロジェクトならではのエンジニアリング ── 全体の話から個別のドメインごとのエンジニアリングという点ではどのようなことをされていましたか? 小田 : 基本的には有馬さんのシーケンス図を元に開発を進めていました。CLINICS では A という状態になる、その時に B というアクションがあると Pharms では C という状態になるというように状態遷移が複雑だったため、設計時にあるべき姿に迷うことが多かったのですが、シーケンスに立ち返るとすぐにその疑問が解決するといった具合です。 有馬 : シーケンスの整合性や難しくなりすぎないように設計する ことには気をつけました。「同時予約」という言葉が先行するとついつい複雑な新機能のようなものを作りがちですが、診療所や薬局の予約機能、処方箋送信機能といった個々のパーツはもともとあるわけで、なるべくシンプルにそれらをつなぎ合わせられるように心がけました。 江藤 : 細かいプロダクト間の調整が必要になるので ちゃんと調剤の欲しい KPI も求めつつ、かつ現場のオペレーション品質を落とさないっていう観点で調整を各ドメインでやりました。 工夫したことでいうと、UX 調査を徹底したところでしょうか。 今回のサービスって業界的にみた時に新しいかというとそうではないんですよね。ですので、同業界の企業さんの各アプリの体験とか、自分でも結構色々使いながら体験してみましたし、それらをベースに逆に現状のうちの仕様を踏まえると、こういう風にうちでは実装しましょうみたいなところを色々やっていました。 小田 : エンジニアリングの観点でいうと、特に患者アプリチームとの API 連携の仕様調整と、開発の進め方は密に連携しながら進めました。先にこっちができてないと向こうも開発できない状態になるので、担当者同士でコミュニケーションとりつつ、工夫しながら進めていました。 酒井 : CLINICS で気にしてた部分はどちらかというと リスクとコストの部分、いかに最小化して価値を最大化するかが一番重要 かなと思っていたので、一番大事なのはやっぱり医科にとってどういう価値が出て、医科にとってどういうリスクが発生するかを考えてました。 例えば一番最初のすり合わせで薬局予約する時に日時まで確定させましょうという話もあったんですけど、そこまでスコープを広げなくてもメリットが出るのであれば、広げたくないですという話をしていました。 あとはリリースプランの策定とかかな？全医療機関に一斉に出すのではなく、まずは一部医療機関様だけに公開するリリース方式にしましょうみたいなところも含めてですかね。医科側で一旦テストをやって検証して、スムーズに機能が使えるところを確認したりするステップを設けましょうと安全策を取りながら進めました。 これはこのプロジェクトに関わらず、どんなプロジェクトでも一番重要でそこが後からひっくり返るのが一番手戻りになってくるので、そこは重要かなと思いながら進めてましたね。 小島 : QA 視点だと横断プロジェクトゆえにステートが本当に複雑で、メドレー入社後に経験したプロジェクトの中で検証の難易度が最も高かったですね。 ですが、皆さん仰られているように各ユースケースに対する設計が図でドキュメント化されていたので、テストケースとして転用できた部分も多くありました。有馬さんが作成した設計図があったからこそ漏れなくテストできた部分は大きいです。大勢が参加するプロジェクトにおいて、全員が認識合わせる上でも設計図は本当に大事だなと痛感しました。 工夫した点としては、小田さんは Pharms 開発のドメイン知識が豊富だったので、QA 時は Pharms 側をメインに見てもらいつつ、自分は CLINICS 側の QA を手厚く見るようにしました。どちらのドメインにも関係する契約プラン等の複雑な仕様は自分が担当しました。 QA 以外の面だと、リリースする上で必要な浮いたボールがあれば積極的に取りにいくようにしました。 例えば、これまで一部の医療機関様だけに機能リリースする場合、その後のフィードバック回収はメールや面談で個別に行っていましたが、日々の診療の中でお時間を確保頂くのが難しいという状況がありました。その結果、本 Pj においても全体リリースして問題ないか？の判断がしづらい時期がありました。 そこで Google フォームでアンケートを作成して短時間で回答できる形に切り替えました。結果的に 100% 回答を得ることができました。 アンケート結果から「従来機能より価値があり、院内オペレーションに組み込んで頂くコストもそこまで高くない」という点が評価できたので、自信を持って全体公開リリースに向けて GO 判定できました。** メドレーは役割に縛られずボールを任せて頂ける環境があるので、自分の専門領域以外のことも学べている**と思うことが多いです。 幸いリリース後も大きな不具合はないのでこれはもう皆さんのおかげですね。 同時予約 Pj を終えて ── では最後にこのプロジェクトの総括をしていだければ。 江藤 : 横断ではあるけど各ドメインでそれぞれのプロフェッショナルがちゃんと力を発揮してプロジェクトをやり切れたというのはすごく大きい資産でした。 医療 PF はアセットをたくさん持っているので、色々組み合わせると、他の会社だとできないけど、うちならできそうだね、みたいなことが色々ある んです。 なので、この後も横断プロジェクトは予定されていますが、それに先駆けてひとつやりきって、かつ僕らが欲しかった期待成果を現状出せているところを含めるとすごく良い一歩だったのかな、と思ってます。 次は品質を担保しつつ、もっとスピードを上げていきたいというのが観点として大きいですね。 ── なるほど。こうした横断プロジェクトもやっていく医療 PF ではどんなエンジニアがマッチするポイントでしょう? 有馬 : 技術と併せてユーザーへの価値提供も考えながらエンジニアリングしたい人がマッチするのではないかと思います。 ── 各プロダクトの持っている役割を踏まえて、俯瞰の視点で開発もしたいという方にはすごく魅力的ですね。本日はありがとうございました。 さいごに 同時予約 Pj について、プロジェクトを推進したメンバーに話を聞きましたが、複雑な要件を実現可能な形にして各チームで垣根を越えて開発をしている様子がとても印象的でした。特に医療 PF ではドメイン同士で有機的に結合していき、コラボレーションすることによりステークホルダーへの価値を高めているというのは、やりがいがあるのではないかと感じます。 このようなプロジェクトで力を発揮したいと思った方はぜひ、お気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの古川です。 今回は CLINICS / Pharms 同時予約プロジェクト(以下、同時予約 Pj)というプロダクト横断で様々な部署が関わった開発プロジェクトについて、尽力された皆さんに座談会形式でお話を伺いました。 メドレーの医療プラットフォーム(以下、医療 PF)でどのようにこうした横断プロジェクトを完遂したのかの様子を皆さんに知ってもらえればと思います。 対談メンバー紹介 ── はじめに、皆さんの自己紹介をお願いします。 江藤 : 所属は医療 PF のプロダクト開発室の Pharms 開発チームです。 役割としては調剤薬局向けのシステムの Pharms のプロダクトオーナーを担っています。 経歴としては、2021 年の 1 月から Pharms のカスタマーサクセスとしてメドレーにジョインしまして、2023 年 1 月から開発チームに来ました。 これまでは事業側の経験が長く、営業全般や事業開発をメインでやってきたキャリアです。 このプロジェクトの PO としてリードする動きをしており、Pharms が担う調剤側のリードに加えて、全体の旗振りや調整等を主軸にやっていました。 江藤さん ── 江藤さんがプロジェクトの中心となって推進したんですね。 江藤 : 調剤ドメインの Pharms にとって事業インパクトがすごく大きい開発だったので、調剤ドメインが責任持ってやりましょう、という整理です。 小田 : 自分の所属も江藤さんと同じになります。 経歴は、2021 年 7 月にエンジニアとして入社し、これまでずっと Pharms の開発をやってます。 入社後はクライアント認証機能や法人担当者向けの本部機能などの機能開発を行ってきました。 昨年から Pharms のリードエンジニアとしてチーム全体を見つつ、Pharms の技術責任者として江藤さんと両輪で動くような形でプロジェクトの推進に関わっています。 小田さん 有馬 : 医療 PF プロダクト開発室、患者統合基盤チームに所属しています。患者統合基盤とは、CLINICS（患者アプリ）というアプリのバックエンドシステムであり、診療所や歯科医院、薬局向けのシステムとの連携基盤としても機能しているプロダクトになります。 経歴は、このメンバーの中では一番古く 2018 年 3 月に入社して、当初は CLINICS カルテの機能拡張の開発に参加し、PKI 基盤や CLINICS エージェントを始めとした他社システムとの連携基盤の開発を行っていました。2020 年くらいから患者統合基盤の立ち上げに参加して、現在に至ります。 有馬さん 酒井 : 入社は 2019 年 8 月なので、 5 年目となります。 デザイナーとして入社後 1 年間はジョブメドレーに在籍していました。その後オンライン診療が伸びてきた時期になり、CLINICS 側のデザイナーの人数が足りなくなったことがありまして、そこからは電子カルテを含めた CLINICS のデザイン全般を担当していました。去年から電子カルテ以外の業務領域の PdM として活動しています。軸足はデザイナーなのですがプロダクトのマネジメントみたいなこともし始めてます。 このプロジェクトにおいては、さっき江藤さんがおっしゃった通り、Pharms の価値向上が中心のプロジェクトなのでプロジェクトの一番大きいリードは江藤さんになるかと思うんですけど、CLINICS などの医科側のプロジェクトリードと言う立ち位置が僕になるかなと思います。 酒井さん 小島 : 医療 PF プロダクト開発室の QA グループに所属しています。QA グループのマネージャである 米山 さんのご紹介で 2022 年 4 月にメドレー３人目の QA エンジニアとして入社しました。主担当は CLINICS の予約機能を中心とした周辺領域です。ここまで酒井さんと一緒に働かせて頂く機会が多く、直近では予約方法を拡張する「リクエスト予約」機能の QA を担当しました。 同時予約に関しては、主に医科側の部分の QA から始まり、調剤側の QA も必要ということになり、最終的には全体の QA を担当しました。 小島さん 同時予約の機能や解決した課題 ── ありがとうございます。次に、今回の同時予約についてどういった機能で、どういった課題を解決するべきかをお話しいただきたいです。 江藤 : 機能としては、 CLINICS（患者アプリ）からオンライン診療を予約する際に、薬の受け取り先として薬局を事前指定できる機能 になっています。 この機能に関係するドメインは患者・医療機関・調剤薬局の３つです。 患者と医療機関のメリットとしては、薬の処方までの手間が減ることです。 オンライン診療では、患者が医療機関に直接訪問するわけではないので、薬を直接薬局に行って受け取るのか、薬局から配送を希望するのかといった薬の受け取り方を、医療機関と患者さんで口頭で話して決めてもらっており、確認に手間が発生していました。患者さんは口頭で話した内容に沿って、オンライン診療終了後に、薬局への予約を取っていました。 同時予約機能が実装されたことにより、診察の予約時にどの薬局でどういう受け取り方をしますという部分を患者さんが事前指定できるようになったので、 医療機関は事務的な話に時間をかけずに診察に集中でき、また患者さんから医師に口頭で追加説明しなくても希望通りに薬をもらえる、というフローに変更されたことが医療機関と患者のメリット だと思ってます。 同時予約機能のリリース前後でのフローの違い もう一つのドメインである調剤薬局については、前述のように診察の予約をする時に患者さんがメドレーのサービスである Pharms を使っている薬局から事前指定をできますので、 オンライン診療後に発行された処方箋の流入が増加します 。 調剤薬局の売り上げは処方箋の枚数 × 単価で大部分が決まりますので、この枚数を増やせるという観点では薬局にとってインパクトのある機能だと思っています。 ── 患者の体験も本当に良くなるし、患者と医療機関の無駄なコミュニケーションも減り、かつ薬局に対しても処方箋枚数が増えて、導線も楽に使えるようになっているというのが、今回のプロジェクトの肝になっている感じですね。これらを踏まえ、プロダクト間を横断して開発しないといけないというのが大変そうです。 開発プロジェクトについて ── どのようなチームがこの横断プロジェクトに関わっていたかを教えてください。 江藤 : 開発側で言うと４つのドメインになってます。 調剤、患者、医科、そして 患者統合基盤 です。患者統合基盤とは医療 PF の各ドメインに存在する業務システムと患者アプリを繋ぐ根幹となるプロダクトです。 ただ今回の機能は医療機関のオペレーションも変わるため、開発側でのみ完結するプロジェクトではないんですね。 いかに現場の運用に合わせつつ、体験を改善できるか？という視点で考えると、各事業側のカスタマーサクセスチームが重要になります 。特に医科と調剤のカスタマーサクセスチームとは、密に壁打ちをしながら開発を進めていました。 ── 今回のプロジェクトは特に事業部との関係性が重要な鍵だったんですね。 江藤 : そうですね。特に医療現場は業務が逼迫している場面も多いですので、例えば「ワンクリック増えます」「ここでページ遷移が増えます」といったことでも業務への影響が非常に大きくなります。 またオペレーショナルに現場を回している箇所も多く、プロダクト都合で勝手にこの方が良いよね、合理的だよね、と決めてプロダクトを作ってしまうと今までの現場オペレーションが崩れてしまい混乱を招くことがあります。 現場の習慣を理解し、我々が目指す姿と調整しながら最適解を出す のが、必須になってくる業界・業態だと思うので、その調整は事業部ともかなり気を遣ってやっていました。 ── 同時予約 Pj は、開発側がやろうということで始まったプロジェクトなんでしょうか? 江藤 : はい。これはメドレーのどのプロダクトもそうなのですが、事業責任者とプロダクト責任者がそれぞれおり、事業と開発の両観点から議論し、事業方針を決めていく、という体制をとっています。 Pharms を正しく成長させていくという観点で見ると、現フェーズでは処方箋をしっかりと調剤薬局に届けることが至上命題でした。サービスのあるべき姿とは？という観点で事業と開発両輪でやりましょうという形で決まったものになります。 横断プロジェクトで工夫をしたポイント ── 今回、横断で色々な開発プロダクトが関係してきますが、工夫した点とか気をつけた点など、どんなものがありましたか。 江藤 : 一番は各ドメインで追っている事業成果がかなり違っていましたので、その調整を時間をかけて擦り合わせした点です。 例えば、調剤の観点では処方箋をちゃんと薬局に届けるというのが、すごく重要な事業インパクトの大きい項目である一方で、医療の観点で見た時に、もちろん手間を減らすのはすごい重要ではあるんですが、医療ドメインとしてその改善に調剤と同規模のメリットを見出してもらえるかと言うと当然そうではなかったりします。 こうした部分で、ドメイン間でこのプロジェクトを達成した後に得られるメリットに差分が出てきます。メリットが大きい事業からしたら工数も大きく割けるのですが、メリットが弱い事業では同じだけ工数かけてやりましょう、という意思決定は難しいと思います。 そこで 本 Pj を通じて各ドメインではどういう事業成果を生むのか、そのために何の KPI を追うのか、を明確にしました 。事業的なメリットが多い調剤のために手伝ってくださいという形ではなく、各ドメインでどういうメリットを生んでいきますか？というところを揃えきるのが、すごく重要だったと思っています。 これを怠ると、メリットの弱い事業にとってはお手伝いみたいなプロジェクトになります。単純にエンジニアリングという部分でも面白いものにならないですよね。ですので、関係する全員でプロジェクトを実施することでどういう結果を得るのか?をちゃんと各ドメイン間で揃えました。 ── なるほど。そうするとそうした擦り合わせは江藤さんと酒井さんがやっていたんでしょうか。 酒井 : はい、僕のほうで行っていました。僕が初期のすり合わせ時に重視していたのは、スコープを適切に区切るという部分でした。調剤側の提供価値の最大化だけを追って初期から大きな機能追加を行うのではなく、変更による医科・患者・調剤へ与えるリスクや開発コストを抑えつつ、価値を最大化できる落とし所はどこか、という部分から刷り合わせしていきました。 メドレーが面白いなって思うのが、プロダクト単独で動いていくわけではなくて、 ペイシェントジャーニー(患者体験)を中心としてプロタクト群が存在しているところ です。 患者体験をより良く構築するためにそれぞれのプロダクトが動いていけるので、お手伝いというニュアンスじゃなく、プロダクトを超えてここはよくしていきましょうと言える文化があるところがいい部分かなと思いますし、やりがいがある部分かなと思います。 江藤 : 特に横断のプロジェクトだとこうした目的意識の統一に一番時間を使っても良いんじゃないかと考えています。ここが決まりさえすれば、後々迷った場合も目的に即した意思決定ができますし。ここを固めた後に各ドメインでの調整するという順番が大事だと思います。 ── 技術面で気をつけたポイントはどんなものがあったんでしょうか。 有馬 : 同時予約機能としてやりたいことはありつつ、診療所側の業務フローや患者の導線、今あるシステムの制約などを踏まえ、どのような形に落とし込めば 診療所も薬局も患者にとっても価値のある機能となるか がポイントです。 ですので、技術的な面と事業的な面を併せて考えながら、システム全体の要件を決めていくというのが最初に手がけた部分でした。 ── 機能を考える上で、全体を見据えた設計などをやっていくと思うんですが、今回はどこから着手されたんでしょうか?患者の導線だったり医療機関の業務フローなど把握した後に、取りかかった部分を聞きたいのですが。 有馬 : 同時予約におけるシステム全体の要件を固めていくと同時に、全体のシーケンスとステートマシンを作っていきました。各システム間の連携フローと、それにより生み出される予約や処方箋といったエンティティの状態遷移を決めていき、この状態の時はこういったことはできないとか、そういった辻褄を合わせるところをしっかりやっていったという感じですかね。 酒井 : 今回は、特に プロダクト横断の共通基盤として、各プロダクトでそれぞれ全く別物の仕組みやステータスを保有しているのを、共通化・抽象化するという業務が必要になる ので、すごく難しいし、難易度が高い部分だなと思っているんですけど、それを綺麗にシーケンス図に落とし込んだ有馬さんが凄いなと思いました。 江藤 : 基盤側で作っていただいたシーケンス図は UX の骨組みなんですよね。そこをいわゆる UX デザイナーが別途やるといった細分化をせず、実装の制限を加味しつつ、正しく運用を回すために、この体験を作るためにこのステータス遷移であるべきだよね、という部分を有馬さんがエンジニア観点で最初に作ってくれてるというのが、 メドレーのエンジニアのとても良い部分 だと思っています。技術だけでなく UX などにも必要であれば越境していける文化ですね。 同時予約 Pj 開発の実際 ── そうした初期フェーズを経て Pharms と CLINICS どちらの開発にも関わった小田さんに聞きたいのが、開発の流れの中でいわゆるリソース的な問題って大変だったと思うのですが、そこはどう解決したんでしょうか。 小田 : 先に Pharms 側の機能 を作ってその後に CLINICS の仕様を決めてもらってから CLINICS の開発に入る流れだったので開発が並行することはなかったです。ただ Pharms ではリードエンジニアという立場なので 、CLINICS の開発に入るための準備と、Pharms 側のレビューやフォローのリソース配分は自分で考えて、各タスクを実施する時間とタイミングを調整しながらやっていました。 一方で、この体制でも進めることができたのは Pharms チームの各メンバーが既に自走できる状態にあったので、そこに支えられたからこそできた かなと思ってます。 ── プロダクトも越境しながら開発するという文化はすごく良いと思ったのですが、ここはフローなどあったりしたんですか? 江藤 : 先程も話した通り Pharms として本プロジェクトの優先度は高かったのですが、CLINICS の事業計画やリソースを踏まえると医科側の実装着手が大きく遅れそうな見立てでした。そこで、小田さんを 医科側の開発にもアサインできたらリソース問題が解決できるのではと調整しました。医科側のエンジニアからのフォローアップは必要なので、その調整もしつつですが、開発を早められるなら良し、と開発チーム間で最終的に判断しました。 酒井 : 今まで触ってなかった CLINICS のシステムにも小田さんはガンガン切り込んでくださったので、元々 CLINICS の開発をやってたのではと思うくらいキャッチアップが早かったです。 ── プロダクトのグロースのためにリソース調整を成功させたという形だったんですね。プロダクト間の越境がしやすいような文化だったり、プロジェクトを成功させようという目線合わせが自然にできるのは良いですね。 チーム間という話でいえば QA は各チームに跨っての活動だと思いますが、その観点ではいかがですか? 小島 : 自分は開発が終盤に入ったタイミングでプロジェクトに合流しました。それまでは米山さんが QA として入っていたのですが、医科側でも検証すべきテスト観点が多数あった背景もあり、医科側の QA をメインで見る担当として参画しました。 後半に参画した背景もあり、そもそも処方箋送付という業務や Pharms プロダクトの仕様理解も浅い…という状態でしたが、 開発目的・要件定義・設計が詳細にドキュメント化されていたので、スムーズに検証に入ることができました 。検証の中で QA エンジニアとしても「この部分の仕様は見直した方が良くなる」というポイントがいくつか出てきたので、仕様の改善提案も行いました。後発参加でしたが、実際に取り入れてもらった改善も多いです。 メドレーのプロダクト開発の文化として QA エンジニアも 要件定義からレビューに参加したり、意見を言いつつプロダクトをより良くするための改善が行える ので、とても働きやすいですね。 ── 後から入っても動きやすいというのは、ドキュメントなどが整備されているからできたことだというのが分かりますね。横断プロジェクトだからこそ気がついた他のチームの良い点などあったりしますか? 酒井 : Pharms のプロジェクトってやりやすいな、と思ったのが KPI 設計がすごく明確なところだったという点でした。 色々紆余曲折あった結果ここに辿り着いてるという苦労を知ってはいるんですけど、今の KPI 設計ってやっぱりすごくシンプル で処方箋送信数ですとなると、そこから逆算した KPI を各 PF に振ればいいと言う体制だったので、すごくこれはやりやすかったポイントの一つかなと思います。 話す論点も結局そこっていう部分がすごくコミュニケーションコストが安くすんだ部分ではあるかなと思いました。 横断プロジェクトならではのエンジニアリング ── 全体の話から個別のドメインごとのエンジニアリングという点ではどのようなことをされていましたか? 小田 : 基本的には有馬さんのシーケンス図を元に開発を進めていました。CLINICS では A という状態になる、その時に B というアクションがあると Pharms では C という状態になるというように状態遷移が複雑だったため、設計時にあるべき姿に迷うことが多かったのですが、シーケンスに立ち返るとすぐにその疑問が解決するといった具合です。 有馬 : シーケンスの整合性や難しくなりすぎないように設計する ことには気をつけました。「同時予約」という言葉が先行するとついつい複雑な新機能のようなものを作りがちですが、診療所や薬局の予約機能、処方箋送信機能といった個々のパーツはもともとあるわけで、なるべくシンプルにそれらをつなぎ合わせられるように心がけました。 江藤 : 細かいプロダクト間の調整が必要になるので ちゃんと調剤の欲しい KPI も求めつつ、かつ現場のオペレーション品質を落とさないっていう観点で調整を各ドメインでやりました。 工夫したことでいうと、UX 調査を徹底したところでしょうか。 今回のサービスって業界的にみた時に新しいかというとそうではないんですよね。ですので、同業界の企業さんの各アプリの体験とか、自分でも結構色々使いながら体験してみましたし、それらをベースに逆に現状のうちの仕様を踏まえると、こういう風にうちでは実装しましょうみたいなところを色々やっていました。 小田 : エンジニアリングの観点でいうと、特に患者アプリチームとの API 連携の仕様調整と、開発の進め方は密に連携しながら進めました。先にこっちができてないと向こうも開発できない状態になるので、担当者同士でコミュニケーションとりつつ、工夫しながら進めていました。 酒井 : CLINICS で気にしてた部分はどちらかというと リスクとコストの部分、いかに最小化して価値を最大化するかが一番重要 かなと思っていたので、一番大事なのはやっぱり医科にとってどういう価値が出て、医科にとってどういうリスクが発生するかを考えてました。 例えば一番最初のすり合わせで薬局予約する時に日時まで確定させましょうという話もあったんですけど、そこまでスコープを広げなくてもメリットが出るのであれば、広げたくないですという話をしていました。 あとはリリースプランの策定とかかな？全医療機関に一斉に出すのではなく、まずは一部医療機関様だけに公開するリリース方式にしましょうみたいなところも含めてですかね。医科側で一旦テストをやって検証して、スムーズに機能が使えるところを確認したりするステップを設けましょうと安全策を取りながら進めました。 これはこのプロジェクトに関わらず、どんなプロジェクトでも一番重要でそこが後からひっくり返るのが一番手戻りになってくるので、そこは重要かなと思いながら進めてましたね。 小島 : QA 視点だと横断プロジェクトゆえにステートが本当に複雑で、メドレー入社後に経験したプロジェクトの中で検証の難易度が最も高かったですね。 ですが、皆さん仰られているように各ユースケースに対する設計が図でドキュメント化されていたので、テストケースとして転用できた部分も多くありました。有馬さんが作成した設計図があったからこそ漏れなくテストできた部分は大きいです。大勢が参加するプロジェクトにおいて、全員が認識合わせる上でも設計図は本当に大事だなと痛感しました。 工夫した点としては、小田さんは Pharms 開発のドメイン知識が豊富だったので、QA 時は Pharms 側をメインに見てもらいつつ、自分は CLINICS 側の QA を手厚く見るようにしました。どちらのドメインにも関係する契約プラン等の複雑な仕様は自分が担当しました。 QA 以外の面だと、リリースする上で必要な浮いたボールがあれば積極的に取りにいくようにしました。 例えば、これまで一部の医療機関様だけに機能リリースする場合、その後のフィードバック回収はメールや面談で個別に行っていましたが、日々の診療の中でお時間を確保頂くのが難しいという状況がありました。その結果、本 Pj においても全体リリースして問題ないか？の判断がしづらい時期がありました。 そこで Google フォームでアンケートを作成して短時間で回答できる形に切り替えました。結果的に 100% 回答を得ることができました。 アンケート結果から「従来機能より価値があり、院内オペレーションに組み込んで頂くコストもそこまで高くない」という点が評価できたので、自信を持って全体公開リリースに向けて GO 判定できました。** メドレーは役割に縛られずボールを任せて頂ける環境があるので、自分の専門領域以外のことも学べている**と思うことが多いです。 幸いリリース後も大きな不具合はないのでこれはもう皆さんのおかげですね。 同時予約 Pj を終えて ── では最後にこのプロジェクトの総括をしていだければ。 江藤 : 横断ではあるけど各ドメインでそれぞれのプロフェッショナルがちゃんと力を発揮してプロジェクトをやり切れたというのはすごく大きい資産でした。 医療 PF はアセットをたくさん持っているので、色々組み合わせると、他の会社だとできないけど、うちならできそうだね、みたいなことが色々ある んです。 なので、この後も横断プロジェクトは予定されていますが、それに先駆けてひとつやりきって、かつ僕らが欲しかった期待成果を現状出せているところを含めるとすごく良い一歩だったのかな、と思ってます。 次は品質を担保しつつ、もっとスピードを上げていきたいというのが観点として大きいですね。 ── なるほど。こうした横断プロジェクトもやっていく医療 PF ではどんなエンジニアがマッチするポイントでしょう? 有馬 : 技術と併せてユーザーへの価値提供も考えながらエンジニアリングしたい人がマッチするのではないかと思います。 ── 各プロダクトの持っている役割を踏まえて、俯瞰の視点で開発もしたいという方にはすごく魅力的ですね。本日はありがとうございました。 さいごに 同時予約 Pj について、プロジェクトを推進したメンバーに話を聞きましたが、複雑な要件を実現可能な形にして各チームで垣根を越えて開発をしている様子がとても印象的でした。特に医療 PF ではドメイン同士で有機的に結合していき、コラボレーションすることによりステークホルダーへの価値を高めているというのは、やりがいがあるのではないかと感じます。 このようなプロジェクトで力を発揮したいと思った方はぜひ、お気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp