SEの働き方研究所

タグ: コミュニケーション

  • 質問が下手なエンジニアの特徴5選｜「聞いてるのに成長しない人」の共通点

    質問が下手なエンジニアの特徴5選｜「聞いてるのに成長しない人」の共通点

    こんなことない？

    • 質問してるのに、なぜか評価が上がらない
    • 「それ前も聞いたよね？」って言われる
    • 聞いてるつもりなのに理解が浅い

    実はこれ、

    “質問している＝良い”ではない

    が原因。

    質問の仕方次第で、

    成長が早い人 ずっと同じところで止まる人

    にハッキリ分かれる。

    この記事では、

    • 質問が下手な人の特徴
    • やってはいけないNG行動
    • できる人の質問テンプレ

    を、現場ベースで解説する。

    ■目次

    ① 丸投げ質問をしてしまう

    ■あるある

    「これ分かんないんですけど、教えてください」

    　　⇒情報ゼロ

    ■なぜ起きる？

    • 考えずにすぐ聞く
    • 自分で整理していない

    ❌NG行動

    • 状況説明なし
    • 試したことを言わない
    • 結論だけ聞く

    ✅解決方法

    「状況＋試したこと＋詰まりポイント」をセットで伝える

    例：

    「〇〇をやろうとしていて、△△を試したんですが、ここで詰まっています」

    　⇒これだけで一気に“できる感”出る

    ② 前提を説明しない

    ■あるある

    いきなり質問だけ飛んでくる

    　　⇒受け手「？？？」

    ■なぜ起きる？

    • 自分の中では分かってる
    • 相手も分かってると思っている

    ❌NG行動

    • 背景なしで質問
    • 専門用語だけで話す

    ✅解決方法

    「誰が聞いても分かる前提」を添える

    何をしているのか 何のための作業か

    ⇒これで会話のズレが消える

    ③ 自分の考えを持たずに聞く

    ■あるある

    「どうすればいいですか？」

    ⇒全部丸投げ

    ■なぜ起きる？

    • 間違えるのが怖い
    • 自信がない

    ❌NG行動

    • 完全受け身
    • 思考停止

    ✅解決方法

    「仮説」をつける

    例：

    「〇〇だと思ったんですが合ってますか？」

    　　⇒これができると成長スピードが段違い

    ④ 同じことを何度も聞く

    ■あるある

    「前も聞いたよね？」

    ⇒一番評価落ちるやつ

    ■なぜ起きる？

    • メモしていない
    • 理解せずに流している

    ❌NG行動

    • メモなし
    • 復習しない

    ✅解決方法

    「自分用ナレッジ」を作る

    同じ質問はまとめる 自分の言葉で整理する

    ⇒“資産化”できる人は強い

    ⑤ タイミングが悪い

    ■あるある

    忙しそうな時に話しかける or 遅すぎる

    ■なぜ起きる？

    • 周りが見えていない
    • 自分都合で動いている

    ❌NG行動

    • 空気を読まない
    • 詰まりすぎてから聞く

    ✅解決方法

    「30分ルール＋一言クッション」

    例：

    「今少しお時間いいですか？」

    ⇒これだけで印象が変わる

    ■まとめ

    質問が下手な人の特徴はこの5つ💡

    • 丸投げしている
    • 前提がない
    • 自分の考えがない
    • 同じことを聞く
    • タイミングが悪い

    逆に言えば、

    ここを改善するだけで一気に評価が上がる

    質問は“量”じゃなくて“質”。

    いい質問ができる人は、

    間違いなく伸びる。

    このブログでは、

    ・新人〜中堅エンジニア向けに

    ・現場で評価される考え方

    ・実務で使えるスキル

    を、実体験ベースで発信しています。

    「なんとなく働く」から抜け出して、

    一段上のエンジニアへ。

  • 新人エンジニアが最初に躓くポイント5選｜「これやってたらヤバい」を全部まとめた

    新人エンジニアが最初に躓くポイント5選｜「これやってたらヤバい」を全部まとめた

    新人エンジニアとして現場に入ったとき、こんなこと思わなかった？

    何をすればいいのか分からない 聞いていいのか分からない 自分だけできてない気がする

    実はこれ、ほぼ全員通る道。

    でも問題はここからで、

    同じミスを続ける人と、すぐ抜ける人に分かれる。

    この記事では、現場でよくある

    「新人エンジニアが最初に躓くポイント」を5つに絞って、

    なぜ躓くのか 何がダメなのか どうすれば抜け出せるのか

    まで、リアルベースで解説する。

    ■目次

    ① 何を聞けばいいか分からない問題

    ■あるある

    「すみません…何を質問すればいいか分からなくて…」

    これ、かなり多い

    ■なぜ起きる？

    自分の理解度が整理できてない 何が分からないか分かってない

    ❌NG行動

    • とりあえず黙る
    • 雰囲気で進める
    • 後でまとめて聞こうとする

    これ全部アウト

    ✅解決方法

    「分からない」を分解する

    例：

    どこまで分かっているか

    どこから分からないか

    何が知りたいのか

    これを言語化するだけで

    質問の質が一気に上がる

    ② 「分かりました」で思考停止してしまう

    ■あるある

    上司「これこうやってね」

    新人「分かりました！」

    　　⇒（分かってない）

    ■なぜ起きる？

    • 理解した気になっている
    • 深く考えていない

    ❌NG行動

    • 即答で「分かりました」
    • 復唱しない
    • メモだけ取って終わり

    ✅解決方法

    ⇒「自分の言葉で言い換える」

    例：

    「つまり〇〇ってことですか？」

    これやるだけで

    　　⇒理解度＋信頼度が爆上がり

    ③ 報告・相談のタイミングが遅い

    ■あるある

    「詰まってたんですけど…今いいですか？」

    　　⇒いや、もっと早く言え

    ■なぜ起きる？

    • 自力で解決しようとしすぎる
    • 迷惑をかけたくない

    ❌NG行動

    1時間以上悩む 完璧な状態で相談しようとする

    ✅解決方法

    ⇒「詰まり時間ルール」を決める

    例：

    30分考えてダメなら聞く

    　　⇒これだけで評価変わる

    ④ 受け身すぎて成長が止まる

    ■あるある

    • 指示待ち
    • 言われたことだけやる

    ■なぜ起きる？

    • 失敗が怖い
    • 何していいか分からない

    ❌NG行動

    指示を待つ 自分で調べない

    ✅解決方法

    ⇒「仮説を持って動く」

    例：

    「こう思ったんですが合ってますか？」

    　　⇒これができると一気に“できる感”出る

    ⑤ 技術だけやればいいと思っている

    ■あるある

    「コード書ければOKでしょ」

    　　⇒これ、半分正解で半分アウト

    ■なぜ起きる？

    学習フェーズの延長 技術＝仕事だと思ってる

    ❌NG行動

    • コミュニケーション軽視
    • 目的を理解しない

    ✅解決方法

    ⇒「仕事＝価値提供」と理解する

    • なぜこの開発をやるのか
    • 誰のためなのか

    　　⇒ここ考えるだけで評価変わる

    ■まとめ

    新人エンジニアが最初に躓くポイントはこの5つ❗️

    • 何を聞けばいいか分からない
    • 「分かりました」で止まる
    • 報告が遅い
    • 受け身
    • 技術だけに偏る

    でも逆に言えば、

    ⇒ここを意識するだけで一気に差がつく

    最初から完璧な人はいない。

    ただ、“気づいて直す人”は伸びる。

    このブログでは、
    現役エンジニア視点で
    • 現場で評価される考え方
    • 新人〜中堅が躓きやすいポイント
    • 技術だけじゃない「仕事力」

    を、実体験ベースで発信しています。

    「なんとなく働く」から抜け出して、
    一段上のエンジニアを目指したい人へ。

  • 現場で評価されるエンジニアは「結論→方針」で話す。結論ファーストの実践法

    現場で評価されるエンジニアは「結論→方針」で話す。結論ファーストの実践法

    「で、結論は？」

    この一言に、何度やられたかわからない。

    新人の頃、いや正直ここ最近まで、僕は“話口調”で報告してしまうタイプだった。
    「えっとですね、まず今回の障害なんですけど…昨日の夜にログを見たら…」みたいなやつ。

    上司からは毎回こう言われる。

    「結論から話して」

    分かってる。分かってるんだけど、できない。
    今回は、そんな自分がどうやって“結論ファースト”を理解していったかをまとめる。

    ■ 目次

    ■ なぜシステムエンジニアは「話口調」で報告してしまうのか？

    まずここを分解しないと、改善はできない。

    ありがちな心理はこのあたり↓

    • 理由から説明した方が“正確”だと思っている
    • 原因や背景を話さないと“理解されない”と思っている
    • 頭の中で整理できていないから、考えながら話している
    • 「結論を間違えたら怖い」という不安がある
    • 技術的な話は順序立てないと伝わらないと思い込んでいる

    要するにこれ、

    「ちゃんと伝えたい」が強すぎる

    でもビジネスの場では、これが逆効果になる。

    ■ 結論ファーストが求められる理由（エンジニア視点）

    シンプルにこれ。

    • 相手（PM・上司）は忙しい
    • 判断したいだけで、ストーリーは後でいい
    • 会話は“情報共有”じゃなく“意思決定”のため

    つまり、

    「正しく話す」より「早く判断させる」が優先

    ここを理解しないと、一生「で、結論は？」って言われる。

    ■ よくあるNGパターンと改善方法

    ① 背景から話し始める人

    NG例：

    「今回の障害なんですが、まず昨日の夜に〜」

    改善：
    最初にこう言う

    「結論から言うと、原因は〇〇で、対応は△△済みです」

    ② 原因を探しながら話す人

    NG例：

    「おそらくなんですが…ログを見ると…いやでも…」

    ここ、実は多くの人が誤解している。

    よくある改善として
    「現時点の結論は〇〇の可能性が高いです」と言いがちなんだけど、これだと少し弱い。

    なぜか？

    それ、“結論”じゃなくて“仮説（状況報告）”だから。

    ▼ じゃあ結論って何？

    ビジネスにおける結論はこれ

     「どうするか（意思・方針）」まで含めて結論

    ▼ NGとOKの違い

    ❌ NG（弱い）

    「原因はDB負荷の可能性が高いです」

    → ただの分析途中

    ✅ OK（これが結論）

    「原因はDB負荷の可能性が高いため、DBの負荷軽減対応を進めます」

    “だからどうする”まで言って初めて結論になる

    ▼ 実務で使える言い回し

    • 「現時点では〇〇の可能性が高いと判断しています。その前提で△△を進めます」
    • 「対応方針としては、〇〇が原因と仮定して△△を実施します」
    • 「結論としては、〇〇前提で動くのが妥当です」

    ▼ なぜ「可能性が高い」だけだとダメなのか

    意思が抜けているから

    上司が欲しいのは「分析」ではなく「判断材料」か「判断そのもの」。

    だから、

    仮説 + 方針 = 結論

    ③ 時系列で説明したくなる人

    NG例：

    「まずAが起きて、その後Bが起きて…」

    改善：

    「結果として、最終的に〇〇の状態です」

    ④ 情報を全部伝えたくなる人

    NG例：

    「関連するログが3つあって、それぞれ説明すると…」

    改善：

    「判断に必要なポイントは2つです」

    ■ 結論ファーストで話すためのシンプルな型

    結論 → 理由 → 補足

    例

    「結論から言うと、今回のリリースは延期した方がいいです。
    理由は、バグが本番影響レベルで残っているためです。
    補足として、現在修正中で明日には見通しが立ちます。」

    ■ それでも話口調になってしまう人へ

    原因はシンプル。

    頭の中で結論が決まってない

    対策

    • 話す前に「一言で言うと？」を自分に問う
    • チャットで一回書き出してから話す
    • 「結論：〇〇です」を口癖にする
    • とにかく実践！意識して話す！

    ■ まとめ

    • エンジニアは「正確に話したい」が強く、話口調になりがち
    • 求められているのは「判断させること」
    • 「可能性が高い」は結論ではなく仮説
    • 結論とは“どうするか”まで含めたもの
    • 仮説 + 方針で話せば一気に通る

    「で、結論は？」と言われる前に、“どうするか”まで言おう。

    これだけで、評価は変わる。

    このブログでは、
    エンジニアとして実際に経験してきたことや、現場で感じた課題・学びをもとに、

    • エンジニアの悩みとその解決
    • 業務効率化・仕事の進め方
    • コミュニケーションの工夫

    など、実務でそのまま使える内容を発信しています。

    同じように悩んでいる方のヒントになれば嬉しいですし、
    コメントで意見をいただけると、自分にとっても新しい気づきになります。

    案件・相談はXのDMまで