思考法 2026年6月13日

「考え方、知ってますか?」と詰められた日:思考にも手順がある話

XECIN 問題解決抽象化具体化メタスキル若手エンジニア

入社2年目の頃、先輩にこう言われた日のことをよく覚えている。

「考えるって、手順があるんですよ。知ってますか?」

プロジェクトで原因不明のバグに引っかかって、コードを眺めながら「うーん」とうなっていたときだった。恥ずかしながら当時の僕は、「なんとなく頭に浮かんでくるまで待つ」というのが「考える」だと思っていた。その後に続いた言葉がまた刺さった。

「あなたの考えるは、ひらめき待ちなので無意味です」

当時は正直かなりきつかった。詰められた気がした。でも今振り返ると、あの言葉は的を射ていた。

ひらめきを待っていた自分

バグを再現させながら「なんかここが怪しい気がする」「いや違うかも」を繰り返していた。仮説を立てているようで、実際は直感で次の調査先をランダムに選んでいた。

先輩が見ていたのはそこだったらしい。「手を動かす前に、何を確かめようとしているか言えますか?」と聞かれて、答えられなかった。なんとなく怪しそうな箇所に当たりをつけていただけで、なぜそこを確かめるのか言語化できていなかった。

結果として、同じ箇所を2回調べていたり、関係ない場所でデバッグログを足したりしていた。時間をかけて動き回っているのに、効率が悪い——そのループから抜け出せなかった。

「思考」の4要素を教えてもらって変わったこと

先輩が整理してくれた内容は、シンプルだった。

「考える」ときに使う道具は4つしかない、という話だった。

【思考の4要素チェックリスト】

1. 深さ(縦)  ── なぜ?を繰り返して根本を掘り下げる
2. 広さ(横)  ── どんな可能性があるか、視野を横に広げる
3. 構造化      ── 情報をグルーピングして関係性を整理する
4. 時間軸      ── いつ発生したか、順序と因果を追う

打つ手が浮かばないとき → どの要素が不足しているかを点検する

対策が思い浮かばないとき、「ひらめきを待つ」のではなく、この4軸のどれが足りていないかを確認する、という考え方だった。

恥ずかしながら、それまで「考える」を単一の行為として扱っていた。「考える」の中にこんなに種類があるとは思っていなかった。

抽象化(帰納法):バラバラな経験を「型」にまとめる

先輩の説明で特に響いたのが「帰納法で抽象化する」という話だった。

個別の経験(N件)から共通パターン(1つ)を取り出す作業のことで、「一を聞いて十を知る」が成立するのはここからだという。

たとえばバグ調査の話で言うと、こういうことだった。

【帰納法での抽象化(Before / After)】

Before(個別経験として記憶):
  - DBへの接続が突然切れたバグ → タイムアウト設定のミス
  - 本番だけでエラーが出るバグ → 環境変数が未設定
  - リリース後に再現するバグ  → キャッシュが古かった

After(抽象化した「型」として記憶):
  - 「設定系バグ」クラスタ
    └ 本番/ローカルの差異、環境変数、タイムアウト値、キャッシュ
  → 次に「本番だけで出る系」のバグに当たったとき、
    まずこのクラスタ全体を確認する

このとき使う道具は「ベン図」「フローチャート」「地図(マインドマップ)」などの図解の型で、抽出したい関係性によって使い分ける、とも教えてもらった。

正直なところ、この「図解の型の使い分け」まではまだできていなかったりします。当時教わってから今でも「とりあえずフローチャート」になってしまいがちで、ここは改善の余地がある部分だと思っている。

具体化(演繹法):縦と横の二方向

演繹法は「抽象 → 具体」の方向、つまり原則から個別の状況に落とし込む作業のことだった。

これには「縦方向」と「横方向」の2つがある。

【具体化の2方向(演繹法)】

縦方向(深掘り):
  「なぜ?」を繰り返して原因の原因まで掘り下げる
  例: エラーが出た → なぜ? → 接続が切れた → なぜ?
      → タイムアウトが短い → なぜ設定を変えた? → ...

横方向(視野拡張):
  「他には?」「別の視点からは?」で原因候補を横展開する
  例: エラーが出た → ネットワーク系かも / 設定系かも
                   / コード変更に起因かも / 外部API側かも
  → 複数の仮説を先に並べてから、確率の高い順に検証する

当時の自分に一番足りなかったのは「横方向」だったと思う。「怪しい場所1点に絞って深堀りする」を繰り返していたから、見当違いの場所に時間を使い続けていた。まず広げてから絞る、という順序が抜けていた。

型を増やすと、思考が「手順実行」になる

先輩が最後にこう言っていた。

「考える型を48個以上ストックしておくと、思考の解像度が変わります」

「48個」という具体的な数字が当時は不思議だったけど、フレームワーク・図解の型・分析手法などをまとめると確かにそのくらいになる、ということだったと思う。KJ法、MECE、Why-Why分析、フィッシュボーン、SWOT、フォースフィールド分析……数えてみると意外と多い。

引き出しが増えると、「何を使えばいいか分からない」という詰まり方が減る。「この問題は視野を広げる局面だから横展開のフレームを使う」「関係者の意見をまとめるならKJ法が向いてる」という判断が先にできるようになる。

「ひらめき待ち」から「手順実行」への切り替えは、要するに引き出しを増やすことでしか起きない——今ではそう思っている。

振り返って

あの日の「詰め」は、今では感謝している。

2年目の自分には「考える」という行為の中身が全然見えていなかった。「頑張って考えてるのに上手くいかない」という状態の正体が、「どの軸で考えるかを選べていない」だったと分かったのはその後だった。

正直、まだ全部うまく使えているわけではない。横方向に広げるのは頭の負荷が高くて、焦っているときほどすぐ縦掘りに走ってしまう。型の使い分けも、得意なやつしか出てこないことがよくある。

ただ、「考えること自体に手順がある」と知っているだけで、詰まり方が変わった気がする。前は「思い浮かばない……」で止まっていたところが、「今は何が足りていないのか?」という問いに変換できるようになった。これだけでも十分だったりします。

まだ引き出しを増やしている途中なので、今後は図解の型の使い分けをちゃんと習得したい。「フローチャートしか知らない」は、さすがにそろそろ卒業したいと思っている。