【アジャイル】LeSSをやってみた

大規模アジャイルフレームワークのLeSSを、実際の現場で導入～運用を手がけました。
大規模アジャイルフレームワークとは、複数のアジャイルチームを統括・管理するのに適用されるフレームワークを言います。有名どころでは SAFe や Nexus をよく耳にします。
今回は、LeSSの導入に至った経緯や、実際に運用して見えた課題についてまとめてみたいと思います。

もくじ

はじめに
LeSSとは
LeSSのメリット・デメリット
LeSSをやってみた
おわりに

はじめに

こんにちは。
クラウドソリューショングループの kikuchi.s です。
この記事は アイソルート Advent Calendar ２０２３ の１５日目の記事です。

LeSSとは

LeSSとは、Large-Scale Scrum の略で、アジャイルスクラム体制を極力シンプルにスケールする事に特化した大規模アジャイルフレームワークです。役割やイベントを増やすことを嫌い、POの関与を省力化することで規模拡大に備えることが出来ます。LeSSの適性規模は２～８チームであり、SAFeやNexusに比べて２チームという小規模からでも適用できるレームワークというのが魅力です。（SAFeやNexusは少なくとも３チーム以上の規模が適正とされます）

（参考）
①LeSSの概要をつかむための記事：何故 LeSSなのか？
②アジャイルスクラムの定義：スクラムガイド

LeSSのメリット・デメリット

メリット

①アジャイルスクラムで定義される役割と変わらない

PO（プロダクトオーナー）/SM（スクラムマスター）/DEV（デベロッパー）/ステークホルダー といった役割・ロール以上に定義されるものはなく、アジャイルスクラムチームと同じ感覚で体制を構築できます。

②アジャイルスクラムで定義されるイベントと内容がほとんど変わらない

ざっくり説明すると、スプリントレビュー/スプリントプランニング/レトロスペクティブ/プロダクトバックログリファインメントが第一弾、第二弾に分かれて定義されます。イベントの内容はアジャイルスクラムで定義されるものと変わらず、参加するロールの人が第一弾と第二弾で変わるくらいです。

③チームをスケールアウトするのにコスト少なく済む

メリット①、②で記載しているように、LeSSはアジャイルスクラムの進め方から大きく変えることなくチームをスケールアウトできるように考えられたフレームワークなので、チーム負担なるべく抑えることが出来ます。特に、メリット２で挙げたイベントが第一弾、第二弾で定義されるといっても、POは第一弾だけに参加すれば良いですし、DEVの大半は第二弾だけに参加すれば良いという感じです。

デメリット

①明確なコミュニケーションパスがない

スケールアウトに伴う役割・ロールやイベント数の増加を抑えている関係上、明確な「誰に」は存在しません。各自で互いの関係性を築き、自身の判断で適宜コミュニケーションをとることを前提とします。体制を俯瞰して見れていない、何かと受け身でコミュニケーションを取ってしまうメンバーは苦労する可能性があります。

②SM（スクラムマスター）の負担が大きい

役割・ロールやイベントを極力抑えている関係で、フレームワークという仕組みだけでのチームの統括・管理は困難を極めます。したがって、アジャイルが正しく運営されるように働きかける役割のSM（スクラムマスター）の難易度は高くなります。チーム間コミュニケーション、透明性の確保、ステークホルダーとの調整事項などを、SM（スクラムマスター）側で適宜ルールを設けるなどして基盤整備・円滑化を図ることが求められます。

③スクラムチームの経験値に依るところが大きい

アジャイル経験に乏しいメンバーは自律的に動くことが難しく、誰かのフォローがないと十分に成果を出せない依存状態に陥る可能性があります。LeSSというフレームワークは、メンバーが自律して動けることを前提とする要素が強く、スクラムチームとしての熟成度合いがパフォーマンスにもろ影響が出るところになります。なお、アジャイルスクラムを十分に経験したメンバーであればLeSSに対応することは可能です。

LeSSをやってみた

フレームワーク選定

DEV４名のスクラムチームを、開発規模に合わせて複数チームにスケールアウトしたいというプロジェクトの意向がありました。また、初回のスケールアウトは１⇒２チームとし、その後３チーム以上に増やすという段階を踏みながらチームを増やしたいという意向もありました。これら要件を踏まえ、複数チームを管理するにはスクラムガイドに定義される運用ルールだけでは足りないので、大規模アジャイルフレームワークへの移行検討が必要だと判断しました。

大規模アジャイルフレームワークには色んな選択肢がありますが、現場のアジャイル経験値からして次の３つを比較検討する運びになりました。

• SAFe
• Nexus
• LeSS

また、これらフレームワークから選定する際に優先すべき事項を定めました。

• スケールアウトする際にDEVの負担が少ないこと
• スケールアウト後のチーム立ち上げのスピード感を重視し、イニシャルコストがより低いもの
• 初回スケールアウトの２チームにマッチすること（以降のスケールアウトに耐えられることを次点での優先事項とする）
• コミュニケーションパスを明確化しやすいもの

つまり、元の１チームのPOやDEVになるべく負担がかからないようなスケールアウト方法を模索するといったところです。
比較検討の結果はLeSSに決まった訳ですが、以下が選定理由（決め手）になります。

• 元のスクラムイベントに対し、少し拡大した程度のイベントに留められる点
• スクラムのチーム構成を大きく変えることなく移行できる点

ただし、デメリットにも挙げましたが、LeSSはコミュニケーションパスの明確化が課題になります。この課題に対策を打つために、実際には、LeSSに多少の工夫を加えた”カスタムLeSS”としてスケールアウトを実施しました。

導入

