クネビンフレームワークとソフトウェアエンジニアリング

2007年にクネビンフレームワークが Harvard Business Review で紹介されて以降、ソフトウェアエンジニアリングの世界では、アジャイル開発、特にスクラムを採用すべき理由の説明で本フレームワークが用いられるようになった。

リーダー向けツールとして開発された意思決定のためのフレームワークが、いったいどのようにして、ソフトウェアエンジニアリングの開発プロセスモデルや開発方法論を説明するというのだろうか。

本稿では、クネビンフレームワークがどういうものであるかを紐解きつつ、その具体例として、ソフトウェアエンジニアリングの現場に適用することを試みる。

クネビンフレームワークとは

クネビンフレームワーク（Cynefin framework）は、リーダーが直面する状況をカテゴライズし、そのそれぞれに適応した意思決定（decision making）プロセスを提供するツールだ。経営コンサルタントであり、ナレッジマネジメントと複雑系科学の研究者である David J. Snowden らによって、1990年代終わり頃に第一世代が開発された。

その後、現在の第三世代が、"A Leader’s Framework for Decision Making" というタイトルで英語版 Harvard Business Review の 2007年11月号にて紹介されると、翌2008年の Outstanding Practitioner-Oriented Publication in OB アワードを受賞するなど、大きな反響を読んだ。この時の記事は、日本語版ハーバード・ビジネス・レビューの2008年3月号で『臨機応変の意思決定手法 「クネビン・フレームワーク」による』として読むことができる。

フレームワークはその後も進化を続けているが、本稿では基本的に、この日本語版ハーバード・ビジネス・レビューの2008年3月号で紹介されたバージョンをもとに書いている。

クネビンフレームワークでは、取り扱う問題が置かれた状況を次の五つの領域（domain）に分類している。

• Simple / 単純な状況
• Complicated / 込み入った状況
• Complex / 複雑な状況
• Chaotic / カオスな状況
• Disorder / 無秩序

この五つの領域は、状況を生じさせている原因と結果の因果関係の明確さの度合いによって分類されている。そして、その領域それぞれに対し、意思決定のためのプロセスモデルが定義されている。

Simple / 単純な状況にある領域

この「単純（Simple）」という呼び名は、実はもう使われていない。2021年10月現在では、「明白（Clear）」と呼ばれ、その前は「単純（Obvious）」と呼ばれていた。いずれにしても、現時点では日本語での名称が未定義のようなので、クネビンフレームワークを紹介するドキュメントによって、若干の表記揺れがある。

単純な状況は、原因と結果の因果関係が誰の目にも明らかである問題領域だ。対応方法には必ずベストプラクティスが存在し、いずれを選択するかが重要だ。

この領域は、ソフトウェアエンジニアリングというより、アプリケーションを利用するシーンをイメージすると分かりやすい。

オンラインで開催される技術カンファレンスで、フロントエンド開発に関する5分間のライトニングトークを受け持つことになった。5分という短い時間とはいえ、トークだけで聴かせるのはなかなかハードルが高い。数枚のスライドを画面に映しながら話すことにしたので、プレゼンテーションソフトを使い、スライドを作り始めた。

ここでの意思決定プロセスモデルは、「把握 - 分類 - 対応（sense - categorize - respond）」だ。

• 把握 - ライトニングトークのハードルを下げるため、スライドを使う
• 分類 - プレゼンテーションソフトを使うことにした
• 対応 - スライドを作った

エンジニアっぽい例を挙げたが、経営者の視点での例を挙げるなら、IT化が進んでいない企業が業務改善を目的としてオフィススイートやグループウェアを導入するといったケースも、単純な状況に該当するだろう。

Complicated / 込み入った状況にある領域

「込み入った（Complicated）」は、「煩雑（Complicated）」と表記されることもある。

ここで扱う問題領域は、その原因と結果の因果関係を特定して適切な解決策を導き出すために、専門家の分析が必要になる。例として、業務システムの開発を考えてみよう。

事業規模の拡大によって非効率になった業務領域に対し、新たな業務システムの導入を検討している。ネットを使って様々なパッケージソフトを調べてはみたが、それらが問題を解決できるのかわからない。そこで、この業界を専門とするシステムコンサルに入ってもらうことにした。そして、コンサルによる業務分析の結果、いくつかのパッケージソフトを組み合わせ、カスタマイズした上で導入することになった。

ここでの意思決定プロセスモデルは、「把握 - 分析 - 対応（sense - analyze - respond）」だ。

