プロダクト開発メインチームのパフォーマンスを最大化するには？　生産性の鍵「認知負荷」を下げる「Enabling Team」の在り方

サービスの完全なオーナーシップを持っているのはすごく大事

名村卓氏（以下、名村）：それをする（認知負荷を下げる）ために何をするかというと、Cognitive Load、認知負荷は見ている領域が広がると結果的にキャパシティを超えちゃうので、そもそも絶対量を減らす必要があります。ドメインフォーカスをするんだけど、そのドメインが大きすぎるとそれだけでキャパシティがオーバーフローするので、サービスのサイズやチームが見るべき領域をできるだけ最小化して、認知負荷の絶対量も最小化する必要があります。

この『Team Topologies』では「Team Firstというのを考えてサービス境界を作る」というのが一応提案されています。

チームは基本的に小さく9人ぐらい。マックスでも十数名ぐらいのチームでやって、重要なのはサービス境界を作った完全なオーナーシップをチームが持っている状態を作ることです。これは僕も経験上そのとおりだなとすごく思っています。

他のチームと連携しないと実現しないものが生まれてくると、そこで急にコミュニケーションコストがバッと上がります。他のチームの優先度と自分のチームの優先度はだいたい合わないので、優先度の調整が入るんですよね。

そこで調整が利かない時は、よりトップダウンの優先度調整が必要になって、結果としてそのチームの意思決定が重要視されなくて、オーナーシップを発揮できないというか、自分たちが「こうやりたい」と思うことができなくなって、情熱が失われます。

なので、サービスの完全なオーナーシップを持っているのはすごく大事で、そのタイプのチームを作るのが重要だなと思っています。

「Stream Aligned Team」と「Enabling Team」とは？

『Team Topologies』には4つのチームが登場するのですが、今回紹介するのはStream Aligned TeamとEnabling Teamで、今回のテーマになっているEnabling Teamのあり方をここから説明していけるといいなと思います。

Stream Aligned Teamはご存じの方もいると思いますが、プロダクトを開発しているメインのチームです。プロダクトの機能やビジネスロジックを開発しているチームで、ここでいうとStream Aligned Teamは本当に小さいチームで、そのチームの持っているサービスやドメイン領域で完結した機能の開発をしています。だいたいクロスファンクショナルチームというか、ある機能の提供に対して全責任を負っています。

なので、Stream Aligned Teamがフロントエンドもやるし、場合によってはモバイルアプリケーションもやるし、バックエンドも持っているという状態が理想的です。そのため、この小さなStream Aligned Teamに複数の能力を持たせるのもすごく大事な要素になってきます。

Enabling Teamがここで初めて出てきますが、Stream Aligned Teamは、タイムラインの1つ機能の開発がスタートして終わるまでの間、ずっとその機能やプロダクトを担当します。

Enabling Teamは、そのタイムラインの一時的な領域に入っていって一緒にプロダクトを開発しながら、例えば「新しいこのデプロイの仕組みはこうやって使うんですよ」とか「こうやるとうまくデプロイできるんですよ」みたいなものを伝授していったりします。

あとはエバンジェリスト的に新しい仕組みを投入するのに入っていって、一緒になって開発をしながらそのStream Aligned Team自体の能力を向上させていくというか、Stream Aligned Teamができることを増やしていくというのが、Enabling TeamのEnablementと呼ばれている携わり方です。

Enabling Teamの役割はいろいろな認知負荷を下げていくこと

この動きがすごくしっくりきたので、ずっとそういうことを提唱してやっているのが僕の現状です。先ほどの認知負荷の話でいうと、そもそも小さなチームがオーナーシップを持つのはすごく大変なんですね。結局、能力的にそこがすべての能力を持っていることは稀ですし、オーナーシップを持って開発するにはいろいろな技術を投入したり、いろいろな仕組みを知っている必要があるので、そこにどうしても認知負荷がかかります。

やはり小さなチームなので、メインとなるプロダクト開発が大変になってきます。Enabling Teamは、このStream Aligned Teamのパフォーマンスを最大化するためにいろいろな認知負荷を下げていくのが役割になっていると僕は認識しています。

（スライドを示して）例えば先ほどの認知負荷のところでいうと、Stream Aligned Teamにそれぞれ同じぐらいのバランスで認知負荷がかかっている場合、仕組みで解決できる余分な認知負荷をとにかく極小化したり、スキルの認知負荷を下げたりというところを目指すので、スキルがあればけっこう簡単にできるところは、そのスキルをきちんと伝授していきます。

例えばバックエンドでGoを使っている中で、「Goってこういうふうに開発をすれば、すごく楽になりますよね」みたいな、スキル的なところやノウハウ的なところも合わせて伝授していくことも重要です。そういうことをどんどんやって全体的な認知負荷のバランスを変えていくというのがいわゆるイネーブルメント（組織）がやるべきことなのかなと思っています。

