“リリース直前ちゃぶ台返し”が減少、開発の属人化が解消…　大規模スクラム内で取り組んだ4つの改善施策と効果

アカツキゲームス社・スクラムマスター吉野正義氏

司会者：では次は、アカツキゲームスさんです。吉野さん、よろしくお願いいたします。

吉野正義氏（以下、吉野）：それでは「LeSSを継続していく上で工夫していること」というタイトルで、株式会社アカツキゲームスにてスクラムマスターを担当している吉野が発表します。よろしくお願いします。

軽く自己紹介です。私は吉野正義と申します。サーバーエンジニアを担当しつつ、現在はスクラムマスターをやっています。最近はスクラムマスターの割合がかなり多いです。

LeSS導入で目指したこと2つ

吉野：では本日のアジェンダです。まず、軽くですが組織の紹介をして、そのあとメインとなるコンテンツでLeSSを継続していく上で工夫していることをお話しして、最後にまとめをお伝えしたいと思います。

最初に組織紹介です。私たちはモバイルゲームアプリを開発しています。LeSS体制は全体で60名ほどのチームで、プロダクトオーナーチームが1つと開発チームが3つ、あとは改善チームという組織体制です。

LeSSを始めた理由ですが、ここも簡単にお伝えすると、目指したことが2つあります。1つが自発的なチームを作るというところで、自分たちで個人やチームをどんどんと成長させていける組織を作る。あとはプロジェクトマネジメントの問題解決で、とある人に集中しているマネジメントコストを減らしたく、LeSSを開始しました。

というところで、さっそく本題を話していきます。「LeSSを継続していく上で工夫していること」ですね。LeSS内で取り組んだ4つの改善についてお話ししていきます。

（スライドを示して）こちらはLeSSを調べるとよく出てくる、LeSSの全体像と各要素ですね。これらの要素に対してこのような改善を行ってきました。スプリントレビューの改善、モブワークの導入、スクラムマスターの勉強会を開いたりとか改善チームの立ち上げですね。1つずつお話ししていきます。

取り組みその1　「ブレイクアウトルームを活用したスプリントレビュー」

吉野：1つ目、ブレイクアウトルームを活用したスプリントレビューというところで、現在私たちはZoomを利用してオンラインでスプリントレビューを行っています。Zoomには、全体のオンラインのミーティングルームではなく個別に小さく分けることができるブレイクアウトルームという機能があります。

それで部屋を分け、機能の開発を担当した人、関連する人と、あとは興味がある人にそれぞれ部屋を選んで入ってもらい、デモと実機プレイとフィードバックをする形式で動作確認を行っています。

はじめはすべての成果物に対して各メンバーが動作動作確認とフィードバックをするかたちで行っていましたが、やはり複数チームで開発が進めているので、そうなるとレビュー量がどうしても多くなってしまい、十分に触る時間が確保できていなかったという状況がありました。そのため、機能ごとに必要なメンバーと、興味のあるメンバーに絞ってフィードバック内容を厚くし量を増やして、話しやすい環境を作ることにしました。

結果として、切り替えた当初はフィードバック量が3倍に増加しました。全体でデモを見る会よりも参加者が主体的に話をしてくれるようになり、動くプロダクトに対して積極的にフィードバックするようになってくれたかなと思います。

フィードバックが増えたことにより、要求の変化や変更の必要性をできる限り早く察知できるようになり、リリース直前の変更といいますか、ちゃぶ台返しといいますか、そういうものが減少しました。

取り組みその2　「モブワークの促進」

吉野：続きまして、モブワークの促進です。モブワークを率先して行う環境を整えるために、タスクの割り振りを変更しました。今まではリソース効率を重視して1タスクに1人割り当てるかたちで着手していましたが、フロー効率を重視することで、1タスクに複数人の担当者を付けるようにしました。

フロー効率を意識することで、できるだけプロダクトのリリースまでのリードタイムを減らしていきたいというところと、属人化の解消を目的としていました。

結果は、狙いどおりといいますか、開発チーム全体でフロー効率が上昇しました。タスク完了までのリードタイムが減ってきているところが見えました。また、それまでは、タスクや機能について知見のある人が優先的にアサインされていたのですが、複数名で1タスクに取り組むことで、知見がない人もアサインをされるようになり、知識の共有が行われることで属人化の改善がどんどん進んでいきました。

あとは＋αですが、モブワークを導入することによりメンバー同士のコミュニケーションが活性化が見られました。

取り組みその3　「スクラムマスター勉強会の開催」

吉野：3つ目は勉強会の開催です。「スクラムマスター勉強会」という名前で、僕たち主催で勉強会を開催しました。アジャイル、スクラム、モブワーク、心理的安全性の大切さについてなど、チームの自己管理を促進するために必要な要素を中心に勉強会を開催しました。

なぜこういうことを行ってきたのかというと、LeSSを始めて1年半以上経っている中でけっこうチームメンバーの入れ替わりがあり、メンバーの知見にけっこうバラつきが発生してくる状況になっていたからです。バラつきが出てきた時に認識の齟齬がけっこういろいろなところで見られるようになりました。

できる限り知見を揃えて、常に同じ方向を目指せるチームを作りたいというところから、勉強会を行いました。

