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

仮説検証法の鍵！「仮設定義」と「調査設計」 

経営企画部を凌駕するテクニック、その王道が「仮説検証」である。　前回、結論は「見つける」ものではなく、「創造する」ものであり、あらかじめ仮設を設定することの重要性を説明した。
今回から2回にわたって仮説検証法の具体的な進め方について解説して行こう。　　ビジネスの課題解決にITが多用される今日、ITに関与する者なら仮説検証法は必須の基本技だ。　ぜひ習得していただきたい。
 

仮説検証法の進め方

　仮説検証法の一般的な流れは、図1に示すタスクとなる。　この図を基に、順を追って各タスクの内容を解説して行く。
 

 1. 仮説の設定

　タスクの最初は「仮説の設定」だ。　この「仮説」とはプロジェクトの「結論」である。　調査や分析をしないうちに「結論」を仮決めするのは乱暴だと思うかも知れない。　しかし、前回に解説した通り、仮説がなければ調査や分析の範囲が確定できない。　では、情報が少ない状況でどのようにして仮説を決めるのか？　実はこの作業は非常に難しい。
　このタスクは論理的な作業ではなく、直感的で右脳を働かす部分だ。　だからこそコンサルタントは豊富な経験や知識が必要であり、頭脳の良さが要求される。　とは言え、やみくもに「仮説」を設定するのではなく、複数のメンバーで検討を行い、考えうる課題や問題点を列挙して、妥当な解を検討する。　外資系の大手コンサルティング会社では、各専門分野で豊富な経験を持つマネジャーやパートナー（役員）クラスを集めて討議することもある。　また、コンサルタントを使い慣れた顧客の場合、あらかじめ仮説を提示してくることもある。　いずれにしても、最初の段階で可能な限り効果的で現実味のある「結論」を創り出すことがこのタスクの最も重要なポイントだ。
　なお読者の中には、「この仮説が間違っていた場合、プロジェクトが失敗するのではないか？」と心配される方も多いだろう。　しかし、実はこの段階で設定する「仮説」は誤っていても問題はない。　もちろん、仮説が正しいに越したことはない。　しかし、誤っていても後ほど解説するタスクで修正するため、ここであまり神経質になって膨大な時間を費やす必要はない。　むしろ、プロジェクトに参加するスタッフが皆賛同できる「結論」を描く方が重要だろう。　なぜなら、後の調査/分析タスクはプロジェクトのスタッフ達が分担して行う。　このスタッフ達が「仮説」をしっかり理解し、適切な調査や分析を行うことが重要だからだ。
　仮説検証法をより理解いただくため、図2にインテリア用品や雑貨の中堅専門商社の具体的なプロジェクト例を示した。
 

 

依頼企業の 戦略	大手取引先が中国とのダイレクト取引を加速しており、当社の存在意義が薄れている。　伝統的な「卸売」から脱却し、情報システムを武器にサプライチェーンの一部として独自の立場を確立したい。
依頼内容	当社は創業以来、情報システムを内製化してきたが、変化の激しい環境の中で最新で適切な技術やシステムを効率的に活用できているか、また情報システム部の要員数やスキルなども適切であるか不安である。　今後、当社が情報システムを武器として競争優位を確率するためにも、当社の情報システムのあり方について検証してほしい。
仮説（結論）	貴社は情報システムの内製化をやめ外部のスペシャリストにアウトソーシングすべきである

 

 

この会社の経営陣は、今後の戦略として情報システムを武器にしたいと考えているが、自社のシステムやそれを開発・管理している情報システム部の実態を知りたいと考えている。　この例は、結論として「内製化を止めて外部のスペシャリストにアウトソーシングすべき」という仮説を立て、いくつかの理由を想定している。
 

2. 調査設計
 

　次のタスク「調査設計」は、「仮説」を論証するための調査・分析を計画する作業だ。　調査設計は図3に示す通り、「仮説」を頂点に「なぜ？」という理由を繰り返して木構造を構成する。　いわゆる「ロジック・ツリー」と言われているものだ。
 

 

 

