カイポケリニューアルプロジェクトにおけるLeSS（大規模スクラム）導入

スクラムマスターの貝瀬です。2024年6月から業務委託として、介護/障害福祉事業者向け経営支援サービス「カイポケ」に関わる組織やプロセスの改善を支援しています。

支援先の部門では、私が参画する以前よりカイポケリニューアルプロジェクトにスクラムをベースとした開発プロセスを導入していましたが、2024年8月にLeSS（Large Scale Scrum：大規模スクラム）を導入しました。今回はLeSSを導入することになった経緯と、導入の最初のステップを紹介したいと思います。

はじめに

本題に入る前に、私の略歴と、エス・エム・エスを支援することになったきっかけを紹介します。

私の経歴

現職の「合同会社makigai（マキガイ）」を創業する前は、IT系の事業会社を中心に活動していました。キャリア3社目となる株式会社ディー・エヌ・エー時代に、開発部門におけるマネジメント上の課題を解決するために導入したのが私とスクラムとの出会いです。

以降、マネージャー・スクラムマスター・プロダクトオーナーなどの様々な役割で、既存事業・新規事業・オフショア開発・営業部門・人事領域などの様々なプロジェクト・組織にスクラムを導入・活用して、10年以上が経ちました。大小さまざまな経験（成功も失敗も）を含めると、3桁を超える程度のスクラム活用経験はあるかと思います。

そうして積んだ経験を体系的に整理し様々な企業にも共有してみたかったのと、スクラムの師匠であり友人でもある江端さんと一緒に働いてみたくて、プロダクト開発のコーチ集団Odd-e（オッドイー）の日本法人であるOdd-e Japan（オッドイー・ジャパン）にも4年ほど在籍しました。

カイポケのプロダクト開発におけるLeSSの導入事例は、私の経験の中でも広く知っていただく価値があると感じ、こうしてブログを書くことになりました。

エス・エム・エスとの接点

ディー・エヌ・エー時代の同僚である田辺さん（@sunaot）の紹介で、2023年秋ごろプロダクトマネージャー向けの研修を開催したことが最初のエス・エム・エスとの接点でした。その後しばらくして、再び声をかけていただき、カイポケの開発関係者に向けて、スクラムの基礎から応用まで、実践できるようにしてもらえないかという相談を受けました。通常私は、スクラムマスターの方を育成する立場（いわゆるアジャイルコーチ）で参画することが多いのですが、カイポケには専任のスクラムマスターがいないということだったので、私がその役を引き受けることになり、現在に至ります。

LeSS導入の背景

LeSSを導入する前の組織構造は、1つのプロダクトに対して、複数のプロダクトオーナー、複数のプロダクトバックログ、複数のチームという構造でした。開発に携わる人数としては約50人程度だったかと思います。当時は、2チーム以上の協力が必要な開発を行う際に、以下のような問題が発生していました。

他チームに依存するPBI（プロダクトバックログアイテム）がある場合、着手したスプリント中に完成しない。
過去に完成させたはずのPBIに対して、突然他チームからの問い合わせや修正依頼が発生する。

私がスクラムマスターとして参画してしばらくの間は、問題の発生頻度が少なかったため、プロダクトオーナーやチーム、マネージャーやステークホルダーたちもさほど困っていないようでしたが、これは上記で述べた組織構造に起因する問題の一つです。いつか（おそらく半年以内に）必ず問題の優先順位が上がると予想していたので、チームレベルの改善を支援しながら、LeSS導入の準備を進めることにしました。

LeSS導入の戦略

LeSSはカイポケのように数十名規模の組織で1つのプロダクトを開発する際に有効なフレームワークです。LeSSの大雑把な構造としては、1つのプロダクトに対して、1人のプロダクトオーナー、1つのプロダクトバックログ、複数のチームが紐付きます。

LeSSは守破離の学習モデルに沿って考えられており、「守（基礎となる部分）」は、LeSSの原理・原則と、ルールとして定義されています。カイポケへのLeSS導入にあたって最も重要視したのは以下のルールです。

単一のプロダクトグループへの導入では、最初から教科書的なLeSSの体制を作るようにします。これはLeSSの導入にとって不可欠です。
さらに大きなプロダクトグループを超えて大規模な組織に導入する場合は、現地現物を用いて、実験と改善が当たり前であるような組織をつくり、段階的にLeSSを導入します。

（出典：Craig Larman・Bas Vodde（著）、榎本明仁（監訳）、荒瀬中人・木村卓央・高江洲睦・水野正隆・守田憲司（訳）『大規模スクラム Large-Scale Scrum(LeSS)』、丸善出版、2019年、52頁）

上記を踏まえ、LeSS導入までの間に意識していたことは以下の3つです。

チームレベルのスクラム理解度・実践力をあげること
複数チームが関わる問題を観察し原因に対して仮説を立てること
スプリントレトロスペクティブ等におけるチーム・組織に対する改善アクションが、部分最適になりすぎないよう選択肢の幅を広げること