なので、例えば新しい仕組みや技術の導入を一緒に実装して進めていったり、Team Cognitive Loadの軽減のためにアプリケーションデプロイの仕組みを整備したり、ふだんいろいろそこに認知負荷を使っているなと思うところがあったら、その部分をどんどん下げていったりする仕組みを投入していきます。

ほかにも、よりチームがドメインフォーカスできるようなコード生成ツールを提供して、余計なコードを書かなくてよくするなど、目指している状態のためにどうやってやっていくかというところを担うのがEnabling Teamだと思っています。

LayerXのEnabling Teamがやっていること

（スライドを示して）LayerXでEnablingとしてどんなことをやっているのかを、公開できる範囲のもので整理していきます。

例えば開発する時に、いろいろなプロセスを立ち上げないといけないとか、モノレポじゃない場合、リポジトリがいろいろなところに分散していて、ドキュメントを見てもちょっとよくわからないし、結局何を何十個クローンしてくれるんだみたいば状態はすごく認知負荷が高いです。

ローカル開発をスタートするための認知負荷も高いし、ローカル開発を起動するための認知負荷も高いので、誰でも簡単にローカル環境がサッと立ち上げられるUIを作ります。あとはTeam Cognitive Loadを意識して、できるだけみんなの認知負荷が下がるようなアーキテクチャを考えていきます。

プロダクトごとにチームがいて、プロダクトが独自のサーバーや独自のデータベースを持っていて、独自の実装を中で持っていてとなると、そのチームのCognitive Loadというか、持っているフレームワークや持っている実装の部分に対する認知負荷がどうしても高くなります。

けれども、そこをできるだけ共通化して、データドメインに対するサービスの定義はこうですよと、お互いのプロダクト間のデータを取得する時の連携手法みたいなものを統一します。ほかには、連携する時に「こういうクライアントを作って、こういう認証情報を入れてこうやってください」とするのはけっこう大変なので、そういうところを自動化して、ほとんど意識せずに他のプロダクトのデータが取れるようにするとか、そういうことを意識したアーキテクチャを提唱して進めています。

Cognitive Load的に仕組みを持って解決した事例

（スライドを示して）1つの事例を言うと、REST APIが必要になったケースがあったのですが、そういう時に現状内部的にあるGraphQLで定義しているものをREST APIで提供しようとすると、両方の知識も必要でいろいろ負担がかかります。そこに対して仕組みを用いて、GraphQLを作って、ちょっと定義すればRESTも提供されますよというものを作って、そのあたりの必要なスキルや余分なデプロイのコストを下げたりしています。

Cognitive Load的に仕組みを持って解決したり、本来スキルがすごくたくさん必要なところをスキルがなくても実現できるようにしたりしています。「（スキルが）なくても」と言うとおかしいですが、スキルが身に付くようなかたちで実現しているのが実際の事例になっています。

（スライドを示して）最近は、ChatGPTのAPIをSlackの中にMODとして生み出してみました。これでChatGPTを試すのが面倒くさいなと思っている人たちも簡単にSlackで試せるので、そういう面の負荷を下げたり、「単純に楽しい」というのもすごく大事だと思うので、そういうことをやっています。

（スライドを示して）まとめると、Enabling Teamは、どんどん成長するプロダクトで上がっていく認知負荷をできるだけ下げるために、まずは小さなチームを実現して、その小さなチームがドメインにフォーカスして開発ができる状態を目指すために動いているチームだと僕は解釈をして、そういうチームのあり方が大事だよねと常に思っている感じです。

Enablementはけっこういろいろな領域にも通用する

（スライドを示して）もう1つ言うと、Enablementはプロダクト開発の組織だけじゃなくてけっこういろいろな領域にも通用するよなと思っています。「ChatGPTがSlackで使えますよ」となると、いろいろな職種の人がそれを触ったり使ったりできたり、そういう会社全体のEnablingみたいなところもできるチームだなと思っています。

このあたりはかなり可能性があると思っていて、このEnablementという概念を取り入れると会社全体の開発速度だけじゃなく、会社全体のいろいろな速度を上げられます。組織の話でいうと、いろいろな組織に仕組み化で解決できる認知負荷が本当にいっぱいあると思うので、そういうところをどんどんEnablingしていきます。

そうして認知負荷を下げて、みんなのフォーカスをよりドメイン中心にフォーカスしたり、より本来あるべきビジネスにみんなの脳のキャパシティを振り向けていけるとすごくいいよなと思っています。ザーッと説明したんですけど、僕からのセッションはこんな感じです。

（次回へつづく）