チーム編成についてどうすればもっと良くできるのか悩んでいた時期に手に取った。この本は、ソフトウェアアーキテクチャの考えを組織に適用するという逆転の発想に基づいた組織論、チーム編成の本である。そのため、マネージャーなどの人事権を持つ人はもちろんだが、開発者にこそこの本を読んでソフトウェアを設計するようにチームを設計する面白さを知ってほしいと思う。
組織構造がソフトウェアのアーキテクチャを決定づけてしまうコンウェイの法則というものがある。本書ではそれを逆手に取って、目指すべきアーキテクチャを実現するように組織編成をするという、逆コンウェイ戦略に基づき、以下の4つのチームとチーム間の3つのインタラクションモードを提示している。
4つのチーム
- ストリームアラインドチーム
- プラットフォームチーム
- イネイブリングチーム
- コンプリケイティッド・サブシステムチーム
3つのインタラクションモード
- コラボレーション
- X-as-a-Service
- ファシリティテーション
それぞれのチームとモードがどのような役割でどういう場面で使うことで効果的かを詳しく説明しているので、この本を読むことで自分達のチームのあり方を見つめ直すことができる。
この本の中で取りあげられているチーム分割の観点はソフトウェアのアーキテクチャにも通じるところがあり、得体の知れない組織論ではなく、普段のソフトウェア開発の考え方を組織論に適用すれば良いチームに近づくことができる。
例えば、ソフトウェアの設計においては、コンポーネント同士は疎結合で高凝集となるように設計するのが良いとされている。これはチームにおいても同じで、１つのドメインには１つのチームを割り当て、そのチーム同士の依存関係を疎にするように境界を設計することで、１つのチームで仕事を完結させることができ、仕事のスピードも品質も上げることができる。 そういった、どのようなソフトウェアアーキテクチャとするのが良いのかということは、当然開発者が一番よく知っていることである。つまり、良い設計をするには、開発者は組織編成や人事権に口を出さなければならない。 本書にあるように
どのサービスを構築すべきか、どのチームが構築すべきかということをマネジャーに決めてもらっているなら、それはシステムのアーキテクチャーをマネジャーに決めてもらっているのと同じだ
というほどの危機感を開発者は持つべきである。
また、本書ではチームの「認知負荷」をいかに下げるかが鍵であると説明している。認知負荷とは心理学用語で、一つの仕事に対してあれもこれも考慮しながら作業すると頭が疲れてしまう状態のことを指す。PCで言うところのメモリが一度に大量の処理をするせいでパフォーマンスが落ちているような状態とも言える。
ソフトウェアの設計の際に、1つの巨大なクラスを作るのではなく分割して適切なサイズのクラスを作る、1つのクラスには1つの責務を与える、と言うことが良いとされる。サイズが適切で、責務が明確なクラスがコードリーディングしやすいように、チームも適切な作業規模で、知識ドメインを限定してあげる方が認知負荷が低くなり全体像を理解しながらも自分の仕事に集中できるようになる。
他にも、
モノリシックアーキテクチャーかマイクロサービスアーキテクチャーを選ぶのではなく、ソフトウェアをチームの認知負荷の制限に合った形に設計するのだ。
とあるように、マイクロサービスのような流行りに飛びつくのではなく、チームのスキル状態を鑑みて慣れ親しんだアーキテクチャを選択するのも認知負荷の観点からは適切な選択と言える。もし、業務要件でどうしても新たなアーキテクチャを採用せざるを得ない場合は、事前にチーム内で学習するなど認知負荷を下げる努力をするべきだろう。
以上のような、ソフトウェア設計のベストプラクティスをチーム設計に適用することで、良いチームに近づけるということを本書は教えてくれていると思う。
