チーム開発はじめました。のその後 - エムスリーテックブログ

コンシューマーチームブログリレー 1日目です。

こんにちは。エムスリーエンジニアリングG コンシューマーチームで主にアスクドクターズ開発を担当しているスクラムマスターの甲村と申します。

2023年にコンシューマーチームを3つのチームに分割した例をご紹介しました。チーム開発の導入から早２年。スクラムチームで起きた変化を語っていきたいと思います。

チーム開発導入前はエンジニア人数分の開発ラインが存在するウォーターフォール型で開発していました。

これは、エンジニア個人の得意分野に特化して開発できるメリットがありました。一方、レビューやQAなどのスイッチングコストがかさむという問題もありました。

このあたりの詳細は以前の記事に書いています。 www.m3tech.blog

2年前と多少のメンバー入れ替えがあり、現在は次の体制で動いています。

この２年間でスクラムチームは２種類の決済APIの更改をはじめ45機能*1をリリースしています。

リアーキ・改善チームも積年の課題をいくつも倒し、体制変更以降、大きく前に進んだ手応えを感じています。

最も大きな変化はスクラムチームがペースを掴んだことで、施策にかかる時間の見積もりの精度が上がったことです。

スクラムを始めたばかりの頃は「5ポイントくらいだけれど、どのくらいかかるかははっきり言えない...」だったものが最近では「3スプリント（3週間）くらいほしいですね」とそれなりの精度で言えるようになりました。

まだ不確実ではありますが、先を見通す力を獲得したのです。

品質も向上しています。

深刻なトラブルでリリース後ロールバックになったものは0になりました。

小さな不具合が出ることもありましたが、後追いの修正リリースで問題のない程度です。

スクラムチームはエンジニアQAがメインです。チーム全員が関わるので、次の要因でQA品質が上がります。

また、全員で実装しているので、後追い修正も迅速です。

昨年、課金系API 2種類の更改をトラブル0で達成しました。現行の機能を損なわず、万が一新しいAPIで不具合が起きてもすぐに戻せるようにしました。

APIのバージョンアップのみでなく、ロールバックや小規模リリースの方法などチーム全員で作業を分割し、 API更改というゴールに集中して開発したことで、大規模かつシビアな開発もトラブルなく完遂できたのです。

スクラム外のエンジニアに設計段階からレビュアーとして入ってもらうことはありますが、設計、実装ともにスクラムチームのエンジニアが主体となって行います。いままで苦手としていた部分にもチャレンジ。

適材適所の最速スピードは出せませんが、リリース後も継続して「診られる」エンジニアが複数名いることになります。

難しかったこともあります。プロダクトオーナーであるPdMは多忙なため参画しきれないこともありました。しかし、この場合は他のメンバーが手伝えれば良いのかもしれません。スクラムの3原則は透明性、検査、適応です。検査と適応を繰り返す中で、より良い活動へと進化していくこと。

制約があるからストップするのではなく、

このプロセスでチームは課題を乗り越え、成長していけます。

実際に、現在ではPdMをプロダクトオーナーとしたまま、かなりの部分をスクラムマスターとエンジニアメンバーで進めています。

チーム開発へ移行してからの反省点と良くなった点をご紹介しました。スクラムチームでは「透明性、検査、適応」を通じてアスクドクターズをより良いプロダクトへと進化させ続けていきます。

エムスリーではテクノロジーを活用して医療業界を変えるプロダクト作りに取り組む仲間を絶賛募集中です。ご興味がある方はぜひカジュアル面談でお会いしましょう。

前回もご紹介したチーム紹介資料もご覧ください。(人数など、一部本記事記載時点と違うものがあります)

*1:スプリント/チケット数ではなく、大きくまとまった機能をカウントしています