ボトルネックに徹底的にフォーカスしリリースが倍速に。 提供価値/事業成果の最大化を突き詰める『SUUMO』開発チームの5年間

SUUMOのモバイルアプリ開発チームは、2018年にそれまでのスクラム方式からカンバンを使った方式に、開発体制を切り替えています。それから5年間、開発フローのボトルネックを徹底的に排除し続け、企画からリリースまでのリードタイムを半分ほどに縮めたそう。

圧倒的な効率化を実現するためにどんなことに取り組んだのか？そのなかでカンバンはどのように作用したのか？5年前のカンバン導入時に開発チームのマネージャーを務めていた上島さんと、現在のマネージャーである藤原さんにお話を聞きました。

• keyboard_arrow_down 『SUUMO』スマホウェブ・モバイルアプリのサービス開発は4つの領域と媒体ごとで8チーム体制
• keyboard_arrow_down カンバンは「事業の成果を最大化するための手段のひとつ」にすぎない
• keyboard_arrow_down 「企画」「開発」「リリース後の検証」すべてのステップで改善を回す
• keyboard_arrow_down ボトルネックはなくならない。大切なのは、改善サイクルを回し続けること

――まず、『SUUMO』スマホウェブ・モバイルアプリの各サービスは、どのような体制で開発しているのか教えてください。

藤原：前段として『SUUMO』は、ユーザーとクライアント両方に価値を提供する構造となっています。

藤原：この事業背景のもと、『SUUMO』スマホウェブ・モバイルアプリの開発は8つのチームで行っています。「賃貸物件」「戸建て住宅」「新築マンション」「全領域の共通機能とサービス全体の保守」という4つの担当領域に、それぞれウェブとモバイルのチームがあります。

藤原：すべてのチームが全く同じ構成というわけではありませんが、一例を挙げると、1つのチームはおおむねプロダクトオーナー1人、プランナー2人、デザイナー2人、エンジニア4～7人、ディレクター1人によって構成されています。なかでもディレクターは、スクラムにおけるスクラムマスターのように、チームの健全性やメトリクスの妥当性を計測、改善する役割です。

――カンバンを使った開発は、具体的にどのように進めていますか？

藤原：細かい部分は開発チームに合わせてカスタマイズされていますが、大まかには以下のような形となります。Jiraのカンバンボードを使い、開発プロセスを以下の7つのレーンに分けて管理しています。

①起票
②リファインメント
③READY
④開発作業中
⑤リリース待ち
⑥分析待ち
⑦Close

藤原：プランナーは、アイデアを思いついたら案件を起票（①）。要件定義をした上でエンジニアと認識を合わせ（②）、定義漏れがない状態になったらReady（③）となります。その後、プロダクトオーナーが決めた開発優先度に従って、開発を進めていきます（④）。

ユーザーにとって価値のある案件だけを残していくために、リリースした案件はすべてABテストをします（⑤）。その結果をもとに、効果が高かったケースを選んで採用し、ソースコードを整理して再度リリースします。

Jiraのチケットが各レーンにどの程度滞留していたかを自動的に集計する仕組みをつくっており、起票からリリースまでのそれぞれのフローでリードタイムがどのくらいかかったのかを定量的に集計・分析（⑥）して、ボトルネックの検証を何時でも行えるようにしています（⑦）。

――スクラムからカンバンを使った開発プロセスに移行した目的は何でしたか？

藤原：カンバンの採用は、事業の成果を最大化するための数ある施策のうちのひとつでした。

カンバンを導入した2018年当時、SUUMOは月間訪問者数が2000万人超と、既に大規模なサービスとなっていました。事業の成果を高めるための施策としては、新しい機能をどんどんつくってユーザー数を伸ばしていくフェーズは過ぎ、機能や動作、安定性等の面から今のプロダクトを磨きこんで価値を最大化していくフェーズに差し掛かっていました。

プロダクトの磨き込みのサイクルを効率よく回し続けるには、企画からリリースまでのフローを最適化する必要があります。そのために、まずはバリューストリームマッピング（VSM）によるボトルネック可視化を行った上で、各工程のボトルネックの解消に取り組みました。カンバンの採用もその中のひとつ、という位置づけですね。カンバンだけで全てが解決するわけではないので各工程のリードタイムを集計するシステムをつくったりと様々な施策に取り組んでいます。

