質問しやすさを仕組みで作る | 新人を受け入れる技術

新人が3日詰まっていた、という話はどの現場にもあります。そのたびに「なぜもっと早く聞かなかったのか」と言われますが、答えははっきりしています。 聞くことにコストがあると本人が判断したからです。

この章では、質問しやすさを本人の性格ではなく、受け入れ側が設計できる仕組みとして扱います。

「いつでも聞いて」が機能しない理由

初日に、ほぼすべてのメンターがこう言います。

分からないことがあったら、いつでも聞いてね。

そして、ほぼすべての新人が聞きに来ません。言葉を疑っているわけではなく、新人の側では毎回こういう計算が走っているからです。

新人が見ているもの	頭の中の判断
相手が集中していそう	「今は話しかけない方がいい」
質問の内容が初歩的	「これを聞くと無能だと思われる」
前にも似たことを聞いた	「2回目は聞きづらい」
自分で調べれば分かるかもしれない	「あと30分だけ粘ってみよう」

問題は、この計算が毎回発生することです。「いつでも聞いて」は、この計算の結果を変えません。コストの存在そのものを消していないからです。

そして粘った30分は、たいてい60分になり、半日になります。本人にとっては「もう少しで分かりそう」の連続で、気づいた時には聞くこと自体が事故報告になってしまっているという状態です。

「聞きに来ない」は良い兆候ではない

質問が来ない期間を「順調」と読むのは危険です。順調で質問が来ないのか、詰まっているのに言えなくて来ないのかは、 外からは区別がつきません。

区別できないものを放置すると、判明するのは常に手遅れになってからです。

「聞いてよい」を「聞くのが仕事」に書き換える

やるべきことは、許可を出すことではなく、基準を決めることです。広く使われている形が「30分ルール」です。

初日にこう合意します。

30分進まなかったら、その時点で聞いてください。これはお願いではなくルールです。30分以上一人で粘るのは、こちらとしては困ります。

ここで効いているのは時間の長さではありません。判断を本人から取り上げたことです。「聞いていいかどうか」を毎回考えなくてよくなり、時計を見るだけで済みます。

さらに一歩進めて、意味づけをこう変えます。

弱い言い方	強い言い方
分からなかったら聞いていいよ	30分詰まったら聞くのがあなたの仕事です
迷惑じゃないから大丈夫	黙って詰まっている方がチームのコストが高いです
なんでも聞いてね	今週は「質問した回数」を成果として見ます

3つ目は極端に見えますが、最初の2週間だけなら有効です。 質問を評価対象の逆側に置かないことを、行動で示す必要があります。

30分は絶対の数字ではない

30分でも45分でも構いません。チームで決めてください。調査系のタスクなら1時間、環境構築なら15分、のようにタスク種別で変えても機能します。

大事なのは長さではなく、数字が決まっていて双方が知っていることです。「詰まったら」だけでは、詰まりの定義が人によってずれます。

30分ルールの副作用に注意する

うまく運用されると、こういう質問が増えます。

30分経ったので聞きに来ました。まだ何も試していません。

これは新人が悪いのではなく、伝え方が足りていません。「30分で聞く」と「30分で分かったことを持って聞く」はセットで伝えてください。後半の形式は、後述するテンプレートで示せます。

詰まりの検知を本人の勇気に依存させない

ルールを決めても、言い出しにくい人はいます。そこで、受け入れ側から取りに行く手段を最低1つ用意します。

手段	拾えるもの	コスト
短いデイリー	今日の詰まり	1日10分
分報（times チャンネル）	作業中の独り言・つまずきの兆候	拾う側の巡回
定期ペアプロ・画面共有	言語化できていない詰まり	週1〜2時間

3つ全部やる必要はありません。1つも無い状態が問題です。

短いデイリー: 進捗ではなく詰まりを聞く

デイリーで「昨日やったこと・今日やること」を聞くと、新人は報告として成立する言い方を選びます。「環境構築を進めていました」で終わります。

聞くべきはここではありません。

悪い聞き方: 「進捗どうですか？」
良い聞き方: 「今、詰まっていることはありますか。無ければ無いで大丈夫です」

「無ければ無いでいい」を付けるのが重要です。これが無いと、何か言わなければいけない空気になり、当たり障りのない話が出てきます。

さらに具体的にするなら、こう聞きます。

昨日、一番時間を使ったのはどこですか。

「詰まった」と自己申告しにくい人でも、時間の話には答えられます。そして時間を食った箇所は、ほぼ詰まった箇所です。

分報: 独り言を垂れ流してもらう

分報は、本人専用のチャンネル（times-<名前> など）に作業中の考えを書き流してもらう運用です。

新人側に伝えることはこれだけです。

独り言でいいので、やっていることを書いてください。「〜しようとしている」「これでいいのか分からない」だけで十分です。誰も返信を強制しません。

受け入れ側の仕事は、書かせることではなく拾うことです。 1日2〜3回のぞいて、次のような書き込みがあったら声をかけます。

同じ話題が30分以上続いている
「よく分からない」「なぜか動かない」が出ている
書き込みがぱたりと止まっている（これが一番危ない）

分報を作っただけで満足しない

分報の失敗はほぼ1パターンです。チャンネルは作ったが誰も見ていない。

この状態は「言える場所を作った」というアリバイになるぶん、何も無いより悪くなることがあります。本人は「書いたのに反応が無い」と学習します。

見る人と時間帯を決めてください。「午前と夕方に見る」程度で構いません。

ペアプロ・画面共有を先にカレンダーへ入れる

「困ったら画面共有しよう」も、「いつでも聞いて」と同じ運命をたどります。呼び出す判断が本人に残っているからです。

そこで、最初から予定として入れておきます。

最初の2週間: 毎日30分（例: 16:30-17:00）
3週目以降: 週2回30分
1ヶ月以降: 週1回、または本人の希望で

予定として存在していれば、本人は呼び出さなくてよくなります。そして「特に困っていません」と言われた回でも、画面を見ると発見があります。

検索の仕方（エラーメッセージをそのまま貼れているか）
エディタやターミナルの操作で無駄に時間を使っていないか
ログをどこで見ているか
そもそも読むべきファイルにたどり着けているか

これらは質問としては出てきません。本人が非効率だと自覚していないからです。画面を見る時間は、詰まりの検知だけでなく、教える材料の発掘にもなります。

質問された時、最初の反応が全てを決める

ここが仕組みの最後の一手であり、一番壊れやすい場所です。どれだけルールを整えても、最初の1回の反応が悪ければ、次から質問は来ません。

新人は、質問した瞬間の表情・間・声のトーンを必ず見ています。

やってはいけない反応

反応	相手が受け取るもの
ため息、無言でモニタから目を離さない	「邪魔をした」
「それ、さっき言ったよね」	「聞き返すのは許されない」
「え、そこ？」	「このレベルは聞いてはいけない」
手を止めて全部の答えを即答する	楽だが、自分で調べる筋肉がつかない
「まず自分で調べてみて」だけで突き放す	30分ルールと矛盾し、ルール全体が信用を失う

最後の2つは対になっています。全部答えるのも、突き放すのも失敗です。 どこまで自力で来たかを聞いてから、次の一歩だけ渡すのが基本形になります。

なるほど。エラーは全文見た？　その中に出てくるファイル名、開いてみた？

手を止められない時の正しい返し方

集中している時に話しかけられることは実際にあります。その時に必要なのは、断ることではなく時刻を返すことです。

ごめん、いま手が離せない。15時から30分取るので、それまでに分かったことをまとめておいて。試したことと、エラーの全文だけあれば大丈夫。

この返し方には3つの効果があります。

拒絶ではないと伝わる。時刻が入っているので、放置ではないことが明確です
待ち時間が無駄にならない。まとめる作業自体が調査になります
15時に会う頃には、本人が自力で解決していることがある

3つ目は珍しくありません。人に説明するために状況を整理する過程で答えが見えるからです。これはラバーダック・デバッグと同じ効果で、意図して起こせます。

時刻を言わない「あとで」は禁句

「あとでね」「落ち着いたら」は、本人にとって期限のない待ちです。待っている間は他の作業に移りにくく、催促するかどうかで悩む時間が生まれます。

必ず時刻を言ってください。守れそうになければ、その時点で言い直せば済みます。

良い質問の形式は、受け入れ側が教える

「質問が下手だ」と感じたら、それは教えていないだけです。良い質問の形は、新人が自然に身につけるものではありません。初日にテンプレートを渡してください。

【やりたいこと】
ローカルで API サーバーを起動して、/health が 200 を返す状態にしたい
 
【現在の状況】
docker compose up は成功するが、curl すると connection refused
 
【試したこと】
- コンテナは起動している（docker ps で確認）
- ポート番号を README と見比べた（8080 で一致）
- コンテナの中から curl したら 200 が返る
 
【エラー全文】
curl: (7) Failed to connect to localhost port 8080 after 0 ms: Connection refused
 
【自分の仮説】
コンテナの中では動いているので、ポートの公開設定の問題だと思っている
 
【詰まっている時間】
40分

各項目には役割があります。

項目	何のためにあるか
やりたいこと	手段の質問に答えて的外れになるのを防ぐ
試したこと	同じ確認を回答者にさせない
エラー全文	要約されると原因が消えることが多い
自分の仮説	思考の癖が見え、次に何を教えるべきか分かる
詰まっている時間	緊急度が伝わり、こちらの優先順位を決められる

「自分の仮説」は、外れていても構わないと明言してください。 外れた仮説ほど、教える側にとって情報量が多いからです。

テンプレートは渡すだけでなく、一度一緒に書く

渡しただけでは使われません。最初の1回は、質問しに来た本人と一緒に埋めてください。 5分で終わりますし、その5分で「エラー全文を貼る」の意味が伝わります。

慣れてきたら形式は崩れて構いません。目的は書式の遵守ではなく、 質問の前に状況を整理する習慣です。

リモートだと何が余分に難しくなるか

出社していれば無料で手に入っていた情報が、リモートでは消えます。

出社時にあったもの	リモートで起きること	対策
隣の様子・表情	詰まっている顔が見えない	定期の画面共有を予定に入れる
雑談のついでの質問	質問がすべて「正式な用件」になる	分報や雑談チャンネルで敷居を下げる
画面を横から見る	操作の非効率に気づけない	ペアプロで実際に操作してもらう
反応の速さ	既読が分からず、待たされている感覚だけ残る	絵文字でもいいので即座に反応を返す

リモートで特に効くのは、最後の即レス（内容ではなく反応） です。

見ました。ちょっと調べるので15分待ってください。

これを返すだけで、相手の「無視されたかもしれない」という不安は消えます。チャットに絵文字リアクションを付けるだけでも構いません。 沈黙は、リモートでは拒絶と同じ意味を持ちます。

もう1つ、リモート特有の対策として有効なのが、 返事の期待値をあらかじめ宣言しておくことです。

私は午前中は会議が多いので、返信は昼以降になりがちです。急ぎの時はメンションを付けて「急ぎ」と書いてください。それは会議中でも見ます。

これがあるだけで、新人は「返ってこない＝嫌われた」という誤読をしなくなります。

リモートで働く新人が、環境構築で丸1日詰まっていたことが後から判明しました。30分ルールは初日に伝えてあります。次にまず手を付けるべきなのは？

運用チェックリスト

自分のチームで、次の質問に即答できるか確かめてください。

新人が「何分詰まったら聞く」か、双方が同じ数字を言えますか
本人が黙っていた場合、詰まりに気づける手段が1つ以上ありますか
分報を作ったなら、誰がいつ見ますか
直近1週間で、新人の画面を見た時間は何分ありますか
手が離せない時、あなたは時刻を添えて返していますか
新人からの最初の質問に、あなたはどんな表情で応じましたか

4 が 0 分のまま2週間が過ぎているなら、それは順調なのではなく、見えていないだけの可能性があります。

この章のまとめ

「いつでも聞いて」が機能しないのは、質問のコスト（時間を奪う・低く見られる）が消えないから
30分ルールの本質は時間の長さではなく、聞くかどうかの判断を本人から取り上げること
「聞いてよい」ではなく「聞くのが仕事」と定義し直す
検知を本人の勇気に依存させない。短いデイリー・分報・定期の画面共有から最低1つ用意する
分報は作るだけでは無意味。誰がいつ拾うかまで決めて初めて仕組みになる
質問された時の最初の反応が全てを決める。手が離せない時は拒絶ではなく時刻を返す
良い質問の形式（やりたいこと／試したこと／エラー全文／仮説）はテンプレートで教える
リモートでは沈黙が拒絶として伝わる。内容が無くても反応だけは即座に返す