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

仮説の修正で結論をブラッシュアップ

経営企画部を凌駕するテクニック、その王道が大手ブランドから町の中小まで、コンサルタントと名の付く者なら必ず習得し活用している「仮説検証」である。　
今回も前回に引き続き、仮説検証法の実践手法を作業タスクに沿って解説して行こう。

 

仮説検証法の進め方（再掲）

　仮説検証法の一般的な流れをおさらいするため、図1に作業タスク流れを再掲する。　前回は下図の「1.仮説の設定」と「2.調査設計」について解説した。　今回は、「3.調査/分析の実施」以降に話を進めよう。
 

3.調査/分析の実施

　プロジェクトの外部から見ると、「3. 調査/分析の実施」からが作業のスタートに見える。　なぜなら、前回解説した「1.仮説の設定」と「2.調査設計」は、あくまでプロジェクト内のメンバーだけで実施する閉じた作業だからだ。　コンサルティング会社のプロジェクトでは、顧客側のプロジェクトメンバーが参加するのは、このタスクからになるだろう。
　前回解説した「調査設計」がしっかりできていると、このタスクは特に難しいポイントはない。なぜなら、「調査設計」で決めたデータソースと顧客の現状を比較するために、アンケートやインタビューを行うだけだ。　前回の調査設計を参考のために図2に再掲しておこう。
 

 

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

 

図2の「調査方法」と「分析方法」の項目をもう一度よく見てほしい。　比較分析するデータソースに「（社）情報サービス産業協会　基本統計調査」や「経済産業省　情報処理実態調査」、「（財）日本情報処理開発協会　情報化白書」といったオープンソース（官公庁やその外郭団体などが無償で公開している調査データやリサーチ情報）を活用している。
　これらのオープンソースは、調査結果だけを公開しているのではなく、使用したアンケートシートを巻末などに掲載している。　そこで、プロジェクトのスタッフは独自に調査項目を作るのではなく、公表されているアンケートシートから必要な項目を抜き出し、再構成だけで調査項目をまとめることができる。　具体的な作業としては、図2の1-1、1-2、2-2は人事部、1-3と2-1は情報システム部という具合に、調査対象の部門ごとに依頼内容や質問内容をとりまとめ、部門別の質問シートを作成する。　これらの作業は頭脳を使う仕事ではなく、体を使う仕事なので誰でもできる作業だ。　調査/分析内容が明確なので、プロジェクトが右往左往することはない。
　このタスクでの注意点は、調査の際に「仮説」が正しいかのように無理に結果を誘導したり、こじつけたりしないよう、ありのままの事実をまとめさせるようにすることだ。

4.仮説の修正

　調査/分析が終了すると、最初に立てた「仮説」が正しか検証する。　前回で述べたが、あらかじめ設定した「仮説」は間違っていてもかまわない。　なぜなら、このタスクで仮説を修正するからである。
　例えば図2 の例は、「内製化をやめ外部のスペシャリストにアウトソーシングすべきだ」というのが最終的な「仮説」だが、調査でいくつかの点が異なったとする。　例えば、図3に示すように1-1〜1-3の仮説が誤っており、「1. 情報システム部員スキルや知識が低いから」という仮説が立証できなかったとする。　図3の例では、情報システム部には問題はなく、ハードやソフトの投資を意志決定する経営陣やシステムを活用するユーザー側にあることが判明した。
　この場合は、優秀な情報システム部を持っておりアウトソーシングする必要はないので、仮説を「ハード/ソフト面を刷新すると共に、経営陣やユーザーのリテラシーを向上し、システムの効果的活用を推進すべきである」と変更して、十分に活かされていなかった情報システム部門の能力を発揮させるという結論となる。
 

 

　それでは、仮説がことごとく間違っていた場合はどうなるだろう。　図4の例は、全ての仮説が証明できなかったケースだ。　このケースでは、情報システム部のスキルが高く優秀な人材が多くいる。　そして、システムの最新の技術を利用しており、ユーザーのリテラシーが高くシステムを効果的に活用できている。
　こういった場合は、仮説を全面的に作り直し、「貴社はシステムの効果的活用に優れ、スキルも極めて高いため、ITの事業化や外販などの新規事業を実施すべきである」という結論に修正する。
 

 

　このように仮説が誤っていた場合、改めて再調査を行うのではなく、結論部分を事実に合った内容に修正することで戻り工数がなくスケジュール通りプロジェクトを終えることができる。

5.成果物の完成

最後の「成果物の完成」タスクは、今までの作業を報告書にまとめる作業だ。　ここで重要なことは報告書のストーリーボード（報告のストーリー展開やシナリオ）だ。　これについては本連載の　≪その7≫経営陣を説得するストーリーボード1と≪その8≫経営陣を説得するストーリーボード2で詳しく説明しているので、そちらを参照いただきたい。
　いくらしっかりした調査を行い、すばらしい結果をまとめることができたとしても、このストーリーボードを誤ってしまうと悲惨な結果に終わってしまうことが多い。　「結論から述べる」というやり方は調査設計で作った木構造と基本的に同じであるため、ストーリーボードの組み方さえ間違えなければ、このタスクについても特に苦労はない。

　ここまでで、コンサルティングの王道と言われる「仮説検証法」の具体的な進め方を解説した。　企業の戦略であれ、業務改善であれ、ITの導入であれ、「仮説検証法」はどんなプロジェクトでも適用でき、多くのコンサルタントが実践している手法だ。
　しかし、実際にやってみるとうまく行かないことが多いだろう。　特に、仮説を分解して木構造を作る部分がこの手法のミソであるが、ここが難しい。　そこで、次回はコンサルタントのテクニックを苦労せずに盗むため、木構造を簡単に作れるヒントを紹介しよう。