開発チームでスクラムに取り組んでいるという方は一定数いらっしゃると思います。しかし会社全体でとなると、経験がない・イメージがわかないという方も多いのではないでしょうか。
本記事では『Developer eXperience Day 2024』（主催：日本CTO協会）における畠中翔一氏によるセッション「最速の組織を目指して全社で大規模スクラムを導入してみた話」の内容をお届けします。
スクラムの基本となる考え方や、開発以外のチームや経営層も含めた大規模スクラムの実践事例についてお話しいただきました。
畠中 翔一
株式会社メディカルフォース
CTO
学生時代からインフラの構築やWebアプリの立ち上げを多数こなす。2020年11月に株式会社メディカルフォースを設立し、現在のmedicalforceをフルスクラッチで開発する。開発の傍ら、深層学習を用いた研究が国際学会に採択されるなど、機械学習(AI)や最先端の技術にも精通する。
目次
学生時代に立ち上げたメディカルフォース
今回は「最速の組織を目指して全社で大規模スクラムを導入してみた話」をします。弊社で行っているエンジニア・セールス・CS・マーケや経営も含め全社で大規模スクラムを行い、その結果どうなったか、なぜやっているのかなどをご紹介します。
私はメディカルフォースという会社でCTOをしている畠中と申します。2020年の11月に株式会社メディカルフォースを共同創業、学生時代に立ち上げた会社です。学生時代からスタートアップの1人目エンジニアやフリーランスエンジニアのような働き方をしており、エンジニア歴は10年弱ぐらいになります。よろしくお願いします。
弊社はmedicalforceという、自由診療＝保険の効かない医療向けのAll in One SaaSを提供しています。最初は電子カルテや予約管理、あとはカルテ情報を元に会計情報を作る部分をベースにリリースしました。
その後1年ぐらいで在庫管理や周辺の業務効率化に関する機能を追加したり、クリニックさん向けのマーケティングの機能などを出したりしています。 そこに広告管理やCRM的なマーケティング機能機能に加え、決済なども含め、保健医療全般を扱っています。
医療に限らず、日本の現場ではまだまだ紙で情報を管理している産業や業界はたくさんあります。そういうところに対してソフトウェアを提供することで、成長プロセスを合理化・DXしていくことを目指している会社、とにかくVertical SaaSを世の中にたくさん生み出していこう！ という会社です。
スタートアップはスピード感で戦う
会社の紹介はこれぐらいにして、本題に移っていきましょう。
今日はスタートアップの話がメインとなりますが、僕としてはスタートアップにとってスピード感が大事だと思っています。それはなぜかと考えたときにPMF=Product Market Fitの話がよく挙げられますが、そもそもPMFとは何かを言語化するのは難しいです。
僕なりにはこの図のように説明できると考えています。
僕たちの場合は、もともとあるシステムに対して、そのシステムをリプレースするべく新しいシステムを作っています。業界によってはこの「元システム」が紙かもしれませんし、Excelかもしれません。
それに対してたとえば「ExcelからこのSaaSを使うと絶対良くなる」と思って導入したとしても、元のExcelでできていたことができなくなってしまったりします。そうなると、一時的に業務が大変になってしまいます。
その一時的な大変さをなかなかお客さんが乗り越えてくれないというのが、よくあるソフトウェアの問題だと思っています。そして、元システムから新システムへの移動をお客さん自身がスムーズに行えて、どんどん新システムに流れ込んでいくようになったときがPMFだと考えています。できなくなることをできるだけ少なくして、できるようになることを増やす。これが必要です。
僕たちの業界の場合は20年前から作られているオンプレの元システムがありました。これはよくできたソフトウェアだったこともあり、そこからリプレースするとなると普通のスピードでは5年以上かかると考えていました。
とくにエクイティ調達をしているスタートアップにとっては、ここを早くやらないと生き残れません。
そのため、とにかく生き残る・次のステージに進むためにも、とにかく創業期においてはスピードが大事でした。
我々業界のクラウドの中ではトップシェアのシステムになったのですが、今でもスピード感は非常に大事です。あとから大企業が参入してくる可能性もありますし、今の時点で機能の差別化ができていたとしても、競合他社も頑張って追いついてきます。そのため、競合よりも速いスピードで開拓しつづけること、独自のロードマップを作っていくことが必要だと考えています。
そして、ここでいうスピード感とは、ミッション/ビジョンに対してどれだけ速く近づけるかだと思っています。
スピード感が出なくなる場合というのは、だいたいはミッション/ビジョンに沿わないこと、ムダな仕事をしてしまっているときです。これはシード期のスタートアップなどではあまり問題になりませんが、スケールするフェーズでは問題になることもあります。あとは、そもそもミッション/ビジョンが明確でない、方向性を見失ってスピード感が落ちるということもあると考えています。
ミッション/ビジョンに早く近づくために重要なのは、ミッション/ビジョンを明確にすること、沿わないことをやっていると気づいたらすぐに軌道修正すること、正しい方に向かっていないと思ったときにはやめること。
そして、やることを決める際には「どれが一番ミッション/ビジョンに速く近づけるか」を問うことが、スピード感にとって大事です。
これが、よくいわれる「アジャイルに」ということだと考えています。
これはまさしく、スクラムでいわれる検査と適応というプロセスの繰り返しです。
スクラムについては経験のある方も多いようなので詳しい説明は割愛しますが、ごく簡単に言うと、チームを運営していくための軽量のフレームワークです。スプリントと呼ばれる1週間や2週間という短い期間のサイクルを回します。
ルールはそれほど多くはなく、チームの中にどの役割の人が何人いればいいかや、各種スクラムイベントを何時間やればいいかなどが決まっているくらいです。
スクラムの中で大事なのは、3本柱と呼ばれる以下の3つです。
- 透明性
- 検査
- 適応
スピード感を出すためには、現状を検査で把握し、理想と異なる場合には適応による軌道修正を繰り返していくことが大事です。そして、検査を正しく行うには組織・チームの透明性が正しくなければいけません。まずは透明性を高めることからはじめ、定期的に検査をし、適応をきちんと行うという流れになります。
よくあるデイリースクラムの失敗例としては、とにかく透明性を高めるために今日やることと昨日やったことを話すだけの報告会になってしまう、というものです。これでは検査が行われておらず、適応も行われていません。スクラムの本質的な価値が発揮できていないところが問題です。
スクラムの基本的な流れは、「やることを決める」「具体化する」「いつやるか決める」「進める」です。
そして、障害があれば取り除いて、やったものをレビューするというのが、基本的なイベントの役割と認知されています。 イベントに関しては、サイクルがぐるぐると回るようになっている形です。
ここではあらためて、スクラムではWhatとHowをきちんと分ける必要がある、とお伝えしたいです。すべてのスクラムイベントはWhatの透明性・検査・適応、もしくはHowの透明性・検査・適応に分かれていますし、役割に関してもWhatとHowに責任を持つ人にしっかりと分かれています。
このようにイベントを再定義するとすごくわかりやすくなります。リファインメントというのは次のスプリントのWhatに対して透明性・検査・適応をしていくところ、プランニングは次スプリントのHowの部分に透明性・検査・適応していくところ。そしてレトロスペクティブは前回のスプリントのHowについて透明性・検査・適応していく場で、スプリントレビューでは前回スプリントのやったもの、Whatに対して透明性・検査・適応をする。デイリースクラムに関してはWhatとHowをセットで透明性・検査・適応をする、というのが重要なところです。
よくある問題としては、リファインメントとプランニングが混ざったり、レトロスペクティブとリファインメントが混ざってしまったり、ですね。なので大事なのはHow＝やり方が悪かったのか、What＝やったものが悪かったのかを区別して話すことです。とくに、このあと述べる大規模スクラムにおいては非常に重要になってきます。
会場の皆さんは、大規模スクラムの経験はありますか？ なかなか少ないですね。ではScrum@Scaleはどうでしょうか？いなさそう、ですね。ありがとうございます。
チームでスクラムを行い、アジャイルさを保つところはできるかと思いますが、それを組織単位でやっていこうと思うと、非常に難しい話になってきます。
大規模スクラムのフレームワークというのは、それこそScrum@ScaleであったりLeSSであったり、いろいろあります。これは個人的な意見ですが、Scrum@Scaleが最も現実的に取り入れられるフレームワークだろうと判断して、弊社ではScrum@Scaleを導入しています。
Scrum@Scaleというのは、チーム間でスクラムを組むようなイメージです。
弊社では開発のAチーム・Bチーム・SRE・サポートのチームがそれぞれスクラムをしていて、それぞれのスクラムの中にはプロダクトオーナーやスクラムマスターがいます。部署の中にはチーフプロダクトオーナーやスクラムオブスクラムマスターがいて、プロダクト部署としてスクラムを組んでいます。
さらに、プロダクト部署とセールス部署それぞれのプロダクトオーナーとスクラムマスターが集まって、事業部のスクラムを組んでいます。そのうえでは事業部のマネージャーたちで経営のスクラムを組んで、という形になっています。
ここで出てくるのがさきほどのWhatとHowの話です。会社としてスピード感を出すには、アジャイルに・リーンに経営をしていくことが必要で、会社として「今のサイクルはきちんと回っているか」を検査しています。
ここからは、スクラムマスターサイクルとプロダクトオーナーサイクルについてもう少し詳しく説明します。
まずはスクラムマスターサイクルです。
具体的には、弊社では11時から11時15分に開発チームのデイリースクラム、11時15分から11時半にプロダクト部署の朝会があります。そして11時半から11時45分の間に事業部の朝会があり、11時45分から12時に経営の朝会があります。これを毎日やっています。
これによって、たとえばCSチームから「バグで顧客からクレームが来ている」といった報告が朝上がってくると、そのタイミングで開発部署にも伝わるので、じゃあ今日割り込みになるけれども解消しましょう、といった話がすんなり進みます。このような動きが随所で起こります。
一方プロダクトオーナーサイクルについては、まず最初に経営のリファインメントがあり、その後事業部のリファインメント、部署のリファインメント、チームのリファインメントがあるという流れになっています。これはさきほどよりもわかりやすいですが、経営として今一番力をいれるのはこれだ、という話が出てくるとまず経営の中で最も優先順位の高いバックログになります。
それを達成するには各部署は何をすべきかが部署のリファインメントで決まり、そこからチームのリファインメントに落としていく流れです。
これらの、スクラムマスターサイクルとプロダクトオーナーサイクルをきちんと回すことができれば、会社としてのアジャイルさ・リーンさは担保でき、それに応じてチームのアジャイルさ・リーンさも担保できます。個人的にScrum@Scaleがいいなと思っているのは、イベントの数が普通のスクラムと大差がないところです。
僕は経営のスクラムに入っているだけですし、メンバーはチームのスクラムに入っているだけです。それでも会社として、それらが関連して回っていくところがScrum@Scaleのすばらしいところだと考えています。
我々もこのScrum@Scaleを実践してみて、良い形で回っています。皆さんの会社でもぜひ取り入れていただきたいと思います。
大規模スクラムの難しさ
ここからは、弊社での取り組みで実感した大規模スクラムの難しさについてお話しします。
開発チームでスクラムに取り組むうえでは、大きな問題はありませんでした。また、開発組織全体で大規模スクラムを行ったのち全社に広げたので、大規模スクラムの回し方については適切なプロセスを踏めば大丈夫だろうと考えています。しかしここからさき、ビジネスサイドにスクラムの価値を理解してもらうことが非常に難しいです。
たとえばよく出てくるのが、スクラムイベントを削りたいという話です。開発チームからも同様の意見が絶対に出てくるのですが、基本的にスクラムイベントはすべて削ってはいけないんですね。必要最小限でかつ十分なイベントになっているのがスクラムのいいところです。
もしどうしても削りたいと言われたら、ある程度はやってもらってもかまいません。しかし、レトロスペクティブだけはなくさないのがよいと思います。仮にスクラムイベントを削ったとして、もしレトロスペクティブを削ってしまうと、削った結果どうだったかのふりかえりができなくなります。
弊社の場合も、マーケティング部門が最初がっつりとスクラムイベントを削っていたのですが、現在はすべて行ってくれています。このような方法は、ビジネスサイドに広げる際のひとつの方法だと思っています。
もう一つ難しかったのは、CSやセールスなどに、お客さんからの問い合わせや相談が突然入ったりなど、「この週はこれをやります」と決めたことに集中しにくい状態です。
開発チームでもバグ対応や緊急の依頼などはありますが、これらは特化チームを作って対応することが可能です。しかしCSやセールスチームではそうはいきません。ここは、ある程度諦めてもいいのかなと思っています。絶対にやりきろうとしてしまうと業務過多になってしまいます。
ただ重要なのは、優先順位が正しいかどうか、今やろうとしていることがミッション/ビジョンに一番近いかの議論ができていることだと思います。そのために、スクラムイベントなどコアな部分は必ず行うようにしてもらっています。
大規模スクラムの難しさをまとめると、以下の2点に集約されると思います。
- 定常業務がある中でどうスクラムをやっていくか
- スクラムの価値をどうやってきちんと伝えていくか
では、今回のお話はここまでとさせていただきます。ありがとうございました。
取材後記
個々のチームから経営レベルまで、全社で大規模スクラムを回している状態がどういったものかがわかりやすく、非常にきれいに回っているようすが伺えました。そこに至るまでの困難や乗り越え方も含め、大規模スクラムに限らずスクラムを行っている組織、これから行おうとしている組織にとって学びの多いご講演でした。
（撮影／文：伊藤由貴）
