認知負荷の拡大、チーム間の衝突、ステークホルダーとの関わり──組織拡大の過程にあった3つの課題
組織を拡大する上での苦労や課題を渡邉氏が質問すると、森鳰氏は「3つの課題がありました」と続けた。
第1の課題はサービス拡大に伴う認知負荷の増加だ。アジャイル内製センターは、サービス拡大のためにメンバーを増員しながら活動してきた。開発人員が増えてプロダクトも成長していく一方で、開発側の認知負荷が増加していく問題が発生した。「メンバーを増やしてもシステムが複雑化していくため、チームで扱っているドメインの領域が広がり、考えるべきこと、知るべきことが増えてしまった」と当時のチームの状態を振り返る。
この状況を打破するため、森鳰氏たちはチームを分解し、特定のユーザータイプに注力できる環境をつくりチームを再構成した。
図に表すと簡単に見えるが、「実態はドメインの戦略的部分を一つ一つ丁寧に整理する必要があった」と森鳰氏は明かす。例えば依存関係の整理はその1つ。「どこに境界を設けるべきか、どのチームがどのドメインを持つべきかなどについて一つ一つ議論して切り替えていきました」（森鳰氏）
こうして認知負荷の課題は緩和したが、チームを切り分け、数が増えたことで、「チーム間の衝突が増えてしまった」と森鳰氏は話す。これが第2の課題だ。「特に我々の場合は、各チームが自律してリリースまでを担当する。このような自律性が高いチーム同士の場合、さらに衝突が起きやすい可能性がある」と森鳰氏は言う。
いくらドメインの境界を設けても、他のチームの協力がないと実現できないものの場合、優先度が衝突する。また、他チームの意思決定に対する納得性は低くなりがちだ。技術選定はその代表例だろう。さらに、所属チーム以外に関心が薄れてしまうということもある。
このような自律性の重視による課題に似た話として、森鳰氏は「仕事のやり方に一貫性がないと人材の異動は難しくなり、悪化すると一つの組織で動いている感じがしなくなる」というSpotifyモデルに対する批判を紹介。「他のチームに異動しづらくなることは、組織のサイロ化が避けられなくなり、チームの学習も妨げられるなどの副作用がある。それが問題だと感じていました」（森鳰氏）
そこで森鳰氏は、なぜ自律性を重視すると、仕事のやり方に一貫性がなくなるなど、弊害を引き起こしてしまうのか、仮説を立てて検証していった。
立てた仮説は2つ。1つは自律性の意味することがチームごとに異なること。もう1つは各チームの自律性で網羅されていない組織の課題があることだ。検証方法として採用したのは、デリゲーションポーカーの考えをベースとした、チーム自体の権限を整理する方法だ。「デリゲーションポーカーは7つのレベルで権限を切り替えて合意をとっていくが、私たちは4つぐらいに絞って行いました」（森鳰氏）
具体的には「チーム内で決められること」「チーム間で合意が必要なこと」「決められないこと」「チームの自律性によって実現しないもの（暗黙知、属人性）」の4つである。「チーム間で認識が揃っていないことを、きちんと揃えていき、揃っていることを確認していきました」（森鳰氏）
揃っていないことが確認されていくことで、良いこともあった。「チームに求められる能力や権限、スキルなどが明らかになったので、例えば組織を拡大するために新しくチームを増やす場合、チームとして成立する条件の目安になりました」（森鳰氏）
一方で、統一による制約はチームの自由度を下げることにもなる。例えば組織で使う言語をPythonに限定したとする。プラスの側面としては、Pythonに関する1つの改善が全チームに影響するため、チーム数分の効果が得られる。一方、Pythonしか使えないのであれば、「辞めます」という人が出てくるかもしれない。
オライリーの『エンジニアリング統括責任者の手引き』に、「働き方にはそれぞれ多くの暗黙のトレードオフがあり、そうしたトレードオフのプロセスにフラストレーションを感じている人には見えていないことが多い」と記されているように、フラストレーションを感じている人は負の側面ばかり見えてしまうからだ。
これを防ぐ方法として、森鳰氏が挙げたのが、権限整理のプロセスにメンバーを参加させること。そうすることで納得感が得られ、制約の意図が理解できるようになる。
第3の課題はステークホルダー（事業部）との関わりだ。「内製している企業の中には、事業部からの受注関係になってしまっているケースもあるのではないか」と森鳰氏は問いかける。実際、森鳰氏のチームもそういう状況に陥っていた。というのも、当時は開発の優先度が事業部側の課長に委ねられており、チーム側で立てたプロダクトオーナー（PO）は、開発チームとの調整役だったという。
この状況を解消するために、まずは事業部からPOやエンジニアを出してもらってチームを構成。社外の内製開発チームの交流会に事業部のメンバーを招待したり、カンファレンス登壇に同行してもらったり、スクラムワークショップに一緒に参加してもらった。こうすることで、最終的には事業部の課長を含む開発チーム全体で、共通言語を持ちプロダクトを議論することができるようになった。
