ノーコードAI開発ツール「Node-AI」のプロダクト開発チーム(以下Node-AIチーム)は、 2024年1月から1年間採用していたLeSSでの開発体制を見直し、1チームによるスクラム体制で再出発しました。
本記事では、その背景についてご紹介します。
はじめに
こんにちは。Node-AIチームのスクラムマスター 中野と申します。
もともとはNode-AIの開発者でしたが、前任者の異動を機に、スクラムマスターに挑戦しています。 得意な分野はデータ分析や機械学習で、プロダクトに関連するログデータの分析にも取り組んでいます。
さて、Node-AIチームは2024年の1年、LeSS(Large-Scale Scrum)を採用しスクラムを運用していました。
確かに最初はうまくいく事が多かったですし、判断は間違いではなかったと考えています。
当時の状況は以下の記事で紹介していますので、ご興味があればご覧ください。
しかし、Node-AIはこの1年でさまざまな状況が変化し、 地道で小さなプロセス改善だけでは対応しきれない問題が増えていきました。
そこで年末にチーム全体で話し合い、1チームによるスクラム体制で再出発することを決定しました。
LeSSの課題
この記事は、LeSSそのものを批判する内容ではありません。 現在のNode-AIチームの状況を踏まえると「LeSSが合わなくなってきた」という理解をしています。
細かい原因はいくつかありますが、要約すると以下に帰着すると考えています。
「Node-AIチームの取り組みが多様化・高度化する中で、 小規模なフィーチャーチームごとにプロダクトバックログを消化する方法で、 ユーザー価値を最大化することが難しくなってきた」
原因1
2024年、おかげさまでNode-AIは多くのお客さまや社内営業から引き合いをいただきました。
そのため、Node-AIチームのメンバーはソフトウェア開発以外の業務にも積極的に取り組み、 要望に応えるべく全力を尽くしていました。
例えば、社内営業にNode-AIを理解してもらう勉強会や社内コミュニティの活動、 営業への同行、SNS等を活用したマーケティング活動をコンサルティングチームと協力しながら開発チームのエンジニアも含めて対応しています。
そのようなタスクは差し込みで発生することが多く、優先度を付けるのも難しいため、 プロダクトバックログとは別の場所で管理し、可視化していました。
しかしタスクによっては個人で動いているものや、 複数メンバーでローテーションを組んで対応しているもの、 実は可視化や共有が十分でなかったものなどさまざまでした。
その結果、誰が何をやっているのか把握するのが次第に難しくなっていきました。
頻繁な差し込みは頭の切り替えにも負荷がかかるため、 開発者のモチベーションや生産性にも影響を与えているという意見も出ました。
ここまではLeSSに関係なく起こり得ることですが、LeSSを採用していた影響で、 小規模な(6人以下の)フィーチャーチームにおいてメンバーが不在となるケースが増えました。
それにより「あるスプリントではフィーチャーチーム内に2人しか開発者がいない」という状況も発生し、 一時的に機能横断ではなくなるためチームが取れるプロダクトバックログに偏りが生じ、 チームごとのベロシティも安定しませんでした。
原因2
また、Node-AIは大規模で専門性の高い機能追加、ユーザー理解のための調査、 研究開発チームと協力して行う高度な機械学習アルゴリズムの実装、 安定的なサービス提供を目的としたOps強化など、 チーム全体での最適化や腰を据えたスキルトランスファー(スキトラ) が必要な取り組みを並列で進めていく必要性が増していました。
そのため、各フィーチャーチームで物事を完結するのは難しく、 スプリント内で無理が生じることも度々発生していました。
対応策として、一時的に1チームにしたり有識者を別チームに派遣するなどしていましたが、 都度調整するコミュニケーションコストも増加し、チームとして不安定な状態と言わざるを得ませんでした。
課題のまとめ
LeSS体制における課題をまとめると、以下の2点となります。
- プロダクトバックログ外のタスクの差し込みにより、各フィーチャーチームのベロシティが安定しない
- チーム横断での最適化やスキトラの必要な取り組みが増え、フィーチャーチーム個別での最適化がチーム全体の最適化とマッチしない
チーム体制変更の検討
調査と決定
上記の課題を解決するには、地道なプロセス改善だけでは難しいという意見が開発者から上がり、 チーム体制の変更で解決を目指す実験をすることをまず決定しました。
ただしチーム体制といっても多数の選択肢があるため、 まずは他社事例やフレームワークを調査し、どのような方法があるのか洗い出しました。
そして、Node-AIのメンバーで現実的に組めるチーム構成案を複数作成しました。
具体的には以下の方法です。
- プロダクトを2つのプロダクト群に分割し、2つのスクラムで別々の目標を設定する体制
- チームトポロジーの考え方にもとづく分割方法
- 1チームでスクラムを回す体制
各案を採用した場合の各チームの責務やメリット・デメリットを整理し、 メンバーの希望も加味して最終的にDevOpsの1チームスクラム体制を採用することに決定しました。
この作業はスクラムマスターが一部整理・誘導した部分もありますが、 ほとんどの検討プロセスはチーム全員で主体的に決定しました。
狙い
1チームスクラム体制を選んだ決め手の1つは、 「うまくいかなかった場合、元に戻しやすく、他の案へ柔軟に変化もさせやすい」という点です。
あまり凝ったことをしてもチーム体制変更の影響を評価しにくく、ルール決めにも体力が必要となります。
一方、1チームスクラムは過去に経験があるため、各自が勘所を把握しており、 1チームで回すこと自体に伴う新たな知識の習得やルール決めを最小限に抑えることができます。
小規模なチームですし、ダメだったら他の案にすればいいだけ、と軽く考えられます。
また、2チームに分散していた個々人のスキルを1チームにまとめることで、 課題(2)に対してタスクに集中して取り組める環境を作り、 チーム全体の最適化が進むことを狙っています。
他の構成案をベースとしてチームごとに役割を分けることでも課題の解消は可能だと思いますが、 社内の他プロダクトのネガティブな例や開発者個人のキャリア面も考慮して今回は見送りとしました。
課題(1)に関連する差し込みタスクについてはプロダクトオーナー(PO)・スクラムマスターでの巻き取りや、 後述するメンバー調整により緩和できると考えていますが、 スクラムチームのビジネスサイドとの関わりを完全に停止するのはリスクもあります。
一定量はスクラムチームに残しつつ、チーム全体での開発者稼働が極端に減る状況が常態化しないように調整していきます。
調整
Node-AIチームは現在約10人のメンバーが所属しています。
1チームだと人数が多すぎること(これがLeSSを採用した背景の1つ)や、 POへの負荷が異常に高いといった別の問題も存在していたため、 今回の課題も考慮して以下の変更も同時に実施しました。
- POとプロダクトマネージャー(PdM)を2名で分業し、PdMはスクラム外からプロダクトを支援する。
- 旧POがPdMとなり、新POは開発者から選任する。
- プロダクトバックログ以外のタスクが特に集中していた開発者2名は(同意のもと)スクラムから外れてもらい、 チームX(名称検討中)として、各自の裁量で遊撃的に動けるようにする。
これによりバックログ外のタスクをスクラムの外で独立して対応できると考えています。
変更前後の構成を図に表すと以下のようになります。
- ※ "az" "mm" はチーム名の略称です。
- ※ POの変更は以下の記事で一部紹介しています。
今後に向けて
PdMやチームXの今後の動きについては、進行しながら調整していくことになりますが、 スクラムの観点から見るとステークホルダーという位置付けになります。
引き続き、各種スクラムイベントでは密に連携していく予定です。
今後の課題としてはチーム体制変更を含むプロセス改善の効果測定を定量的に実施することです。
これまでベロシティを基準としたり、Four keys等の調査までは行ったものの、 形骸化したり導入が後手となり、結局は肌感を優先した検査・適応となっているのが実情です。
さまざまな指標をモニタリングできる環境も整いつつあるので、近いうちに検証を始めてみたいと考えています。
おわりに
1チームスクラムに移行したことで、チームが抱えていた課題が緩和されることを期待しています。
しかし、チーム体制を変更すればすべての問題が解決されるわけではありません。
今後は地道にプロセスを改善し、どうすれば最もユーザー価値を高められるのか試行錯誤していきます。
また、そもそも1チームからLeSSに移行した際には逆の課題があったわけですから、当然それが再燃することも考えられます。
その時に、再度チーム体制の変更で問題を乗り越えるのか、別の方法を取るのかは現時点では分かりません。
ただ、今回チーム全員が主体的に課題に対する手段を選択し、 変化を実現できたことはチームにとって非常に価値のある経験となりました。
引き続き、どのような変化にも対応できる強いチームを目指していきたいと思います!