Large-Scale Scrum

はじめに

少し時間が経ってしまったが、2018/5/7 ~ 2018/5/9 で、認定 LeSS 実践者研修 に参加してきたので、簡単に内容をまとめておこうと思う。LeSS における細かいお作法は、全て 公式ページ の方にまとまっているので、本ブログでは研修を通じて特に興味深かった点に絞って書いてみる。

なお、本ブログの内容は Scrum の基礎を知っている人向けのものとなっている。Scrum 関連の用語は、日本語表記にしてしまうとどうもしっくりこない気がしたので、ブログ全体を通してあえて英語のままの表記とした。若干、ルー大柴間が否めない点については目をつぶってもらえればと思う。

Scrum と LeSS の関係

LeSS (Large-Scale Scrum) とはその名の通り、本来 7 ± 2 名程度のチームで行うのが望ましいとされている Scrum を、より大きな組織に適応するためのフレームワークの一つである。

同様に、Scrum 拡張の中には、SAFe や Nexus といったものもあるようだが、実際にどれを使用するかについては好みによっても分かれそうなところ。というのも、Scrum が「透明性」、「検証」、「適応」の実現に必要最低限のルールを定義しているのに対して、その拡張である LeSS, SAFe や Nexus は、どちらかというと Scrum の実践のためのプラクティス集的な意味合いが強く、適用する組織によってもベストな手法は変わってくると思われる。

今回は、私自身が LeSS の研修に参加してきたということもあり、LeSS を中心に本記事を書いてはいるが、私は SAFe と Nexus をきちんと勉強してはいないため、それらとの適正な比較などが行えていない点については予めご了承いただきたい。

LeSS の成り立ち

前章でも述べたように LeSS は Scrum をより大きな組織に適応するためのフレームワークである。つまり、LeSS はあくまで Scrum の一つの姿 に過ぎず、Scrum 自体に手を加えた別の何かでは無い。

本研修の講師で、LeSS の考案者の一人でもある Bas Vodde は、「私は、クライアントの組織に意図的に LeSS を導入したことは一度も無い。Scrum を導入していたら、自然と LeSS になっているケースがほとんどだった。」 とも述べていた。

具体的には、以下の図を見てもらえるとイメージがし易いかと思う。

LeSS の成り立ち (※)¹

様々な組織に対して Scrum を適応するという Experiments (実験) を繰り返す中で、得られる知見をまとめたものが LeSS である。それらの知見についても、その抽象度に応じて Guides (ガイド)、Frameworks (フレームワーク) と段階を設け、それらの中心に位置する最も普遍的なものを Principles (原理・原則) として括りだしたようだ。

LeSS の概要

前章でも述べたように、LeSS は Scrum の一つの姿に過ぎない。ただ、LeSS は Scrum をより大きな組織に適用するために、いくつかの LeSS ならではの特徴を持っている。以下は LeSS の全体像を示した図となっており、ぱっと見では Scrum とほぼ同じように見えるかと思うが、大規模な組織に対応するためのいくつかの工夫が施されている。

LeSS の全体像 (※)

LeSS という考え方の一つのポイントとして、LeSS は複数の Scrum の集合ではなく、それ自体で一つの大きな Scrum である。具体的には、以下のような仕組みによってこのポイントを実現している。

• LeSS における Team という用語は、Scrum 用語における「Scrum Team」のことではなく「Development Team」のことを示す
  • 一つの Team には Product Owner (PO) や Scrum Master (SM) は含まれない
• 一つのプロダクトに対して、組織が大きくなり Team が増えた場合にも、必ず PO は一人のみ
  • SM は、一人で 複数 Team を見ることもある
• 一つのプロダクトに対して、Product Backlog も一つのみ
• Product Backlog の粒度は、プロダクトの全体像が見えるように通常の Scrum よりも大きめに設定する
  • e.g. LeSS: UI の変更 ↔ Scrum: ボタン A の変更
• 一つの Sprint の中で、Sprint Planning は二段階に分けて行い、一度目の Sprint Planning（上記図中の Sprint Planning 1）には、必ず全ての Team（もしくはその代表者）が参加する
• Product Backlog Refinement には、全ての Team が参加する
• Sprint Review には、全ての Team が参加する
• Sprint Retrospective についても、Team 毎に行うもの以外に、Overall Sprint Retrospective と呼ばれる、PO, 全ての SM, 全ての Team の代表者が集まるものが存在する

