はじめに 自己紹介 はじめまして。人材プラットフォーム本部プロダクト開発室第一開発グループの田中です。 私は、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

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

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

はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ https://www.medley.jp/jobs/

はじめに こんにちは。 プロダクト開発室第二開発グループ所属の古川です。 私は 22 年新卒としてメドレーに入社し、現在はインフラとアプリケーションを 5 : 5 の割合ぐらいで開発・運用・保守などを行っています。 学生時代からインフラ周りに触る機会も多く、入社前に AWS Certified Solutions Architect - Professional を取得しました。 大のコーヒ好きで自宅で生豆から焙煎をし、毎朝豆を挽き、抽出したコーヒーを飲むことが日々の幸せです。 好きなコーヒー豆の種類は インドネシア・スマトラ島産・アラビカ種のマンデリン( G1 )の中深煎りです。 さて、今回の記事では私が携わっているプロダクトで運用している Amazon Aurora （以下 Aurora ）を暗号化した時の検証・暗号化の作業について紹介させていただきます。 私が検証を始める前の Aurora 周りに関する私自身の認識は以下の通りでした。 AWS のサービス全体は大体知っている 論理レプリケーションというものが存在することは知っており触ったこともあるが、実際に稼働中のものに対して実施したことはない 非暗号化の Aurora DB クラスターを暗号化するのは大変であるという理解 上記のような認識の新卒エンジニアが、検証をしながら大きな問題なく暗号化作業を実施した過程を紹介できればと思います。 暗号化を実施する Aurora とその周辺アプリケーションについて 影響範囲と暗号化をする Aurora DB クラスターについて 今回暗号化を行う Aurora DB クラスターの周辺アプリケーションはざっくり以下のようになっています。 実際に暗号化をする Aurora DB クラスターのエンジンは Aurora PostgreSQL で、主に AWS Fargate 上にある Ruby on Rails (以下 Rails )で書かれた API サーバからのアクセスがあります。 インフラ構築は IaC ( Infrastructure as Code ) ツールの Terraform で管理しています。 また、暗号化対象の Aurora DB クラスターのデータ量は 5GiB 以下で比較的容量は小さめです。 Aurora DB クラスターの周辺について 複数プロダクトへ同時にアクセスを行うクライアントから、本クラスターにはアクセスが頻繁にあります。 そのため長時間読み込み処理ができないと他のプロダクトにも影響がでる可能性があります。 また、本 Aurora DB クラスターに対して書き込みが行われるメイン機能が実行されるタイミングでは、アプリケーションへの影響を最小限にしたいと考えました。 API サーバ内では基本的にロールバック処理がされているので、データ不整合は起きませんが処理に失敗はします。 当たり前ですがユーザ体験は悪くなるので、できるだけ失敗しないように暗号化作業を行う必要があります。 実施方法の検討 実施方法の検討をする上で以下の観点を意識しました。 暗号化を実施する時間帯 暗号化するためにかかる時間 移行までの準備と労力・アプリケーションコードへの依存 暗号化を実施する時間帯 前提として ライターインスタンスの停止は 10 分程度にしたい という目標のもと時間帯を検討しました。この時間は暗号化実施時に予期せぬことが起き、元の状態に戻すことが必要になった時も踏まえ、できるだけ短く・かつクライアントの影響範囲が比較的少なくなるように決めたものです。 また、暗号化を実施する Aurora DB クラスターは複数プロダクトからのアクセスがあります。その中でも、今回は書き込み処理が行われる機能の利用が少ない時間帯に実施することにしました。 Amazon CloudWatch の Logs や Datadog の情報をもとに、あるメイン機能は夜間・休日の利用が少ない傾向にあり、特に土曜日の深夜 26:00 が 1 番少ないと判明したのでその時間に実施することにしました。 暗号化するためにかかる時間 暗号化をするために行う作業はいくつか存在し、その内容とかかる時間が異なります。 例えば、 Rails がアクセスする DB ホスト名を変更しただけだとコネクションプールが残ってしまい、変更前の非暗号化クラスターに接続しようとしてしまいます。そのため、ホスト名を変更した後に AWS Fargate サービスの再起動が必要 で、その時間も安定稼働までに確保しなければなりません。 以上のような時間が発生することと、ライターインスタンスの停止は 10 分程度にしたいという目標を踏まえ、検証時に時間を計測しました。 移行までの準備と労力・アプリケーションコードへの依存 基本的に 1 人で検証・移行作業を行う、かつ私自身が別のプロジェクトも並行して進めているため、準備に時間がかかりすぎてしまうものは採用しないことにしました。 そのためできるだけ変更箇所は少ないもの、特に できればアプリケーションコードの変更が極力ない方法 というのを検証時点で決めておきました。 上記を踏まえ、以下の 3 つの方法で検証をしたのでそれぞれについて説明します。 スナップショットを用いて新規暗号化済みクラスターを作成する方法（方法 1 ） AWS Database Migration Service (以下 AWS DMS )を用いて継続的論理レプリケーションを使用する方法（方法 2 ） pg_dump & pg_restore を使用する方法（方法 3 ） スナップショットを用いて新規暗号化済みクラスターを作成する方法 こちらの方法は Web 上で「 Aurora 暗号化 後から」などと検索すると良くヒットする方法です。 すでに起動している非暗号化クラスターのスナップショットを取得し、そのスナップショットから暗号化済みの新クラスターを復元する方法です。データの不整合が起きないように、スナップショットを取得する段階から書き込みがされないように制限する必要があります。 準備することはほぼなく簡単に実施できるのですが、ライターインスタンスの停止時間が長すぎるため不採用としました。 検証時ではそれぞれ以下の時間だけかかり、ライターインスタンスの停止許容時間を大きく上回り現実的ではないと判断しました。 スナップショットの取得時間：3 分 暗号化済み新クラスターの作成：約 30 分 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate の再起動：3 分強 AWS DMS を用いて継続的論理レプリケーションを使用する方法 こちらの方法は AWS DMS で論理レプリケーションを行い、旧クラスターの変更を検知して、新クラスターに反映させる方法です。 想定しているライターインスタンスの停止時間は、旧クラスターを読み取り専用に変更 〜 レプリケーションが追いつき DB ホストの変更が終わるまでの時間です。 この停止時間は 5 分弱と想定しており採用するつもりだったのですが、AWS DMS の移行前評価を行った時すぐに実施できないことが明らかになりました。 移行前評価の詳細は省きますが、主な原因は Large Object ( LOB ) の制約で、150 以上のカラムがそのままの状態では移行することができかったためです。 そのほとんどが null 許可の制約だったので解消しようとしましたが、テーブル構造だけでなくアプリケーション側の変更もいくつか必要だったため、不採用としました。 また論理レプリケーション設定を ON にするためには事前にライターインスタンスの再起動が必要で、結局別のタイミングで少しのダウンタイムは発生してしまうこともあり実施しないことにしました。 pg_dump & pg_restore を使用する方法 こちらの方法は、 PostgreSQL クライアントに標準で提供されている pg_dump と pg_restore を使用する方法です。 実施する時は、 AWS Systems Manager のセッションマネージャーを介してクラスターにアクセス可能な状態を作り、コマンドを実行します。 結論からいうとこちらの方法を実際に採用しました。 理由は主に以下になりますが、 暗号化するクラスターのデータサイズが 5GiB 以下 だったので、本方法でもそこまで時間がかからなかったのが一番の理由です。 検証時にライターインスタンスの停止時間は 8 分程度だったこと pg_dump & pg_restore ： 4 分弱 アプリケーションから接続する DB ホストの切り替え：数秒程度 AWS Fargate サービスの再起動： 3 分強 移行時に実行するシェルスクリプトを用意すれば良いので準備が大変ではないこと 検証時に開発環境で実行した後も不具合は確認されなかったこと またこちらの方法は Amazon Aurora PostgreSQL をマイグレーションする時の方法として公式にも掲載されていたので、迷いなく行えると思いました（ pg_dump and pg_restore ）。 それぞれの検証結果をまとめると以下のようになります。 今回のユースケースでは方法 3 の pg_dump & pg_restore を使用した暗号化が良いと判断し、実施することにしました。 項目 方法 1 方法 2 方法 3 暗号化するためにかかる時間 40 分弱 2 〜 5 分程度 5 〜 8 分程度 移行までの準備と労力 小 大 小 アプリケーションコードへの依存 なし あり なし 実施内容 行った作業内容は以下の通りで、それぞれ説明していきます。 移行時は、私とは別にもう 1 人の方にアラートなどの状況を Sentry 等で確認していただき、予期せぬ問題が起きていないかを確認します（当たり前ですが、ダブルチェックはすごく大事）。 API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する 暗号化された Aurora DB 新クラスターを Terraform で構築する 旧クラスターを読み取り専用に変更する 移行スクリプトを実行する（実行時間： 3 分強） DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） AWS Fargate サービスを再起動する（実行時間： 3 分強） 1. API アプリケーションから Aurora に接続する時には DNS Alias で名前解決するように設定する AWS のマネージドサービスである Route 53 で、レコードに旧クラスターのエンドポイントを指定します。エイリアスの名前は、取得済みのドメインからサブドメインを指定しています。API アプリケーションから、そのエイリアス名で DB ホスト名を名前解決できるように設定を変更しておきます。 本 API アプリケーションは DB のホスト名は Parameter Store で管理していたので、AWS Fargate の再起動を行い起動時に新しい値が読み込まれるようにしました。 2. 暗号化された Aurora DB 新クラスターを Terraform で構築する 移行の前に暗号化済みの新クラスター作成しておきます。暗号化には AWS Key Management Service を使用します（ Terraform の公式リファレンス を見ればすぐに構築可能です）。 余談ですが、 Terraform で Aurora クラスターを作成する時、 aws_rds_cluster に記載されているサンプルでは、暗号化設定が記述にはないので作成する時は気をつけた方が良さそうです。 3. 旧クラスターを読み取り専用に変更する 旧クラスターに紐づいているパラメーターグループの default_transaction_read_only を 0 から 1 に変更します。この作業が完了すると旧クラスターへの書き込み処理はされなくなります。 4. 移行スクリプトを実行する（実行時間： 3 分強） 移行するためのスクリプトを実行します。 実際に実行した時には、いくつかのオプションをつけましたが、基本的にやったことは、 pg_dump したものを暗号化された Aurora DB 新クラスターに pg_restore するだけです。 2 で構築した新クラスターは、旧クラスターと同じプライベートサブネットに作成しておけば旧クラスターにアクセスできる状態になるので、移行コマンドは問題なく実行できると思います。 $ pg_dump -h < 旧クラスターのホスト 名> -p < ポート番 号> -U < ユーザー 名> -d < データベース 名> | \ pg_restore -h < 新クラスターのホスト 名> -U < ユーザ 名> -d < データベース 名> 5. DNS Alias を旧クラスターから新クラスターに切り替える（実行時間：数秒） 移行が完了したら、 1 で作成した DNS Alias を新クラスターに向くように変更します。 移行時は TTL（ Time to Live ）はできるだけ短く設定（ 15 秒）することで、ホストの切り替えに時間がかからないようにします。 6. AWS Fargate サービスを再起動する（実行時間： 3 分強） ホストが切り替わったら、AWS Fargate サービスを再起動します（以下コマンドを実行するだけ）。 先述しましたが、本作業を行わないと Rails から Aurora DB クラスターへの DB コネクションプールが残ってしまいます。 すでにホスト名は変更されているためコネクションが失敗すると自動で新しく接続をし直し、失敗後は意図したホスト（暗号化済みの新クラスター）に接続されますが、接続先を必ず変更したいので、サービスの再起動を行います。 $ aws ecs update-service --profile < プロファイ ル> \ --cluster < クラスター 名> \ --service < サービス 名> \ --force-new-deployment 本作業は検証時に DNS Alias を変更しただけだと接続先が変わらないことに気付き入れた対応でした。 ここまでの作業が完了したら実際に動かしているアプリケーションに不具合がないかを確認し作業完了です ✨ さいごに まとめ 今回は稼働中の Amazon Aurora PostgreSQL を暗号化した時の検証・実施内容を紹介しました。 今回の方法は、対象のプロダクトで行う上での一例ですが、比較的少ないダウンタイムで作業を完了することができました。 また、 pg_dump と pg_restore 実行時に並列度を増やすことでもっと早く移行作業は完了できると思いますが、暗号化するデータの容量が大きくない、Aurora クラスター側に負荷をかける必要がなかったので今回は 1 で実行しました。 私自身本作業を終えて、パラメータグループの細かい設定についての知見も増え、この後にやった他の施策にも活きているので自分自身の成長にも繋がりました。 先輩方に意見を求めたりもしましたが、施策自体は 1 人でやり切れたことはとても良い経験になりました。 普段は、 AWS のマネージドサービス内で行えないかを真っ先に考えるのですが、マネージドサービスに依存しない形で行うこともユースケースによっては必要だなと再認識できた良い経験でした。 少しでも私の経験が誰かの役に立てばうれしいなと思います。 このように、メドレーは新卒・中途に関わらず裁量を持って施策を実行できる環境です。インフラやアプリケーションにとらわれず様々なプロジェクトに携われる開発チームにジョインしてみませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

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

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

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