仮説検証による問題解決のアプローチ

<<仮説検証による問題解決のアプローチ>>

今日は、仮説検証型のアプローチについて説明する。そこで、まず初めに別項の問題解決スタイルでも記述したが問題解決のテーマでの用語をもう一度確認しておきたい。問題解決関連の用語定義を記載する。

 

現象:できごと=出来事、 人間が知覚すること。 すべての物事。

問い:現象に接して起きる疑問、好奇心、新発見等。経営者の思い、消費者の違和感等

問題:解決すべき事柄、困った事柄。厄介な 事柄、解答を求める問い。試験などの問い。

課題:解決しなければならない問題。仕事や勉強の問題や題目

原因:ある物事や状態を引き起こしたもとになった事・出来事。

真因:事件・事物の本当の原因。

仮説:因果関係の推論の主張(XXの現象結果=問題が起こるのは、YYが原因だからではないか。YYの原因を排除するには、ZZの対策が有効ではないか。)

検証:フィールド調査やコンピューター・データ分析などで 証拠を集め仮説が正しいと 証明すること。

改善点:改善できた事項、もしくは、今後改善を要する事項。過去の反省を踏まえた、より良い成果を得るための変更点。

改善策:状況を改善するための方策。手段。手立て。

解決案:問題のある事柄や、ごたごたした事件などを、うまく処理すること。また、かたづくこと。疑問のあるところを解きほぐして、納得のいくようにするアイデア

実施:解決案を計画に従って実際に行うこと

評価:解決案の実施からでた事象について、その意義・価値を認めること、判断すること”

 

課題解決方法の種類

problem-98377_1280仮説検証の説明に入る前に、どのような問題解決の方法があるか、確認しておきたい。大きく分けると 仮説検証方法と、それに対するASISプロセス調査法がある。

ASIS調査法は、品質管理の手法と言ってもよく、不良品が多く発生するという問題に対して、生産管理の工程を体系的に究明し、要因を特定する方法である。製品に致命的な欠陥があり生産管理の工程のどこかに問題があるケースとか、航空機事故のような生命に影響があるようなケースについては、その実行プロセスにおいてどのような不具合があるのか丁寧に調査し、原因の究明が求められる。網羅性による信頼性の確保が重要視される。

一方、経営戦略やマーケッティング分野の課題などにおいては、解決のスピードを求められ、試行錯誤アプローチで多様な情報による証拠固めが可能で論理的説明力もつけやすいので、一般的に仮説検証の方が有効であると考えられる。

このように、仮説検証アプローチが採用されるかASISプロセス調査法が採用されるか、その目的に応じて判断されるべきである。そのほかに 類似比較による方法やデータ分析手法も言われるが、基本的には前述の2方法(仮説検証かASIS調査)に包含されると考える。本稿では戦略的な経営の課題を解決するという観点から仮説検証を主題とする。

利用ツールについて

flowchart-311347_1280課題解決のステップの中で各種のツールが登場する。たとえば「ロジックツリーとかブレーンストーミングとかKJ法とかデシジョンツリーテーブルとかポートフォリオ分析とか」である。色々なツールの議論はあるが、この論点はあくまでもハウツー議論であるので本稿では話題とはしない。

議論の中身品質が大事

課題解決では手順の話として、問題認識→調査分析→解決案策定→実施とステップが説明されるが、各ステップからもたらされるデリバラブルの品質の高さがさらに重要である。

なぜならステップを踏んでいても、その論理性や証拠説明力に欠けるケースが、日本社会には多くみられるからである。課題解決において何を決めそれに対して何をアクションするか。決定事項の品質レベルが大事なのである。

図:仮説検証による課題解決のアプローチ

hypo1

 

上の図を見てもらいたい。

仮説検証型のアプローチをフローチャート図で表現した。順番に見ていこう。

平常時 青色:A、( O、P、Q )