前述の通りLeSSに工夫を加えた”カスタムLeSS”として、アジャイル運用ルールを以下のように定義しました。

　役割・ロール

• PO（プロダクトオーナー）：
  プロダクトの価値を最大化することの結果に責任を持つ。そのため、複雑な問題に対応するためにもプロダクトバックログの内容を明確化し、優先順位に並べる。

• POA（プロダクトオーナーアシスタント）：
  POの業務全般を支援する。また、POから権限移譲された業務については、POとしての責任を持つ。そのため、POの視点を常にキャッチアップし、POとの認識齟齬がないように細心の注意を払ってコミュニケーションを行う必要がある。

• SM（スクラムマスター）：
  スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ。また、スクラムチームの有効性にも責任を持つ。そのために、スクラムチームがスクラムの理論やプラクティスを理解し、プラクティスを改善できるように支援する。

• DEV（デベロッパー）：
  定義された成果物を完成させることに責任を持つ。そのために、スプリント計画を立て、完成の定義を忠実に守ることで品質を担保します。

　イベント

• デイリースクラム
  スクラムと変わりません。各チームごとに毎朝１５分の進捗確認・課題共有を実施します。

•  プロダクトバックログリファインメント（以下、PBRと表記します）
  • 全体PBR
    PO/POA/SM/DEVが参加します。ただし、DEVは全員ではなく各チームから代表１～２名が参加します。議論内容はスクラムのPBRと変わりません。

• • チームレベルPBR
    SM/DEVが参加します。全体PBRに参加したDEVの代表者が、各チームに議論内容を展開します。課題が発見されれば、必要に応じて関係者との会議を設けて認識合わせを行います。

• スプリントプランニング（以下、SPと表記します）
  • SP１
    PO/POA/SM/DEVが参加します。ただし、DEVは全員ではなく各チームから代表１～２名が参加します。議論内容は、スプリントバックログの選定までです。

• • SP２
    SM/DEVが参加します。全体PBRに参加したDEVの代表者が、各チームに議論内容を展開します。スプリントバックログをタスクに細分化します。課題が発見されれば、必要に応じて関係者との会議を設けて認識合わせを行います。

• スプリントレビュー（以下、SRと表記します）　※LeSSの定義から変更している箇所になります
  LeSSでは、全体SRとチームレベルSRで定義し、PBRやSPと同様にして、DEVの代表者が全体⇒チームレベルへ内容を展開する方式です。しかし、成果物のデモを直接見ることが出来ないことも相まって、隣のチームの開発状況をDEVが正確に把握することが難しいと考えました。
  ついては、スプリントレビューは一堂に会してPO/POA/SM/DEVの全員が参加します。議論内容はスクラムと変わらず、チーム毎に順に成果物の報告をあげます。

• レトロスペクティブ
  • チームレベルレトロスペクティブ
    SM/DEVが参加します。議論内容はスクラムと変わりません。なお、現場ではKPT分析を用いた振り返りを実施していました。
    （参考）【アジャイル】KPT分析でふりかえりを効率的に

• • オーバーオールレトロスペクティブ
    PO/POA/SMが参加します。また、必要に応じてDEVから代表者の参加を要請します。開発に寄った話というよりかは、アジャイル運営の管理視点に立った振り返りが主旨となります。アジャイルイベント運営/チーム間コミュニケーション/プロジェクト全体の透明性確保/etc… のような観点で俯瞰して良い点・課題点などを洗い出し対策方針をすり合わせます。

課題と対策

①コミュニケーションパスが明確化されていないが故に、誰かに問い合わせが集中する

現場で多かったのは、POAやSMが誰かと誰かの橋渡しになることです。アジャイルの観点からすると関係者同士が直接やり取りして欲しいところですが、立ち上がりはどうしても関係性の構築がない状態ということもあり、誰かに問い合わせが集中してしまう状況に陥りやすいのかなと考えます。これは誰かに依存している状態なので対策しないと後々で大きな問題になります。

対策として、インセプションデッキの「お隣さんを探せ」のように体制図を可視化して整理し、問い合わせ先の認識合わせを行いました。少しずつですが効果は出てきており、コミュニケーションパスがスマートになり、橋渡し業務が減りました。こういった対策はSMから継続的に啓蒙してチームに浸透するよう働きかけたいと思います。

②DEVの代表者が偏る

案件初期から関わっている、背景・前提を分かっているDEVが参加しないと話がスムーズに進まないところがあり、どうしてもDEVの参加者は固定になりがちでした。

対策として、いきなり固定のDEVを参加させないということは難しいと判断したので、固定のDEVとは別にもう一人DEVが持ち回りで参加するかたちを取っています。結果、他のDEVの方も徐々に議論内容についていけるようになりつつあります。これも継続的に取り組みながら、誰かに依存する状態から脱却できるよう改善を図っていきたいと思います。

おわりに

いかがでしたでしょうか。

今回ご紹介した内容は、案件/体制/特性/etc… に合わせて検討・導入し、見えた課題になります。なお、上記で挙げた以外にも課題は色々ありますが、LeSSに特化した課題感に絞って記載しております。これ以外には、複数チームの管理/チーム構成の複雑さ/etc… などが起因となる課題もありました。

私は、こういった課題をスクラムマスターがいち早くキャッチしスピード感をもって対策する必要があると考えます。もちろん、チームメンバーに頼るべきところはしっかり建てつけた上で相談し、チームとして解決していくことこそが非常に重要です。独りよがりでは本当の改善にはなりません。

めちゃくちゃ難しいけど、これこそ”アジャイル”です。チームとして価値を追い求め成果をあげていくことをやりがいに、もっともっとアジャイルを深く理解していきたいと思います。

以上です。ここまで読んでいただきありがとうございました。