フィーチャーチーム移行の過程でアンチパターンを試した話

Watanabe

これはGLOBIS Advent Calendar 2022の24日目の記事です。

はじめに

こんにちは、GLOBIS 学び放題 LEDチーム💡*1でEMをしている渡辺(@mshrwtnb_)です。

今回は、2つのコンポーネントチームをチーム統合し、フィーチャーチーム化していく過程で、アンチパターンを試した体験についてお話します。そのアンチパターンとは「20人規模でスクラムを回す」というものでした。

なぜそんな無謀なことを…？

自分も最初はそう思いました。しかし、今では「当時の自分たちにとっては大事な通過点だった」と考えています。この記事ではその経緯を紹介していきます。似た境遇に置かれた開発組織の参考になったら幸いです。

背景

~2021/9 Webチーム、Appチームのコンポーネントチーム体制
2021/10 Web側の長期PJが終わる
2021/11~2022.06 フィーチャーチーム化に向けた話し合い
2022/07 方針を固める、チームに発表
2022/08 ワンチーム体制（20人規模の一つのフィーチャーチーム） スタート
2022/11 ワンチーム体制 -> 2つのフィーチャーチームに移行

元々、私たちのチームはWebチーム、Appチームの2つのチームに分かれていました。これはWeb側で長期PJが走っており、必要な人材が集められていたからでした。2021年10月、そのPJもついに終わり、「WebとAppをまたいだ学習体験を提供していきたい」という機運が高まっていきました（かなり以前からそうでした）。

当時は、POが同じ開発アイディアを2つのチームに持ち込み、それぞれで納得を得る。開発チームは各自の優先度があるなかで、依存関係にうまく対応しながらリリースを目指すなど、ハンドリングが大変でした（課題１：着想〜リリースまでの速度や手間）。

加えて、長年チームも分かれ、メンバーも固定化されていたことによる組織的傾向も出ていました（課題2: 組織のサイロ化）。その傾向はプロダクトにも現れ、WebとAppでデザインや仕様ズレが発生するなど「コンウェイの法則」の状態になっていました。

すぐに解決を目指そうとはならなかった

課題感や目指したい方向性（＝フィーチャーチーム化）を、チームメンバーに話すと「未来志向で良いですね！」「何か手伝えることありますか？」といったポジティブな反応が多く集まった一方で、ネガティブな反応も一部で出てきました。

「今のチームが機能しているのになぜ変更する必要があるのか」
→ 過去や現在に最適化してるという意味ではYes、未来に対してはNoではないか

「せっかく築き上げたチームの文化が壊れるのでは」
→ 今までのやり方と変わるだろうが、次で活かせる部分は大いにある

「人を奪われる」
→ 横の視点ではなく、全体視点で見たときにやりたいことに対して、最適な人材配置を考えたい

各論点に対して回答してきましたが、感情的対立として終わることも多々ありました。

コミットメントを引き出せる"遠回り"

半年以上に及ぶ話し合い、開発フェーズの変化もあり、課題の理解は進んでいきました。

しかし、その実現方法にNoが出ていました。原案では「20人近いメンバーを、2つのフィーチャーチームに分ける」という方法を提案していました。

フィーチャーチーム化移行プラン原案。Noが突きつけられる

言葉に表れること、表れないことを総括すると、以下のような強い想いが背景にあるのが分かってきました*2

  • 「自分たちは素晴らしいスクラムチームを作ってきた。その運営方法、仲間を失いたくない」

  • 「（小規模チーム時代のように）すべてのタスクを把握していたい。最初からチームを分けると、何かを見落としそうである」

だから「20人全員でスクラムイベントを実施することで情報やコミュニケーションを集約し、一緒に開発したい」（ワンチーム制）とのことでした。2チームのスクラムマスターが話し合い、開発プロセスを決めてくれました。

  • スクラムの運用方法は、思い入れが強いチームのほうをベースとする

  • バックエンド、フロントエンド、アプリ、デザイン全員のタスクを同じカンバンで扱う

  • 各種スクラムイベントには全員で参加する（＝コミュニケーション、情報は集約する。1つのチーム）

  • 実際の開発作業は2チームで分かれる。一つのチームがEpicを一気通貫で開発できるようフィーチャーチームとする。それぞれにSMが付く（= 開発は2チーム）

この方法のメリットとデメリットを比較しました。

  • メリット: フィーチャーチーム化、人材と文化のMixという目指したい方向性に合致している

  • デメリット: 人数・情報量的に認知負荷が高くなる、ミーティング時間の肥大化

当初、難色を示していたメンバーたちも、これはピザ2枚ルールを無視したアンチパターンと承知のうえで、限界まで試してみたいと言ってきました。

