はじめに
学習のため、技術質問に関する記事を探していたところ、素晴らしい記事を見つけました。勝手ながら引用させていただきます。
記事でも言及されていますが、技術質問に関する記事が意外と少ないため、とても助かりました。執筆者の@gon0821(ごん)様に、心から感謝いたします。
【面接対策】技術質問に対して簡潔な回答【２０選】
https://qiita.com/gon0821/items/44856f384f321f96d877
記事内20の技術質問を拝見し、私は自身が質問される場面を想像しました。想像の中の私は、脂汗を浮かべ、苦笑いで口をパクパクしていました。原因は勉強不足・理解不足です。
この記事では自身の知識の整理を兼ね、引用の記事などを参考にさせていただきながら、自分の回答を記載いたします。改善点があればどなたでもお気軽にご指摘ください。私も随時更新します。
この記事が、同じような境遇の"技術質問ジプシー"の一助になれば幸いです。
プログラミング基礎
Q1. オブジェクト指向とは何ですか？
共通化して再利用しようという考え方。
データと処理（メソッド）のまとまり「オブジェクト」を、共通の設計図「クラス」から生成し、それらを組み合わせてシステムを構築することで、コードの共通化と再利用性を促進する。
3つの主要な概念：
- データと処理をまとめる「カプセル化」
- 既存の機能を引き継ぎ再利用する「継承」
- 同じ操作で異なる動作を可能にする「ポリモーフィズム」
Q2. MVCモデルとは何ですか？
アプリケーションの役割を3つに分けて整理する設計パターン。
- Model：データベースとのやり取りやビジネスロジック
- View：ユーザーが見る画面（HTML等）
- Controller：ユーザーの操作を受けて、ModelとViewを制御
各々が独立しているため、一箇所を修正しても他に影響が出にくく、複数人での開発がしやすい。
Q3. CRUD処理とは何ですか？
データベースの基本的な4つの操作。
- Create（生成）：新しいデータの作成・保存
- Read（読み込み）：データの取得・表示
- Update（更新）：既存データの修正
- Delete（削除）：データの削除
例） ユーザー管理では、新規登録がCreate、プロフィール表示がRead、情報変更がUpdate、アカウント削除がDelete。多くのWebアプリケーションは、CRUDで構成されている。
Q4. 例外処理とは何ですか？
プログラム実行中に発生する予期せぬ問題（例外）を捕捉し、中断せずに適切な処理を行うための仕組み。
ファイルが見つからない、ネットワークエラー、不正な入力値などが発生した場合に、エラーメッセージの表示や代替処理の実行を行う。
例外処理があることで、プログラムが安定して動作し続けることができ、デバッグや問題特定も容易になる。ユーザーに優しいアプリケーションを作るために必要不可欠。
Q5. バリデーションとは何ですか？
入力されたデータが適切かどうかをチェックする処理。データの品質保持とセキュリティ向上の両面で重要な処理。
具体例： メールアドレスの形式確認、パスワード強度のチェック、必須項目の入力確認。
重要ポイント： クライアントサイド（ブラウザ側）とサーバーサイド両方でのバリデーションが必要。クライアントサイドのみでは、悪意のあるユーザーが簡単に回避できてしまう。
Q6. 非同期処理とは何ですか？
時間のかかる処理を待たずに、他の処理を並行して実行できる仕組み。
例えば、サーバーからデータを取得している間も、ユーザーは他の操作を続けることができる。同期処理だと、一つの処理が終わるまで全体が止まる。
JavaScriptのPromiseやasync/awaitを使って実装することが多く、現代のWebアプリケーションには欠かせない技術。
Web技術
Q7. HTTPとHTTPSの違いは何ですか？
HTTPSはHTTPをセキュリティ強化したもの。どちらも「通信プロトコル」の一種。
他の通信プロトコル：TCP/IP、FTP、SMTP
HTTPは「Webブラウザ（クライアント）がウェブサーバーにWebサイトなどの情報を要求（リクエスト）→サーバーがその要求に応じて情報（レスポンス）を返す」やり取りを規定している。HTTPSは通信を暗号化し、より安全にやり取りできる。
Q8. GETとPOSTの違いは何ですか？
GETはURLの後ろに入力データが付く。POSTはそれがない。どちらもHTTPリクエストメソッドの一種。
- GETはサイト閲覧・検索など、サーバーからの「データ取得」
- POSTは会員登録やSNS投稿など、サーバーへの「データ送信」
Q9. レスポンシブデザインとは何ですか？
PC、スマホ、タブレットなどの画面サイズに合わせ、Webサイトのデザインやレイアウトが自動的に最適化されるデザイン。
CSS3の機能「メディアクエリ」で、「もし画面幅が○○px以下なら、△△のスタイル適用」のような、条件付きCSS適用が可能になった。
Q10. クッキーとセッション情報の違いは何ですか？
クッキーはユーザーのブラウザに保存される小さなデータ。ログイン状態やカート情報の保持に利用される。
セッション情報はサーバーに一時保存されるデータ。ブラウザを閉じると消える場合も多く、銀行サイトの取引など一時的・重要な情報管理に使われる。
※ちなみにキャッシュは表示を早くするためブラウザに一時保存するデータ。
Q11. APIとは何ですか？
アプリケーションが他のアプリケーションの機能やデータを利用するための「窓口」や「ルール」
多くの場合、APIといえばWeb APIを指す。Web APIはHTTP/HTTPS通信により、機能やデータを利用する。
具体例：
- Amazon API：WebサイトにAmazonの商品を表示
- Google Maps API：Webサイトに地図を表示
- 天気予報API：Webサイトで最新の天気予報や気象データを提供
Q12. SPAとは何ですか？
XのタイムラインやGoogleマップで地図を動かしたときのように、ページ全体が再読み込みせず、コンテンツを部分的に更新する技術。
スムーズな画面遷移と高速なレスポンスにより、サイトの使用感がネイティブアプリに近づく。
SPAは、単一のHTMLページでコンテンツを切り替える。URLの遷移をせず、JavaScriptのAPI（XMLHttpRequestやfetchなど）がサーバーからデータを取得して、ページの一部を動的に更新する。
SPAに対しMPAは、ページ遷移のたびに新しいHTMLを読み込む従来の手法。一般的にはブログやメディア記事など静的サイト向き。各ページが明確なURLを持ち、独立したHTMLファイルで構成される。情報整理がしやすく、SEOに有利。
開発手法/ワークフロー
Q13. アジャイル開発とは何ですか？
「小さく作って出す」開発手法。機能ごとに短期間（1～4週間程度）で開発・リリースを繰り返す。
ユーザーのフィードバックを受けながら柔軟に機能追加・修正しやすい。多くのWeb系企業がアジャイル開発を採用している。
アジャイルに対しウォーターフォール開発は、上流から下流工程へ順番に進める開発方法。進捗管理がしやすく、変更が少ない大規模プロジェクト・SIer向き。
Q14. なぜテストコードを書く必要がありますか？
テストコードを書く理由は品質保証：バグを早期に発見・修正し、ソフトウェアの品質と信頼性を高めるため。
- 安全な変更：既存の機能が壊れていないことを自動で確認できるため、新機能の追加やリファクタリングを安心して行える
- 仕様の明確化：テストコード自体が「この機能はどう動くべきか」という仕様書となり、チーム内での認識齟齬を防ぐ
Q15. ビルドとは何ですか？
成果物を作る開発工程の一つ。
ソースコードのコンパイル、リンク、パッケージングなどを含み、最終的にコンピュータが実行できる形である実行ファイルやアプリケーション、配布可能なパッケージを作成する。
開発工程：
-
ソースコード作成
└ 人が書いたコード（.java, .ts, .php など） -
ソースコードの解析・チェック
└ 静的解析・Lint・型チェックなどで品質確認 -
コンパイル
└ ソースコード → オブジェクトコード（中間成果物）
保存したものがオブジェクトファイル（.c → .o、.java → .class） -
リンク（リンカ）
└ 複数のオブジェクトファイルやライブラリを結合
→ 実行可能ファイル（.exe, .out, .jar など）を生成 -
パッケージ化（パッケージング）
└ 実行ファイル＋設定ファイル＋リソースをまとめる
→ .zip, .tar.gz, .apk, .deb など配布形式に -
ビルド
└ 上記すべてを含む「成果物を作る一連の工程」
※ Web系では JS/CSS/画像の圧縮・結合も含む -
テスト環境へデプロイ
└ 本番前に動作確認する環境へアップロード -
本番環境へデプロイ
└ 実際のユーザーが使う環境へ公開
Q16. デプロイとは何ですか？
ビルドしたものをテスト・本番環境に配置すること。
ざっくり用語理解：
- ビルド：動く形にする
- デプロイ：サーバーに置く
- テスト：壊れてないか確認
- 本番：ユーザーに届ける
デプロイ4ステップ
- 準備：ビルド済み成果物・設定・環境を整える
- 配置：サーバーへコードやファイルを転送する
- 起動：アプリやサービスを起動／再起動する
- 確認：動作確認・ログ確認で正常性をチェックする
Q17. CI/CDとは何ですか？
ビルド・テスト・デプロイ自動化の開発手法。
- CI：コードをpushしたら自動で「統合・ビルド・テスト」
- CD：テストが通ったら自動で「デプロイ・リリース」
CI/CDの具体的な流れ
Git Push
↓
【CI - 継続的インテグレーション】
├─ コードの取得：リポジトリから最新の状態をダウンロード
├─ マージ：チームの変更を1つにまとめ、最新のコードベースにする
├─ ビルド：成果物の生成
├─ 自動テスト（ユニット・結合）：部品単位の動作確認
├─ 静的解析・品質チェック：コードの書き方や保守性を検査
└─ セキュリティスキャン：脆弱性や危険な依存を検出
↓（全部OKなら）
【CD - 継続的デリバリー／デプロイ】
├─ ステージング環境デプロイ：本番に近い検証環境
├─ 統合テスト・E2Eテスト：機能連携やユーザー操作の検証
├─ 承認待ち（手動or自動）：本番公開の最終判断
└─ 本番環境デプロイ：ユーザーに正式リリース
システム/セキュリティ
Q18. Linuxとは何ですか？
開発現場のサーバーやコンテナ環境で広く使われるOS。
Linuxとは元々カーネル（OSの中核）の名前。実務ではUbuntuやCentOSのようなディストリビューション（カーネル＋便利ツール）として扱う。現場で「Linux」といえば、多くはこのディストリビューションを指す。
Linuxの基本操作や環境構築、CLI（コマンドライン）操作やスクリプトでの自動化・デプロイ管理はエンジニアの必須スキルといえる。
Linux操作ができること
- サーバー障害の調査・復旧（ログ確認、プロセス管理、権限設定など）
- デプロイやCI/CDパイプラインの構築・保守
- 他メンバーの作業効率化（スクリプト化、環境整備、再現性のある運用）
Q19. SQLインジェクションとは何ですか？
Webセキュリティの代表的3つの脆弱性の1つ。
3つの脆弱性
1. SQLインジェクション（SQLi）
- 攻撃対象：データベース
- 概要：入力フォームに悪意あるSQL文を混入させ、アプリを経由してデータベースを不正操作する
- リスク：顧客情報の流出、データ改ざん、サーバー乗っ取り、システムの完全停止
-
対策：プリペアドステートメント
→ SQL文と入力値を分離して処理する仕組み。入力値はあくまで「データ」として扱われ、SQL文として解釈されないため、不正な命令を実行できなくなる
2. クロスサイトスクリプティング（XSS）
- 攻撃対象：サイト訪問者のブラウザ
- 概要：掲示板やコメント欄に悪意あるJavaScriptを埋め込み、閲覧したユーザーのブラウザで実行させる
- リスク：個人情報の盗難、セッションの乗っ取り、フィッシングページへの誘導
-
対策：出力エスケープ処理
→ < や > といった特殊文字を < や > に変換することで、ブラウザがスクリプトを「単なるテキスト」として扱い、実行されないようにする
3. クロスサイトリクエストフォージェリ（CSRF）
- 攻撃対象：ログイン中ユーザーの権限
- 概要：ユーザーを騙して悪意あるリンクやフォームを踏ませ、本来意図していないリクエストを本人の権限で実行させる
- リスク：勝手な送金、パスワード変更、掲示板への投稿、アカウント削除
-
対策：CSRFトークン
→ ユーザーのブラウザとサーバーの両方に一意なトークンを発行し、送信時に照合する仕組み。トークンが一致しない場合はリクエストを拒否することで、不正な操作を防ぐ
データベース
Q20. DB設計の正規化とは何ですか？
データベースの整理整頓術。データの変更や検索を楽にする仕組み。
ぐちゃぐちゃなExcelを、見やすく・効率よく使えるように分けるイメージ。
例： 社員テーブルに「部署名」を直接書くと、部署名が変わるたびに全社員を直さなければいけない。部署テーブルを作って「部署ID」でつなげば、1箇所直すだけで済む。
正規化は第5まであるが、実務では特に第3正規形が頻出。
- 第1正規形・1NF：1セル1値
- 第2正規形・2NF：複合キーの一部にしか依存していない情報は切り出す※
- 第3正規形・3NF：非キー同士で依存している情報は切り出す
数字が上がるとルール・テーブルが増える＆下の番号も含む
※RDBは1NFの形式／実務では単一キーが多いため2NFの意識が薄い
主キー = 行を一意にする列（または列の組み合わせ）
だから1列の場合もあれば、2列以上の場合もある
- 単一キー：社員ID、商品ID みたいに「これ1つで一意」
- 複合キー：注文ID＋商品ID のように「組み合わせて一意」
正規化によりデータの一貫性が向上し更新時の異常を防げるが、パフォーマンスとのバランスを考慮し、あえて非正規化を採用する場合もある。
おわりに
20の回答、「小一時間で終わるっしょ」と始めたら、一週間くらいかかりました。そして自分の技術への理解の甘さを、まざまざと思い知りました。知れてよかったです。
元記事の執筆者@gon0821(ごん)様に、改めて感謝いたします。大変よい勉強になりました。
この記事が、同じような境遇の方々の参考になれば幸いです。改善点があればご指摘いただけますと幸いです。継続的に学習し、より良い内容に更新していきます。