The Flow System - 複雑な問題を解決するためのリーダシップ

原文(投稿日：2021/05/14)へのリンク

John Turner、Nigel Thurlow、Brian Rivera3氏の共著"The Flow System: The Evolution of Agile and Lean Thinking in an Age of Complexity"は、複雑な環境下で運営される組織のアジリティ向上を支援する書籍です。トヨタ生産方式に基いて理論構築されたこの本は、複雑性の時代において、組織がより適応性とレジリエンスを備えた革新的な存在になり得るために、複雑性思考(compelxity thinking)、分散型リーダシップ(distributed leadership)、チームサイエンスの3つを組み合わせ、著者らの言う"フローの3重らせん(螺旋)"(Triple Helix of Flow)を形成することによって、組織のリーン思考を促進しようというものです。

抜粋をこちらからダウンロードできます。 

John Turner、Nigel Thurlow、Brian Rivera3氏が答える本書のQ&Aは、2部構成の記事として公開されています。そのパート2にあたる今回の記事では、複雑性思考、分散型リーダシップ、チームサイエンスによる3重らせんについて詳しく見ていきます。パート1の"Getting Fast Customer Feedback and Managing Flow"では、品質の重要性、カスタマからの迅速なフィードバック獲得、フロー(flow)のコンセプト、フローシステム(Flow System)について詳説しています。 

InfoQ: "Complex Problem"とは何で、私たちはそれにどう対処すればよいのでしょうか？

John Turner: "Complex Problem"は、私たちが日々扱っているような、複雑ではあるが予測可能な従来型の問題とは違います。"Complex Problem"は、さまざまな方法とレベルで相互対話する複数のエージェント、有機体、あるいはシステムによって起こされるもので、不調和、未知、予測不能といった状況をもたらし、その結果、プロセス全体を通じて一定した不確実性の感覚を与えます。

文献ではSimple(単純)、Complex(複雑)、Wicked(最悪)という、3つのタイプに問題を区別しています。Churchmanがこれら3タイプの問題を最初に示したのは、1967年のことでした。"Simple Problem"には、問題と解決方法に関する合意があります。"Complex Problem"には、問題に関する合意はありますが、問題を解決する手法への合意はありません。そして"Wicked Problem"には、問題にも解決方法にも合意が存在しないのです。"Simple Problem"の例は代数的解法です(3X + 2 = 5)。私たちすべてに影響しているパンデミックへの対処は、"Complex Problem"の現実的な例です。何が問題なのかは分かっているのですが、問題への対処や、世界規模で問題を解決するために必要なソリューションについて、多くの科学的、政治的な議論が交わされています。"Wicked Problem"の例は地球温暖化です。 

未知の部分が多すぎるため、小さな問題に区切ることができません。"Complex Problem"には、他の問題に使うものとは違ったテクニックが必要なのです。

私たちが"複雑性思考"と呼ぶプロセスは、ここから始まります。

ステップ1: 複雑系(complex systems)の特徴を理解する。

ステップ2: システム、エンティティ、あるいはイベントが複雑適応系(complex adaptive systems)であるという、世界観ないし観点を持つ。

ステップ１は、対処する環境あるいは問題のタイプを認知するための知識を与えてくれます。私たちの経験では、Cynefinフレームワークが、直面する問題を識別するための最善のツールのひとつです。CynefinフレームワークとCognitive Edgeの方々(Dave Snowdenとその同僚)は、複雑なドメインに対処するためのステップも提供してくれています。

ステップ2は、複雑適応系に関連する、数多くの構成要素の認知に関わるものです。これらの構成要素は非線形で、予測不能で、再現不能です。他の多くの問題には存在しない、それら自身にのみ関わるような、特有のパターンもそこに含まれています。複雑性を扱うためには、実験と、探索的な活動が必要になります。複雑適応系のユニークな構成要素について学ぶためには、センスメイキング(Sensemaking、意味付け)が必要です。 

組織内においては、リーダやチームが対処する"Complex Problem"のほとんどが人由来のものである(human-derived)点にも注目が必要でしょう。私たちが直面する"Complex Problem"の大部分は、実は私たちが生み出しているのです。フローの3重らせん(螺旋)を統合することが重要な理由はここにあります — ひとつの"らせん"にだけ注目していたのでは、複雑性を回避することはできません。組織全体の3重らせんを統合して初めて、フローが生み出され、顧客に価値をもたらすことができるのです。 

