こんにちは。株式会社アカツキでエンジニアリングマネージャーをしている、石毛琴恵です。私がマネージメントするチームでは、約1年半前から、スクラムのスケール手法であるLeSS（Large-Scale Scrum）を導入しています。本記事では、「これから自分の環境でLeSSを取り入れたい」「スクラムをスケールさせたい」と考えている方に向け、私のLeSS導入体験やそこから得た学び、失敗したこと、導入した結果や今後の挑戦についてお伝えしたいと思います。
なお、本記事のテーマは、「LeSSの実践」です。そのため、スクラムやLeSSの基本的な概要については、詳しく触れません。これらの基本概念に関しては、スクラムガイドやless.worksをご参照ください。
- LeSSを導入した環境について
- LeSSとはなにか？なにをどのように解決するものなのか？
- なぜLeSSを採用したのか
- LeSS導入のプロセス。チームの状況把握とメンバー理解。そして一部のメンバーとLeSS導入の目的を繰り返し話し合う
- LeSS導入のプラクティス、うまくいったことと、反省点
- 導入した結果はどうなの？効果検証など
- 小さくLeSSを導入した、その先
LeSSを導入した環境について
私がLeSSを導入したのは、モバイルゲームを開発しているプロジェクトです。モバイルゲーム開発では、組織規模が大きくなり、また、開発プロセスが複雑になりがちです。それは、単体の画面でユーザー体験が完結することが少なく、プレイヤーに飽きずにゲームを長期間楽しんでもらえるよう、定期的にインパクトの大きな機能追加や改修を行わねばならないからです。また、リリース規模が大きく、企画〜リリースの期間が長くなることが多いです。さらに、イベントなどに合わせた機能追加・改修なども行うため、大きなリリースバージョンが複数同時に動くということも、発生しやすいです。
アカツキの場合も例に漏れず、開発組織の規模が70人と大きくなっており、同時並行する大きなリリースバージョンを、プロジェクト型チーム（リリースが完了するまでの一時的なチーム）を組成して開発するという、複雑な状況（以下図参照）にありました。
私が担当するモバイルゲームプロジェクトも組織規模が大きく、2つのチームに分かれています。ひとつは、企画からリリースまでを担う新規チーム（70名規模）。もうひとつは、リリースしたものを用いてゲームを運営する運用チーム（120名規模）です。導入検討開始から1年の時間をかけ、まずは以下図のように新規チームにLeSSを導入しました。
LeSSとはなにか？なにをどのように解決するものなのか？
さて、私が導入を図ったLeSSとはどのようなものでしょうか。 LeSSは複数のチームが協調しながらひとつの製品開発を行うためのフレームワークです。「スクラムをシンプルに拡張したもの」と表現されることがありますが、この表現のとおり、スクラム同様、1つのプロダクトバックログに全員で取り組み、スプリントプランニングやデイリースクラム、スプリントレビュー、スプリントレトロスペクティブといったイベントを行います。しかし、LeSSがスクラムと異なるのは、複数の開発チームが同期し仕事をするためのイベントが増える点です。
なお、前述のless.worksでは、LeSSは2〜8つの開発チーム向けと解説されています。さらに大きな規模の開発組織向けにはLeSSHugeというフレームワークもあります。LeSSHugeでは製品の領域（エリア）を分割し、エリアごとにAPO（エリア・プロダクト・オーナー）を定めて開発を行います。こちらも基本的な考え方はスクラムと同じです。
なぜLeSSを採用したのか
LeSS以外にも、S@S（Scrum@Scale）やSAFe（Scaled Agile Framework）など、スクラムをスケーリングするためのフレームワークはさまざま存在します。数あるフレームワークの中から、私たちはLeSSを採用しましたが、それにはいくつかの理由や課題がありました。
LeSS採用前は、やることリスト（スクラムで言うところのプロダクトバックログ）の数こそ、現在と変わらず1つでしたが、チームを構成するメンバーは流動的でした。リリースバージョンごとに担当者がアサインされ、リリースを終えるとチームが解散する、プロジェクト型チームで開発を行っていたのです。また、エンジニアやQA担当者は複数バージョンを同時に取り組むこともありました。
そして、開発プロセスは企画→開発→検証→リリースというウォーターフォール形式になっていました。以下が、LeSS導入前の開発のおおまかな流れです。
こうした体制、プロセスで開発を行っている中で、チーム、そしてスケジュールの両面で以下のような課題意識がありました。
【チームに関する課題意識】
①リーダーなど、一部のメンバーの負荷が高い
- ウォーターフォールゆえ、職種（開発やQAなど）ごとにタスクを受け渡す形になっていた。そのため、職種リーダーを経由してのやりとりが多くなり、リーダーの負荷が増大していた。さらに、このことが原因で、リーダー以外のメンバーが自発性を持ちづらい状態になっていた。
②業務の属人化
- 新たなプロジェクトチームを組成する際「以前やったことがある人がやるのが早い」というリソース効率的な思考で担当者がアサインをされていたため、結果として業務内容の属人化が発生しやすい状態となっていた。
③ふりかえりの形骸化。PDCAサイクルが回らない
- ふりかえりが「KPTをすること」になっており、ふりかえりの目的が不明確になっていた。結果、ふりかえりは実施されているものの、チームやプロダクトにとって良い影響を与えるふりかえりが実施できていない。
【リリーススケジュールに関する課題意識】
①スケジュールが遅延する、遅延が終盤に発生・発覚する
- ウォーターフォール開発のため、検証フェーズで不具合が発覚し、差し戻しが多発。また、プロダクト完成後に要求とのズレや仕様漏れの指摘が発生したりすると、調整や修正が難しい状態になっていた。
②プロジェクトマネジメントの負荷が高い
- プロジェクト型チームが複数同時に動き、かつ、終盤にスケジュールが変動することもあり、プロジェクトの状況を把握するのが困難。
これらの課題は開発フローがウォーターフォールであること、またチームメンバーが流動的であることから生じたものですが、いずれもスクラムの考え方を流用することで解決できると考えていました。しかし、すでにチーム規模は比較的大きくなっている状態だったため、基本的なスクラムではなく、大規模な組織に適用できるLeSSの採用を考えたのです。当初、LeSSHugeのように領域を分けることも検討したのですが、適切な領域分けが見つからず、まずはLeSSをやってみようという結論に至りました。
LeSS導入のプロセス。チームの状況把握とメンバー理解。そして一部のメンバーとLeSS導入の目的を繰り返し話し合う
かくしてLeSS導入を決めましたが、導入の際にはもちろん、準備が必要です。私たちチームにとって、LeSS導入は「変化」です。変化を起こす前に、チーム全体の観察と、メンバーそれぞれの立場や考えを理解する必要があり、そのために私はまず以下のことを行いました。
①観察し、チームの仕事のやり方や状況を理解する
- 組織図を読み、指揮系統を理解する。
- 自分から手を挙げて、さまざまなMTGに参加させてもらい、MTGリストや業務フロー図を作成する。
- MTGは実施目的、実施頻度、参加メンバー、アジェンダをまとめる。
- MTG参加中や資料作成中に不明点があった場合は、都度教えてもらう。
②対話し、メンバーの立場や考えを理解する
- さまざまな職種の人と1on1で対話をする。
- 業務内容、責任を持っていること、好きなこと、得意なこと、組織の良いところや好きなところ、困っていることや課題に思っていることを聞く。
- 困っていることや課題については、気になるところを深堀りする。
- さまざまな職種の人と1on1で対話をする。
1ヶ月ほど上記のようなことを行い、結果、理解できたのが、先に挙げた組織課題でした。新規チームにLeSSを導入したいと考えました。その後はチームメンバーに導入する目的を理解してもらうための活動を並行して行いました。
③新規チーム全員参加の勉強会を開催
- LeSS導入の目的を2部制のLTとして、新規チーム全員に向けて実施。第1部では大切にしたい価値観（HRTや心理的安全、自己管理など）、第2部では効率のいい仕事の仕方（計画の立て方や、フロー効率など）、事例発表、スクラムの説明の全16回を行う。
④1つの職種チームで小さくお試し導入
- 前述の課題意識を強く感じていて「いますぐ何かを試してみたい」という職種チームに、先行お試し導入実施。
⑤各職種のリーダーを中心に、深い対話
- 業務や各メンバーを深く理解しているリーダーと繰り返し対話を行い、LeSS導入に付随して発生する変更点の共通認識を形成し、不安の解消（プロセスを変えることにより発生しそうな課題と解決案）に努める。
お試し導入は当初予定していなかったことでしたが、目的をあらためて設定し、計画→実行→ふりかえりというサイクルを実施しました。プロダクト開発はもとより、仕事の取り組み方を含めて、改善していく流れを取り入れたところ「自チームだけで解決できることは少ない。クロスファンクショナルなチームを形成したほうがよさそうだ」という意見が得られたのです。こうしたお試し導入チームの意見は、その後、チーム全体にLeSSを導入するうえで大きな後押しになりました。
LeSS導入のプラクティス、うまくいったことと、反省点
ここまでが、LeSS導入にあたって私が実施したプロセスです。これらプロセスを端的にまとめるならば、「組織の観察と導入目的を伝える」。そして、「小さく試す」ことです。こうした導入プロセスは、非常に一般的なものではありますが、同時に多くのチームで有効だと考えます。
観察は、自組織にどのようにスクラムを適応させるかを考えるためにも、チームやメンバーを理解するためにも、とても重要です。また、目的を伝えるステップも非常に重要です。仮に目的がきちんと伝わっていない場合、LeSSがうまく機能しなければ「元のやり方に戻すべきではないか」という議論が生まれてしまうかもしれません。また、せっかく新たに取り入れたフレームワークが形骸化し、思わしくない変化をしてしまうことも懸念されます。
とはいえ、大きな組織の場合、最初からチームメンバー全員の目的理解や共感を得るのは困難です。また、導入準備段階において、メンバー全員と深く対話を行うのも難しいでしょう。そのため、私の場合は「各職種のリーダーが導入の目的に共感してくれていて、その他のメンバーはある程度理解している」という状況を作ることを目指しました。これは、そもそもLeSSが導入ができるよう、仲間、つまり共感者を増やすという目的もありますが、それ以上に導入直後に発生が予測されるネガティブな感情や問題が起きたときに、各職域で影響力を持つ自分以外の誰かが、対話や説明をできる状態を作る必要があったからです。
手厚く説明の機会を設けたことで、各職種のリーダーに「LeSSの意味や効果」を、ある程度伝えるという目標は達成することができたと思います。その結果、導入直後に発生した小さな不安や、従来のやり方とは異なるためにうまくいかないことに対し、リーダーの方々が他のメンバーと対話をしてくれ、私にアラートを上げてくれたりしました。
また、小さな1チームでまずは実践してみる、というのもよくある手段ですが、有効です。小さな「スクラムチーム」をつくりスケールさせていくことがさらに良い手段ですが、たとえこうした手段をとれなくとも、小さく試すことと、試したチームメイトが効果を伝えてくれることは、外からの情報を伝えるよりも、共感の効果が高まります。
以上が、私が取り組んだLeSS導入において「うまくいった」方法です。しかし、すべてがうまくいったわけではもちろんなく、反省点も多々あります。ここからは、私のLeSS導入プロセスにおける反省点もプラクティスとしてお伝えしたいと思います。
スクラムやLeSSなど「分からない言葉」を伝えるタイミングは熟慮せよ。導入の反省点
1つめは、「スクラム」や「LeSS」といった独特な単語を伝えるタイミングが早すぎたことです。スクラム導入の際には「スクラム」という単語をなるべく使わない、とはよく聞くプラクティスです。私の場合もこれにならい、チームの勉強会においてはまずはスクラムの根本にある思考を伝えようと心がけ、「スクラム」「LeSS」という単語を伝えるのは後半にしたのです。しかし、それでも時期尚早でした。
実践の前に「スクラム」「LeSS」という単語を出してしまったことで、いざLeSSを導入してみると「スクラムやLeSSをまだよく理解できていない。いま自分たちが取り組んでいるのが、正しいLeSSか分からない」という発言が散見されたのです。これはおそらく、聞き慣れない単語に思考を引っ張られてしまい、LeSSの効果を体感する以上に「正しいLeSS」であるかどうかに意識が向いてしまったのだと思われます。
幸い、私以外のメンバーの協力のおかげで「スクラムやLeSSをもっと知りたい」「より良い仕事をするにはどうするべきか」というポジティブな方向に思考が早めにシフトしてくれましたが、いま思えば、実践し、チームメンバー自身が「以前よりいい感じだな」と実感したタイミングで「私たちが取り組んでいるのはLeSSだ」と伝えるべきだったと感じています。
スクラムがうまく機能している組織にもかかわらず「スクラムという言葉をずっと伝えない」という事例を聞くこともあります。たしかに、「スクラム」や「LeSS」という単語を伝えず、プロセスを変更しても大きな混乱は起きないのではないかと想像します。しかし、私は、スクラムやLeSSというフレームワークや概念を知っているからこそ、プロダクトやチームの立ちふるまいを改善していく機運や機会ができると考えたのです。 しかし、導入期の混乱はもちろん抑えるべきです。そのためには、「スクラム」「LeSS」という単語を伝えるタイミングの見極めが重要だと実感した出来事でした。
2つめは、私がLeSSを導入しようと活動を始めたのが、入社と同時だったという点です。時間をかけチームメンバーとの信頼関係を築く前に、大きなアクションに出てしまったのです。こうしたタイミングでの行動は、行動を起こす当事者（本稿の場合は私）にとって心理的なハードルが高く、周りのメンバーにとっても混乱を招きかねないものでした。私の場合は、周りのメンバーの理解に恵まれたために大きな問題にはなりませんでしたが、ある程度の信頼関係があることを前提に行動をしたほうがスムーズに進むと思われます。
3つめは、やりたいこと（LeSSの導入）の前に、チームの素敵なところ、すでにできていることを、きちんと伝えられなかったことです。これは周りのメンバーから「できていることもたくさんある。それをちゃんと知っていると伝えないと、変化のための行動がマイナスに捉えられてしまう」と事前に伝えてもらえたので、自分の行動を改められましたが、とても大事なことです。どのチームにも課題はあるはずですが、同じようにどのチームにも良いところや、大切にしたいことがあります。チームのポジティブな面も共感しつつ、さらに改善していきたいという気持ちを伝えることが、仲間と一緒にチームを作っていくことであり、継続的に良いチームであり続けるために必要です。
こうした反省点が多々あることからお分かりになるように、そもそも大規模組織でのチーム開発は難しく、また、たくさん人がいれば成果が出るとも限りません。これからスクラムのスケールを考える方は「なぜスクラムをスケールさせたいのか」を最初に考えてから行うと良いと考えています。
導入した結果はどうなの？効果検証など
現在は、LeSSを導入して1年半ほどが経過しました。私は導入初期のみスクラムマスターのロールを担いましたが、現在は別のメンバー3名がスクラムマスターをしています。現在もチームは成長過程にありますが、導入して半年ほどで、以下のような成果がありました。
①職種を超えたコミュニケーションと協力
- プロジェクト型チームの頃と比較して、固定化されたチームでのコミュニケーションが増えたため、心理的安全が向上。また、クロスファンクショナルなチームになったことで、職種を超えた情報共有や協力が多く見られるように。エンジニアの設計レビューにQAチームが参加したり、QAの検証項目作成にエンジニアも参加したりということが、日常的になった。
②属人化の低減
- スキルマップ作成やペア / モブプログラミング（ワーク）といったプラクティスの実践により、属人化が徐々に減少。また、チームメンバーの「属人化を減らしていきたい」という意識が高まり、個人が暗黙的に抱えていたタスクも分散されるように。
③メンバーの自発的な行動の増加
- スクラム理論の実践により、メンバーが主体となる行動が増加。その行動が元となって定着したことも。例えば「HackDay」と呼ばれる、緊急ではないが長期運営のために重要な開発タスクを集中して片付ける2日間というイベントが半年に1回、開催されるように。
こうした成果は導入前から期待していた、目に見えやすいものですが、本当の成果はこの先、事業貢献や顧客満足を指標とする必要があります。それは、LeSSを実践する目的が、ひとつのスクラムを組織全体で動かし、優先順位が高いことから取り組めるようにするためであり、LeSSを適切に運用できれば、達成できるはずだからです。
小さくLeSSを導入した、その先
冒頭にお伝えしたとおり、私が所属する組織は、大きく新規チーム、運用チームに分かれています。LeSS導入に付随してさまざまな検証を行っていくなかで、チームの分断という課題が発見されています。新規チームがリリースをし、運用チームが利用するというサイクルでは、新規チームが「リリースしっぱなし」になってしまっていたり、運用チームからは「想定していたものと違うものができてしまって使いづらい」といった事態が発生しやすくなっていたのです。また、運用チームが実際に利用し、機能を改善したいと思っても、異なるサイクルで動いている新規チームのスケジュールがすでに埋まっている、ということも、しばしば発生します。
こうしたチーム分断による課題を解決するべく、新規 / 運用チームという垣根を取り払い、プロジェクト全体でスクラムに臨むというのが、現在取り組んでいる課題です。以下の図のように、LeSSの適用範囲を拡大しようと試みているのです。
LeSS導入当時は、企画（PO）、デザイナー、エンジニア、QAという、リリースに必要なすべての職種を巻き込んだ体制が組めていると考えていましたが、事業運営においてはさらにチームを拡大し、必要な職種をすべて巻き込まねばならなかったのです。
本稿のタイトルにある「小さく始める」に違和感を持った方もいるかもしれません。私自身、70人の組織にLeSSを導入しようと考えた時も、そしてつい最近まで「小さく」始めたと認識していませんでした。しかし、私たちのLeSSはさらなる拡大が必要であり、その意味で、ここでご紹介したLeSS導入の取り組みは「小さく始めた」ものだったのです。
1チームで実践し、もう少し大きな新規チームで実践し、そしてこの先は事業全体でLeSSを実践していきます。少しずつ周りを巻き込みながら、本当の意味の成果である事業貢献を達成を目指していきたいと考えています。
編集：はてな編集部
