クネビンフレームワーク

Cynefin Framework

ゆれ:カネビンフレームワーク

2022年現在、解像度低い使われ方しか見たことがない。

目乗り前で起きていることがどれに該当するのかを対応させる補助仮説が弱すぎて「私が思ったからこう」になってしまう。能力が高ければシルプルになりやすく、低ければカオスになってしまう。自分の情報処理能力の自己紹介になりがち。

主観的評価の5領域

無秩序が中心に居座っているが、無秩序は外縁だと思う

Cynefinとは

「人間は自分では気づかないものの、さまざまな要素の影響下にある」という意味のウェールズ語である。

開発は複雑系と認識していても、営業はシンプルと捉えていたりする。

状況を因果関係の明確さに基づいて分類する。

直面する状況を、因果関係の明確さの度合いに基づき5種類に分類したもの。これらは同時に発現することに注意すること。

参考

Harvard Business Review 2008.3

----

Scrum ギャザリング の講演で complicated と complex について語られいたと思います。私は講演を聴いて 「生もの である ソフトウェアの要求 は、(機械のようなというよりも生命のような) complicatedなテーマなので、complicatedに適したアプローチが必要、それには、ユーザーストーリー＆パターンが適している」と解釈したのですが、まだ咀嚼しきれていないところがあります。 complicated, living な user stories, patterns について角さんの見解を、もう少し詳しくお聞かせください。

さて、ご質問ですが、まず「生命のような難しさ」はComplicatedではなく「Complex」です。それから、講演では意図的に「ソフトウェア要求」と「システム要求」を分けていました。また、「システム要求は、Complexなテーマ」とは言っておらず、ユーザーストーリーのなかにはComplexなものもある（同様にComplicatedなものもある）という話をしました。

というわけで、用語が違うと回答するのがしんどいのですが……簡単に説明すると、システムは（クネビンフレームワークで言う）「シンプル」なものが多いと思います。短納期で開発されているならば、それは「シンプル」なシステムです。過去に作ったことのあるもの、理解しやすいもの、単純なもの、規模の小さなもの、なんかは「シンプル」であると言えます。

そのなかで部分的に「Complex」なものが登場することがあります。いつまで経っても解決策が見つからない、昨日の要求と今日の要求が違う、時間によって挙動が変わる、なんかは「Complex」であると言えるでしょう。それがComplexであるとわかれば、パターン的なアプローチ（コミュニケーションを通じてパターンを創発する）を使うのがいいと思います。そのための手段として、コミュニケーションを重視したユーザーストーリーは適していると思います。

パターンは建築由来のものですが、「土地」「法律」「予算」など固定された「かたい」ものはパターンでは対応できません。それと同様に、システムの「土地」（アーキテクチャやドメインモデル）にComplexなアプローチが通用するとは思いません。そこは時間がかかってでも、Complicatedなアプローチをとるべきです。