フローの3重らせんでは、3つのらせん(複雑性思考、分散型リーダシップ、チームサイエンス)を統合して、設計から提供までのフローをシームレスなものにする必要があります。今日の組織内で日々繰り返されるこの例は、フローの3重らせんという概念を使ってフローが実現される様子や、3つのらせんのそれぞれが総体的に統合されている様子を示すものです(詳細は"The Evolution of Lean Thinking"を参照してください)。この統合なくして、フローは実現できません。

InfoQ: 組織的なシステムを理解する上で、システム思考を用いると、どのようなことが問題になるのでしょうか？

Turner: 基本的にクローズドなシステムを扱うのであれば、何も問題はありません。システム思考は、そもそもクローズドシステムに適用されるものなのです。複雑な環境や問題に対処する場合には、基本的にクローズドなシステムから、基本的にオープンなシステムへとテーブルが移ります。複雑性思考はオープンで複雑な適応系に対処するように考えられています。システム思考が念頭に置いているのは、おもにクローズドシステムなのです。 

クローズドシステムとオープンシステムにはオーバーラップした領域があります。この領域を最もよく説明したものが、CynefinフレームワークのLiminal Boundary(境界面)です。クローズドな傾向のあるシステムの管理には、システム思考のテクニックが最も適しています。対照的に、オープン的なシステムでは、複雑性思考のテクニックを用いた方がよい管理ができるのです。対象とする問題がどのタイプなのかを最初に特定した上で、そのタイプの問題に適したツールとテクニックを決めることが大切です。これが、複雑性思考を支える基本的な考え方です。まずは、直面している問題ないし環境のタイプを特定することです。 