LeSS がこのような形態を取っている理由は、LeSS においてプロダクトがどのように定義されるかに深く関わっている。こちらについては、次章の プロダクトの定義 で説明する。

プロダクトの定義

LeSS における「プロダクト」の定義とは何か？ Less では一つのプロダクトを可能な限り 大きく 定義するのが良いとされている。

具体例を出してみよう。例えば、ある Web サービス（サービス X）を開発していて、そのサービス X を展開するプラットフォームが Web ブラウザ、iOS, Android といったように複数存在するとする。この場合にプロダクトを

• サービス X (Web)
• サービス X (iOS)
• サービス X (Android)

のようにプラットフォーム別に定義するのではなく、まとめて一つの「サービス X」として定義することを、この場ではプロダクトをより「大きく定義する」と呼んでいる。

プロダクトを大きく定義する理由として、以下のような点が挙げられている。

1. プロダクト全体（上記例であれば、Service X 全体）での、要件の順位付けが容易になる
2. 複数のプロダクト間で発生する重複作業を、極力減らすことができる
3. 小さなコンポーネント（部品）を減らす
4. 顧客視点で物事を考えやすくなる
5. プロダクトに関わる組織構成がシンプルになる

これらに共通して言えるのは、プロダクトを大きく定義することにより、プロダクトに関わる全ての人たちが、共通の「顧客価値」を認識して動きやすくなるという点である。

ビジネス書などで多く引用されている「3 人のレンガ職人」の寓話がある。²

旅人がレンガを積んでいる職人に「あなたは何をしているのですか」と尋ねると、職人は、険しい顔で「レンガを積んでいる」と答えた。別の職人にも尋ねたら、平気な顔で「壁を作っている」と答えた。さらに別の職人に尋ねたところ、喜びに満ちた顔で「大聖堂を作っている」と答えた。

大事なのは、あくまで自身が「大聖堂を作っている」ことを認識できているかどうかなのだ。

科学的管理法（テイラー主義）

科学的管理法 とは、20 世紀初頭に フレデリック・テイラー によって提唱された、プロダクトの生産性向上のための手法であり、以下のような特徴を持つ。

• マネジメント層と作業者に分離
• 作業は職能別に細分化して最適化
• 個々の作業者のスキルの違いは考慮しない、一律な作業時間による工数見積もり

これらの特徴を見てハッとする方もいるかもしれないが、工数を人月 (man-month) で管理し、PMO (Project Management Office) がプロジェクトを取り仕切るような開発スタイルと、どこか通ずるものがあるだろう。

科学的管理法は、基本的に作業者をただのリソースと見なす「リソース指向」に基づいている。リソース指向では、作業者はあくまでプロダクト開発の過程で消費される「リソース」でしかないため、常に計画に忠実に、一定のスループットで作業をこなすことを求められる。例えば、10km/L の燃費の自動車に乗った場合に、ガソリンは常に 10km/L のペースで消費されてほしいのと同じような感覚である。

科学的管理法が流行り始めた 20 世紀初頭では、高等教育を受けることができたのはごく一部の人たちであった。そういった時代の中では、一部の優秀な人材をマネジメント層に据えてその他の作業者を「リソース指向」で管理するこの手法は、一定の効果を上げていたようだ。ただ、その頃からすでに一世紀近くもの時間が経ち、日本に限って見ても国全体の教育水準は当時と比べても遥かに上がっている。科学的管理法を裏付けていた時代背景そのものが変わってきている今日、果たしていつまでも科学的管理法が通用し続けるのか。

LeSS はこの問題に着目し、前述した「リソース指向」とは対極的な位置に存在する「人間指向」に基づいた考え方を取っている。人間指向では、（当前ではあるが）作業者を「人間」と見なし、作業者が自主的に「学習」することを前提とする。つまり、作業者のスループットは作業者自身の「学習」によって改善されていくことが期待されている。

