STORES では、それぞれのプロダクトを横断した機能開発にチャレンジする機会が増えてきています。一方で、 STORES は今までそれぞれのプロダクトに開発チームが紐づいていたことから、その連携や横断には課題もありました。それを解決に導いたのが「LeSS」の導入です。PdMの視点で開発の生産性向上にこだわり、LeSS導入の旗振り役を務めた淺田純史さんに、その経緯や成功の秘訣をききました。

事業の優先順位に沿って開発ができる「LeSS」

──まずは、現在の仕事について教えてください。

私には、現在ふたつの役割があります。ひとつは、プロダクト部門のPdMとしてSTORES のプロダクトをいかに使っていただくかを考えること。特に、複数のプロダクトを使っていただくために STORES のプロダクトの基盤の統合や、エンドユーザーの情報を統合するプロジェクトをリードしています。

もうひとつは、テクノロジー部門の開発企画室として、開発の生産性を上げること。開発からリリースまでの時間をいかに短くできるかを推進しています。

──ありがとうございます。このインタビューでは、後者の「開発の生産性を上げる」ための取り組みについてお話を伺っていきたいと思います。まず、このために取り入れている手法があるとか。

「LeSS」を採用しています。LeSSとはLarge-Scale Scrumの略で、1つのプロダクト開発を複数のチームでスクラム開発するためのフレームワーク版だと考えてよいでしょう。

スクラム開発はひとつのチームがひとつのプロダクトを作るのに有効なフレームワークですが、1つのプロダクトを複数のチームが開発することが想定されていません。プロダクトが大きくなってきた場合、チーム数が増え、スクラム開発だけではまかなえない点が出てきます。

例えば、プロダクトの規模が大きくなってくると、機能ごとに特化した開発チームが編成されます。一見効率が良いように見えますが、プロダクトのなかで優先順位の高い開発がどれかの機能に偏っていると、優先順位が高いはずなのに、他のチームが対応せず「待ち」の状態になってしまったり、プロダクト全体では優先順位の低いタスクがある機能のチームでは優先順位が一番高いという理由で進んでいくなど、理想的な順位での開発が行えなくなってしまうのです。

──LeSSでは、それが解決できるのですね。

LeSSは開発チームごとに機能を固定しないのが特徴なので、プロダクトの優先順位に沿って開発を行えます。

具体的には、全体を見るプロダクトオーナーとスクラムマスターがおり、各チームに優先順位が高い機能開発を割り当てていきます。各チームはプロダクトに関わる全ての知識と視点を持ち、どの機能も開発できる状態にします。開発する機能が固定されないので、スプリントごとのレビューや計画は全員で行い、全員がプロダクトの全ての機能を理解した上で開発を進めていきます。

そうすると、全てのチームが全ての機能の開発を行えるので、プロダクトにとって優先順位が高いタスクから着手することができます。ひとりひとりが見なければいけない範囲が広くなりますが、プロダクト全体を見渡す視点を持って開発をしてもらえるのが利点です。他のチームと一緒にレビューを行ったり、質問があれば他のチームに聞きながら開発することも可能です。

オフラインミーティングで浮き彫りになった、言葉の定義の違い

──LeSSについてわかってきたところで、ここからは  STORES での導入についてお伺いしていきたいと思います。まず、LeSSを導入する前の STORESにはどのような課題があったのでしょうか。

STORES では、もともとスクラム開発を行っていました。 STORES（ネットショップ）、決済、レジなど複数のプロダクトごとに開発チームを編成しそれぞれが開発を行うものです。そのため、各プロダクトの個別最適はできていましたが、機能開発の順番が事業として優先順位が高いものと一致しないという課題がありました。

また、横断での開発が苦手な組織であることも課題でした。各プロダクトの連携が始まり、横断プロジェクトが立ち上がると、コミュニケーション不足から、それぞれの認識が合っていなかったり、それぞれが都合よく解釈して開発するので結合してみるとうまく動かないといった問題が発生していたのです。

──LeSSを導入し始めたのはいつ頃のことなのでしょうか。

去年の3月頃、プロダクト横断の「予約システムとひとつになったPOSレジアプリ」の開発が始まった時です。前職の経験からその時の課題にLeSSが合いそうだとチームに提案し、プロジェクトメンバーが賛成してくれたことから導入が始まりました。まず勉強会を行い、LeSSのフレームワークを全員に理解してもらいましたが、初めは思うようにいかないこともありました。

──どのような点でしょうか？

全員でスプリントごとに計画やレビューを行ってみたものの、スプリントゴールは全員で決められても、具体的なタスクを議論する時には元のチームに分かれてしまいがちだったのです。結果、スクラム開発を行っていた時と同じような課題が出てくるようになり、2ヶ月くらいその状態が続いてしまいました。

──これをどう解決したのですか？

スプリントごとのレビューと計画を、メンバー全員で丸一日かけてオフラインで行うことにしました。11時から13時までを振り返り、昼休憩を挟んで14時から18時までを計画にあて、丸一日かけて徹底的にタスクを洗い出してもらったのです。この日はコードを書かずに、2週間のスプリントの間に必要なことを全て話してもらいました。

すると、面白いことがわかってきました。同じだと思っていた言語の認識が違うこと。例えば「店舗」「ユーザー」といった一般的な単語でも、それぞれのプロダクトごとに微妙に認識が異なっていたのです。そこで、ひとつひとつの単語を細かく定義し、時にはホワイトボードに図を描いたりしながら少しずつ認識をそろえていきました。

こうして、普段使っている単語や、技術的なバックグラウンドの認識が揃ってくると、スプリントごとの計画とレビューを本当の意味で全員で行うことができるようになっていきました。現在も、全員でのオフラインでの計画とレビューは続いています。

LeSS導入を叶えた今、目指すのは緻密な工数見積もり

──LeSSを導入して1年あまりがすぎましたが、どのような効果や影響を感じていますか？

何度かLeSSを導入した開発を行ってみて、2、3回目からは失敗がなくなってきました。例えば、大きくリリースしようとしすぎて前に進まなかったことを踏まえて、次からは小さくリリースすることができるようになったり、オンラインミーティングがオフラインに移行され、より緻密な計画とレビューができるようになったり。回数を重ねるごとに生産性が上がっているのを感じています。

──その上で、現在目指していることや課題があれば教えてください。

横断で開発することができるようになった今、ロードマップにある開発案件全ての工数の見積もりができるようにしていきたいと考えています。会社やプロダクト全体が目指すゴールをどのくらいで達成できるかが明確になれば、ビジネスの見通しが立ちやすくなるからです。

そのために、PdMとして未来を予測し、それに対する緻密な見積もりができる体制を作るのが目下の目標です。

──お話を伺っていると、淺田さんの「生産性」へのこだわりを強く感じました。この原体験はどこにあるのでしょうか。

PdM出身だからなのだと思います。PdMとしてたくさんの作りたいものを作るには、開発の生産性を上げることが必須です。それならば、それをチームにだけ任せているのではなく、自ら協力できることを探した方が良い。そんな思いから、LeSSの導入をするなど生産性向上のアイデアをだしてきました。生産性が上がることで、世の中にたくさんのプロダクトが出ていき、社会と事業に貢献できるのが私の願いなのです。

──ありがとうございます。最後に、 STORES のプロダクトで実現したいことを伺ってこのインタビューを締めくくりたいと思います。

「Excelに勝つこと」です。SaaSは、ユーザーがSaaS内で完結しないことをExcelで補って運用している場合が多いと感じます。Excelを使わなくていいようにSaaSを提供しているのに、いつまでもExcelに勝てないこのジレンマは、私が解決したい大きな課題です。なので、私の目標は「Excelに勝つこと」。そのプロダクトだけでやりたいことが完結して、他に補助ツールを必要としないプロダクトを作り上げるのが目標です。

デザイン：石橋 講平
写真・文：出川 光

＼ STORES では一緒にはたらく仲間を募集中です！／