認知負荷とエンジニアリング組織論 〜チーム・トポロジーをじっくり読む〜
こんにちは、コインチェックCTO室の大村です。
突然ですが、私はコインチェックに転職して一番びっくりしたことは、認知負荷という難解なワードが、極めてカジュアルに利用されていることでした。
言葉のニュアンスは理解できるのですが、「〜〜は認知負荷を高めるのでやめよう」とか「〜〜の認知負荷を軽減しよう」という会話が日常的にに交わされているのは、かなりカルチャーショックでした。
私は監査系の大企業から転職してきたので、何をするにも重厚長大な承認プロセスを通さねばならず、部門間最適という概念など存在しないことが半ば当たり前だと思って働いてきました。
認知負荷を抑えた組織設計にするべきだという、エンジニアリング組織としてのあるべき姿を常に考えながら行動できるメンバーが多いところは、コインチェックの魅力の1つですね。
1. エンジニアリング組織論におけるチームファースト
1-1. Team-First thinking
チーム・トポロジーは、フロー効率を高めるためのエンジニアリング組織の設計について、多くの示唆に富んだ提言を行っています。コンウェイの法則とか、チームのインタラクションモードなど、今やエンジニアリング組織論の定石になっていますね。
チーム・トポロジーの全容を把握したい方は、訳者であり高明なアジャイル実践者でもあられる吉羽さんの素晴らしいサマリ資料をご覧ください。また、チームトポロジーの著者陣がキーコンセプトのサマリサイトを作ってくれたりもしていますのでそちらもぜひご参照ください
さて、チーム・トポロジーの第三章は"Team-First thinking"と銘打たれています。この章では、有効な開発組織を作る上で、個人ではなくチームを最小単位と考えることの重要性が語られます。
能力の高い個人を集めるだけではなく、まとまったチームとしてのパフォーマンスを最大化することに注力した方が生産性の向上に寄与することを証明した研究は枚挙に遑がありません。ここでは1つ、リファレンスとしてGoogle のre:Workを引用します。ちなみにre:Workは、Googleがeffectiveなチームを作るためにどのような工夫を行っているかを無料で公開している非常に有用なサイトなのでぜひご覧になってみてください。
2年以上にわたり、Googleの従業員（Googlers）と200回以上のインタビューを行い、180以上のアクティブなGoogleチームの250以上の属性を調べました。
私たちは完璧なチームを構成するために必要な個人の特性やスキルの理想的な組み合わせを見つける自信がありました。
すなわち、ローズ奨学生1人、外向的な人2人、AngularJSを使いこなせるエンジニア1人、博士号保持者1人を組み合わせれば、ドリームチームができると思っていました。
しかし、私たちは大きな誤りを犯しました。
チームに誰がいるかよりも、チームメンバー同士がどのように相互作用し、作業を構造化し、それぞれの貢献を見るかが重要であることがわかりました。
Agileフレームワークとしてデファクトスタンダードであるスクラムも、チームが自己組織化し継続的なカイゼン活動を担うことを推奨します。エンジニアリング組織論において、チームファーストアプローチは必須であると言えるでしょう。
1-2. チームにおける適切な認知負荷設計の重要性
ここからは、開発チームがパフォーマンスを最大化するために、チームが対峙する認知負荷をどのように設計するべきかを検討していきます。
チーム・トポロジーで提示される通り、認知負荷は3つに分けて考える必要があります。この分類はSwellerの認知負荷理論の基本ですが、日本語で紹介されている文献やポスト/資料をみると言及が少ないので、きちんと紹介させてください。
1. 課題内在性負荷 intrinsic cognitive load
タスク自体に固有の認知負荷であり、複雑さや処理する情報量に基づいています。この種類の認知負荷は減らすことはできませんが、複雑なタスクをより管理しやすいステップに分割することで制御することができます。
2. 課題外在性負荷 extraneous cognitive load
タスクの外部要因、例えば関係ない情報や混乱したインターフェースによって引き起こされる認知負荷です。この種類の認知負荷は、不要な情報を排除し、直感的で使いやすいインターフェースを設計することで減らすことができます。
3. 学習関連負荷 germane cognitive load
学習や問題解決に必要な認知負荷であり、新しい情報を既存の知識構造に積極的に処理・統合することを含みます。この種類の認知負荷は、学習体験を課題に挑戦的でありながら、学習者が積極的に関わることを促すような設計をすることで増やすことができます。
https://www.jstage.jst.go.jp/article/jsaialst/76/0/76_02/_pdf/-char/ja
認知負荷理論は前提として、人間は後天的に学習するあらゆる事象は感覚記憶→作業記憶(ワーキングメモリ)→長期記憶というパスを通じて摂取する必要があるとします。
このワーキングメモリは、あらゆる意識的な活動が行われる場所なのですが、困ったことに20〜40秒程度しか情報を保持しておくことができず、しかもその容量は成長と共に増えたりしません。また、複数の要素を並行処理することが非常に苦手で、過負荷をかけるとあっという間にパンクしてしまいます。
ゆえに、個人が効率的に情報処理を行うためにはワーキングメモリにかかる認知負荷を適切に設計することが不可欠になります。
そして、チームが人の集まりである以上、チームにかかる認知負荷も適切に設計されていることが、効率的なパフォーマンスを発揮する上では極めて重要なのです。
2. 開発チームにおける認知負荷のあるべき姿
認知負荷理論では、それぞれの認知負荷に対して以下の対応が推薦されます。
1. 課題内在性負荷：細かく分けて、プロセスできる単純さに分解する
2.課題外在性負荷：最小限に減らす
3.学習関連負荷：2を減らして、最大限増やす
ここからは、それぞれの認知負荷に対する適切な対応を、開発チームの場合に引きつけて考えてみましょう。
2-1. 課題内在性負荷：細かく分けて、プロセスできる単純さに分解する
これはタスク自体に固有の認知負荷のことなので、それ自体を削減したりすることはできません。例えばですが、英語の文法を勉強したい時、英語の文法を勝手に単純化したりとか、自分が不要だと思うところを勝手に飛ばしたりはできませんよね。これは、英文法というドメイン自体の固有な複雑性がもたらす認知負荷なのです。
課題内在性負荷に対応する際には、摂取するタスクや情報を可能な限り単純化していくことが必要です。例えば、英文法を単語→発音→文型、のように体系立てて一つずつ摂取していくことは、課題内在性負荷を削減する有効な方法です。
エンジニアリング組織論の文脈では、課題内在性負荷はチームが担当しているドメイン領域の広範さや複雑さに相当します。下記リンクでは、ドメインベースでチーム組成する際のベスプラを紹介しています。
チーム・トポロジーでは、チームが担当するサブシステム領域やドメインの数を制限することが推奨されています。具体的にはシンプルなものであれば2〜3、複雑なものであれば1つと記載があります。また、チームの認知負荷のキャパシティに適合した責任分界点の設計が推薦されます。これは逆コンウェイ戦略に近いアプローチだと言えそうです。
チーム・トポロジーの4つのチーム分類におけるストリームアラインドチームは、職能横断型でビジネスフローに沿って要求定義からリリースまでを完結できるようなチーム形態を提唱しています。これは、スクラムにおけるスクラムチームの構成要件や、（ビジネスフローか特定機能かという要求工程における違いはあるにせよ）フィーチャーチームの構成要件とほとんど同じです。
https://www.visual-paradigm.com/scrum/feature-team-vs-component-team-in-agile/より
コンポーネントチーム（機能別）は、相対する必要のあるビジネスドメインが複雑になるため、どうしても課題内在性負荷を大きくしてしまいます。エンジニアリング組織のベストプラクティスとしては、やはりビジネスロジック（フロー）や特定の機能ベースで機能横断型のチームを組成することになると言えるでしょう。
2-2. 課題外在性負荷：最小限に減らす
課題外在性負荷は文字通り、課題に関係のない情報や煩雑なインターフェースがもたらす不必要な認知負荷のことです。これは、引き続き英文法で例えるとすれば、参考書のフォントが１ページごとに変わっているとか、気持ち悪いキャラクターが出てきていちいち関係のないコメントを挟んでくるとか、単純に環境の雑音がすごいとか、そういったことになります。
課題外在性負荷への正しい対応は、可能な限り減らすことです。インターフェースの統一性を高め、コミュニケーションノイズを最小限に抑えること。これにつきます。これは、個人でも開発チームでも全く同じです。
さて、私なりに少しチーム・トポロジーの内容を拡大して解釈すると、チーム・トポロジーの4つのチーム分類におけるイネーブルメントチームは課題外在性負荷の軽減への責任も負っていると思います。
イネーブルメントはドメインやテック領域への理解をサポートする役割と定義（課題内在性負荷削減のサポート）されますが、私としてはチームにとってノイズになりうるあらゆる認知負荷の探索と撃破への責任を負っていると考えています。LayerXさんやTimeeさんみたいな素敵なイネーブルメントチームをコインチェックでも作りたいですね！
2-3. 学習関連負荷： 課題外在性負荷を減らして、最大限増やす
学習関連負荷は新しい情報やタスクを、長期記憶の中に関連づけて取り込む際の負荷です。続けて英文法で例えるとすれば、英語のアルファベットをひらがなやカタカナの体系との対照で記憶したり、音素を日本語と関連付けながら摂取していく際にワーキングメモリーにかかる負荷のことです。
長期記憶はスキーマやスクリプトと呼ばれる関連構造、すなわちネットワークを持ちます。ワーキングメモリーを長期記憶に組み込むためには、既存のスキーマやスクリプトにそのタスクや情報を位置付ける必要があります。
学習関連負荷は、開発チームにおいては最も付加価値を生むタスクの処理に関連するものになります。例えば、チームの相対しているドメインに新しい付加価値を付与するために、他のドメインから持ってきたナレッジを適用するとか、他のチームのメンバーの知恵を借りて適用できそうな部分を探すとか、そういった高度な学習活動がここに分類されます。
開発チームとしては、課題外在性負荷を極力減らして、学習関連負荷に割くことができる余力を増やすことが大切になります。
3. まとめと考察
3.1 まとめ
エンジニアリング組織論においては、チームファーストでパフォーマンスを最大化する思考が肝要です。その上で、チームに対する認知負荷をどのようにコントロールするべきかを提示しました。
課題それ自体に内在する課題内在性負荷は、細かく刻んでわかりやすくする。これはコンポーネントチームからストリームアラインド/フィーチャーチームへの移行や、ドメインの制限などが対処として挙げられます。
課題と関係のないところに存在する課題外在性負荷は、とにかく減らす。プロセスに対するノイズでしかないので、UIは分かりやすく統一するとか、ドキュメントのフォーマットを揃えるとか、そういう地道な作業をイネーブルメント活動の一環として行う必要があります。
課題に取り組むために必要な知識を長期記憶のスキーマやストリームに組み込む際の学習関連負荷は、価値発揮のための最も重要なプロセスに充当するために最大化する必要があります。知識の補充や探求、そして適用は開発チームの生産性を上げる上で最も重要なプロセスになるわけです。
3.2 考察①：脳は情報に対してマゾヒズムである
ここから先は私が独自にチーム・トポロジーの内容を受けて議論を展開します。
複雑なドメインを複数持っているチームのメンバーは、対応する課題やタスクを切り替えるだけでコンテキストスイッチのコストが発生します。複数ドメイン/プロジェクトへのアサインが人の生産性をどれだけ下げるのかについては豊富な先行研究がありますのでそちらに譲ります。Atlassianのこちらの記事がとても参考になります。
私の関心は、肝心の我々人間の側はそうした状況をどのように感じるのか、という点にあります。確かに脳はこのようなコンテキストスイッチを疲労に感じ、生産性を下げることはよくわかっています。認知負荷の増大というのも、経験的に納得感が高いです。
一方で、私たちは、Slackの未読を消化し、Twitterのタイムラインを更新し、読みかけの本を数ページめくり、買い忘れていた消費財の購入ページをamazonでスクロールし、書き途中のブログ記事を少し進めて、ふと気になったワードをブラウザで検索し…というとんでもないコンテクストスイッチを、ごく自然に、日常的に行なっています。それも、取り憑かれたように。
Slackを追いかけて、コンテクストの全く違う会議に2〜3個出席でもすれば、「あ〜疲れた。なんだか今日はいい仕事したなぁ〜」くらいに感じませんか？あるいは、Twitterのフィードを眺めてBlog記事を4〜5個くらい斜め読みしたら、夕方くらいになっていてなんとなく疲労感が溜まっている、ということはありませんか？書いてみると、生産性がなくとても虚しい行為に思えますが、私たちはこういう1日を相当な頻度で過ごしてしまいます。（え、もしかして私だけでしょうか？）
それは、私たち人間にとって新しい情報の摂取が報酬刺激として作用し、学習された快楽が新たな情報の摂取へと駆り立てる中毒的な症状をもたらすからなのです。それが例え非生産的で虚しい行為であると知っていても、アルコールやギャンブルへの依存と全く同じメカニズムで情報への依存が発生しているのです。
3.3 考察②：スキナー箱と情報中毒のネズミ
徹底行動心理学の開祖であるスキナーは、動物の自発的な行動強化を体系立てて説明するオペラント条件付けという理論を組み立てました。特定の行動（オペラント行動）をとった場合に正/負の報酬（強化刺激）を与えることで、特定の行動の学習を説明する理論です。
ネズミはレバーを引く動作を学習する
スキナーが白眉であった点は、特定の行動を学習する際に、常に強化刺激が提供される場合よりも、強化刺激が提供される場合とそうでない場合が混在している方が、行動が積極的になり継続的になることを証明した点です。これを間欠強化と呼びます。ギャンブルやストーキングへの依存を説明する際によく引き合いに出されますね。
情報の摂取というのはまさに、この間欠強化によって学習された行動なのです。Slackをアクティブにしても、自分になんのメンションも飛んでいない場合もあれば、そうでない場合もあります。Twitterのフィードを更新しても、なんの情報もない場合もあれば、とても有益なものが流れている場合もあります。いつも何の実りのない会議であっても、たまに自分の為になる情報が摂取できることがあります。そうした間欠強化のもとで、私たちは不確定な報酬である新しい情報を得たいと思ってしまうのです。
その結果として、コンテクストスイッチという行動が学習されます。当然脳は疲労しますが、アプリケーションからアプリケーションへ、会議から会議へ、SlackからTwitterへ、という情報のサーフィンは確かに人に快楽物質を与えるのです。私たちは、過剰な情報中毒の時代を生きています。
強く注釈しますが、私は個人が望んで非生産的な行動をとっているということを言いたいわけではありません。ただ、認知負荷が個人の学習された行動（コンテクストスイッチ）の結果として生じる場合があるという気付きを持つことで、改善できる組織的な課題がたくさんあるのではないかと感じているので、このように書いています。
3.4 考察③：認知の手前で情報を断つ
こうした人間観を踏まえて考えると、エンジニアリング組織論というのは、セラピーやリハビリによく似ています。チームの対応するドメインを絞ることで、プロセスする情報の絶対量を減らすこと。認知の手前で情報の絶対量を遮断するという、設計による克服です。
あらゆるエンジニアリング組織論が、”FOCUS”（集中）に力点を置くのも、組織の内外のあらゆる情報の氾濫に晒され続け、その摂取に中毒的に埋没する散漫な依存症状態を防ぐためなのではないか、と最近思っています。
当然、個人の行動としてアプリケーションを複数開かない、とか明確な優先順位づけを持ってタスクを処理する、といったベスプラがあるにせよ、それは情報摂取への依存行動を解消するための、本質的な解決にはなりません。
やはり、アーキテクチャのレベルで個人が摂取できる情報への制限をかけることが大切なのではないでしょうか。もしかすると、今後は同時に開くアプリケーションの数とか、参加できるSlackチャンネルの数とかに、ベストプラクティスが出てきたりしたら面白いですね。
おわりに
本稿ではチーム・トポロジーで紹介される認知負荷概念への適切な対処方法の検討を行いました。そして、コンテクストスイッチという認知負荷が、新しい情報を摂取するという刺激に対する強化行動として発生している可能性を考察しました。
チームがパフォーマンスを最大化する為には、エンジニアリング組織を考える人々がアーキテクチャをきちんと検討し、各チームのキャパシティに合った適切な情報量・認知負荷の設計を行うことが必要という話でした。
また、人の行動や心理への解像度を上げると、より幅広い視野でパフォーマンス改善の打ち手が見えてくることもありそうです。そうした観点で、スキナーの徹底行動主義的心理学を紹介してみました。
ありがとうございました！
この記事が気に入ったらサポートをしてみませんか？