フルスクラッチ開発で大規模スクラムを実装した話 #dxd2024

2024年7月16日(火)・17日(水)に行われた「Developer eXperience Day 2024」。”開発者体験”をテーマに、その知見・経験の共有とそれに関わる方々のコミュニケーションを目的とした本カンファレンスにmedicalforceも協賛しました。17日にはCTOの畠中が登壇し、全社横断型の大規模スクラム開発について話をしました。

この来場者の方にも好評いただいた大規模スクラムについて述べていきます。

登壇セッション「最速の組織を目指して全社で大規模スクラムを導入してみた話」

スライドは以下でも公開しております。
https://www.slideshare.net/slideshow/dxd2024/270289176#16

スピードを重視するmedicalforce

medicalforceでは、スピード感を重視しています。スピードといっても、ただ機能を短期間でローンチすることだけではありません。ミッションやビジョンに最短で近づけたか、という点を重視しています。

当社の事業の一つである「medicalforce」は自由診療クリニック向けのオールインワンSaaSです。この業界は、すでに20年利用されてきたオンプレミス型のシステムが多くのシェアを占めており、クラウド型への転換期を迎える最中にあります。2023年の市場規模は約5,940億円を超え、年10%の躍進を続ける成長産業といえます（※）。

実際、2021年5月にローンチしたmedicalforceは約460院に利用されるサービスへと成長しました（2024年6月時点）。市場の成長による後押しもあれど、ここまで短期間にPMFを実現できた要因のひとつがスピード感であると考えています。加えて、成長する産業のなかでトップシェアを走り抜くためには、今後もスピード感ある開発が欠かせません。

（※）株式会社矢野経済研究所 美容医療市場に関する調査を実施（2024年）
https://www.yano.co.jp/press-release/show/press_id/3570

課題：スピード感の低下

しかし、組織が拡大するにあたって直面したのがスピード感の低下です。原因を探求していくと、「無駄な業務の発生」という問題を発見しました。無駄な業務とは、ミッション・ビジョンに沿わない業務のことです。なぜそのような状況に陥ったかをさらに考えると、そもそもミッションやビジョンが明確でない、というさらなる問題が見つかりました。

そこで考えたのは、アジャイルかつリーンに明確なゴールに向かうことができれば、スピード感が担保できるであろうということです。アジャイルかつリーンの実現にはスクラムが最適であると考え、導入を決めました。

 基本思想

スクラム導入にあたっては、理論を踏襲して以下の3点を重視しました。

• 適応…不確実性に打ち勝つ意思決定

• 検査…WhatとHowの適切な把握。直面した不確実性についての正確な観測と、それらへの適応のメリット・デメリットの判断

• 透明性…検査と適応を繰り返すために必要不可欠な要素

イベント

適応・検査・透明性を重視するため、イベントは基本に忠実に取り組みました。

• Daily Scrum: 毎日の進捗を透明にし、問題を早期に発見し適応するためのミーティング

• Refinement: 次のスプリントで何を行うかを具体化し、透明性を高めるとともに、検査と適応を行う場

• Planning: 次のスプリントをどうやって行うかを計画し、透明性を確保と適応の計画

• Retro: 前回のスプリントの方法を振り返り、改善点を見つけ出し、適応を促進

• Sprint Review: スプリントの成果をレビューし、透明性を確保し、次のスプリントへの適応を計画

開発部内では上記を実行するスプリント期間を2週間に設定し、一定の開発サイクルを確立させました。

事例：決済機能の例

medicalforceでは、開発のみならず、人事やマーケティング、セールスを担う部署でもスクラムを導入しています。すべての部署で一斉にスクラムを導入できたわけではありません。開発部内でスモールに導入し、地道な布教活動を重ねた結果です。

実際、2024年7月現在では全社でうまく回り始めており、medicalforceの新機能ローンチの際にも良好な連携を図ることができました。おかげでリリースの翌日には営業担当が営業に動ける状態を作り、ディスカバリーからデリバリーまでをスムーズに取り組むことができました。

スクラムのイベントを削りたいリクエストへの対処

全社でのスクラムの導入は容易ではありませんでした。スクラムを実施するには、複数回のイベントが必要です。しかし、スクラムという考えを身近に感じていないこともあり、イベントの多さに驚き、イベントを削りたいというリクエストが一部の部門で発生しました。

必要最低限かつ十分な要素になっているため削りたくないところですが、各部門それぞれ事情があることは考慮されます。そこで、まずは試してもらうことにしました。実際にイベントを削ってうまくいくか検証してもらったのです。ただし、レトロだけは削らないよう伝えていました。レトロを削ると、振り返りを実施する時間がなくなってしまうためです。

また、スクラムを受け入れてもらうには、その価値を実感してもらうことが重要です。開発部がうまくいき始めているという成功体験を他部署にも共有するよう努めました。

改善点

全社横断的に取り組んでいるスクラム体制ですが、未だ課題は存在します。

そのひとつが、「高いレベルでの透明性の担保」です。直面している状況を正確に把握できるほどの透明性を担保することは難易度が高いものです。開発部ではタスクの担当者や期日と進捗をイベント実施によって透明化することに取り組んでいますが、理想とする水準での透明化のあり方には及んでいません。また、開発部だけでなく、全社で細かいメトリクスを設定し一定の水準で検査と適応を実施することが目下の課題です。

透明化については、また後日登壇などで発表させていただければと思います。

一緒にスクラム開発しませんか？

最後に宣伝です。medicalforceでは、フルスタックエンジニアを積極採用中です。すぐに選考ではなくても大丈夫。まずはカジュアル面談で話をしましょう！

pitta.me