この検討のプロセスをご理解いただく際には、「制約理論（ToC）」や「フロー効率性とリソース効率性」という考え方が参考になるかと思います。

――なぜカンバンを使うことにしたのでしょうか？

上島：当時の開発チームにとって、優先度の高いチケットに着目し効果を最大化することを意識するためには、カンバンという形が最適だと判断したからです。

取り組みを始める前は、開発チームで起こりがちな「職種間のギスギス」に入りかけてしまっている面もあったんです。リリースまでに時間がかかると、エンジニアに対して「開発側が遅いんじゃないか」というイメージができてしまう。でも、エンジニアからしたら「設計からリリースまでに時間がかかっているのは、企画側の要件定義が甘いからじゃないか」と言いたくなるときもある、といった具合に。こうして本来協力して事業の成果の最大化に向かうべき者同士が争っていては、成果を上げることはできません。

この状況を打破し、企画からリリースまでのフローを最適化する第一歩として、「工程ごとのリードタイムを全て可視化してチーム全体の共通認識をつくり、ボトルネックをあぶり出すべきだ」と考えました。

カンバンなら、注力すべき案件の優先度を管理しやすく、その案件がどの工程に居るかをチーム全員がいつでも把握できます。また、工程ごとのリードタイムについて、異なる職種間でも簡単に認識を合わせられるおかげで、リードタイム短縮のためのボトルネックも見つけやすく、解消しやすくなりました。

プランナー、デザイナー、エンジニア、プロダクトオーナーが集まり改善ミーティングを以前から実施していますが、カンバンを導入してから「その案件がどう進んだか」「無駄はなかったか」「もっと速くできたところはなかったか」に着目しやすくなり、ボトルネックの改善につなげることができています。こうした取り組みを続けることで、各工程のリードタイムがどんどん短くなり、カンバンを導入する前と比較して、企画からリリースまでのリードタイムを半分に短縮できましたし、チーム全員が納得感を持ってボトルネックの改善に取り組めるようになりました。

――開発プロセスを見直すことでリードタイムが短縮できたとのことですが、具体的にどんな課題を解決したんですか？

上島：カンバンという形でリードタイムや在庫を可視化したことで、開発フローに着目しやすくなり、既に存在していたいくつものボトルネックを発見できたので、それらを1つずつ解消していくことでリードタイムを短縮していきました。

最初に着目したのは「開発のリードタイムの長さ」。特にコードレビューに時間がかかっていたんです。当時の進め方では、「コーディング」「レビュー依頼」「レビュー」「フィードバックの反映」と、フローごとに小さな待ち時間が発生していました。「それなら形式を変えて、モブプロで開発すれば、待ち時間がなくなるからリードタイムが短くなるのでは」と考え試してみました。想定通り、待ち時間がなくなった分、開発のリードタイムを短縮できました。

次に着目したのは「検証のリードタイム」です。開発が完了した案件は、リリースした後にABテストを行って案件の効果を検証し、良い結果が出たもののみを反映しています。ただ、ABテストの開始から完了までの時間が長く、「検証待ち」の案件がどんどん増えてしまっていました。しかしABテストには「一定期間のデータを、有意差検定を行えるレベルの分量で集めないと確からしい検証ができない」という特性があり、単純にテスト時間を短くするという方法はとれません。だったら、「同時並行で複数のABテストを進められるように、テストのための検証画面を増やせばよい」と考え、同時に検証できるテストの数を増やすことで、開発した案件を効率的に検証できるようになりました。

そうして同時並行で検証できる案件数が増えれば、次は検証画面を常に最大限稼働させられるようなペースで、プランナーが企画を出す必要が出てきます。

このように企画、開発、検証のそれぞれの工程で改善を回しながら、リードタイム短縮のためのボトルネックを解消しています。ボトルネックを取りこぼしなく見つけて潰していくために、計測するメッシュを細かくしたり、データを見るスコープを変えたりと工夫を重ねていて、カンバンを使った開発プロセスはその一端を担っています。

――リードタイムの他にはどんな改善指標を設定していますか？

