はじめに
システム開発第一事業部の奥田です。普段はフロント寄りのフルスタックエンジニアとして、Webアプリの開発を担当しています。
新人の頃って、エラーが出た瞬間に「とりあえずググる」、最近だと「とりあえずAIに聞く」になりがちじゃないですか?
私が初学者だった頃はまだAIがない時代でしたので(といっても5年前のことですが笑)、 わからないことやエラーが出たらとりあえず「ググる」という感じでした。
「ググれカス」という言葉もあるくらいでしたからね〜。
時代の流れで今は私もAIを多用していますが、本当に便利すぎて時折脳死状態でとりあえずAIに丸投げしてしまうことも多々あります...
日に日に性能が良くなっていくAI、毎日の日常に何の違和感もなく入り込んできたAIに恐怖感すら感じるほどです。
既にAIに依存しすぎて、AIがなくては仕事ができなくなってしまった人もいるのではないでしょうか?
「AIに頼ってばかりじゃダメなのはわかってはいるけれども...」
「AIを使いこなす側になって、うまく依存しないようにしたい」
そんな声が聞こえてきます。
というか、私自身もそう思っています!
実は私、元々はお菓子を売る会社で営業をしており、IT業界は完全に未経験で入ってきています。
その時にどうやって学んでいたかを思い返すと、そういえばとにかく言語化をしていたなと思い出したんです。
その言語化というプロセスのおかげでAIがない時代でもしっかりと学ぶことができ、業務をこなしていけたという経験があります。
そして気づいたのが、ググる前・AIに聞く前の思考が、その後の問題解決スピードを大きく変えてくれるということです。
「AIと何の関係があるの?」と感じるかもしれませんが、すごく深く関係しています。
この記事で紹介する仮説思考フレームワークは私が初学者の頃に実際に使っていたもので、 これのおかげでコードの動きや足りない視点を炙り出せるようになりました。
そして今後、AIが主流になっていく中で「ただ指示を出す人」ではなく「AIを使いこなす人」になるためにも、 仮説思考は必要不可欠だと感じています。
この記事では、仮説思考は才能ではなく型であるという前提で、新人エンジニア向けにやさしく解説していきます。
(もちろん新人じゃなくても「あ、自分のことかも」と感じた方は読んでくださいね!)
- はじめに
- 仮説思考とは何か
- 仮説思考の具体的なフロー
- 具体例:仮説メモの書き方
- 「ググれ」「AIに聞け」の本当の意味
- 仮説思考 × AI の実践的な使い方
- まとめ:新人のうちに身につけたい「考える型」
- テコテックの採用活動について
仮説思考とは何か
仮説思考とは「こうすれば解決するかもしれない」という当たりを立てて、検証していく考え方です。
「仮説」という言葉は少し難しそうに聞こえますが、実際にやっていることはとてもシンプルです。
たとえば、病院での問診をイメージしてみてください。
- 「どこが痛いのか?」
- 「いつから痛いのか?」
- 「それを踏まえると、原因は何か?」
このように情報を整理しながら、
可能性を一つずつ絞っていきますよね。
エンジニアの問題解決も、実はこれとまったく同じです。
つまり仮説思考は、
特別な才能がなくても、誰でも使える「型」だということです。
大事なのは、当たりを外しても落ち込まないこと。
仮説が外れたら、それは「失敗」ではなく「情報」が増えただけです。
分からなかった原因が一つ消えた、という前進でもあります。
次の章ではこの仮説思考を実際の開発でどう使うのか具体的なフローを紹介していきます。
仮説思考の具体的なフロー
ここでは、実務でそのまま使える「仮説思考の型」を5ステップで整理します。
1. 今どんな問題が起きているのか? (現状把握)
まずは「現状の事実」を集めます。
ここがあいまいだと仮説がぶれてしまいます。
ポイントは「起きている事実だけを見る」ということです。
- エラーメッセージは何か?
- コードはどこまで動いていて、どこから止まるのか
- いつから起きたのか(直前に変更したコードはあるか)
- いつでも再現するのか?特定条件だけか?(ユーザー・環境・データなど)
「現象を言語化する」こと自体がトレーニングにもなります。
推測は入れずに事実とひたすらに向き合いましょう!
2. 何が解決したらいいのか? (ゴール設定)
何が解決したらOKなのか、ゴールをはっきりさせます。
たとえば、
- 「画面に一覧が表示される」
- 「
POST /loginが200で返る」
のように、成功条件を一文で言えるようにすると迷子になりにくいです。
一歩踏み込めそうでしたら
- どこどこの処理で〜〜が〜〜になっているので、これを〜〜にする
くらい具体的な方が目指すべきものがより具体的になりますので、個人的にはオススメです。
ゴールがない調査はただの迷子です。 しっかりと仮説を立てる意味を明確化しておきましょう!
3. 問題解決するための仮説をいくつか立てる
次に「原因の候補」を複数出します。
ここは数より幅が大切です。
また、めちゃくちゃ具体的であればあるほど良い仮説とも言えます。
なお、このステージで「仮説を作るために調べる」ことはまったく問題ありません!
例:Reactで一覧が表示されないときの仮説
データ取得まわり
- APIリクエスト自体が失敗している(
fetch/axiosがエラー) - ステータスが
4xx / 5xxで正常なレスポンスが返っていない - APIは成功しているが、レスポンスの形が想定と違う
state / hooks まわり
useEffectが実行されていない(依存配列の指定ミスなど)setStateは呼ばれているが、値が空のまま- state更新後に再レンダリングされていないと思い込んでいる
JSX / 描画条件まわり
items.length > 0 && ...の条件で弾かれているmapしている配列がundefined/ 空配列keyの指定ミスで想定外の挙動になっている
イベントまわり
- ボタンの
onClickが発火していない - 親コンポーネントから渡した props が違っている
環境・設定まわり
- 環境変数(
API_URLなど)が想定と違う - 開発環境と本番環境で向き先が異なっている
- 認証トークンが付与されていない
仮説がないと、検索ワードも質問文も作れません。
逆に、仮説があると検索や質問の精度が一気に上がります。
仮説を立てるときは、次のポイントを意識すると考えやすくなります。
- 調べてわかったこと(仕様・公式ドキュメント)
- 似たような事例(過去にハマったエラー、Qiita / Stack Overflow など)
- 「ここ、怪しくない?」と直感的に感じた箇所
「え、そんなに具体的な仮説をいきなり作るのは難しい…」
という声が聞こえてきそうなのでここで一つコツを紹介します。
それは、
「最初はざっくり仮説を立てて、そこから深掘りしていく」
というやり方です。
いきなり完璧な仮説を作る必要はありません。
まずは、
- 「どこかでAPIが怪しそう」
- 「このあたりの条件分岐が怪しいかも」
といった粗い仮説でOKです。
そこから、
- なぜそう思ったのか?
- 具体的に「何」が怪しいのか?
- それは「どうやって」確かめられるのか?
というように「なぜ・何・どうして」を自分に問いかけながら分解していきます。
また、「この仮説を検証するための仮説」を立てるのも、まったく問題ありません。
たとえば、
- 「APIが怪しい」
→「本当にリクエストは飛んでいるのか?」
→「ステータスコードはどうなっているか?」
という感じです。
仮説思考は回数を重ねるほどコツが掴めてきます。
最初から上手くやろうとせず、 知らないことを前提に、 まずは簡単な仮説を立てるところから始めてみてください!
4. 仮説を一つずつ検証していく(検証)
仮説を立てたら「どうやって確かめるか」を決めて、1つずつ試します。
- ネットワークタブでAPIのステータスを見る(そもそも飛んでいる?200?4xx?5xx?)
console.logで条件分岐の通り道を確認する- 関連するファイルだけを一時的にコメントアウトして切り分ける
このとき、一度に複数の仮説を混ぜないのがポイントです。
「ここが動けば、次はこうなるはず」という仮説をもとに、処理のフローを丁寧に追っていく作業になります。
ここで、とても大事なポイントがあります。
それは「結果だけを見るのではなく、そこまでのフローが仮説と一致しているかを見ること」です。
結果だけを見ていると、そこまでのフローの中で起きている仮説とのズレに気づけません。
たとえば、
- 仮説では「A → B → C → D」と処理が進むはずだった
- 実際は「A → C → B → D」だった
ということは、実務ではよくあります。
結果だけを見ると「一応動いている」で終わってしまいますが、フローを追うことで、
- 実は別の条件分岐が先に評価されていた
- 想定していない処理が途中で挟まっていた
といった重要な気づきが見えてきます。
そして、そういった場所にこそ「難しい仕様」や「ハマりポイント」が隠れていることが多いです。
5. 検証結果を確認し、解決しなければ再度仮説を立てる (修正)
結果が当たりなら解決、外れなら次の仮説へ。
この繰り返しで、原因はだんだん狭まっていきます。
仮説が外れても『次のヒント』になるので決して無駄ではありません。
ただし、やりすぎると無限ループに陥りがちです。
そのため、15分など時間で区切ることをおすすめします。
もし区切った時間内で解決しなかった場合でも、
これまでに立てた仮説や行った実行内容は、すでにテキストとして整理されているはずです。
そのテキストを持ってプロジェクトメンバーや先輩に質問しにいきましょう。
周りに助けを求めることも、とても大切なスキルです!
また、ここまでの内容が整理されたテキストとして残っていれば、
- 「何を考えて、何を試したのか」が伝わる
- 「ここまでは理解できていて、ここで詰まっている」が分かる
状態になります。
結果として質問された側も状況を把握しやすくなり、より的確なアドバイスをもらいやすくなります。
こうした質問ができる人は、自然と「ちゃんと考えている人」という印象を持ってもらえます。
具体例:仮説メモの書き方
仮説を言語化すること自体が、思考の整理になります。
実務では、次のような「短い仮説メモ」を書くだけでも頭がかなりスッキリします。
――― 仮説メモ例 ―――
現象:送信ボタンを押すとスピナーが回ったまま止まる
ゴール:成功時に「保存しました」が表示される
仮説1:APIが500を返している
検証:ネットワークタブでレスポンスを確認する
仮説2:成功メッセージの表示条件が逆になっている
検証:if (isSuccess) の分岐を console.log で確認する
――――――――――
このメモは最初から完璧に書く必要はありません。
- 書き途中でOK
- 仮説が増えてもOK
- 外れた仮説が残っていてもOK
仮説を立てたり、検証したりするたびに、少しずつ追記・修正していけば十分です。
この「短い仮説メモ」を日常的に書けるようになると、
- 何が分かっていて
- 何が分かっていなくて
- 次に何を試すべきか
が自然と整理されるようになります。
その結果、言語化力と体系的思考力が鍛えられ、問題解決のスピードがぐっと上がっていきます。
また、このメモはAIに相談するときや、質問するときにもそのまま見せられる「思考のログ」になります。
「ググれ」「AIに聞け」の本当の意味
「とりあえずググれ」「AIに聞け」と言われることもありますが、 本当の意味は「自分で考えた上で、必要な情報を取りにいけ」ということです。
仮説がない状態だと、
- 検索ワードがざっくりしすぎて、欲しい答えにたどり着けない
- 前提が共有されておらず、AIへの質問が的外れになりやすい
ということが起きがちです。
たとえば、
- 悪い例:「React 画面が出ない」
- 良い例:「
useEffectでAPIを呼ぶと、初回だけ一覧が出ない」
このように仮説があると検索や質問が一気に具体的になります。
そして、これは 「ググる力」や「AIを使う力」そのものでもあります。
次の章では、この仮説思考を使ってAIとどう付き合っていくかについて、
もう一段踏み込んで説明していきます。
仮説思考 × AI の実践的な使い方
AIは「答えを出す道具」ではなく、思考を広げるための相棒です。
仮説を添えて相談することで、自分では気づけなかった視点を補完してくれます。
この使い方、実はシニアエンジニアに相談するときのコツとほぼ同じです。
- 状況を整理して伝える
- 自分なりの仮説を出す
- 「何が分からないか」を明確にする
こうした情報があるからこそ的確なアドバイスがもらえます。
AIに聞くときも、考え方はまったく同じです。
たとえば ChatGPT に相談するときは、次のように「仮説込み」で投げると精度が上がります。
――― 例 ―――
現象:ログイン後にトップ画面が真っ白になる
ゴール:一覧が正常に表示される
仮説:APIのレスポンスが空配列で、描画条件に弾かれている可能性がある
質問:この前提で、ほかに考えられる原因や確認すべきポイントはありますか?
――――――――
この聞き方だと、
- 自分の仮説の抜けや偏りを指摘してもらえる
- 思い込みを外すヒントがもらえる
- 次に試すべき選択肢が増える
といったメリットがあります。
AIは「考えなくていい存在」ではありません。
むしろ、考えたことを投げるほど価値が上がる存在です。
これは先輩やシニアエンジニアと一緒に仕事をするときも、
まったく同じだと思っています。
まとめ:新人のうちに身につけたい「考える型」
- 仮説思考は才能ではなくだれでも使える型
- ググる前・AIに聞く前に、まず15分だけ考えてみる
- 仮説を言語化することで、思考力と問題解決力が伸びる
- AIは答えではなく、視点を増やす相棒として使う
焦らずに「型」を回せるようになると、成長スピードが変わります。
小さな仮説を1つ立てるところからぜひ始めてみてください!
テコテックの採用活動について
テコテックでは新卒・中途採用を積極的に行っています。 採用サイトでは会社の雰囲気や福利厚生、募集ポジションをご確認いただけます。 ご興味をお持ちいただけましたら、ぜひチェックしてみてください。 tecotec.co.jp