• 把握 - 事業規模の拡大によって業務が非効率になった
• 分析 - 専門家による業務分析を行った
• 対応 - パッケージソフトを組み合わせ、カスタマイズした上で導入した

ここで扱う問題は、当事者にとっては未体験でも、業界にとっては未知の領域ではない。様々な人が何度も対峙してきた問題であり、その対応法が型化され、いくつかのプラクティスとなっている。そうして体系化されたナレッジを有している存在である専門家が、分析によって適切なプラクティスを選び出し、より具体化された対応法を提示する。

つまりこの領域は、不確実性が低く、予測可能性が高い領域だ。分析結果から得られた対応法が正しく問題を解決する可能性が高い。分析の品質が担保できればプロセスを後戻りすることもないので、段階的にプロセスを進めていくウォーターフォールモデルに向いた領域と言える。

しかし、ウォーターフォールでソフトウェアを作り上げた結果、ユーザーから「これじゃない」と言われたなら、対象としていた領域が実は複雑な状況であったのかもしれない。

Complex / 複雑な状況にある領域

「複雑（Complex）」は、前述した単純な状況や込み入った状況とは違い、その状況を生じさせている原因と結果の因果関係が、後になって分かる領域だ。その因果関係を見出すために、失敗しても影響が小さい実験を繰り返し、そこから成功パターンを見つけ出す。

コンシューマー向けソフトウェアプロダクトの自社開発を例に考えてみよう。

ユーザー調査によって、ターゲットユーザーの日常生活をより便利にするための方向性が見えてきた。それを新機能としてリリースすることはできるが、想定通りのユーザー価値になる保証はない。大規模に開発してリリースした結果、使われなければ無駄だ。そこで、ユーザー価値があるという仮説を検証する最小限の機能（MVP, minimum viable product）を作り、ユーザーに使ってもらうことで、ユーザー価値の有無を確認することにした。そして検証の結果、ユーザー価値が十分に確認できなかったため、仮説を組み直して新たに検証を進めることにした。

ここでの意思決定プロセスモデルは、「探索 - 把握 - 対応（probe - sense - respond）」だ。

• 探索 - MVP を作って検証した
• 把握 - ユーザー価値が十分に確認できなかった
• 対応 - 仮説を組み直すことにした

これは言うまでもなく、アジャイル開発系のソフトウェア開発方法論が得意とする開発プロセスだ。込み入った状況とは対照的に、不確実性が高く、予測可能性が低い領域であり、実験を繰り返すことで正解となるパターンを見つけ出すことを重視している。

Chaotic / カオスな状況にある領域

「カオス（Chaotic）」は、「混沌」と表記されることもある。

この領域は、その名の通りカオスだ。何が起きているのかを正確に把握することができない。状況は刻一刻と変わり続ける。得られる情報が断片的で、全貌が見えず、時間経過と共に様々な事象が検知され、報告されてくる。それ故、因果関係が明らかになることはなく、この段階で根本的な解決策を打ち出すことは不可能だ。

そもそも、解決策を見出すために探索したり、分析したりといった、そんな悠長な時間はない。止血することが最優先であり、とにかく、実効性のある一次対応を可能な限り打つことに集中する。そうして状況が安定してきたところで、ようやく根本的な解決策を見つけ出す活動に移行できる。

この状況をソフトウェアエンジニアリングの現場に当てはめてみると、真っ先に思い浮かぶのは、障害対応だろう。

企業向けに提供しているマルチテナントの SaaS プロダクトをアップデートし、新機能をリリースした。数時間後、ある顧客から「既存機能でエラーが出て、業務に必要なデータがダウンロードできない」という問い合わせが入った。他の顧客では同様の事象が発生していないようだったので、問い合わせのあった顧客が必要としているデータをひとまず手動で取得し、顧客に渡した。その直後ぐらいから、様々な機能からアラートが飛び始め、問い合わせが増え始めた。対応に追われ、社内はパニックだ。事象としては、いずれもデータベースとの接続で失敗しているようであった。しかし、調査・対策するにも時間がかかる。ひとまず今回のアップデートをロールバックすることで状況は落ち着いた。やはり、先程まで発生していた問題は、アップデートによる影響のようだ。被害状況を調査しつつ、原因の特定と対策に取り掛かった。

ここでの意思決定プロセスモデルは、「行動 - 把握 - 対応（act - sense - respond）」だ。

• 行動 - 手動でのデータダウンロードや、ロールバックなどの手を打った
• 把握 - ロールバックによって状況が安定したことで、アップデートによる影響であることがわかった
• 対応 - 被害状況の調査と、原因の特定と対策を進めた