A:現状がある=日々の活動の中に 清々と出来事が起き過ぎ去っていく中、疑問や問いを思いつつも流している。head-113927_1280

最初は「現状がある」である。そして、経営者、担当者、外部コンサルタント、取引先の提案営業型営業マン。彼らは「これは変だ。ちょっと疑問だ。もっとこうしたいんじゃないか。」ということに心がけている必要がある。「なんでだろうー」、「なんでそうなるの?」、好奇心を持つことが一番大事である。いつも気づきを持つ人生を送ることである。

そのためには対象物(会社、事業、社会、生活など)に関心を持ち、好きであること。この部分は、まさに意識改革の世界である。日ごろから新聞、雑誌、TV、会話、会議などの刺激をうけて「考える」の習慣をつけておく必要がある(思考スタイル ロジカルシンキング 参照)。

問題定義 黄色:B、C、D

B:問い・疑問・好奇心がある(疑問を確信する、確かにおかしい!)

C:問題意識を持つ (これは解決しなければいけないという意識と意欲を持つ)

D:フィールドスタディ、データ解析 (実体がどのような物か できる範囲で調べてみる)

疑問や変だの気持ちが、「明らかにこれは解消しなけらば!」となればと問題意識となる。そこでは問題意識が:解決案策定への実行力に変換される必要がある。

実行力、行動力を持ち、誰かが調査をしたりアンケートとったり人に聞いたり問題の現場に行ったり、自分なりの意識で問題を定義する。経営者は日ごろから自社のビジネスに目配せをし、問題定義をするのが仕事である。そしてこの問題を解決しなければならないということ=すなわち課題となる。

analysis-227171_1280真因特定(原因究明) ピンク:E、F、G、H

E:問題定義 (解決すべき問題=課題が明確に記述される)

F:原因(因果関係)仮説設定 (問題と原因の関係性の仮説を考える)

G:原因 検証実施 (論理検証、データ検証)(仮説を自信を持って説明できるように証拠づけする)

H:真因特定 (原因の階層化も行う) (原因・真因を説明できる状態にする)

問題意識され、ここからが課題解決のスタートだ。これは問題定義、真因特定、解決案の確定と言うメインの道筋である。仮説検証アプローチでは、「仮説:この問題XX(結果)を起こしている原因はYYではないか、」と因果関係の推論するのが第一歩である。この仮説設定を円滑かつ効果的に実施するために使われるツールが、ブレーンストーミングであったりKJ法であったりする。
最初は、いくつかの推論が出る。それを論理的に考え、あるいはデータを使って検証する。すなわち、仮説を検証実施で説得性のある確かなものにするのが第二歩目である。

検証の実施には、論理検証(定性的検証)とデータ検証(定量的検証)がある。当然Dのフィールドスタディデータ解析である程度の証拠は積み上げているわけだが、まだあたりをつけた段階であり、十分な証拠で裏付けられているというわけではない。したがって、証拠を幅・深さともに固める必要がある。定性的検証では現場アンケートヒアリング店舗や工場の視察満足度調査プロセス機能検証等々色々なやり方で行う。データ検証は、各種のマーケティング手法を統計分析なので実施、実績データ文裏付けられた証拠がため行う。

推論は必ずしも正しくないので、検証過程において謙虚に論理と事実に向かい合うべきである。検証して誤っている部分は再度仮説検証の流れを実施する。

図の赤枠の部分は、仮説設定と検証実施のトライアル&エラーを繰り返すプロセス領域を示している。この仮説検証作業を繰り返して、中核の原因=真因は何か、取り巻く原因は何か、原因の階層が明確になる。

明確で説明できる「原因と結果の(因果)関係」が必要:

このように十分に納得の行く、誰からどの様な質問をされてもしっかり答えられる真因特定を行っておく必要がある。よくある失敗のパターンは仮説設定をした段階で「もうわかった」と誤解し、検証作業をおろそかにするケースである

