コンシューマーチームのブログリレー3日目です。
コンシューマーチームで行ったアスクドクターズ開発の開発体制変更についてご紹介したいと思います。
はじめまして。エムスリーエンジニアリングG コンシューマーチームで主にアスクドクターズ開発のスクラムマスターの甲村と申します。
すっかり寒くなり紅葉の季節ですね。
アスクドクターズ開発の守備範囲
オンライン医師相談サービスのアスクドクターズは15年以上続いているサービスです。
このサービスの技術基盤はStripe、AmazonPay、 携帯キャリア決済関連にiOS決済、ネイティブアプリ（iOS/Android）やメール決済など。機能としてもコアとなる医師相談の他、企業従業員向けにサービスのエムスリーペイシェントサポートプログラムをはじめとする法人利用との連携など多岐にわたります。
そして、15年以上続いているサービスです。保守すべき部分も多いですし、正直なところ技術的負債が溜まってしまっている部分もあります。これら負債を解消し、各種バージョンアップ等を保守すると同時に、利用者様に価値を提供していく必要があります。
これらすべてをプロダクトオーナー1名、PdM2名（兼務）、エンジニア11名（内4名は兼務）で行います。
十分な人数がいるようにも見えますが、より良い開発にするために体制変更しました。
元々の開発体制
バックログに積み上げたチケットを、上から順にその時手が空いている人にアサインして実装をやりきり、他のエンジニアにレビューを依頼、その後QA担当者がQAというウォーターフォール型の開発をしていました。
この体制の良さは以下のような点が挙げられます。
- 特に実装フェーズは1人で集中するので素早くおわる
- 各人が専門性を発揮しやすい
- 同時にすすめられるチケットの数が多いため、長期的に見ると期中にリリースするチケットの数が多い（最大11多重！）
一方で以下の困りも出てきました。
- 「xxの機能はAさんじゃないとわからない」問題(各機能や基盤への理解が属人化)
- 「レビュー依頼きてるこの機能の仕様なんだっけ」問題
（実装作業に割り込みで、別機能をレビューするためスイッチングコスト大） - 「この機能いつリリースになりますか？」問題（機能を開発開始してからリリースまでの期間が長く、予測しづらい）
- 「ばらばらの仕様確認つらい」問題（最大11個の別の機能の仕様確認が1人に集中する可能性もありました）
- 負債解消系が進まない問題（機能開発と負債解消が同列のバックログにいるので負債解消チケットの順位が上がりづらい）
体制変更と工夫した点
上記の様な困りを解消するため、チームを分割し、それぞれに適した開発スタイルを採用しました。
大きく3チームに分けました。
- 大規模リアーキなど負債解消と次世代に向けた開発を進めるプラットフォームチーム（エンジニア4名 内、兼務２名）
- 直近の機能開発を速やかに進めるscrumチーム（エンジニア 4名、プロダクトオーナー 1名、スクラムマスター1名）
- ネイティブアプリチーム（兼務のエンジニア2名）
チーム分割に伴いバックログも機能開発系バックログと技術系バックログに分割しました。機能開発系は主にscrumチームが、技術系は主にプラットフォームチームが担当します。
プラットフォームチームは従来同様、カンバン形式でバックログを上位から順次消化していきます。
scrumチームは1週間スプリントとし、プロダクトオーナーはその時のスプリントゴールに合わせてPdMが持ち回りで担当します。
scrumチームの活動は基本的にすべてチーム内で完結させます。
しかし、現状scrumチームにはSREが不在です。このためIaCのコードレビューやインフラ系作業が発生する場合は必要に応じてプラットフォームチームのエンジニアにヘルプを依頼する形をとっています。
この分割により、エンジニア全体で集まる機会が減ります。そのため、全体振り返りとバックログチケットの見積もりを週に1回ずつ、エンジニア全員で行います。これらの場で学びの共有と今後の開発の認識合わせを行うようにしています。
また、割り込みチケットとして発生しがちな「（静的な文言などの）ちょっとした変更」といった小規模で急ぎのチケットは、すべてスクラムマスター兼エンジニアが担当して順次さばくことでバックログの変動を最小限に抑えることにしました。
変更したら何が起きたか
体制変更から約半年。ねらい通りの効果を感じているのは以下のような点です。
- プラットフォームチームはリアーキテクチャに集中でき、技術検証の時間も取りやすくなった
- プロダクトオーナーは機能開発に対して考えることが限定でき、仕様検討に集中しやすくなった
- レビューに必要な業務や技術基盤の知識が集中するので深いレビューができるようになった
- みんなで開発するので知識の共有が行われた
意外だったのは、いわゆる「割れ窓」の現時点で明確に害はないが直しておきたい小さな改善のチケットが40件以上消化されました。
これはscrumチームのエンジニアがスプリント中にちょっとだけできた隙間時間におさまる範囲で消化していったためです。
体制変更後の失敗談
アプリの機能開発でAPI開発のみをscrumチームで行ったスプリントがありました。
この時は見積もり会で認識あわせした構成、scrumチームが最初に想定したAPI、ネイティブアプリチームにレビューを受けて実装したAPIがそれぞれ違う形になってしまい、誰も全体が見えなくなって手戻りが発生しました。
これは、1つの機能をチームも開発期間も分割して実装してしまったためと考えています。
このスプリント以降、API開発を伴うアプリの機能開発は必ずAPI担当とアプリ担当を一体のチームとして開発するようにしています。
まとめ
総勢14名のプロダクト開発チームをその目的ごとに分割し、プラットフォーム開発と機能開発の推進を両立させた例をご紹介しました。
変更開始から随時、振り返りと修正を続けている様子をお伝えできたかと思います。
まさに検査と適応です。変更して困った点はどんどんPDCAを回してよりよい開発、よりよいプロダクトを作り出していきます。
We are hiring!!
エムスリーではテクノロジーを活用して医療業界を変えるプロダクト作りに取り組んでいます。 エンジニア、プロダクトマネージャー、プロダクトデザイナーを絶賛募集中です。 ご興味がある方はぜひカジュアル面談でお会いしましょう。
アスクドクターズチーム開発資料もご覧ください！(人数など、一部本記事記載時点と違うものがあります)
