IT部門は戦略的IT活用の担い手たれ

理詰めで説得する技術

ビジネスマンなら「ロジカルシンキング」という言葉を一度は耳にしたことがあるだろう。　某トレーニング機関によれば、ビジネスマンに最も人気があるプログラムがロジカルシンキングだそうだ。　問題解決型、提案型人材が求められている時代にあっては、もはやビジネスマンの身だしなみとも言える技術だ。
今回は、ロジカルシンキングで最も有名である「ロジックツリー」の効率的な構成法を解説しよう。
 

MECEの罠

　「ロジカルシンキング」はものごとを論理的かつ順序立てて説明したり、複雑な問題を解き明かすために単純化、構造化する技術だ。　そして、「ロジカルシンキング」の代表的な手法が「ロジックツリー」であり、これらについては多くの書籍やWeb上で説明されいる。　しかし、実際にそれを作ってみると意外に難しい。　その原因のひとつがMECE（ミーシーまたはミッシー）である。
　MECEとは、Mutually Exclusive and Collectively Exhaustive　の略であり、「ダブリなく・漏れなく・全ての項目」を洗い出すことをいい、木構造を作るというロジックツリーの大原則である。　実際に木構造を作る際、この原則に則りさまざまな角度から仮設の理由を考えることは極めて重要である。　ただし、全てを洗い出しても、実際にそれを論証できるわけではない。　そこで、「MECEに従って考える」という作業は行うものの、実際の木構造については、論証可能な項目に絞ることが現実的である。　また、木構造は階層が深くなるにつれてネズミ講式に広がって行くため、あまりに大きな木構造を作るのは現実的ではない。
　そこで、現実的なツリー構造は、1項目を3〜4項目に分解して行くのが適当である。　2項目では少なすぎるし、5項目になると多すぎて消化不良を起こす。　具体的には頂点の1項目を下位の階層で3〜4項目に分解し、それを更に3〜4項目に分解する。　更に深い木構造にする場合は、これを繰り返して行く。

親子関係の罠

 

　ロジックツリーを作るうえで最も厄介な問題は、各項目の親子関係である。　なぜなら、ビジネスにおける課題は複雑に入り組んでおり、ある課題が別の課題を産み、その課題がまた別の課題を産み、その課題は大元の課題を更に引き起こすという循環した課題が絡み合っている。　こういった課題を厳密にロジックツリーに置き直すことは困難ある。　循環した課題をモデル化する手法として、コーザルループなどの手法があるが、これもかなり限定した領域でしか使えないことが多い。
　ロジックツリーでこれらの課題を扱う場合、論理展開の主題に立ち返って過去の本連載で解説した「結論から言うストーリーボード」の論旨に最も適する親子関係を定義することを心がけると良い。　現実とは異なるモデルに抵抗を感じる人もいるだろうが、複雑に入り組んだものをそのままの状態で表現しても解決策は見えてこない。　特定の解決策を前提に抽象化し、単純化したツリー構造に仕上げることが鍵である。　そもそもロジックツリーは複雑な問題を単純化、構造化することが目的であることを忘れてはならない。

ロジックツリーのヒント

　上記のやり方に従って、いくつかのロジックツリーを作ってみると、あることに気付くだろう。　それは、異なる課題であっても、その構造が意外にも似通ったものとなることだ。　木構造の上位は、企業の戦略や組織、マーケット、顧客など、非常に大きなくくりとなり、下位に行くに従って業務や組織、更にはその品質や時間、スピード、コストなどに詳細化されて行く。　つまり、一定のパターンのようなものがあることに気づくはずだ。
　コンサルティング会社では、方法論というものを開発し、それに従ってプロジェクトを進めることで、効率化や品質の維持をはかっている。　実は彼らが使う方法論とは、ここでいうロジックツリーを特定領域に絞ってテンプレート化したものをべースとしている。　ロジックツリーを頭を抱えながら作り上げて行くのではなく、あらかじめ雛型となる構造を作っておき、それを活用するということで、コンサルタントの能力差などのばらつきをなくし、短時間に一定レベルの成果をあげるのである。　そこで、以下にヒントとなる汎用的な分解方法を紹介しよう。
　「仮説」を最初に分解する際（第一階層の分解）は、大きなくくりとなるのが一般的であり、表1に示す視点から3〜4つ選べば、計画策定であれ、業務改善であれ、システム導入であれ、ほとんどのプロジェクトで使えるだろう。　ロジカルシンキングの解説書では、MECEで分解するよう指南しているが、実際にはここから3項目程度選ぶ方が現実的なものとなるはずだ。
 

第一階層の視点	視点の説明
戦略／方針	中期的なビジョンや戦略、方針などや業務遂行の上位概念
目標値	標利益やROA、ROEなど大目標となる数値や係数
マーケット動向	マーケットのトレンドや環境変化、技術動向など
顧客ニーズ	顧客満足、重要度の高いクレームなど
競合／競争	規制緩和や競合相手、新規参入者など
商品／サービス	自社または他社の商品やサービス、アフターケアなど
業務／主要プロセス	組織横断の主要プロセスやルール、内部統制など
スキル／知識	従業員のスキルや知識、およびその蓄積や伝承など
IT／システム	ハードウェア、ソフトウェア、ネットワーク、アーキテクチュアなど
文化／伝統	組織に内在する不文律や慣習、意識やカルチャーなど

 

　プロジェクトのテーマの大小によっては、表1の内容を全社ではなく部門や特定領域に限定して使うと良い。　本連載の第11回（前々回）　「コンサルの王道『仮説検証法』2」　や、第12回（前回）　「コンサルの王道『仮説検証法』3」　で活用した例を再掲して示してみよう。
 

 

上記の図1の例では、第一階層目の1項目　「1.情報システム部のスキルや知識が低いから」　は表1の「スキル／知識」を組織に限定して使っている。　同じく2項目　「2. ハードウェアやソフトウェアが陳腐化しているから」　は表1の「IT／システム」、3項目は「業務／主要プロセス」を使っている。
　第二階層以下については、第一階層の項目を表2の視点を使って分解すると良い。
 

第二階層以下の視点	視点の説明
コスト／価格	コストや価格などの財務的な価値基準
スピード／時間	早さ、所用時間、タイミング（時期、季節）など
品質	クオリティー、精度、エラーの少なさ、歩留まりなど
数量	要員数、商品数など力量を左右する数量の大小
組織／責任	組織の数や機能、役割分担、責任や権限など
業務機能	業務プロセス内の各機能や業務固有の機能など
教育	トレーニングや講師の力量、従業員育成に関する設備など
ノウハウ	独自の技術や特許、知識とそれを支える仕組み
労力／負荷	難易度や複雑さ、工数、手間など
ロケーション	商圏、立地環境、距離、物流要件など

 

　例示の図1の第二階層は、表2の視点である業務や組織などやその品質、コストについて分解していることが解るだろう。　このように、表1や表2の視点をヒントに使うと効率的な分解ができるのである。　そしてこれらの項目がバランス良く配置できれば、結論となる「仮説」が誤っていても、本連載の前回で解説した仮説の修正が容易に行えるはずだ。

　以上、本連載の第10回から4回に渡ってコンサルタントの王道と言われる仮説検証法とロジックツリーを紹介した。　IT部門がこの技術を身につければ、更にこれを応用して、より経営に近い立場でIT導入を検討することが可能となるだろう。　そこで次回は、経営の根幹となるマネジメント・システム（経営の仕組み）に話を進め、より経営戦略の視点に立ったIT要件の確定方法を解説しよう。