「Navigating Complexity of Cognitive Load in Software Product Development」という本を読んだのでメモ。 learnhow.simplification.works
認知負荷という言葉が浸透して久しいが、この記事では、認知負荷を「制限する」組織設計パタンは従来の組織構造(ピラミッド型、狭い所有権による統治)に迎合したパタンであり、組織レベルで価値提供能力を高めるための課題を解決していないのでは？ という疑問について考察する。
具体的には、認知負荷理論について軽く解説し、本書で示される2種類の組織設計パタン、技術的所有権(狭い所有権)パタンと流動的所有権(広い所有権)パタンについて利点や問題点を解説をする。
背景
LinkedIn上でチームトポロジー(TT)の著者が議論していたのを目にし、気になって投稿や一連のレスバを眺めていた。
このレスバを簡単に概要をまとめると、以下のようなものになる。
- チームトポロジーは認知負荷理論(Cognitive Load Theory、以降CLT)をチームの単位で応用している。
- CLTは「個人の学習」に対して設計されたものであり、これを「チームで働くこと」に対して適用することは議論の余地がある。
TTの著者の方自身もこの投稿はクリックベイトだと非難しつつも、CLTをチームに対して適用する是非については同意していた。
私自身も、TTの実装方法は「チームの認知負荷に合うように責任範囲を制限する」ため、DevOps以前のパラダイムであるAとBの責任(例えば実装と運用)を分割して統治する方法を再実装しているだけなのではないか？ と懐疑的に思っていた。
こうした背景から、TTに代表されるようなCLTや暗黙的にCLTに基づいた組織設計パタンがどのような課題を無意識に生じてしまうかを探求したいと思い読書をした。
注意点として、本書は解説にあたってTTや特定の設計プラクティス名は明記されておらず、あくまで私自身の関心に基づく補足である点を認識してもらいたい。 また、本文中でのTTはあくまで簡単な説明にとどめているので、関心のある方は実際の書籍を参考にしていただきたい。 www.kinokuniya.co.jp
認知負荷について
TT本でも本書でも記述されているが、認知負荷とは大きく分けて3種類のものがある。
- 課題内在性負荷: 問題領域の本質的なタスクに関するもの
- 例: ソフトウェア製品を変更するために必要な努力
- 課題外在性負荷: タスクが実施される環境に関するもの
- 例: ソフトウェア製品で何を変更するかを読み取り理解するために必要な努力
- 学習関連負荷: 学習を進めたり高性能を実現したりするうえで、特別な注意が必要なタスクに関連するもの
- 例: 永続的な知識、専門知識を発展させるために必要な努力
TT本では、課題内在性負荷、課題外在性負荷を下げていくための取り組みが必要で、学習関連負荷に使う余力を持つことが大事という主張である。 本書では、これらの認知的負荷は相互に関連しており、個別の種類のみを対処するのではなく、すべての負荷を最適化する必要があると述べている。例えば、「外在性負荷が高い状態は、ドキュメントや構造化が不十分であるため内在性負荷にも影響を及ぼす」といった具合である。
チームトポロジーにおけるCLTの適用とその懸念
背景の項目でも少し説明したが、TTはソフトウェア開発チームの構造と相互作用に関する設計に焦点を当てている。CLTを組織設計、特にチームに対して適用するアプローチを提案している。 この理由として以下の課題を挙げている。
- 個人の認知負荷に容量があるように、チーム全員の認知容量を超えることは出来ないということ
- 従来型の組織設計においてはチームに責任を与えるときに認知負荷が議論されることはなく、これが無視されることで責任や担当領域が広がりすぎてしまい、結果として自分の仕事に熟達するだけの余裕がなくなったり、担当業務のコンテキストスイッチングに悩まされること
TTでは、このような認知負荷に対してチームが対処可能な範囲を知り、それ以上の責任を負わせないように制限することを提案している。具体的には4つのチームタイプを提示しており、ストリームアラインドチームが中心的な立ち位置となっている。
各チームタイプの組閣目的例:
- ストリームアラインドチーム:
- 特定のバリューストリームに専念し価値を迅速に提供することを目的とする
- イネイブリングチーム:
- ストリームアラインドチームが現時点で持たない必要な能力を獲得することを支援するという目的で発足される(学習関連負荷を軽減させる意図?)
- コンプリケイテッド・サブシステムチーム:
- 特定の複雑なサブシステムを専門に取扱い、ストリームアラインドチームの認知負荷を減らすという目的で発足される(外在性負荷を軽減させる意図?)
- プラットフォームチーム:
- ストリームアラインドチームの自律性を担保するために内部サービスを提供することで、下位サービスの開発を請け負い認知負荷を減らす目的で発足される(外在性負荷を軽減させる意図?)
一方で、興味深いこととして、認知負荷に対する教育心理学の研究は、人間の認知構造や限界を考慮して、より効果的な学習設計を考案することを目指している。これは、私達が出来るor実行する量を制限すべきという考え方とは対極にある。外部に学習を移譲することでチームメンバーの学習機会を制限するのは疑問が残る。
従って、認知負荷を効果的に管理することを目指すことには疑いの余地が無いが、以下の点で懸念があるのではないだろうか。
- チームにCLTを適用するのは議論の余地がある
- 認知負荷を制限するアプローチはチームに必要な学習機会を制限するアプローチでもありCLTの目的に反している
知識の量は認知負荷と関連があるか?
前節に加えて、本書では、前提として脳の容量に限界があることは必ずしも知られてないため(e.g., Highly Superior Autobiographical Memory)、認知負荷に関する「多くのコンポーネント(ドメイン)について知ることが認知過負荷になる」という一般的な推論は誤りである可能性があると述べている。 ソフトウェア開発においての問題はそのコンポーネントの学習(再学習)に掛かる時間であり、認知負荷は人の持つ知識の量そのものとは関係がない。
認知負荷と直接関係があるのはワーキングメモリの量であり、ワーキングメモリの取り扱い方を工夫することが効果的な認知負荷の管理につながると述べている。 ワーキングメモリに関しては、
- エビングハウスの忘却曲線に基づいて情報の長期の活性化が再学習に必要な時間を節約すること
- タスク誘発瞳孔反応は認知負荷と積極的に関連しており、専門化であればあるほどそのタスク誘発瞳孔反応は小さくなること
- ダニエル・カーネマンの「ファスト&スロー」より、システム1の思考とシステム2の思考のうち、学習はシステム2の活動であるため、積極的に学習した知識を再利用することが結果的にワーキングメモリを節約すること などを述べている。これらの点は本書でより詳しく解説されている。
ここまでの内容を踏まえると、ソフトウェア開発において「認知負荷が高い」と呼ばれている状況は、単純に取り扱うドメインの広さや深さが起因するわけではなく、認知負荷が「継続して」高くなる状態が何らかの要因で発生し続けている事に起因しているのではないかと思う。
では、認知負荷を乗り越えるためにどのような組織設計のパタンがあるのか？ というのが次の話。
組織設計パタン1: 技術的所有権(狭い所有権)
このパタンは、お客様への価値提供全体の技術的な一部分について所有権を与えるパタンである。 所有権は、一般に組織におけるルール・ポリシー・命令・または一部の人が持つ責任のこと。 例:
このパタンは、チームは技術的なコンポーネントを深く理解し、かつその所有権を持っているため他のチームの影響を最小限にしたまま簡単に所有物を置き換えたり再編成できる柔軟性を持っている。
本書はこれは一般的な組織パタンで、テイラー主義に根ざしたものであると説明している。すなわち、タスクを小さな単位に分解し、プロセス内の各要素を最適化するものである。テイラー主義は御存知の通り産業労働における日常的かつ反復的な作業の最適化を目指したもので、現代の知的労働とは取り扱うものが本質的に異なる。
にも関わらず、マネジメントに関する慣行に現在も影響を与えており、その影響の1つが狭い所有権をチームに割り当てるといった考え方であると説明している。
TT本では、相対ドメイン複雑度(解こうとしている問題がどれだけ複雑か)によって認知負荷を(大まかに)計測し、認知過負荷(Cognitive Overload)になっている状態を相対的な複雑度として検知可能であるということ。この数値が悪い場合、扱うドメインの種類を制限することを提案している。
言い換えれば、認知負荷を管理するという目的で狭い所有権を持つことを提案している組織設計パタンである。(注意: ドメインにはビジネスドメイン以外にも技術的なドメインも含まれている)
問題点: 組織レベルで価値貢献するための能力が低い
このパタンの問題な点は、組織レベルで価値貢献するための能力が低いという点である。なぜなら、すべてのコンポーネントとバリューストリームが常に同じ優先度を持っているわけではないからである。
例えば、組織が最も重要なものに集中する場合、同時点であまり変更や保守が必要ではないコンポーネントを担当するチームには仕事がない。そして、誰も手持ち無沙汰のチームを許容することはないので、組織レベルでは全てのチームが忙しくなるようにプロジェクトや作業を導入する。
上記は、一見チーム内での認知負荷が低くなるように見えるが、組織の単位ではより複雑になる。
組織の目標はしばしば複数チームでの取り組みが必要になるが、各チームの関与度合いは必ずしも一致するわけではない。
あるチームの作業に依存しているとき、その作業を待つ間、手持ち無沙汰な状態を避けるために無関係なプロジェクトに着手する。これが常態化すると、他のプロジェクトも同様なことが起きるため、結局複数のタスクと優先順位間の両立が求められて認知負荷が増加する。(感覚的には、多くのチームはこのような優先順位付けを放棄し、すべてのプロジェクトを「P1」としているのではないかと思う。)
より現実的には、同時進行のプロジェクトが増え、プロジェクト間でのコンフリクトとチームに対してのリソースへの圧力が高まる。様々な目的を持つ利害関係者との調整作業やそれぞれのロードマップと締切に対処しなければならない。(これはチームのEMやPdMに相当する人が実施しているのではないかと思う。)
チームはこの負荷に対処するためにメンバーを分担することで対処するが、結果としてこれが個人への属人化につながったり、お客様との距離やプロダクトゴールへの関与が弱まることになる。
ある時点で経営層はリソース問題を認知する。各チームは、多くのコンポーネントチームにメンバーが居るにも関わらず、キャパシティが不足していると主張する。
この解決策に経営層はメンバーをチーム間で移動させたり、チームごとにパートタイムのメンバーを割り当てることを行う。結果として、さらに認知負荷が高まる構造になってしまう。
他にも本書では狭い所有権を志向するメンタルモデルとして、
- ダニエル・ピンクの内発的動機付け
- コンウェイの法則
- 技術的な所有権が高品質に寄与する
- 技術的品質 などに対して生じる予想外の副作用を説明している。
TTにおけるストリームアラインドチームを支援するための、先述した残り3つのチームに関する組閣条件や組閣目的を踏まえると、狭い所有権パタンと同じ問題を再発明する構造であると思う。各チームは目的が異なるため、当然ストリームアラインドチームとは異なる優先順位を持つことになる。 各チーム単位ではフロー効率は高まる構造かもしれないが、この視点が組織単位と切り替わると価値提供までのリードタイムは特定チームの能力に依存してしまう。
これは複数のストリームアラインドなチームが存在する場合を仮定しても同じ議論ができると思う。それぞれのチームに対して認知負荷や何らかの理由で所有権の制限がある場合、ある時点では組織の優先順位は一致するかもしれないが、特定のチームに優先順位が偏っていたとき、その他のチームは全体の優先順位を厳守することができないため優先順位を無視して別の仕事を始めることになる。
まとめると、狭い所有権を適用するパタンは、実際のお客様への価値提供の能力も制限されるリスクがあり、関心が分離されることで複雑な組織構造を生んでしまったり、ビジネスニーズと専門知識のバランスを取るためにリソース管理などのマネジメントが必要になる。
組織設計パタン2: 流動的所有権(広い所有権)
一方でこのパタンは、技術的なコンポーネントの変更に制限を設けず、お客様のニーズに直接対処する権限をチームに与える組織設計パタンである。
これは、技術コンポーネントに特定チームの所有権が無い(組織レベルで共同所有権をもつ)ことを意味し、チームに特定の作業が紐づくような境界を取り除くことで、チーム間が疎結合ではなく、密結合な状態を促すものである。
このアプローチはWilson & Corbett in 1983, Firestone in 1985の密結合な構造(組織の様々な部分 e.g., チームやユニット)は、独立した部分が多い疎結合な構造と比較して広範囲にわたる変化への適応能力に優れるという研究結果に基づいており、Meyerson & Martin in 1987ではマネージャが疎結合な組織で変更を計画、予測、制御、実行するのに苦労していることを観察している。 他にも組織の結合に関する文献が本書では記載されているが、この記事中では省略する。
このパタンの利点としては、すべてのチームがお客様への影響を与える必要な資源を管理する責任を負うため、組織レベルで各チームがお客様との距離が近くなることや、真の優先順位を厳守しビジネス価値最大化を図れる点などが挙げられる。
また、チームに対して所有権の紐づかないアプローチは、チームと実作業を紐づけてしまう境界を除外し、サイロ化された知識や不必要な組織的な複雑さ、複雑さに伴う非効率性を回避することが可能になる。 具体的には、構造を密結合化することで以下のようなメンタルモデルを育み、個別最適化を避ける。
- 相互の説明責任: 全員の作業が相互依存することで高い基準を維持する
- 内発的動機: 透明性が保たれることでチームの仕事が他のチームにも見られることで品質の高い仕事をする内発的動機を持つ
- 直接的な調整とアライン: 中間の管理レイヤーではなくチームが直接他チームと調整し、目標や方法をアラインすることでタスクに対してアジリティを持った対応が可能になる
問題点: 共有地の悲劇問題が起きる
このパタンの問題点として、本書中でも複数の要素を考慮出来なければ無法地帯となり、更に過負荷でストレスの多い状況に陥ると説明されている。 一般的に、If everybody is responsible, then nobody is responsible.(誰もが責任を持つなら誰も責任を持たない) と呼ばれているように、共同所有、共同責任による運用は、共有地の悲劇(コモンズの悲劇)という有名な経済学の法則を思い出させる。
共有地の悲劇とは、端的に言えば共同所有は必然的に共有している資源を枯渇させる(品質を低下させる)というもので、今回のケースにおいてはソフトウェアコンポーネントの品質が該当するだろう。 TT本でも、このようなチームはエンジニアリングチームの成熟度が高くない場合、ボーイスカウトルールが徹底されなかったりテストを自動化しなかったりするチームによって技術的負債が積み上がると非難している。
しかし、この共有地の悲劇の問題は、2009年ノーベル経済学賞を受賞したオストロームによって、資源管理の効率性はコミュニティが補完的役割を果たしたときに最も効果的になることを示している。(Ref: コモンズのガバナンス - 株式会社晃洋書房)本書中でも適切な条件が整えば共有資源をチームが責任を負って品質を向上させることが出来ると説明している。 www.koyoshobo.co.jp
その他、共有地の悲劇以外の問題点としては以下のようなものが考えられる。
成功させるための重要な要素
長期間の集中
狭い所有権のパタンは、所有する責任の範囲内でチームの稼働率を高めるために、プロジェクト・タスク間のコンテキストスイッチングが多く認知負荷を高める構造だった。 例:
- 1つの欠陥から別の欠陥へと飛び移る
- 別の観点のフィードバックを待ちながら何か他のことを始める
- ビジョンや戦略の欠如による継続的な優先順位の変更
- 1つのプロジェクトと別のプロジェクトに対して部分的なリソースの割り当て
この組織設計パタンは、全員が流動的にコンポーネントを共同所有しているので、複数のチームが特定の成果に対して長期間集中することを可能にしている。 優れたビジョンと戦略を持ち、取り組むべき大きなニーズや問題を順序立てて整理する組織はチームが特定のニーズや問題に長期間(数週間から数ヶ月)集中する機会を提供する。 この状態はその時点で行われていることに関する専門知識を高め、頻繁に同じドメインに取り組むことで認知負荷を軽減する。
逆にビジョンと戦略の無い組織は、必然的に1つの優先事項から別の優先事項に飛び移る必要があり、かつそれぞれが独自の締切を持つ。 このような状況下では、流動的な組織設計に基づくと頻繁にドメインやコンテキストの切り替えが発生するので各チームで学習が困難になり、許容できない認知過負荷になる。
進化的デザイン
これはソフトウェアがコーディングが開始される前に完全に仕様を定めるのではなく、時間をかけて継続的に進化、改善するプロセスのことを指している。 現代的なソフトウェア開発では当たり前の価値観なので、広く多様な開発組織にアプローチするための補足だと思う。
特筆すべきこととして、共同所有であることで、アーキテクチャは最も関係者にとって抵抗の少ない方法を採用し、既に知っていることを適用することを好むという事がある。 エンジニアが各所有コンポーネント内で独自のアーキテクチャ設計や独自の言語などを導入する動機づけを減らし、より標準化に対する議論が推進され、導入されることで認知負荷や学習の非効率性を軽減する狙いがある。 ただし、全員に単一の技術スタックを求めるべきという意味でも、より良い技術スタックに切り替えることを避けるべきという意味でもない。切り替えは多くの人と調整し、漸進的な改善を推奨している。
価値を生み出す人々と生み出された価値を消費する人々との近さ
要件を「提供する側(PdMや企画職など)」と「提供される側(Engineerなど)」の関係性の話。
提供された要件を意図通り理解するのは認知負荷が高く、文脈や意図、目的を完全に理解すること無く、要件が間違っている疑いがあっても最も可能性の高い解釈を単に実装する。 実際に要件変更は要件が変更されたためではなく、そもそも要件が理解/検証されなかったために発生する事が多く、認知負荷を更に悪化させる。 こういったケースの多くは、意図が悪いからではなく、価値を消費する人と生み出す人々の間で行われる書面の文書を介した引き継ぎの多さに依ると指摘している。
多くの人はチームは製品のディスカバリーに関与せず、デリバリーに集中するべきと仮定するが、結果としてチームは情報を準備する人々、ストーリーやProduct requirement document(PRD)を準備する人、設計を構築する人から遅れて情報を受け取る。この状態は、チームは議論に関与していないために実際のお客様のニーズや問題について推測する必要がある。結果、デリバリー直前やデリバリーの最中に要件の変更を確認し、コンテキストスイッチングや集中の欠如をもたらすことになる。
つまり、チームを(提供する側を介さずに)お客様の課題に近づけるのはドメイン理解、プロダクトゴールやビジョンを深く理解することを意味する。学習心理学の観点からも新しい知識と既存の知識を関連付けることが認知負荷を大幅に軽減する事もわかっており、顧客ドメインを理解することが結果的に問題を理解する労力を減らすことになる。
問題なのは、全体像を理解することには明らかな認知負荷があるということ。これが狭い所有権が認知負荷を減らすという一般的な考え方につながっている。
この点については、チームは様々なドメインの専門家と一緒に時間を過ごして学ぶ必要があることを明言している。
全体像を学習する行為は理解が深まるにつれて時間とともに減少するが、都度意図を理解したり、し損なうことで生じる偽の要件変更の認知負荷よりは問題が少ないと説明している。
プロダクトのディスカバリーとデリバリーは2項対立ではなく、ある時期はデリバリーに傾倒するし、ある時期はディスカバリーに傾倒する状態があり、集団が適切にお客様の理解をする状態を育むことの重要性を説いている。
その他にも重要な要素として以下を提示しているが、今回は割愛する。
- 協力的なリファインメントセッションの実施
- よく考え抜かれたルーチン
- 早期のフィードバック
感想
今回の組織設計パタンは所有権と認知負荷が大きなテーマになっていたが、本書は様々な状況で認知負荷と呼ばれるものが「価値提供の観点で無意味なもの」なのか「学習することで乗り越えるべきもの」なのかが明確になる本だと思う。 特に自分を含む多くの人々は、限られた集団における局所的な最適化を志向しがちだが、実際に組織レベルでどのようなダイナミクスが生まれるのかや、その中のひとりひとりが選択する行動は果たしてどれくらいプロダクト全体にとって価値が生まれるのかを再考するのに価値があると思った。
また、この本はコンポーネントチームとフィーチャーチームの議論を組織レベルに拡張したものであるとも言える。どちらも焦点は「学習」をどのように認識しているかだと思う。本書中にはあまり述べられていないが、採用や評価制度なんかに関しても、「学習」をどう解釈しているかで最適な設計は変わるはず。
学習する組織では「構造が挙動に影響を与える」とも述べられているし、クレイグ・ラーマンの法則では、「組織構造が文化を作る」と述べられていることも踏まえると、私達は組織構造についてもっと理解を深める必要があるし、得たい成果に対して恣意的に構造を決定出来る能力を磨く価値は大きいと思う。 www.kinokuniya.co.jp 同時にどのような構造を選択するとしても、その構造によって生じる副作用には注意する必要がある。副作用には直接的に観測できるものもあれば、顕在化まで時間が掛かるものもある。安易に実装方法に飛びつく前に選択した構造が人々のどのような振る舞いをもたらすのか、繰り返し考えたい。
