【”考え方”を考える】フレームワークの活用：6バブル(Six-bubbles)の応用

活用する　と　都合よく変える　は違う。

前回ご紹介した通り、シックスバブルと言うのは、世界有数のコンサルティングファームであるアクセンチュアが、少なくとも2000年代前半くらいまでは活用していたフレームワークです。（基本的な説明および、それを「如何に読み解くか」という考え方・アプローチについては、前回記事をご参照ください。）

本日は、それを踏まえ、「実際のプロジェクトにどのように適用するのか＝フレームワークの活用の具体例」をご紹介します。

実際に、どう使うか

このフレームワークは「ビジネス運営の全体像」を定義するのに適している、と前稿でも述べました。

ビジネス運営の全体像を捉える必要があるシチュエーション、即ち「改革の方向性」であったり「課題の抽出・整理　および　その改善施策」を検討したりする場合に、このシックスバブル・フレームワークの活用が適していると僕は思います。

課題解決の視点で活用する

そこで、課題解決をする際に、このフレームワークをどのように使うかを考えてみましょう。

まず、課題を抽出します。課題抽出の方法は色々ありますが、一つには「プロセスに砕いて考える」というのがオススメです。（関連記事：プロセス思考のススメ①）そこで、様々な課題を抽出した上で、シックスバブルの各セグメントにマッピングしていきます。これだけでも、十分、「フレームワークを活用した」ことになるわけですが、それではあまりに芸がありません。型通りなぞっているだけ、という感じがします。

もう一歩、踏み込む＝課題を何のために洗い出したのか？を考える

そこで、マッピングしたものを眺めながら、もう一度、目的に立ち返って考えてみます。

おそらく、最終目的は、前稿の末尾で述べたように「Behaviorの変化」であるのではないかと思います。そうすると、各種課題は「Behaviorの改善＝ビジネス運営の”リアルな場面”での日々の改善による効果創出」というゴールを目指して設定されるべきです。

つまり、洗い出された様々な課題は、本来的に、Behaviorを変化させるための課題（裏返せば、Behaviorが望みどおりの形になっていない原因）になっているハズです。要するに「Behaviorの課題」は「それ以外の課題の結果、解決されるべきもの」であるハズです。

（参考）もう少し、具体的に言うと・・・

ちょっとお話が抽象的なので、非常に卑近な例で。

例えば「Behaviorの課題」が「メンバーがやる気を出してくれない」「メンバーが納期を守らない」「売上目標に対するコミットメントが低い」などだとしましょう。これらを直接的に改善するのは非常に困難です。（「毎日、やる気を出せと言う」「納期を守ったらインセンティブを払う」「売上目標を達成しろとはっぱをかける」などの打ち手は、効果が薄そうです）

そうすると、その解決策は、「個人別のミッションの明確化と目標の共有を行う（Human Resources領域）」「納期管理のためのPMOを立てる（Organization領域）＋ 納期管理のための日次MTGを実施して10項目のリストに従って進捗状況をチェックする（Business Process領域）」「売上結果に加えてパイプラインを管理する（Business Process領域）＋ 顧客リストを共有して提案資料作成等のバックアップ／フォローアップ体制を整える（Organization領域）」などの周辺領域に存在することになります。

つまり「Behavior領域の課題」は、抽出されたものの、直接的な解決策が存在しない、となることが多いと思われます。

目指す「ゴール」＝「結果」を外してみる

ということは、「Behavior領域の課題」は、解決すべき”ゴール”であり、多領域の課題を解決した”結果”として到達するもの、であるわけです。

そうすると、この場合においては「同じメッシュ・同じレベル感で敢えて語る必要が無い」と僕は思います。

そこで、思い切って、Behaviorを外してしまいます。

つまり、上図の右側の「ピラミッド構造」にしてしまうわけです。

ITと組織と人材が下支えする「ビジネスインフラ」となり、その上で「ビジネスプロセス（業務）」が回る。そして、当然ながら、「戦略」という最上位の概念が「ビジネスプロセス」「ビジネスインフラ」の全体整合性を確保する指針となる。というわけです。

そして（これがとても重要なのですが）、このピラミッドにマッピングした課題に、適切な打ち手を実施した結果、解決されるべきは（この図から消去された）「Behavior」であるということです。

また、ピラミッド構造にした際にも、それぞれの領域間のつながりが存在することを踏まえ、「戦略」⇔「ビジネスプロセス」間、「ビジネスプロセス」⇔「ビジネスインフラ」間（※正確には、ビジネスプロセスと人材は直結しない）、「ビジネスインフラ内の各領域」間での”連携不足の課題”がないか、ということも考慮すべきです。

尚、こういう視点は「いきなりピラミッドを描いた」場合には、思いつきにくい視点となりますので「既存のフレームワークを活用する意味があった」ということになります。

フレームワークを都合よく変えても「真理」はズラせない

フレームワークを深く理解し、自分なりに活用する、ということは、決して「自分の都合よい見栄えにする」ということではありません。

シックスバブル・フレームワークを、上図右側のピラミッドフレームワークに変更したからと言って、人材とビジネスプロセスが相互作用することはありませんし、ITがビヘイビアに直接的な影響を与えることもありません。また、当然ながら、ビヘイビアを変革する必要が無くなったわけでもありません。（誤解の無いように補足しますが、IT技術の進歩は、結果的にビヘイビアに大きな影響を与えます。しかし、それは「そういった高度なIT技術をビジネスプロセス上にどのように取り込み、最大限に活用するか」という「ビジネスプロセスのレイヤー」が間に挟まっているはずだ、ということです）

今回は、一つの例として「シックスバブル」を例に取り上げましたが、これは、BCGマトリックスであろうと、5forcesであろうと、3Cであろうと、4Pであろうと同じことです。全てのフレームワークには「それが指し示している真理」があります。これらのフレームワークはどれも非常に切れ味鋭いものですので、その真理を（たとえ間違っていても良いので）自分なりに解釈し、齟齬が無いように理路整然と説明できる状態にしておかないと、斬りたくないものまでぶった斬ってしまって大怪我をしかねません。所謂、生兵法は怪我のもと、という奴ですね。はい。

「定番」「定法」と言われるフレームワークも、「知ってる」からといって油断せずに、きちんと一度立ち止まって「本当に、自分の言葉でちゃんと説明できるのか」と考える癖をつけることが、フレームワーク活用の第一歩だと思います。