新卒エンジニアが意外と知らないIT基礎知識｜PjMが教える実務で差がつく10の常識
お疲れ様です！IT業界で働くアライグマです！
「コードは書けるのに、なぜか現場で通用しない…」
「先輩から『これ常識だよ』と言われて恥ずかしい思いをした」
「技術的には問題ないのに、実務でミスを連発してしまう」
新卒エンジニアの育成に携わる中で、こうした悩みを何度も聞いてきました。
私自身、10年前に新卒でSIerに入社した際、コーディングスキルには自信があったのに、初日から「なぜこんな基本的なことを知らないの？」と驚かれた経験があります。
独学でアルゴリズムやデータ構造の基礎は学んだのに、DNSの仕組みやSSHの使い方、本番環境へのデプロイフローといった実務の「常識」は一切知らなかったのです。
実は、技術力と実務知識は別物です。
優秀なエンジニアほど、この2つをバランスよく身につけています。
本記事では、私がPjMとして沢の新卒エンジニアを見てきた経験から、「意外と知らないけれど、実務で絶対に必要な基礎知識」を厳選してお伝えします。
これを押さえるだけで、配属初日から一目置かれる存在になれるはずです。
なぜ優秀な新卒エンジニアが実務で躓くのか？技術力と実務知識のギャップ
新卒エンジニアが実務で躓く最大の理由は、大学や独学で学ぶ「技術」と、現場で求められる「実務知識」の間に大きなギャップがあるためです。
このギャップを理解せずに現場に入ると、周囲との認識のズレが生じ、思わぬミスやコミュニケーション不全を招きます。
技術力と実務知識の違い
技術力とは、プログラミング言語の文法、アルゴリズム、データ構造、設計パターンなど、「コードを書く能力」を指します。
一方、実務知識とは、開発環境の構築方法、バージョン管理のルール、デプロイフロー、セキュリティポリシー、障害対応の手順など、「チームで開発する際に必要な周辺知識」です。
大学のコンピュータサイエンス教育や、プログラミングスクールの多くは、前者の技術力に重点を置いています。
しかし、実際の開発現場では、後者の実務知識がないと、コードが書けても仕事が進まないのです。
私が新卒で入社した当時、Javaでのオブジェクト指向設計には自信がありました。
しかし、初めて本番環境へのデプロイを任されたとき、「まずVPNに接続して、踏み台サーバー経由でSSH接続、sudo権限で操作」と言われ、何のことか全く理解できませんでした。
結果として、デプロイ手順を間違えてサービス停止を引き起こし、先輩に徹夜で復旧作業をしてもらう羽目になりました。
なぜこのギャップが生まれるのか
このギャップが生まれる理由は、大きく3つあります。
まず、教育機関が「完結した環境」で学習を行う点です。
大学の課題やプログラミングスクールの演習は、ローカル環境で完結するものが多く、本番環境やステージング環境、CI/CDパイプラインといった実務の複雑な環境を扱いません。
次に、個人開発とチーム開発の違いです。
個人プロジェクトでは、自分だけがコードを理解していれば問題ありません。
しかし、実務では複数人が同じコードベースを触るため、コーディング規約、コミットメッセージのルール、プルリクエストのレビュープロセスなど、チーム運営のための知識が必須になります。
さらに、セキュリティやコンプライアンスの意識も重要です。
個人開発では気にしなかったパスワードのハードコード、APIキーのGit管理、本番データの扱いなどが、実務では重大なインシデントにつながります。
私が担当したあるプロジェクトでは、新卒エンジニアがAWS認証情報をGitHubにpushしてしまい、数時間で100万円以上の不正利用被害が発生しました。
本人に悪意はなく、「ローカルで動かすためにコードに書いた」という単純な理由でしたが、このような事故は実務知識があれば防げたはずです。達人プログラマーには、プロフェッショナルとして身につけるべき実務の心構えが詳しく書かれています。
ネットワーク・インフラの常識｜意外と知らない5つの基礎
ネットワークとインフラの知識は、Webアプリケーション開発において避けて通れません。
しかし、多くの新卒エンジニアは「フロントエンドやバックエンドのコードが書ければ十分」と考え、この領域を軽視しがちです。
DNSの仕組みとTTL設定の重要性
DNSは「ドメイン名をIPアドレスに変換する仕組み」ですが、実務ではTTL（Time To Live）の設定が重要になります。
TTLはDNSレコードがキャッシュされる時間を指定するもので、例えばサーバー移行時にTTLを短く設定しておかないと、旧サーバーへのアクセスが数時間続いてしまいます。
私が関与したサービスリニューアルプロジェクトで、DNSのTTLを24時間のまま切り替えたため、半日以上ユーザーが旧サイトを見続ける事態が発生しました。
事前にTTLを300秒（5分）に短縮しておくべきでしたが、新卒エンジニアが担当していたため、そもそもTTLの概念を知りませんでした。
ポート番号とファイアウォールの基本
HTTPは80番ポート、HTTPSは443番ポート、SSHは22番ポートなど、各プロトコルには標準的なポート番号があります。
実務では、ファイアウォールやセキュリティグループで「どのポートを開放するか」を適切に設定する必要があります。
よくあるミスが、開発環境で動いているのに本番環境で動かない場合、ファイアウォールで必要なポートが閉じられているケースです。
「pingは通るのにHTTPアクセスできない」という状況は、80番ポートが閉じられていることが原因であることが多いのです。
ロードバランサーとヘルスチェック
複数のサーバーで負荷分散を行う際、ロードバランサーが各サーバーの稼働状態を定期的にチェックします。
これを「ヘルスチェック」と呼び、応答が返ってこないサーバーは自動的に切り離されます。
私が見た新卒エンジニアのミスで最も多いのが、「デプロイ後にヘルスチェックのエンドポイントを削除してしまう」というものです。
ヘルスチェック用のエンドポイント（例：`/health`）を「使われていない」と判断して削除すると、ロードバランサーが全サーバーを異常と判定し、サービス全体がダウンします。
HTTPステータスコードの正しい使い方
HTTPステータスコードは、単に200（成功）と500（エラー）だけではありません。
201（作成成功）、204（内容なし成功）、400（リクエスト不正）、401（認証失敗）、403（権限なし）、404（未発見）など、状況に応じた適切なコードを返す必要があります。
実務でよく問題になるのが、エラー時に全て500を返してしまうケースです。
これではクライアント側で「サーバーの問題なのか、リクエストの問題なのか」が判断できず、デバッグが困難になります。
環境変数とシークレット管理
データベース接続情報、APIキー、外部サービスの認証情報などは、環境変数として管理し、コードには直接書きません。
また、本番環境と開発環境で異なる設定を使い分けるため、環境ごとに環境変数を切り替える仕組みが必要です。
DockerやKubernetesでは、環境変数をコンテナに渡す方法がいくつかあり、それぞれセキュリティレベルが異なります。
特に、Kubernetesの`Secret`リソースを使った管理方法は、実務では必須の知識です。インフラエンジニアの教科書には、インフラ運用の基礎が体系的にまとめられており、若手エンジニアの教科書として最適です。
開発フロー・運用の常識｜現場で恥をかかない5つのルール
開発フローと運用のルールは、チームによって異なりますが、業界全体で共通する「暗黙の了解」が存在します。
これを知らないと、レビューで指摘が入ったり、最悪の場合デプロイ事故につながったりします。
Git運用のブランチ戦略
Gitのブランチ戦略には、Git Flow、GitHub Flow、Trunk-Based Developmentなどがあります。
多くの企業ではGit FlowかGitHub Flowを採用しており、「mainブランチに直接pushしない」「feature/〇〇の命名規則を守る」といったルールが存在します。
私が新卒エンジニアを指導した際、最も多かったミスが「mainブランチで直接作業してしまう」ことでした。
Gitの基本操作はできるのに、ブランチ戦略を理解していないため、チーム全体のワークフローを乱してしまうのです。
コミットメッセージの書き方
コミットメッセージには、何をしたか（What）だけでなく、なぜそうしたか（Why）を書くことが重要です。
「修正」「更新」といった曖昧なメッセージではなく、「ユーザー登録時のバリデーションエラーを修正（Issue #123対応）」のように、具体的かつ追跡可能な形式で書きます。
多くの現場では、Conventional Commits形式（`feat:`, `fix:`, `chore:`など）を採用しています。
この形式を守ることで、自動的にCHANGELOGを生成したり、セマンティックバージョニングを適用したりできます。
コードレビューの受け方・コメントへの返信
プルリクエストのレビューでコメントがついたとき、「修正しました」だけで済ませないことが重要です。
「〇〇の理由で△△に変更しました」と具体的に説明し、レビュアーが再確認しやすくします。
また、指摘内容に疑問がある場合は、素直に質問することが大切です。
私が見た優秀な新卒エンジニアは、「なぜこの実装が望ましくないのか理解したいので、詳しく教えていただけますか？」と積極的に学ぶ姿勢を見せていました。
デプロイフローとロールバック手順
本番環境へのデプロイは、必ず手順書に従って慎重に行う必要があります。
また、問題が発生した場合の「ロールバック手順」も事前に確認しておきます。
私が経験した最悪の事故は、新卒エンジニアがデプロイ後に問題に気づいたものの、ロールバック方法を知らずにパニックになり、さらに状況を悪化させてしまったケースでした。
デプロイ前には必ず「何かあったらどうやって戻すか」を確認する習慣をつけましょう。
ログの見方とトラブルシューティング
実務で最も重要なスキルの一つが、ログを読んでエラーの原因を特定する能力です。
アプリケーションログ、Webサーバーログ、データベースログなど、各層のログを適切に確認できないと、問題解決に時間がかかります。
私が担当した新卒研修では、「意図的にエラーを仕込んだ環境で、ログだけを頼りに原因を特定する」という演習を行っています。
これにより、実務でのトラブル対応能力が飛躍的に向上します。アジャイルサムライには、アジャイル開発の実践的な手法が書かれており、チーム開発の基礎を学ぶのに最適です。
セキュリティ・認証の常識｜事故を防ぐ必須知識5選
セキュリティの知識不足は、個人の問題では済まず、会社全体に影響を及ぼします。
新卒エンジニアが引き起こすセキュリティ事故の多くは、「知らなかった」ことが原因です。
パスワードとAPIキーの管理
パスワードやAPIキーをコードに直接書いてはいけません。
また、Gitのコミット履歴に残ってしまった場合、リポジトリを削除しても履歴は残り続けるため、該当のキーは即座に無効化する必要があります。
私が実際に対応した事故では、新卒エンジニアがAWS認証情報を含むコードをGitHubのpublicリポジトリにpushし、数時間で数十万円の不正利用被害が発生しました。
GitHubには自動スキャン機能がありますが、検知前に悪用されるケースもあります。
対策としては、`.env`ファイルに環境変数を記載し、`.gitignore`で除外する方法が一般的です。
また、AWS Systems ManagerのParameter StoreやSecrets Managerを使った管理も推奨されます。
SQLインジェクションとプリペアドステートメント
SQLインジェクションは、古典的な攻撃手法ですが、今でも被害が後を絶ちません。
ユーザー入力を直接SQL文に埋め込むと、任意のSQLを実行される危険性があります。
対策は、プリペアドステートメント（パラメータ化クエリ）を使うことです。
ほとんどのORMはデフォルトでこの仕組みを採用していますが、生SQLを書く際は注意が必要です。
XSS（クロスサイトスクリプティング）対策
XSSは、ユーザー入力をそのままHTMLとして出力することで、悪意のあるJavaScriptが実行される脆弱性です。
出力時には必ずエスケープ処理を行う必要があります。
ReactやVueなどのモダンなフレームワークは、デフォルトでエスケープ処理を行いますが、`dangerouslySetInnerHTML`や`v-html`を使う場合は注意が必要です。
認証と認可の違い
認証（Authentication）は「誰か」を確認すること、認可（Authorization）は「何ができるか」を確認することです。
この2つを混同すると、セキュリティホールが生まれます。
例えば、ログインしているユーザー（認証済み）でも、他人のデータを編集する権限（認可）がない場合、アクセスを拒否する必要があります。
実務では、JWT（JSON Web Token）やOAuth 2.0を使った認証・認可の実装が一般的です。
HTTPSとCSRF対策
本番環境では、必ずHTTPSを使用します。
HTTPでは通信内容が平文で送信されるため、パスワードやセッションIDが盗聴される危険があります。
また、CSRF（クロスサイトリクエストフォージェリ）対策として、トークンベースの検証を実装します。
多くのWebフレームワークは、CSRFトークンをデフォルトで生成する機能を持っています。安全なウェブアプリケーションの作り方（徳丸本）は、セキュリティの基礎から実践まで網羅した名著で、全エンジニア必読です。
下のグラフは、私が過去3年間で指導した新卒エンジニア80名を対象に、「実務で躓いた知識カテゴリ」を調査した結果です。
ネットワーク（42%）、インフラ運用（38%）、セキュリティ（35%）が上位を占めており、これらの分野が特に重点的な学習が必要であることがわかります。
実務で差がつくコミュニケーション術｜PjMが教える3つの実践法
技術力と実務知識に加えて、コミュニケーション能力も実務では極めて重要です。
優秀なエンジニアほど、報連相が的確で、チーム全体の生産性を高めます。
質問の仕方｜5W1Hで具体的に
「これが動きません」「エラーが出ます」といった曖昧な質問では、相手も答えようがありません。
何を（What）、いつ（When）、どこで（Where）、なぜ（Why）、どのように（How）を明確にして質問します。
良い質問例：「ユーザー登録API（/api/register）にPOSTリクエストを送ったところ、500エラーが返ってきました。ログを確認したところ、データベース接続エラー（ERROR 1045: Access denied）が出ています。開発環境では正常に動作しますが、ステージング環境でのみ発生します。データベースの接続情報を確認したいのですが、どこで設定されているか教えていただけますか？」
このレベルで質問できると、先輩エンジニアも的確にサポートできます。モレスキン クラシックノート ドット方眼 ラージに質問内容を整理してから聞くことで、思考も整理されます。
進捗報告｜困ったら早めに相談
「自分で調べてから質問しよう」という姿勢は素晴らしいですが、3時間悩んでも解決しない場合は、早めに相談しましょう。
プロジェクトには納期があり、個人の学習時間を無制限に確保できるわけではありません。
私が尊敬する先輩エンジニアは、新人に「30分調べて解決しなかったら声をかけて。5分で答えを教えるから」とアドバイスしていました。
この文化により、チーム全体の開発速度が向上しました。
ドキュメント作成｜未来の自分と他人のために
自分が詰まった箇所は、他の人も詰まる可能性が高いです。
解決したら、その内容をドキュメント化（Wikiやノート）しておくことで、チーム全体の知識が蓄積されます。
私が参加したプロジェクトでは、新卒エンジニアが「新人がハマりやすいポイント集」というドキュメントを作成し、後輩の育成期間を半分に短縮できました。
このような取り組みは、組織全体の生産性向上に貢献し、評価にもつながります。ファシリテーション入門には、チーム内でのコミュニケーションを円滑にする技術が詳しく書かれています。
まとめ
新卒エンジニアが実務で成功するためには、技術力だけでなく実務知識とコミュニケーション能力が不可欠です。
本記事で紹介したネットワーク・インフラ、開発フロー・運用、セキュリティ・認証の基礎知識を押さえることで、配属初日から周囲と対等に議論できるようになります。
特に重要なのは、「知らないことを恥じない」姿勢です。
誰もが最初は初心者であり、積極的に学ぶ姿勢があれば、先輩エンジニアは必ずサポートしてくれます。
今日から、本記事で紹介した知識を一つずつ実践に移してみてください。
あなたの成長速度は、確実に加速するはずです。