はじめに みなさん、こんにちは。エンジニアの山田です。メドレーでは医療プラットフォームで患者が使う「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 チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。医療プラットフォーム本部プロダクト開発室第三開発グループ グループマネージャの太田です。レセコン（電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア）新規開発プロジェクトでレセコンの開発を行っています。 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 チームと協力して稼働医療機関を増やしていき、より患者が医療にアクセスしやすい環境が作れるように取り組んでいきます！

はじめに みなさん、こんにちは。エンジニアの新居です。 今回のインタビューは前回の CTO へのインタビュー に続いて、メドレーの開発組織についてご紹介していきたいと思います。 メドレーでは開発組織をリードするロールとして、CTO の他、「グループマネージャ」(以下、GM)という役職があります。今回は医療プラットフォーム(以下、医療 PF)における開発グループの GM を担う二人に、具体的にどのような役割なのか聞いていきます。 インタビュイー紹介 今回の紹介はインタビュー中で前職からメドレー入社の話を聞いているので、シンプルにお送りします。 平山さん 医療 PF 第一本部 プロダクト開発室 第四開発グループ GM。現在は CLINICS 基幹システムチームのマネジメントを担当。 岡村さん 医療 PF 第一本部 プロダクト開発室 第三開発グループ GM。現在はレセコン(電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア)新規開発チームのマネジメントを担当。 左から岡村さん、平山さん、筆者 前職までの経歴とメドレー入社の理由について 二人の経験について 新居 : 早速始めていきますが、まずはお二人の経歴を教えていただきたいと思います。 平山 : メドレーは 2 社目の会社となります。前職は SIer で 14~5 年くらい受託開発や客先常駐して開発をしていました。SIer というと場合によっては二次請け・三次請けの開発をしているところもあるんですが、自分は一次請けとして直接顧客と関わる形で業務を行っていました。 顧客のサービスをステークホルダーと提案・折衝しながら、技術選定・要件定義から開発、リリースまで行い、そこからの保守運用といった部分までの一連の流れを様々な業態の顧客と関わらせて頂きました。 新居 : ありがとうございます。かなり自社開発と同じ感覚の開発を長年されてきたんですね。それでは、岡村さんお願いします。 岡村 : 新卒で外資系の IT コンサルティング会社で IT コンサルタントとしてキャリアを始めました。その中でも特に「情報系」と呼ばれるデータアナリティクスや BI (Business Intelligence) などを取り扱う部門で業務をしていました。領域的には金融・製薬・省庁など堅めの領域を主に担当していたので、いわゆる Web アプリケーションを作るというよりは SQL をガリガリ書いてデータ分析を基に業務改善していく…という感じの業務が多かったです。 2 社目はスタートアップ企業の立ち上げフェイズにジョインしました。その会社はいわゆる Insure Tech と呼ばれる保険業界 x テクノロジー領域のサービスを作っている会社でした。そこで、その会社でのプロダクトマネージャ業務と、運転資金を確保するために大手保険会社向けのコンサルタント業務に半々で従事していました。 その後にメドレーにジョインするという経歴です。 岡村さん メドレー入社の経緯について 新居 : ありがとうございます、お二人はメドレーに入社してどのくらい経ちますっけ? 平山 : 私は 3 年半ですね。 岡村 : 私は 4 年経ちました。 新居 : もうそんなに経つんですね。みなさんの前職を転職しようと思った動機とはどんなものだったんですか? 平山 : 前職でプレイングマネージャとして業務をしてきましたが、キャリアを重ねてくると徐々にマネジメントの割合が増えてきます。それ自体は自然なことではあるのですが、前職の延長線上でマネジメントに比重を置くことに対して、危機感を感じていたんです。手を動かす部分を含めて、エンジニアとして良いキャリアを積むには別の環境に身を置く必要があると思い、転職を決意しました。 転職に際しては、自分が 身近に感じるサービスで特に自分の家族が関わるような領域が良いと考えており、医療はそうした意味でぴったりな領域 でした。これらの条件で転職エージェントを通じてメドレーに辿りつきました。 平山さん 岡村 : 先程も少し話しましたが、前職は自社プロダクトと他社向けコンサルティングを並行して運営していた会社でした。しかし、途中から経営方針が変わってコンサルティング業務をメインに据えるようになったんです。自分としては、自社プロダクトを作っている点を大事に考えていたため、転職を考えはじめました。 会社選びの軸としては、もちろん自社サービスが事業の主軸である会社というのが一番でした。他の条件としては「上場一歩手前」くらいのフェイズの会社というものがありました。これは、そのくらいのフェイズの会社であれば今までやっていた事業をいきなりピボットするという可能性が限りなく低いのではないかと考えたからです。そんな感じで会社を探していて、LinkedIn の広告経由でメドレーにアプローチして入社しました。 新居 : 岡村さんは次の会社の事業領域は、意識していたんでしょうか? 岡村 : 医療領域を名指しで考えていたわけではないです。しかし、いわゆる 昔ながらの慣習などが多く残るような業界や領域を、自分達が手がけたサービスで変えていくというのが良い という考えでした。これは前職でも考えていたことだったので、引き続き志向していました。 メドレー入社後にどのような仕事をしていたのか 新居 : ありがとうございます。そんな経緯でメドレーに入社したお二人ですが、入社後はどのような業務をされていたんでしょうか。 平山 : 私は入社後から一貫して CLINICS カルテを担当しています。入社後は医療に関する業務知識を身につけながら、周辺業務から徐々に関わっていきシステム面のキャッチアップをしていきました。一番最初に携わったプロジェクトとしては、CLINICS カルテにおける診察業務のコントロールを担う「診療ステータス」の拡張を行うという、カルテ全体に影響のある大きな改修に携わりました。それ以降も、小さいタスクを捌きつつ、中・大規模な施策に携わってきた感じです。 そこから医療 PF 横断のプロジェクトにも関わっていくようになりました。CLINICS というプロダクトは患者が使用するアプリを始め、調剤・歯科のサービスも提供しています。 医療 PF 全体の体験設計を踏まえて、周辺プロダクトとも積極的に関わっていく必要がある という点は特徴的だと思います。 岡村 : 私は入社当時は「社長室コンサル」という役割で入社し、この部署は M&A などをメインに担当していた部署だったんです。そのため最初にアサインされたのが NaCl メディカル社(現在はメドレー本体に統合)の業務面での PMI でした。これと平行して、現在も引き続き携わっている新しいレセコンを作るプロジェクトのプロダクトマネージャを担当してきました。 新規レセコンは CLINICS カルテと連携しているプロダクトなので、平山さんが率いるチームと連携 しながら、このプロダクトを作っている開発チームを率いています。 GM としてのミッションと就任してから変わったこと・変わらないこと 新居 : 話を聞いていると、お二人とも最初の仕事を順調にスケールアップしていったという形で現在の業務に繋っているんですね。さて、ここからは GM に就任してからの自身の業務がどのように変化してきたのかという点を聞きたいのですが、この点どうでしょうか。 平山 : ミッションはやはり変化しました。GM としてのミッションで一番求められるものは「 プロダクトを前進させる 」という部分と考えています。自身の管掌組織は当然ですが、組織を横断する形の取り組みも必要になります。 「ピープルマネジメント」という点も GM としての変化の１つかなと思います。とはいえ、先ほどの話と通じる部分はあり**「プロダクトに軸足を置いて目線を合わせていくこと」が基本**となります。また、組織上の持続可能性という意味においても「任せていく」というところは大事にしています。メンバーに優秀な方が多いので助けられている部分は多いと感じます。 エンジニアリングという意味では、手を動かす量は減りました。手の動かし方という意味では入社当初から横の動きを見るようにはしていたので GM になって変わったという部分は無いですね。 岡村 : レセコン新規開発プロジェクトでの GM のミッションとして、「プロジェクトの完遂」、「チームメンバーのピープルマネジメント」、「Tech Studio MATSUE(島根県にあるメドレーの拠点。レセコン新規開発プロジェクトの開発をしている)の管理」がメインになります。 GM に就任したタイミングは NaCl メディカル社がメドレー本体に吸収合併されたというタイミングでした。就任前はグループ会社ということもあり、開発業務を受発注するという動きに近い感じで協業してきました。GM になってからは、同じ会社になったのでより近い距離でチーム開発をするようになったり、メンバーのピープルマネジメントの割合が多くなるという変化がありました。 担当領域としてはレセコンのプロダクトマネジメントをしているという部分は変わらない部分です。また平山さんがおっしゃっていたように、いつまでも自分が上にいて指揮するという状態を良しとするのではなく、 メンバーの人をどんどんと上のロールに引き上げていくというのが GM の役割の 1 つ かと思うので、そういう意識でメンバーのマネジメントをしています。 エンジニアリングとマネジメントの比率はプロダクトのフェイズによって変わってくるし、変わるべきかなと思っています。現在は 8 対 2 でマネジメントの比率が多くなっています。一方でプロダクトの初期でどんどんと開発をしていかないといけないという場合には自分も含めて人手をかけて開発していくようにします。 新居 : お話をうかがうと、やはり GM 前よりもマネジメントの比率が多くなっているのではないかと思うのですが、葛藤などはありましたか。 平山 : 元々の自分のスタンスとして「自分も駒の一つ」としてプロダクト開発を推進していくという思考があります。GM の話が来たときにも、やれるかなという不安感はありましたが、今の場面においては自身がやった方が良いと感じて受けました。 岡村 : 私は出自がエンジニアではないというのもあって、葛藤のようなものも平山さんとは違って、特にありませんでした。元々 NaCl メディカル社だった松江オフィスとのハブになるのは、自分しかいないと思っていましたので躊躇のようなものも全く無かったです。 GM で苦労したポイント・どう克服していたか 新居 : ありがとうございます。では、GM になって苦労したとか大変だったというところってどんなところがありましたか。 平山 : 自分は口下手な方なんで、以前より喋る機会が増えたのが困ったところですね（笑） 新居 : 平山さんに口下手な印象は全然ありませんが（笑） 平山 : 他には、これはどちらかというと PdM 属性の仕事にも関わってくるんですが、開発計画の策定は大変です(メドレーでは 3 ヶ月ごとに開発計画を立てている)。 大規模な施策の実施と並行して優先度の高いタスクの差し込みを踏まえて、優先度の再設計や施策のフェージングや運用の検討したりしています。 自分で抱え込む必要はないですが、関係者と調整しつつも最終意思決定は自分になるので、様々な葛藤をしながら取り組んでいます 。 新居 : ピープルマネジメント面では何かありましたか。 平山 : 先程お話した「プロダクトに軸足を置いて目線を合わせていくこと」を大切にコミュニケーションを実施し、日々の業務を通してメンバー一人一人でシナジーが出る・良いキャリアが重ねられるようにしたいと考えていますが、先ほどの開発計画の難しさもここにあります。 新居 : ありがとうございます。では岡村さんはいかがでしょう。 岡村 : 平山さんに全く同感ですね（笑） 冗談は置いておいて、計画外の差し込みタスクなどが入ると、どうしてもチームの負荷が高くなってくるので、そこをコントロールしきれずに申し訳ないなと思うことがあります。 他には、メンバーのキャリア形成をどうするかという点が難しいと思います。 メンバーの志向に合わせての将来像を見据えて現在の業務に取り組んでもらいたい のですが、実際のタスクとそうしたキャリアの方向性が必ずしもぴったりと合うときばかりではないので、ここをどう揃えていくかという点にも苦労はしています。 新居 : なるほど、岡村さんの場合は元々として島根と東京という立地間でのマネジメントをされていたと思うんですが、リモートコミュニケーションが中心という環境での苦労は何かありましたか。 岡村 : 実はこれと言って無いんですよ。それでもちゃんと上手く機能している要因としては、2 つあります。1 つは島根の方に現地のメンバーを取りしきってくれるスキルを持ったメンバーが居てくれたことです。ここは今でも本当に助かっています。 また、当初から技術的な部分も含めて私もメンバーと一緒に勉強しながら、新しい取り組みをするというスタンスを持ってプロジェクトを推進できたことです。ですので、離れたところから命令する人のような感じではなく、 チームで一緒にプロジェクトを進める人という認識を持ってもらえた んじゃないかなと考えています。 もちろん、関係値を作れるまでは私が最初の頃は 1 ヶ月に 1~2 回程度島根に出張して、実際にメンバーと会ったりすることもしていましたが。 GM を担う上で、役に立った経験・知識 新居 : ここからは、お二人が今までの業務の中で積んできた経験・知識の内、現在 GM として活動する上で役に立っているものとして、どんなものがあるのか聞ければと思います。 平山 : そうですね、一番役に立っているなと感じているのは前職で経験した「 様々なステークホルダーとの主体性を持った折衝経験 」です。色々な会社や立場の方とコミュニケーションを取ることが多かったんですね。専門性もそれぞれ違う方達とお話して物事を進める経験ができたことは、今の GM という役割に本当に役立っていると思います。 岡村 : 私が役に立っていると感じる経験は、「 一回深く細かいところまで業務を見てみて理解をしてから、改めて俯瞰した視点で業務を見直してメンバーにお願いする 」という習慣です。この相反する方法をバランス良くできるようになっているというのが、良い点なのかなと思っています。また、深く見るというのは自分が興味を持っている分野でないと中々難しいので、何にでも興味を持って業務に取り組むという心持ちも必要になるかと考えています。 こうした形で業務を分解してメンバーにお願いできるところはしながら、GM としては適切に権限委譲していくというのに役立っています。 エンジニアのピープルマネジメントで意識していること 新居 : 今までのお話でも少し出ている話題になるのですが、GM としてエンジニアのマネジメントで意識しているポイントって、どんなことがありますか。 平山 : 自分達が作る プロダクトへの興味関心・解像度を高め、何を作るのか 。という点において各所コミュニケーションを含めて主体的に動くこと。そうした積み重ねの延長線上にあるエンジニアとしてのキャリア形成を意識しています。 この考え方に加えて「プロダクトの持続可能性を高める」というテーマで、エンジニア・デザイナー・ディレクター・ QA エンジニア・カスタマーサクセスといったプロダクトに関わる人達の専門性を踏まえたタスクの再配布・プロジェクト設計を行う。といった体制作りも推進しようとしています。 新居 : 「プロダクトの持続可能性を高める」というのは、すごく難しい試みですよね。 平山 : 確かにとても難しいなと思います。でも打ち手としては色々あるのではないかと考えていて。「属人性の排除」といった点は、分かりやすいのではないかなと思います。誰かに依存した状態は、組織変更や事業スケールの変化に弱くなりがちですよね。 大事なのは「人から組織への移行」「仕組み化」と捉えています。「できる人を増やす」については、大事だけど秘伝のタレが受け継がれるだけになってしまうので、持続可能性の観点では本質的ではないかなと。 一方で「仕組み化するための計画的な属人性」については推奨できると考えてます。新しいことをいきなり「組織に転換」や「人を増やしてローテする」だと、ナレッジが蓄積されづらく、次の一手が打ちづらくなるので。 新居 : そうした取り組みをするのに、例えばエンジニアだと作ってみたものがプロダクトの目指す方向性とズレが生じていたというような事態があると思うんですが、そうしたズレを事前に仕組みで抑えるような事をしているんですか。 平山 : きっちりとした仕組みなどは作ってはいないです。仕組み化というよりも、そうならないように メンバーから上がってきた疑問などに対する壁打ちなどは気軽にできる ようにしています。また、そういった相談を気軽にできるような自分自身のプロデュースといいますか、キャラ作りみたいなものも含めてメンバーが相談しにくいという空気を作らないようにはしていますね。 新居 : ありがとうございます。岡村さんはどんな意識をしていますか。 岡村 : やっぱり平山さんに全く同感ですね（笑） 付け加えると、ソフト面ですが メンバーであるエンジニアが楽しめる環境作り というところを意識しています。楽しさにも色々な種類があるとは思いますが、単にコーディングするだけではなく、やはりプロダクトそれ自体の提供価値というものをしっかりと共有して、プロダクトを作ること自体に楽しさを感じてもらう…というのは重要じゃないかなと思っています。 また楽しさの別側面ですが、新しいテクノロジーなどもどんどんと取り入れることができるような仕組み作りもしています。島根のメンバーは今回のプロジェクトで初めて Ruby を使うというメンバーも多かったので、ここで楽しさを感じられないと、こうしたテクノロジー自体を嫌いになってしまう恐れがあるなと思ったので。 そうした「楽しい仕事」にしていくと「時間をかけなきゃ」ではなく「時間をかけたい」という感じで取り組めるようになると思います。 GM という役割の醍醐味とは 新居 : それでは終盤になってきましたが、GM の「やりがい」や「醍醐味」はどういったものになりますか。 岡村 : 一番は「ピープルマネジメント」になるんじゃないかと考えています。最近、岸田首相の所信表明演説で聞いて感銘を受けたアフリカの諺ですが「早く行きたいなら 1 人で行け、遠くへ行きたいならみんなで行け」という言葉はピープルマネジメントの本質なんじゃないかなと思っています。 メンバーと一緒に遠くに行くために組織作り などをしていけるのが醍醐味だと感じています。 平山 : メンバーの 個人スキルを高めつつ「チーム」に還元してもらうための仕組み を作っていく。というのは、醍醐味と言えるのかなと。CTO インタビューで田中も言っていますが「チームバリュー」は大切だと考えています。 チームといっても、狭義のチームではなくプロダクトに関わる関係者全員を含めたチームという感じで意識しています。開発組織に閉じないバリューの発揮がメンバーそれぞれでできると心強いと思います。 メドレーで GM やリードエンジニアのロールに向いている方 新居 : 最後になるのですが、メドレーで GM やテックリードといったロールに向いているのは、どんな人だと思いますか。 平山 : 基本的に 物事を前に進めるための解像度を高く描ける人 かなと思っています。何を誰のためにというのを体現しつつ、関係者を引っぱっていける人ですね。メドレーの Our Essentials 全般必要だとは思いますが、その中でも「成果を出す」「自分をアップデート」「組織水準を高める」「革新と改善を主導」というところが必要になるかな。困難な状況でも結果を出しつつ、自分の行動も高めていき、結果組織・プロダクトを良くしていける…というのがメドレーのリードと呼ばれているエンジニアかと思います。 やり方としては、マイクロマネジメントではなく、基本となる考え方をちゃんと伝えてメンバーに学んでもらう…という、やり方ができる人が向いていると思います。 岡村 : 困難な状況であっても何とかして前に進めることができる人 でしょうか。無理矢理に進めるというわけではなく、状況の整理や色々な部署との調整などもしたりして、何とか結果という形にしていける能力がある人がリードとしてメンバーを引っぱっていける人だと思います。 もちろん、フェイズによってメンバーとの関わりなどはちゃんと調整していける柔軟さなども必要になると思います。 新居 : なるほど。本日は色々なお話をしていただきまして、ありがとうございました! さいごに メドレーの GM 二人に仕事について聞いていきました。 前回の CTO インタビューでも語られた開発組織の話ですが、より現場に近い GM という立場のメンバーからの話でまた違った雰囲気などを感じていただけたかと思います。 このような GM を「ぜひやりたい!」という方や「こんな上司の元で自分の力を発揮していきたい!」という方はぜひカジュアルにお話ができればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。 今回のインタビューは前回の CTO へのインタビュー に続いて、メドレーの開発組織についてご紹介していきたいと思います。 メドレーでは開発組織をリードするロールとして、CTO の他、「グループマネージャ」(以下、GM)という役職があります。今回は医療プラットフォーム(以下、医療 PF)における開発グループの GM を担う二人に、具体的にどのような役割なのか聞いていきます。 インタビュイー紹介 今回の紹介はインタビュー中で前職からメドレー入社の話を聞いているので、シンプルにお送りします。 平山さん 医療 PF 第一本部 プロダクト開発室 第四開発グループ GM。現在は CLINICS 基幹システムチームのマネジメントを担当。 岡村さん 医療 PF 第一本部 プロダクト開発室 第三開発グループ GM。現在はレセコン(電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア)新規開発チームのマネジメントを担当。 左から岡村さん、平山さん、筆者 前職までの経歴とメドレー入社の理由について 二人の経験について 新居 : 早速始めていきますが、まずはお二人の経歴を教えていただきたいと思います。 平山 : メドレーは 2 社目の会社となります。前職は SIer で 14~5 年くらい受託開発や客先常駐して開発をしていました。SIer というと場合によっては二次請け・三次請けの開発をしているところもあるんですが、自分は一次請けとして直接顧客と関わる形で業務を行っていました。 顧客のサービスをステークホルダーと提案・折衝しながら、技術選定・要件定義から開発、リリースまで行い、そこからの保守運用といった部分までの一連の流れを様々な業態の顧客と関わらせて頂きました。 新居 : ありがとうございます。かなり自社開発と同じ感覚の開発を長年されてきたんですね。それでは、岡村さんお願いします。 岡村 : 新卒で外資系の IT コンサルティング会社で IT コンサルタントとしてキャリアを始めました。その中でも特に「情報系」と呼ばれるデータアナリティクスや BI (Business Intelligence) などを取り扱う部門で業務をしていました。領域的には金融・製薬・省庁など堅めの領域を主に担当していたので、いわゆる Web アプリケーションを作るというよりは SQL をガリガリ書いてデータ分析を基に業務改善していく…という感じの業務が多かったです。 2 社目はスタートアップ企業の立ち上げフェイズにジョインしました。その会社はいわゆる Insure Tech と呼ばれる保険業界 x テクノロジー領域のサービスを作っている会社でした。そこで、その会社でのプロダクトマネージャ業務と、運転資金を確保するために大手保険会社向けのコンサルタント業務に半々で従事していました。 その後にメドレーにジョインするという経歴です。 岡村さん メドレー入社の経緯について 新居 : ありがとうございます、お二人はメドレーに入社してどのくらい経ちますっけ? 平山 : 私は 3 年半ですね。 岡村 : 私は 4 年経ちました。 新居 : もうそんなに経つんですね。みなさんの前職を転職しようと思った動機とはどんなものだったんですか? 平山 : 前職でプレイングマネージャとして業務をしてきましたが、キャリアを重ねてくると徐々にマネジメントの割合が増えてきます。それ自体は自然なことではあるのですが、前職の延長線上でマネジメントに比重を置くことに対して、危機感を感じていたんです。手を動かす部分を含めて、エンジニアとして良いキャリアを積むには別の環境に身を置く必要があると思い、転職を決意しました。 転職に際しては、自分が 身近に感じるサービスで特に自分の家族が関わるような領域が良いと考えており、医療はそうした意味でぴったりな領域 でした。これらの条件で転職エージェントを通じてメドレーに辿りつきました。 平山さん 岡村 : 先程も少し話しましたが、前職は自社プロダクトと他社向けコンサルティングを並行して運営していた会社でした。しかし、途中から経営方針が変わってコンサルティング業務をメインに据えるようになったんです。自分としては、自社プロダクトを作っている点を大事に考えていたため、転職を考えはじめました。 会社選びの軸としては、もちろん自社サービスが事業の主軸である会社というのが一番でした。他の条件としては「上場一歩手前」くらいのフェイズの会社というものがありました。これは、そのくらいのフェイズの会社であれば今までやっていた事業をいきなりピボットするという可能性が限りなく低いのではないかと考えたからです。そんな感じで会社を探していて、LinkedIn の広告経由でメドレーにアプローチして入社しました。 新居 : 岡村さんは次の会社の事業領域は、意識していたんでしょうか? 岡村 : 医療領域を名指しで考えていたわけではないです。しかし、いわゆる 昔ながらの慣習などが多く残るような業界や領域を、自分達が手がけたサービスで変えていくというのが良い という考えでした。これは前職でも考えていたことだったので、引き続き志向していました。 メドレー入社後にどのような仕事をしていたのか 新居 : ありがとうございます。そんな経緯でメドレーに入社したお二人ですが、入社後はどのような業務をされていたんでしょうか。 平山 : 私は入社後から一貫して CLINICS カルテを担当しています。入社後は医療に関する業務知識を身につけながら、周辺業務から徐々に関わっていきシステム面のキャッチアップをしていきました。一番最初に携わったプロジェクトとしては、CLINICS カルテにおける診察業務のコントロールを担う「診療ステータス」の拡張を行うという、カルテ全体に影響のある大きな改修に携わりました。それ以降も、小さいタスクを捌きつつ、中・大規模な施策に携わってきた感じです。 そこから医療 PF 横断のプロジェクトにも関わっていくようになりました。CLINICS というプロダクトは患者が使用するアプリを始め、調剤・歯科のサービスも提供しています。 医療 PF 全体の体験設計を踏まえて、周辺プロダクトとも積極的に関わっていく必要がある という点は特徴的だと思います。 岡村 : 私は入社当時は「社長室コンサル」という役割で入社し、この部署は M&A などをメインに担当していた部署だったんです。そのため最初にアサインされたのが NaCl メディカル社(現在はメドレー本体に統合)の業務面での PMI でした。これと平行して、現在も引き続き携わっている新しいレセコンを作るプロジェクトのプロダクトマネージャを担当してきました。 新規レセコンは CLINICS カルテと連携しているプロダクトなので、平山さんが率いるチームと連携 しながら、このプロダクトを作っている開発チームを率いています。 GM としてのミッションと就任してから変わったこと・変わらないこと 新居 : 話を聞いていると、お二人とも最初の仕事を順調にスケールアップしていったという形で現在の業務に繋っているんですね。さて、ここからは GM に就任してからの自身の業務がどのように変化してきたのかという点を聞きたいのですが、この点どうでしょうか。 平山 : ミッションはやはり変化しました。GM としてのミッションで一番求められるものは「 プロダクトを前進させる 」という部分と考えています。自身の管掌組織は当然ですが、組織を横断する形の取り組みも必要になります。 「ピープルマネジメント」という点も GM としての変化の１つかなと思います。とはいえ、先ほどの話と通じる部分はあり**「プロダクトに軸足を置いて目線を合わせていくこと」が基本**となります。また、組織上の持続可能性という意味においても「任せていく」というところは大事にしています。メンバーに優秀な方が多いので助けられている部分は多いと感じます。 エンジニアリングという意味では、手を動かす量は減りました。手の動かし方という意味では入社当初から横の動きを見るようにはしていたので GM になって変わったという部分は無いですね。 岡村 : レセコン新規開発プロジェクトでの GM のミッションとして、「プロジェクトの完遂」、「チームメンバーのピープルマネジメント」、「Tech Studio MATSUE(島根県にあるメドレーの拠点。レセコン新規開発プロジェクトの開発をしている)の管理」がメインになります。 GM に就任したタイミングは NaCl メディカル社がメドレー本体に吸収合併されたというタイミングでした。就任前はグループ会社ということもあり、開発業務を受発注するという動きに近い感じで協業してきました。GM になってからは、同じ会社になったのでより近い距離でチーム開発をするようになったり、メンバーのピープルマネジメントの割合が多くなるという変化がありました。 担当領域としてはレセコンのプロダクトマネジメントをしているという部分は変わらない部分です。また平山さんがおっしゃっていたように、いつまでも自分が上にいて指揮するという状態を良しとするのではなく、 メンバーの人をどんどんと上のロールに引き上げていくというのが GM の役割の 1 つ かと思うので、そういう意識でメンバーのマネジメントをしています。 エンジニアリングとマネジメントの比率はプロダクトのフェイズによって変わってくるし、変わるべきかなと思っています。現在は 8 対 2 でマネジメントの比率が多くなっています。一方でプロダクトの初期でどんどんと開発をしていかないといけないという場合には自分も含めて人手をかけて開発していくようにします。 新居 : お話をうかがうと、やはり GM 前よりもマネジメントの比率が多くなっているのではないかと思うのですが、葛藤などはありましたか。 平山 : 元々の自分のスタンスとして「自分も駒の一つ」としてプロダクト開発を推進していくという思考があります。GM の話が来たときにも、やれるかなという不安感はありましたが、今の場面においては自身がやった方が良いと感じて受けました。 岡村 : 私は出自がエンジニアではないというのもあって、葛藤のようなものも平山さんとは違って、特にありませんでした。元々 NaCl メディカル社だった松江オフィスとのハブになるのは、自分しかいないと思っていましたので躊躇のようなものも全く無かったです。 GM で苦労したポイント・どう克服していたか 新居 : ありがとうございます。では、GM になって苦労したとか大変だったというところってどんなところがありましたか。 平山 : 自分は口下手な方なんで、以前より喋る機会が増えたのが困ったところですね（笑） 新居 : 平山さんに口下手な印象は全然ありませんが（笑） 平山 : 他には、これはどちらかというと PdM 属性の仕事にも関わってくるんですが、開発計画の策定は大変です(メドレーでは 3 ヶ月ごとに開発計画を立てている)。 大規模な施策の実施と並行して優先度の高いタスクの差し込みを踏まえて、優先度の再設計や施策のフェージングや運用の検討したりしています。 自分で抱え込む必要はないですが、関係者と調整しつつも最終意思決定は自分になるので、様々な葛藤をしながら取り組んでいます 。 新居 : ピープルマネジメント面では何かありましたか。 平山 : 先程お話した「プロダクトに軸足を置いて目線を合わせていくこと」を大切にコミュニケーションを実施し、日々の業務を通してメンバー一人一人でシナジーが出る・良いキャリアが重ねられるようにしたいと考えていますが、先ほどの開発計画の難しさもここにあります。 新居 : ありがとうございます。では岡村さんはいかがでしょう。 岡村 : 平山さんに全く同感ですね（笑） 冗談は置いておいて、計画外の差し込みタスクなどが入ると、どうしてもチームの負荷が高くなってくるので、そこをコントロールしきれずに申し訳ないなと思うことがあります。 他には、メンバーのキャリア形成をどうするかという点が難しいと思います。 メンバーの志向に合わせての将来像を見据えて現在の業務に取り組んでもらいたい のですが、実際のタスクとそうしたキャリアの方向性が必ずしもぴったりと合うときばかりではないので、ここをどう揃えていくかという点にも苦労はしています。 新居 : なるほど、岡村さんの場合は元々として島根と東京という立地間でのマネジメントをされていたと思うんですが、リモートコミュニケーションが中心という環境での苦労は何かありましたか。 岡村 : 実はこれと言って無いんですよ。それでもちゃんと上手く機能している要因としては、2 つあります。1 つは島根の方に現地のメンバーを取りしきってくれるスキルを持ったメンバーが居てくれたことです。ここは今でも本当に助かっています。 また、当初から技術的な部分も含めて私もメンバーと一緒に勉強しながら、新しい取り組みをするというスタンスを持ってプロジェクトを推進できたことです。ですので、離れたところから命令する人のような感じではなく、 チームで一緒にプロジェクトを進める人という認識を持ってもらえた んじゃないかなと考えています。 もちろん、関係値を作れるまでは私が最初の頃は 1 ヶ月に 1~2 回程度島根に出張して、実際にメンバーと会ったりすることもしていましたが。 GM を担う上で、役に立った経験・知識 新居 : ここからは、お二人が今までの業務の中で積んできた経験・知識の内、現在 GM として活動する上で役に立っているものとして、どんなものがあるのか聞ければと思います。 平山 : そうですね、一番役に立っているなと感じているのは前職で経験した「 様々なステークホルダーとの主体性を持った折衝経験 」です。色々な会社や立場の方とコミュニケーションを取ることが多かったんですね。専門性もそれぞれ違う方達とお話して物事を進める経験ができたことは、今の GM という役割に本当に役立っていると思います。 岡村 : 私が役に立っていると感じる経験は、「 一回深く細かいところまで業務を見てみて理解をしてから、改めて俯瞰した視点で業務を見直してメンバーにお願いする 」という習慣です。この相反する方法をバランス良くできるようになっているというのが、良い点なのかなと思っています。また、深く見るというのは自分が興味を持っている分野でないと中々難しいので、何にでも興味を持って業務に取り組むという心持ちも必要になるかと考えています。 こうした形で業務を分解してメンバーにお願いできるところはしながら、GM としては適切に権限委譲していくというのに役立っています。 エンジニアのピープルマネジメントで意識していること 新居 : 今までのお話でも少し出ている話題になるのですが、GM としてエンジニアのマネジメントで意識しているポイントって、どんなことがありますか。 平山 : 自分達が作る プロダクトへの興味関心・解像度を高め、何を作るのか 。という点において各所コミュニケーションを含めて主体的に動くこと。そうした積み重ねの延長線上にあるエンジニアとしてのキャリア形成を意識しています。 この考え方に加えて「プロダクトの持続可能性を高める」というテーマで、エンジニア・デザイナー・ディレクター・ QA エンジニア・カスタマーサクセスといったプロダクトに関わる人達の専門性を踏まえたタスクの再配布・プロジェクト設計を行う。といった体制作りも推進しようとしています。 新居 : 「プロダクトの持続可能性を高める」というのは、すごく難しい試みですよね。 平山 : 確かにとても難しいなと思います。でも打ち手としては色々あるのではないかと考えていて。「属人性の排除」といった点は、分かりやすいのではないかなと思います。誰かに依存した状態は、組織変更や事業スケールの変化に弱くなりがちですよね。 大事なのは「人から組織への移行」「仕組み化」と捉えています。「できる人を増やす」については、大事だけど秘伝のタレが受け継がれるだけになってしまうので、持続可能性の観点では本質的ではないかなと。 一方で「仕組み化するための計画的な属人性」については推奨できると考えてます。新しいことをいきなり「組織に転換」や「人を増やしてローテする」だと、ナレッジが蓄積されづらく、次の一手が打ちづらくなるので。 新居 : そうした取り組みをするのに、例えばエンジニアだと作ってみたものがプロダクトの目指す方向性とズレが生じていたというような事態があると思うんですが、そうしたズレを事前に仕組みで抑えるような事をしているんですか。 平山 : きっちりとした仕組みなどは作ってはいないです。仕組み化というよりも、そうならないように メンバーから上がってきた疑問などに対する壁打ちなどは気軽にできる ようにしています。また、そういった相談を気軽にできるような自分自身のプロデュースといいますか、キャラ作りみたいなものも含めてメンバーが相談しにくいという空気を作らないようにはしていますね。 新居 : ありがとうございます。岡村さんはどんな意識をしていますか。 岡村 : やっぱり平山さんに全く同感ですね（笑） 付け加えると、ソフト面ですが メンバーであるエンジニアが楽しめる環境作り というところを意識しています。楽しさにも色々な種類があるとは思いますが、単にコーディングするだけではなく、やはりプロダクトそれ自体の提供価値というものをしっかりと共有して、プロダクトを作ること自体に楽しさを感じてもらう…というのは重要じゃないかなと思っています。 また楽しさの別側面ですが、新しいテクノロジーなどもどんどんと取り入れることができるような仕組み作りもしています。島根のメンバーは今回のプロジェクトで初めて Ruby を使うというメンバーも多かったので、ここで楽しさを感じられないと、こうしたテクノロジー自体を嫌いになってしまう恐れがあるなと思ったので。 そうした「楽しい仕事」にしていくと「時間をかけなきゃ」ではなく「時間をかけたい」という感じで取り組めるようになると思います。 GM という役割の醍醐味とは 新居 : それでは終盤になってきましたが、GM の「やりがい」や「醍醐味」はどういったものになりますか。 岡村 : 一番は「ピープルマネジメント」になるんじゃないかと考えています。最近、岸田首相の所信表明演説で聞いて感銘を受けたアフリカの諺ですが「早く行きたいなら 1 人で行け、遠くへ行きたいならみんなで行け」という言葉はピープルマネジメントの本質なんじゃないかなと思っています。 メンバーと一緒に遠くに行くために組織作り などをしていけるのが醍醐味だと感じています。 平山 : メンバーの 個人スキルを高めつつ「チーム」に還元してもらうための仕組み を作っていく。というのは、醍醐味と言えるのかなと。CTO インタビューで田中も言っていますが「チームバリュー」は大切だと考えています。 チームといっても、狭義のチームではなくプロダクトに関わる関係者全員を含めたチームという感じで意識しています。開発組織に閉じないバリューの発揮がメンバーそれぞれでできると心強いと思います。 メドレーで GM やリードエンジニアのロールに向いている方 新居 : 最後になるのですが、メドレーで GM やテックリードといったロールに向いているのは、どんな人だと思いますか。 平山 : 基本的に 物事を前に進めるための解像度を高く描ける人 かなと思っています。何を誰のためにというのを体現しつつ、関係者を引っぱっていける人ですね。メドレーの Our Essentials 全般必要だとは思いますが、その中でも「成果を出す」「自分をアップデート」「組織水準を高める」「革新と改善を主導」というところが必要になるかな。困難な状況でも結果を出しつつ、自分の行動も高めていき、結果組織・プロダクトを良くしていける…というのがメドレーのリードと呼ばれているエンジニアかと思います。 やり方としては、マイクロマネジメントではなく、基本となる考え方をちゃんと伝えてメンバーに学んでもらう…という、やり方ができる人が向いていると思います。 岡村 : 困難な状況であっても何とかして前に進めることができる人 でしょうか。無理矢理に進めるというわけではなく、状況の整理や色々な部署との調整などもしたりして、何とか結果という形にしていける能力がある人がリードとしてメンバーを引っぱっていける人だと思います。 もちろん、フェイズによってメンバーとの関わりなどはちゃんと調整していける柔軟さなども必要になると思います。 新居 : なるほど。本日は色々なお話をしていただきまして、ありがとうございました! さいごに メドレーの GM 二人に仕事について聞いていきました。 前回の CTO インタビューでも語られた開発組織の話ですが、より現場に近い GM という立場のメンバーからの話でまた違った雰囲気などを感じていただけたかと思います。 このような GM を「ぜひやりたい!」という方や「こんな上司の元で自分の力を発揮していきたい!」という方はぜひカジュアルにお話ができればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。 今回のインタビューは前回の CTO へのインタビュー に続いて、メドレーの開発組織についてご紹介していきたいと思います。 メドレーでは開発組織をリードするロールとして、CTO の他、「グループマネージャ」(以下、GM)という役職があります。今回は医療プラットフォーム(以下、医療 PF)における開発グループの GM を担う二人に、具体的にどのような役割なのか聞いていきます。 インタビュイー紹介 今回の紹介はインタビュー中で前職からメドレー入社の話を聞いているので、シンプルにお送りします。 平山さん 医療 PF 第一本部 プロダクト開発室 第四開発グループ GM。現在は CLINICS 基幹システムチームのマネジメントを担当。 岡村さん 医療 PF 第一本部 プロダクト開発室 第三開発グループ GM。現在はレセコン(電子カルテの機能のうち主に会計など診療報酬の計算をするソフトウェア)新規開発チームのマネジメントを担当。 左から岡村さん、平山さん、筆者 前職までの経歴とメドレー入社の理由について 二人の経験について 新居 : 早速始めていきますが、まずはお二人の経歴を教えていただきたいと思います。 平山 : メドレーは 2 社目の会社となります。前職は SIer で 14~5 年くらい受託開発や客先常駐して開発をしていました。SIer というと場合によっては二次請け・三次請けの開発をしているところもあるんですが、自分は一次請けとして直接顧客と関わる形で業務を行っていました。 顧客のサービスをステークホルダーと提案・折衝しながら、技術選定・要件定義から開発、リリースまで行い、そこからの保守運用といった部分までの一連の流れを様々な業態の顧客と関わらせて頂きました。 新居 : ありがとうございます。かなり自社開発と同じ感覚の開発を長年されてきたんですね。それでは、岡村さんお願いします。 岡村 : 新卒で外資系の IT コンサルティング会社で IT コンサルタントとしてキャリアを始めました。その中でも特に「情報系」と呼ばれるデータアナリティクスや BI (Business Intelligence) などを取り扱う部門で業務をしていました。領域的には金融・製薬・省庁など堅めの領域を主に担当していたので、いわゆる Web アプリケーションを作るというよりは SQL をガリガリ書いてデータ分析を基に業務改善していく…という感じの業務が多かったです。 2 社目はスタートアップ企業の立ち上げフェイズにジョインしました。その会社はいわゆる Insure Tech と呼ばれる保険業界 x テクノロジー領域のサービスを作っている会社でした。そこで、その会社でのプロダクトマネージャ業務と、運転資金を確保するために大手保険会社向けのコンサルタント業務に半々で従事していました。 その後にメドレーにジョインするという経歴です。 岡村さん メドレー入社の経緯について 新居 : ありがとうございます、お二人はメドレーに入社してどのくらい経ちますっけ? 平山 : 私は 3 年半ですね。 岡村 : 私は 4 年経ちました。 新居 : もうそんなに経つんですね。みなさんの前職を転職しようと思った動機とはどんなものだったんですか? 平山 : 前職でプレイングマネージャとして業務をしてきましたが、キャリアを重ねてくると徐々にマネジメントの割合が増えてきます。それ自体は自然なことではあるのですが、前職の延長線上でマネジメントに比重を置くことに対して、危機感を感じていたんです。手を動かす部分を含めて、エンジニアとして良いキャリアを積むには別の環境に身を置く必要があると思い、転職を決意しました。 転職に際しては、自分が 身近に感じるサービスで特に自分の家族が関わるような領域が良いと考えており、医療はそうした意味でぴったりな領域 でした。これらの条件で転職エージェントを通じてメドレーに辿りつきました。 平山さん 岡村 : 先程も少し話しましたが、前職は自社プロダクトと他社向けコンサルティングを並行して運営していた会社でした。しかし、途中から経営方針が変わってコンサルティング業務をメインに据えるようになったんです。自分としては、自社プロダクトを作っている点を大事に考えていたため、転職を考えはじめました。 会社選びの軸としては、もちろん自社サービスが事業の主軸である会社というのが一番でした。他の条件としては「上場一歩手前」くらいのフェイズの会社というものがありました。これは、そのくらいのフェイズの会社であれば今までやっていた事業をいきなりピボットするという可能性が限りなく低いのではないかと考えたからです。そんな感じで会社を探していて、LinkedIn の広告経由でメドレーにアプローチして入社しました。 新居 : 岡村さんは次の会社の事業領域は、意識していたんでしょうか? 岡村 : 医療領域を名指しで考えていたわけではないです。しかし、いわゆる 昔ながらの慣習などが多く残るような業界や領域を、自分達が手がけたサービスで変えていくというのが良い という考えでした。これは前職でも考えていたことだったので、引き続き志向していました。 メドレー入社後にどのような仕事をしていたのか 新居 : ありがとうございます。そんな経緯でメドレーに入社したお二人ですが、入社後はどのような業務をされていたんでしょうか。 平山 : 私は入社後から一貫して CLINICS カルテを担当しています。入社後は医療に関する業務知識を身につけながら、周辺業務から徐々に関わっていきシステム面のキャッチアップをしていきました。一番最初に携わったプロジェクトとしては、CLINICS カルテにおける診察業務のコントロールを担う「診療ステータス」の拡張を行うという、カルテ全体に影響のある大きな改修に携わりました。それ以降も、小さいタスクを捌きつつ、中・大規模な施策に携わってきた感じです。 そこから医療 PF 横断のプロジェクトにも関わっていくようになりました。CLINICS というプロダクトは患者が使用するアプリを始め、調剤・歯科のサービスも提供しています。 医療 PF 全体の体験設計を踏まえて、周辺プロダクトとも積極的に関わっていく必要がある という点は特徴的だと思います。 岡村 : 私は入社当時は「社長室コンサル」という役割で入社し、この部署は M&A などをメインに担当していた部署だったんです。そのため最初にアサインされたのが NaCl メディカル社(現在はメドレー本体に統合)の業務面での PMI でした。これと平行して、現在も引き続き携わっている新しいレセコンを作るプロジェクトのプロダクトマネージャを担当してきました。 新規レセコンは CLINICS カルテと連携しているプロダクトなので、平山さんが率いるチームと連携 しながら、このプロダクトを作っている開発チームを率いています。 GM としてのミッションと就任してから変わったこと・変わらないこと 新居 : 話を聞いていると、お二人とも最初の仕事を順調にスケールアップしていったという形で現在の業務に繋っているんですね。さて、ここからは GM に就任してからの自身の業務がどのように変化してきたのかという点を聞きたいのですが、この点どうでしょうか。 平山 : ミッションはやはり変化しました。GM としてのミッションで一番求められるものは「 プロダクトを前進させる 」という部分と考えています。自身の管掌組織は当然ですが、組織を横断する形の取り組みも必要になります。 「ピープルマネジメント」という点も GM としての変化の１つかなと思います。とはいえ、先ほどの話と通じる部分はあり**「プロダクトに軸足を置いて目線を合わせていくこと」が基本**となります。また、組織上の持続可能性という意味においても「任せていく」というところは大事にしています。メンバーに優秀な方が多いので助けられている部分は多いと感じます。 エンジニアリングという意味では、手を動かす量は減りました。手の動かし方という意味では入社当初から横の動きを見るようにはしていたので GM になって変わったという部分は無いですね。 岡村 : レセコン新規開発プロジェクトでの GM のミッションとして、「プロジェクトの完遂」、「チームメンバーのピープルマネジメント」、「Tech Studio MATSUE(島根県にあるメドレーの拠点。レセコン新規開発プロジェクトの開発をしている)の管理」がメインになります。 GM に就任したタイミングは NaCl メディカル社がメドレー本体に吸収合併されたというタイミングでした。就任前はグループ会社ということもあり、開発業務を受発注するという動きに近い感じで協業してきました。GM になってからは、同じ会社になったのでより近い距離でチーム開発をするようになったり、メンバーのピープルマネジメントの割合が多くなるという変化がありました。 担当領域としてはレセコンのプロダクトマネジメントをしているという部分は変わらない部分です。また平山さんがおっしゃっていたように、いつまでも自分が上にいて指揮するという状態を良しとするのではなく、 メンバーの人をどんどんと上のロールに引き上げていくというのが GM の役割の 1 つ かと思うので、そういう意識でメンバーのマネジメントをしています。 エンジニアリングとマネジメントの比率はプロダクトのフェイズによって変わってくるし、変わるべきかなと思っています。現在は 8 対 2 でマネジメントの比率が多くなっています。一方でプロダクトの初期でどんどんと開発をしていかないといけないという場合には自分も含めて人手をかけて開発していくようにします。 新居 : お話をうかがうと、やはり GM 前よりもマネジメントの比率が多くなっているのではないかと思うのですが、葛藤などはありましたか。 平山 : 元々の自分のスタンスとして「自分も駒の一つ」としてプロダクト開発を推進していくという思考があります。GM の話が来たときにも、やれるかなという不安感はありましたが、今の場面においては自身がやった方が良いと感じて受けました。 岡村 : 私は出自がエンジニアではないというのもあって、葛藤のようなものも平山さんとは違って、特にありませんでした。元々 NaCl メディカル社だった松江オフィスとのハブになるのは、自分しかいないと思っていましたので躊躇のようなものも全く無かったです。 GM で苦労したポイント・どう克服していたか 新居 : ありがとうございます。では、GM になって苦労したとか大変だったというところってどんなところがありましたか。 平山 : 自分は口下手な方なんで、以前より喋る機会が増えたのが困ったところですね（笑） 新居 : 平山さんに口下手な印象は全然ありませんが（笑） 平山 : 他には、これはどちらかというと PdM 属性の仕事にも関わってくるんですが、開発計画の策定は大変です(メドレーでは 3 ヶ月ごとに開発計画を立てている)。 大規模な施策の実施と並行して優先度の高いタスクの差し込みを踏まえて、優先度の再設計や施策のフェージングや運用の検討したりしています。 自分で抱え込む必要はないですが、関係者と調整しつつも最終意思決定は自分になるので、様々な葛藤をしながら取り組んでいます 。 新居 : ピープルマネジメント面では何かありましたか。 平山 : 先程お話した「プロダクトに軸足を置いて目線を合わせていくこと」を大切にコミュニケーションを実施し、日々の業務を通してメンバー一人一人でシナジーが出る・良いキャリアが重ねられるようにしたいと考えていますが、先ほどの開発計画の難しさもここにあります。 新居 : ありがとうございます。では岡村さんはいかがでしょう。 岡村 : 平山さんに全く同感ですね（笑） 冗談は置いておいて、計画外の差し込みタスクなどが入ると、どうしてもチームの負荷が高くなってくるので、そこをコントロールしきれずに申し訳ないなと思うことがあります。 他には、メンバーのキャリア形成をどうするかという点が難しいと思います。 メンバーの志向に合わせての将来像を見据えて現在の業務に取り組んでもらいたい のですが、実際のタスクとそうしたキャリアの方向性が必ずしもぴったりと合うときばかりではないので、ここをどう揃えていくかという点にも苦労はしています。 新居 : なるほど、岡村さんの場合は元々として島根と東京という立地間でのマネジメントをされていたと思うんですが、リモートコミュニケーションが中心という環境での苦労は何かありましたか。 岡村 : 実はこれと言って無いんですよ。それでもちゃんと上手く機能している要因としては、2 つあります。1 つは島根の方に現地のメンバーを取りしきってくれるスキルを持ったメンバーが居てくれたことです。ここは今でも本当に助かっています。 また、当初から技術的な部分も含めて私もメンバーと一緒に勉強しながら、新しい取り組みをするというスタンスを持ってプロジェクトを推進できたことです。ですので、離れたところから命令する人のような感じではなく、 チームで一緒にプロジェクトを進める人という認識を持ってもらえた んじゃないかなと考えています。 もちろん、関係値を作れるまでは私が最初の頃は 1 ヶ月に 1~2 回程度島根に出張して、実際にメンバーと会ったりすることもしていましたが。 GM を担う上で、役に立った経験・知識 新居 : ここからは、お二人が今までの業務の中で積んできた経験・知識の内、現在 GM として活動する上で役に立っているものとして、どんなものがあるのか聞ければと思います。 平山 : そうですね、一番役に立っているなと感じているのは前職で経験した「 様々なステークホルダーとの主体性を持った折衝経験 」です。色々な会社や立場の方とコミュニケーションを取ることが多かったんですね。専門性もそれぞれ違う方達とお話して物事を進める経験ができたことは、今の GM という役割に本当に役立っていると思います。 岡村 : 私が役に立っていると感じる経験は、「 一回深く細かいところまで業務を見てみて理解をしてから、改めて俯瞰した視点で業務を見直してメンバーにお願いする 」という習慣です。この相反する方法をバランス良くできるようになっているというのが、良い点なのかなと思っています。また、深く見るというのは自分が興味を持っている分野でないと中々難しいので、何にでも興味を持って業務に取り組むという心持ちも必要になるかと考えています。 こうした形で業務を分解してメンバーにお願いできるところはしながら、GM としては適切に権限委譲していくというのに役立っています。 エンジニアのピープルマネジメントで意識していること 新居 : 今までのお話でも少し出ている話題になるのですが、GM としてエンジニアのマネジメントで意識しているポイントって、どんなことがありますか。 平山 : 自分達が作る プロダクトへの興味関心・解像度を高め、何を作るのか 。という点において各所コミュニケーションを含めて主体的に動くこと。そうした積み重ねの延長線上にあるエンジニアとしてのキャリア形成を意識しています。 この考え方に加えて「プロダクトの持続可能性を高める」というテーマで、エンジニア・デザイナー・ディレクター・ QA エンジニア・カスタマーサクセスといったプロダクトに関わる人達の専門性を踏まえたタスクの再配布・プロジェクト設計を行う。といった体制作りも推進しようとしています。 新居 : 「プロダクトの持続可能性を高める」というのは、すごく難しい試みですよね。 平山 : 確かにとても難しいなと思います。でも打ち手としては色々あるのではないかと考えていて。「属人性の排除」といった点は、分かりやすいのではないかなと思います。誰かに依存した状態は、組織変更や事業スケールの変化に弱くなりがちですよね。 大事なのは「人から組織への移行」「仕組み化」と捉えています。「できる人を増やす」については、大事だけど秘伝のタレが受け継がれるだけになってしまうので、持続可能性の観点では本質的ではないかなと。 一方で「仕組み化するための計画的な属人性」については推奨できると考えてます。新しいことをいきなり「組織に転換」や「人を増やしてローテする」だと、ナレッジが蓄積されづらく、次の一手が打ちづらくなるので。 新居 : そうした取り組みをするのに、例えばエンジニアだと作ってみたものがプロダクトの目指す方向性とズレが生じていたというような事態があると思うんですが、そうしたズレを事前に仕組みで抑えるような事をしているんですか。 平山 : きっちりとした仕組みなどは作ってはいないです。仕組み化というよりも、そうならないように メンバーから上がってきた疑問などに対する壁打ちなどは気軽にできる ようにしています。また、そういった相談を気軽にできるような自分自身のプロデュースといいますか、キャラ作りみたいなものも含めてメンバーが相談しにくいという空気を作らないようにはしていますね。 新居 : ありがとうございます。岡村さんはどんな意識をしていますか。 岡村 : やっぱり平山さんに全く同感ですね（笑） 付け加えると、ソフト面ですが メンバーであるエンジニアが楽しめる環境作り というところを意識しています。楽しさにも色々な種類があるとは思いますが、単にコーディングするだけではなく、やはりプロダクトそれ自体の提供価値というものをしっかりと共有して、プロダクトを作ること自体に楽しさを感じてもらう…というのは重要じゃないかなと思っています。 また楽しさの別側面ですが、新しいテクノロジーなどもどんどんと取り入れることができるような仕組み作りもしています。島根のメンバーは今回のプロジェクトで初めて Ruby を使うというメンバーも多かったので、ここで楽しさを感じられないと、こうしたテクノロジー自体を嫌いになってしまう恐れがあるなと思ったので。 そうした「楽しい仕事」にしていくと「時間をかけなきゃ」ではなく「時間をかけたい」という感じで取り組めるようになると思います。 GM という役割の醍醐味とは 新居 : それでは終盤になってきましたが、GM の「やりがい」や「醍醐味」はどういったものになりますか。 岡村 : 一番は「ピープルマネジメント」になるんじゃないかと考えています。最近、岸田首相の所信表明演説で聞いて感銘を受けたアフリカの諺ですが「早く行きたいなら 1 人で行け、遠くへ行きたいならみんなで行け」という言葉はピープルマネジメントの本質なんじゃないかなと思っています。 メンバーと一緒に遠くに行くために組織作り などをしていけるのが醍醐味だと感じています。 平山 : メンバーの 個人スキルを高めつつ「チーム」に還元してもらうための仕組み を作っていく。というのは、醍醐味と言えるのかなと。CTO インタビューで田中も言っていますが「チームバリュー」は大切だと考えています。 チームといっても、狭義のチームではなくプロダクトに関わる関係者全員を含めたチームという感じで意識しています。開発組織に閉じないバリューの発揮がメンバーそれぞれでできると心強いと思います。 メドレーで GM やリードエンジニアのロールに向いている方 新居 : 最後になるのですが、メドレーで GM やテックリードといったロールに向いているのは、どんな人だと思いますか。 平山 : 基本的に 物事を前に進めるための解像度を高く描ける人 かなと思っています。何を誰のためにというのを体現しつつ、関係者を引っぱっていける人ですね。メドレーの Our Essentials 全般必要だとは思いますが、その中でも「成果を出す」「自分をアップデート」「組織水準を高める」「革新と改善を主導」というところが必要になるかな。困難な状況でも結果を出しつつ、自分の行動も高めていき、結果組織・プロダクトを良くしていける…というのがメドレーのリードと呼ばれているエンジニアかと思います。 やり方としては、マイクロマネジメントではなく、基本となる考え方をちゃんと伝えてメンバーに学んでもらう…という、やり方ができる人が向いていると思います。 岡村 : 困難な状況であっても何とかして前に進めることができる人 でしょうか。無理矢理に進めるというわけではなく、状況の整理や色々な部署との調整などもしたりして、何とか結果という形にしていける能力がある人がリードとしてメンバーを引っぱっていける人だと思います。 もちろん、フェイズによってメンバーとの関わりなどはちゃんと調整していける柔軟さなども必要になると思います。 新居 : なるほど。本日は色々なお話をしていただきまして、ありがとうございました! さいごに メドレーの GM 二人に仕事について聞いていきました。 前回の CTO インタビューでも語られた開発組織の話ですが、より現場に近い GM という立場のメンバーからの話でまた違った雰囲気などを感じていただけたかと思います。 このような GM を「ぜひやりたい!」という方や「こんな上司の元で自分の力を発揮していきたい!」という方はぜひカジュアルにお話ができればと思います。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp