現場に入って最初の半年くらい、
「これって自分で調べるべき？先輩に聞くべき？」
と悩むことがめっちゃ多かったです。
- ググれば出そう
- でも調べても分からない
- 聞いたら「調べた？」と言われそう
- 聞かないと作業が進まない
- どこまで自力でやればいいの？
このモヤモヤ、若手エンジニアあるあるだと思います。
そこで今回は、僕なりに整理した
“ググる vs 聞く” の境界線 をまとめます。
✔ 結論：
「一般論・技術知識」はググる
「現場固有・仕様」は聞く
この2軸で判断するとかなりスッキリします。
たとえば：
- Javaの例外 → ググる
- プロジェクトのログの場所 → 聞く
- Gitの使い方 → ググる
- このAPIの戻り値の仕様 → 聞く
- SQL文の基礎 → ググる
- このテーブルの設計意図 → 聞く
これだけで判断に迷う時間が減ります。
🔍 1. “ググるべき質問” 5パターン
① 一般的な技術知識
例：
- SpringのDIって何？
- NullPointerException とは？
- Gitのrebaseとmergeの違い
- SQLのJOINの種類
→ これは世の中に無限に情報があるので、聞く必要ないです。
② 言語・フレームワークの使い方
例：
- Javaのラムダ式の書き方
- Spring Boot の設定ファイルの書き方
- Linux の chmod の意味
→ これらはググったほうが早い。
③ ツールの基本操作
例：
- VSCode のショートカット
- Postman の使い方
- curl コマンドの書き方
→ 公式・Qiita・ブログが大量にあります。
④ 検索すれば1〜3分で分かるもの
- エラー文言
- 設定ファイルの書き方
- よくあるコマンド
- 標準的なログの読み方
→まずは検索。そのあと聞くのはOK。
⑤ 先輩の作業時間を奪う必要がないもの
つまり「自分で調べて済むもの」は全部ググる項目です。
🗣 2. “聞くべき質問” 5パターン
① プロジェクト固有の仕様・ルール
例：
- このAPIの設計意図は？
- このカラムは何に使う？
- このログはどこに出ている？
- この機能はどの範囲まで対応する？
→ ググっても出ません。聞くしかない。
② 設計書・要件の背景
例：
- なんでこの仕様になったのか？
- どういう理由でこの制約があるのか？
→ 現場の人にしか分からない領域。
③ 迷って作業が止まる時
例：
- この修正の影響範囲が読めない
- DBをどこまで触っていいか判断できない
→ 早く聞かないと、ただの作業遅延になる。
④ 調べても分からず“時間が溶けている”状態
僕もやったんですが、
30分以上詰まって何も進まないのって普通にコスパ悪いです。
→ 15〜30分でリミットを決めて聞く のが最適。
⑤ 安全性・品質に影響する判断
例：
- ここで削除して大丈夫？
- 仕様を変えて良い？
- このテーブルをいじる必要ある？
→ これは聞けば聞くほど喜ばれます。
逆に勝手に判断すると危険。
🧭 3. **判断に迷った時の黄金ルール：
「検索 → 15分考える → 記録して聞く」**
僕がやっているのはこれ。
① 検索してみる（5〜10分）
→ 出ないものは割り切る。
② どう分からないのか言語化（5分）
例：
- 「Aのエラーは調べたけど、Bの原因が分からない」
- 「Cのパスがどこにあるか見つからない」
③ 聞く時は“ここまでやった”を添える
例：
「◯◯の件、検索しても分からず、
ログとコードを確認しましたが、
AとBの関係が掴めません。
どこを見れば良いかヒントいただけますか？」
→ これを言えると“自走してる人”としてめちゃくちゃ好印象です。
🧩 4. “聞いてもいい雰囲気” の職場かどうかも重要
実は、若手が一番苦労するのは 質問のしづらさ です。
- 「調べて」と突き放される
- 聞いたら嫌な顔される
- チームが忙しすぎて聞きにくい
こうなると成長スピードがガタ落ちします。
質問しやすい文化のある現場は
若手の成長速度がえげつなく速いです。
🔚 まとめ
“ググる vs 聞く” の境界線はこれ。
- 一般論 → ググる
- 現場固有 → 聞く
そのうえで、
- 15〜30分で区切る
- 調べた履歴を見せる
- 手が止まる前に相談する
これができると、若手エンジニアとして
めちゃくちゃ信頼されるようになります。
僕自身、これを意識するようになって
作業スピードも品質も上がりました。