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

「結論から言う」はプレゼンや報告書だけではない！

経営企画部を凌駕するIT部門のテクニック、その王道が「仮説検証」である。　「仮説検証法」とは最も基本的な問題解決手法で、超一流の外資系経営コンサルタントから町の中小コンサルタントまで、コンサルタントと名のつく者なら必ず学び活用する手法だ。
「仮説検証」による問題解決は、優れたプロジェクト報告書が作成できるだけではなく、無駄がないプロジェクトの作業タスクをスケジュールすることができる。　まさに一石二鳥のテクニックである。　ビジネスの課題解決にITが多用される今日、ITに関与する者なら習得すべき必須の基本技だ。
 

なぜプロジェクトが失敗するのか？

　政府、地域、企業、大学などでさまざまなプロジェクトが実施されている。　しかし、「プロジェクト」と銘打った活動の8割は失敗に終わると言われている。 ITにも「プロジェクト」はつきもので、改革/改善の旗印のもとにスタートする。しかし、システムを稼動させることが精一杯で、本来の目的である改革/改善を達成している例は少ない。こういった失敗プロジェクトには以下の症状が見て取れる。　本連載の読者はプロジェクトを経験したことがあるだろうが、以下のような症状はなかっただろうか。
 

1. 調査や資料作成、会議などの目的が不明であり、意味のない作業をやらされているように思う
2. 収集できる資料や情報はとりあえず全て集めるが、結局のところ活用されない
3. 次のタスク内容や作業手順が示されず、どこに向いて進んでいるかわからない
4. ユーザーなど関係者の意見によってプロジェクトの内容や進め方がよく変更になる
5. ユーザーがプロジェクトに対して懐疑的で非協力的である

 

上記の各項目に心当たりのあるプロジェクトは、失敗プロジェクトの典型だ。では、なぜこのような状況に陥るのだろうか？　答えは簡単である。　そのプロジェクトは最終的な「結論」が見えないままスタートし、底なし沼から抜け出そうともがいているだけで、どんどん深みにはまって行く。実は、プロジェクトにおいて最も重要なことは、スタートの段階で「結論」を描くことである。

本日紹介する「仮説検証法」は、あらかじめ「結論」を仮説として決めてから作業を行う手法である。　先にあげた失敗の症状が出ているプロジェクトは、ぜひこの「仮説検証法」を試していただきたい。　作業の目的が明確になるばかりか、無駄な作業を削減することができる。　そしてユーザーから信頼を得ることができ、協力的に接してもらえるだろう。

「結論から」はストーリーボードだけではない

本連載の7～9回で、「結論から言う」ストーリーボード（報告のストーリー展開やシナリオ）が重要であることを学んだ。　しかし、報告書を作成する時になって「結論」を決め、その理由を構成してもうまく行かない。　なぜなら、「結論」なしで膨大な情報や資料を集めても、その中に「理由」となるべき情報が含まれている保証はない。　また、インタビューやアンケートは、聞き方によって答えが変わることがあり、「結論」なしで行った調査結果は使えないことが多い。　つまり、「結論から言う」ストーリーボードは、今回紹介する「仮説検証法」でプロジェクトを進める必要があるのだ。

結論は「発見する」ものではなく「創造する」もの

　「仮説検証法」を解説する前に、「結論」についての誤解を解かなければならない。　誤解とは、多くの人がプロジェクトの調査などから「結論」が発見できると考えていることだ。　残念ながら調査から「結論」が発見できることはまれだ。　結論は「発見する」ものではなく、「創る」ものだからだ。　ただし、「結論」をねつ造しろと言っているのではない。　最も効果的で実現可能性が高く、聞き手が納得するような「結論」は、調査だけでは導けないことを理解してほしい。　以下に興味深い例を2つ紹介しよう。

1つ目は、数年前に新聞に掲載されていた記事である。　米ブッシュ大統領がイラクを「悪の枢軸」と宣言しイラク戦争が勃発した。　イギリスのブレア首相も大量破壊兵器の開発についてクロだと宣言した。　ブレア首相の情報源は、映画007で有名なSIS（秘密情報局）である。　しかし、SISの幹部はインタビューで次のように答えている。

SISのミッションは他国のさまざまな統計や情報を収集して本国に伝えることである。　我々は現地の情報をありのまま本国に伝えるが、決して何らかの意味づけをしたり、考えを盛り込んだりしない。　そして、ありのままの情報は、往々にして「そうとも言えるし、そうとも言えない」という内容である。　調査結果とは複雑で、入り組んでおり、それそのままで何らかの「結論」を導けるものではない。

