この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
セミナーでも職場でも、技術力はあるのに「質問の仕方」で損をしている人を、私はこれまで何度も見てきました。同じ問題を抱えていても、聞き方ひとつで解決までの時間が10分になるか2時間になるか、大きく変わります。
この記事では、3,100名以上にLinuxを教えてきた経験から、現場で信頼される「質問の仕方」と「障害報告の伝え方」について解説します。技術そのものではなく、技術を伝える力が、あなたの評価を大きく左右します。
この記事のポイント
・質問が下手なエンジニアに共通する3つのパターン
・「何がわからないかわからない」を脱出する事実→ギャップ→試行の3ステップ
・現場で一発で伝わる障害報告テンプレート（5項目）
・質問力を鍛えることがLinux学習の加速につながる理由
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「質問が下手な人」に共通する3つのパターン
セミナーで3,100名以上の受講生を見てきた中で、質問がうまくいかない人には明確な共通点があります。技術レベルの問題ではなく、伝え方の問題です。そして、この伝え方は意識すれば誰でも変えられます。1. 「動きません」で終わる
最も多いパターンです。「このコマンドが動きません」「エラーが出ます」——これだけでは、何も伝わっていません。聞かれた側は「何を実行したのか」「どんな環境か」「エラーメッセージは何か」を一つずつ確認しなければならず、それだけで時間を消費します。
私のセミナーでも、ハンズオン中に手が止まった受講生に「何が起きていますか？」と聞くと、「動かないです」としか返ってこないことがあります。悪意はまったくないのですが、相手に判断材料を渡せていないのです。
このパターンには、もう一つ見落とされがちな問題があります。「動きません」だけで終わると、「自分で考えていない人」という印象を周囲に与えてしまうことです。現場では、エラーメッセージすら読んでいないと思われることもあります。少しの言葉を加えるだけで、その印象は大きく変わります。
2. 情報を出しすぎて焦点がぼやける
逆のパターンもあります。ターミナルの出力を全部コピーして「これ見てください」と送ってくる人です。100行のログをそのまま貼り付けても、受け取った側は「どこを確認すればいいのか」がわかりません。問題の箇所を絞り込めていないということは、自分の中で整理ができていないということでもあります。
「必要な情報だけに絞り込む」という作業は、そのままトラブルの切り分け作業でもあります。どこが問題か自分でも特定できていない段階では、せめて「このあたりが怪しいと思っています」という自分の見立てを一言添えるだけで、回答者は大幅に助かります。
3. 自分が試したことを伝えない
「○○がうまくいきません」と聞いてくる人に「何を試しましたか？」と返すと、「何も」と答えるケースがあります。これは厳しいようですが、「調べてから聞いてほしい」と思われても仕方ありません。逆に、「Aを試したがダメで、Bも試したが状況は変わらなかった」と言えるだけで、相手の受け取り方はまったく違います。自分が何をやったかを伝えることで、相手は「では次はCを試しましょう」と即座に判断できるからです。
VirtualBoxなどの検証環境を持っていると、この「試した証拠」が自然に増えます。本番環境を壊すリスクなしに仮説を検証できるので、「Aを試した」「Bを試した」という報告が具体的かつ安全に積み上がっていきます。まだ検証環境を持っていない方は、そこから始めることも一つの突破口です。
「何がわからないかわからない」を抜け出す方法
質問が苦手な人の多くが口にするのが、「何がわからないかわからない」という状態です。20年近くLinuxサーバーを運用してきた経験から言うと、この状態は「知識が足りない」のではなく、「整理の手順を知らない」ことが原因です。以下の3ステップで、誰でもこの状態から抜け出せます。
ステップ1：事実を書き出す
「何をしたか」「何が表示されたか」を、そのまま書き出します。解釈や推測は入れません。# 事実を書き出す例 # 実行したコマンド $ systemctl restart httpd # 表示されたエラー Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details.
ステップ2：期待と現実のギャップを言語化する
「本当はこうなるはずだった」と「実際にこうなった」を並べます。・期待：httpdが起動して、Webページが表示される
・現実：httpdの起動に失敗して、エラーメッセージが出た
このギャップが「質問の核」になります。ここまで整理できれば、「httpdをrestartしたら起動に失敗しました。正常に起動させるにはどうすればいいですか？」という具体的な質問が自然に出てきます。
「当たり前のことを書く必要がある？」と思う人もいます。あります。期待値を言語化する過程で「そもそも自分は何を期待していたのか」が明確になり、「その期待は正しいのか」という問いかけも生まれるからです。前提が間違っていたと気づく場合もあります。
ステップ3：自分で試したことを添える
ステップ2の質問に「自分が調べたこと」「試したこと」を加えます。# エラーの詳細を確認 $ systemctl status httpd.service # → "AH00526: Syntax error on line 56 of /etc/httpd/conf/httpd.conf" # 設定ファイルの該当行を確認 $ sed -n '55,57p' /etc/httpd/conf/httpd.conf
私のセミナーでは「ここまで書いているうちに、自分で解決しました」という受講生が珍しくありません。整理するプロセスそのものが、問題解決になっているのです。
現場で一発で伝わる障害報告テンプレート
セミナーだけでなく、実際の運用現場でも「報告の仕方」は極めて重要です。私がSE時代に先輩から叩き込まれたのは、「障害報告は5行で伝えろ」というルールでした。・いつ：発生日時（例：2026-04-14 09:15 JST）
・どこで：対象サーバー・サービス名（例：web01 / httpd）
・何が：現象の一文要約（例：httpdが起動失敗）
・影響：ユーザーへの影響範囲（例：外部公開Webページが閲覧不可）
・対応：今やっていること/次にやること（例：httpd.confの構文チェック中）
この5項目が揃っていれば、上司やチームメンバーは状況を即座に把握できます。逆に「サーバーが落ちました」だけでは、「どのサーバー？」「いつから？」「影響は？」と質問のラリーが始まり、対応が遅れます。
5項目を文章にするとこうなる
上の5項目を実際の報告文に組み立てると、次のようになります。【第一報】2026-04-14 09:20 JST いつ : 2026-04-14 09:15 JST（監視アラートで検知） どこで : web01 / httpd 何が : httpdが起動失敗。Webページが503を返している状態。 影響 : 外部公開サイト全体が閲覧不可 対応 : httpd.confの構文確認中。apachectl configtestを実行予定。
受講生からよく聞かれる質問が、「報告は完璧にしてから出すべきですか？」というものです。答えはNOです。5項目が埋まった時点で第一報を出す。調査が進んだら続報を出す。完璧を待っていたら報告が遅れ、遅れた報告は「隠していた」と受け取られかねません。
質問力がLinux学習を加速させる理由
「質問の仕方」は単なるコミュニケーションスキルではありません。Linux学習そのものを加速させる力を持っています。なぜなら、質問を組み立てるプロセスが、そのままトラブルシューティングの手順だからです。
・事実を書き出す → ログを正確に読む力
・期待と現実のギャップを言語化する → 問題の切り分け能力
・自分で試したことを伝える → 仮説検証の習慣
私のセミナーでは、「質問を整理しているうちに自分で答えが見つかりました」と言う受講生が少なくありません。これは「ラバーダックデバッグ」と呼ばれる手法と同じ原理です。誰かに説明しようとする過程で、自分の理解の穴が見えてくるのです。
20年近くサーバーを運用してきた経験から言うと、ベテランエンジニアほど質問がうまい。それは「知識が豊富だから」ではなく、「問題を整理する手順が身についているから」です。質問力は、技術力と別のものではなく、技術力の一部そのものです。
質問の仕方がチーム全体のスピードを変える
質問力の恩恵は、質問する本人だけにとどまりません。チーム全体の問題解決スピードに直結します。5人のチームがいたとして、全員が「事実→ギャップ→試したこと」で質問できるようになると、1日に処理できるトラブルの件数が変わります。それぞれが自分で整理してから聞くようになるだけで、チーム内の「確認待ち」時間が大幅に減るからです。
私が指導してきた現場でも、質問の仕方がそろうと、コミュニケーションが目に見えて変わります。「動きません」の一言が減り、代わりに「◯◯を確認したところ◯◯でした。次に◯◯を試そうと思いますが、方向性は合っていますか？」という質問に変わっていきます。これが「任せられるチーム」の姿です。
まとめ
| ポイント | 内容 |
|---|---|
| ダメな質問の共通点 | 「動きません」だけ/情報過多で焦点なし/試行なし |
| 整理の3ステップ | 事実を書く→ギャップを言語化→試したことを添える |
| 障害報告の5項目 | いつ/どこで/何が/影響/対応 |
| 第一報のタイミング | 完璧を待たず5項目が揃ったら即送る |
| 質問力と技術力の関係 | 質問の整理手順＝トラブルシューティング手順 |
| チームへの波及効果 | 全員が整理してから聞く習慣がチームのスピードを上げる |
逆に言えば、質問力は意識すれば誰でもすぐに伸ばせるスキルです。次にLinuxで何か困ったとき、「事実→ギャップ→試したこと」の3ステップを試してみてください。それだけで、周囲の反応が変わるはずです。
「質問できる自分」になるために、まずLinuxの基礎を固めませんか
質問の質を上げるには、基礎知識という「共通言語」が必要です。
何を聞けばいいかわからないのは、知識が足りないからではなく、整理の土台がないから。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxの設定ファイルが「読める」と現場の仕事が変わる理由｜現役講師が伝える設定力の鍛え方
- 前のページへ：Linuxエンジニアとして「一人前」になるまでに必ず越える3つのステージ｜3,100名を指導した現役講師が語るキャリアの節目
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます