---
title: 【公開】質問力研修_新入社員未経験向け
tags:  #エンジニアコミュニケーション  
author: [smile_yukiko_it](https://docswell.com/user/smile_yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/V7NYY156E8.jpg?width=480
description: 【公開】質問力研修_新入社員未経験向け by smile_yukiko_it
published: April 25, 26
canonical: https://docswell.com/s/smile_yukiko_it/ZMQ78W-2026-04-25-222506
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/V7NYY156E8.jpg)

新入社員・未経験者向け
うさうさ
エンジニア研究室
質問力研修
〜 現場で困らないエンジニアの聞き方 〜
✓ 質問の 4 ステップ
✓ 15 分ルール
✓ 演習で体得
講師: Yukiko Ishiguro ｜ ALJ Education Plus


# Page. 2

![Page Image](https://bcdn.docswell.com/page/YJ9PP5YR73.jpg)

ゴー ル
2 / 18
本研修のゴール
研修後すぐに現場で使える『型』を身につける
①
質問の重要性を理解する
②
質問の 4 ステップを使える
③
15 分ルールを実践できる
なぜ質問が下手だと損するのかを知る
型に当てはめれば誰でも上手に聞ける
詰まる時間と質問するタイミングの目安
出典: Hashimoto-Noriaki『開発エンジニアの質問の正しいやり方』(Zenn, 2023)


# Page. 3

![Page Image](https://bcdn.docswell.com/page/GJ8DDY6GJD.jpg)

目 次
3 / 18
本日の流れ
全 6 章 + 演習 + まとめ
1
なぜ質問力が必要なのか
2
上手い質問のメリット・下手な質問の損
違いを数字で実感
失
3
ダメな質問の例(Before)
現場で よく見るパターン
4
質問の 4 ステップ(本日の核)
型に従えば誰でも上手
5
15 分ルール
聞くタイミングの目安
6
上達のコツ ・ 練習方法
現場で続けるために
現場でのコスト感を共有する
所要時間: 60 分(講義 40 分 + 演習 15 分 + Q&A 5 分)


# Page. 4

![Page Image](https://bcdn.docswell.com/page/LJLMM49XER.jpg)

1 . 必要 性
4 / 18
なぜ質問力が必要なのか
技術力の前に立ちはだかる『コミュニケーションの壁』
「エンジニアの時間は会社のお金」
質問力が左右するもの
今後のキャリア
ある PM の言葉:
現場での評価・昇進・案件アサイン
会社の利益
1 人優秀なエンジニアが手を止めるだけで会社が
損失する。それを頭に入れた上で質問しなよ。
工数削減 → 利益貢献 → 自分の収入 UP
人間関係
周囲のストレスを減らせれば信頼が育つ
技術力の伸び
→ 質問は『してもいい』けど『仕方』が大事
コミュニケーションが整って初めて技術に集中
出典: Hashimoto-Noriaki『開発エンジニアの質問の正しいやり方』(Zenn, 2023)


# Page. 5

![Page Image](https://bcdn.docswell.com/page/47MYYKZ37W.jpg)

2. メリ ット
5 / 18
上手い質問の 3 つのメリット
技術以外でも使える一生モノのスキル
01
仕事ができる人と思われる
質問の組立てを見れば思考の整理具合が分かる。上手な人は『この人に任せたい』と評価される。
02
他のエンジニアの時間を奪わない
工数削減 = 利益貢献。一発で要点が伝わる質問は周囲の生産性も底上げする。
03
困った時に欲しい回答が返ってくる
ぼんやりした質問にはぼんやりした答えが返る。具体的に聞けば的確な答えが返る。
「質問が上手いと褒められる」場面は、現場で必ずやってくる


# Page. 6

![Page Image](https://bcdn.docswell.com/page/P7R99X6RE9.jpg)

2. メリ ット
6 / 18
下手な質問が招く損失
やり取りが 4 倍に膨らむ + 双方が疲弊する
✗ 下手な質問
✓ 上手な質問
20 回
5回
やり取りが必要
で同じ問題を解決
●
質問者・回答者ともに疲弊
●
要点が一発で伝わる
●
本題の解決が後回しに
●
本題の議論にすぐ入れる
●
実務だと会社に損失
●
技術の話に集中できる
4 倍の差
同じ 1 問の解決でも、聞き方ひとつでこれだけ差が出る


# Page. 7

![Page Image](https://bcdn.docswell.com/page/PJXQQ6MY7X.jpg)

3. Be fore
7 / 18
ダメな質問の例
現場で本当によく見るパターンを見てみよう
新入社員さん
「rails で migration を実行したらエラーが出ました。どうすればいいですか
。」
受け手の心の声
●
何が分からないのか? どういうエラーが出たのか?
●
そもそも自分でエラー解決する気あるのか?
●
「どんなエラー? 何して欲しいの?」と返さないと進まない → 余計なやり取りが発生
→ 結果: エンジニアの時間を無駄に奪う = お金の損失


# Page. 8

![Page Image](https://bcdn.docswell.com/page/3JK991G4JD.jpg)

4. 4 ステ ップ
8 / 18
質問の 4 ステップ(本日の核)
型に従えば、誰でも上手な質問ができる
①
②
③
④
要件を伝える
今の状況
試したこと
最後にお願い
結論ファースト
事実+エラー
仮説+調査
教えを請う
この順番を崩さないことが一番大事
順番を意識するだけで、質問の質は劇的に変わる


# Page. 9

![Page Image](https://bcdn.docswell.com/page/LE3WWQNDE5.jpg)

4. Ste p ①
9 / 18
Step ① 要件を伝える(結論ファースト)
最初の 1 行で『何のメッセージか』を宣言する
4 つの要件タイプ
例文
● 【質問】わからないことを聞く
● 【相談】判断を仰ぎたい
● 【報告】結果を伝える
● 【共有】みんなに知らせる
「質問です。
rails で migration を実行できず
困っています。」
→ 受け手は『質問モード』で読める
→ 困りごとも一緒に伝わる
Step ① で間違えると、その後 何を書いても伝わりにくくなる


# Page. 10

![Page Image](https://bcdn.docswell.com/page/8EDKK9W27G.jpg)

4. Ste p ②
10 / 18
Step ② 今の状況を伝える
事実とエラーをそのまま渡す。受け手が想像できる材料を出す
状況に含めるもの
例文
● どのファイルで作業中?
● 何をしようとしていた?
● 何が起きた?(エラー文をそのまま)
● 事実と推測を混ぜない
「○○ファイルで △△ を実装し migration を実行
したら、以下のエラーで落ちました:
ActiveRecord::PendingMigration...」
→ 状況がわからないと適切な助言は出せない
現場あるある: エラー文を要約してしまう → 原因情報を捨てている


# Page. 11

![Page Image](https://bcdn.docswell.com/page/V7PKKZ9LJ8.jpg)

4. Ste p ③
11 / 18
Step ③ 試したこと・調べたこと(+仮説)
『考えました感』を見せると相手も丁寧に答えてくれる
含めるもの
例文
● 実際に試したこと(コマンド・修正内容)
● 調べたサイト・キーワード
● 自分の仮説(なぜそう思った?)
● 数字・固有名詞を入れる
仮説には 必ず根拠 を添えること
「カラム名の typo かと思い 3 箇所修正しましたが解消
せず。
Stack Overflow の類似質問を 5 件読みましたが当ては
まりませんでした。」
→ 数字+固有名詞 で『調べた量』が見える
根拠なき仮説は『考えていない』と同じ
「修正した」より「✕✕を 3 箇所修正した」のほうが 100 倍伝わる


# Page. 12

![Page Image](https://bcdn.docswell.com/page/2JVVVWM6JQ.jpg)

4. Ste p ④
12 / 18
Step ④ 最後にお願い・方向性を添える
受け手が答えやすいように『何を聞きたいか』を最後に明示
締めの定型文
「〜の方向性で調べているのですが、解決できず困っています。
ご教授いただけると幸いです。」
これで何が起きるか
●
受け手は『いま何を提供すればいいか』が即わかる → 返信が早くなる + ピンポイントになる
Step ① の宣言 と Step ④ のお願い、両方あると質問が完結する


# Page. 13

![Page Image](https://bcdn.docswell.com/page/5EGLLDG2JL.jpg)

4. 比 較
13 / 18
4 ステップを通すとどう変わる?
同じ困りごとでも、伝わり方がここまで違う
✗ Before
✓ After
【質問】migration が通らず困っています。
rails で migration を実行したらエラーが出ました
。どうすればいいですか。
user.rb で belongs_to を実装して migration したら
ActiveRecord::Pending... で落ちました。
カラム名を 3 箇所修正、SO の類似 5 件確認しましたが解消
せず。
外部キー設定が原因かと考えています。ご教授いただけると幸
いです。
After は ① 質問宣言 → ② 状況 → ③ 試したこと → ④ お願い の順序


# Page. 14

![Page Image](https://bcdn.docswell.com/page/4JQYY1X97P.jpg)

5. タイ ミン グ
14 / 18
Google の 15 分ルール
聞くべきタイミングを明確にする
15
ルールの内容
●
詰まったら、まず 15 分は自分で考える
●
15 分経っても解決しなかったら必ず聞く
やってはいけない
MIN
●
考えずにすぐ聞く(NG)
●
1 人で 1 時間 抱え込む(NG)
チームのために『15 分超えたら聞く』が最善 ─ 抱え込みは害


# Page. 15

![Page Image](https://bcdn.docswell.com/page/K74WWR2RE1.jpg)

5. チェ ック
15 / 18
送信前 30 秒 チェックリスト
Slack で送る前に、この 5 項目を見返す
✓
① 要件タイプ(質問/相談/報告/共有)を最初に書いた?
✓
② 状況を 事実+エラー文 で書いた?
✓
③ 自分が 試したこと・調べたこと を書いた?(数字+固有名詞)
✓
④ 仮説に 根拠 を添えた?
✓
⑤ 最後に お願い・方向性 を書いた?
これを満たさない質問は、現場ルールで投稿不可にするのも有効
送信前 30 秒の確認で、後の 1 時間が変わる


# Page. 16

![Page Image](https://bcdn.docswell.com/page/LJ1YYQMVEG.jpg)

6. 演 習
16 / 18
ペアワーク: 質問の書き換え
Before の質問を、4 ステップで書き換えてみよう
お題
「Python が動きません。助けてください。」 ─ この質問を 4 ステップに整えて書き換える
進め方(15 分)
3分
個人で書いてみる(4 ステップに沿って)
5分
ペアで読み合い、改善点を 1 つずつ指摘
5分
改善版を書き直す
2分
数組ピックアップして共有
ペアワークの目的: 自分の盲点を相手の目で気づく


# Page. 17

![Page Image](https://bcdn.docswell.com/page/GJWGGM3372.jpg)

6 . 上達 法
17 / 18
質問力を上達させる 3 つの習慣
現場で続けるためのシンプルな型
型に当てはめて毎日使う
Slack/Teams での質問は必ず 4 ステップで書く。最初は遅くても、1 ヶ月で習慣化する。
業務日報で言語化を訓練する
1 日の終わりに 5 行だけ書く。事実 / やったこと / 詰まったこと / 試したこと / 明日やること。
Qiita / Zenn で発信する
先生になったつもりで自分の言葉でまとめる。書く力 = 質問する力。
とにかく練習・とにかく習慣化 ─ 上達した人は全員これをやっている


# Page. 18

![Page Image](https://bcdn.docswell.com/page/4EZLLQVG73.jpg)

まとめ
今日の持ち帰り
1
質問は順序が命: ①要件 ②状況 ③試したこと ④お願い
2
数字 + 固有名詞 で『考えた量』を可視化する
3
15 分詰まったら必ず聞く(抱え込みは害)
4
送信前 30 秒のチェックリストを毎回通す
面白きこともなき世を面白く — Yukiko Ishiguro