聞き方ひとつで、現場の信頼は変わる

株式会社Codence代表の西野です。

4月に入りました。新しい現場に配属されたエンジニアの方も多いのではないでしょうか。環境が変わると、最初の数週間はとにかく緊張します。プロジェクトの全体像が見えない。チームメンバーの名前と顔が一致しない。開発環境のセットアップだけで初日が終わる。

私自身、SESエンジニアとして何度も「新しい現場の初日」を経験してきました。そのたびに感じていたのは、技術的なキャッチアップよりも「聞けないこと」のほうがずっとストレスだということです。

今日は、SES現場を何度も経験してきた私が「聞き方」について書いてみます。技術の話ではありません。でも、技術力と同じくらい、もしかしたらそれ以上に、エンジニアのキャリアに影響する話だと思っています。

「わからない」を言えない空気

新しい現場に入ると、最初は何もかもがわからない状態になります。プロジェクトの背景、コードベースの設計思想、ブランチ運用のルール、会議の進め方。技術力がどれだけあっても、その現場固有のことは入ってみないとわかりません。

問題は、その「わからない」を口に出せるかどうかです。

私がエンジニアだった頃、ある金融系のプロジェクトに途中参画したことがあります。既存のコードが数十万行あって、ドキュメントは断片的にしか残っていませんでした。最初のタスクとして渡された機能改修の仕様書を読んだのですが、前提条件が省略されていて、肝心な部分がわからない。

その時、隣の席のリーダーに聞けばよかったのですが、聞けませんでした。理由は単純で、「こんなことも読み取れないのか」と思われるのが怖かったからです。

結局、自分の解釈で2日間かけて実装を進めました。レビューの場で「前提が違います。この機能は既存のモジュールと連動する想定です」と指摘されて、全部やり直しになった。あの時、最初に30分確認していれば防げた手戻りでした。

「わからないこと」自体は恥ずかしくない。でも「わからないまま進めてしまうこと」は、自分の信頼を大きく損ないます。2日間、間違った方向に走っていたエンジニアと、初日に「ここがわかりません」と聞けたエンジニア。どちらが信頼されるかは明らかです。

手が止まったら15分で聞く

「まずは自分で調べてから聞くべき」というのは、どの現場でも言われることです。それ自体は正しい。ただ、このアドバイスを真面目に受け取りすぎると、いつまでたっても聞けない状態に陥ります。

「もう少し調べればわかるかもしれない」「ここまで調べたのだからもう少し粘りたい」と思っているうちに半日が過ぎていた。そんな経験のあるエンジニアは多いはずです。

私が今、Codenceのエンジニアに伝えているのは「15分ルール」です。自分で調べて15分経っても手が動かないなら、そこが聞くタイミング。

15分という数字に科学的な根拠があるわけではありません。ただ、15分あれば「まったく調べていない」とは言われない。一方で、15分以上ハマっているなら、自力で解決するよりも聞いたほうが速いことがほとんどです。

大事なのは、自分なりに調べたという事実をつくること。そしてその上で聞く。何も調べずに聞く人と、15分調べた上で聞く人では、同じ質問でも相手の受け取り方がまるで違います。

もう一つ補足すると、「15分調べた」は「15分Googleを眺めていた」とは違います。エラーメッセージを読んだ。公式ドキュメントを確認した。類似のコードをプロジェクト内で探した。こうした具体的なアクションを15分間でやった上で「ここまで調べたのですが」と聞けると、相手の反応は確実に変わります。

聞き方には「型」がある

現場で信頼されるエンジニアの聞き方を観察していると、共通するパターンがあります。

一つ目は、自分がどこまで理解しているかを先に伝えること。

「この仕様がわかりません」という聞き方と、「この仕様について、AとBの処理フローまでは理解できたのですが、Cの条件分岐のところで既存テーブルとの整合性がわからなくなりました」という聞き方では、相手の印象がまったく変わります。

前者は、何がわからないのかもわからないように聞こえてしまう。後者は、ここまで考えた上でピンポイントで詰まっている、と伝わります。相手も回答しやすくなるので、やりとりの効率も上がる。

二つ目は、自分の仮説を添えること。

「Cの条件分岐は、ユーザーのステータスがアクティブの場合だけ実行されると理解していますが、合っていますか？」と聞ければ、相手はYes/Noで答えられます。これは相手の時間を最小限にする配慮です。

