「LeSS」や「スクラム」導入の効果はどう測定しているか　Retty×アカツキゲームス× atama plus三者三様のやり方

atama plus、アカツキゲームス、Rettyが「開発改善チーム」を作っている理由

常松祐一氏（以下、常松）：各社の中の人という、推進者でもなくスクラムマスターでもない、「LeSSに巻き込まれた人」というのもなんですが（笑）。今LeSSに実際に携わっている立場からの話ができたので、次のトピックにいってみようかなと思います。

次は「LeSS以外で開発を大きく変えようとしていることはありますか？」ですね。今日の話を聞いていて、「意外と3社で共通しているな」と思ったのがアレですね、開発改善と言うんですか？

石毛琴恵氏（以下、石毛）：はいはい。

常松：たまたま3社とも、「バックログでは優先順位が上がらないんだけど、開発としてきちんと対処しておかなくてはいけないもの」に対応するチームを、LeSSの中や外に作っていたのですが、これはどんな経緯で作られたのですか。では、atama plusさんからお願いします。

深澤良介氏（以下、深澤）：スクラムチームはUXやQAの人、Devの人を交えて機能開発を十全にするためのチームで結成されているのですが、技術に特化した話題を扱うとなると、UXの人は「そのチームで何やるんだ？」と仲間はずれに少しなっちゃったりしていて。やはり専門領域ややるジャンルが少し違ってくる場合、チームのかたちも見直した上で、別チームを作るというのがけっこういいだろうなという話がありました。

あと、技術のバックグラウンドがないプロダクトオーナーもやはりいるので、そういう人に技術的負債の話や「フレームワークをアップデートするとこういう良いことが……」ということを言っても「うーん、わからん」となってしまいます。なので、そういう優先順位の判断をしやすい人がチームをリードするという構造がけっこう大事かもなと思っていて、1つのチームがスピンオフした感じですね。

常松：アカツキゲームスさんはどうですか？

石毛：経緯としては、最初にテストの自動化をしたいという話が出たのが大きかったかなと思っています。今は開発チームが3チームあるので、ゲーム開発をする中で検証をする時に、特にリグレッションテストなどで毎回すごく工数がかかってしまったり、抜けや漏れが発生してしまったりということがありました。そこをもっと自動化していきたいよねという話はずっとあったのですが、なかなか動かせていませんでした。

片手間ですぐにできるものでもないので、どうしようかなとなった時に、そういったものを優先度高くやってもらうというのが理想かなと最初に思いました。でも、先ほど深澤さんの話にもあったとおり、やはりPO（プロダクトオーナー）が技術者上がりでないなどさまざまな要因があって、（優先度が）上がって本腰入れてできるという状況にはなかなかなりませんでした。

それならば、いったんは別チームとして切り出して、少数精鋭でチームを作ってそこでやったほうがいいのではないかというところで、チームを分けました。「それをやりたい目的」や「何をやるか」というところはPOと認識を合わせて、「こういう目的でこういうことをやりたいです。このぐらいの期間はかかると思います」とコミュニケーションを取って、別で動いている感じです。

常松：うちの場合だときっかけは若干違います。もともとSREというか、攻めのアプリケーション改善というか、サービスをより安定して稼働させられるように、わかっているものである程度エンジニアリング的に効果が期待できるものは中長期でやったほうが良いよね、というところがあってチームを発足しています。生産性や開発者体験などでけっこうそういうチームが発足している各社の事例があって、それを飲み込みながらだんだんと今のかたちに落ち着いていったのがそのチームです。

バックログもやはり分かれてはいて、そのチーム単独で「私たちのチームが課題として改善できると思っていますよリスト」を持っています。でも、結局それを独自に運用しているというよりは、コミュニケーションを取って今の会社の状況や事業の状況、他チームの状況などを見ながら「じゃあこれは上げたほうがいいですね」「これはいったん下げましょう」ということをやっている感じです。

LeSSやっていく上であれは必須なんですかね？　それとも、中長期でLeSSを継続していくためにはこういう取り組みも必要ですよという位置付けなんですかね？　「LeSSを構成する必須要素なのか？」と言われると「うーん、わからん」となります（笑）。

