【Unit4 ブログリレー1日目】
エムスリー エンジニアリンググループの関根です。 医療従事者向けポータルサイト「m3.com」のサイトプロモーションを行う、「Unit4」というチームに所属しています。
エムスリーテックブログリレーもUnit4のターンが回ってきました。 トップバッターである私からは、チームについての紹介と、利用技術や開発スタイルをご紹介します。
Unit4は m3.com の玄関口として、30を超える多種多様な技術スタックを持つサービスを15人前後のエンジニアで開発・運用する、ちょっと変わった（でも面白い！）チームです。 新しい技術への挑戦や幅広いスキルの習得、自由度の高い開発など、チームの魅力をお伝えできればと思います。
Unit4のミッション
Unit4は、医療従事者向けポータルサイト「m3.com」のサイトプロモーションを行うチームです。m3.comの玄関口として、m3.com会員向けに多種多様な魅力的なサービスを展開し、m3.comをたくさん使っていただくことが我々のミッションです。
自他チームのサービスへの流入を増やしてm3.com全体を活性化させ、プラットフォーム全体の価値提供を支えています。いわば、m3.comエコシステムの「入り口」と「魅力の創出」を担当している重要な役割だと自負しています。
Unit4を含む、エムスリーエンジニアリンググループの組織構成については、以下記事をご参考ください。
Unit4の特徴
Unit4の最大の特徴は、会員のアクセスを促すという明確な目的に対して、アプローチの幅が非常に広いことです。基本的に、ユーザの訪問が増える施策であれば、どのような施策も検討対象となります。 この自由度の高さから、ニュース配信、Q&A、SNS、クイズ、動画コンテンツ、ポイントシステムなど、性格の違う小規模サービスを多数展開しています。
また、既存サービスではリーチできない医師層に対して、新サービスの立ち上げも活発に行っています。市場のニーズや医療業界のトレンドを敏感に察知し、迅速にサービス化することで、常に新しい価値提供を目指しています。
特定の顧客を持たず、チーム内で意思決定を行うため、自由度が高く、既存のプロダクトに縛られない開発が可能です。これにより、技術的な挑戦や新しいアプローチを積極的に取り入れることができます。 新しいことを試したい、広い技術を身につけたい、というエンジニアには魅力的な環境だと実感しています。
技術スタック
エムスリーでは全社的に現場の裁量で利用技術を選定できる文化があります。この文化のもと、Unit4では新サービスの立ち上げ頻度が高いことも相まって、技術スタックの異なるサービスが多数存在しています。
ここでは技術スタックに焦点を当て、Unit4のいくつかの事例をご紹介します。
多彩な利用言語
Unit4では、m3.comの玄関口として多種多様なサービスを展開しています。主要サービスだけでも23あり、それ以外の社内向けサービスを含めると30を優に超えます。その一部と採用技術は次に示します。
| サービス名 | 概要 | 技術スタック |
|---|---|---|
| 医療ニュース | 医療関係のニュースや独自記事を配信 | Scala, Play Framework |
| Docpedia | 医療現場の疑問を専門医に相談できるQ&Aサービス | Kotlin, Spring Boot, Vue.js |
| m3TV | 医師向け動画コンテンツ | Go, React |
| m3ラウンジ | 医師限定SNS | Go, Vue.js |
| Point Club | m3.comを使って貯めたポイントを景品に交換 | Java, Spring Framework |
| 管理画面 | m3.comの運用者向け管理画面 | Ruby on Rails |
成熟した技術からモダンな技術まで、幅広い技術スタックのサービスを手掛けています。
各サービスの内部実装については、去年のUnit4ブログリレーを始め、多数の過去記事を掲載していますので、ぜひご覧ください！
代表的なシステム構成
プログラミング言語は多彩ですが、それを支えるクラウドインフラ構成はほとんどのサービスで統一されています。
各サービスをマイクロサービス的に運用しており、CI・監視（ログ/メトリクス）・KPIダッシュボードも、サービスを横断して共有しています。
サーバレスサービスの活用
アプリケーションコンテナやRDBが不要なケースでは、上記ECS Fargate + RDSの代表ケースではなく、運用コスト最適化のためにサーバレスサービスも活用しています。
こちらはm3.com内にある静的ページ（キャンペーンのランディングページなど）の管理サービスの事例です。
幅広い技術スタックに対応するための開発スタイル
これまでに記載したとおり、Unit4では幅広い技術スタックのサービスを多数手掛けています。一方で、それを支えるチームメンバーの数は15人前後です。
圧倒的にサービス数の方が多く、「〇〇さんはこのサービスを担当してね」というような担当制では運用が困難です。
この状況に対応するため、Unit4では「メンバーとサービスがN:Nの関係」という開発体制を取っています。個々のメンバーが対応するサービスを固定せず、一人ひとりが複数のサービスに緩く関わることで、チーム全体として各サービスの知見者が常に一定数いる状態を維持しています。
各サービスに担当者はいますが、その役割は大きくしすぎず、あくまで連絡窓口や一次対応に限定しています。これにより、特定の個人にサービスの全責任が押し付けられることを避け、人依存にならない体制を構築しています。
実際の着任後の流れは次のようになります。
- チームリーダーとの1on1を通して、これまでの経歴や好み（これが一番大事！）に合わせて、最初に手をつけるサービスや技術領域を決定します。私の場合は前職でJavaやC#の利用が多かったので、近しくも新しいKotlinを選びました。またAWSの経験が少なかったので、terraformに触れる案件をアサインしてもらいました。
- 小規模な開発を通じてそのサービスにある程度慣れてきたら、次に着手する別のサービスを選びます。近しいサービスを選んでも良いですし、全く性格の異なるものを選んでも構いません。好みや興味がキャッチアップ速度に大きく影響を与えるため、本人の自主性を重視しています。私はKotlinに次いでまた未経験の言語を学びたかったので、同じJVMのScalaに手をつけました。
- ある程度チームに慣れてきたら、サービス立ち上げにも参画してもらいます。リリース後ある程度の期間は立ち上げメンバーが面倒を見ますが、開発プロジェクトはなるべく早めに解散させ、他のメンバーも新サービスにどんどん触れる機会を設けます。
- 全メンバーがこれを繰り返し、触れるサービスを増やしていきます。
また、サービス数が多いため、開発・運用の効率化は生命線です。DX（開発者体験）やDevOpsにも強くこだわっています。
- トイル（無駄な手作業）を見つけたらなるはやで解消します。サービスの開発・運用コストを下げなければ、定常タスクですぐに埋もれてしまいます。
- CI/CDを整備し、検証環境はもちろんのこと、本番環境へのリリースも工程のほとんどを自動化しています
- SREチームも監視・運用プロセスをPDCAし続け、日々効率化を進めています。
トイルの自動化については、例えばレビュー依頼の省力化を行なった過去記事もありますので、興味があればこちらの記事もぜひご覧ください！
まとめ
Unit4は、m3.comの玄関口として多種多様なサービスを展開する、自由度と裁量の高いチームです。私自身、多種多様なサービスと技術に触れながら、裁量を持ってプロダクトを立ち上げ・エンハンスしていく経験を積めていると感じています。
明日からは、実際にUnit4で活躍するメンバーたちが、より具体的な技術的取り組みや開発の裏側をお伝えしていきます。乞うご期待！
We are Hiring!
エムスリーでは一緒にプロダクト開発をするエンジニアを絶賛募集中です。Unit4に興味を持たれた方は、ぜひカジュアル面談でお話ししましょう！
