このエントリは全9回を予定する18卒新人ブログリレーの第4回です！

今回は、SUUMOのモバイルアプリ開発の現場から、企画と開発が一体となったチームでの開発プロセスについてご紹介します！

はじめに

はじめまして。リクルートテクノロジーズ新人の三田涼介です。現在は不動産検索サービスSUUMOのAndroidエンジニアとして働いています。

今回はSUUMOアプリチームの開発プロセスについて紹介します。

SUUMOは巨大なサービスでありながら日々高速に改善を行っており、週1回以上の頻度でiOS、Androidの各OSでリリースを行っています。このスピード感を実現するために、開発プロセス自体も日々磨き込みが行われており、私が配属された3ヶ月前にも開発プロセスに大きな変化がありました。

この記事では、私が新人としてキャッチアップしていく中で学んだ、

• なぜ開発プロセスを選ぶことが必要なのか
• どうやって開発プロセスを選べばいいのか

ということについて、SUUMOアプリチームの取り組みを例に紹介したいと思います。

スプリントからカンバンへ

SUUMOアプリチームは、事業領域ごとにチームでの開発を行っており、それぞれが事業の特性やチームの状態に合わせた開発プロセスを運用しています。私が配属されたチームは、プロダクトオーナ(PO, 開発案件の優先順位を決める人)、プランナー（開発案件の企画をする人）、エンジニア（開発する人）、チーム推進（開発の進め方に責任を持つ人）で構成されていたのですが、ちょうどそれまでのスプリント方式での開発からカンバン方式への移行を検討している最中でした。

スプリント方式の開発では、2週間を1つの単位（1スプリント）として開発を実践していました。具体的には、プランナーの方が企画した新機能や機能改善などを案件として蓄積し、各スプリントのはじめにそのスプリントで開発する案件を選定し、スプリント中は設計、開発、テストを行い、スプリントの終わりに新機能としてリリースするというサイクルを回すものでした。このように企画と開発が一体となって、短いサイクルでの開発を実践していました。

一方現在のカンバン方式では、案件の企画からリリースまで流れをすべて一つのカンバンボード上で管理しており、期間で区切ることなく、1つの案件の開発が終わったら次の案件に着手するという流れで開発を行っています。

チームでの開発経験が浅かった私は、スプリントというと最近よく使われている、なんかいい感じのプラクティスというような印象しか持っておらず、またカンバン方式にすると何が嬉しいのかもよくわかっていなかったため、その背景について調べてみました。

SUUMOアプリの事業背景

そもそもの勘違いなのですが、いい感じのプラクティスなんか存在していませんでした。

時と場合によって最適な開発プロセスは変わってきます。達成すべき目的に対して最適な開発プロセスを選んで、運用しながら磨き込んでいくことが求められるそうです。「なんか流行ってるから」とか「なんかイケてそうだから」のように手段先行ではなく、何を実現したいのかを明らかにする必要があります。

そこでまずはチームの事業背景について調べるところから始めました。

SUUMOは国内最大規模の不動産検索サービスです。モバイルアプリのアクティブユーザも増え続けており、私の所属しているチームでは“ユーザに提供する価値”を最大化するための機能の磨き込みが最重要課題となっています。例えば、物件の情報がひと目でわかりやすい画面構成の磨き込みなどですね。私達のチームでは複数のA/Bテストを並行して実施しながら、定量的な指標に基づいた改善を進めています。

このような磨き込みのフェーズでは、仮説の立案、仮説検証のための機能開発、A/Bテストでの計測、振り返りによる学習と仮説の補強からなるBuild-Measure-Learnからなる仮説検証のサイクルを次々と回していくことになります。

こうした中で、世に提供する価値を最大化するためには、

• 1サイクルでの学習の質を高める
• 1サイクルを回す速度を高める
• 同時に回すサイクルの数を増やす

の3つの方針が考えられるんじゃないかと思います。今回はこれらのうち、定量的に評価しやすい、1サイクルを回す速度と同時に回すサイクルの数について考えてみます。

サイクルを速く回すには、1サイクルの間のムダを徹底的に排除し、案件の企画からリリースまでの時間が最短となるような開発プロセスを選定し、実践していくことが求められます。

一方、同時に回すサイクルの数を増やすには、できるだけ多くの案件を並行して企画、開発、リリースすることが必要となります。

もちろんどちらもできるに越したことはないのですが、現実には作業できる人数や工数の制約があります。それではどちらを優先すれば、より効率のよい開発が実現できるのでしょう。

フロー効率とリソース効率

結論から言うと、まずは仮説検証にかかる時間の短縮を目指すべきです。

理由としては2つあり、

• ユーザに提供できる価値が結果的に多くなる
• 開発におけるムダ、課題が可視化されやすい

これらの利点からまずは仮説検証にかかる時間の短縮から手を付け、ムダや課題を解決した後に並行して稼働する案件の数に取り組んでいくのがよいと考えています。では、時間の短縮がなぜこのようなメリットにつながるのでしょうか？

ここで、効率についてフロー効率性とリソース効率性という２つの考え方について紹介します。

この２つはSUUMOアプリチームに配属されると繰り返し耳にすることになる概念です。

フロー効率性とは、 一つの案件が企画されてからリリースされるまでの時間効率のことを指しています。1サイクルが速ければ速いほど、フロー効率性は高まります。

一方のリソース効率性は、作業に取り組む人員の稼働率を指標とする考え方です。メンバー全員が時間のある限り取り組める仕事を割り振られている場合に最大となるので、同時に並行してたくさんの案件に取り組む方がリソース効率性は高まります。

例えば、チーム内で同時に複数の機能開発案件（それぞれの工数が15人日）に取り組んでいる場合を考えます。このとき、これらの機能が世にでるのは3週間後となるため、学習までのリードタイムは長くなり、フロー効率は犠牲となります。一方で、複数の案件が進行しているため、手持ち無沙汰な人は生まれにくく、人の稼働率は高い状態を維持できます。これはリソース効率性にフォーカスした開発プロセスと言えます。

一方で、フロー効率性を重視した場合、極端にいうと、チーム全員で同時に1つの案件に取り組んで、できたものから順次リリースしていくことになります。ソフトウェア開発では、常に並行して進めることのできる作業があるとは限らないので、手持ち無沙汰になる人が発生しやすくリソース効率は犠牲になります。ただ、個々の案件は最短でリリースすることができるので、“ユーザに提供する価値”はリソース効率を重視した場合に比べて積み上げ式に多くなります。また、フィードバックも迅速に得られるため、次の企画への動き出しや修正も早くなります。同時に検証する仮説も少ないほうが、計測と分析がクリアになるというメリットもあります。

フロー効率性とリソース効率性について詳しくは、以下の資料を参照ください。

私が所属するチームの現在の目的は”ユーザに提供する価値”の最大化なので、まずはフローを重視した短いサイクルタイムでの開発を行うべきです。いつでも大事なのは目的をどう実現するかです。

そこで私達のチームでは2週間のスプリントでの開発を行っていました。しかしながら、次第にリソースの稼働が優先され過ぎた結果、提供する価値の最大化が達成しにくい状態に陥ってしまったそうです。

なぜスプリントがうまくいかなかったのか

先述したとおり、現在は磨き込みに注力しているので、とにかく早く価値を提供しようという意識をチーム全員が共有していたそうです。その結果、2週間に1度のリリースのタイミングでできるだけたくさん案件をリリースしようと、限界まで多くの案件に同時に着手するような運用が自然と行われるようになっていました。つまり、スプリントのタイムボックスが制約となり、フロー効率が優先されるべきところをリソース効率的が重視されるような力学が自然発生してしまっていたのです。

また、稼働率を限界まで高めてしまった弊害として、優先度の高い案件に遅れが発生してもリカバリできずにリリースが遅れてしまう一方で、優先度の低い案件が先にリリースされるような事態が起こっていました。このようにタイムボックスに囚われてしまった結果、最上段の目標である、”ユーザに提供する価値”の最大化を実現することが難しい体制になってしまっていました。

在庫のムダも無視できないものになっていました。案件が実装されるよりもプランナーが案件を企画するペースのほうが早かったため、在庫が肥大化していき、一度時間をかけて工数見積りしたにもかかわらず、開発が進む間にコードベースの状況が変わっており、実際に着手できる状態になったときに工数の再見積もりをせざるを得ないようなケースもしばしば発生していました。