このように、カオスな状況では、唐突に未知なる状況に追い込まれ、その緊急対応に追われる。

ソフトウェアエンジニアリングでは、カオスな状況を意図的に生み出すことで、前もって未知な問題への対応能力を高め、ソフトウェアシステムの信頼性をより高めようとする手法がある。それが、カオスエンジアリングだ。命名の由来は異なるようだが、「カオス」と名付けられている点が興味深い。

Disorder / 無秩序な領域

「無秩序（Disorder）」は現在、「混乱（confused）」と呼ばれているようだ。これは、現在の状況が、前述の四つの領域のいずれにあるのか、当事者が理解していない混乱した状態のことだ。そもそも、理解していないこと自体を本人が認識していない可能性もある。

この状態にある意思決定者は、自分の経験や好みに基づいて、意思決定プロセスモデルを選択する。よくある、アジャイル開発とウォーターフォールモデルの論争も、この辺りに起因しているのかもしれない。取り扱っている問題領域が複雑な状況にあるにもかかわらず、ウォーターフォールを採用している、といったように。さすがに、カオスな状況の中で、スクラムやウォーターフォールを使って問題解決しようとするなんてことは無いと思うが。

プロセスモデルや手法の選択は、個々のモデルの長所・短所や、モデル同士の比較だけで決定するのではなく、取り扱う問題領域がいずれの状況にあるのかを理解し、そこから導きだすべきなのだろう。

スクラムの祖 野中郁次郎との関係性

クネビンフレームワークの構築にあたり、David J. Snowden 自身が、一橋大学名誉教授の野中郁次郎らの著書『知識創造企業』に刺激を受けたと述べている点が興味深い。

He also recalls being particularly provoked by Ikujiro Nonaka and Hirotaka Takeuchi’s book The Knowledge-Creating Company around converting tacit knowledge into explicit knowledge and around the whole Socialization, Externalization, Combination and Internalization (SECI) approach.

野中郁次郎と言えば、一般的には書籍『失敗の本質―日本軍の組織論的研究』の著者の一人として知られているが、ソフトウェアエンジニアリングの世界では、「スクラムの祖」としての方が知られているのではないだろうか。スクラムを作り上げたメンバーの一人である Jeff Sutherland が、その着想を得る原点が、野中郁次郎らが1986年に Harvard Business Review で公開した論文 “The New New Product Development Game” だ。

実際、Jeff Sutherland は、スクラムに関する自著で、スクラム理論の中心として David J. Snowden が参考にしたものと同じ書籍『知識造像企業』の「SECIモデル」を紹介しているようだ。

このような点からも、クネビンフレームワークとアジャイル開発の間接的な関係性がうかがえる。Cynefin.io にも、アジャイル開発に関する次のような記述がある。

Alongside this, the Cynefin® framework "took off" in a world of "Agile" software development, coming together with the "Agile Manifesto" in ways which have been "a rich source of ideas and practice ever since."

最後に - 複雑な領域に挑む「攻め」の姿勢とイノベーション

不確実性が低く、予測可能性の高い環境では、新しいものは生まれない。不確実性が高く、予測可能性の低い、複雑な状況にある領域に挑んでこそ、イノベーションが創発される。では、その観点で日本の現状を見てみるとどうだろうか。

ガートナージャパンによる2018年5月の調査では、日本国内でのアジャイル開発の採用状況は 17% 程度にとどまっている。ウォーターフォールの採用状況である 43% と比較するとかなり低い状況だ。

これは、日本国内でのIT投資の対象が「込み入った領域」であり、よりイノベーティブな「複雑な領域」に踏み込めていない現状を表しているのではないだろうか。これが、日本のIT投資が「攻め」ではなく「守り」だと言われる所以だろう。調査結果からは、ウォーターフォール採用の縮小と、アジャイル開発採用の拡大が読み取れるため、これからは期待が持てるようにも読み取れる。

また、『DX白書2021』で、日本のアジャイル開発の採用状況をアメリカと比較してみると（『DXを支える手法と技術』p.213）、日本の 19.3% に対し、アメリカは 45.8% と、大きく差が開いている。インターネットの登場以降、GAFAをはじめとするアメリカのテック企業に日本企業が後塵を拝しているのは、ここに起因するのではないだろうか。

note.com

よく言われるように、世の中は否応なしに複雑化している。少なくとも、複雑な状況にある領域にも関わらず、分析に時間をかけて機能要件を網羅するようなソフトウェアプロダクト開発は、無秩序な領域にはまり込んでいると言わざるを得ないだろう。

note.com