「仮説&検証」は、コンサルタントであれば基本のキともいえる考え方の1つで、業界界隈では普通に聞く言葉だ。
要は、まず仮説を立ててから調査を行い、結論を出す方法だね。
今回はその「仮説」について深堀してみよう。
仮説思考の手順とは?
仮説思考の手順を先に説明しちゃうね。
- 問題や課題を明確化する:まず、解決すべき問題や課題を明確にする。
- 仮説を立てる:問題に対して仮説を立てます。仮説は、事前の予想や推測ってこと。
立てた仮説は正しいかどうかはわからないけど、仮の方向性や仮定を持つことで調査の手がかりとなる。 - リサーチや調査を行う:立てた仮説に基づいて必要な情報やデータを収集する。
リサーチや調査の結果をもとに、仮説の妥当性を検証します。 - 仮説の検証と結論づけ:収集した情報を分析し、仮説が正しいかどうかを検証する。
もし仮説が正しい場合は、それに基づいて解決策や意思決定を行う。
仮説が間違っていた場合は、新たな仮説を立てて再度検証を行う。
以上のステップによる仮説思考は、事前の仮説を持つことで情報の収集や分析を効率化し、迅速な意思決定や問題解決を可能とするんだ。
また、仮説が誤っていた場合でも柔軟に修正し、新たな方向性を模索することができる特徴があるよ。
別記事で、「雲雨傘」(うんうさん)を説明したけど、覚えているかな?
- 事実(雲)を観察する:問題や課題について客観的な事実を確認する。具体的なデータや情報を集め、現状を正確に把握する。
- 解釈する(雨):事実をもとに、状況や要因を解釈する。問題の原因や背後にある要素を分析し、理解を深める。
- アクションを選択する(傘):適切な対策や行動を選びぶ。解釈に基づいて、問題解決や改善策を立案し、実行に移す。
だったね。
ここで、手探りで雲雨傘を実行するではなく、「仮」で雲雨傘を設定してから、1~3を進めましょうという話。
これは、以前説明した「アプローチを考える」ことにも通じるね。
仮の雲雨傘、仮のアプローチ・・・をまず設定して、そのあとで、実行、手を動かしましょうということね。
仮説思考の具体例
仮説思考がピンとこないかもしれないので、ITプロジェクトの例を見てみよう。
例1:アプリケーションのパフォーマンスが悪い・・・問題に対する仮説思考
仮説: アプリケーションのパフォーマンスを向上させるために、データベースのクエリの最適化が必要である。
アクション: 現在のデータベースクエリの実行状態を分析し、パフォーマンスの低下やボトルネックとなっている箇所を特定する。
その後、該当箇所の対策としてインデックスの追加、クエリのチューニング、データベース設定の最適化などの対策を実施する。
結果: パフォーマンス改善対策を実施した後、アプリケーションの応答時間やクエリの実行速度などの評価指標を計測し、仮説の効果を評価する。
例2: Webメディアのエンゲージメントが悪い問題に対する仮説思考
仮説:ユーザーの離脱率を減少させるために、ユーザーインターフェースの改善が必要であると仮定する。
アクション: ユーザビリティテストやヒートマップ解析などの手法を使用して、ユーザーがサイトやアプリケーションの使用中に直面する課題やボトルネックを特定する。
その後、改善点を洗い出し、ユーザーインターフェースの改良を行う。
結果: インターフェースの改善後、ユーザーの離脱率や操作エラーの発生率などのメトリクスをモニタリングし、仮説の効果を評価する。
例3:ITプロジェクトの進捗が悪い・・・問題に対する仮説思考
仮説: プロジェクトの進行状況を可視化するために、タスク管理ツールを導入することで、プロジェクトの進捗管理が改善されると仮定する。
アクション: タスク管理ツールを導入し、プロジェクトのタスクやスケジュールを登録し、進捗状況を定期的に更新する。プロジェクトメンバーはタスクの完了状況を報告し、管理者はプロジェクト全体の進行状況を確認できるようにする。
結果: タスク管理ツールの導入後、プロジェクトの進捗状況や遅延の有無などをモニタリングし、プロジェクトの可視化と進行管理の改善度を評価する。
これはITプロジェクトの1つ例だけど、ITプロジェクトの性質や目標に応じて、さまざまな仮説を立てることができるよね。
ここで、重要なのは、仮説を検証し、データに基づいた意思決定・アクションを行うことだね。
仮説がないとどうなるか?
ここまで、仮説思考がどういうものか?はわかったと思うけど、逆に仮説を立てないとどうなるか?について考えてみよう。
仮説がないと、思い付きだったり、場当たり的な対処となってしまう。
つまり、運が良ければ、良い結論にたどり着くけども、運が悪ければ、悪い結論がでてきてしまうということ。
例えばITプロジェクトマネジメントであれば、仮説思考を使わないと、以下のような問題が発生するね。
- 不明瞭な目標: 仮説思考を使わないと、プロジェクトの目標や成果物があいまいになる。
目標が明確でないと、チームメンバーはどの方向に進めばいいのか理解しにくくなり、結果としてプロジェクトの成果物や納期の達成が困難になる可能性がある。 - 問題の見落とし: 仮説思考を使わないと、問題点や課題を見落としやすくなる。仮説思考は、プロジェクトの成功のために仮定や予測を立て、それを検証するプロセスです。問題を正確に特定せずに進めると、予期せぬリスクや障害が発生し、プロジェクトの進行に悪影響を及ぼす可能性がある。
- 無駄なリソースの浪費: 仮説思考を使わないと、効果的なアクションプランを立てることが難しくなる。仮説思考は、仮説に基づいた実験や検証を通じて、最も効果的なアクションを見つけ出すプロセスといえる。仮説を持たずに無計画に進めると、時間やリソースを無駄に消費する可能性がある。
- 学習と改善の欠如: 仮説思考を使わないと、プロジェクトの進行状況や成果に関する学習と改善が制限される。仮説思考は、仮説の検証を通じて得られたデータや洞察を分析し、次のステップや戦略の改善に活かすプロセスです。仮説を持たずに進めると、プロジェクトチームは成果を最大化するための貴重な学習機会を逃すことになります。
逆に、仮説思考を活用することで、目標の明確化、問題の特定、効果的なアクションプランの立案、学習と改善の促進などが可能となる。
これはプロジェクトマネジメントのレベルでもそうだし、目の前の自分のタスクのレベル(例:上司に資料作成を頼まれた)でも同じメリットがあるんだ。
仮説思考を身に着けるためには?
ここまで、仮説思考のメリット(使わない場合のデメリットも)を理解したよね。
最後に、どうやって仮説思考を身に着ければいいのかを説明しよう。
仮説思考を身に着けるためには、以下のステップを実践することが役立つよ:
- 問いを立てる: 仮説思考の出発点は、疑問や問題意識なんだ。
自分が解決したい課題や理解したい領域について、具体的な問いを立てよう。
例えば、「なぜこの業務プロセスが効率的でないのか?」や「どの機能がユーザーに最も価値を提供するのか?」など。 - 仮説を立てる: 問いを基に、可能性のある解決策や結論についての仮説を立てる。
仮説ってのは、確証ではなく推測や予想ってことね。
具体的な仮説を立てることで、方向性を持った考えを形成できるよ。 - 検証のための実験や調査を計画する: 仮説を検証するために、実験や調査を計画する。
データの収集や観察、テストなどを通じて、仮説が正しいかどうかを確かめる。
このステップでは、具体的な手法や計画を立て、実施可能性を考慮する。 - 実験や調査を実施する: 計画を実行し、データや結果を収集する。
実験や調査の過程で得られた情報は、仮説の検証や修正に役立つ。
また、定量的なデータだけでなく、定性的な観察やフィードバックも重要となる。 - 結果を評価し、仮説を修正する: 収集したデータや結果を評価し、仮説の妥当性を判断する。
仮説が支持された場合は、次のステップに進むか、アクションを起こす準備をする。
もし仮説が支持されなかった場合は、仮説を修正し、再度検証を行う必要があるよ。 - 繰り返し学習する: 仮説思考は終わりのない継続的なプロセスだ。
得られた結果やフィードバックを活かし、新たな問いや仮説を立てることで、さらなる学びと改善を続けることが大事。
そして、経験を積むことで、仮説思考をより深く使いこなすことができる。
このステップは世の中「すべての」問題に使える、抽象度の高いステップだよ。
ITコンサルの仕事だけでなく、プライベートな人間関係などの問題にも同じステップが使るってことね。
なので、日常的に思いついた疑問や解決したい課題について、仮説を立てることが、スキルの習得の近道だね。
ITプロジェクトにおける仮説思考の例
で、具体的にITプロジェクトに仮説思考を当てはめると、こういう感じ。
- 問題や目標を明確にする: まず、解決したい問題や達成したい目標を明確に定義する。これにより、仮説思考の方向性が明確になる。
- 利害関係者と話し合う: プロジェクトに関わる利害関係者と積極的にコミュニケーションを取り、彼らの視点やニーズを理解する。
利害関係者のフィードバックや意見は、仮説の立案に役立ちからね。 - 仮説を立てる: 問題や目標に基づいて、可能性のある解決策やアプローチについての仮説を立てる。
仮説は、確証ではなく推測や予測ということ。具体的な仮説を立てることで、プロジェクトやタスクの方向性を明確化する。 - テストやプロトタイピングを行う: 仮説を検証するために、テストやプロトタイピングを行う。これにより、仮説の妥当性や効果を評価できます。開発の早い段階で小規模なテスト・実験を行うことで、問題点や改善点を早期に発見できる。
- データの収集と分析: 実験やプロトタイピングの過程で得られたデータを収集し、分析する。
定量的なデータや定性的なフィードバックを活用し、仮説の妥当性を評価する。
データに基づいた意思決定が重要だ。 - 結果を評価し、仮説を修正する: 収集したデータや分析結果を評価し、仮説の妥当性や有効性を判断する。
仮説が正しい場合は、次のステップや次の問題に進む。
もし仮説が間違っている場合は、仮説を修正し、再度検証を行う。 - 継続的な学習と改善: 結果やフィードバックを反映し、新たな問題や仮説を立てることで、プロジェクトを改善していく。
チーム全体で学びを共有し、持続的な改善を促進する。
とはいえ、仮説思考って難しい
ここまで、仮説思考の内容と実際に身に着けるためにどうすればいいかを説明したよ。
が、とはいえ、そんなにホイホイ仮説を立てられたら、みんなコンサルになってるよ!と思う人もいるかもね。
実際、僕が1年目だったら、そう思っちゃうね。
じゃぁそれに対して仮説思考をしようか。
仮説が立てられない問題というのは、それ仮説=ストーリーを立てるための、ストーリーの引き出しが少ないからという仮定を置く。
少ないというのは量もそうなんだけど、質=絶対的な抽象度レベルが低いという理由もある。
だから、ストーリー(仮説のテンプレート)の量か質を上げれば、問題は解決すると仮定する。
ここで、質(抽象度)を上げるというルートAはそれなりに時間がかかるけど、ルートBの絶対量を増やすことはすぐにできる。
それは、自分で調べたり、人に聞くということ。
そもそも、テンプレートとなるストーリーがないのに、ゼロからストーリーを考えろというのは難しいし、時間の無駄。
ゼロをどうイジっても=何をかけてもゼロだからね。
つまり、仮説思考で使える材料=ストーリー・テンプレのバリエーションがなければ、仮説ができない。
なので、「仮説を考えてもってきて」と上司に言われても、無理なものは無理。
その場合は、正直に「仮説が思い浮かびません、どのような仮説が考えられるか、いくつか例をもらってもいいですか?」と
上司に相談しよう。
上司に聞くのはダサイと思うかもだけど、自分の実力を直視できないのが一番ダサイからね。
自分の実力を直視して、教えを乞う姿勢は勇気がある=カッコイイと思うんだけど、どうかな?
小学1年生がプライド持ってたら、別にいらないのにな、って思うよね。
それと一緒で社会人1年目でプライド持ったり、カッコつけるだけ時間の無駄だと思うんだよね。
逆に、遠慮せず、どんどん僕(上司)を使え、考えをパクった方がタイパがいい。
守破離の守でもあるしね。
なので、仮説思考を身に着けるために必要な事とは、仮説を立てずにまず聞く事。
これが重要なので、覚えておいて。
え?それだと上司に怒られる?
まぁ、少しはググってから聞いた方がいいかもとは思うんだけど、怒る上司であれば逃げたほうがいい。
その上司はそもそも仮説できない人か、できるけど部下に教えることができない人だろうからね。
部下のサポートをしてくれる上司を選ぶようにしよう。
そもそも、無理に合わない上司の下にいる必要はない。
苦行が好きな人ならそういう上司の下で歯を食いしばって頑張ってもいいと思うけどね。
が、そういうタイプじゃなかったら、さっさと逃げよう。
そして、仮説思考を教えてくれそうな人を探すってことだね。
人間関係の試行回数を増やすということだね。
では、今日の仮説思考の学びはここまで。
お疲れさまでした。