もちろん今の世の中でも、科学的管理法もしくはリソース指向が有用なケースもいくらかはあるだろう。ただ、昨今ではプロダクトへの要件は複雑化し、スピーディに変化していくことを考えると、それらの全てをマネジメント層が把握して、科学的管理法によってコントロールしていくことの難しさは容易に想像できるかと思う。

コンポーネントチーム vs フィーチャーチーム

Scrum では、Team のメンバーはクロスファンクショナル（機能横断）に構成されるのが一般的である。

LeSS では複数の Team が力を合わせて一つのプロダクトを開発するわけだが、その場合にも各 Team をプロダクトのコンポーネント（部品）によって分けることはせず、プロダクトのフィーチャー（機能）によって分けるのが望ましいと言われている。

なぜ、フィーチャーチームなのか。こちらについては、一般的な Scrum Team がクロスファンクショナルに構成される理由と大きく違いは無い。Team が顧客の価値（つまりフィーチャー）に直結しており、常に顧客目線でソリューションを考え易いことや、Team 間におけるタスクの依存関係を減らすことなど、様々なメリットが挙げられる。

コンポーネントチーム vs フィーチャーチーム (※)

ただし、上記図のようにフィーチャーチームの方では Team 間の作業の依存関係が減ってシンプルになっている一方で、複数の Team が同一のコンポーネントに対して変更を加える可能性が出てくるため、コンポーネント変更管理の難易度が上がっているのが見て取れるかと思う。実際のところ、この問題を人間の手作業のみで解決することは非常に難しいため、CI/CD のためのツールを導入することで、ソフトウェア的に解決することが求められる。

Definition of Done

通常の Scrum 同様、LeSS においても Undone（Definition of Done に含まれてはいるが、現時点では必ず毎 Sprint では実施できていないもの）が積み上がることは後の技術的負債となる恐れがあるため、適宜減らして行くことが求められる。

Undone がもたらすリスクと遅延 (※)

Undone に含まれやすい作業としては、セキュリティテストやパフォーマンステストなどが挙げられるが、こういった Undone を実際にどのように消化していくべきか。

例えば、Scrum では（もちろん LeSS でも）推奨されないものではあるが、「Release Sprint」と呼ばれる、プロダクトのリリース準備を行うためだけの Sprint を設け、そちらの Sprint を Undone の消化に当てる方法は存在する。そもそも Scrum では、全ての Sprint の成果物が Potentially Shippable Product Increment でなければならないため、「Release Sprint」の考え方自体が矛盾をはらんでいる訳ではあるが、実際のところ Scrum や LeSS を始めたばかりの Team だとこういったことはめずらしくはないようだ。

ただ、LeSS で扱う規模のプロダクト開発ともなると、Undone の消化のみを専門に行う部署、通称「Undone 担当部」なる部署が作られてしまうこともあるようだ。「Undone 担当部」という名前を聞いてもあまりピンと来ない方も多いかもしれないが、いわゆる一般的なソフトウェア企業に存在する「QA 部」、「リリース管理部」などが、「Undone 担当部」に該当するケースが多いようだ。

Undone の消化を Team 自身ではなく「Undone 担当部」に任せてしまうことは、Team のプロダクトに対する責任意識を損なうことに繋がるため、「Release Sprint」よりもむしろ避けるべきもの として研修の中では扱われていた。（なお、ここで述べているのはあくまで LeSS という文脈における「Undone 担当部」の話であり、組織や開発手法によっては「QA 部」や「リリース管理部」が必要となるケースもあるだろう。）

繰り返しになるが、あくまで Team は例外無く（セキュリティ、QA なども含めて）クロスファンクショナルであることが理想なようだ。

LeSS 実践のための Tips

講義の中で、LeSS 実践のための Tips がいくつか紹介されていたので、ここにまとめておく。

LeSS の 導入

本記事では説明を省いたが、LeSS の中にも 2 ~ 8 つの Team で構成される Basic LeSS と、8 つよりも多くの Team で構成される LeSS Huge が存在する。この 2 つの中で、Basic Less の導入については、1 つの Team を徐々に増やしていくやり方ではなく、始めから Basic LeSS の構成（2 ~ 8 Team）で一斉に導入するのがが望ましいようだ。