ただ、これはあくまで現在のSUUMOの事業背景と開発チームにとって相性が悪かったためにリソース効率的な力学が働きやすかったただけであり、決してスプリントの仕組み自体に問題があるということではありません。

このような中で私達は、一度開発方針を見直し、現在のチームの開発背景により適した方法を探した結果、カンバン方式を採用することになったそうです。

この辺りの話は以下のタウンワークでの事例を参考にしたそうです。

こんな風に社内でナレッジが共有しやすいのは、多くの事業を抱えている会社ならではのメリットだと感じました。

なぜカンバン方式を選んだのか

カンバン方式とは、工程間の仕掛け在庫を最小にする、必要なときに必要なものだけを生産するジャスト・イン・タイム生産方式を実現するための方法論です。

企画からリリースまでの各工程に現在どれくらいの在庫が積まれているのかを示すカンバンを用いて作業の流れを可視化することで、フロー効率の改善に意識を向けやすくなります。

カンバン方式は以下の6つのコアプラクティスに支えられるとされています。

• 作業の可視化
• WIP制限
• 流れの管理・測定
• 明確なポリシーを作る
• カンバンからのフィードバック
• 常態的な改善・進化

つまり、各作業工程の可視化を行い、WIP制限を用いて同時に着手していい作業量に制約を与え、きちんと計測をおこなってボトルネックの特定を行い、ボトルネック解消のための打ち手を考えて実証してみるサイクルをきちんと回すことで、開発におけるムダの排除とリードタイムの改善が達成できます。

スプリントでの失敗は企画と開発それぞれが、同時にたくさん企画して同時にたくさんの開発に着手するというように、全体のバランスを考えず目の前だけに集中するようになってしまった結果起こってしまいました。なので私達のチームでは、企画部分と開発部分で局所最適に陥らないよう、企画の立案からリリースまでを一貫して扱うカンバンをつくることで、案件創出からリリースまでの全行程でのリードタイムを最短にできるよう、カンバン方式の導入を決定しました。

在庫量の可視化により、必要なものを必要なだけ作ることが可能になります。これにより作り過ぎのムダの改善が期待できます。案件が滞留しやすいレーンも可視化されるので、ボトルネックになりがちな作業も明らかになります。これは継続的な開発プロセスの改善に有用です。

WIP制限を設けることで、優先度の高いものからきちんとユーザの元へ届けられるようになることが期待できます。

運用方法

実際の運用方法について説明します。JIRAのカンバンボードを用いた運用をしており、各レーンは

起票、リファインメント、READY、開発作業中、リリース待ち、分析待ち、Close

に分かれています。

現在はリファインメントからリリース待ちまでの工程ではWIP制限を設けて、作業量に制限を与えています。すべてJIRA上で管理しているので各工程に費やした時間の計測が可能です。また、チームの状況に合わせてレーンを減らしたり、増やしたりと柔軟な運用を行っています。

物理ボードではなくソフトウェアで管理しているおかげで、案件の各レーンでの滞在時間や実際に作業に費やした時間の計測ができています。そもため、開発プロセスの改善でもきちんとBuild-Measure-Learnの仮説検証サイクルを回し、定量的な指標に基づいた会話が行われているのはチームに配属して感心したポイントでもあります。

ただ、たしかに物理カンバンで得られるメリット（見に行かなくても目に入りやすい、柔軟に設計を変えられるなど…）は犠牲になっていると感じる部分もあります。 現在は、朝会、夕会などの日次ミーティングでメンバー全員でカンバンを確認したり、なにか不都合や改善点があればすぐJIRAのカンバンをカスタマイズして対応したりすることでカバーしています。

導入してみてどうだったか

カンバンに移行してからWIP制限を意識することで、同時に取り組む案件数は抑えるようにしています。厳密な比較はできていないのですが、昨年度と比べると案件のリリースまでのリードタイム(LT)も確実に短縮できていることが計測結果からわかっています。特に開発に着手してからリリースされるまでの時間は劇的に短縮されています。すごい！

導入からたった3ヶ月でこの結果です。改善できる白地はいくらでも残っているので、まだまだスピードアップさせていきたいです！

具体的な働き方の変化についてですが、同じ案件に複数人で着手する機会が増えたので、メンバー間の会話が多くなったと感じます。

