2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
リンクをコピー
記事をブックマーク
名村卓氏(以下、名村):それをする(認知負荷を下げる)ために何をするかというと、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.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略