atama plus社・スクラムマスター松村高朗氏
司会者：事例発表の3つ目はatama plusさんです。では松村さん、よろしくお願いします。
松村高朗氏（以下、松村）：ではここから、atama plusのLeSSの紹介をしていきたいと思います。よろしくお願いします。まず始めに簡単に自己紹介をします。atama plusの松村といいます。2021年4月にatama plusに入社してからずっとスクラムマスターをしています。
会社の紹介をすると、「教育に、人に、社会に、次の可能性を。」というミッションを掲げて、教育を新しくしていくことで社会の真ん中を新しくしようをしている会社です。
このミッション実現のためにいくつかプロダクトを提供しており、その中でも一番大きいプロダクトでLeSSで開発しているのが「atama＋」という会社名と同じ名前のプロダクトです。
こちらは今、全国の塾・予備校さんに提供しています。学習教材なんですけれども、（スライドを示して）生徒さんにこういったタブレットの画面で学習してもらって、その内容を基に一人ひとりの得意・苦手なところを分析していって、最適な学習を提供するというプロダクトです。
ペルソナ別のスクラムチームで上がってきた2つの課題
松村：まずは、この開発になぜLeSSを導入したのかという話をしていきたいと思います。もともとペルソナごとに開発チームを組んでいました。これが2020年の5月までですね。例えば一番上のチームは、生徒さんの学習体験を良くするにはどうしたらいいかがプロダクトバックログにひもづく体制を取っていました。
例えば2番目の真ん中のチームだと、塾で指導する先生の体験が良くなるにはどうしたらいいかというところを考えたバックログと、それを開発するチームというところがありました。このペルソナ別のスクラムチームで、いくつか課題が上がってきていました。
まず1つが、3つのプロダクトバックログの優先順位が異なるというところです。各バックログがペルソナごとに最適化されたものだったので、全体で見た時に生徒さんの体験を良くするというところにたくさん課題があるのにも関わらず、バックログの作りやチームの構成がそうなっていないので、開発チーム全体として提供価値が最大化されないという問題が起きていました。
もう1点がスクラムチームのサイロ化ですね。ペルソナごとにチームが分かれていたのですが、プロダクトとしては同一なのでコンフリクトが起きたり。類似の開発をしようとしていても、隣のチームが何をしようとしているのかがなかなか見えにくくなっている状況があって、チーム間で協働がしにくいという状況が起きていました。
大規模アジャイルのフレームワークはいくつもありますが、そういった課題に対応するためにatama plusはLeSSを選んで導入しました。ペルソナごとに分かれていたバックログを1つに統合して、プロダクトオーナーを1人にして、そこに3チームがひもづくかたちで体制を組みました。
先ほど挙げた課題に関しては、ここでけっこう解消して開発も滞りなく進むようになったので、このあとはチームメンバーも増えて4チーム目、5チーム目というかたちを取っていきました。
LeSS Hugeに近い体制に移行
松村：（スライドを示して）これがLeSSの導入からアプデまでの流れです。開発体制は現在少し変わっているので、そこについても紹介しようと思います。
結論から言うと、今はLeSS Hugeに近いかたちで開発を行っています。メンバーが増えたりチーム数が増えることでコミュニケーションコストやPO（プロダクトオーナー）の負担がけっこう限界に近いところに来ていたのが一番の理由です。
このあと入社するメンバーも決まっていて6チーム目、7チーム目ができることは見越していたので、早いタイミングでLeSS Hugeに近い体制に移行しました。
LeSS Hugeだと本当は要求エリアをドメインごとにきれいに区切ったりするんですが、atama plusではそこまで区切らず、なんとなく、こっちのチームはだいたいこういったこと、下のチームではだいたいこういったことをやるというかたちでバックログを区切っていたので、「LeSS Hugeに近い体制」と表現をしています。
開発基盤チームを組成
松村：2つ目ですね。開発基盤チームというものを組成しました。ここはアカツキゲームスさんと似ていますね。LeSSに限った話ではないと思うのですが、技術的課題の投資判断の難しさというのがあります。POが4チーム、5チームの戦略を考えながら併せて技術的課題も投資判断するのがなかなか難しいところがあります。
もちろん、プロダクトを作る組織としてそういったところにも投資をする必要があるというところで1チームの組成を行いました。
LeSSで運用する上での工夫3つ
松村：ここまで、LeSSとLeSS Hugeに近いかたちの2つの体制を紹介してきましたが、2つに共通する、LeSSで運用する上での工夫について3点紹介していこうと思います。
1点目ですね。基本的かもしれませんが、スクラムイベントのやり方は、基本的に各チームにお任せしています。
LeSSで4チームや5チームが横並びでいると、なにか標準を作ったりルール化したほうがいいかなと思うところもあるのですが、実際にスクラムマスターとして各チームを回っていると、メンバー構成やチーム状況によって最適なやり方はぜんぜん違うなと思うので、基本的に各チームにそれぞれの最適なやり方を見つけるところをお任せするのが一番だと思っています。
もちろん良いプラクティスややり方をチームで共有するのも大事なので、オーバーオールレトロスペクティブで共有したり、スクラムマスターが回って共有したりしています。
2点目ですね。開発内容の検討は、POからなるべくチームに委譲するというところを大事にしています。単純にPOが忙しくなりやすく時間を取りにくいことが一番大きく、画面の文言だったり細かい仕様を全部検討できるかというと、実際はぜんぜんできないくらい忙しくなってしまうというところです。
POは最終的な意思決定をしたりしますが、基本的にPOは戦略までを検討して開発内容はチームで検討することが大事かなと思っています。
3点目ですね。複数チームで開発しやすくするための工夫も大事かなと思っています。atama plusには、フィーチャーチームの中にデザイナーがいて、エンジニアはQAとともに課題整理など仕様策定も行っています。
プロダクトバックログの上位に課題整理や仕様策定のチケットがあったからといって4チーム、5チームのみんなで取り組めるかというと、実際には非効率的だったり並行してできないところもあったりするので、そういった場合には、リードチームを設けて効率化を図っています。
そのあと複数チームで同じテーマを開発していく際には、通常のスクラムイベント以外にも合同でレビューを行ったり、他にも同期するタイミングだったりを設けるようにしています。
本当はスプリントプランニング1とかスプリントプランニング2などできれいにチケットを分割できればいいのですが、なかなかそこではカバーしきれない部分もあるので、そういったものに関してはコミュニケーション設計で緩和するようにしています。
先ほども出てきた話かもしれませんが、属人化していく内容はどうしても出てくるなと思っています。そういったものに関しては、ナレッジシェアの会議を開いたり、学習用のチケットを用意したりすることで知識を均していくことも大事だと思っています。
スクラムチームとは異なる観点での運営や支援が必要
最後にまとめですね。atama plusとしてはLeSSを導入することで、開発チーム全体で見た時に最適な優先順位での開発が可能になったと思っています。一方で、チームが増えるにつれてPOの負担が増えたり、チームとしてもけっこう難しさを抱えてくるところがあるので、適切なタイミングでエリアに分けるのが良さそうだと思っています。
またLeSSに関しては、1チームのスクラムチームとは異なる観点で運営や支援が必要だなと思っています。1チームスクラムに比べると、POとチームというところで人数比率がぜんぜん違ったり、横並びで何チームも見るという状況なので、そこの関係性は注視する必要があると思っています。
また、当然のように各チームが平等にすべてのドメインやコードベースに詳しくない状況が生まれてくるので、atama plusとしてはそういったものを一時的に許容して、部分的に効率化をしながらも後に均していくことが大事だと思っています。
atama plusのLeSSの紹介は以上です。プロダクト開発については情報発信をしているので見てもらえればと思います。
質疑応答
司会者：松村さん、ありがとうございます。今回の3社の発表は特に示し合わせていたわけではないのですが、けっこう似ているところも多いなと思いました。池田さんの話にはありませんでしたが、開発の生産性を高めるチームを、うちはLeSSの外に置いているかたちで、実は持っています。だから3社、実は一緒とか（笑）。
あとは属人性だったり、だんだんとスケールさせていくにつれてボトルネックが移っていくみたいなコミュニケーションの悩みというんですかね。そういうところはやはりLeSSをやっていく上で1チームスクラムにはない悩みになるんですかね。ちなみにまたちょっとチャットが元気ないんですが質問があれば……来た！
松村：（笑）。
司会者：「LeSS Hugeに詳しくないからかもしれませんが、かたちだけを見ると最初の複数チームに戻ったように見えました。最初とどこが違うのでしょうか？」。
松村：やはり結果を見た時には、けっこう同じようなかたちに見えるかもしれませんが、1つのバックログに複数チームがいるというところは大きく違うかなと思っています。でもやはり2チームできれいに切る、要求どおりに分けるのはなかなか難しいなと思っています。
司会者：LeSS Hugeというものの補足をちょっとすると、LeSSはプロダクトバックログが1個で全体として1つのスクラムを回すというのが基本なのですが、それでもチームが8チームとかを超えてくるとやはり全体を見きれなくなるので、ある程度のエリアだったりドメインだったりで分けましょうとなってそれがLeSS Hugeなんですよね。
LeSS Hugeになったらバックログが2個や3個になるのかというと、そうではなくて。バックログは1個で、その内のここのエリアやここのドメインはこっちが見ますみたいなかたちになって、そこでバックログの優先順位が一応均されるというか、優先順位を横並びで議論するというのがたぶんどうしても強制的に入るんですよね。そこがたぶん最初のところとの違いなのかなという気がします。
もう1個、質問が来ました。「複数開発チームで1つのフィーチャーに着手する場合、それぞれのチームにSBI（スプリントバックログアイテム）があると思うのですが、どのように対応したのかをぜひお聞きしたいです」。
松村：「SBIはあると思うんですが、どのように対応したか」ですね。1つのフィーチャーに着手する場合ですよね。特別工夫があるというよりは、各チームでこのスプリントのどういったところに対応するかを分担をしながらチケット分割をしていて、それをバックログに落とし込んでいくというところです。チケット分割でコンフリクトをしないような分割の意識が一番大きいかなと思っています。
司会者：特別工夫していることがないことはないんだけれども、「LeSSを入れてきちんとチームが分かれているからうまくいく」ではなくて、きちんとコミュニケーションや意思疎通を泥臭くやっていかないとうまくいかないというところですかね。
松村：そうですね。「これをやったから」というよりは、そういったものの積み重ねのような気もしますね。
司会者：じゃあ最後に、これだけ拾って次にいきたいと思います。「コミュニケーションの工夫について具体策があれば聞きたいです」。
松村：POとチーム間とのコミュニケーションですが、これは先ほどもお話ししたようにPOはどうしても忙しくなりやすく、チームから相談を持ち掛けにくい場面もあると思います。
もともとはオーバーオールレトロスペクティブで、チーム全員に対して「今週チームで話したいことはありますか？」と投げかけていたのですが、それだと手を挙げるハードルがなかなか高くて（手が）挙がらないということがありました。
なので、そこのハードルを下げるためにその直前に行われている各チームのレトロの内容をオーバーオールレトロスペクティブの中で共有してもらって、チームやPOに「ちょっとこういうところを話してみました」と相談して、それをきっかけに「これをもうちょっと話してみようかな」とチームやPOが拾って話を展開させていくことで、なるべくコミュニケーションのハードルを下げるところを意識しています。
司会者：なるほど。ありがとうございます。
