こんにちは。ノートチームPdMのさいとうです。昔からファシリテーションに関心があります。
チームが大きくなるほど「全員で話す」は機能しない
プロダクトも人も増えるほど、「全員で話す」は機能しなくなります。けれど、「小さく分ける」だけでもうまくいかない。ルクミーの基本機能を担当するノートチームでは、このジレンマと向き合っています。
規模が大きくなると、会議の話題は広がりすぎる。一人ひとりが関心を持てる範囲を超える。横断の問題が起きたとき、合意形成がなかなか進まない。 かといって会議を増やせば、開発に使える時間が削れる。会議は増やしたいし、減らしたい。
このジレンマは、きれいには解けません。外部のベストプラクティスをそのまま持ち込んでうまくいくものでもありません。
だからこそ、チーム内の情報流通とコミュニケーションの設計は大規模チームには効果があると感じています。この記事では、大規模チームの会議体設計と振り返りの実践について紹介します。
ノートチームの紹介
ユニファが提供する「ルクミー」は、保育ICT&保育AIのトータルサービスです。その中でノートチームは、共通基盤を除いた、いわゆる「保育業務の基本機能」を担っています。
「基本機能」と聞くとシンプルに聞こえるかもしれませんが、保育園が抱える業務範囲は広く、ノートチームが担当する6つのプロダクトと2つのモバイルアプリは、次のような役割を果たしています。
- 園児の日々の生活の記録
- 保護者への情報発信
- 先生と保護者とのコミュニケーション
- 保育記録の書類作成
- 保護者からの情報収集
これらのプロダクト群に関わるメンバーは、兼務も含めて19名。サーバサイドエンジニア、モバイルエンジニア、デザイナー、QA、EM、PdMが、6つのプロダクトと2つのモバイルアプリに関わっています。
サービス立ち上げ当初は、サーバサイド・ToB（先生向けアプリ）・ToC（保護者向けアプリ）それぞれにPdMが立ち、各チームが独立して開発を進めたものの、現在はその3チームを「ノートチーム」という大きなチームに体制が変わっています。
なぜチームを分けるのか：関心の分離の必要性とその副作用
プロダクトチームにとって関心の分離は、限りある認知コストの節約であり、スピードの源泉として重要な考え方です。
マシュー・スケルトンとマニュエル・パイスによって提唱されたチームトポロジーの出発点は、チームが扱える認知負荷には上限があるという考え方です。人間の認知能力には限界があり、チームも同様です。担当する領域が広がりすぎると、チームは「深く考える」ではなく「こなす」モードに移行します。これが品質低下・スピード低下の根本原因だと論じています。
| 種類 | 内容 | 理想 |
|---|---|---|
| 本質的負荷 | ドメインの複雑さそのもの（保育業務の知識など） | できるだけ深く持つ |
| 付随的負荷 | 技術的な実装の複雑さ（インフラ・ツールなど） | プラットフォームチームが吸収する |
| 外来的負荷 | 本来不要な複雑さ（調整コスト・割り込みなど） | 極力排除する |
担当する領域を絞ることで、一人ひとりが深く考えられる。不要な情報に引っ張られず、目の前の課題に集中できる。大人数の開発チームにとって、「分ける」ことは善であり、欠かせない設計です。
ただし副作用として、「横の摩擦」が必ず出ます。ノートチームでは、こうした課題が日々の困りごととして顕在化している状態がありました。
- プロダクトをまたぐ不具合調査が進みにくい——どちらの担当か判断が難しい問題が、宙に浮きやすい
- サーバサイドとアプリをまたぐ機能開発で、設計の議論が噛み合わない——前提の共有に時間がかかる
チームを分けることでスピードを得ても、横断の摩擦があればスピードは落ちます。分割するからこそ横の連携は重要です。
ノートチーム会議体の設計：全体会議と分科会
ノートチームの中の連携を設計するにあたって、ノートチームの全体会議では3つの原則を意識しています。
① 全体会議は「意思決定」ではなく「情報流通」の場にする
全体会議に意思決定を持ち込むと、会議が重くなります。情報共有がメインの場は、30分枠でも基本15分で終える。決めなければいけないことは、関係者が揃う別の場で話す。
意思決定を同期しない分、情報流通はより手厚くした方が良いのではと感じることもありますが、会議進行のバランスは常に試行錯誤しています。
② 深掘りは分科会へ逃がす
プロダクト間の開発のスケジュール調整はシビアです。デザイナーやQAメンバーが複数プロダクトの開発案件を兼務していること、バックエンドのリポジトリをプロダクト間で共有していることもあり、スケジュール調整が頻繁に発生します。
そこで複雑な調整や進捗共有はPdM・EM・QAなどの中心メンバーが担い、分科会の中でコンフリクトの解消を図っています。それにより、全体会議の役割を小さく保つこと、メンバーの認知負荷を高めないことを意識しています。
③ チームの課題が変われば分科会構成も変えていく
昨年からモバイルチームのテックリードとの間の連携を強めるために分科会を増やしました。日頃の業務で話しきれないことがあれば定例化して、役割を果たしたら頻度を減らしたり解散して、会議体構成は固定化させずに変化するものと考えています。
会議体の全体像
会議体と情報の流れを整えることで、リーダー層同士・異職種同士の連携を強化する効果がありました。プロダクトが抱える根深い問題に対してエンジニア同士が協力して問題の特定・解決策の立案をしやすい空気感が生まれ、解決策が確立せず眠っていた課題の解決が進みました。一定の成果が出る一方で、メンバーとして関わるエンジニアの開発者体験が変わらない課題も残りました。
19人でKPT：非同期・分散型の振り返りで他チームの思いを見える化する
追加機能開発のMTGの中で、「相手のチームがどう考えているか、わからない」「だから決められない」という会話がいろいろな場面で見られました。
ノートチームの開発は各担当者の単体では成り立たず、サーバサイドと2つのモバイルアプリがセットになって初めて顧客へ価値を提供できるプロダクトです。全体感を見通す難易度が高く、関心の分離により自律的に決められる余地が小さくなる難しい構造にあります。
リーダー間の連携だけでは、実際に開発の手を動かすメンバーの開発者体験は向上できない、そういうブロッカーが見えてきました。しかし会議への参加メンバーを増やすことも現実的ではないですし、別の工夫が必要だと考えました。
施策：ふりかえり用のホワイトボード
ユニファでは半期に一度、Dev本部キックオフとして開発部のメンバーが集まる会があり、その中でチームのWin-Sessionを発表する機会があります。この機会を活かして、昨年初めて、ノートチーム全体での振り返りに挑戦しました。
通常、振り返りはチームを構成するメンバー内で、同期的に時間を取って行うものですが、19人での振り返りとなるとそうはいきません。そこで、非同期と同期のハイブリッドで取り組みました。
取り組み方：
- ふりかえり用のホワイトボードを用意して、各自が記入する（非同期）
- 各チームの定例会議で各々が出したふせんを読み、まだ書いてない人へ記入を促す（同期・分散）
- 全体会議でふせんを眺める（全体・同期）
- 筋の良さそうなふせんをピックアップして、深掘りして改善策を議論する
- 各チームの定例会議へ全体会議の議論を共有する（同期・分散）
成果：
短期的に成果が出ることを期待したわけではないのですが、この振り返り後の議論をきっかけに、モバイルエンジニアとデザイナーの間に共有Slackチャンネルが生まれました。
メンバーはお互いにプロフェッショナルなので、当事者同士が同じ方向を向いて話せれば物事は前に進みます。
チームの課題に対してPdMの担うべき役割は、課題解決や調整、伝言や翻訳ではなく、当事者同士のコミュニケーションのお膳立てに尽きると感じる出来事でした。
まとめ：大きなチームの難しさに向き合いながら、ともに成熟するプロセスに向き合いたい
大規模プロダクト開発の難しさの理由の一つは、誰もがプロダクトの全体像を把握できないこと、そのため物事に対する価値判断や良かれと思う解決策が立場によって異なることにあります。
スクラムガイドでは、アジャイルソフトウェア開発宣言が提唱する「プロセスやツールよりも個人と対話を」「計画に従うことよりも変化への対応を」の思想に則って、経験主義（透明性・検査・適応）のプロセスを実現するための具体的な仕組みが提唱されています。
ノートチームが扱っているプロダクトの性質やチーム構成・規模感との相性から、スクラムの具体の手段を適用しづらく、具体的な困りごとへの打ち手を出しにくいことが悩みでした。ですが私たちの文脈に合う正解をまだ誰も知らないからこそ、当事者同士が一緒に考える機会を小さく業務の中に実装することには価値があると考えて、チームを運営しています。
事業目的は家族の幸せを生み出す社会インフラとなる、価値あるソフトウェアを生み出すこと。そのための最良のアーキテクチャ・要求・設計をともにつくり出すために、私たちはチームとして何ができる？ チームの探索は続きます。
