仮説
開発を進めていると「あれ？これってどうやればいいのかな」と度々躓くことがあります。
何事にも共通しますが、常に思い通り上手くいくことはないでしょう。
失敗とたまにある成功を繰り返して知識は積み重なっていくものだと思います。
誰しもが手こずり、少しずつ成長していくものです。
この手こずることを今回の記事では「課題」と書くことにしましょう。
さて、この「課題」を解決するうえで最も大切なことは何でしょうか？
私は「仮説をもつこと」だと思っています。
「仮説」を持っていない場合「何が問題なのか」というポイントが不鮮明になり、解決するためのハードルは非常に高くなります。
これは「だれかに質問をする」というシーンでも同様です。
質問するときにも「仮説」は必須
だれかに質問をして、回答から解決の糸口を見つける
これも一種の課題解決のアプローチです。
解決の糸口を明確に示してもらえば非常に楽ですが、質問の受けてから、自分にとってほしかった回答をもらうためにも「仮説」はなくてはならないものといえます。
「質問をする」となると、相手方に解決を委ねるように見えますが、質問に対し助言をする人に
- 何を達成したかったのか
という目的を伝えたうえで - どのようなアプローチをしたのか
というHowとWhyがわからないことには回答に悩みます。
ここがない場合、質問と回答のキャッチボールが成り立たず、
- 質問の受け手に意図を考えさせえる負担
- 前向きに回答しようという動機の喪失
- 的外れな回答をさせてしまう
上記のようなネガティブな動きが生まれてしまいます。
「自分の仮説は何であったが、できなかった。」ということを明確に伝えることは非常に大切と言えるでしょう。
自分がなぜこう考えたのか「仮説」ありきで考える
「このようなアプローチをとれば解決できるのではないか」
まずは仮説を立てることから始めましょう。
- 自分自身の経験則
- 持っている知識
- 調査結果
間違っていたとしても「仮説」をもって検証することで、自分の予想と結果のギャップが鮮明になります。
そしてそれを他者と共有することができます。
経験から仮説を立てる
私はPower AppsやPower AutomateそのほかPythonやGoogle Apps Scriptsの学びました。
学び方の基本は、過去に触れたことがある技術から推論してトライアンドエラーを繰り返すことです。
学んだ順序は
- Excel VBA
- Google Apps Script
- RPA(Power Automate for desktop)
- Python
- Power BI
- Power Apps / Power Automate
私が最初に真剣に学んだのはExcel VBAです。もっと言うとExcel関数だったと思います。
経験の中で「今まで自分が学んできた技術の中で、つまり何か」という仮説をたて、トライしてきたと思います。仮説の精度は最初低くても、徐々に精度は高められます。自分の中で、理解の筋道が描けるようになります。
私の場合は、式の参照がExcel VBAのCellsに置き換わり、つまづきからWorksheetを抽象化して捉える二次元配列の理解、そこからJSONと全て繋がってきています。
ここで私の意見になりますが、ここで言う抽象化は、自分のなかで「つまり何か」を捉えることを示しています。この抽象化した自分の中での理解は他者に壁打ちをしないほうが良いと思っています。
何故他者に確認しないのか それは自分の中で捉えている「成長途中の理解」を他者が確定的に持っている理解ではズレる可能性があるからです。
「成長途中の理解」は最終的に辞書的な言葉に置き換わります。
「自分の中で咀嚼していく」という**理解の工程は千差万別です。壁打ちには適していません。
間違ってもいいから言語化した仮説で試す
「仮説をもって質問してみる」といえども、自分の考え方が間違ってるのではないかと不安になる気持ちはよくあります。
特に専門性の高い人から「それ全然違うよ」といった反応があると、非常に不快な気持ちになるでしょう。
個人の感想です
しかし理解するための工程と言うものは本当に千差万別だと思っています。
「自分はAだと思う、あの人はBだと思っている」そんな解釈の不一致なんてありふれたものです。
いろいろな視点から物事の見え方が異なります。
鳥の目、虫の目、魚の目と言う視点の違いの格言もあるよう、視点というものは
- 立場
- 属性
- 培った経験
- 育ってきた文化
複数の事象の組み合わせで形成されます。自分の「物の捉え方」は自分専用のものです。
最終的な理解は教科書的な解釈になるかもしれません。
しかしながら、その理解までの工程は、自分の中で「こうではないか、いや違った」と言う仮説検証の繰り返しによります。
「質問すること」これは一種のテストのようなものです。出し手と受け手が、理解のステップ、考え方を共有しないと、解決まで上手く進みません。
そのためにまずは
- 自分の中で言語化して
- 自分による構造化を実施して
その「仮説」で質問を出してみましょう。
そうすることで、ギャップがわかり、そのギャップから解決までの道のりは見えていきます。
そして、この仮説の組み立てで得た経験や、自分の観察力の向上にもつながります。
技術だけの話ではなく、ビジネスの中でも、または日々の生活のTipsとしても活かせる考え方です。
自分が普段見て普段考えた結果を持って仮説を検証することによってその精度は高まってきます。
おわりに
今回はQiitaを通じて技術の学び方と言うことをテーマに「仮説を持つことの大切さ」を書いてきました。
数年前は、配列やオブジェクトっていうものがさっぱりわかりませんでした。
そんな私でも、仮説検証で理解力は高められたと思います。
「今回配列の書き方を、このように参照してみたけれども、全然答え違った。この数字を入れ替えれば変わるのではないか」
「添え字を書き換えてみれば答えに近づくのではないか」
「添え字を変えることで正しい答えが出るということは、自分の理解の根本が異なるのではないか」
こういったVBAのときにぶち当たった悩みが懐かしいです。今では当たり前のように配列を使っていますが、それまでの自分の見てきたもの、学んできたもので生み出した仮説は、かつてそういった精度のものでした。
しかしそれは自分の学びにつながっています。大切な事は試すことです。
技術領域では何回でもテストすることができます。間違いを恐れずどんどん数を検証してみましょう。
今回はポエムな内容になってしまいましたが、仮説思考と言うことをテーマにログを書いてみました。お読みいただきましてありがとうございました。
セール中