2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
名村卓氏(以下、名村):それをする(認知負荷を下げる)ために何をするかというと、Cognitive Load、認知負荷は見ている領域が広がると結果的にキャパシティを超えちゃうので、そもそも絶対量を減らす必要があります。ドメインフォーカスをするんだけど、そのドメインが大きすぎるとそれだけでキャパシティがオーバーフローするので、サービスのサイズやチームが見るべき領域をできるだけ最小化して、認知負荷の絶対量も最小化する必要があります。
この『Team Topologies』では「Team Firstというのを考えてサービス境界を作る」というのが一応提案されています。
チームは基本的に小さく9人ぐらい。マックスでも十数名ぐらいのチームでやって、重要なのはサービス境界を作った完全なオーナーシップをチームが持っている状態を作ることです。これは僕も経験上そのとおりだなとすごく思っています。
他のチームと連携しないと実現しないものが生まれてくると、そこで急にコミュニケーションコストがバッと上がります。他のチームの優先度と自分のチームの優先度はだいたい合わないので、優先度の調整が入るんですよね。
そこで調整が利かない時は、よりトップダウンの優先度調整が必要になって、結果としてそのチームの意思決定が重要視されなくて、オーナーシップを発揮できないというか、自分たちが「こうやりたい」と思うことができなくなって、情熱が失われます。
なので、サービスの完全なオーナーシップを持っているのはすごく大事で、そのタイプのチームを作るのが重要だなと思っています。
『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は、このStream Aligned Teamのパフォーマンスを最大化するためにいろいろな認知負荷を下げていくのが役割になっていると僕は認識しています。
(スライドを示して)例えば先ほどの認知負荷のところでいうと、Stream Aligned Teamにそれぞれ同じぐらいのバランスで認知負荷がかかっている場合、仕組みで解決できる余分な認知負荷をとにかく極小化したり、スキルの認知負荷を下げたりというところを目指すので、スキルがあればけっこう簡単にできるところは、そのスキルをきちんと伝授していきます。
例えばバックエンドでGoを使っている中で、「Goってこういうふうに開発をすれば、すごく楽になりますよね」みたいな、スキル的なところやノウハウ的なところも合わせて伝授していくことも重要です。そういうことをどんどんやって全体的な認知負荷のバランスを変えていくというのがいわゆるイネーブルメント(組織)がやるべきことなのかなと思っています。
なので、例えば新しい仕組みや技術の導入を一緒に実装して進めていったり、Team Cognitive Loadの軽減のためにアプリケーションデプロイの仕組みを整備したり、ふだんいろいろそこに認知負荷を使っているなと思うところがあったら、その部分をどんどん下げていったりする仕組みを投入していきます。
ほかにも、よりチームがドメインフォーカスできるようなコード生成ツールを提供して、余計なコードを書かなくてよくするなど、目指している状態のためにどうやってやっていくかというところを担うのがEnabling Teamだと思っています。
(スライドを示して)LayerXでEnablingとしてどんなことをやっているのかを、公開できる範囲のもので整理していきます。
例えば開発する時に、いろいろなプロセスを立ち上げないといけないとか、モノレポじゃない場合、リポジトリがいろいろなところに分散していて、ドキュメントを見てもちょっとよくわからないし、結局何を何十個クローンしてくれるんだみたいば状態はすごく認知負荷が高いです。
ローカル開発をスタートするための認知負荷も高いし、ローカル開発を起動するための認知負荷も高いので、誰でも簡単にローカル環境がサッと立ち上げられるUIを作ります。あとはTeam Cognitive Loadを意識して、できるだけみんなの認知負荷が下がるようなアーキテクチャを考えていきます。
プロダクトごとにチームがいて、プロダクトが独自のサーバーや独自のデータベースを持っていて、独自の実装を中で持っていてとなると、そのチームのCognitive Loadというか、持っているフレームワークや持っている実装の部分に対する認知負荷がどうしても高くなります。
けれども、そこをできるだけ共通化して、データドメインに対するサービスの定義はこうですよと、お互いのプロダクト間のデータを取得する時の連携手法みたいなものを統一します。ほかには、連携する時に「こういうクライアントを作って、こういう認証情報を入れてこうやってください」とするのはけっこう大変なので、そういうところを自動化して、ほとんど意識せずに他のプロダクトのデータが取れるようにするとか、そういうことを意識したアーキテクチャを提唱して進めています。
(スライドを示して)1つの事例を言うと、REST APIが必要になったケースがあったのですが、そういう時に現状内部的にあるGraphQLで定義しているものをREST APIで提供しようとすると、両方の知識も必要でいろいろ負担がかかります。そこに対して仕組みを用いて、GraphQLを作って、ちょっと定義すればRESTも提供されますよというものを作って、そのあたりの必要なスキルや余分なデプロイのコストを下げたりしています。
Cognitive Load的に仕組みを持って解決したり、本来スキルがすごくたくさん必要なところをスキルがなくても実現できるようにしたりしています。「(スキルが)なくても」と言うとおかしいですが、スキルが身に付くようなかたちで実現しているのが実際の事例になっています。
(スライドを示して)最近は、ChatGPTのAPIをSlackの中にMODとして生み出してみました。これでChatGPTを試すのが面倒くさいなと思っている人たちも簡単にSlackで試せるので、そういう面の負荷を下げたり、「単純に楽しい」というのもすごく大事だと思うので、そういうことをやっています。
(スライドを示して)まとめると、Enabling Teamは、どんどん成長するプロダクトで上がっていく認知負荷をできるだけ下げるために、まずは小さなチームを実現して、その小さなチームがドメインにフォーカスして開発ができる状態を目指すために動いているチームだと僕は解釈をして、そういうチームのあり方が大事だよねと常に思っている感じです。
(スライドを示して)もう1つ言うと、Enablementはプロダクト開発の組織だけじゃなくてけっこういろいろな領域にも通用するよなと思っています。「ChatGPTがSlackで使えますよ」となると、いろいろな職種の人がそれを触ったり使ったりできたり、そういう会社全体のEnablingみたいなところもできるチームだなと思っています。
このあたりはかなり可能性があると思っていて、このEnablementという概念を取り入れると会社全体の開発速度だけじゃなく、会社全体のいろいろな速度を上げられます。組織の話でいうと、いろいろな組織に仕組み化で解決できる認知負荷が本当にいっぱいあると思うので、そういうところをどんどんEnablingしていきます。
そうして認知負荷を下げて、みんなのフォーカスをよりドメイン中心にフォーカスしたり、より本来あるべきビジネスにみんなの脳のキャパシティを振り向けていけるとすごくいいよなと思っています。ザーッと説明したんですけど、僕からのセッションはこんな感じです。
(次回へつづく)
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには