プロジェクト中にトラブルが発生したとき、「なぜ発生したのか」と原因探しから始めて、解決するための対策を立てた経験はありませんか？
これは「ギャップ・アプローチ」と呼ばれる問題解決の手法ですが、問題の種類によってはこの手法が最適でない場合もあります。
そういった問題の種類を分別する手法が「クネビンフレームワーク」です。
本記事ではクネビンフレームワークの概要と、スクラム開発を導入する際の活用例を紹介します。
この記事を読むことで、プロジェクト中に問題が発生した際、迅速に対応方針を整理する方法を理解できるようになります。
問題発生時にスムーズに対応できるようになりたい方は、ぜひご一読ください。
クネビンフレームワーク(Cynefin Framework)とは
クネビンフレームワーク(Cynefin Framework)とは、問題の種類をその性質によって分類し、それぞれの分類に対してどのように考え、行動すべきかのプロセスを体系づけたものです。
1999年にDaveSnowden（デイブ・スノーデン）がIBM Global Services社で働いていた際に提言し、フレームワークはその後も進化を続けています。
クネビンフレームワークの分類
クネビンフレームワークでは、問題発生時の状況を上図のような「4象限」と「無秩序」に分類しています。
それぞれの状況について解説します。
明確(Simple)/単純な状況
明確(Simple)は、誰の目にも原因と結果の因果関係が明確な状況です。
それゆえ対処法も分かりやすく、問題を作業者が感知し、分類した上で対応することができます。
また、問題発生の予測が可能とされています。
この場合は「把握 – 分類 – 対応（sense – categorize – respond）」の順で対応することで問題解決を図ることがベストとされています。
事例として「社内への新しいセキュリティソフトの導入」の意思決定プロセスを挙げます。
- 把握 – 社内のセキュリティソフトが古いため、別のセキュリティソフトを導入する。
- 分類 – A社のセキュリティソフトを使用することにした。
- 対応 – A社と契約し、社内PCにセキュリティソフトを導入した。
なお、2022年5月現在は「明白（Clear）」と呼ばれています。
しかし、日本語での名称は明確に定義付けされておらず、文献によっては若干の表記ゆれがあるため注意しましょう。
困難(Complicated)/込み入った状況
困難(Complicated)は、専門知識によって感知、分析した上で対応することが必要ですが、論理的に原因を探していけば必ず1つ以上の解が見つかる状況です。
また、問題発生の予測が可能とされています。
この場合は「把握 – 分析 – 対応（sense – analyze – respond）」の順で対応することで問題解決を図ることがベストとされています。
事例として「PCの故障」の意思決定プロセスを挙げます。
- 把握 – 使用していたPCの動作が重くなり、操作がまともにできなくなった。
- 分析 – 専門の修理業者に故障の原因を調べてもらい、部品が故障していたことが分かった。
- 対応 – 部品を交換した。
この領域の問題は、当事者は未体験であっても過去に様々な人が何度も対応してきており、そういった人々によるベストプラクティスが既に存在します。
そうした知見を持つ専門家が分析によって最適な手法を選び、提示することで解決されます。
つまりこの状況は不確実性が低く、予測可能性が高いため、適切に対処すれば必ず解決できます。しかし、真因を追及できず、他の部分に手を打っても、問題は解決されないため注意が必要です。
複雑(Complex)/複雑な状況
複雑(Complex)は、様々な原因が交錯しており、原因と結果の因果関係が後から判明するような状況です。
原因の究明には、専門家による実験・精査を繰り返していく必要があります。こうした性質から、問題発生の予測が不可能とされています。
この場合は「探索 – 把握 – 対応（probe – sense – respond）」の順で対応することで問題解決を図ることがベストとされています。
事例として「売上減少の原因究明および改善」の意思決定プロセスを挙げます。
- 探索 – 社内で調査チームを組み、昨年の売上状況と環境要因から、相関関係を分析した。
- 把握 – コロナウイルスの影響で実店舗の売上が下落していることが判明した。
- 対応 – 実店舗に足を運ぶ必要が無い、オンラインに対応したサービスをローンチした。
実際のビジネスの場に起きる問題は予測不可能なことが多く、この領域にあたることが非常に多いです。
混沌(Chaotic)/カオスな状況
混沌(Chaos)は、想定外の問題が突発的に発生し、何が起きているのかすら正確に把握することが難しく、すぐに対応する必要がある緊急性の高い状況です。
この状況では原因を究明することよりも、まず考えられる対応から順次取り組み始める必要があります。
とにかく目の前の事態に即効性のある一次対応をすることを優先し、事態が安定的になったタイミングで原因を考えていくことが重要です。
この場合は「行動 – 把握 – 対応（act – sense – respond）」の順で対応することで問題解決を図ることがベストとされています。
事例として「システムの障害対応」の意思決定プロセスを挙げます。
- 行動 – 手動でデータを取得し、ロールバックを行った。
- 把握 – ロールバックによって状況が安定したことで、アップデートによる影響であることが判明した。
- 対応 – 問題となっている箇所を修正し、被害状況の調査と、原因の特定と対策を進めた。
混乱(Discorder)/無秩序な状況
混乱(Discorder)は、前述の4つの領域のどれにも分類できていない、混乱した状況です。それどころか、問題が発生していることすら、当事者が認識できていない場合もあります。
この状況の場合、意思決定者は自身の経験や嗜好に基づいて対応方針を決定していくことになります。対応方針は、まず問題が前述の4領域のどれにあたるのかを決定してから行動すると良いでしょう。
クネビンフレームワークの活用例：スクラム開発導入の有効性を判断する
クネビンフレームワークの概要が理解できたところで、具体的にどのような形で活用されるか把握していきましょう。
ここではスクラム開発(※)を導入する場合の有効性を、クネビンフレームワークを使用して判断していく例を紹介します。
※スクラム開発とは?
ソフトウェア開発手法における、アジャイル開発手法の1つ。反復という短い開発期間単位で開発を進めることでリスクの最小化を狙う手法。開発の1つの期間単位を「スプリント」と呼び、1週間〜1ヵ月程度の期間に区切って作業を行う。
スクラム開発が効果的な領域
スクラム開発は、複雑(Complex)な領域の問題を解決する場合に効果的です。
開発の場面では、前例のない革新的な新規開発や、既存のプロダクトに革新的機能を追加する場合が「複雑(Complex)」に該当します。そのような場合、短期間のスプリントを組んで開発するスクラム開発は、「複雑(Complex)の対応方針」である「探索 – 把握 – 対応（probe – sense – respond）」がうまく当てはまります。
予測できないことが起きたとしても、期間内に反復して開発を行うことで振り返ることが容易になります。
スクラム開発が効果的でない領域
スクラム開発は開発のすべての場面に用いられるわけではなく、別の対応方針が適している場合もあります。
スクラム開発が効果的でない領域は以下の通りです。
・明確(Simple)な領域
この場合は既に解決方法が定義されているため、スクラム開発を用いるよりも手順化したほうが効果的です。
・困難(Complicated)な領域
この場合は担当者が初めて問題にあたる場合であっても、専門家がいればベストプラクティスは導き出せます。よって、専門家を交えつつ、「明確」と同様に対応していくのが望ましいとされています。
・混沌(Chaotic)とした領域
システム障害対応や、プロダクトに致命的な不具合が発生した場合は緊急性が高く、素早い対応が必要となります。「緊急性が高い」とは、すぐに解決しなければ金銭的な損害や訴訟されるリスク等がある場合がこれに該当します。
こうした場合はスクラム開発のようにスプリントを組んだりしている余裕はなく、効果的でないとされています。
・混乱(Discorder)している領域
上記4つの領域いずれにも該当しないと思う場合は、まずどれかの領域に状態を変化させることを優先させましょう。混乱した状態でスクラム開発を進めることは難しく、効率的ではありません。
上記のほか、スプリント内で追加の開発依頼が多い場合は、スクラム開発にあまり向きません。
スプリントを設定しても、期間内でタスクが完了せず、頻繁にバックログの中身や優先順位を変更する必要があるためです。
こうした場合は「カンバン方式」の方が適している場合もあります。カンバン方式とは、チーム内の仕事の流れの最適化を重視した開発の手法であり、現在進行中の作業が完了すると、開発者が新しい作業を取り出すというものです。
今の領域がどれにあたるのかを考えながら、プロダクトに最適な開発手法を選択していくことが重要です。
参考ページ：【サルが書く】クネビンフレームワークを使って、関わっているプロダクトはスクラム開発が有用なのか判断する
クネビンフレームワークを問題解決に活用しよう
ビジネスの場において実際に起きる問題には、「完璧な解決策」が存在しない場合が多いです。それゆえ、既存の「原因を追究し、最適な問題解決を図る」という手法が通用しないことがあります。
多くの場合、問題を分類する前に原因追及をしてしまいがちです。しかし、原因が見つかる可能性が低い場合に、原因追及を優先することは非効率です。
問題が発生したら、まずはクネビンフレームワークを用いて「今の状況が何の種類に分類されるか、どのようなアプローチが最適か」を考えていきましょう。
ワークマネジメントツールの「Asana」では、問題発生時においても、チームの連携を重視したプロジェクト管理を可能にする機能を提供しています。
Asanaを使用することで、問題発生時の対応方針を決定する際の一助となることでしょう。
