エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

VPoEとしてこの4年間を振り返って&VPoEを卒業します!

みなさん、こんにちは、こんばんは!日夜、部屋キャンで練習を重ね、先週末ついにキャンプ場デビューしたエムスリー執行役員VPoE兼プロダクトマネージャー兼その他諸々の山崎です。終日豪雨に見舞われ、設営から撤収まで全て雨の中で行うという、初回としてはストロングスタイルな体験を経て経験値が沢山溜まって嬉しかったです。

さて、本日は毎年書いていた「VPoEとしてこのx年間を振り返って」シリーズの最新作をお届けしようと思って筆を取りました。最後にエムスリーの体制変更に関するお知らせもありますので、是非最後まで読んでもらえると嬉しいです。

はじめに

2017年12月にエムスリーにおいて始めてVPoEが設置され、私が初代VPoEに就任しました。 それからの4年間は本当にあっという間に過ぎ、4年以上も経っているとは信じられないというのが正直なところです。 一方で、その間、多数のチャレンジをしてきました。

この記事では、社内外の参考になるかもしれないと思い、それらのチャレンジを抜粋して紹介したいと思います。 ちなみに、報酬に関するチャレンジはセンシティブなので割愛します*1

f:id:yamazaki-m3:20220405222007p:plain
エンジニアリンググループグループリーダーの岩佐淳史さんとのツーショット(深い意味はあるような、ないような)

*1:CTO、VPoEの方で聞きたい方がいらっしゃればCTOミートアップなどで個別にお声がけください。

続きを読む

オンプレで実行されているバッチ (cron + shell script) をAWS Lambdaに移植する方法

こんにちは、エンジニアリンググループの大和です。
弊社ではエンジニアリンググループ全体で継続して脱オンプレを進めており、これまでに多くのDBやサーバを停止してきました。

www.m3tech.blog

また、直近ではコンシューマチームでの取り組みが紹介されています。

www.m3tech.blog

私が所属するマルチデバイスチームでも、前年度までに管理しているサービスのオンプレDBおよびサーバを廃止しました。

コンシューマチームの記事でも説明されていますが、脱オンプレではサーバアプリケーションとDBだけを移行するだけでは足りず既存のバッチや監視周り等含めて移行する必要があります。 この記事では、そのうちcronでshell scriptを実行しているような簡単なバッチをAWS上に移行する方法を紹介します。

続きを読む

ElasticsearchのMore like this内部実装とパフォーマンス問題の解決

エムスリーエンジニアリンググループ AI・機械学習チームでソフトウェアエンジニアをしている中村(po3rin) です。検索とGoが好きです。

今回はLuceneのMore like this(MLT)機能のコードリーディングでMLTの実装を理解して、エムスリーで問題になっていたMLTパフォーマンス問題を解決したお話をします。

続きを読む

スモークテストのテストケースを1から作り直したお話

こんにちはエンジニアリンググループの森内です。私はエムスリーデジカルというクラウド型電子カルテチームでQA(品質保証)を担当しております。本ブログでは、今期に実施したスモークテスト*1の改修で得た知見をお話します。今回の改善の効果は将来のリリースの度に授かることができるので、少しでも参考になれば幸いです。

*1:本ブログでは、JSTQBに則り『プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視するテスト』をスモークテストとさせていただきます。

続きを読む

15年間続いているサービスをクラウドに移行しています (part 2)

こんにちは、エムスリーエンジニアリンググループのコンシューマチームに所属している園田(@ryoryoryohei)です。今回は 15 年以上続いている弊社の C 向けサービスである AskDoctors の AWS 移行で苦労した点や工夫した点などをお伝えしたいと思います。

  • はじめに
  • 移行フェーズ
  • 苦労したポイント
    • デプロイ方法の変更
    • バッチのアーキテクチャ
    • 泥臭い修正
    • 待ち時間
    • 定型外のリリースフロー
  • AWS 移行後のこと
    • End-to-End のレイテンシー悪化
    • バッチ起動エラー
    • Redis メモリ逼迫
    • オンプレの API に対する Connection Failed
  • おわりに
  • We are hiring!

はじめに

弊社では to C のサービスとして AskDoctors という医師に直接相談できる Rails のサービスを 15 年以上前から運営しています。

www.askdoctors.jp

こちらの AskDoctors ですが、先日 1 年以上の時間をかけてフロントエンドサービスの AWS 移行が完了しました。

続きを読む

7年間運用している主力アプリをリファクタリングしている話 Android編

こんにちは、エンジニアリンググループ マルチデバイスチーム 新卒2年目の小林です。

先日、iOS版m3.comアプリのリファクタリングに関する記事が公開されましたが、Android版もリファクタリングを行っているため、Androidの方で起きていた問題とリファクタリングをどのように行っているのかについて紹介します。

  • m3.com Androidアプリについて
  • m3.com Androidアプリの課題
    • ActivityやFragmentにビジネスロジックが書かれている
    • 必要以上にコードが共通化されている、ActivityやFragmentが多段階に継承されている
    • 責務が不明なクラスがある
    • 多くのコードがJavaで書かれている
  • リファクタリングの検討
  • リファクタリングの大まかな設計やルール
    • アーキテクチャをFluxに
      • FluxとAAC ViewModelの使い分け
      • StateFlowによるViewの状態の管理
    • マルチモジュール化
    • ライブラリのモダン化
    • ID型を定義
    • 過剰な継承の禁止
    • ○○Helperや○○Serviceという名前のクラスを作らない
  • リファクタリングの進め方
  • UIの実装について
    • Groupieによるリスト画面の描画
    • Jetpack Composeの導入
  • 最後に
  • We are hiring!

m3.com Androidアプリについて

f:id:kobasato34:20220314145810p:plain
m3.com Androidアプリ

m3.comアプリは医療従事者専用なので中身はお見せできないのですが、一言で説明すると、トップ画面に様々なサービスのタブが並べられたポータルアプリです。サービスは 20個以上あります。

主力のアプリであるため、今後もサービスが増えたり保守運用を続けていく必要があります。 他に開発しているアプリはモダンな構成になっているのですが、このアプリは運用歴が長いこともあり、様々な課題がありました。

続きを読む