この記事は Retty Advent Calendar 2019 8日目の記事です。
はじめに
マネージャーの常松です。 6月に入社して以来、開発プロセスの改善に携わってきました。
今年は大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法が刊行され、アジャイル開発・マネジメントの勉強会でも大規模スクラム(LeSS : Large Scale Scrum、以降LeSSと表記)の名前を聞くことが増えたように感じています。 しかし本だけを参考に自分の組織で大規模スクラムを導入していくのはまだまだ難しいのではないでしょうか? スクラム開発・アジャイル開発を組織全体に適用した事例はまだまだ少なく、悩んでいる人が多いのではないかと考えています。
Rettyでは2019年に組織全体へのLeSS導入を進め、ある程度狙っていたところに着地させることができました。 またその効果も感じられるようになってきています。 この学びをまとめてRegional Scrum Gathering Tokyo 2020にプロポーザルを出したのですが、残念ながら通りませんでした。
そこでこの記事でこの半年の学びをまとめ、LeSSに興味を持った方が自分の組織に導入する際の参考になればと思っております。
LeSSを選択した背景
Retty株式会社はグルメサービスRettyの開発・運用を自社で行っています。 まだまだ成長過程のサービスであり、ユーザーへいち早く価値を届けていくため、アジャイルな開発を志向することは自然な流れでした。 実際に2018年からスクラムの導入も始めています。
https://employment.en-japan.com/engineerhub/entry/2018/11/16/110000
しかし各チームが個別にスクラム開発に取り組むのでは、会社全体の優先順位とチーム内の優先順位に差が生じることがあります。 全社で最優先の課題解決に他チームの開発を待つ必要があったり、手が空いたチームが急ぎでない開発に着手しているといったことは皆さんも経験があるのではないでしょうか? このような問題はマネージャーなどの責任者が調整することで回避することが多いと思いますが、私たちは開発プロセスとして解決できる仕組みが必要だと考えました。
「組織全体で1つのスクラムを回すことを考える。その上で人数が多くスケールが必要なところを工夫する」というLeSSの考え方は、全社で1プロダクトの成長を目指す私たちがまさに求めていたものでした。 LeSSの仕組みそのものについては下記YouTube動画(日本語字幕あります)、公式サイト、ブログなどを参照ください。
- Overview - Large Scale Scrum (LeSS)
- LeSS (Large Scale Scrum) - tuneの日記
- https://qiita.com/yunon_phys/items/565490c5475777fce8d2
LeSS展開のプロセス
LeSS公式サイトではLeSS導入を進めるにつれプロダクトオーナー・開発チームへの支援から、徐々に組織・開発プロセスへの支援へと注力を変えていく必要があると解説しています。 ということで3つのフェーズに分けて順に説明していきます。
- 1チームスクラム期(4月〜6月)
- テスト導入期 (7月〜9月)
- 全社展開期 (10月〜12月)
1チームスクラム期(4月〜6月)
大規模とはいえ、「LeSSはスクラム」が基本です。なので、まずは「スクラムがきちんとできること」が最初の一歩です。 いきなり大規模スクラムでスタートしてはいけません。
先に貼ったリンク先で紹介されているアプリ開発のチームは2018年から取り組んでいましたが、少し遅れてWeb開発の1チームも2019年の4月からスクラム開発を始めました。 メンバーは書籍等で勉強し、スクラムのプラクティスを一通り押さえ、基本通りに始めてくれました… しかしスプリントを何回かこなしてみても、アウトプットが上がってこないことが課題として浮上します。 そこで私はアジャイルコーチとして開発チームに参加し、スクラムの背景をきちんと説明しながらプラクティスへの取り組みを1つずつ直していきました。 具体的には下記のような事項です。6月の中頃には自律したチームへと成長し、結果としてアウトプットも大きく改善されました。
- 小さくリリースする意識が抜けていた → ストーリーを分割する。リリースまでやりきる意識を持つ。
- スプリントプランニングがGitHub Issue(=ストーリー)の割り振りになっており、細かなタスク分解や計画ができていなかった → スプリントバックログをGithub Issueと分ける。付箋でタスク分解を行う。
- 見積もりが実作業時間に換算され、見積もり精度を高めることに意識が向いてしまった → 換算をやめ、規模の見積もりをするように促す。
- デイリースクラムが長く、課題解決の議論など脱線が多々あった → 報告を短くし、議論は朝会後に別途行うよう促す。
- KPTを使った振り返りで、全ての問題に改善策を考えたり、気持ちで解決するTRY(〇〇を気を付ける など)を挙げてしまい、改善が進まない → 改善策を2〜3に絞る。具体的な行動を伴うものを挙げる。
- チーム外からの割り込み(採用の手伝い、個人で受けたバグ調査など)がチームで共有できていなかった → ホワイトボードに付箋で張り出す。
- スプリントで終わらない開発項目が多い → 1人が並行して作業できる数を制限する。
「スクラムがきちんとできていること」の判断が難しいところですが、「より良いやり方に改善できていること」を実感できていることが大事だと思います。 「すごくいい振り返りができた！この調子でどんどん良くなっていきそう！！」とメンバーからコメントが出たあたりでもう大丈夫だなと安心したことを覚えています。
テスト導入期 (7月〜9月)
- 【支援対象】プロダクトオーナー、開発チーム、組織
- 【何を行うか】属人化の解消
- 【ポイント】コードを共同所有する意識を持たせる。開発チームだけでなくステークホルダーの信頼を得る。
次に複数チームでのスクラム開発が実際に機能することを証明するため、2チームでLeSSを始めました。 ここでの課題はシステムを構成する複数のサービス・コンポーネントを、2つのチームがそれぞれ扱えるようになることです。
Web開発に携わるメンバーが「予約」「検索」といった目的別のチームに散っていたため呼び戻し、下記に留意して2チームを組み直しました。
- 対外的に「同じ」責務を持つチームであることを明確に伝える。
- 1チームスクラムの成功経験を積んだメンバーを均等に割り振る。
- チームそれぞれが単独でリリースできるよう、フロントエンド・バックエンド・インフラを一通り触れるフィーチャーチームを構成する。
1はチーム名を「予約チーム」「検索チーム」のようにつけてしまうことで発生しうる、チーム名に引きずられた開発のアサイン・それに伴う属人化を防ぐためです。例えば「予約」「検索」がチーム名になっていたら「口コミ投稿」はどちらのチームが担当するべきでしょう、揉めますよね? メンバーに名前を考えてもらった結果、「きのこチーム」「たけのこチーム」となりました。幸いなことに戦争は起きていません。 2はスクラム開発がうまくいっていない時、それを感じ取って声を出せるメンバーが各チームにいて欲しいという気持ちです。
ポイントは3です。フィーチャーチームはLeSSが推奨するチームの組み方で、コンポーネントごとにチームを構成するのではなく、各チームがコンポーネントを横断して扱うクロスファンクショナルなチーム構成をとります。コンポーネントチームではチーム外の誰かが「開発項目をコンポーネント毎にタスク分解し」、「進捗管理を行い」、「情報を共有する仕組みを設ける」必要があります。これでは開発チームが自律して機能リリースまで漕ぎ着けることができないことは明白です。「このコードは誰が作った」という意識を変え、「コードを共同所有している」という意識を全メンバーが持ち、属人化した状態から脱却していくことが大切です。
ではそのためにどう対処したかと言うと…開発チーム・エンジニアを信じたところが大きかったと思います。もちろんフィーチャーチームを組んだ意図は丁寧に説明し、新たに扱うことになるコンポーネント・サービスを互いに教え合うことを促し、学習による一時的なアウトプット減少を受け入れ、心配に思うステークホルダーが社内にいれば説明に伺い理解を求めることはやりました。他には一度にたくさんのコンポーネントの学習が必要にならないよう、バックログの優先順位を多少入れ替えをした程度はあったと思います。エンジニアは一つずつ扱える領域を広げ、属人化が都度解消していきました。
チームの開発アウトプットは残念ながら目標に届かなかったものの、状況に応じた柔軟な優先順位の変更・開発状況の透明性・属人化の解消・開発チームによる自律した動きが実現でき、全社展開を進めるに足る信頼が得られたと考えています。
ちなみにこの期間は開発組織・目標設計を「運用でカバー」しています。例えば2チームのメンバーは上司がそれぞれ違っており、「個人に付与する」ことに決まっている目標設計は「チームで共通」にしました。組織や仕組みを先に変更してしまうと、うまくいかなかったときに戻すことが困難になります。「試してみて、うまくいったら変える」とすると色々と進めやすくなると思います。10月からLeSSに即した組織変更を行うことを事前に通知した際、2チームのメンバーからは組織変更に伴う不安が誰からも出なかったことから、2チームLeSSはうまくやれたのだなと感じたことを覚えています。
全社展開期 (10月〜12月)
- 【支援対象】組織、開発プロセス
- 【何を行うか】関わる人が増えるため、改めて丁寧に説明
- 【ポイント】プロジェクト思考からプロダクト思考への切替
10月からは新たにアプリ開発チームが合流しました。 アプリ開発に携わっていたメンバーにもAPIサーバーなどリリースにあたって必要なものは扱えるようになって欲しく、アプリに囚われないチーム名ということで「はらみチーム」と名乗ってもらっています。これにより「きのこ」「たけのこ」「はらみ」の3チームLeSSとなりました。 プロダクトオーナーとスプリント期間が一緒になったことで、両者の優先順位が自然と揃うようになり、スプリントレビューを一緒に行うことで仕様のズレなどプロダクト全体としての体験に目が向くようになりました。
合わせて10月からプロダクトの開発項目・方針を考えるプロダクト部門(プロダクトマネージャー・プランナー・デザイナーが所属)と実際に開発を行うエンジニアリング部門(エンジニアが所属)を分ける組織変更を行い、中・長期で開発体制をLeSSに寄せていくことを伝えました。これには良い面・悪い面の両方があったなと感じています。
[良い面]
- 組織構造から来る課題をきちんと言語化し、LeSSがなぜその対策になるのかまで踏み込んで共有した。
- LeSSを学ぶ機運が生まれた。特にLeSSの開発プロセスに関与していなかったマネージャー層にも興味を持ってもらえた。
- 会社の組織・開発プロセスを少しずつ良いやり方に変えていくのだと意識づけられた。
[悪い面]
- "LeSS"というほとんどの人には初見の言葉でギョッとさせてしまった。
- 何でもできるようにならないといけないという不安感を広げてしまった。アプリ開発者もWeb開発ができなければならないとか。
関わるメンバー・ステークホルダーが増えたことで、「プロダクトを皆で良くしていくことに変わりはない」「変化は少しずつ進めていく」「うまくいかない場合は無理に変えない」といった考えを個別に話したり、説明会を開いたり、説明資料を作ったり・・・と丁寧に・何回も説明し、不安感を取り除くことにとにかく注力しました。
また今回の組織変更はプロダクト部門のメンバーに「期限と限定された目標を持つプロジェクト型の仕事」ではなく、「終わりのない全体で改善を積み重ねていくプロダクト開発をやっている」のだと改めて認識してもらうきっかけにもなりました。 どう協力すればスピード感を持って持ってアウトプットを出していけるのか、中長期でプロダクトをどう成長させていくべきかといった議論が常に起きるようになり、互いを高め合う動きが今のところできてます。これについてはプロダクトオーナーの野口がProduct Manager Advent Calendar 2019の17日目にプロダクトマネージャー側から見た今回の変化を書いてくれるようで、私も楽しみにしています。
※2019/12/17追記 公開されました
導入後の状況と今後の課題
以上のように段階を経てLeSSへ移行したことで、下記のような効果が実感できています。
- 「ユーザーへいち早く価値を届けていく」開発体制への変化
- 定期的なアウトプット
- 小さく出して改善していく意識
- プロダクト全体でユーザー体験・優先順位を考える。
- 開発チームが自律したことでマネジメントのコストが減り、改善へ向ける余裕ができた。
一方でWeb開発とアプリ開発を一緒に行うようになりましたが、開発項目が並んだバックログはまだ別れています。 また社内にはまだLeSS開発に合流していない開発チームもあります。 LeSSの導入は単にフレームワークを入れるだけでなく、その時々に合わせてより良いやり方を「実験」していくことが求められています。 私たちのLeSS導入はまだまだ途中です。
おわりに
アジャイルな開発は「文化の変革」でもあると考えています。 LeSSに興味を持ったあなたが自分の組織に展開していく場合、あなたがアジャイルな考え方を受け入れるのに要した時間と同じだけ、新たにそれを受け入れることになるメンバーも待ってあげる必要があるのではないでしょうか。 「アジャイルである」ために今後も試行錯誤が続くと考えていますが、都度Rettyメンバーと議論し良いやり方を見つけていきたいと思っています。
RettyはRegional Scrum Gathering 2020をスポンサーしてます。私も3日間参加予定です。 今回の記事で書ききれなかったこと、疑問に思ったこと、知りたいことがあればぜひ聞いてください。会場でお会いしましょう!
