大規模組織でLeSSの再導入をしています
スクラムが好きです。ここ数年、スクラムをよく知らないけどスクラムイベントをやっているという現場でスクラムを再導入するということに向き合ってきました（よくよく考えると不思議な縁だなと思ったのですが、よくあることなのでしょうか）。
今まさにそろそろ始めるぞ！というタイミングなので、始めるまでにやったこと、考えたことをまとめていきます。
現在の現場ではスマートフォンゲーム開発をしており、組織規模は大きめです。エンジニアはスクラムチームが複数作れる人数、ディレクターが複数人いて、デザイナーは少なめ、QAチームがたくさんというチーム構成です。PMやEMも複数人います。スクラムを知ってる？と聞くと「なんとなく知ってる」「聞いたことはある」が若干名。
プロローグ
状況把握
弊社のEMは組織課題の解決やアジャイルな開発プロセスの導入が含まれています。
まずは現在どのような状態を把握するためにヒアリングから。
把握した現在の体制、プロセス
- ロードマップを引いた数ヶ月ごとのリリース
- バージョンチーム（リリース単位で実装、テストに関わるメンバーを定める）が組成され、PJTの進捗状況により増減員しつつ、リリース後に解体される。複数のバージョンチームに携わるメンバーがいる
- 開発完了後検証を開始する
- 進捗はガントチャートで管理し、朝会でガントチャートを確認
- スクラムイベントを行っているが、バージョンチーム、セクションチームでスクラムイベントが混在（下図。朝会、夕会が抜けている）。
現場からの課題感
- MTG（スクラムイベント）が形骸化
- 複数のバージョンチームにまたがるメンバーがいるため、朝会や夕会だけでで1時間弱かかり、プランニングも時差で行う必要がある
- 振り返り〜プランニングの間に1日ある
- スケジュール管理や進捗確認が大変
- プロジェクトの後半になって進捗の遅れが判明する
- 進捗の遅れの原因が分からず、解決策の妥当性も分からない
- 振り返りがあまり意味を出せない
- チームの一体感が少ない。より主体性を促したい
さて、どうしましょ
各メンバーと1on1をして課題を聞き、各種イベントに何度か出た時点で、ちゃんとLeSSをやっていこうという方向性はEM内ですぐに合意できた（入社から10日くらい）。しかし、入社後すぐ大規模な組織を相手に「課題があるから体制とプロセスを変えるぞ〜〜」とはならないし、理解・共感をしてもらえるための時間と信頼を得るための対話を大事にしようと考えました。
理解・共感を得ようとしたのは「学習する組織」の
人は変化に抵抗するのではない。変化させられることに抵抗するのだ
という言葉があるように、自分たちでそうなりたいと少しでも感じてもらうためと、理解せずに導入しても形骸化してしまうからです。
導入ステップ1. 理解、共感
LeSS導入に至る背景をLTで伝えた
チーム全体に対して週次でLTを実施。LTは2部制で、LTを完走すると AsIs ToBe が埋まるようなコンテンツにしました。
- 第一部 認識を揃える（チームとしてありたい姿、効率的な仕事の仕方）
- 第二部 具体的にやること（LeSS）
第一部ではHRT、心理的安全、自己組織化など全15回*1ほど行いました。
LTでお世話になった書籍
1セクションでスクラムをやってみた
エンジニアのみのチームでスクラムイベントの改善を試みてみました。当初予定していなかったのですが、チームの中で「振り返りを改善したい」という声があったからです。そこでプランニング、スプリントレトロスペクティブを少しずつ変えていきました。セクションチームでスクラムをやってみようとすると、以下のような問題にぶつかります。
- 要求が不明瞭だが確認するPOがいない
- セクションを越えた課題の解決コストが高い
- セクションを越えて業務の流れを整理したり、完了の定義を定めづらい
- 上記のような状態のときにリーダーがハブになり別の場所で解決する必要がある（イベントが止まる）
「クロスファンクショナルなチームになったほうが良い」という声が聞けました。
導入ステップ2. 輪読会や勉強
有志で輪読会や勉強を行いました。読書リスト。SMは必須。
www.amazon.co.jpwww.amazon.co.jp
www.amazon.co.jp
www.amazon.co.jp
導入ステップ3. 組織への適応を考える
自チームへの適応で難しかったのは、組織規模の大きさ、Epicの大きさです。またPBIもリリース可能な単位とするととても大きくなってしまいます。
体制
通常のLeSSの体制は以下のような体制ですが、自チームでは企画を考える（PBIを作る）メンバーが複数名いること、彼らと一緒に企画を考えるデザイナーが複数名いることがありました。
また、LeSS Hugeの形は適していない（Areaが固定できない）という事情があり、POのプロダクトバックログを作成する作業を委譲する形でEPO（Epic Product Owner）というポジションを作ることにしました。全体構造が以下の図です*2。
ロールと責任範囲
RACI図でまとめました。フラットな構成の中でボールが落ちることやコミュニケーションロスを防ぐために役立ってくれるはず。
計画づくりと進捗把握
PBIを相対見積もりし、以下の記事を参考にプロジェクトバッファを算出、CCPMのバッファ消費率を用いてプロジェクトの状況を把握します。その他、タスク管理ツールのバーンダウン（スプリント、バージョン）も参照します。「10秒あれば誰でもPJTの状況が分かり、POが判断可能な状態」を目指します。
なぜ LeSS の再導入を推進したのか
能力の高い人が集まったチームや組織であっても、 体制や仕事のやり方よっては1+1が2にも満たない状態になってしまいます。メンバーには主体性を持って、プロダクトゴールのために行動できる自立した人でいてほしいし、ユーザーに価値を提供し続けられるチームでありたいです。私は、メンバーが自分の魅力や能力を発揮しやすい基礎を作ることもEMとして大事な責務だと考えているのです。ここから先を彩っていくのはメンバーが主体的にやっていってくれるでしょう。私は彼ら彼女らをサポートしていきたいと思います。
あとがき
メンバーが感じている課題からLeSSの再導入は適当（チームの固定化、クロスファンクショナルなチーム設計、テストのシフトレフト、イテレーティブでインクリメンタルなアプローチ）だと考えたのですが、体制を考えるのが当初考えていたよりも苦戦しました。
過去B2B Webサービスでスクラムをやってきました。〇〇業界だから、こんなプロダクトだからスクラムができる / できない / 適している / 適していないということはありません。どういうチームでありたいか、どのようにユーザーに価値を届けていきたいか、その先にスクラムやLeSSがあるかないかという話なだけです。
この記事は、Engineering Manager Advent Calendar 2020の8日目の記事でした。他の方の記事は以下からご覧ください！