すなわち仮説=真因と断定し話を詰めてしまうことである。このようなケースでは、後からいろいろな質問をされそれに論理的な回答ができず紛糾することになる。 (昨今のマスメディアでいろいろとでてきている社会問題などに多くの例がある)

solution-488976_1280解決案確定 ピンク:H、I、J、K

H:真因特定 原因の仮説検証作業で 真因と原因階層が特定された。

I:解決案候補リスト 仮説設定 真因を解決できるアイデア候補を仮説設定する

J:解決案候補に検証実施 論理検証・データ検証 解決案仮説の証拠づけを行う

K:解決案確定(主従・組合選択) 解決案のなかから有効な案を採択する。

通常、仮説検証は、真因を特定するアプローチといわれるが、本稿では解決案策定の段階においても活用するイメージで記述した。もともと仮説検証は用語定義でも説明したように「因果関係の推論」であるからだ。

解決案の対策候補はリストにして、いろいろなアイディアが発想されるべきである。真因ならびに階層化された原因に対して、ブレーンストーミング手法やDecision
Tree手法で解決案の候補が記入されてゆく。どうしたら変えられるか!どうしたら良くすることができるのか!を考える。議論する。考える。考える。発想する。(思考スタイル参照)

これらはYYの原因改善はZZの解決案で対応できるのではないかという1つの仮説設定である。そしてこの仮説に対してそれが有効か否か論理検証とデータ検証対象となる。この試行錯誤が行れた後に結果として解決案が確定される。

ここにおける複数の解決案の有用性に関する仮説検証は、すでに上記の図のDGで行われた論理やデータを活用しさらに強固な補習がなされていくわけである。billboard-63978_1280

データー検証のツールは、昨今のIT進化の恩恵を得て、マーケティングなどではPOS、ID-POS、Twitter、FBなど正規化、非正規化データのツールなどが代表的な例である。

重要な1つの解決案で、すべての課題が解決されればそれは幸福である。しかし真因はもともと主たる原因であるわけだが当然問題の現象を起こしている原因は階層化されている。従って対策も有効な打ち手が1つと限る訳では無い。いくつかの体系的な解決案が優先順位を持って実行されるような形になるであろう。

この解決案の組み合わせオプションが数種類ありこれを選択することになる。これを「主従組み合わせ選択」という表現でK:に表した。

パイロット 緑:L、M、N

L:パイロット計画 解決案の全面適用のまえにパイロットを行うこともある

M:パイロット実施 フィールドスタディ・データ解析 実施と同時にモニターする

N:最終意思決定 (微調整も含んで) 微調整で済めば大成功

最後に緑の部分であるが解決案適用において、最初から全社的をて実施することがリスクがあるときには、パイロットで実施することもあるだろう。たとえば 九州地区店舗で値上げするパイロット行うなどである。(もちろん実験的な検証はJの解決案候補に対する検証実施においても行われ、1店舗において棚割の配置を変えて1週間実験するなどである。)

パイロットは、 100%成功とはいかなくても、大きな失敗はできない実験ではある。従って解決案の策定以前においてかなりの完成度を求められる事だけは明らかである。

パイロット実施のフィールドスタディやデータ解析を行い最終調整を行うことになる。OKであれば最終意思決定ならびに本番実施である。万が一にもこの時点で結果が悪ければ、解決案の見直し、あるいは真因や原因の再検討まで影響与えてしまう。このようなことは避けたいものである。

平常時 青:O,P,Q(A)

O:本番実施 計画に従って清々と実施

P:解決案の適用が成功しているか モニタリング

Q:評価 解決案の仮説検証の通りか、上振れか 下振れか そして次への 問いに進む

最後に本番実施後は継続できモニタリングと評価が必須である。この評価は再び疑問を呈して更なる改善アプローチがスタートすることとなる。
<<短絡アプローチに注意>>

