何を学んだかを説明する
面接では、使った技術名だけでなく、学びの中身を説明する必要があります。
「何を作ったか」より、「作る過程で何を理解し、次にどう活かすか」を話せることが重要です。
回答では、以前できなかったこと、制作中に確認した課題、自分が理解して改善したこと、根拠、次に試すことを順につなぎます。強みを伝える自己PRと成果物や、失敗に絞る技術的な失敗談とは質問の目的を分けます。
説明の型

最初は〇〇が分かりませんでした。
△△を作る中で、□□の仕組みを理解しました。
特に◇◇で詰まり、原因を調べて改善しました。
次は☆☆に挑戦したいです。
例
最初はCSVの読み込みが分かりませんでした。
点数集計ツールを作る中で、DictReaderで列名から値を取り出す方法を学びました。
KeyErrorに詰まりましたが、見出し名の違いが原因だと分かりました。
避けたい説明
- とにかく頑張りました
- AIに作ってもらいました
- 何となく使いました
これだけでは、自分の理解が伝わりません。
抽象的な回答を事実へ変える
弱い例は「エラーが大変でしたが、諦めず頑張りました」です。何を確認し、どう変わったか分かりません。
課題: 保存後に一覧へ反映されなかった
行動: Networkでレスポンスを確認し、再取得がないと特定
改善: 保存成功後に一覧を更新
学び: 通信成功と画面更新は別に確認する
証拠: 修正前後のcommitとREADME
この形なら、本人が観察して改善した事実を説明できます。利用者数や効果を推測で足さず、測っていないことは「未計測」とします。
丸暗記ではなく30秒版と2分版を用意し、質問されたら自分の判断理由や検証方法を具体化します。 答えられない点は推測せず、確認方法を伝えます。
回答できたかの確認
- 技術名ごとに「何ができるようになったか」を言える
- 自分が確認したコード、コミット、READMEなどを示せる
- teamやAIの作業と自分の判断範囲を分けている
- 未計測の効果や理解していない部分を断定していない
技術名の羅列、丸暗記、実際より大きな成果は避けます。30秒版だけを暗記せず、「なぜそう判断したか」という追加質問へ自分の言葉で答えられることを成功条件にします。
確認問題
「チーム開発を学びました」には、自分の役割、意見が分かれた場面、決め方、残った成果物を加えると具体的になります。
まとめ
面接では、学習前、制作中の課題、解決方法、次の改善をつなげて話します。技術名より、理解と改善の過程が大切です。
成果物は未経験者が成果物で評価されるポイント、経験の構成はガクチカをIT学習で作る方法を参照してください。
← 一覧に戻る