総合的に考えると、彼らが大切にしていることを尊重し、やる気やコミットメントを引き出せるなら、この遠回りも悪くない。むしろ、課題2に関しては効果的だろう、と考えるようになりました*3。

ワンチーム制スタート！大量の”課題”が出てくる

実際にやってみてどうだったか？

最初の数週間。
大小様々な”課題”が出てきました。種類としては、体制変更直後ならではの「どうしよう？」系課題が多かったように感じます。例えば、「問い合わせがきた！どっちの開発チームが持つか」、「技術領域ごとに相談したい！今まで隣にいた人が別の実装チームに移ってしまった。どの会議体で相談するのが適切か？」などです。特にこのタイミングでは、スクラムマスター陣が奮闘してくれました。

ワンチーム化から1ヶ月が経過。
良い兆しが聞こえてきます。

  • Web & Appで連携しやすくなった

  • Web & Appになったことで考えられる施策幅が広がった

  • 視野が広がった

  • セクショナリズム的な意識がなくなってきた

  • 今まで話したことがなかった仲間と近くなった

当初解決したかった「課題１：着想〜リリースまでの速度や手間」、「課題2: 組織のサイロ化」が、解決されつつあるのがわかりました！

不満は変化の材料となる

ワンチーム化から2ヶ月が経過
1on1での会話やチームを観察していくと、以下のような課題が残り続けているのが分かりました。

  • ワンチームで扱うにはEpicが多く、スプリントゴールを定めづらい

  • JIRAカンバンの情報がオーバーフローしている。タスクの全体像、進捗が追いきれない

  • 20人全員でミーティングは時間がかかりすぎる。開発要件決めやふりかえりの議論が深まらない

フィーチャーチーム化や2つのチームを統合したメリットを享受できていた一方で、大規模チームならでは課題が残っている状態となっていました。「そろそろ適切なサイズの2つのフィーチャーチームに移行できるか？」を考える時期に差し掛かってきました。

「変化の公式」（Formula for change, Change Equation）という概念があります。

不満 × ビジョン × 最初のステップ > 変化への抵抗

何か変化を起こそうとするとき、成功 or 失敗しそうか？を理解するための式です。左辺が右辺より上回っていると「変化が成功する可能性が高い」という解釈ができます。

主観的な評価にはなりますが、この時点では左辺が上回っていたように感じます。各変数を、5点評価をすると以下のような感じでしょうか。「不満」だけが突出していたように感じます。

不満 3 × ビジョン 1 × 最初のステップ 1 > 変化への抵抗 1

  • 不満(3): 大規模チームならではのデメリット。大人数では深い話ができない。ゴール、タスクが雑多で圧倒される。

  • ビジョン(1): 実現したい方向性はチームですでに共有されており、特に変化なし。

  • 最初のステップ(1): すでにワンチーム制を歩んでいる。特に変化なし。

  • 変化への抵抗(1): そろそろ2つのフィーチャーチームに移行しても問題ない、という声多数

ワンチームから2つのフィーチャーチームに移行するタイミングがやってきました。

２つのフィーチャーチームへ移行

ワンチーム化から3ヶ月目で、2つのフィーチャーチームへ移行することとしました。アンチパターン卒業です。

移行してどうだったか？

実は、特筆することがないくらい課題が出てきませんでした。ここの移行はソフトランディングできた、という評価です。

むしろ、各チームが適切な認知負荷、情報量の範囲内で話し合やすくなり、ゴールや進捗を追いやすくなりました。大きな開発目標も達成できてきました。

本当に実現したかったこと

「フィーチャーチーム化を目指したかった」と言っていたものの、本当に実現したかった（し続けたい）のは「事業やフェーズの変化に柔軟に適応する組織」です。フィーチャーチームは今最適と考える形態に過ぎません。

今後も残すものは残し、変えるべきものは変え、みんなで実験・学習していきたいと思います。

参考になった考え


*1 受講者体験開発チーム Learner Experience Development Team, 通称LEDチームです
*2 ロナルド・A・ハイフェッツ「最難関のリーダーシップ――変革をやり遂げる意志とスキル」と、ロバート・キーガン「なぜ人と組織は変われないのか――ハーバード流 自己変革の理論と実践」からTipsを得ました。人は変化そのものではなく、変化がもたらす喪失に抵抗する。人には免疫マップというメンタルモデルがあり、その一部に「強力な固定観念（Big Assumptions)」を持つ。これらを考慮しました。また、社の情緒的配慮も重要視する価値観も考慮しました。
*3 マイケル・A・ロベルト 決断の本質に、コミットメントの重要性が書かれています。意思決定の質だけでなく、推進の実効性も考慮する観点を持ちました。

この記事が気に入ったらサポートをしてみませんか？