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

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

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

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

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

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

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

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

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

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

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

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

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

はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。 記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。 松江オフィスでやっていること 松江オフィスではレセコン新規開発プロジェクトとして、 CLINICS カルテ に内包されるレセコン部分の開発を Ruby on Rails で行っています。 医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。 レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。 電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。 これらの問題を解決すべく、 Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。 アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。 松江オフィスで利用してる技術 サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。 インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。 各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。 新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。 現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、 COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。 松江オフィスの雰囲気・文化 松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。 年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。 松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきました トレイルヘッズ様の HP にてご確認いただくことが可能です。 開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。 東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。 現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。 松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。 レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。 以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。 松江オフィスでこんな人と働きたい 以下に当てはまる方、大募集中です。 プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる Our Essentials に共感できる 医療業界に革新を起こす壮大なミッションにチャレンジしてみたい 下記のリンクからご応募お待ちしています。 中途採用は こちら 2024 年度新卒採用は こちら おわりに 簡単ですが、松江オフィスの紹介をさせていただきました。 今後も松江オフィスのメンバー一丸となって レセコン の開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。 記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。 松江オフィスでやっていること 松江オフィスではレセコン新規開発プロジェクトとして、 CLINICS カルテ に内包されるレセコン部分の開発を Ruby on Rails で行っています。 医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。 レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。 電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。 これらの問題を解決すべく、 Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。 アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。 松江オフィスで利用してる技術 サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。 インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。 各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。 新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。 現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、 COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。 松江オフィスの雰囲気・文化 松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。 年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。 松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきました トレイルヘッズ様の HP にてご確認いただくことが可能です。 開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。 東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。 現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。 松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。 レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。 以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。 松江オフィスでこんな人と働きたい 以下に当てはまる方、大募集中です。 プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる Our Essentials に共感できる 医療業界に革新を起こす壮大なミッションにチャレンジしてみたい 下記のリンクからご応募お待ちしています。 中途採用は こちら 2024 年度新卒採用は こちら おわりに 簡単ですが、松江オフィスの紹介をさせていただきました。 今後も松江オフィスのメンバー一丸となって レセコン の開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。 記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。 松江オフィスでやっていること 松江オフィスではレセコン新規開発プロジェクトとして、 CLINICS カルテ に内包されるレセコン部分の開発を Ruby on Rails で行っています。 医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。 レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。 電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。 これらの問題を解決すべく、 Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。 アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。 松江オフィスで利用してる技術 サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。 インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。 各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。 新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。 現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、 COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。 松江オフィスの雰囲気・文化 松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。 年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。 松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきました トレイルヘッズ様の HP にてご確認いただくことが可能です。 開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。 東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。 現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。 松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。 レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。 以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。 松江オフィスでこんな人と働きたい 以下に当てはまる方、大募集中です。 プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる Our Essentials に共感できる 医療業界に革新を起こす壮大なミッションにチャレンジしてみたい 下記のリンクからご応募お待ちしています。 中途採用は こちら 2024 年度新卒採用は こちら おわりに 簡単ですが、松江オフィスの紹介をさせていただきました。 今後も松江オフィスのメンバー一丸となって レセコン の開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。 記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。 松江オフィスでやっていること 松江オフィスではレセコン新規開発プロジェクトとして、 CLINICS カルテ に内包されるレセコン部分の開発を Ruby on Rails で行っています。 医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。 レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。 電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。 これらの問題を解決すべく、 Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。 アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。 松江オフィスで利用してる技術 サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。 インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。 各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。 新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。 現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、 COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。 松江オフィスの雰囲気・文化 松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。 年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。 松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきました トレイルヘッズ様の HP にてご確認いただくことが可能です。 開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。 東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。 現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。 松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。 レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。 以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。 松江オフィスでこんな人と働きたい 以下に当てはまる方、大募集中です。 プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる Our Essentials に共感できる 医療業界に革新を起こす壮大なミッションにチャレンジしてみたい 下記のリンクからご応募お待ちしています。 中途採用は こちら 2024 年度新卒採用は こちら おわりに 簡単ですが、松江オフィスの紹介をさせていただきました。 今後も松江オフィスのメンバー一丸となって レセコン の開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。 記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。 松江オフィスでやっていること 松江オフィスではレセコン新規開発プロジェクトとして、 CLINICS カルテ に内包されるレセコン部分の開発を Ruby on Rails で行っています。 医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。 レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。 電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。 これらの問題を解決すべく、 Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。 アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。 松江オフィスで利用してる技術 サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。 インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。 各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。 新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。 現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、 COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。 松江オフィスの雰囲気・文化 松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。 年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。 松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきました トレイルヘッズ様の HP にてご確認いただくことが可能です。 開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。 東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。 現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。 松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。 レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。 以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。 松江オフィスでこんな人と働きたい 以下に当てはまる方、大募集中です。 プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる Our Essentials に共感できる 医療業界に革新を起こす壮大なミッションにチャレンジしてみたい 下記のリンクからご応募お待ちしています。 中途採用は こちら 2024 年度新卒採用は こちら おわりに 簡単ですが、松江オフィスの紹介をさせていただきました。 今後も松江オフィスのメンバー一丸となって レセコン の開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。 記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。 松江オフィスでやっていること 松江オフィスではレセコン新規開発プロジェクトとして、 CLINICS カルテ に内包されるレセコン部分の開発を Ruby on Rails で行っています。 医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。 レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。 電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。 これらの問題を解決すべく、 Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。 アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。 松江オフィスで利用してる技術 サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。 インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。 各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。 新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。 現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、 COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。 松江オフィスの雰囲気・文化 松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。 年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。 松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきました トレイルヘッズ様の HP にてご確認いただくことが可能です。 開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。 東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。 現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。 松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。 レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。 以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。 松江オフィスでこんな人と働きたい 以下に当てはまる方、大募集中です。 プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる Our Essentials に共感できる 医療業界に革新を起こす壮大なミッションにチャレンジしてみたい 下記のリンクからご応募お待ちしています。 中途採用は こちら 2024 年度新卒採用は こちら おわりに 簡単ですが、松江オフィスの紹介をさせていただきました。 今後も松江オフィスのメンバー一丸となって レセコン の開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 2021 年 9 月 1 日に Tech Studio MATSUE オフィス（以下松江オフィス）が設立された際、他の初期メンバー 4 人と一緒にメドレーに入社しました。 記事を読み終わられた際は、1 人でも多くの方が松江オフィスに興味を持っていただけると嬉しいです。 松江オフィスでやっていること 松江オフィスではレセコン新規開発プロジェクトとして、 CLINICS カルテ に内包されるレセコン部分の開発を Ruby on Rails で行っています。 医療機関でどちらも使われるものですが、電子カルテがドクター向けのアプリケーションなのに対して、レセコンは事務員さん向けのアプリケーションとなります。 レセコンでは電子カルテに登録された診療内容を元に診療報酬の計算を行い、日々の業務としては請求書兼領収書、診療費明細書、処方箋、日報の作成を行い、月次の業務としては、保険者に対しての請求データの作成などの処理を行っています。診療報酬とは我々が医療機関を受診した際に受けた医療行為について、その対価として医療機関に支払われる費用です。医療行為１つ１つに点数が設定されており、この点数を「1 点=10 円」として診療報酬の計算を行います。 電子カルテとレセコンの関連性は強く、2 つのアプリケーションが近い関係であればあるほど、CLINICS の顧客に対してより価値の高いサービスの提供が可能となります。 これらの問題を解決すべく、 Sustainable （維持し続けられる）、Reasonable （合理的である）、Improvable （改善し続ける）、Manageable （管理しやすい）を基本コンセプトにレセコン新規開発プロジェクトが始まり松江でレセコンの開発が行われることになりました。 アプリケーション側で使いやすい API の開発を効率的に進めています。これには、アプリケーション側の開発チームとの関係強化が必須です。このため、東京の CLINICS チームとは日々 Slack や Google Meet などを通じて密に連絡を取り合いながら相互理解に努めることで、信頼関係を強化し、効率的に開発ができるよう取り組んでいます。 松江オフィスで利用してる技術 サービスのバックエンドということもあり、特別な技術スタックは使用せずオーソドックスに Ruby on Rails、MySQL を利用しています。 インフラも同様でサービスがスケールすることを念頭において AWS を利用しています。また IaC として Terraform を利用しています。 各人の開発環境も GitHub や Docker といった極めて一般的なものを採用しています。 新人を除く 5 人は元々別の会社において新規レセコンとは異なるレセコンの開発に携わっていました。当時は COBOL で開発を行っていましたが、レガシーな言語ゆえ、冗長的なコードになったり、同じようなロジックが複数のコードに存在していたりとメンテナンスに大変苦労していました。 現在は Ruby で開発を行っており、Ruby なりの難しさはありますが、 COBOL で同じコードを書いたら 5 倍の量になるなと感じるくらい、当時と比べると開発コストは大幅に下がっていると実感しています。 松江オフィスの雰囲気・文化 松江オフィスがある松江市は中海、宍道湖と大きな湖を 2 つもつことで水の都と言われています。この 2 つの湖を結ぶ大橋川ではシーバス釣りが盛んです。 年に 1 回秋頃にレガッタの大会が行われ、弊社のメンバーもチーム TAGBORTS として参加しています（まだオフィスのメンバーだけではチームが組めないため助っ人をお願いしている状況です…）。去年は 2 回戦敗退と悔しい結果となりましたが、今年は更に上を目指したいと思います。 松江オフィスは事務所のような雰囲気は一切なく、都会的なデザインとなっています。内装は設計・施工を行っていただきました トレイルヘッズ様の HP にてご確認いただくことが可能です。 開発用デスクは周囲が気にならないようにパーティションを設置しています。椅子にはアーロンチェアを採用しており、長時間の作業で体に負担がかからないよう配慮されています。 東京オフィスとのコミュニケーションは Google Meet か Slack がメインのため、電話がかかってくることもなく、集中して開発に取り組むことができる環境となっています。 現在エンジニア 5 名、ディレクター 1 名の計 6 名が在籍しています。 松江オフィスではレセコンに関する業務的な質問や Ruby に関するロジック的な質問など誰とでも気兼ねなく行うことができるように、メンバー間のコミュニケーションが取りやすい環境づくりを心がけています。例えば、今年からの取り組みですが、毎日 10 分程度の朝会を行うようにしました。会の目的としては進捗の遅れや、詰まってることなどを話すきっかけづくりです。 レセコン開発の性質上、エンジニアも診療報酬の知識のインプットが必要です。このため、ディレクターを中心に診療報酬の勉強会も行っています。 以前開発していたレセコンを超えるレセコンを作り上げる。それがメンバーの共通の目標です。 松江オフィスでこんな人と働きたい 以下に当てはまる方、大募集中です。 プログラミング（技術）が大好きで、それを手段として課題に対して積極的に行動できる Our Essentials に共感できる 医療業界に革新を起こす壮大なミッションにチャレンジしてみたい 下記のリンクからご応募お待ちしています。 中途採用は こちら 2024 年度新卒採用は こちら おわりに 簡単ですが、松江オフィスの紹介をさせていただきました。 今後も松江オフィスのメンバー一丸となって レセコン の開発を進め、CLINICS チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！