複雑さがある世界でものを作り続けたり、問題を解決するにはどのようなアプローチがよいのでしょうか。私は、Cynefin Framwork (クネビンフレームワーク) で問題領域がどこなのかを認識するところからはじめることをおすすめしています。本当に複雑な領域なのかというのはもちろんですが、大抵は、複雑さがあるにもかかわらず、それを認めず、できれば「明確」な状態であると信じ、錯覚することが多いからです。
それぞれの領域において、意思決定の仕方、頻度はことなるものです。また、問題の発見方法、対処方法もことなるものです。
複雑さのある世界
複雑さがある問題領域では、どのように過ごしていけばよいでしょうか?基本的に正解がまだなく、未知な取り組みとなるわけです。私は、経営者やマネジメントには、EBM(エビデンスベースドマネジメント)をおすすめし、実践者にはアジャイル(とりわけスクラム)をおすすめしています。これらは優れた知見を集合したフレームワークなので、この恩恵を受けない手はありません。
その反面で、これらのフレームワークを盲目的に信じ、盲目的に、機会的に、主旨を理解せずに取り入れてしまうこともあります。完全に否定するものではありませんが、できれば複雑であるという認識とその特性を同じ状況下にある仲間(グループやチーム)で分かち合い、ともに取り組みたいものです。
そこで、クネビンフレームワークの生みの親であるデイブ スノーデン氏が解説した複雑系のサブドメインの解説を拝聴しました。動画を何度も読み、記事も穴が開くほど読みました。その上で私なりに簡潔に解説できるようにしてきています。ここでは、その簡潔にした私の理解を元としたものをさらに簡潔に紹介したいと思います(ややこしや)。
複雑系のサブドメイン
![](https://www.servantworks.co.jp/wp-content/uploads/2023/01/cynefin_framework_complex_subdomain_modification-1024x577.jpg)
こちらのスライドは、2023年1月に開催された RSGT2023 での講演のものです。講演スライドはこちらでご覧いただけます。
左上と右上にある「無秩序へ」とは、問題領域がどこなのかが判断できなくなってしまうことを指すと言われています。また、複雑系は、混沌系と煩雑系の間にあるので、この図の対角線は、混沌系から来て煩雑系に向かうと捉えることができます。当然対処方法がうまくいかないと反対に向かっていくこともあり得ます。
この対角線は、「一貫性」とされていて複雑系では、この一貫性のラインにいるように心がける必要があります。特にこの中心にある状態を目指し、ずれを補正していくように振る舞っていくことになるでしょう。
通常、複雑系では、この中心部にあると錯覚することが多いとも言われています。しかしながら、概ね、混沌系から来て左下からスタートすることになるでしょう。
左下からスタートし、直感や予想、賭け、当てずっぽうにより意思決定しながら進めてしまったりするものです。もしくは、一部の人が事実に辿り着き、理解されないまま関係を悪化させてしまったりするのではないでしょうか。その結果が、それぞれの「同調圧力」「異端児」となるでしょう(※命名は長沢による)。
同調圧力のような状況であれば、まずはそれだったり、その流れを止めなければなりません。その上で冷静に反証できるものや、帰納的で再現性のある事実を見つけていき一貫性のラインに戻してあげます。もしくは、多くの「チャレンジ(課題)」や「問い」を投げかけて思い込みから脱却する必要があります。
異端児のような状況であれば、少数だけが知り得た確かな事実があることになるので、それが妥当なのか、十分に周知するために実証すべきです。コーチングやファシリテーションによりその事実をより再現性が得られ、誰もが認識できるようにするか、もしくは、「安全に実験できる」(目的のために小さな失敗を許容する、事実を実証できる、新たな事実に繋げる)ようにすべきです。
常に意識してみる
私は、アジャイル支援を行う際に、この図を意識してどの状況なのかを想像しながら、どういった投げかけをすべきかを考え、実行しています。頭の中を整理する際に活用できると自認していますので、みなさんも良さそうだと思ったらやってみてください。
スクラムがうまくいかない理由
スクラムがうまくいかない。ScrumButやメカニカルスクラム、ゾンビスクラムと呼ばれる現象になってしまうのは、問題領域の誤り、問題領域の共通理解のなさ、Howに縋りすぎるなどがあります。今回書いたことを一つの参考にしていただき、これらからの脱却に繋げて欲しいです。また、頻繁に立ち返ることをチームで試してください。
オリジナルにあたる
以上、私の理解と私なりのアプローチで解説していきました。オリジナルは以下ですので、ぜひオリジナルにあたってください。
本記事の執筆者:
![PSPO II - Professional Scrum Product Owner II](https://www.servantworks.co.jp/wp-content/uploads/2021/08/pspoii.png)
![PSPO I - Professional Scrum Product Owner I](https://www.servantworks.co.jp/wp-content/uploads/2021/08/pspoi.png)
![PSM II - Professional Scrum Master II](https://www.servantworks.co.jp/wp-content/uploads/2021/08/psmii.png)
![PSM I - Professional Scrum Master I](https://www.servantworks.co.jp/wp-content/uploads/2021/08/psmi.png)
![PSD I - Professional Scrum Developer I](https://www.servantworks.co.jp/wp-content/uploads/2021/08/psdi.png)
![PAL-EBM - Professional Agile Leadership - Evidence-Based Management](https://www.servantworks.co.jp/wp-content/uploads/2021/08/pal-ebm.png)
![PAL I - Professional Agile Leadership I](https://www.servantworks.co.jp/wp-content/uploads/2021/08/pali.png)
![SPS- Scaled Professional Scrum](https://www.servantworks.co.jp/wp-content/uploads/2021/08/sps.png)
![PSU I - Professional Scrum with User Experience](https://www.servantworks.co.jp/wp-content/uploads/2021/08/psui.png)
![PSK I - Professional Scrum with Kanban I](https://www.servantworks.co.jp/wp-content/uploads/2021/08/pski.png)
![PSF - Professional Scrum Facilitation Skills](https://www.servantworks.co.jp/wp-content/uploads/2023/11/psfs.png)
![PSPBM - Professional Scrum Product Backlog Management Skills](https://www.servantworks.co.jp/wp-content/uploads/PSPBM.png)
![認定スクラムマスター](https://www.servantworks.co.jp/wp-content/uploads/2021/01/seal-csm.png)
![DASA Accredited DevOps Trainer](https://www.servantworks.co.jp/wp-content/uploads/70x400xd69ea27b-8fbc-4827-8522-4617839b1d39.png.pagespeed.ic.rFwV_8c4qD.png)
![DASAアンバサダー](https://www.servantworks.co.jp/wp-content/uploads/2022/04/DASA-Ambassador.png)
『More Effective Agile』、『Adaptive Code』、『今すぐ実践!カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。
Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。