こんにちは！LIFULLのプロダクトエンジニアリング部の井上です。 エンジニアリングマネージャーをやっています。
今回は、私が管掌する組織で「大規模スクラム」という、スクラムを拡張して複数チームで運用する開発手法へチャレンジし、生産性向上を図った話をしようと思います。
結論
結論から伝えますと、組織を俯瞰して管理する立場からすると、一定レベル、メンバー主体で合理的に動ける仕組みをつくれた実感をもてました！ その反面、経験値不足もありますが本質的な組織的なスクラム開発が実践できているか？と言うと、まだまだ改善をしていく必要があるとは感じています。
取組みのポイント
スクラムの３本柱「透明性」「検査」「適応」に倣うならポイントはこのような感じです。
| 透明性 | バックログは組織に１つだけ | 誰でもいつでも全体像が見れる、判断できる状態をつくる（チームや誰かだけしか知りえない状態は禁止） ただし認知コスト削減の為にチーム単位でフィルタを作るのは問題なし |
|---|---|---|
| 検査 | 意思統一できる場を用意 | 全体＋各チームの状況を共有や相談できる場、共有や議論できる定例を用意 |
| 適応 | 優先度ルール | 基本的には各チーム内施策に集中すればよい ただし、優先度が高い障害や、組織判断で優先度「高」の施策が現れたら、各チームの施策に専念する限りではないというルールを初期に徹底 |
前提（それまでの組織の構造）
最初に、私が管掌している組織の話からさせてください。
私が管掌する組織ではあるプロダクトに対して１つミッションを持っています。
今回の取り組み以前は、それらの達成のために４～６人程度の職種混合の小チームを４～５チーム程組成し、それぞれで施策表/課題表（バックログ）をつくり開発していました。
チームだけで考えれば関心ごとがチーム中で閉じている為、意思決定速度は担保されるのですが、チームでミッションを固定している故にチーム外への意識が弱くなったり、全体では優先度が高い施策や変化に対して、柔軟性が損なわれる課題がみえていました。
私たちが目指したいこと
限られたリソースで、効率よく最大の効果を出すためには・・
＝チームへミッションを固定させすぎず、全体視点で優先度が高い課題から対応できると良さそう
真の優先度が高い施策から実行したい
これを実現するためには、ひとつのミッションを分解した課題群が組織で１つのバックログで管理され、各チームがバックログから自主自律的に、優先度が高い課題を選んで実行していくことが理想と考えました。
柔軟な組織
また、期の途中であってもミッション実現のために当初計画していたタスクとは別に、重要な課題が発生するケースも考えられ、突発の事態に柔軟に対処できる仕組みである必要があります。
想定される、計画外案件：
- 障害対応
- 他部署からの依頼・相談
- 成果を出すために、戦術レベルでの優先度変更
など
効果的なチームの組成
効果的なチームである為には心理的安全性が重要であるという調査結果もでています（Googleが公開しているre:Workより）が、この観点でも配慮はいれたいと考えました。
その為にチームメンバーを固定することができれば、互いに信頼し合い働き方や考え方・期待値を一致させることがしやすく、仮に優先度にあわせてミッションやKPIが多少変化したとしても高いパフォーマンスで乗りきりやすいと考えました。
逆に、チームメンバーがコロコロ変化すれば信頼や考え方の一致が出来るように至るまで、パフォーマンス低下は免れないでしょう。
現実は複雑
新規開発などシンプルなKPIを追いかける構造のミッションや、スクラムに対して習熟度が高いメンバーが揃っていれば、上述した仕組みがワークする気がするのですが・・・
施策優先度が単純に比較できない
数年間、運用を続けているプロダクトに対して適用させると、方向性がそこそこ違う複数の打ち手が並列で並んできます。
すると、チーム間で優先度の判断は非常に困難になってきます。
| チーム | 打ち手 | 課題 |
|---|---|---|
| A | UX追及 | 〇〇モーダルの挙動調整 |
| B | SEO対策 | 〇〇記事からのリンクの新規設置 |
| C | 新機能開発 | 〇〇機能の開発 |
全体で優先度を判断するためには、方向性の異なる打ち手を誰かが管理する必要があると思います。 その方法として以下のようなパターンが考えられます。
- 方法①：各チームのスクラムマスターが集まり、全体バックログリファインメントを実施し全体管理して各優先度を決定。
- 方法②： 全体をみている上長が、トップダウンで優先度を判断。
しかし、前者は認知負荷が大きかったり、後者も上長が都度意思決定するプロセスが増えてしまい、不要なコストがかかりすぎるように思えました。
前提となるスクラム / アジャイル開発に対して、理解や習熟度がバラバラ
そもそもスクラムやアジャイル開発を知らない・経験がないというメンバーは、いないものの、習熟度も興味も人によって差が大きく、理想形から組織に落としていくには、導入コストもコミュニケーションコストも大きい割に十分なリターンが得られるか不透明で、困難を極める事が想定されました。
導入の為に、意識したこと
理想と現実のジレンマはあるのですが、最初からすべて完ぺきに実行するのではなく、次の３点をベースに極力シンプルなルールを設ける事としました。
意思決定の速度を高める、不要なものを可能な限り排除
チームメンバー全員がチームの中と外の両軸について、常に関心を持ち続けることは認知コストが高く効率性を下げてしまいます。 よって、シンプルに原則チームに集中してよいルールとし、チーム内はもちろん組織全体で発生した優先度が高い課題をとるかはチームの自主・自律性に任せる体制としました。
合わせて上長が意思決定や承認に入るケースも最低限とすることで、より効果を高めることも図りました。
定期的に、全体の数字や課題を確認・議論できる場を用意
とはいえ、チームに関心を集中しすぎると、横断的な施策などに対して組織的な柔軟性は失われ、上長が指示をしたとしても自主性がないためストレスを抱えかねないと考えました。
これは心理学でいうザイオンス効果（単純接触効果）により、自身が一番よく触れる数字や課題、プロダクトに対して、興味をもってしまうので致し方がないことだと考えていますが、極端になりすぎないようにしなければいけません。
効率よく結果を出す為には、隣のチームと協力できる程度の情報共有はされているべきですし、上述していますが、当初計画していなかった戦術の変化や緊急対応はありえる事だから対処が当然必要です。
その為に、隔週でスクラムマスターを集めて組織全体の中でも特に課題となっている部分だけを議論する場を用意し、話し合いで合理的に処理するようにしました。
学習コストは最低限に
ルールは、シンプルに可視化により組織全員が共通認識をとれるようにする為のルール（＝小さな学習コスト）だけが必要とだけ伝えていました。
結論
冒頭にも記述していますが、３か月ほど運用した時点での感想としては、本当の意味で、組織の目指すKPIに対して優先度が高いものから動けているか？というと、まだまだ伸び代を感じていますが、最初の一歩としては、よい状態をつくれたと感じています。
導入のポイント
今回、アジャイルをスケーリングした開発手法を導入するにあたり、Scrum of ScrumやLeSS・SAFeといった様々なものを参考にさせてもらったのですが、フレームワークのカタチに拘らず、そもそも自組織の課題やありたい姿と照らし合わせてシンプルに小さく適用したのがよかった気がしています。
ここまで、この記事を読まれた方は、 アジャイルをスケーリングすることに興味がある方かと思いますが、何かの参考になれば幸いです。
最後に
今回とりあげた、組織で実行するスクラムは私自身も上手く行くか不安があったものの、 チャンレンジをさせてもらって一定の次に繋がるカタチにできたかなと思っています。
このように、LIFULLでは、さまざまな新しいチャレンジに取り組みやすい環境が整っています。
LIFULLでは一緒に働く仲間を募集しています。よろしければこちらも合わせてご覧ください。
