エンジニアから見た、大規模スクラム「LeSS」を始めてよかった3つのこと
こんにちは、atama plusでエンジニアをしている安井です。
atama plusでは創業時からスクラムを採用し、開発を続けてきました。
そしてメンバーが増えるに従って、大規模スクラムの一つであるLarge Scale Scrum（以下、LeSS）体制に移行しatama plus流に磨き込んできました。
今回は私がエンジニアとしてLeSS体制を経験し、
同じプロダクトを複数のスクラムチームで役割分担して作るよりも
良い点が多かったため紹介してみたいと思います。
LeSSを採用するまでの過程については弊社河口が記事を書いておりますので、そちらをご覧ください。
LeSS体制を取り入れてよかったこと
1. プロダクト全体で最重要なタスクにリソースを集中できる
例えばA・Bの２チームが別々にProductBacklogを持ち、
それぞれの得意領域でタスクが分かれているとします。
Aチーム「今自分たちのやっているタスクと、その次にやる予定のタスクはどちらもめちゃくちゃ顧客へのメリットがある。早くリリースしなくちゃならないのに手が足りない」
Bチーム「ProductBacklogが小さな改修ばかりだな。本当にこれ優先度最高なの？手が空いてるし、前作ったシステムのリファクタやろうかなぁ」
これは極端な例かもしれませんが、
LeSS体制に移る前のatama plusでは、こんな事が起きてたんですね。
（リファクタリングが不要という意味ではないです）
そのような問題を避けるため、ProductBacklogを統一し、
全てのチームが同じ優先順位に基づいてタスクを選択するようにしました。
同じProductBacklogを見て各チームが取り組むタスクを選択することで、
常にProduct全体で最も重要なタスクにリソースが集中している状態を作る事ができるようになりました。
2. チームをまたいだ協力がしやすい
分担や受け渡しをするのではなく、チームをまたいで同じタスクに取り組む。
これって意外とやろうとすると難しいのではないでしょうか？
LeSS体制でPlanningする時、こういう会話がされていました。
スクラムマスター「各チームで、今回のsprintでとる予定のタスクを出したけど、優先順位高いタスクが一つ残っているね。
どこかのチームで、他のタスクの代わりに取れませんか？」
Aチーム「この機能の一部を次のsprintに回して二段階でリリースする代わりに、取りますー」
こんな具合にチームが個別最適に陥らず、
全体の優先順位を見る習慣がついてきたんですね。
慣れてくるとこんな会話がではじめました。
Aチーム「今やってるチケット○日までには絶対リリースしたいんだけど、
このままじゃ間に合いそうにないので助けが欲しいです」
Bチームdev「Bチームが今後着手予定のタスクは急ぎじゃないので、
1-2週間ヘルプに入りますよ」
CチームUX「そのチケットの背景は知ってるから、デザインの確認を手伝うよ」
Product全体の優先順位が全員に見えているから、柔軟に動けるんですね、
全体の成功確率を上げるために、ヘルプを依頼する側も、あまり気負わずに協力の依頼ができます。
3. 徒労感が少ない
原則として、どのチームも優先度の高いタスクに取り組む事になるため
「限りある開発チームのリソースを無駄遣いしている」という感覚が起こりにくいです。
また、自分の抱えたタスクの難易度が高く解決に時間がかかりそうな時でも悩むより助けを求めて早く進めた方が、エンドユーザのためになります。
苦ではないけど大変だったこと事
1. 「チームが自律して意思決定をする」という意識変化
LeSSにおける開発チームでは、基本はDev UXデザイナー、
QA（Quality Assurance）で構成されたチームです。
POプロダクトオーナーやスクラムマスターSMがチームに一人ついておらず、チームを引っ張る役割がないんですね。
チームビルディングやファシリテーション、どのチケットを選択するかなど
様々な事柄をチームが自律して意思決定しなければなりません。
メンバーは「決めてくれ」とも「決めさせてくれ」とも言えず、全員に主体性が求められます。
「私はこうするのが良いと思うんだけど、みんなどう思う？」
という問いが繰り返され、どの意思決定もしっかりと議論した上で、チーム全体の納得感を得ながら進みます。
複数のチームを見ているスクラムマスターのサポートを受けつつ、各チームに合ったやり方を構築していきました。
2. コミュニケーションにかける時間が増えた
チーム内での意思決定や計画に加え、チームを跨いだコミュニケーションがLeSSでは非常に重要です。
来週やると思っていたタスクより重要なタスクがProductBacklogに入ること事もあれば、
バグや障害の対応で、最優先のタスクを担当しているチームの進捗が遅れてくること事もあります。
通常のスクラムでもPlanning・BacklogRefinement・Retrospectiveなどのミーティングは重要ですが、
LeSSでは、チームのミーティング物に加え、全チームで集まるミーティングも加わり、それぞれ二回行います。
複数チームで集まるミーティングが長引くと負担が大きいため為、
事前に各チームで方針の叩きを作っておいたり、sprintBacklogをしめておくといった補助的なミーティングが生まれることも。
「え、今週コード書ける時間これだけ？」
と思うこともありますが、上述したメリットを得るには開発チーム全員が全体感を持っている状態の維持が必要です。
3. 意識的にナレッジを共有する必要がある
共通のProductBacklogを持つということ事は、
限られた領域ではなく広い範囲のタスクを担当するため、
必要なナレッジの範囲が広くなります。
Aチーム「バックエンドが得意なんで、フロントはやりません。
Angularわかりません」
Bチーム「このシステムは、Aチームが作ったからわかりません」
とか言っていると、機能しません。
他チームの作った機能であっても、自分達が引き継げるくらいの最低限の背景知識と、
全体設計を把握できる程度に積極的にナレッジを共有していました。
とはいえ、全員の知識を同等にするまでは難しいため、
原則は詳しいチームが担当すること事が多いです。
ただし、協力が必要になった時にサポートできるように、たまに他チームとメンバーを交換してみたり、
あえて詳しくない領域のタスクを取るといった取り組みをしています。
4. 優先順位は低いけど、やりたいタスクに取り組みづらい
ProductBacklog上位は、全社の戦略や顧客へのインパクトの大きなタスクが占めています。
AチームUX「ページごとの余白の違いがめちゃめちゃ気になる」
BチームDev「そろそろサーバーサイドのフレームワークを置き換えたい」
そうなると、優先順位は低いけどいつかやりたいようなタスクに
割けるリソースは永遠に巡ってきません。
サクッと個人でできる修正であればやってしまうのですが、
工数が大きくなると納得いく理由とともに、熱意あるメンバーからPOへの働きかけが必要です。
もちろんそういったタスクも全くやらなくて良い訳ではないので、つっぱねられたりはしません。
既にBacklogにあるタスクと同様に、必要性を議論して一定のリソースを割いています。
LeSS体制でのあるチームの1週間
sprintの流れと他チームとの協業検討するタイミングはこんな具合です。
水：SprintReview
Retrospective
複数チームでのSprintPlanning
各チームでのSprintPlanning
木：作業日
金：複数チームでのBacklogRefinement
月：作業日
火：POと一週間の振り返りと次のsprintの大まかな方針を話す
チームで次sprintの方針を相談、チーム間連携どうするかとかも相談
基本のミーティングに加えて、職種横断のミーティングがあったり、個々人で別の役割を持っていたりするので、作業時間の見積もり、きちんと完了できる範囲で計画を立てています。
これからの取り組み
社員が増え続ける中で１つのLeSSチームに全ての課題を詰め込んでいては
パンクしてしまうため、
LeSSチーム自体の分割も試みています。
新たなペインも生まれるでしょうが、しっかり向き合って解決していきたいと思います。
atama plusはまだまだ成長途上の会社です。
より多くの生徒により良い教育を受けてもらうため、
限られたリソースで優先順位をつけて取り組んでいますが、
「もっと仲間がいればあれもこれも進められるのに！」と歯がゆい思いです。
この記事で少しでも興味を持っていただけたら、嬉しいです。