特に、同時に着手できる案件数が制限された結果、ペアプロ・モブプロを積極的に取り組むようになりました。コードレビューが必要なくなったり、設計レベルでの手戻りが少なくなったりしているのでリードタイム短縮に効いていると感じます。

結果的にリソースの稼働率が抑えられているおかげで、チームとしての柔軟さも向上しているように感じます。突発的に割り込んでくるような開発案件もたまにあったりするのですが、作業に余裕があるエンジニアが控えているおかげで問題なく対応できています。

また、OS別でカンバンを分けることをしていないので、ときにはAndroidだけ、またはiOSの案件だけしか開発作業中レーンに並んでいないこともあります。そのため別OSを学習しようとする意欲が高まっており、その機会も増えています。私自身もAndroidエンジニアとしてチームにジョインしましたが、Androidの案件が無いときは積極的にiOSの案件に参加して、ペアプロなどに取り組むことでベテランの方の知識を吸収しながら開発を進められています。自分では思いつかないような実装方針やハマりどころをお互いに共有できるのでペアプロ・モブプロはとても楽しく学びも多いです。

おわりに

配属されてからの3ヶ月で、

• 開発プロセスによってチームの生産性が大きく変わりうること
• 目的の明確化、それに応じた開発プロセスの選定が重要となること
• 開発プロセスも日々改善していくことでチームとして成長できること

を学ぶことができました。

また、効率性についても学べたおかげで、目の前の自分の開発作業だけに集中するのではなく、チームとしていかに早くユーザの元へ価値を届けられているかについても意識できるようになったと思います。

今後も視野を広く持ち、チームとしての提供価値を最大化できるように、開発と改善に取り組んで行きたいと思います。

カンバン方式に移行してからの各工程での案件の滞在時間を計測した結果、リリース待ちがボトルネックとなっていることがわかりました。したがって、今後は、リリース頻度の増加とリリースフローの整備にチームとして取り組んでいく方針です。

また今回は開発プロセスの改善によるムダの排除の話をしましたが、もちろん技術によって解決できる白地もたくさん残っています。例えば、技術負債の解消やアーキテクチャの刷新、チューニングによるビルドの高速化などにも取り組んでいます。いずれまたブログエントリで紹介しようと思っています！

追記

思ったより反響があってびっくりしました。コメントやはてブありがとうございます。フィードバックのおかげで自分の中で曖昧だった箇所が見つかったり、新しい考え方を知れたりと、とても勉強になりました！

いくつかご指摘頂いているのですが、説明が足りていない部分があったため、補足をさせて頂きます。

スプリントに関しては、記事でも触れている通り、問題がある仕組みだとは考えていません。リリース頻度とスプリントのタイムボックスが別のものであることも理解しています。”提供価値の最大化”を目的に「リードタイムを短くする」ことを目指して、当初はスプリントというプラクティスを活用して開発を進めていました。しかし、原理原則をチームや取り巻く環境が理解しきれていなかったこともあり、本来目指していた方向から徐々にズレが生じてきていました。その課題を解消するための一つの手段としてカンバンに振り切った形です。

私達は、「アジャイルをする」のではなく「結果的にリードタイムが短くなっている」状態を目指していました。
なので、いわゆるきちんとしたプラクティスには従えてはいないかもしれませんが、リードタイムの改善は達成できています。でも頂いたコメントのような正しいアジャイルのやりかたを知っていれば、もっと効率よく改善できたかもしれません。ここは引き続き勉強がんばります！

私達は”提供価値の最大化”を優先し、実現のための手段にはこだわらず、その時々のチームに最適なものを取捨選択しながら装着して成長していこうと考えています。チームが成熟し、別の課題や伸びしろが見つかれば、再びスプリントを導入したり、もしくはもっと別のプラクティスを導入したりしているかもしれません。
記事中の表現についてですが、チーム内でのコンテキストのまま使ってしまっている部分もあり、違和感のある箇所が多々あったかと思います。この点に関しても引き続き学習を進めていこうと思います！
繰り返しとなりますが、この記事でお伝えしたかったのは、チームを取り巻く状況と目的に合わせて柔軟に開発プロセスを選定し、日々改善していくことの大切さです。

引き続きブログエントリで発信を続けていければと思います。よろしくお願いします！