「職能横断チーム」の実践におけるアンチパターンと対策

近年のアジャイルムーブメントにおいて「職能横断チーム」は当たり前の概念になっています。ユーザーに価値を届けるのに必要なあらゆる機能をチームが備え自律的にコントロールすることで、リードタイムを短縮するとともに、イノベーションが起こりやすい環境を作ることができます。しかしながら、7〜8人を超える大きめの集団になってくると、開発の効率を著しく下げるアンチパターンを踏んでしまうことがあります。

「職能横断チーム」の実践におけるアンチパターン

そのアンチパターンとは「いつも全員一緒」です。バックエンドエンジニアだろうとアプリエンジニアだろうと、デザイナーだろうとプランナーだろうと関係なくとにかく全員です。サイロ化のカウンターとしての「職能横断チーム」に囚われ過ぎてしまって、チーム内に部分集合を作ることを極端に避けてしまっている状態です。その結果、10人もいる会を開いて細かい相談で時間が伸びたり、そもそも深い相談の場を持てなかったり、ひとつのカンバンに全員の情報が載ってわけがわからなくなったり、というトラブルをよく目にします。

特にミーティングの観点では、リモート化によって会が有効に機能する人数の上限が下がっている印象があり、このアンチパターンの被害は拡大していると感じます。僕の同僚も「雪見だいふく2袋ルール」（つまり4人）というのを提唱していて強く同意します。

普通に考えると、2、3人しか関係ない話に全員を拘束するのはどう考えても非効率なのですが、このアンチパターンでは職能横断という言葉が逆に呪いとなってチームを硬直させます。アジャイルを実践するという善意から生まれた状況なので、おかしいと思っても反論しづらい側面があります。うまくやらないと、職能横断チームを否定するんですか？アジャイルがんばるんじゃないんですか？と衝突が起こってしまいます。

望ましいマインド

こうした極端な考え方に陥ってしまったときは大元の目的に立ち戻るのが有効でしょう。我々が一番達成したいことはなんでしょうか。それはバリューストリームを最適化することだと考えます。チームが幸福で、ユーザーに早く多く価値が届くことが何よりも重要です。「職能横断チーム」はそのための有力な手段のひとつに過ぎませんし、適用する塩梅はチームに合わせてうまくカスタマイズしていく必要があります。一歩引いた目線で、「いつも全員一緒」が本当にバリューストリームを最適にしているかを考えてみると良いでしょう。

そうして実際にバリューストリームを分析していくと、一部のメンバーに特化したパートが必ずと言って良いほど現れることでしょう。例えば、リファインメント（ないし設計）の場が充実していれば、エンジニアとPO・プランナーが常に一緒である必要はないかもしれません。それよりも、エンジニアリングに特化したカンバンや相談の場があったほうが、バリューストリームはスムーズに流れるかもしれません。こういう分析をしていくと、全員が一緒にいなければいけない場面が思いのほか少ないとわかってくるはずです。というか、もしそれで本当に全員いつも一緒にいる必要があるとわかったら別の課題があるように思います。逆にもっと深く関わるべきだったコミュニケーションパスもたくさん見つかるはずです。

「いつも全員一緒」はソフトウェアで言えばmain関数に全ての処理を書いている状態で、もっとチームやコミュニケーションの構造を掘り下げる余地があると思います。いま1チームだと思っている集団の中で、どんな部分集合が価値を生み出しているか、その部分集合同士がどのように通信をするのかを、色々な絵を描いて掘り下げてみると面白い知見が得られるはずです。

FAQ

最後に、こういう話をするときの想定FAQをまとめて変化の助けとします。

Q. とはいえ全員に共有したい話題もあります

1. 全員が集まる場を無くせと言っているのではありません。必要ならやったら良いです。わたしのチームでも、毎日15分は全員（15人ほど）が集まって同期を取る時間があります。ただ、それに引っ張られて全てのアジェンダを全員で消化するのは違うと思います。全員が集まる場ではそこでしか解決できない話題に限るべきだと思います。

Q. 開発の状況が見えづらくなって不安です

1. まずは本当に細かく状況を知るべきか検討しましょう。たとえばスクラムでは、リファインメントによって今後の計画を、スプリントレビューで開発の成果を知ることができます。それ以上の解像度で恒常的に開発状況を把握する必要があるとしたら、それは別の課題のサインかもしれません。また、同期的な共有をしないまでも、ひと目で開発の状況を把握できるようなカンバンを運用できていれば十分かもしれません。リリース間近のような特殊な状況では専用のミーティングを用意するのも良いでしょう。

Q. 情報格差が生まれるのが心配です

1. 大規模チームでリーダーだけの会などを開くようになると生まれる懸念だと思います。これに関しては話すべきことを話せないよりはマシなので諦めましょう。議事録を透明化したり、別途サマリーを共有する場を設けたりすると良いと思います。

Q. イノベーションが阻害されませんか

1. これは難しい話題ですが、それにしても全員で一堂に会するのは筋の悪い解決策であると思います。リモート会議なら尚更ですが、全員いたところで発話できるのは数人なのでアイディアは集まりませんし広がりません。もし全く新しいものを生み出したいなら、デザインスプリントのような仕組みを利用して、各職種から人をピックアップしてタスクフォースを組んだりするほうが効果が高いと思います。日常的なちょっとした創意工夫を期待しているなら、プロセスを整理した後も職種横断のコミュニケーションは続くはずなので心配はないように思います。

Q. チーム内の部分集合がうまく見つかりません

1. 基本的には、職種やフィーチャーなど、バリューストリームの中の主要なパートに着目すると見つかるはずなので頑張って探してくださいとしか言えません。たまに同じ役割のエンジニアが10人も20人も横並びになっていて困っているケースがあり、それは難しい問題です。どうしてそんなことになるまで放っておいたんだ！！というのが正直な感想ですが、そうなってしまったものは仕方ありません。まずは能力が均等になるように小グループに分けるだけでもマシになるのではないでしょうか（わたし自身も解決の経験がなく当て勘で言っています）。長期的には、チームトポロジーで議論されているようなやり方でチームとアーキテクチャを分割したり、大規模スクラムを導入したりといったことを検討するのが正道になるでしょうか。

Q. たまーに話題があるコミュニケーションパスはどうしたらよいですか

1. 話題があるときだけ自由に参加できる形にしたり、ワンショットで会話の場を設定したら良いと思います。コミュニケーション設計は、いつも集まるか集まらないかの二元論ではありません。

以上！バリューストリームを最適化してハイパフォーマンスな職能横断チームを作っていきましょう。