SES現場では、自分はクライアントのチームに参画している立場です。相手は自分の業務を抱えながら、時間を割いて教えてくれている。その意識があるかどうかは、質問の仕方ににじみ出ます。仮説を添えて聞くというのは、相手の時間を大切にしているという意思表示でもあるのです。

三つ目は、聞いた結果を記録して同じことを二度聞かないこと。

これは当たり前のようで、意外とできていない人が多い。新しい現場では一日に大量の情報が流れ込んできます。昨日聞いたことを今日もう一度聞いてしまうのは、起こりがちなミスです。

だからこそ、メモの習慣が重要です。ノートでもテキストファイルでもNotionでも何でもいい。聞いた内容を書き残す。翌朝、出社前に見返す。それだけで「同じことを聞かない人」という信頼が積み上がります。

私がエンジニア時代にやっていたのは、プロジェクト専用のメモファイルを一つ作って、日付ごとに「聞いたこと」「教えてもらったこと」「自分で調べて解決したこと」を記録することでした。これを1ヶ月も続けると、そのプロジェクトのナレッジベースのようなものが出来上がります。後から見返すと、自分の理解がどう深まっていったかもわかる。地味な作業ですが、確実に効きます。

「ありがとうございます」が次の質問のハードルを下げる

聞いた後の対応も、実は大きな意味を持っています。

教えてもらったら「ありがとうございます」と伝える。そして、その結果どうなったかを簡単にフィードバックする。「教えていただいた方法で解決できました」「あの後、こういう形で実装を進めています」と一言報告するだけで、相手は「教えてよかった」と感じます。

逆に、聞くだけ聞いて、その後どうなったのか報告がない人には、次から教える気が薄れていく。これは人間として自然な感情です。

こうした小さな積み重ねが、「次にまた聞きやすい関係」をつくっていきます。3回、4回と質問を重ねるうちに、相手のほうから「何か困ってることある？」と声をかけてもらえるようになる。

そこまでいけば、もうその現場に自分の居場所ができた証拠です。SES現場では、この「居場所をつくるスピード」がエンジニアの評価に直結します。プロジェクトの期間は限られている。最初の2週間で信頼関係を築けるか、1ヶ月かかるかで、その後のパフォーマンスはまるで違うものになります。

私がエンジニア時代に経験した中で、特に印象に残っていることがあります。ある現場で、私がレビューで教えてもらったことを翌日の朝会で「昨日のレビューで指摘いただいた点を修正しました。こういう理由でこの書き方に変えています」と報告したことがありました。レビューしてくれた先輩が「おお、ちゃんと考えて直してくれたんだね」と嬉しそうに言ってくれた。些細なことです。でも、そこから明らかにそのレビュアーとの関係が変わりました。次のレビューでは、指摘だけでなく「ここ、こういうやり方もあるよ」と、より踏み込んだアドバイスをもらえるようになった。聞く、感謝する、報告する。このサイクルが回り始めると、学びの密度が一気に上がります。

「聞ける」は才能ではなく、練習で身につく

経営者になって、エンジニアの面談をする機会が増えました。さまざまな現場経験を持つ人の話を聞いていると、あるパターンが見えてきます。

技術力が高いのに現場での評価が伸び悩んでいる人に共通しているのは、「一人で抱え込みやすい」ということです。自分で解決することにこだわりが強い。それ自体は立派な姿勢ですが、チーム開発においては、適切なタイミングで助けを求めることも能力の一つです。

逆に、技術的にはまだ発展途上でも、素直に聞ける人は現場での評価が高い傾向にあります。「あの人は聞いてくれるから安心する」と周囲から言われるのは、エンジニアにとって大きな武器です。

なぜ安心するのか。それは、問題が小さいうちに表面化するからです。聞かない人が抱え込んだ問題は、納期直前に大きなトラブルとして表に出ることがある。プロジェクトマネージャーやリーダーが最も恐れるのはこのパターンです。早い段階で「ここが詰まっています」と言ってくれる人がいると、チーム全体のリスクが下がります。

「聞ける」というのは、生まれつきの性格だと思われがちです。でも私はこれを練習で身につく技術だと考えています。最初は勇気がいる。声をかけるタイミングを計って、結局かけられなかった日もあるでしょう。

ただ、一度聞いてみて「全然大丈夫だよ。むしろ聞いてくれて助かる」と言われる経験をすれば、次からのハードルは確実に下がります。その「最初の一回」をどう乗り越えるかが分かれ道です。

