セミナーでも職場でも、技術力はあるのに「質問の仕方」で損をしている人を、私はこれまで何度も見てきました。
この記事では、3,100名以上にLinuxを教えてきた経験から、現場で信頼される「質問の仕方」と「障害報告の伝え方」について解説します。技術そのものではなく、技術を伝える力が、あなたの評価を大きく左右します。
【この記事でわかること】
・質問が下手なエンジニアに共通する3つのパターン
・「何がわからないかわからない」を脱出する具体的な手順
・現場で一発で伝わる障害報告テンプレート
・質問力を鍛えることがLinux学習の加速につながる理由
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「質問が下手な人」に共通する3つのパターン
セミナーで3,100名以上の受講生を見てきた中で、質問がうまくいかない人には明確な共通点があります。技術レベルの問題ではなく、伝え方の問題です。1. 「動きません」で終わる
最も多いパターンです。「このコマンドが動きません」「エラーが出ます」——これだけでは、何も伝わっていません。聞かれた側は「何を実行したのか」「どんな環境か」「エラーメッセージは何か」を一つずつ確認しなければならず、それだけで時間を消費します。
私のセミナーでも、ハンズオン中に手が止まった受講生に「何が起きていますか？」と聞くと、「動かないです」としか返ってこないことがあります。悪意はまったくないのですが、相手に判断材料を渡せていないのです。
2. 情報を出しすぎて焦点がぼやける
逆のパターンもあります。ターミナルの出力を全部コピーして「これ見てください」と送ってくる人です。100行のログをそのまま貼り付けても、受け取った側は「どこを見ればいいのか」がわかりません。問題の箇所を絞り込めていないということは、自分の中で整理ができていないということでもあります。
3. 自分が試したことを伝えない
「○○がうまくいきません」と聞いてくる人に「何を試しましたか？」と返すと、「何も」と答えるケースがあります。これは厳しいようですが、「調べてから聞いてほしい」と思われても仕方ありません。逆に、「Aを試したがダメで、Bも試したが状況は変わらなかった」と言えるだけで、相手の受け取り方はまったく違います。自分が何をやったかを伝えることで、相手は「では次はCを試しましょう」と即座に判断できるからです。
「何がわからないかわからない」を抜け出す方法
質問が苦手な人の多くが口にするのが、「何がわからないかわからない」という状態です。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項目が揃っていれば、上司やチームメンバーは状況を即座に把握できます。逆に「サーバーが落ちました」だけでは、「どのサーバー？」「いつから？」「影響は？」と質問のラリーが始まり、対応が遅れます。
受講生からよく聞かれる質問が、「報告は完璧にしてから出すべきですか？」というものです。答えはNOです。5項目が埋まった時点で第一報を出す。調査が進んだら続報を出す。完璧を待っていたら報告が遅れ、遅れた報告は「隠していた」と受け取られかねません。
質問力がLinux学習を加速させる理由
「質問の仕方」は単なるコミュニケーションスキルではありません。Linux学習そのものを加速させる力を持っています。なぜなら、質問を組み立てるプロセスが、そのままトラブルシューティングの手順だからです。
・事実を書き出す → ログを正確に読む力
・期待と現実のギャップを言語化する → 問題の切り分け能力
・自分で試したことを伝える → 仮説検証の習慣
私のセミナーでは、「質問を整理しているうちに自分で答えが見つかりました」と言う受講生が少なくありません。これは「ラバーダックデバッグ」と呼ばれる手法と同じ原理です。誰かに説明しようとする過程で、自分の理解の穴が見えてくるのです。
20年近くサーバーを運用してきた経験から言うと、ベテランエンジニアほど質問がうまい。それは「知識が豊富だから」ではなく、「問題を整理する手順が身についているから」です。質問力は、技術力と別のものではなく、技術力の一部そのものです。
まとめ
| ポイント | 内容 |
|---|---|
| ダメな質問の共通点 | 「動きません」だけ/情報過多で焦点なし/試行なし |
| 整理の3ステップ | 事実を書く→ギャップを言語化→試したことを添える |
| 障害報告の5項目 | いつ/どこで/何が/影響/対応 |
| 質問力と技術力の関係 | 質問の整理手順＝トラブルシューティング手順 |
逆に言えば、質問力は意識すれば誰でもすぐに伸ばせるスキルです。次にLinuxで何か困ったとき、「事実→ギャップ→試したこと」の3ステップを試してみてください。それだけで、周囲の反応が変わるはずです。
「質問できる自分」になるために、まずLinuxの基礎を固めませんか
質問の質を上げるには、基礎知識という「共通言語」が必要です。
何を聞けばいいかわからないのは、知識が足りないからではなく、整理の土台がないから。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxの設定ファイルが「読める」と現場の仕事が変わる理由｜現役講師が伝える設定力の鍛え方
- 前のページへ：Linuxエンジニアとして「一人前」になるまでに必ず越える3つのステージ｜3,100名を指導した現役講師が語るキャリアの節目
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます