こんにちはGROOVE XでScrumMasterをやっているniwanoです。
先日の11月26日、恵比寿にあるRed Hatのオフィスで、LeSS Huge 導入事例に関するイベントに参加しました。
そこでWARTSILA（ワーツィラ）社の実例をベースにした学びを得ることができました。
（このイベントはBas Vodde氏の特別講演で通訳は、Odd-eの榎本氏です。）
LeSS Huge 導入事例の動画解説 – connpass
WARTSILA は、豪華客船や発電所向けの巨大エンジンを製造し、さらにそのエンジンを”止まらずに動かし続ける”ためのメンテナンス契約と監視ソフトウェアを提供している会社です。
今回のイベントでは、同社の実際のスクラム運用を密着撮影した映像をもとに、LeSS Huge のリアルな姿が紹介されました。
私自身「これは自社にも取り入れたい」と強く感じた点が多くあったため、以下に整理してレポートします。
30〜40名のソフトウェアエンジニアが全員で行う「スプリントプランニング1」の衝撃
WARTSILA では、代表者制度を廃止しています。
「代表だけがスプリントプランニング1に集まる」という従来の手法は、現在の Less では推奨されていないと、Bas 氏は言っていました。（LeSSも日々アップデートしているそうです。）
代わりに彼らは、
30〜40人が全員集まってスプリントプランニング1を実施します。
そして面白いのが、PO や ScrumMaster が前面に出てこないという点です。
プランニング1の全体運営は「チームが行う」ものであり、PO や ScrumMaster がファシリテートするものではありません。
プランニング中に起きていた「プロダクト全体思考」を象徴する光景
スプリントプランニング1の最中、非常に印象的だったことがあります。
自分のチームに関係のない PBI についても、積極的にアドバイスをするメンバーが何人もいたことです。
普通なら「自分のチームが取る PBI だけに集中する」のが自然です。
しかし WARTSILA のチームはそうではありませんでした。
- 他チームが説明した PBI に対して「それならこの技術的前提も確認したほうがいいよ」と助言する
- 特定のタスクを取り合っていても、「プロダクト全体として最適になる」方向に議論が収束する
- 依存関係で詰まりそうなチームがいれば、即座に「助けようか？」と声をかける
これらはすべて、個々のエンジニアがプロダクト全体思考を持っているからこそ成立する振る舞いだと感じました。
このマインドセットが、部分最適ではなく全体最適を生む
Bas 氏も繰り返し語っていたのは、
「エンジニアがプロダクト全体思考を持つことで、プロダクト全体の最適化が加速する」
という点です。
つまり、
“自分のチームの利益”ではなく “プロダクト全体の成功”を第一に考えるエンジニアこそが、巨大組織のアジリティを支えている。
その結果として、
- チーム間の摩擦が減る
- 無駄な調整が不要になる
- 決断が圧倒的に早くなる
- PBI の取り方もプロダクト全体にとって合理的になる
という好循環が回り始めます。
優先順位が“ユニーク”だからこそ、プロダクト全体思考が成立する
ここで非常に重要だと感じたのが、WARTSILA では優先順位が1本化されていることです。
Less が推奨する「単一のプロダクトバックログ」は、
単に管理のために存在しているわけではなく、
“エンジニアがプロダクト全体思考をもつための仕組みそのもの”
になっています。
優先順位がユニーク（一本化）されているからこそ
- どのチームも「今プロダクトが最も必要とするもの」が明確にわかる
- チームごとのローカル最適が生まれない
- 他チームの PBI であっても自分ごと化しやすい
- “全体最適” へ議論が自然に向く
という状態がつくられます。
逆に、複数のバックログや複数の優先順位が存在すると、
エンジニアは必然的に「自分のチームの都合」を優先しがちになり、
プロダクト全体思考は育ちません。
学び
この “チームによる運営” は、自律性の象徴です。
スクラムマスターは自律チームづくりにより深く時間をそそぐべきだと感じました。
また、今回見たような プロダクト全体思考 は、弊社のエンジニアにもぜひ身につけてほしいと強く思いました。
- 自分の担当領域だけを守るのではなく
- プロダクト全体の価値を最大化する視点で
- 他チームにも率直に助言したり、改善提案したりできる
そんな文化を持つことが、部分最適ではなく全体最適を志向する組織をつくります。
そして、プロダクト全体思考を育てるためには、優先順位をユニークにする構造が欠かせない。
それが今回の最大の学びのひとつでした
スピルオーバーを「悪いこと」として扱う文化
スピルオーバー（＝PBIがスプリント内で終わらず、次のスプリントに持ち越されること）、WARTSILA では強く問題視されます。
未完了はリズムを乱し、改善を阻害します。
だからこそチームは全力でスピルオーバーゼロを目指します。
また、他チームの依存で詰まっているメンバーがいると、即座に他チームが「助けようか？」と声をかけるのも印象的でした。
さらに、WARTSILA ではスピルオーバーが起きるとチームが自然と申し訳なさそうにするほど、
組織文化として「悪いこと」と認識されている点も非常に印象的でした。
これは責められるからではなく、「プロダクト全体に貢献できなかった」という健全な責任感から生まれる態度です
スピルオーバーが発生すると何が起きるのか
今回のイベントを通して、スピルオーバーが引き起こす負の影響は想像以上に大きいと改めて実感しました。
①優先順位のコントロールが乱れる
スプリントの最後まで残った作業が次スプリントに持ち越されると、
本来その次スプリントで優先されるべき PBI が後ろ倒しになります。
つまり プロダクトの優先順位が歪む のです。
②ステークホルダーとの信頼低下
ステークホルダーは「スプリントで完了する」という前提で期待をもちます。
その約束が繰り返し守られないと、
チームの予測可能性が低い＝信用できない
という評価につながります。
③ WIP（仕掛かり作業）の増加 → 効率低下
スピルオーバーが発生すると、仕掛かりの作業がどんどん積み残されます。
WIP が増えると
- 集中力が散る
- コンテキストスイッチが増える
- レビューやテストの負荷も増える
- 新しいタスクに着手できない
結果として チーム全体の効率が大きく低下 します。
ウォッチシフトのチームは割り込みタスクを前提に「スプリントに詰め込みすぎない」
WARTSILA では、市場の障害対応などの割り込みタスクが発生すると、それを担当するチーム（ウォッチシフト）は スプリント中に新しく取るタスク量を明確に減らしています。
これは、
- 割り込みタスクは発生するもの
- 割り込みを担当する以上スピルオーバーリスクが高い
という前提を組織全体が理解しているからです。
この「割り込みを前提に、最初からスプリントに余白を作る」ルールは、弊社でも十分応用できると強く感じました。
後日、榎本さんからお伺いしたのですが、スプリント中に完了しないPBIがあってもリバーとしてPBLに戻せば、スピルオーバーにはカウントしないそうです。 問題なのは、リリースできないこと、POが優先順位を柔軟に変更できないこと。さらに、問題なのは、スピルオーバーが多いチームは個人にタスクを割り当てていることが多い、のだそうです。（これは弊社にも当てはまりそうです。。。）
学び
弊社でも、割り込みタスクが原因でスピルオーバーが発生するケースがあります。
さらに、割り込みタスクを積極的に取りにいくメンバーと、そうでないメンバーの差が生まれていることも現実起きているようです。
ウォッチシフト運用は弊社でも実践可能
「ウォッチシフトチームは、最初からスプリントの作業量を減らす」という明確なルールを導入することで、スピルオーバーは大幅に減らせます。
スピルオーバーに対して健全な“申し訳なさ”が生まれる文化を作りたい
罪悪感ではなく、プロダクト全体に対する責任感としての「申し訳ない」が重要。
Weber チーム ― 「不快さに飛び込む」チーム文化
Weber チームはイベント参加者にも強烈な印象を残したチームです。
- 自分たちが最も不快になるタスクを率先してとる
- スプリントプランニング2では「最も自信がない人」に設計説明を任せる
- モブプロ中に他チームから質問が来たら 全員で 説明に向かう
- 入社3ヶ月の新人にも難しいタスクを開放する
これは組織として「早い学習」を最重要視している表れであり、不快ゾーンに自分から飛び込む＝学習を止めないチームそのものの象徴だと感じました。
そして印象的だったのは、講演中に Bas 氏がこのチームの説明で使っていた言葉です。
「コンフォートゾーンを抜ける」
まさに Weber チームの文化を体現するキーワードでした。
この言葉は、実は 弊社 CEO もたびたび社員に向けて発しているメッセージと同じであり、イベント中にその言葉が出た瞬間、私は強く “重なり” を感じました。
つまり、
私たちの会社も、本質的には同じ方向を目指している。
そのことを改めて確認できた瞬間でもありました。
いわば Weber チームは “自律的に学習しようとするチーム” の理想形です。
彼らにとって「不快」は避けるべきものではなく、成長のサインであり、チームの可能性を広げるための燃料なのだと実感しました。
学び
私たちも、こうした “不快ゾーン” を意図的に取りに行く文化 を作れるはずです。
特に
- 新メンバーに早期から大きなタスクを任せる
- あえて挑戦的な領域のタスクをチームで取りにいく
- 自信のない領域にこそ学習のチャンスがある
こういった考え方は、組織全体の学習速度を何倍にも引き上げます。
そして今回強く感じたのは、
「こんなふうに学習しつづけるエンジニア組織をつくりたい」
ということでした。
また、弊社のプロダクトは範囲がとても広く、すべての領域をカバーするエンジニアを育てるのは難しい現実があります。
だからこそ
というアプローチは非常に現実的だと感じました。
Weber チームのような「自律的に学習するチーム」を増やすことで、広いプロダクト領域の中でも、
全体として学習スピードが落ちない組織構造が作れるはずです。
私が「自社にも取り入れたい」と思ったことまとめ
最後に、今回のイベントから私自身が 「これは自社でも実践できる・すべき」 と思ったことをまとめます。
プロダクト全体思考＝優先順位はユニークに。並列化しない
複数バックログや複数優先順位は害悪。
エリアを分けた上で、顧客価値起点で一本化されたバックログを作るべき。
ウォッチシフトのような、当番制でフローを守る仕組み
システムトラブルや問い合わせ対応を“持ち回りチーム化”し、開発チームのフローを守る。
Weber チームの「不快ゾーンを取りに行く」文化
チームが自発的に学習を促進できるチームにする
おわりに LeSS Huge は“巨大な自律チームをつくるためのシステム”だった
WARTSILA の実例は、単なるプロセス改善の話ではありませんでした。
そこにあったのは、人とチームが自律し、学習し、相互に支え合う巨大な“生態系” です。
LeSS Huge を学ぶとは、単にフレームワークを知ることではなく、
「チームにオーナーシップを返す勇気」を持つことなのだと、強く感じました。