藤原：成果の最大化のためには、企画そのものの質が高いことも大切です。そのため、案件のリリースによって創出できた価値の大きさを検証し、改善指標としています。

1件のリリースの価値の大きさはもちろん、5件リリースしたなら5件分の価値が出せているか、1カ月のすべてのリリース数に対して妥当な大きさの価値が出せているかも検証しています。もしリリース数に対するアウトカムが想定より低ければ、企画の質に問題がありますよね。

どんなにリードタイムを短くしてリリースを繰り返しても、そうしてつくったものが価値を創出できていなければ、事業の成果にはつながりません。そうならないように、企画の質も改善指標として設けていて、プランナーも協力してくれています。

――カンバンを使い開発を進めて5年間。これまでを振り返ってどんな収穫がありましたか？

藤原：この5年間で徹底的にボトルネックを探して潰してを継続してきたことで、大きなボトルネックが見つかることは少なくなりました。そして、プランナーとエンジニアなど職種の異なる者同士が「リードタイムの短縮」を同じ目的として振り返りと改善を重ねていくことで、「いかに自分の仕事を速く終わらせるか」ではなく「いかにチーム全体として高速に質の高いものをつくっていくか」に目線が向くようになったと思います。

――いま、新たな課題やボトルネックはありますか？

藤原：異動等でメンバーが入れ替わるたびに、ボトルネック解消のためにとっている取り組み1つ1つの意義が薄れていってしまっているのが、目下の課題です。

新しく入ったメンバーは、今の取り組みを始めた経緯を知りません。各取り組みの目的を、勉強会などで伝えようともしていますが、当時からいるメンバーと同程度に理解することはどうしても難しい。

最初は明確な目的や効果があって始めた取り組みでも、その施策を始めた当時のメンバーがいなくなっていくうちに、「前任者がやっていたから同じようにやるものだ」と、目的を理解せずにとりあえずやっているだけの状態になっていってしまいます。さらに、その状態でも直ちに問題が発生するわけではなく、当面はうまく回ってしまうから、「その取り組みをやっておくこと」が目的になっていくんです。そうなると、今やっている取り組みが形骸化し、徐々に新たなボトルネックが生じてくるだろうと危惧しています。

ただ、新しいメンバーが入ってきてくれたからこそ「その取り組みは本当に効率的なのか」という疑問に気づけることもあります。人の入れ替わりも改善につながるとも言えますから、メンバーの入れ替わりがチームのプラスになる要素も生かしていきたいですね。

上島：ボトルネック自体は決して悪ではなく、どんなに改善を回しても、内外の環境変化によまた別のどこかで発生したりと、必ず存在し続けるものです。

大切なのは改善サイクルを回し続けることであって、それができればチームは一定以上のスピードで動いていけます。改善サイクルが回らなくなってしまうと、気づかないうちに改善したはずのプロセスが陳腐化して、リードタイムも悪化してしまうといったことが起きるでしょう。 

我々が実現したいのは、開発という手段を使って、短い時間で多くの価値をユーザーに届け、事業の成果を最大化することです。そのために、リードタイムを適切にし企画の質を高め続けられるよう、改善サイクルを回していく。この目的と手段の関係を見失わずに、チームが動いていけるようにするのが、我々マネージャーの務めだと思っています。

――マネージャーがこうした環境を整えることで、現場では日々の案件の開発に全力で取り組むことができているんですね。

藤原：我々がしたのは、2018年にカンバンを使った開発プロセスに移行すると同時に、開発に関する定量的なデータを計測し誰でも自由に確認できる状態にするところまでです。それ以降は、我々マネージャーが直接関わらなくても、チームが自律的に改善サイクルを回してくれています。振り返りには一応マネージャーである我々も参加することがありますが、特に我々からフィードバックするようなこともないですね。

上島：各工程のリードタイムを数値としてはっきり計測できているので、ファクトベースで議論できるんですよね。「計測結果」は圧倒的な事実で、それをベースに議論すれば職種ごとの優劣や上下関係は生まれないし、「チームとしてどうだったのか」と全体の動きにフォーカスした議論をしやすくなる。これが、チームが自律的に動き、改善サイクルを回せている肝だと思いますね。

取材・執筆：青山 祐輔