また、上記理由からも 2 ~ 8 Team のコンポーネントチーム同時にフィーチャーチームに組み替えていく必要があるため、LeSS の導入には組織構造の変更を伴うケースが多い。ただ、そういった組織改革には必ずと言っていいほど反対勢力が存在する。その際に重要となるのが、少なくとも以下の図におけるキーパーソンには予め LeSS 導入の価値を理解しておいてもらい、協力を得られる関係を築いておくことだ。

コンポーネントチームの組織構造

このキーパーソンは、コンポーネントチーム型の組織構造において、ビジネス層とエンジニア層の狭間に位置する人物であり、エンジニア層に対する人事権を有している場合が多い。また、人事権を有していれば誰でも良いわけではなく、エンジニアリングに関する知識が全く無い層（例えば CEO など）だと、LeSS 導入後にエンジニア層の人々が「LeSS を やらされて いる」という感覚を持ってしまうようだ。

なお、この辺は言うまでも無いことかもしれないが、組織に　LeSS を導入する場合には、既存のコンポーネントチームにおいてアプリの開発を行っているチーム（上記図における App Team）の近辺から着手するのが良いらしい。具体的な理由については研修の中では述べられてはいなかったが、おそらくコンポーネントの性質上クロスファンクショナルな Team が編成しやすいことが要因だろう。

フィーチャーチーム適応マップ

「コンポーネントチームよりもフィーチャーチーム」、「Undone は少ない方が良い」といった理想はわかるが、実際これらを完璧に実践している Team というのもそこまで多くは無いだろう。

現時点で Team がこれらをどれだけ実践できているか、また理想の状態に向けて何をしていけばよいかを議論するためのツールとして、研修の中ではフィーチャーチーム適応マップというものが紹介されていた。

フィーチャーチーム適応マップ (※)

フィーチャーチーム適応マップでは、横軸に Definition of Done（現時点で実現できているものから順に、実現できていないものまでを列挙していく）、縦軸にチームが扱うことのできる技術スコープを取り、現時点で Team がグラフ上のどこに位置しているかをプロットする。次に、Team の目指す少し先の未来の状態をグラフ上に同様にプロットし、先にプロットした現時点の状態から未来の状態へ以降する上で、「何が阻害要因となっているか」、「具体的にどのようなアクションを取るべきか」を議論する。

大人数で実施する Ceremony

LeSS の概要 の章でも簡単に触れたように、Product Backlog Refinement や Sprint Review などの Ceremony には、基本的に全ての Team の全てのメンバーが参加する。ただ、2 ~ 8 Team もの大勢のメンバーが一挙に集結する Ceremony の実施の仕方にはいくつかのコツがある。

Product Backlog Refinement

Product Backlog Refinement については、以下の図のように複数 Team のメンバーでグループを作成し、グループ単位で Product Backlog Item (PBI) の精査や、必要に応じた分割を行う。

Product Backlog Refinement

Sprint Review

Sprint Review については、各 Team の代表者が成果物のデモを行い、それ以外のメンバーは他の Team の成果物を見て回る。（もちろん PO や Stakeholder も、同様に見て回る。）

バザー形式の Sprint Review

トラベラー

LeSS のように、複数の Team で開発をしていると、どうしてもそれぞれの Team が有しているスキルに差が出てくる場合がある。そういったスキルの差を埋めるために、LeSS では他の Team が必要とするスキルを持つ開発者を Team 間で移動させる「トラベラー（Team 間を旅する人の意）」という仕組みを設けている。

ただ、基本的に Scrum においては、Team からメンバーが減ること以上に、Team にメンバーが加わることによる生産性の低下を気にしなければならない。「トラベラー」の仕組みでは、受け入れ先の Team が「トラベラー」の加入を望んでいる場合に限り、 メンバーの Team 間での移動を許可している。

ソースコード管理

ソースコード管理に Git を使う辺りは一般的だと思われるが、以下のような使い方を推奨していた。

• ブランチを切りすぎない
• プルリクエストは使用しない

Git の思想からはかなり離れているような気もするが、ブランチを切りすぎて開発者が自身の（もしくは自身の所属する Team の）開発している部分しか見なくなってしまうことを防ぐ目的らしい。さらに言えば、コミットに問題があった際には、即座に誰もが気づけるように、開発者が皆 master ブランチに直接コミットをプッシュするのが望ましいという話だった。