しかしながら、システム思考の信奉者には、すべてのシステムがシステム思考を用いて管理可能だという考えて、複雑性思考を完全に否定する人たちもいます。システム思考と複雑性思考という2つのパラダイムは、異なる分野で同じ時期に発展しました。 その後も長い間、別々のものでした。ひとつのテクニックとして統合され始めたのは最近のことです。この統合は、STが一部のコンポーネントを、CTが別のコンポーネントをそれぞれ提供し、いくつかのコンポーネントを共有するという、複雑適応系のコンポーネント集合体である、と私は理解しています。この重複については以前記事にしましたが、どのテクニックがどちらのパラダイムに由来するものかを特定するには、まだ必要な作業がたくさん残っています(https://www.mdpi.com/2079-8954/7/1/4)。遅々とではありますが、私は今、この調査に取り組んでいます。そのような状況ですが、この話題については、本書の中でも少し論じました。私たちはこの重複を、CynefinフレームワークのLiminal Boundaryにあるとして、STではComplecated Domain(クローズドシステム)、CTではComplex Domain(オープンシステム)に、それぞれ位置付けています。  

この疑問はまた、システムにおける境界や制約についても示唆しています。複雑な要素の取り除かれたポイントにおいてシステムが境界付けられている場合、システム思考のテクニックが有効に機能します — 境界が損なわれていない、という条件付きではありますが。複雑性思考のテクニックが必要になるのは、複雑性に結び付くコンポーネントでシステムが境界付けられている場合です。複雑性に対処する場合には、複雑な要素の取り払われたポイントでシステムを制限したいとは思わないでしょう。そんなことをすれば、システムがその境界内で最適化された場合、その最適化は複雑性を発生させる要因なしで行われるため、複雑性が改めて取り込まれた時には期待されたように機能できなくなるからです。境界や制限のシステムに対する位置付けは、システムと複雑性を扱う上で非常に重要なものです。

InfoQ: 今日のリーダシッププラクティスの限界は何でしょうか？

Turner: 最も重要な限界のひとつは、発展性が欠如していることです。リーダシップトレーニングのほとんどは、実態としてリーダ教育です。これらのトレーニングには、リーダ候補が新たに学んだリーダシップスキルを実践するための時間もありません。実践や発展段階で失敗する自由がなければ、新たなリーダがスキルをマスタすることはほぼ不可能です。もうひとつの問題は、ほとんどのプログラムが、すべての人に同じ方法でトレーニングを提供していることです。最初から"万人向け(one-size-fits-all)"トレーニングとしてデザインされたリーダシップ開発プログラムがほとんどなのです。"The Flow System"では、状況設定を中心としたリーダシップやチーム開発の設計に多大な努力を払っています。 

私たちはリーダシップを個々の構造ではなく、集合的な構造として捉えています。チームがリーダシップのモデルであり、個々のチームメンバがリーダであるという、共有型のリーダシップモデルを取り入れているのです。この集合性は組織において、低いランクから管理層のレベルに至るまでのリーダシップモデルとなります。このような方法で、組織内におけるリーダシップは、個人主義的な他のリーダシップ理論ではなく、分散型リーダシップに焦点を当てた、より分散的なものになるのです。 

リーダシップモデルとしてのチームは分散型リーダシップへの移行の第一歩ですが、実現のためには不可欠な概念です。リーダシップは個々のものではなく、集合的なものです。これは同時に、"Complex Problem"に対処する上で必要なものでもあります。複雑性に立ち向かうには、スキルや知識の多様性(diversity)が必要であり、そのような多様性を達成するためにチームが使われることが多いのです。個人プレーの入る余地はありません。複雑性に対処できるスキルをひとりで備えることは不可能です。複雑性を管理できるリーダは、個人としては存在しないのです。複雑なドメインを扱う上で、分散型リーダシップは不可欠です。

Brian Rivera: Johnが挙げた点に加えて、いくつかのFORTUNE 50企業や米海軍での私自身の最近の経験から、現在のリーダシッププラクティスの最大の制限は、個人を重視していることだと思っています。複雑適応系において、個々のエージェントの改善を重視するのは誤った考え方です。そうではなく、インタラクションの改善に注目することが必要なのです。これは、組織のすべてのレベルにおけるチームワークに注目することで達成されます。現実を直視しましょう — ほとんどの"リーダ"は技術的スキルで選ばれたのであって、リーダシップのスキルではないはずです。  

この問題をさらに難しいものにしているのが、"チームレベル"で"アジャイル"を適用するためにビジネスリーダを重視するという、アジャイルコミュニティの固定観念であり、内部用語なのです。状況を明確にするために言えば、相互依存的なチームとして活動する必要があるのは、顧客に最も近い人たちとは限りません。現実的なそれは、経営陣や取締役会の最も近くにいるマネージャやリーダたちなのです。 

Nigel Thurlow: "リーダ"を自負する大部分の人たちのモチベーションの本質は、自尊心と価値観です。つまり、"それが自分にとって何のやくに立つのか？"ということなのです。"私たち"より"私"を重視するこの考え方は、ナルシシズム的行動という特徴の発露に結び付きます。これが企業における"リーダシップ"の実態なのです。

対処方法のひとつは、顧客第一に重点を変えることですが、それだけでは不十分です。リーダシップを変えて、私たちが分散型リーダシップの中で定義したような、集合的リーダシップモデルを採用する必要があります。これは精神病患者が病院の運営を始めるという意味ではないので、制約管理の一環として制約を有効にしたり、必要時にはガードレールを用意するなどといったコンロトールは引き続き必要です。

リーダシップはチームです。リーダはチームとして行動する必要があります。リーダがチームを組むと言うのではなく、サイロで活動を続ける(自己完結している)べきなのです。チームを判断する上で重要なのは、それぞれのメンバが、他のメンバの行っていることを常に知っている、ということです。私自身の調査から、大部分のリーダは、ミーティングに集まった後、自身のチームの運営に戻っても、その"リーダシップ"チームの他のメンバにはほとんど触れていない、ということが分かっています。

フローの3重らせんの概念を理解することで、将来的には、組織のすべてのレベルにおいてリーダが生まれるようになります。そのような"集合的リーダシップ"が顧客への"価値のフロー"を最適化するのです。 

InfoQ: 組織においてリーダシップを開発するには、どのようにすればよいのでしょう？

Turner: 私たちは分散型のリーダシップモデルを使って、個々のレベルにおける自己リーダシップ(self-leadership)と自己効力感(self-efficacy)に注目することから始めました。チームレベルでは、共有型リーダシップモデルを用いて、チームが自己組織的かつ自律的なエンティティになることを重視しています。機能的リーダシップは、マルチチームシステムのレベルにおける境界スパナ(boundary spanner、越境者)を育てます。経営層においては、戦略的、手段的、世界的リーダシップに見られる機能を、既存のリーダシップ機能の中に組み込みました。全体としてこれが、"The Flow System"で紹介した分散型リーダシップモデルを作り上げているのです。

リーダシップは、すべてのレベルにおいて状況依存です。そのためには、各レベル(個人、チーム、MTS、経営陣)で求められる必要なスキルや能力を特定し、上図に示したボックスに列挙する必要があります。その組織において必要なこれらのスキルが特定されれば、各レベルにおけるこれらのスキルの開発を中心としたリーダシップ開発がデザインできます。重要なのは、組織のすべてのレベルにおいて、リーダシップとチームワークスキル(個人間のスキル)を構築することです。リーダシップは創発的であり、組織内のすべてのレベルにおいて発生します。それが起きるのは、すべてのレベルがリーダシッププロセスに関与した時です。ブロックの積み重ねやジェンガブロックのセットのように、ひとつのレベルのブロックを取り去ると、その上のすべてのレベルのブロックが崩れてしまいます。いずれかのレベルでリーダシップやチームワークスキルの発展を無視すれば、組織内に抑制的な制約が生まれて、顧客に対する価値提供(のフロー)が低減することになります。 

InfoQ: 共有型リーダシップを用いることのメリットは何でしょうか？

Turner: 共有型リーダシップは、メンバが責任を共有し、コラボレーションし、集合的に判断し、タスクワーク中のサポート機能を提供することが自由にできるという、心理的な安全感のある環境を提供してくれます。共有型リーダシップは、個人を集めて単にチームと呼ぶだけで起きるものではありません。チーム内に本物の共有型リーダシップが生じる状態を達成する前に、チームメンバにチームワークリーダシップのスキルを教える必要があります。 

共有型リーダシップモデルを用いたチーム運営が可能な状態を達成することのメリットのひとつは、チームリーダや外部のリーダが必要でなくなることです — 集団としてのチームがリードするのです。これによって管理ないし監督職の総数が削減されれば、次にチームが向かうレベルは境界スパナです。そうなれば、組織に必要なのはチームメンバと、マルチチームシステム毎にひとりの境界スパナのみになります。 

複雑性の下で業務を遂行する場合、ひとりのリーダがチームを効果的に指揮することはできません。必要なスキルをトレーニングされたチームメンバが共有型リーダシップを活用することで、チームは多様性を備えた集団として機能し、ひとりのチームリーダに率いられたチームよりも、複雑性によりよく対応することが可能になるのです。 

チームメンバが自由に交流し、アイデアを交換し合うチーム構成が、創造性を生み出します。外部のリーダ、あるいはチームリーダがこの自由なアイデア交換を阻害して、プロセスを指揮しようとすれば、創造性は阻害されて完全なものではなくなります。共有型リーダシップは、チームが自由にアイデアを交換できるメカニズムを提供することで、成果においてより創造的になるためのチーム構造を提供してくれるのです。 

InfoQ: タスクワークとチームワークの違いは何でしょう？

Turner: チームが機能するにはどちらも必要なものです。最も基本的な形式では、チームワークがメンバの対人的活動に関するものであるのに対して、タスクワークはチームメンバが自身のタスクを完成させる上での技術的側面に関連します。 

一般的にチームは、チームにアサインされた仕事を完遂する上で、必要なタスクを遂行可能なチームメンバによって構成されています。必ずしもこれが事実でなく、また多くのチームを混乱させているのは、これら同じチームメンバが、チームとして機能するためのトレーニングを受けていることはほとんどない、という点が原因です。チームワークトレーニングは重要な差別化要因なのです。チームワークスキルのトレーニングを受けたチームは、受けていないチームと比較して、ワークスキルの面で優れており、それ以外では同等である、という調査結果もあります。

InfoQ: チームの有効性を向上するには、どうすればよいのでしょうか？

Thurlow: チームの有効性に不可欠なコンポーネントに注目した公式があります。 

次のような公式です: TE = (TW + IP) + TK f (TP + AP) + PF + CV

チームの有効性 = (チームワーク + 対人的プロセス) + タスクワーク f(移行フェーズ + 実践フェーズ) + パフォーマンス + 顧客価値 

チームワーク(TW)には、実践フェーズ(AP)、移行フェーズ(TP)、対人的プロセス(IP)が関与します。チームメンバは、チームのコアプロセス(調整(coordination)、連携(cooperation)、認知(cognition)、対立(conflict)、コミュニケーション、コーチング)を自己管理する能力を備えなくてはなりません。

タスクワーク(TK)に関与するのは、与えられたタスクをチームメンバが完遂する上で必要な知識、スキル、能力といったものです。チームはそのタスクに必要な知識とスキルを持ったチームメンバで構成(設計)されなくてはなりません。

パフォーマンス(PF)は、さまざまなマトリックス値(品質、数量、時間など)に関する実績値です。

顧客価値(CV)は、顧客に提供する価値を表現します。ただしこれには、内部的な顧客としてのチームメンバの満足度も含まれています。

InfoQ: 複数のチームで構成される組織をどのようにセットアップし、リードすればよいのでしょうか？

Tuirner: 複数チームに関する質問ですが、詳しく答えるにはフローの3重らせんが関わってきます。組織において複数のチームが正しく機能するためには、3重らせんのそれぞれが重要になります。複数チームを中心とした組織構造を、私たちはチームベース構造(team-based structure)と呼んでいます。この活動に関与するのは、直面する問題のタイプに応じてメソッドやテクニックを使い分けることのできる知識とスキルを備えた個人です。機能的リーダシップと境界スパナのもたらすリーダシップ構造と、経営陣の提供するサポートとリソースを持つことによって、チームは、自己完結的かつ自律的なユニットとして機能することができるのです。

端的に答えるならば — 中核となるのは複数チームシステム(MTS)を中心とする複数チームの構造であり、それに関与するのは、組織的目標に向けて複数チームシステムを管理し、行動を調整する境界スパナの役割です。これにはほとんどの組織において、複数チームシステム構造を使ったチームの再構成が必要になります。その実現方法は組織やそのプロダクト、関与するチーム数によってさまざま、すなわち状況依存です。 

共有型リーダシップモデルと境界スパナの役割を使用することが、大部分の組織における最も重要な変革になるでしょう。自らのエンティティのコントロールに固執するリーダがいる状況で、この自律性と自己組織のレベルを達成するのは困難です。最大のハードルは、チームと複数チームシステムが機能して価値を提供するものであると信頼するポイントまで、リーダシップやマネージャを導くことです。適切なトレーニング、プラクティス、サポート、リソースを用意することができれば、外部の脅威(や変化)に対する適応性と回復性を持って組織を運営することが可能になります。

Thurlow: 複数チームシステム(MTS)の使用を試みる組織の大部分は、何らかの形式のアジャイルスケーリングアプローチを取り入れています。これを監督する作業は、通常はIT部門に委任されています。人事部門がこれに関与することは、役職の変更や定義に関する問題が発生しない限り、ほとんどありません。MTSは単にチームが複数あるだけではありません。作業の方法や価値の提供方法の構造的変革です。リーン実践者にとっては、バリューストリームを支える基本的な概念であり、価値提供に必要な人々とツールをすべて詰め込んだコンテナなのです。

アジャイルのスケーリングアプローチはロールの機能とデリバリプロセスを扱うものですが、対象はソフトウェアにほぼ限られている上、必要とされるリーダシップの変更には対応できていません。それに言及しているものはあっても、効果的に行う方法については述べていなかったり、あるいは新たにMTSを有効にする上で組織全体に必要な構造的変革に対処していなかったりしています。

目標を改めて重視する必要があります。2020 Scrum Guideではこの方向性を認識していて、文献や書籍で"遠隔目標(Distal Goal)"と定義されているものを"プロダクト目標(Product Goal)"として取り入れると同時に、チーム目標を"近接目標(Proximal Goal)"と定義しています。目標は価値を決定するものですが、残念なことに多くの組織が、チーム個々のレベルや、あるいはホームページに掲載した企業ビジョンやミッションを越える視点を失っているのです。

大部分の組織において、スクラムあるいはアジャイルを拡大する上での最大の課題は、彼らが従来の管理アプローチを、さらに悪いことに自分たちの階層構造を、維持したいと考えている事実です。スクラムやアジャイルの類は、マネージャやスーパバイザの役割について何も定義していません。当然のようにマネージャを無視して、"そうですね、プロダクトオーナにでもなればどうですか"というような、高飛車な言葉を使っているのが現状です。これでは失敗して当然でしょう — 経営層は変わらず、一方で作業者はチームベース、自律型、自己管理型の構造(複雑適応システム)に移行して、"リーダシップ"と管理者は旧態依然としている訳ですから。分断型リーダシップに移行する必要があります。

Johnの言及した境界スパナの役割はこの変化に不可欠なもので、私はこれをマネジメントの転用(Repurposing Management)であると定義しています。"アジャイルに移行"する時、マネージャをどう処遇してよいのか分からないすべての経営層にとって、これがその答なのです！

中間管理層の転用は、そのマシンによる抵抗と反撃を回避するために不可欠なものです。Peter Druckerの言うように、"企業におけるすべてのイノベーションは、企業の免疫システムを刺激し、それを破壊する抗体を生成させる"のです。企業が変革活動の中で課題と戦う時、中間管理層の転用は、フローにおける主要な差別化要因のひとつになります。これによって彼らマネージャが、問題を解決し、価値のフローの最適化に貢献する貴重な資産になる方法を、コーチングを通じて提供することが可能になるのです。

マネジメント層を新たな境界スパナの役割に転ずることで、彼らの行動や焦点、目標は変わるはずです。これが結果としてリーダシップリーダシップの発露となり、分散型リーダシップの新たな文化が形成され始めるのです。境界スパナは、複数チームシステムを指導および管理する上で鍵になります。その核となる概念は、"チーム間のリレーションシップを促進し、問題を解決し、目標への一致団結を実現するためには、チーム間の境界を埋める必要がある"、というものです。

複数MTSに拡張する場合には、境界スパナらが協力し合って、この合成されたMTSを共に導くことになります。スクラムではこの役割をスクラムマスタあるいはアジャイルコーチに割り当てていますが、現実にはほとんどの組織においてこれらの役割には権限がないため、単にフラストレーションを募らせてチームの士気を低下させ、企業の悲惨な状況の中で漂う結果になっています。 

"The Flow Systems"に関するインタビューのパート1である"Getting Fast Customer Feedback and Managing Flow"では、品質の重要性、カスタマからの迅速なフィードバック獲得、フロー(flow)のコンセプト、フローシステム(Flow System)について詳説しています。

本書の著者について 

John R.Turner氏はPh.D.で、米国北テキサス大学の准教授です。氏は"The Flow System: The Evolution of Agile and Lean Thinking"、"The Flow System Guide"、"The Flow System: Key Principles and Attributes"の著者のひとりです。研究では、リーダシップ、チーム、複雑性の相互作用に関心を持っています。氏への連絡は、jrthpt@gmail.com宛で可能です。

Nigel Thulow氏は、受賞した"Scrum the Toyota Way"トレーニングコースの開発者で、"The Flow System"の作者のひとりです。氏はかつて、Toyota Connectedでリーンとアジャイルプラクティスをリードする世界的なToyota社でアジャイルの初代チーフを務めた経歴を持っており、Toyota Production System、Toyota Way、およびさまざまなアジャイルアプローの専門家として知られています。基調講演者としても著名な氏は、プロフェッショナルのスクラムマスタとして、2020年までに世界中で7,500人以上をトレーニングしてきました。氏のYouTubeチャネルは、WatchNigel.comで見ることができます。

Brian Rivera氏、コールサイン"Ponch"は、作戦および戦略レベルにおける戦争で豊富な経験を持つ、TOPGUNおよびF-14デモンストレーションチームの元メンバで、" The Flow System: The Evolution of Agile and Lean Thinking in an Age of Complexity"および"The Flow System Guide"の著者のひとりです。氏は基調講演者で、AGLX Consultingの創業者兼CEOです。