声に出すのが難しければ、テキストから始めてもいい。Slackで「お忙しいところすみません。○○について確認させてください」と送ってみる。対面より心理的なハードルは低いはずです。そこから少しずつ、直接聞けるようになっていけばいい。

SES特有の「聞く相手がわからない」問題

SESの現場には、もう一つ独特の難しさがあります。自社開発のチームと違って、誰に何を聞けばいいのか、最初はまったくわからないということです。

プロパー社員の関係性や、暗黙のヒエラルキーがある。PMに直接聞いていい案件と、まずリーダーを通すべき案件がある。それを誰も明示的に教えてくれないことも珍しくありません。

私が実践していたのは、最初の数日で「この人に聞けば大丈夫」という人を一人見つけることです。チーム全員と関係を築く必要はない。まずは一人、気軽に聞ける相手ができれば、その人を起点にしてチーム内の情報が入ってくるようになります。

見つけ方は難しくありません。会議中にわかりやすく説明している人、休憩中にチームメンバーと雑談している人、新しく入ったメンバーに声をかけている人。そういう人はだいたい「聞かれ慣れている」人です。

その人に最初に聞く質問は、業務の内容でなくてもいい。「このプロジェクトで困ったときは誰に聞くのがいいですか？」と聞くだけでも十分です。誰に聞けばいいかを聞く。それだけで、現場での動き方が一気にクリアになります。

SES歴が長くなると、この「最初の一人を見つけるスピード」がどんどん上がります。新しい現場に入ったときの立ち上がりが速い人は、技術のキャッチアップが速いのではなく、人間関係の入口をつくるのがうまい。そしてその入口は、たいてい「上手に聞くこと」から始まっています。

質問しやすい空気は、自分からもつくれる

ここまでは「聞く側」の話を書いてきましたが、実は逆の視点もあります。

SES現場で経験を積んでいくと、自分が後輩やチームの新しいメンバーから質問を受ける側になることも増えてきます。その時に「自分は聞かれやすい人だろうか？」と振り返ってみてほしいのです。

忙しそうにしている人には、誰も質問しません。イヤホンをつけて画面に集中している人にも、声をかけづらい。それは自分がかつて感じていたことと同じです。

自分が新しい現場で「聞けなくて苦しかった」経験があるなら、その経験を活かすことができます。新しく入ってきた人に「何か困ったことがあったら遠慮なく聞いてね」と一言伝えるだけで、相手の不安は少し和らぎます。そして、聞かれたときに面倒くさそうにしない。丁寧に答える。それだけで、チームの空気は変わります。

Codenceでは、社員同士でこうした「聞きやすい関係」を大事にしています。まだ小さな会社だからこそ、お互いのことをよく見て、困っていそうなら声をかける。SESで別々の現場にいても、Slackで「最近どう？」と聞くだけで、一人で抱え込まなくて済む場面が生まれます。

4月、新しい現場に立っている人へ

もし今、新しい環境で「聞いていいのかわからない」と悩んでいるなら、小さなことから始めてみてください。

朝の挨拶の後に「少しお時間いただけますか？」と一言添えてみる。それだけで十分です。

最初の一歩は小さくていい。ただ、その一歩を踏み出した人と踏み出さなかった人では、1ヶ月後、3ヶ月後に想像以上の差がついています。

聞き方ひとつで、現場での居場所ができる。居場所ができれば、自分の技術力を発揮する土台が整う。

SESという働き方は、現場が変わるたびに人間関係を一から築かなくてはなりません。だからこそ、短い期間で信頼を構築するスキルが求められます。聞き方は、その中でも最も早く効果が出る部分です。

私たちCodenceは、まだ会社です。社員も片手で数えられるくらいの規模で、それぞれがSESの現場で日々奮闘しています。だからこそ、エンジニアが現場で力を発揮できるように、技術の話だけでなく「現場でどう振る舞うか」という部分も真剣に考えています。

月に一度の面談では、技術的なスキルアップだけでなく、現場での人間関係やコミュニケーションの悩みも話します。「聞き方がうまくいかなくて」という相談があれば、具体的にどう聞けばよかったかを一緒に振り返る。小さな会社だからこそできる、一人ひとりに向き合ったサポートを大切にしています。

新しい環境で頑張っているすべてのエンジニアに、この記事が少しでも役に立てばうれしいです。

聞くのは怖い。でも、聞いてみたら意外と大丈夫だった。そんな経験が、きっとあなたの現場をもっと良い場所に変えてくれるはずです。