深澤：LeSSとは少し違う次元の話の気がしますね。「その開発全体をうまくいかせるために、ボトムアップ的なアプローチを特別な技術領域として扱わなければいけない」「じゃあそれはLeSSという枠組みからは少し違うかたちになるかもね」という順番な気がするんですよね。

石毛：（改善チームは）必須ではないとは思っています。一方で、現実的に直面しやすい課題に、通りやすいソリューションでもあるかなと思っています。うちだと、改善チームはまあまあ工数のかかる大きな課題に着手する立ち位置でやっていますが、もう少し小さいものもあって、本当はそういったものにも日々取り組んだり、バックログで取り上げなければいけないのですが、弊社ではまだそこまでうまくできていません。

やはり「機能開発したいです」というものがドーンとあると、そっちで忙しくなってしまって、なかなかそういったものに声を上げにくくなってしまいます。そもそもPOに届かないということが起こるので、アジャイルな計画作りなど、そういったところからもテコ入れをしつつ、改善チームに頼りすぎずに、日々の負債を溜めない努力や工夫をもっと考えなければいけないのではないかなぁとは思っています。

深澤：確かに。運用雑多業務を受けるチームのようになってくると「運用を気にしなくていいのか？」という世界になってしまうと思っています。

石毛：そうそう。

深澤：そういう分断はよくないなと思います。

常松：スクラムの中できちんと技術負債の解消や返却もしなければいけないのだけど、どうしてものところで（改善チームが）うまく折り合いつけていく。ただ、そのパワーバランスは適宜見直していく必要があるとは思います。

開発改善チームメンバーを入れ替えるタイミングは？

常松：少しTwitterから質問を拾ってみましょう。「技術課題を解決するチームはずっと専任なのか？　途中で飽きちゃいそうな気もする」。みなさんはどうされていますか？

石毛：あまり専任にする気はないです。今はそういうところに興味がある比較的初期メンバーなので、まだ「飽きた」「交代したい」という声は上がっていません。

例えば、外の会社さんから入って来た方や、他の事業から移動してきた方にまず改善チームに入ってもらって、少し慣れてもらってからプロダクト開発にいくケースもありますし、プロダクト開発をしている時に「やはりそっちのほうに興味があるからやってみたい」と言って移動するのもあります。

常松：深澤さん、どうですか？

深澤：実際のところ、改善チームを立ててからメンバーはほとんど変わっていないですね。ただ、扱っているテーマはけっこう多岐にわたっていて、入れ替わったりもしているので、ずっと同じことをやっているという状態ではないかなと思っています。

ただ中長期的に考えると、方向性としては、扱うテーマだったり、そのチームの立ち位置がどうなるべきかだったりは、やはり変化し得るだろうなという感じですかね。

石毛：うんうん。

常松：うちのケースで言うと、チームができて半年くらいなので、入れ替わりがまだない状態です。「じゃあ固定がいいんですか？」と言われると、入れ替えたほうがいいんだろうなという気がしています。

やはり飽きる人も出てくるだろうし、「そういう技術課題を解決していたら、KPIなどの数字を伸ばしたくなりました。もっとプロダクトをやっていきたいです」という人もいれば、プロダクトやっていて「課題だらけなので私がやりたいです」という人もいると思っています。

でも、「1年に何人かを入れ替えるペースなのかなぁ」と少し思っています。「3ヶ月とか半年で頻繁にグルグルするのがいいの？」と言われると、「んー、こういうものはもうちょっと腰を据えてやったほうがいいのかなぁ」という思いもあります。

石毛：改善チームにかかわらずLeSSもそうだと思いますが、それぞれのチームが安定していることを前提にして、一部のメンバーが交代するというのはあるじゃないですか。

常松：はい。

深澤：はい。

石毛：ノリはそれとあまり変わらないというか……。

常松：そうですね。チームを安定化するのが第一で、それは開発改善チームをLeSSの外に置いたとしても同じであって、それを壊さないように少しずつメンバーの入れ替えを考えていく感じですかね。

深澤：うん。

石毛：そうですね。

スクラム導入後の効果を定性的・定量的にどう測定しているか

常松：では、次の質問に移ります。「LeSSに限らず、スクラム導入後の効果測定についてどう聞かれているか。どう答えているか。どうしているか」。LeSSやスクラムの効果は出たんですか（笑）？

石毛：私、これ前に常松さんに個人で相談したことありますね（笑）。

