よくある2つの場面
「うまく説明できない」には大きく2つの形があります。どちらで詰まっているかによって、対処法が変わります。
1つ目は、担当しているシステムの構成のように、全体像は見えているのに、どこから話せばいいか分からない場面です。2つ目は、技術的な仕組みを問われて、一部は分かるけれど全部は分からない場面です。
全体は見えているのに、話す順番が決まらない
「システム構成を教えてください」
頭の中には構成図があるのに、どこから話せばいいか分からない。部品の名前を、思いついた順に並べてしまう
一部は分かるのに、全部は分からない
「インデックスを張ると、なぜ速くなるのですか」
実務で使ったことはあるのに、仕組みまでは自信がない。全部答えられないなら黙った方がいいと思ってしまう
どちらの場面でも、うまく話せないと、面接官からは「経験がない人」と見分けがつきにくくなります。実際には経験があるのに、伝え方ひとつで評価を落としてしまうのはもったいないことです。
足りないのは知識ではなく
「話す順番」と「答えの区切り方」
分かっているのに説明できない原因
原因が分かれば、対処法は気合いではなく手順になります。多くの場合、次の4つが重なっています。
① 頭の中の知識は「図」、話す言葉は「一列」
構成図は、全体が同時に見えています。ところが言葉は、一度に一つずつしか出せません。説明するには立体的に見えている図を、一本の線に並べ直す作業が必要で、「どこから始めて、どの順に進むか」が決まっていないと入口で詰まります。
頭の中（図）
話す言葉（一列）
- 1画面
- 2API
- 3DB
- 4キュー・ワーカー
② 普段は「言わなくても通じる」環境にいる
同じチームの中では、サービス名や略語、構成の前提を全員が知っています。「あのバッチ」「いつものキュー」で通じる会話に慣れていると、前提を知らない相手に、最初から順に話す機会がほとんどありません。面接官は社外の人なので、普段なら省いている部分から話す必要があります。
③ 「使える」と「説明できる」は別のスキル
毎日触っている仕組みでも、「なぜそうなっているのか」を言葉にしたことがなければ、説明はできません。手が覚えている知識と、人に渡せる知識は別物です。これは経験が浅いという意味ではなく、説明する練習をしてこなかったというだけのことです。
④ 「全部分かっていないと答えてはいけない」という思い込み
一部しか分からない質問で黙ってしまうのは、多くの場合この思い込みが原因です。間違えるくらいなら「分かりません」と言った方が安全だと感じ、分かっている部分まで捨ててしまいます。そこに面接の緊張が加わると、答えを考えながら「どう見られているか」も気にすることになり、頭の余裕がさらに減ります。
システム構成を聞かれたときの話し方
図を一列に並べ直すときの「順番」を、先に決めておきます。おすすめは、ユーザーのリクエストが流れる順に話すことです。
構成図には決まった読み順がありません。だから毎回その場で順番を考えることになり、詰まります。そこで、「ユーザーの操作が、どこを通ってデータベースまで届くか」という流れに沿って話すと決めてしまいます。流れには始まりと終わりがあるので、話が自然に一列になります。
- 1
全体を一言で言う
「ざっくり言うと、画面・API・DBの3層構成で、AWS上で動いています」
最初に形と規模を言うと、聞き手の頭に枠ができる
- 2
リクエストの流れをたどる
「ユーザーが画面を操作すると、APIを通ってDBに保存されます」
入口から出口へ。流れには始まりと終わりがあるので、自然に一列になる
- 3
流れの外にある仕組みを足す
「重い処理はキューにためて、別のワーカーで処理しています」
非同期処理・バッチ・監視などは、本流を話し終えてから足す
- 4
自分の担当で締める
「私はこのうち、APIと非同期処理の部分を担当していました」
面接官がいちばん聞きたいのはここ。担当と判断したことを添える
話し方のNG / GOOD
えっと、AWSで、ECSとRDSを使っていて……あとLambdaもあって、SQSも使っています。フロントはReactで、CloudFrontもあって……
ざっくり言うと、Reactの画面、RailsのAPI、MySQLのデータベースの3層構成で、AWS上で動いています。ユーザーが画面を操作するとAPIが呼ばれ、リクエストはロードバランサーを通ってECS上のRailsに届きます。データはRDSのMySQLに保存しています。メール送信のような重い処理は、SQSにためて別のワーカーで処理しています。私はこのうちAPIと非同期処理の部分を担当していて、表示が遅かった画面を改善するために、重い処理をワーカーへ切り出すことを提案しました。
NGの方も、使っている技術は同じです。違うのは順番だけで、部品の名前を並べるのではなく、流れの中に部品を置いていくと、聞いている側の頭にも同じ図が描けます。
図を描いてよいか聞いてみる
口頭だけでは伝えにくいと感じたら、「図にした方が早いので、描きながら説明してもよいですか」と聞いてみてください。対面ならホワイトボードや手元の紙、オンラインなら画面共有したホワイトボードツールや、紙に描いてカメラに映す方法があります。頭の中の図をそのまま外に出せるので、並べ直す負担がほとんどなくなります。伝えようとする姿勢そのものも、好意的に受け取られやすい方法です。
なお、現職や前職のシステムを話すときは守秘義務に気を付けます。社名が特定できる固有名や社内システムの名前、公開されていない数字は伏せ、「ECサイトの決済まわり」「数十万ユーザー規模」のように一般的な言葉と幅のある数字に置き換えれば、構成の説明には十分です。
一部だけ分かる質問への答え方
「分かる」「たぶんこうだと思う」「分からない」を分けて、それぞれに区切りの言葉を付けて話します。分かっている部分まで捨てる必要はありません。
面接官が技術の質問で見ているのは、知識の量だけではありません。自分がどこまで分かっていて、どこから分からないのかを正確に言えるかも見ています。実務でも、分からないことを分からないと言える人の方が、安心して仕事を任せられるからです。
| 区切り | 使う言葉 | ポイント |
|---|---|---|
| 確実に分かること | 「実務で◯◯したので、ここは分かります」 | 経験や根拠と一緒に言う |
| 推測になること | 「ここからは推測ですが、◯◯だと理解しています」 | 推測だと先に断ってから話す |
| 分からないこと | 「◯◯については、正確には分かりません」 | 分からない範囲をはっきり区切る |
| 分からないことへの補足 | 「必要になったら、まず◯◯を確認します」 | 調べ方や、近い経験を添える |
例：「インデックスを張ると、なぜ検索が速くなるのですか」
すみません、そこはあまり詳しくないです。
実務では、遅いクエリの実行計画を確認してインデックスを追加し、検索を速くしたことがあります。仕組みとしては、本の索引のように、全件を順番に見なくても目的の行にたどり着ける構造を先に作っておくもの、と理解しています。ただ、内部のデータ構造、たとえばB-treeがどう分岐していくかといった細かい動きまでは、正確に説明できる自信がありません。
同じ「完全には分からない」状態でも、GOODの方は実務の経験・自分の理解・分からない範囲がそれぞれ伝わっています。面接官はここから「では、インデックスを張りすぎるとどうなりますか」のように、あなたが答えられる方向へ質問を続けやすくなります。
反対に避けたいのは、分からない部分を知っているふりをして話し続けることです。深掘りの質問で必ず崩れますし、そうなると本当に分かっていた部分まで疑われてしまいます。
質問の粒度を確かめてから答える
何をどこまで答えればよいか迷ったら、先に聞き返して構いません。「仕組みの話と、実務での使い方の話、どちらに寄せてお話しすればよいでしょうか」と確認すれば、自分が答えやすい方に話を寄せられることもあります。面接官が知りたいのが実務での使い方なら、仕組みの細部で悩む必要はそもそもありません。
途中で詰まったときの立て直し方
沈黙そのものより、固まったまま何も言わないことの方が不安に見えます。考えていることを一言で伝えれば、数秒の間は問題になりません。
考える時間をもらう
「少し整理させてください」と言ってから5秒ほど考える。黙って固まるより、ずっと落ち着いて見える
質問を言い換えて確かめる
「◯◯についてのご質問、という理解で合っていますか」。考える時間にもなり、ずれた答えも防げる
最初に全体を一言で言う
「ざっくり言うと」から入る。細部は、全体を言ったあとで足していけばよい
順番を立て直す
話が散らかったら「すみません、順番を整理して話し直します」と言ってよい。言い直しは減点になりにくい
途中で相手に渡す
「ここまでで、詳しくお話しした方がよいところはありますか」。一人で全部を説明しきる必要はない
分からないところで止める
「ここから先は自信がありません」と区切る。無理に話し続けるより、ずっと印象が良い
面接はプレゼンではなく会話です。一度で完璧に説明しきろうとせず、相手の反応を見ながら足していくくらいの気持ちで臨むと、緊張もやわらぎます。
普段からできる言語化の練習
説明は、知識とは別に練習で伸びるスキルです。面接の前に、よく聞かれる質問だけでも一度声に出しておきます。
担当システムの図を1枚描く
関わったシステムの構成を紙に描き、リクエストの流れの順に番号を振る。その番号がそのまま話す順番になる
30秒版と2分版で話す
全体だけの30秒版と、担当部分まで入れた2分版の2通りを用意する。聞かれた深さに合わせて使い分けられる
録音して聞き返す
スマートフォンで録音し、「えっと」が続く場所を探す。そこが、順番が決まっていない場所
「なぜ」を書き出す
使っている技術ごとに、選んだ理由・ほかの候補・困ったことを1行ずつ書く。深掘りの質問への備えになる
人に説明する機会を作る
新しく入った人への説明、社内の勉強会、技術ブログ。文章に書くことも、言葉を一列に並べる練習になる
AIに面接官役を頼む
自分の説明を書いて、深掘りの質問をしてもらう。社名や社内の固有名は伏せてから使う
録画や録音を使った練習の手順は面接練習の完全ガイドで、技術の深掘りでよく聞かれる質問は面接の定番質問集で紹介しています。
そして、いちばん効果が大きいのは職務経歴書に書くことです。プロジェクトごとに「どんな構成で」「自分はどこを担当し」「何を判断したか」を書いておくと、書類そのものが面接で話す台本になります。面接官も書類を見ながら質問するので、書いた順に話せば、相手の手元の情報とも話がずれません。書き方は職務経歴書の書き方ガイドで解説しています。
よくある質問
Q.考える時間をもらうと、印象が悪くなりませんか？
数秒から10秒ほどであれば、ほとんど問題になりません。印象を下げやすいのは、何も言わずに固まってしまうことの方です。「少し整理させてください」と一言添えてから考えれば、落ち着いて答えを組み立てようとしている姿勢として受け取られます。
Q.「分かりません」と言ったら、その時点で不合格になりますか？
1つの質問だけで合否が決まることはほとんどありません。むしろ、知っているふりをして深掘りの質問で崩れる方が、それまでの回答まで疑われて評価を下げます。分からないと伝えたうえで、近い経験や、自分ならどう調べるかを添えると、未知の問題への向き合い方として評価されます。
Q.オンライン面接で、図を描きながら説明したいときはどうすればいいですか？
画面共有をしてよいか確認し、あらかじめ開いておいたホワイトボードツールや作図ツールに描きながら話すのが一般的です。面接で使うツールによっては画面共有ができないこともあるので、手元に紙とペンを用意しておき、描いた図をカメラに映す方法も準備しておくと安心です。
Q.前職や現職のシステム構成は、どこまで話してよいのでしょうか？
使っている技術の種類や構成のパターン、自分の役割は、多くの場合話して問題ありません。社名が特定できる固有名、社内システムの名前、公開されていない売上やアクセス数などは伏せてください。「数十万ユーザー規模」のように幅を持たせた言い方にすれば、規模感は十分に伝わります。迷ったときは話さない方を選ぶのが安全です。
Q.口頭での説明が苦手なのは、エンジニアとして致命的ですか？
致命的ではありません。説明は知識とは別のスキルで、話す順番の型を持ち、何度か声に出して練習するだけでも大きく変わります。知識がある人ほど、順番さえ決まれば伸びやすいのが特徴です。まずは担当しているシステムの構成を、30秒で話せるようにするところから始めてみてください。
