あ
あかね
面談であった15問の質問と回答
2026年08月20日
Tips
見出しはありません
要約を生成中...
先日、PRレビュー後に面談をしました。
PRの修正自体はほぼ終わっていて、「実装は直せたけれど、考え方について聞いておきたい」というところから始まった面談でした。
そこから出てきた質問がとても良かったので、面談で話した内容をいくつかピックアップして一問一答形式でまとめます。
サーバー側だけで取得・判断できるものは、基本的にサーバー側で扱います。 クライアントから送られてくる値は、ユーザーが書き換えられることを前提に考える必要があるからです。
「フロントから送らないと取得できない情報なのか？」を一度考えると、責務を判断しやすくなります。
「このコンポーネントは何をするもの？」と聞かれたとき、一言で答えられるくらいが一つの目安です。「メッセージを表示する」「メッセージを送信する」のように、機能やデータのまとまりで考えてみます。
ただし、最初から完璧に分割する必要はありません。
まず動かして、同じUIが複数回登場するなど、必要になったらリファクタリングで大丈夫です。
AIに相談すること自体は問題ありません。 ただ、「完成コードを出してもらって理解する」より、「どういう処理が必要か」を相談して、自分でコードに落とす方が今はおすすめです。
分からないロジックを知ることと、実装そのものを丸ごと任せることは分けて考えます。
AIに説明してもらって「分かった」と感じるだけではなく、自分が説明する側になってみます。 たとえばAIに「このPRのレビュアとして、なぜこの実装にしたのか質問して」と頼む方法があります。 質問に自分の言葉で答えられなければ、そこが理解の浅い部分です。
自分の言葉でアウトプットしないと理解が浅いことにも気付きにくいです。
一つの正解を聞くのではなく、「選択肢を3つ出して」と聞いてみるのがおすすめです。 その中から自分で選び、「なぜこれを選ぶのか」まで考えます。 AIに選択まで任せず、最終的な判断を自分に残しておくことが大切です。
まず「今までの書き方ではなぜダメなのか？」を考えてみます。
高度な書き方だから良いとは限らず、AIはその場だけを見ると正しいけれど、プロジェクトには不要な実装も提案します。
既存コードやこれまで学んだ方法と比較して、変更する理由を説明できる場合に採用するのがよいと思います。
まず「何を期待していたのに、実際には何が起きているのか」を把握するところまで自分でも追ってみます。
関数の定義へ移動し、値がどこから来て、どこでエラーになるのかを順番に読むのも大切です。 原因を理解しないまま修正を繰り返すと、AIとのやり取り自体が複雑になってしまうことがあります。
サーバー側が「誰からのリクエストなのか」を確認するためです。
今回のコードでは、Authorizationヘッダーのtokenからユーザーを取得する処理があったため、tokenがなければ認証できずエラーになっていました。 逆に、認証が必要なAPIなのにtokenなしで操作できるなら、認証処理の漏れを疑う必要があります。
相談はして大丈夫です。
むしろ、知らない設計を最初から全部自力で生み出す必要はありません。
「どういう流れで作れる？」「どんな選択肢がある？」と聞き、出てきた案を自分で検討します。
大切なのは、AIの設計をそのまま採用するのではなく、「なぜこの構成なのか」を少しずつ判断できるようになることです。
外部APIやライブラリなどを選ぶときは、公式ドキュメントなどの一次情報まで確認します。 AIは古い情報や誤った情報を、それらしく回答することがあります。 候補を複数出してもらい、公式情報へのリンクも提示してもらったうえで、自分でも裏取りする習慣をつけるのがおすすめです。
そんなことはありません。 公式ドキュメントやライブラリのサンプルコードを参考にして、自分の用途に合わせて変更するのも普通の開発方法ですし、生成AIが出てくる前は私もそうして実装していました。
重要なのはコピペしないことではなく、「どこを変える必要があって、なぜそう変えたのか」を理解することです。
「設計」「バグ」「セキュリティ」など、何を確認したいのかを指定すると使いやすくなります。
特に、クライアントで扱うべきでない処理がないか、認証済みユーザーが他人のデータを操作できないか、といった観点は重要です。
ただし、学習段階ではまだ扱っていない高度な改善まで取り入れると今は混乱すると思うので、AIレビューは無理にしなくて大丈夫です。
まずは正しく動くものを作ることを優先して大丈夫です。 コンポーネント分割やリファクタリング、UIの作り込みは後からでもできます。 「動かす」と「きれいにする」を分けることで、完璧を求めすぎて開発が止まるのも防げます。
できれば早めに一度デプロイしておくのがおすすめです。
ローカルでは動いていても、環境変数や公開URL、ビルドなどが原因でデプロイ時に初めて問題が分かることがあります。
GitHubとVercelなどを連携しておけば、PR単位でデプロイできる状態を作ることもできます。
通常、本番用のメインURLは再デプロイしても変わりません。 一方、PRやブランチごとに作られるプレビューURLは、それぞれ別のURLになります。 本番環境とプレビュー環境を分けて考えると理解しやすいです。
今回の面談で何度も出てきたのは、なぜそうするのかという話でした。
AIがコードを書いてくれるようになったからこそ、実装方法を知るだけではなく、
なぜフロントではなくサーバーなのか。 なぜこの単位でコンポーネントを分けるのか。 なぜこの実装方法を選んだのか。
自分の言葉で説明できることが、以前より重要になっているように感じます。
「自分の言葉で説明できるように」というのも「ここはこういう動きをしています」では足りません。
AIから答えをもらうことではなく、AIも使いながら自分で選び、理由を考え、説明できるところまで持っていく。
そんな使い方が、学習中には特に大切なのではないかと思います。
要約
コメント
まだコメントはありません。