常松：なんて答えましたっけ（笑）。

石毛：「え、事業成果だろう」って。

常松：でもこれ、何回か聞かれたことがある気がしますが2つ私は答えています。Rettyだと1週間スプリントですが、「優先順位の順に毎週きちんとできていて、それにステークホルダーが満足していますよね？」というのが1つです。LeSSの前は「そもそもできていなかった」「スケジュールが遅れて当たり前」という状態だったので、「それは改善しましたよね」「計画を立てやすくなりましたよね」というのが1つです。

もう1つが、チームを固定して、いろいろと改善を回してもらうので、やはりみんな楽しそうに仕事をすると思います。

石毛：うんうん。

常松：みんな楽しそうにしているので、そういう話を社内で拾い上げて、「こんな効果が出ていますよ」とよく伝えていますね。

石毛：そういう定性的なところもすごく大事ですし、特に導入初期はそういった効果を感じる人が多いと思います。

常松：定量的なものだと難しいですね。ベロシティと言われると……。んー、ベロシティ。ちょっと違うんだけどなー（笑）。

深澤：ベロシティは比較しにくいですからね。

常松：ふっふっふっふ（笑）。

石毛：定量で測るところはあまりLeSSもスクラムも変わらないのかなという気がしています。

常松：なんだかんだステークホルダーにきちんと満足してもらうのが大事ですね。ステークホルダーと認識を合わせるのがすごく大事で、ステークホルダーが満足していなければ、どんな定量の情報を説明しても意味がないだろうなとは思っていました。「うまくいってないじゃん」と言われて、「じゃあ『うまくいってない』ってなんです？」と聞くと、本当の課題がたぶん出てきますよね。

深澤：確かに。atama plusは、定量的なものを厳密にやっていたの？　と言われると、そうではありません。ただ「コミュニケーションのボトルネックが解消しているか」や「流動性がきちんと高い状態か」などは定性的に感覚として話をしているかなというところですかね。

あとは、ベロシティが安定していることは、LeSSによらず、スクラムチームがうまく組成できているかという話ともけっこう関連するので、定量的に見なくはないという感じですかね。

石毛：効果測定と言っても、チーム内で見ることなのか、ステークホルダーに対してなのかでもそれぞれ違いそうですね。

深澤：そうですね。

石毛：確かに、中向けとしてはベロシティを見ていますね。

バグや障害の発生における各社の運用作業は？

常松：もう1つ質問が来ています。「運用作業はどうなっていますか？　LeSSの枠の中にあるのか、LeSSの枠の外にあるのか」。「こういうバグが出ました」「障害が出ています」などありますよね。

深澤：これは難しいですね。今はスッキリしているのかというと、だんだん難しさが出ているかもなぁという感じです。

「バグが出た時にどのチームが見るといいの？」ですが、atama plusはけっこうモノリスな開発をしている状況で、コードベースも一緒のものをやっているので、（バグの）特定がしにくくて、「自分も詳しくないんだけどなー」という悩みがたまに出てきてしまいます。「LeSSの中でやっている」というのが正直な答えですが、やり方には工夫がありそうだなというところですね。

常松：うちだと基本、急ぎのものはLeSSのチームのどこかにお願いして対処をしてもらいます。あまり急ぎではない場合には、バックログに積んで優先順位を判断をしてもらいます。その上で、ある程度そういう割り込みがあるのは想定して、毎週のスプリントプランニングをしていたり、ある程度運用をきちんと減らしていくことに貢献してくださいねという目標を設定していたりはしますね。「自分で作ったサービスだから自分で見ていこうよ」ということですね。当たり前の話ではあるのですが……。

石毛：うちも中でやっていますね。担当したチームがあって、「この機能のバグだったらこのチームだね」という感じでけっこうスッとアサインされるので、そんなに困っていないかもしれません。

うちで運用と言うと、たぶんもっと大きな話になってしまいます。モバイルゲームを作る中で実際にイベントを作ったり、キャラを作ったりというところが「ゲームにおける運用」に近いです。例えば、みなさんのように管理画面やお問合せ対応というところまでを運用と言うのであれば、今はLeSSの外にありますが、そのチームを巻き込んでLeSSやっていこうかなという話をちょうど中で相談しているところですね。

（次回へつづく）