ここまでの説明で仮説検証すなわち因果関係の推論は2段階で行われた。問題定義→真因特定。真因特定→解決案確定。よくある失敗はこれを一連の流れで処理してしまうことである。

例示 「問題:ハンバーガーが売れなくなった → 原因:近所に格安バーガー店ができたから → 解決案:値下げしよう」  で いいのか。

opportunity-396265_1280例示 「問題:ハンバーガーが売れなくなった → 原因:価格て負けている or 店長・スタッフの態度で負けている or 清潔感で負けている or コンビニのコーヒーに客を取られている or 家庭での食事が増えているので夕方客が来ない」 など原因の仮説から 本当の原因・本質の原因=真因はなにかを証拠と論理でつかむ必要がある。「店員やスタッフの態度が悪く店も汚いことがアンケートや調査で判明した。」であれば、その真因にたいして、たとえば「スタッフ教育と清掃や陳列での清潔感対策をすることでどうか?仮説」を検証して意思決定すべきである。

すなわち、失敗のパターンは、問題定義→原因仮説→解決案候補=解決案確定と誤解することである。現場を踏んだ真因特定、データーに裏付けられた真因特定、十分に検証された解決案の組み合わせ、ではなく仮説設定を最終版と理解してしまう稚拙な行動である。たいていこのようなケースは客観的な物とはならず、リーダーの主観的な意思決定で間違ったアクションとされることになる。

もちろん、経営者がカリスマ的なリーダーシップを持ち自らの過去の経験と幅広い知見により、鋭い洞察ができる方であれば、検証実施という比重が少なくとも良いかもしれない。しかしながら、日本企業の経営者の多くは、合議制に基づいており、日々の業務オペレーション遂行に懸命に当たっているものの、未来に対する洞察力が鋭いわけでもないので、しっかりと課題解決の手順を踏んだほうがいいだろう。

 

<<提案営業における考慮事項>>真のソリューション営業

さて、営業も御用聞き物売り営業から、提案型ソリューション営業になれという話が良くなされる。しかし、別項目(問題解決スタイル項の図4)でも述べたが、ソフトウエアパッケージ導入販売をソリューション(解決)販売と言ってしまっているケースがあるが、これは間違いである。解決案を提示しているのではなく製品ソフト+導入工数サービスを足しているだけで、解決案はお客様が考え指示しているにすぎない。お客様において、顕在化している問題に対しては、解決案を一緒に考えない限り、ソリューションサービスとは言えない。RFPをいただいた時点でSIerにソリューション=解決案は無縁となる。顕在化している問題についてはお客様と一緒に考えないと解決案の提供という付加価値はつかない。しかし、そのような機会チャンスは、すぐれたコンサルティングファームでない限りなかなか巡り会えない。ではどうするか? お客様が気が付いていない段階、すなわち表の黄色=B,C,Dで営業レベルで検討し問題を提起するのが付加価値である。education-548105_1280お客様の経営者は絶えずこの問題発見の意識を持っていなければならないのだが、通常、明日の売上・・利益・キャシュに気をとられているものである。現場で、受注・生産・納品・債権回収のようなオペレーションをしている人たちはというと、気が付いていても、わざわざ自分から問題提起を起こしていく 余裕や気合はないのである。そこで提案営業の出番である。お客様の経営者が気づいていない、お客様の現場が提案できない問題意識を喚起し、さらには事前に調査をして問題定義の提案をすること。RFPをまって、他社との値引き競争状況になるのは避けたいものである。
宣伝でありますが、弊社は「考える力 営業力強化のコースプログラム」を提供してますので、ご興味のある方はご連絡ください。<<最後に>>

仮説検証型アプローチで主張されなければならない事は、検証をしっかりとやれということである。

仮説検証型が「仮説思込型(仮説を考えただけで結論を得たと思い込む形」にならないように!!

それから、騙されないために

仮説を、都合のいい証拠で塗り固めて、真説に見せかける方々も多いので 真贋を見抜く目を持とう!!

以上