こんにちは。CTOの八幡です。

今日は「仮説」について書いていきたいと思います。

「仮説」は英語では hypothesis と書きます。意味は「とりあえず正しいと見なす仮の命題」といったところでしょうか。皆さんも，意識的にせよ無意識的にせよ何か仮説を立てた経験があると思います。

普段の仕事の中でも，仮説を立てる機会というのは結構多いです。

• スケジュールを立てる時。
• タスクの時間見積りをする時。
• 企画を立てるとき。
• 何かの文書を読む時。
• 人の話を聞く時。

結構たくさんありますね。仕事をする上でもそれ以外でも，仮説の立て方を意識しておいて損はありません。

なぜ仮説を立てるの？

仮説というのは，現実をハッキリと理解するための道具です。現実を理解するための補助輪みたいなものです。現実を理解したいから仮説を立てます。

頭のなかに仮説を持っておかないと，情報は頭に入ってきません。右耳から左耳へ筒抜けです。
人間は「差異」によく気づく生き物なので，仮説と現実との差異を知覚することで，現実をハッキリと理解することができます。
小難しく言うと，インプットに対して自らコントラストを与えることで理解を促進する，とも言えます。

「良い」仮説ってどういうもの？

良い仮説は，現実を理解するための大きな助けになります。「仮説ではこうなるはずだったのに，現実はこうなった」というギャップやサプライズによって，よりハッキリと現実を理解することができるようになります。

どうやって仮説を立てるのか

仮説を立てるのは結構難しくて，かなり意識しないと良い仮説って立てられません。

最初はロジカルシンキングの手法をベースにしてみると，思考プロセスに迷いが無くなるのでオススメです。ただし，慣れないうちは「あれもこれも考慮しなきゃ…」と枝葉末節に囚われすぎて思考スピードが遅くなることもあります。練習あるのみです。

ロジカルシンキングのさわりを少し説明します。

ロジカルシンキングにはMECE（漏れ無くダブり無く）という言葉があります。何かを考える時は，MECEを意識しながら全体像をブレークダウンして具体化していく（＝ロジックツリーを作る）ことが大切です。ただし，「ダブり無く」を過度に意識しすぎると「これはダブってるかも」と心配になってアイディアを出せなくなってしまうので，仮説立案の初期段階では適度に気を抜いてゆる〜く行きます。

スケジュールを立てたり，タスクの時間見積りをしたりする時

スケジュールを立てる時は，とりあえず適当な目標を立ててみて，それを基準に比較しながら相対的に見積もって，微調整していきます。
人間っていうのは，相対的な見積りは得意なんです。
アジャイル開発手法のスクラムでも相対見積りを使うことになっていて，見積り手法のひとつプランニングポーカーでは，フィボナッチ数列（1,2,3,5,8,13,21,…）を使って見積りを行います。
「この機能を実装するのに何時間かかる？」と言われてもすぐには答えられませんが，「この機能を実装するのにかかる時間は，8時間未満？それとも8時間以上13時間未満？」と聞かれると，すぐに答えられますよね。

何かを読む時や人の話を聞く時

何かを読む時や人の話を聞く時は，「なぜそうなるのか？」「どうやってそうするのか？」と疑問をそばに置きながら，本を読んだり話を聞いたりします。
また，頭の中で概念図を思い浮かべながら情報をインプットします。例えば推理小説を読みながら，人物相関図を思い浮かべる，という感じです。
もちろん紙に概念図を書き出すのも効果的で，紙の本ならページの余白に図を書きながら読むのもおすすめです。
余談ですが，私は普段Kindle Paperwhiteを愛用していて，本にフリーハンドで書き込めないのだけが惜しいなあといつも感じています。ペン付きKindleが出たら即決で購入するんですけど…。

なぜこの記事を書いたのか

実は，今回「仮説」を記事にしようと思ったのは理由があって。
他の人にプログラミングを教えていた時に「プログラミングのデバッグが得意な人は，仮説の立て方も上手いなあ」と感じたからなんです。
「このプログラムはこの入力でこう振る舞うべきだ」と仮説を持ちながらデバッグできている人は，問題解決が速いような印象があります。
デバッグが下手だと自分で感じている人は，仮説立案を意識してみるとどうでしょうか。

そんなわけで，仮説というのは奥深いなあと日々感じています。どなたか，仮説立案勉強会を開いてくださったら是非参加したいです。