　この木構造は、一般的に1つの親に対して3〜4つの子を配置して行く。　3〜4つである理由は、2つでは論拠が弱く、5つ以上だと消化しきれないからだ。　そして、この木構造の一番下にくる項目全てが調査／分析の項目となる。
　なお、ロジカル・シンキングなどの指南本は、この木構造を「MECE」（ミーシー = Mutually Exclusive Collectively Exhaustive の略）と言って、ダブリがなく漏れがないように構成するよう指導しているが、それは現実的ではない。
　仮説を漏れなく細かに分解したところで、現実にそれを全て調査で証明することはなどできない。　実際には、最も説得力のある項目3つ程度を3〜4階層まで作れば良い。　論理的に筋が通り、調査可能な項目で構成されるよう作るのがコツである。
　また、階層の深さについては、プロジェクトの期間や予算に合わせるようにする。　この木構造が深ければ深いほど調査項目が多くなり、浅ければその逆となる。　つまり、時間的・経済的に余裕のあるプロジェクトの場合、この構造を深くしてより綿密な調査を行い、逆に短期間かつ安価に終わらせるプロジェクトは浅い木構造にする。　ここで注意が必要なのは、プロジェクトの規模に合わせるのは深さによって詳細さを調整するだけで、上位の構造は基本的に変わらない。
　この木構造を作る作業も、複数のメンバーで課題を列挙し、親子関係を定義して行く。　親の項目は大きな包括的な理由で、子に行くほど詳細な理由で構成する。　ただし、この作業もある程度の熟練が必要だ。　特に原因と結果は複雑に入り組んでおり、ある課題の原因が別の課題を引き起こし、「鶏と卵」のように親子が判断できないものがある。　このため、きれいな形の木構造が作れないと感じるだろう。　しかし、この作業は割り切りが必要であり、どちらかを親に決めてしまう。　報告会で最も論理的な説明となるよう「創り上げて行く」ことが重要だ。
　図2の例示をこの木構造にしたものが図4である。　ここでは、アウトソーシングすべきという「仮説」の理由として「1.情報システム部員のスキルや知識が低いから」と仮定している。　そして1-1〜1-3で更にスキルや知識が低い理由を「給与水準が低い」とか、「教育に限界がある」と仮定している。
 

木構造が完成したら、最下位の各項目をどのように調査するか、その方法もここで確定する。　図5に図4の木構造の最下位をどのように調査し分析するかという調査設計の具体例を示そう。
 

 

＃	結論の理由		調査方法	分析方法
1	スキルや知識が低いから
	1-1	給与水準が低く辞めてしまうから	人事部から給与データを入手する	「（社）情報サービス産業協会　基本統計調査」のモデル賃金と比較
	1-2	IT専業でない会社は教育に限界があるから	年間トレーニング費用のデータを入手する	「経済産業省　情報処理実態調査」の教育費を抜き出し比較
	1-3	ナレッジの共有や管理が行えていないから	情報システム部員へアンケートを行う	「（財）日本情報処理開発協会　コンピュータ利用状況調査」と比較
2	ハードやソフトが陳腐化しているから
	2-1	伝統的な旧言語で内製しているから	開発言語の現状をヒアリングする	「（財）日本情報処理開発協会　情報化白書」と現状を比較
	2-2	内製の要員がコスト高を招き資金を他の投資に回せないから	情報システム部の職種別の要員数を人事部に確認する	「経済産業省　情報処理実態調査」のアンケート「情報処理要員の概要」と比較
	2-3	・・・・・  ・・・・	・・・・・・・  ・・・・・・	・・・・・・・  ・・・

 

例えば、1-3のように情報システム部員全員に対してアンケートを行い、その結果をオープンソース（官公庁や業界団体などが、一般に対して無償で公開している調査結果や分析データ）などの信頼できる情報と比較するなど、具体的な調査方法と分析方法を決める。
　調査/分析方法の確定は骨が折れる作業だ。　プロジェクトのスタッフ達と手分けしてネットやデータベースサービスを駆使し、活用できそうなオープンソースを探すと良い。　そして、それぞれの項目について調査担当者や作業終了期限を決める。　このような調査設計を作ると、複数のスタッフで作業を分担し効率的に作業を進めることができる。　また、目的不明の情報収集やインタビューなど、無駄な作業や無意味な調査はなくなる。　何事も「段取り8割り」と言われるように、仕事の段取りを決めてしまえば8割方は終わったも同然だ。
　多くのプロジェクトは、最初の「仮説の設定」と「調査設計」をしっかりと作り込めば、方向性や作業内容、分担が明確となり、失敗することはまずない。　失敗プロジェクトの多くは、この最も重要な2つのタスクを軽視し、いきなり調査に入ってしまうのだ。

ここまで、仮説検証法の最も重要な最初の2つのタスクについて解説した。　次回は残りのタスク内容について解説して行く。