結局ご存知の通り、大量破壊兵器は発見されず、ブレア首相は判断の誤りを認めざるを得なくなった。　ここで重要な点は、単に多くのデータを集めても、そこからの何かを「結論」づけるのは難しいという事だ。　調査結果から「結論」を導くのではなく、創った「結論」を証明するために調査結果を利用するのだ。

2つ目は、マーケットリサーチや統計学に詳しい方はご存じの通り、調査や分析はあらかじめ仮説が必要という例である。　あるデータマイニングのセミナーで、米国のスーパーでオムツとビールを併売したら良く売れたという有名な「オムツとビールの法則」を持ち出して、データマイニングによって思わぬ商品の組み合わせが発見されたと紹介していた。　これが事実であれば、かなり希なケースだろう。　データマイニングを使ったとしても、仮説なしに膨大なデータから何か発見できることはまずない。　発見できるとすれば、パンと牛乳や弁当とお茶など、誰もが知っている単純な組み合わせだけだ。　商品の売れ行きは、気候や陳列位置、品揃え数、価格、近隣の競合店の状況、時間帯、その時の客層など、さまざまな要因によって変化する。　この併売が個別販売より良く売れたと判断するためには、これらの条件も加味した特別の分析が必要で、偶然見つかるようなものではない。　こういった分析は、「オムツとビールを併売するとよく売れるはずだ」という仮説が先にあり、その後にテストを行い、分析によってデータで証明することになる。　つまり、先に仮説が必要という事だ。

上述した２つの例は、他のビジネスやプロジェクトにおいても同じだ。　ビジネスに影響を与える変数は実に多く、法律や規制、天候、地域特性、戦略、マーケティング、人材、品質、価格、取引先の力、競合の戦略などさまざまだ。　おまけに、これらは常に変化しており、今日の調査結果が明日も同じであるという保証はない。　このような状況で、当てもなく調査して「結論」を導き出すことが、いかに無謀であるか理解できるだろう。
仮説検証法を学ぶに先立って、調査や分析で自動的に「結論」が出るという誤解を捨て去ってほしい。　「結論」は創り出すものであり、調査や分析はそれを証明するための方法である。

指南本の嘘

計画策定や問題解決などの指南本も鵜呑みは危険だ。　例えば図1に示すプロジェクトのタスクは、事業計画策定などで一般的にみられる手順であり、読者も一度は目にしたことがあるはずだ。
 

実際にこの通り作業を進めても、うまく結果はまとまらない。　なぜなら、先に書いたようにビジネスに影響を与える変数は非常に多い。　また、事実とは複雑怪奇であり、「そうであると言えるが、そうでないとも言える」というような調査結果が多くある。　仮説の「結論」がなくこの手順で情報を集めても、そこから何か導き出せるわけではない。　実際は始めの段階で「結論」を仮説として設定し、それに沿って情報を集めたり分析をしたりしなければ答えは導けないのだ。

では、なぜこれらの指南本は最初に「仮説の設定」というタスクを記載しないのだろうか。　理由は簡単である。　一番始めに「仮説の設定」を持ってくると、「ではその仮説はどこから来るのか？」という問いに答えられないからである。

また、コンサルティング会社の提案書を見ても、最初に「仮説の設定」というタスクはない。　なぜなら、もしプロジェクトのスタート時点で「結論」があるということを明かしてしまうと、結論ありきの出来レースに思われてしまうからである。　また、コンサルティングの報酬は、作業時間（作業期間）に基づいて請求するのが一般的だ。　このため、できるだけ作業が多い方が（作業期間が長い方が）報酬額は多くなる。　スタート時に既に「結論」があると、長々と行う調査・分析作業でお金をもらうことができなくなる。　こういった理由から、指南本にもコンサルティングの提案書にも、「仮説の設定」という項目は削除されているのだ。

なお、こういった上流工程のコンサルティングは俗人的であり、複数メンバーで作業分担できないと言うプロジェクト・マネジャーがいる。　しかしそういったタイプは要注意だ。　なぜなら、このマネジャーは「結論」となる仮説が描けておらず、PowerPointやExcelの上でストーリーを考えながらプロジェクトを進めている。　このため、作業分担ができず、プロジェクトの進め方が決まらない。　これは失敗プロジェクトの前兆である。　「仮説検証法」を使えば、何ら問題なく複数のメンバーで作業分担できるし、進め方も明確になるだろう。
次回以降でこの「仮説検証法」の具体的な進め方を詳しく解説して行こう。