---
title: 技術面接 - 完璧に答えなくても大丈夫な話
tags:  #エンジニア #転職 #面接  
author: [興梠敬典](https://docswell.com/user/rocky_manobi)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/4JZLD85XE3.jpg?width=480
description: 2026.05にお話した「技術面接完璧に答えなくても大丈夫な話」の発表資料です。 動画アーカイブはこちら https://lapras.com/events/52
published: July 31, 26
canonical: https://docswell.com/s/rocky_manobi/ZGNJ4L-tech-interview-tips
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/4JZLD85XE3.jpg)

技術面接
完璧に答えなくても大丈夫な話
@LAPRAS公式イベント - 技術面接、完璧に答えなくても大丈夫な話
2026.05.19
LAPRAS株式会社CTO 興梠 敬典


# Page. 2

![Page Image](https://bcdn.docswell.com/page/YE6W1P9PEV.jpg)

LAPRAS株式会社 CTO
興梠 敬典(コウロキ タカノリ)
@rocky_manobi
https://lapras.com/public/rocky_manobi
●
●
●
●
SWE歴15年程度
エンプラ/Web系の受託、事業会社双⽅経験があります
採⽤やキャリアを扱うサービスを運営しています
これまでLAPRASを含む2社でエンジニア採⽤‧選考を担当しました
○ オンボーディング成功率100%‧内定受諾率90%超 @LAPRAS
個⼈の活動として採⽤‧組織作り相談をやっています
この辺りで経験‧⾒聞きした情報を踏まえて、
⾯接する側の視点を絡めたお話をしていきたいと思います。


# Page. 3

![Page Image](https://bcdn.docswell.com/page/GE5M4KNPE4.jpg)

前提と今日のお話
“技術”⾯接 なので、技術的知識はもちろん評価対象であり、重要。
その⼀⽅で...
● 全ての問いや課題に正答できるような知識武装には限界がある
● ⾯接で確認したいことは技術的な知識以外にもある
意気込み
● ポジションに期待される知識や経験を持っているにも関わらず、
その他の要因で取りこぼしてしまったり、
完璧に答えなければと緊張してしまい普段の⼒が発揮できない...
これらを解消するヒント的なものを提供できれば嬉しいです


# Page. 4

![Page Image](https://bcdn.docswell.com/page/9729VW5ZJR.jpg)

今日のお話
●
●
知識以外に何が‧なぜ⾒られているのか
その特性を⽰すためにはどう振る舞うとよいのか
おしながき
1.
2.
3.
4.
5.
6.
技術⾯接では何を⾒られているのか ←⼤きめ
対応⽅針 ← ちょっとだけ⼤きめ
具体的な⾏動‧作法 - 少し ← ⼤きめ
⼤事 : 選考官も⼈間
参考になりそうな書籍
まとめ


# Page. 5

![Page Image](https://bcdn.docswell.com/page/DJY43LKN7M.jpg)

1/6
技術⾯接では何をみられているのか


# Page. 6

![Page Image](https://bcdn.docswell.com/page/V7NYV4RVE8.jpg)

技術面接いろいろ
●
アルゴリズム
●
計算量やデータ構造を考慮し、
効率的な解法を導き出す。
●
ホワイトボードテスト
提⽰された課題を解くプログラムを実装する。
●
設計ディスカッション
●
ペアプログラミング
⾯接官と協⼒して⼀つのコードを書き、
実務に近い共同作業を再現する。
⾮同期課題のディスカッション
事前提出したコードの意図や設計判断の根拠について、
レビュー形式で対話する。
抽象的なお題に対し、拡張性や負荷分散などを
考慮したシステム構成を議論する。
●
⾏動⾯接
過去経験したプロジェクトや出来事の、
具体的なエピソードについての質問に答える。
物理的なボードに図や数式を書きながら、
思考プロセスを⼝頭で実演する。
●
コーディング
●
技術的な知識を問う質問
⽤語や技術の基本概念について、
正しく理解しているかを⼀問⼀答形式で答える。


# Page. 7

![Page Image](https://bcdn.docswell.com/page/YJ9P6QMV73.jpg)

技術面接いろいろ
●
アルゴリズム
●
計算量やデータ構造を考慮し、
提⽰された課題を解くプログラムを実装する。
考案っていうか、知ってるかどうかやんこんな。
効率的な解法を導き出す。
実務でソートアルゴリズム書かないでしょ。⾞輪の再発明？
●
ホワイトボードテスト
実務で⼀番⼤事な「ドキュメントを読み込む時間」が⼀切与えら
れないというのは⽭盾では。いまはAIも使うし
●
設計ディスカッション
●
ペアプログラミング
⾯接官と協⼒して⼀つのコードを書き、
⾯接官が横でガン⾒してるプレッシャー、
実務に近い共同作業を再現する。
実務と違いすぎるやろ
⾮同期課題のディスカッション
事前提出したコードの意図や設計判断の根拠について、
⽇曜の夜に数時間で作ったコードに、完璧を求めないで...
レビュー形式で対話する。
抽象的なお題に対し、拡張性や負荷分散などを
前提が曖昧すぎる話されても答えなんかないやろ
/ 実務の検討は
もっと時間かけるのに、30分で結論出せって⾔われるの無理ゲー
考慮したシステム構成を議論する。
じゃない？
●
⾏動⾯接
過去経験したプロジェクトや出来事の、
そもそも現職と環境違いすぎるし、
具体的なエピソードについての質問に答える。
詳細な背景‧前提まで共有するの無理やん
物理的なボードに図や数式を書きながら、
(このツッコミは課題によるかなぁ)
思考プロセスを⼝頭で実演する。
●
コーディング
●
技術的な知識を問う質問
⽤語や技術の基本概念について、
公式ドキュメント⾒れば3秒で済む話では
正しく理解しているかを⼀問⼀答形式で答える。


# Page. 8

![Page Image](https://bcdn.docswell.com/page/GJ8DZGL4JD.jpg)

面接で確認されるのは技術的知識だけではない
⾯接のお題や問い ≠ 必要な「知識」の確認
というより
⾯接のお題や問い(の⽬的) ⊃ 必要な「知識」の確認


# Page. 9

![Page Image](https://bcdn.docswell.com/page/LJLMDGLVER.jpg)

技術面接のお題を通して確認したいこと
⼀緒に働きたいかどうかを⾒ている
…
…
……？


# Page. 10

![Page Image](https://bcdn.docswell.com/page/47MYPQMN7W.jpg)

技術面接のお題を通して確認したいこと
ポジションに求められる経験や知識を有していること


# Page. 11

![Page Image](https://bcdn.docswell.com/page/P7R918V4E9.jpg)

技術面接のお題を通して確認したいこと
ポジションに求められる経験や知識を有していること
x
課題解決‧成果を出す再現性
思考のプロセス
● ⽬的や前提条件を確認しながら進める姿勢
● 仮説を明⽰し、検証する姿勢
● 曖昧さ‧不確実性がある中で物事を進める⼒
● 優先順位の判断(⽬的‧論点にフォーカス)
以前の活躍が偶然や環境依存ではないことを確認したい


# Page. 12

![Page Image](https://bcdn.docswell.com/page/PJXQY8ZZ7X.jpg)

技術面接のお題を通して確認したいこと
ポジションに求められる経験や知識を有していること
x
協業‧サポートのしやすさ
課題解決‧成果を出す再現性
思考のプロセス
● ⽬的や前提条件を確認しながら進める姿勢
● 仮説を明⽰し、検証する姿勢
● 曖昧さ‧不確実性がある中で物事を進める⼒
● 優先順位の判断(⽬的‧論点にフォーカス)
チームで働くための適正
●
●
●
●
●
問題を隠さない
⾃分の理解‧考えを説明できる
助⾔を受け⼊れ、⽣かすことができる
建設的に対⽴を扱うことができる
必要なときに助けを求めることができる


# Page. 13

![Page Image](https://bcdn.docswell.com/page/3JK93K8VJD.jpg)

技術面接のお題を通して確認したいこと
ポジションに求められる経験や知識を有していること
x
協業‧サポートのしやすさ
課題解決‧成果を出す再現性
思考のプロセス
● ⽬的や前提条件を確認しながら進める姿勢
● 仮説を明⽰し、検証する姿勢
● 曖昧さ‧不確実性がある中で物事を進める⼒
● 優先順位の判断(⽬的‧論点にフォーカス)
チームで働くための適正
●
●
●
●
●
問題を隠さない
⾃分の理解‧考えを説明できる
助⾔を受け⼊れ、⽣かすことができる
建設的に対⽴を扱うことができる
必要なときに助けを求めることができる
選考官視点では現在の知識以外にも確認したいことがある。
だから、全てを完全に回答することは求められていない。
選考を通して、上記の性質を示すことができれば良い。


# Page. 14

![Page Image](https://bcdn.docswell.com/page/LE3WGZMQE5.jpg)

技術面接のお題を通して確認したいこと
ポジションに求められる経験や知識を有していること
x
協業‧サポートのしやすさ
課題解決‧成果を出す再現性
思考のプロセス
● ⽬的や前提条件を確認しながら進める姿勢
● 仮説を明⽰し、検証する姿勢
● 曖昧さ‧不確実性がある中で物事を進める⼒
● 優先順位の判断(⽬的‧論点にフォーカス)
チームで働くための適正
●
●
●
●
●
問題を隠さない
⾃分の理解‧考えを説明できる
助⾔を受け⼊れ、⽣かすことができる
建設的に対⽴を扱うことができる
必要なときに助けを求めることができる
選考官視点では現在の知識以外にも確認したいことがある。
だから、全てを完全に回答することは求められていない。
選考を通して、上記の性質を示すことができれば良い。


# Page. 15

![Page Image](https://bcdn.docswell.com/page/8EDK1R6W7G.jpg)

AIの台頭による評価軸の変化 - 国内
⽣成AIで「エンジニアに求めるスキル」が変わった
43.9% の採⽤担当者が回答
より重要になった
以前ほど重要でなくなった
●
●
●
プログラミングスキル(26%)
資料作成スキル(24.6%)
予算管理スキル(21.6%)
●
●
●
コミュニケーションスキル(48.3%)
ピープルマネジメントスキル(38.5%)
プロンプトスキル(29.8%)
出典
Karat「2025-2026 AI Workforce Transformation Report」
調査対象：米国・インド・中国のエンジニアリングリーダー400名
公開：2025年12月（NextGen Interviews発表に併せて）/ 解説記事は2026年1月
URL：karat.com/engineering-interview-trends-2026/


# Page. 16

![Page Image](https://bcdn.docswell.com/page/V7PKQWYXJ8.jpg)

AIの台頭による評価軸の変化 - 海外
AIによって技術スキルを評価することが難しくなった
71% のエンジニアリングリーダーが回答
⇒AIの出現で技術課題やコーディングテストが機能しなくなった
評価軸の変化
●
●
●
データ構造‧アルゴリズム
きれいで効率的なコード
⾔語の⽂法知識
※あくまで採用する人材に対しての評価軸の変化であって、
左側の要素の重要性が下がったわけではない
●
●
●
判断⼒
適応⼒
問題解決⼒‧AI協働⼒
出典
Karat「2025-2026 AI Workforce Transformation Report」
調査対象：米国・インド・中国のエンジニアリングリーダー400名
公開：2025年12月10日（NextGen Interviews発表に併せて公開）
URL：karat.com/resource/ai-workforce-transformation-report/


# Page. 17

![Page Image](https://bcdn.docswell.com/page/2JVV58G3JQ.jpg)

技術面接のお題を通して確認したいこと
ポジションに求められる経験や知識を有していること
x
協業‧サポートのしやすさ
課題解決‧成果を出す再現性
思考のプロセス
● ⽬的や前提条件を確認しながら進める姿勢
● 仮説を明⽰し、検証する姿勢
● 曖昧さ‧不確実性がある中で物事を進める⼒
● 優先順位の判断(⽬的‧論点にフォーカス)
チームで働くための適正
●
●
●
●
●
問題を隠さない
⾃分の理解‧考えを説明できる
助⾔を受け⼊れ、⽣かすことができる
建設的に対⽴を扱うことができる
必要なときに助けを求めることができる
ケアをしておいて損はないのでは、という主張です！
技術や知識に価値がない、というお話ではなく


# Page. 18

![Page Image](https://bcdn.docswell.com/page/5EGL658YJL.jpg)

2/6
対処⽅針


# Page. 19

![Page Image](https://bcdn.docswell.com/page/4JQY4Z967P.jpg)

「わからない・答えられない」に直面した時は...
⼊社後に知らないことや、想定外の事態が発⽣したときに...
⼀緒に課題解決に取り組んでいける⼈
を、⽰すつもりで取り組むと良い
シニア・ミドル・ジュニア、等々ポジションに関わらず重要な要素。
※ニュアンスとしては「頼りになるか」vs「成長してくれそうか」あたりの差分はありそうですが
●
●
知識があれば回答が早く終わるだけで、
なければ「どこまで知っているか」「どう調べるか」「どう推論するか」を
⾒せればよい
知識不⾜を認めた上で、周囲のサポートをどう活⽤し、
ゴールに辿り着くかという「現場での振る舞い」が⼤事


# Page. 20

![Page Image](https://bcdn.docswell.com/page/K74WQ3XME1.jpg)

選考の捉え方
● 良く⾒せることよりも
「課題を解決すること」にフォーカスしたほうが良さそう
○
○
○
仕事でこれを受けたとしたら、知らなければチームに頼るはず
わからない部分は仮定をおいて話を進めるなどベストを尽くすはず
誤った情報のまま誤った⽅向に進むことを防ごうとするはず
● 選考官は評価者というよりも
チームメイトとして捉えたほうが良さそう
○
○
サポートを得るためには
■ 現状を正直に開⽰したほうが良いはず
■ ⽅向性や考え⽅、取らなかった選択肢なども共有したほうが良いはず
(厳密には評価者でもあるけれど、上司と似たようなものと思えば現場と変わらないはず!)
⾯接官もスペシャリストではないことが多いので、質問とか頼ってもらったほうがありがたいはず
⾯接という空間はただでさえ被評価者意識や独⼒で解決しないといけないのでは圧が強く働くので、
これくらいの気持ちでいてちょうど良い。(もちろん⾃分で何も⾔わず答えず頼ってばかりというのは良くないですが)


# Page. 21

![Page Image](https://bcdn.docswell.com/page/LJ1YP1NYEG.jpg)

3/6
具体的な⾏動‧作法 いくつか


# Page. 22

![Page Image](https://bcdn.docswell.com/page/GJWG284172.jpg)

質問、大事！
⼀般的な技術知識においても、知らない/曖昧なところは質問する
-
-
課題の前提条件や要件、制約事項についての質問は当然必須
- 前提を揃えるため、理解を確認するために必要
- (知らなくて当然なので、聞きやすいはず)
⼀般的な技術知識も、⾃信がなければ素直に開⽰しつつ、聞いた⽅が良い
- 問題を隠さず、サポートを受けて、それを⽣かせるのは良い特性
- 少なくとも「誤っている可能性に気づいていること」を⽰せる
- 間違った理解のまま誤った⽅向に進むより良いはず/実際の仕事なら聞く
- 評価基準的に禁則事項に抵触するならば⾯接官が教えてくれる
(選考基準を候補者が知らないのは当たり前 / 評価基準でないところで戦っても損)
- 「選考基準抵触したらすみません」など前置きしても良いかも


# Page. 23

![Page Image](https://bcdn.docswell.com/page/4EZLD82X73.jpg)

曖昧さ・不確実性をうまく扱うために 仮定 を使う
課題を進めたり、回答を考えているときに、
わからない/曖昧な要素があれば、仮定を共有してすすめる
「このクラスの細部はうろ覚えなので、仮にこういうAPIがある前提で進めます」
「この⼿の外部サービスを利⽤したことがないので、仮にこのような仕様を満たすものがある前
提ですすめます」などなど
- 知識を誤魔化さない / 仮定の上で⽭盾のない解法を導き出す姿勢を⽰せる
- 仕事でも不明な要素に仮定をおいてその場を進める、という⾏動は良くとるはず
(影響度合いによっては先に調査ですが)
<例えば>
ER図を書く課題において「1:Nの正確な書き⽅などの記法」に⾃信がない場合は...
「記法はうろ覚えなので合っているかは分からない」
「今回はこのような記述⽅法で進める」
のように、現状と作業の前提を共有することで、場の不確実性を減らすことができます。
具体的には
- ⾃分視点の「合ってるか / 記法がジャッジされていないか」のような不安の解消
- ⾯接官視点の「知らないのか」「この記述はどういう意図なのか」のような疑問の解消


# Page. 24

![Page Image](https://bcdn.docswell.com/page/Y76W1PVP7V.jpg)

その他にも
考えていることを⾔葉にしながら/⽅針を説明しながら進める
-
よく求められる(そういう書籍や記事も多い)
再現性の確認のために思考のプロセスを知ってもらうために必要
助⾔なども受けやすくなるので、候補者にとっても有⽤
- （選考官から予期せぬ助⾔が⾶んでくる可能性も減らせる)
黙って考えたいときは「少し考えます。黙ります」と⾔ってしまっても良いかも
不安なポイントを共有しながら進める
「このライブラリを使った経験が浅いので、間違っているところあったら訂正お願いします！」
「この辺は雰囲気でしか理解できていないので、違和感あったら⾔ってください！」
-
「この領域について理解できていないことがある...ということがわかっている」は⽰せる
注意 : 謙虚と卑屈はまた違うので、予防線を貼りすぎないように(塩梅難しいですが)


# Page. 25

![Page Image](https://bcdn.docswell.com/page/G75M4KDP74.jpg)

ぷちTips : 面接特有の圧(の一部)対策
「なぜ？」という質問は、誤りの指摘ではない
これを普段よりも強めに意識しておくと良いと思います。
(背景を知っていると助けになるかな...)
そもそも⾯接では質問がOpen Questionになりがち
●
●
仕事 : 「AにしたのはBだからですか？」
⾯接 : 「Aにしたのはなぜですか？」
再現性を確かめたいため
- Closed Questionにすると、考えを確認できない
- 普段ならしない質問もする
→ 選考官側で⾯接時にこの⼒学を説明したほうがよい派ではありますが、今回は⾯接対策視点ですので


# Page. 26

![Page Image](https://bcdn.docswell.com/page/9J29VW8ZER.jpg)

とはいえクイズ的な質問どうしようか
【答えがわからないとき】
わからないところ、わかる範囲を伝えたうえで、
実務ではどうするか or 推論(暗記はしていないが⽭盾はないことを⽰す)
●
●
●
わからないこと / 理解している範囲を開⽰
○ 「名前と⽤途は知っているけれど、内部の詳細までは⾃信がないです」
○ 「〇〇という概念の親戚だという認識はありますが〜」
実務ではどうする / 推論
○ 「もし実務で直⾯したら、まず〇〇で調べていくと思いますが...」
○ 「⽂脈から推論すると、〜という理由で、HOGEHOE~となりそうです」(推論と宣⾔するの⼤事)
その他
○ 「差し⽀えなければヒントもらえますか？」も場合によってはあり
【+Tips : 答えはその場で確認しておこう(私⾒ですが)】
- 回答があっているか、加えて、期待していた回答との差分はあるかを確認する
- 今後の課題‧問題の前提になるかもしれないし、
少なくとも選考官が期待する回答の粒度や⽂脈を知ることができる


# Page. 27

![Page Image](https://bcdn.docswell.com/page/DEY43L6NJM.jpg)

ぷち話題 : それはそうだが...
「技術⾯接、瞬発⼒をみすぎていませんか」
↑それはそう
時間
次第
その場の会話でのやりとりよりも、テキストでのやりとりや、
少しじっくり考える時間があったほうが得意な⼈もいるはず。
スキル‧課題解決の再現性‧協業にも、必ずしもリアルタイムコミュニケーショ
ンが全てではないし、むしろドキュメントをベースにコラボレーションしていく
⽅がスケールしていく、というのも事実。
「だが今は特にそういう環境なのかも（ぐぬぬ」
残念ながらAIの登場によって、しばらくはこの傾向が続きそう
- 対策文脈でも、要件文脈でも


# Page. 28

![Page Image](https://bcdn.docswell.com/page/VJNYV4ZV78.jpg)

【疑問】
omake
時間
次第
ここまで⼀理ある感もあるけれど、
“クイズに正解することが全て”
と、考える企業や⾯接官もいるのでは？


# Page. 29

![Page Image](https://bcdn.docswell.com/page/YE9P6QZVJ3.jpg)

それはそうだが...
そもそもこのお話は「答えられない場合」なので、
答えられない場合にNGになるなら、その時点でNG。
今日のお話が悪い方向に働くことにはならないかなと思います。
時間
次第
最低でも練習にはなるので、
課題解決フォーカスでグイグイいったほうが得だと思います。
もう少し踏み込むと、
さすがにあまりにもクイズ的な要素で選考成否を決めているとしたら、個人的
にはその組織の選考は通過しないほうが良いのではとも思ったりもするので、
あまり気にしなくて良いのではと思います。


# Page. 30

![Page Image](https://bcdn.docswell.com/page/GE8DZG14ED.jpg)

ぷち話題 : 技術面接をが正解のない話になりがちな理由(企業目線)
問題が流出する・対策される・たまたま知っていただけだった ..などを考慮すると、
明確な正解があったり、知識を問うだけの選考はやりにくい
-
-
対策やたまたま得意分野にFitしたなどの理由で通過されてしまうと、
本当に必要な技術や課題解決⼒について確認できなくなってしまう
- 情報収集能⼒や課題解決能⼒と捉えることはできるけど、
少なくとも再現性を選考の場で確認することはできない
⾯接対策そのものが、望ましい⾏動に直結するなら問題が⽣じない(むしろプラス)
- わからないときにどう振る舞うか、どのように問題に⽴ち向かうか、
望ましい振る舞いを⾝につけ、実践する練習であれば⼊社後も役⽴つ特性になる
時間という制約があるので、ある程度曖昧な題材を扱うことになりがち
-
回答が⼀意に定まるような具体性のある課題を扱うには細部に渡るコンテキストの共有が必要
そのような時間や労⼒をさくことはできない(お互いに)
課題に曖昧さ‧不確実性が⼊りやすくなるので、
不定なところを仮置きしたり、わからないまま処理する⼒が求められがち
から、対策しても無駄にはならないと思います！
時間
次第


# Page. 31

![Page Image](https://bcdn.docswell.com/page/LELMDGQV7R.jpg)

4/ 6
⼤事 : 選考官も⼈間


# Page. 32

![Page Image](https://bcdn.docswell.com/page/4JMYPQ1NJW.jpg)

人間だもの - 老害って言われるかもですが
(成否に直結するのかはわからないですが)
選考はお互いに時間を作ってやっていることなので、相互のリスペクトだった
り、お互いに気分よく進められるようにお互いが努⼒できるといいなぁと
-
元気、じゃなくても良いのいではっきり挨拶をする、とかも⼤事かも
うなずく、相槌をうつ などは⾺⿅にできない影響がありそう
- サポート‧協業のしやすさにつながる
- 信頼関係構築までのコミュニケーションがしやすいかどうかに影響
- コミュニケーションは双⽅のコラボレーションだけど、
どちらかがフォローしているってことはある


# Page. 33

![Page Image](https://bcdn.docswell.com/page/PJR918L479.jpg)

omake
おまけ
通話品質について


# Page. 34

![Page Image](https://bcdn.docswell.com/page/PEXQY8WZJX.jpg)

通話品質について
通話品質が悪いと今日お話ししたコミュニケーション要素全ての足枷になる。
通信速度とマイクについて、必ず事前に確認しておきましょう。
●
●
通信速度
○ 発言が被るなどなど、やりとりが成立しなくなる
○ 問題なく感じていても「会話のテンポが悪い」「反応が遅い」
という印象を抱かれてしまうかも
○ 遅延0.2秒程度から違和感を感じ始め、 1秒超あたりで確実に問題になる
○ (この日だけめちゃめちゃ遅い、などであればリスケの打診も選択肢）
マイク
○ 音が割れる、掠れて聞こえる、低音を拾いすぎて聞き取りにくいなど
■ 息を拾いすぎる角度なども問題になる可能性あり
○ 高品質である必要はない
【その他】
ITエンジニアであれば気にして欲しい気持ちもある(個⼈の感想ですが、共感する⼈も多そう)
もちろん⾯接官側も注意


# Page. 35

![Page Image](https://bcdn.docswell.com/page/3EK93KVVED.jpg)



# Page. 36

![Page Image](https://bcdn.docswell.com/page/L73WG3QQ75.jpg)

5/6
対策 - 参考書籍


# Page. 37

![Page Image](https://bcdn.docswell.com/page/87DK149WJG.jpg)

●
●
●
鉄板として有名
コーディング⾯接以外にも当てはまる考え⽅を学べる
例題中⼼で極⼩⽂字 x 750ページ超なれど、
最初の100ページくらいで結構”得られる”
選考側も読んでいるケースが多いかもしれない
●
●
システム設計系の⾯接試験に取り組む際の考え⽅を、
フレームワークとして紹介している(3章)
⾯接対策だけでなく、要件をどうシステム設計に落とし
込んでいくのか... など、普通に仕事として勉強になりま
した


# Page. 38

![Page Image](https://bcdn.docswell.com/page/VJPKQMZXE8.jpg)

●
●
こういう⼈を求める、みたいなところがまとまっているし、結構引⽤されてる感
みんなはGoogleじゃないけど、みんなGoogleのことを⾒ているから
インプットしておいて得だとは思います / HRTなどは特に⼤事そう


# Page. 39

![Page Image](https://bcdn.docswell.com/page/2EVV59W3EQ.jpg)

6/6
まとめ


# Page. 40

![Page Image](https://bcdn.docswell.com/page/57GL6ZDYEL.jpg)

技術面接のお題を通して確認したいこと
ポジションに求められる経験や知識を有していること
x
協業‧サポートのしやすさ
課題解決‧成果を出す再現性
思考のプロセス
● ⽬的や前提条件を確認しながら進める姿勢
● 仮説を明⽰し、検証する姿勢
● 曖昧さ‧不確実性がある中で物事を進める⼒
● 優先順位の判断(⽬的‧論点にフォーカス)
チームで働くための適正
●
●
●
●
●
問題を隠さない
⾃分の理解‧考えを説明できる
助⾔を受け⼊れ、⽣かすことができる
建設的に対⽴を扱うことができる
必要なときに助けを求めることができる
選考官視点では現在の知識以外にも確認したいことがある。
だから、全てを完全に回答することは求められていない。
選考を通して、上記の性質を示すことができれば良い。


# Page. 41

![Page Image](https://bcdn.docswell.com/page/4EQY4L16JP.jpg)

おわりに - 実践について
今日のお話を実践（？）するのであれば、面接対策としてではなく、
“普段の仕事におけるより良いコラボレーションの進め方の訓練”として
考えると良いのではないかなと思っています。
たとえ選考に落ちてもレベルは上がるし、
転職にするしないに関わらず活きるスキルとして身に付くのかなと。
良いと言われているプラクティスをインプットする・周囲のできる人の仕事の進め方や振る
舞いなどをよく観察する、などなどして、取り入れてみると良いと思います。エンジニア以外
の人とかも参考になると思います。普段の作業中に練習もできます(特にリモート環境なら
ブツブツ言っていても周囲に迷惑がかかりません)。
自分もこの辺り改めて意識しつつ
普段のお仕事を進めていこうと思いました。
何か新しい情報がご提供できていれば嬉しいです！