結果としてメンバーの認識が統一されて、チーム内のコンテキストが変化してきたなというところが見られました。当初に比べて高いコンテキストでコミュニケーションができるようになり、認識の齟齬がなくなってきて同じところを目指していける環境が徐々にできているかなと思います。

先ほどお伝えしたように、僕たちはZoomを活用しているのですが、Zoomにはレコーディング機能もあるので、行った勉強会の発表内容はできる限りレコーディングして、いつでも共有できる環境を整えられたというところも、今後継続していく上でよかったなと思っています。新しいメンバーが入ってきた時に「こういうのもあるよ」と紹介できる環境が作れました。

取り組みその4　「改善チームの立ち上げ」

吉野：最後に、改善チームの立ち上げを行いました。（スライドを示して）最初にお見せしたこちらの体制図ですが、右下のところにエンジニアだけで構成された「改善チーム」というものがあります。既存のスクラムチームや他の3チームとは別に、中長期的な技術課題に向き合うチームを立ち上げました。腰を据えてしっかりとプロジェクトの中長期課題に対して着手できるチーム作りが狙いでこのようなチームを作りました。

それまでの体制では、自動テストや新技術の調査など、中長期的な課題の優先順位がプロダクトバックログの中でけっこう低くなりがちだったんですね。本当は中長期的な課題をやりたいのに、なかなか進まないという状態でした。片手間で他のタスクと並行してやったり、手が空いた隙にちょっと進めたりという状況でした。

改善チームを立ち上げてメインストリームの開発とは別に進めていくことで、自動リグレッションテストの導入、新エンジン導入の調査、ビルド時間の削減とか、中長期的な技術課題の取り組みが進行しました。事業の長期運用の実現は、結果的にLeSSの体制を敷いているチームの継続にもつながると考えています。

大切なことは「組織全体へ目を向けること」

吉野：最後のまとめです。今回は、私たちのチームで行った4つの改善を紹介しました。スプリントレビューに対しての改善とモブワークの促進、スクラムマスターの勉強会の開催、あとは改善チームの立ち上げです。

大切なことは、組織全体へ目を向けることだと考えています。各スクラムチームにおいて、細かな改善がいろいろと進んでいます。スプリントレトロスペクティブでトライが出て、次のスプリントでどうだったかをふりかえるというかたちで小さな改善がどんどん積み重なっています。

LeSSチーム全体の課題に対しては、スクラムマスター、エンジニアリングマネージャー、ミドルマネージャーに該当するポジションの人などが組織の課題抽出と課題解決に対して率先して動くことで、チーム全体をレベルアップさせLeSSの継続につながっていけると私たちは考えています。

以上で私の発表は終わりです。より深く知りたい方は、こちらの資料も見てもらえばと思います。ご清聴いただき、ありがとうございました。

質疑応答

司会者：吉野さん、ありがとうございました。池さんの発表ともけっこう内容が被るところもありました。モブワークだったり、チームで属人化せずにいろいろなところに触れるようになるべきというところが、やはりLeSSをやっていく上でのキーになるんですかね。

吉野：そうですね。

司会者：質問にいきましょうか。「スクラムメンバーが多いと、ふりかえりの実施に時間がかかりそうだけど工夫していることってあるのかしら」。

吉野：工夫していることで言えば、けっこう自分の体験の中でなんですけど。要素や事象を全部拾っていこうとすると、やはり時間がどうしても足りなくなるケースはあるので、できる限り1つとか少ない数でちょっとずつトライしていくことが大切かなと考えています。本当であれば全部できたらいいのですが、そういう時間が全部取れるかはわからないし、それであれば少なくても1つずつ確実にやっていきたいなと考えています。

司会者：そうですね。全部拾えないのもあるし、やはり人数が多いなりにどうしてもなにかを効率化せざるを得ないところはあって、そういうところなんですかね。

スプリントレビューの分散体制もアイデアとして初めて見たんですけど、おもしろいというか、LeSSがコロナが広まる前に提唱したバザール形式のスプリントレビューで、大きな部屋にみんなに集まってもらって興味があるところに移動して聞いてね、みたいなのと限りなく近いかたちで、おもしろいなと思いました。

吉野：ありがとうございます。

司会者：だんだんと質問が出てきた。「勉強会はどれぐらいの頻度でやっていますか？」。

吉野：現在は月1で開催しています。1回あたりの時間はだいたい10分ですね。あまり長いとみんな時間を割くのもなかなか難しいかもしれませんし、集中力も極力続けられるような時間で開催しています。あとはライト目に時間を短くしてやることで、気軽に参加してもらえるような環境を作っています。

司会者：はい。次にいきたいと思います。「複数チームで開催していると、特定のフィーチャーに関わっていないものの知識がだんだんと薄くなってしまう、欠落してしまうと思うのですが、なにか工夫していることはありますか？」。このへんがやはり勉強会だったりモブワークなんですかね。

吉野：そうですね。関連していないところもモブワークとかで一緒に入って開発してみたり、眺めてみたり。あと弊社では、個々のスキルや知見など、どういう能力を持っているかというスキルを「スキルマップ」という表にしています。それで誰がどういう知見を持っているかとか、または誰がどういうところに今後アプローチをしていきたいかというところの見える化を行ったりしています。

司会者：ありがとうございます。きっとまだ他にも質問があると思うのですが、時間もありますので次にいきたいと思います。吉野さん、どうもありがとうございました。

吉野：はい、どうもありがとうございました。