正直なところ、現実世界においてこういったの運用が成り立つイメージは全く沸かなかったのだが（他の研修参加者も同様の感想を抱いていたようだ）、モブプログラミングなどを導入すると、わざわざプルリクエストを送るのが面倒になって形骸化してくるよね、という意見は研修参加者の間でも少なからず出ていた。

リモートワーク

ここ最近では、様々な企業でリモートワークの導入が進められているという話はよく耳にするが、Scrum あるいは LeSS という文脈に限った場合には、リモートワークを手放しで推奨することはできないようだ。

例えば、通常の Scrum の場合だと、以下のように Team は同一拠点で作業を行うことが推奨されている。

Scrum におけるリモートワークの可否

また、LeSS にまで話を広げると、Basic LeSS を構成する 2 ~ 8 Team についても、極力同一拠点で作業を行うことが推奨されている。

LeSS におけるリモートワークの可否

これらの理由としては、Team のメンバーが物理的に同一の空間で作業を行うことで享受できるメリットが比較的多いことが挙げられる。 例えば、Sprint Planning などの Ceremony タイミングで Team のメンバーがリモートワークをしていて、それぞれが自身の PC を見ながら議論するのと、メンバーが一箇所に集まってホワイトボード上に作成した Sprint Backlog を見ながら（メンバー全員が、「物理的に」同じ方向を見て）議論するのとでは、だいぶ勝手が違うだろう。 また、Ceremony 以外でも、些細なことを Team のメンバーに聞きたいのだが、チャットで聞くには少し内容が複雑だ、といったケースもあったりするかと思う。 こういうケースでは、リモートワークよりも、オフィスなどのスペースに Team のメンバーが集まって作業をした方が、効率が良い場合も存在する。

とはいえ、働き方に多様性を設けようとした場合、リモートワークは避けて通れないのもまた事実である。 研修参加者の中には、面白い方法でこの問題を解決している方がいた。その方の会社では、オフィスにおける Team のワークスペースに、常時接続型のビデオ会議システムを導入し、リモートにいる Team のメンバーと常にビデオコールでつながった状態で作業をしているとのことであった。この方法によって、リモートのメンバーとも同一拠点にいるのと近い感覚で作業ができているとのことであった。話が少し飛躍するが、最近では VR 機器を使用した会議なんてものも出てきているようなので、技術の革新によってこの辺の問題は今後さらに緩和されていくのかもしれない。

人事評価

LeSS に限らず、Scrum では Team 内の個々のメンバーのパフォーマンスよりも、Team 全体でのパフォーマンスを最大化する方向で物事を考えることが多い。そういう意味では個人の人事評価はどのように実施すべきなのかという話は、研修参加者の中でも自然と話題に挙がった。

研修参加者の方々が口をそろえて言っていたのは、「定量評価」の替わりに「定性評価」を導入するようになったという話だった。各メンバーの Team に対する貢献度合いは、わざわざ定量的に評価せずとも一目瞭然なようで、Team 内でもある程度コンセンサスが取れているケースが多いらしい。むしろ定量的部分に着目し過ぎると、個人が数字ばかりに気を取られるようになり、Team 内での助け合いが減ってしまう恐れもあるようだ。

特に面白かった話としては、今回研修に参加していた、とある会社では、そもそも人事評価という概念が無いらしい。そのかわりに、社員は自身の欲しい額の年俸を提示し、それらの希望に応じて会社の予算の中から給料が振り分けられる。一見夢のような制度に見えるかもしれないが、その一方で全社員の給料が社内で公開されることで、公平性が保たれているとのことであった。

おわりに

本ブログは、認定 LeSS 実践者研修の講義内容及び、研修参加者との議論の中で出てきた話を私の観点でまとめたものとなっている。私の現職における役割上、LeSS の導入を実践する立場にはいないため、本ブログに記載されている内容については、実際に私が LeSS の導入を行って検証したものでは無い点については予めご理解いただければと思う。もし本ブログを読んでいただいた上で、「この解釈は誤っている」、「実際にうちで導入した場合にはこのようになった」などのご意見があれば、是非コメントいただければと思う。