入社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年目の自分には「考える」という行為の中身が全然見えていなかった。「頑張って考えてるのに上手くいかない」という状態の正体が、「どの軸で考えるかを選べていない」だったと分かったのはその後だった。
正直、まだ全部うまく使えているわけではない。横方向に広げるのは頭の負荷が高くて、焦っているときほどすぐ縦掘りに走ってしまう。型の使い分けも、得意なやつしか出てこないことがよくある。
ただ、「考えること自体に手順がある」と知っているだけで、詰まり方が変わった気がする。前は「思い浮かばない……」で止まっていたところが、「今は何が足りていないのか?」という問いに変換できるようになった。これだけでも十分だったりします。
まだ引き出しを増やしている途中なので、今後は図解の型の使い分けをちゃんと習得したい。「フローチャートしか知らない」は、さすがにそろそろ卒業したいと思っている。