yigarashiのブログ

学んだことや考えていることを書きます

高すぎる認知負荷が生むサービスの袋小路とエンジニアリングマネージャーの役割

最近流行りの「チームトポロジー」では、フローが改善するようにチームの認知負荷をコントロールすることが述べられています。そのためには組織とアーキテクチャをうまく変化させていく必要があり、いくつか主要な考え方やパターンが紹介されています。詳しく知りたい方は以下の資料を読むと良いです。

【資料公開】30分で分かった気になるチームトポロジー | Ryuzee.com

この資料は2022年3月16日の「チームトポロジーを成功させる実践方法の探求」というイベントの発表資料です。このイベントでは、上記の解説に加えて、イベント共催企業で実際にチームトポロジーを適用した様子も紹介されました。それが以下です。

チームトポロジーを成功させる実践方法の探求 - Team Topologies Study、登壇資料

課題の言語化が上手く、しかも実際に素早く変化しており、「とても敵わないな」というのが率直な感想でした。ただこの無力感をそのままにしておくのは勿体無いと思い、どうしてそんなに距離を感じるのか考えた結果、以下のように言語化されました。

高すぎる認知負荷が生むサービスの袋小路

いわゆる「服を買いに行く服がない」というやつです。一度システムが複雑化して組織や事業がそれに追いつかない状態になってしまうと、あらゆるアクションが高コストになります。チームトポロジーではドメインの節理面を見つけて組織とプロダクトを分割せよと言うのですが、真面目に分割しようとすると2年も3年もかかってしまうとか。自動化やドキュメンテーションによって認知負荷を軽減しようにも、対象のコンポーネントが多すぎてペイしないとか。そしてそんなことを言ってまごまごしているうちに普通は事業も停滞するので組織を拡大することもできない。見事な袋小路の完成です。

手堅い処置としては、プロダクトの仕様を整理してそもそもの複雑度を下げていくことが考えられます。袋小路を戻るイメージが近いかもしれません。飛び道具としては、上位レベルの判断によって大量の人を投入するとか、低コストでとんでもなく成長する施策をぶち当てるといったことが考えられます。しかしどれも難しかったり不確実性が高かったり、こんなこと考えずに済むならそれが一番だという気になってきます。

エンジニアリングマネージャーの役割

どうやったらこの袋小路に入らずに済むのか考えた時に、僕はエンジニアリングマネージャーの役割を再認識することになりました。上では袋小路の原因を、事業、組織、システムのバランスが崩れていることだと分析しました。逆にそれらの足並みが揃っていれば、システムを現実的なスピードで進化させられるし、そこに合わせて組織も変化・拡大できるし、フローが改善して事業も成長するし、とポジティブなループを期待できます。

こうしたマネジメントは、エンジニアリングマネージャーを目指す若者の戦略 - yigarashiのブログで整理した、エンジニアリングマネージャーの4領域であるテクノロジー・プロダクト・デリバリー・ピープルにまたがる大仕事になります。いわゆる"強いEM"の視座を持って取り組むことになるのでしょう。これは誰かがやらないといけない（というよりは誰かがやるともっと上手くいく余地がある）仕事であると思います。あぁ、だからエンジニアリングマネージャーが必要なのかと腹落ちしました。事業を成長させたいと思った時に、システムと開発組織を一緒に変化させる視点を持っている人がいることで、「成長し続ける事業」への道が開けるのではないかとか、そんなことを考えました。

僕はいまのところ新米の"弱いEM"で、まだここまでをコントロールできる胆力はないなーと感じます。個別にボトムアップでやれることを探したり"強いEM"と連携したり、地道に袋小路から抜け出す手を打っていこうと思います。