取り組みの具体例についてはこの後紹介します。

勉強会を活用したスクラム理解度・実践力向上の土台作り

スクラムのルールとLeSSのルールと自分たちのやり方との違いを知り、改善につながるネクストアクションを考えていただくことを目的に勉強会を開催しました。

過去にプロダクトマネージャー向けの研修を実施したことは冒頭で述べたとおりですが、熱心に参加されている方が多くいらっしゃったことを鮮明に覚えています。実際にスクラムマスターとして参画してみると、当時学んだことを現場で実践されている方が多いことにも衝撃を受けました。こうした経緯から、スクラムやLeSSに関する学習の機会を設ければ、自主的に現場の業務に活かしていただけるのではないかという期待があったためです。

スクラム勉強会はワークショップ中心の、参加者自身に考えていただくスタイルで行いましたが、当初の狙い以上に盛況となりました。これは、人から与えてもらうのではなく自分自身で学ぶこと・改善することが習慣化していることを表す一例だと捉えています。さらには、プロダクト開発に直接関わる方々だけでなく、マネージャーやステークホルダーも積極的に参加されていたので、全体を巻き込んだ改善活動を促進する上での土台がしっかりしている組織であると感じました。私が主催する勉強会は現在も継続していますが、それぞれのチームでも、スクラムやLeSSに関する勉強会を自主的に開催しています。

参考までに、スクラム勉強会の参加者からいただいたフィードバックの一部を紹介します。

よかった。自分のわからないこと、解決できないことが、適切に難しいことだという現在地の確認になった
QAで、組織やプロダクトの状況視点ではなく「スクラム」という視点で切り離して会話ができたことが自分にとってはよいことでした。社内で話すとどうしても「現状を鑑みて」になりやすいので、まずはフラットにスクラムを行うために必要な情報が整理でき大変勉強になりました。
スクラムマスター不在の状況で今までやってきたため、そもそもスクラムマスターの役割と必要性があまり理解されていないように感じています（自分も含めて）。グループワークの中で、4グループ中2グループが、スクラムマスターについて付箋を出していることからも、スクラムマスターの役割と必要性について取り扱ってほしいです。
LeSS 勉強しようと思って手つかずだったので概要がつかめて良かったです！

LeSS導入準備のための現地現物

私が参画する以前はスクラムマスター不在でしたが、チームの中でファシリテーターを決め、スプリントプランニングやスプリントレトロスペクティブなどのスクラムイベントを実施していました。そこにオブザーバーとして参加しながら、LeSSの導入によって改善が見込まれる事象を観察していました。同様に、プロダクトバックログやスプリントバックログをはじめとするスクラムの作成物、作成物に付随するアウトプット、スクラム以外の定例会議なども観察対象です。

一方、勉強会の効果もあってかチームから自主的にフィードバックを求められるようになってきました。例えば「他チームに依存するPBIが着手したスプリント中に完成しない」といった類の問題が出てきた場合にはLeSS導入時の妨げとなるような部分最適の改善にならないように、視野や選択肢を広げるためのフィードバックやオプション提示などをしていました。問題の真因が組織構造などにありそうな場合は、考察をまとめながら、フィードバックや提案の機会を待つようにしました。

冒頭でも触れたように、その機会が訪れるのは半年くらい先になるだろうと踏んでいたのですが、驚くことに私が参画してから2ヶ月後にはLeSS導入が決定、3ヶ月後にLeSSが開始されるという意思決定の早さでした。

多くのチーム、多くの方々が課題に感じていたことへのソリューションがLeSSだったというだけの話ですが、組織全体にスクラムの5つの価値基準が浸透していることが成功の秘訣だったと思います。

スクラムを成功させるためには、5つの価値基準をより高度に実践することが求められる。

確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage）

チームは継続的な改善とお互いのサポートを確約する。チームは最善の成果を上げるために、スプリントでの作業に集中する。チーム、プロダクトオーナー、そしてステークホルダーは、作業と課題を公開する。チームのメンバーはお互いを能力があり自立した人間として尊敬し、一緒に働く人たちからも尊敬される。チームメンバーは、正しいことを実行し、困難な問題に取り組む勇気を持つ。

これらの価値基準は、作業、⾏動、そして振る舞いの⽅向性を⽰している。下される決定、実⾏される手段、スクラムの使⽤⽅法は、これらの価値基準を強化するものであり、減少させたり損なったりするものであってはならない。これらの価値基準がチームや⼀緒に働く⼈たちによって体現されると、スクラムの経験主義を支える三本柱「透明性」「検査」「適応」が実際に機能し、信頼が築かれる。

（出典：「スクラムガイド(LeSS版)」 https://less.works/jp/less/scrum-guide 、参照2024年11月14日）