ごきげんよう、先日、新卒から3年間お世話になった会社を、無事（？）卒業したコガと申します。
4月。IT業界に飛び込み、「詰んだ…」と白目を剥きそうになっている新卒SEの皆さん、息してますか？
現場に出ると、周りの先輩が呪文のような専門用語を唱え、真っ黒なターミナル画面と格闘している。
「自分、場違いなとこ来ちゃった？」 と震えて夜しか眠れない日々を過ごしていらっしゃると思います。
今回は、そんな皆さんがやりがちな 「実はこれ、現場でブチギレ案件だよ」 というNG行動を10個まとめました。ついでに深堀り出来る関連書籍も紹介。
僕は見事に地雷を踏みまくっていたので職場には散々迷惑をかけましたが、皆さんには僕の屍を超えて強く生きてほしいと思います。
NG行動その1：「分かりました」と反射的に答えてしまう
上司や先輩の説明中、内容が1ミリも理解できていないのに、物知り顔で「はい、はい、分かりました」と頷いていませんか？（僕はやってました）
これは「分かりました！」の3分後に 「……で、結局何すればいいんだっけ？」 となるやつです。もっかい質問しに行くの、気まずいね。
現場での「分かった」の後に「実は理解できてませんでした」というのは、サインした後に「中身読んでませんでした」と言うのと同じ。その後のミスは、100%自分の責任になります。
説明を聞いた後は、内容を要約して「これで合ってますか？」と必ず聞き返しましょう。
分からない時は質問して早めに恥をかいておきましょう。
「すみません、今の『デプロイ』って何ですか？」 と。
※ちなみに、この「デプロイ」もそうですが、IT用語には「トークン」「モジュール」「スキーマ」など、喋る人によって定義が全然異なる用語が大量に存在します。なんてややこしいんだ…
正直、ベテラン勢ですら雰囲気で使っていることがあるので、最初に定義をすり合わせておかないと、後で盛大な認識のズレという爆弾が爆発することになります。
・おすすめ書籍
コンサルティング会社 完全サバイバルマニュアル
https://www.kinokuniya.co.jp/f/dsg-01-9784163916767
NG行動その2：30分以上一人で悩み続けてしまう
分からないことにぶち当たった時、自力で解決しようとモニターを睨みつけたまま、静かに石化。
「うーん……」と唸りながら、どこにヒントがあるのかさえ見当もつかない状態でフリーズする。気づけば30分、1時間と、ただただ時間だけが虚無に消えていく……。
その悩み、詳しい上司や先輩に聞けば5秒で解決します。
もちろん、自走力を磨くのは大事です。
でも、上司や先輩は、まだ あなたの「知識の引き出し」がどれくらいあるのかを把握していません。 あなたが何に詰まっているのか、エスパーでは無いので分からないのです。
15分間、自分なりに調べたり手を動かしたりして、それでも1ミリも前進しなかったら、潔く白旗を揚げましょう。
「ここまで自分なりに調べてみたのですが、完全に詰まりました！教えていただいてもよろしいでしょうか？」
こう言われて嫌な顔をするエンジニアは（多分）いません。むしろ、何も言わずに1時間地蔵になられる方が、チームとしては、進捗が読めないという一番怖い事態を招きます。
「分からない」と白旗を揚げる勇気も、新人エンジニアとしての生存戦略です。
・おすすめ書籍
ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた
https://www.shoeisha.co.jp/book/detail/9784798185187
NG行動その3：「何がわからないか」を整理せずに質問する
質問する時に「なんかエラーが出て動かないんです……」とだけ伝える行為。
上司や先輩はミステリー小説の探偵じゃありません。出来る限りこちらの時間を使ってコミュニケーションを準備しましょう。
×：「〇〇が分かりません！教えてください！」
→学生にのみ許される質問形式です。全然ダメ。
〇「自分はこう思っているんですが、認識は合いますか？」
→仮説を立てて、Yes/Noで答えられるように質問している。間違っていた場合でも、正解との差分だけ答えればよいので回答コストが少なく、答えやすい。及第点。
◎「資料Aを読んだ結果、仮説Bという認識を持ちましたが、合ってますか？」
→具体的なエビデンスを根拠として仮説を立てている。パーフェクト。
何も考えずオープンクエスチョンを行うのは基本的にNGです。出来る限り相手の回答のコストが少なくなるよう、Yes/Noで答えられる形式、もしくは想定の選択肢を準備してコミュニケーションを取りましょう。
ちなみに全てのコミュニケーションを上記の形式で行うと、自然とコンサルみたいな喋り方になっていきます（準備が大変だし、めちゃめちゃ窮屈ですが…）
・おすすめ書籍
「いい質問」が人を動かす
https://bunkyosha.com/books/9784866517476
NG行動その4：コピペしたコード、AIが生成したコードの内容を理解していない
ネットで見つけたコードや、ChatGPTが爆速で生成してくれたコード。それを内容も理解せずコピペして、「とりあえず動いたし、エラーも出てないからヨシ！」
これは自分の担当範囲に、いつ爆発するか分からない時限爆弾を埋め込んでいるのと同じです。テロ行為は今すぐやめましょう。
そもそも、「なぜこの記述が必要なのか」を自分の言葉で説明できないコードは良い成果物とは言えません。例えテストが通ったとしても。
もしそのコードが原因で本番環境が止まった時、「AIが書いたので分かりません」なんて言い訳は通用しません。責任を取るのはAIではなく、そのコードを採用した我々自身だからです。
公開されているソースコードやAIの力を借りるのが悪いわけではありません。むしろ、これからの時代には必須のスキルです。AIを使えないエンジニアは淘汰されていきます。
ただし、それはあくまで自分でも書けるけど、時短のためにツールを使うというフェーズになってからの話。
分からないから丸投げするのではなく、理解した上で使いこなす。 それがプロのエンジニアのマナーです。
・おすすめ書籍
実践Claude Code入門
https://gihyo.jp/book/2026/978-4-297-15354-0
NG行動その5：メモを取らずに同じ質問を繰り返す
昨日聞いたはずのことを、今日また「すみません、これってどうやるんでしたっけ……？」と聞きに行く。
相手の先輩に 「あれ、俺、タイムリープしてる……？」 という既視感を与えてしまったらヤバイです。
同じ質問を繰り返された側は 「こいつ、教える側の時間を何だと思ってるんだ？」 と感じます。
「話を聞く気がないな」と判定された瞬間、相手の親切心はオフになります。新人にとっては最大の損失です。
自分の記憶力を過信してはいけません。
仕事における記憶力なんて、寝て起きたら半分以上揮発しているものだと思っておきましょう。（誰だよこのコード書いたやつ！！！あ、俺じゃん…）
だからこそ、一度教わったことは、PCのメモ帳でも手書きのノートでもいいので、即座に 「自分専用の資産」 として記録しましょう。ちなみに僕は「Shift + Windows + S」でスクショを撮ってExcelにペタペタ貼り付けて、吹き出しでメモを取ってました。あまりにもSIerすぎるだろ。
- 教わった手順をその場でメモする。
- 後で読み返して「自分なりのマニュアル」にブラッシュアップする。
この一手間を加えるだけで、二度と同じ質問をせずに済みます。しかもそのメモ書きは、後任の人にとっての手順書にもなりえます。
同じ質問をしないというだけで、あなたの信頼残高は少しづつ積み上がっていきます。
先輩の貴重な時間を奪わないこと。それが、現場で可愛がられるてスムーズに仕事を教えてもらえるための、最も泥臭くて着実な生存戦略です。
・おすすめ書籍
考える人のメモの技術
https://www.diamond.co.jp/book/9784478113028.html
NG行動その6：ドキュメントや仕様書を読まずに作業に入る
「この仕様書、文字ばっかりで読みづらいな……。よし、とりあえずコードを書きながら理解していくスタイルで行こう！」
そう言って颯爽と作業を始めるあなた。ちょっと待ってください。そのとりあえずは地獄への片道切符です。
キーボードを叩いてコードを打ち込むのは、最後の清書に過ぎません。設計や仕様を正しく理解していないまま走り出すのは、設計図を見ずに家を建て始めるようなものです。あとで「あ、柱の位置がズレてた」と気づいたら手戻りが発生します。そして割かれる無駄な工数。
だからこそ指を動かす前に、まずはドキュメントを読み込みましょう。
- このシステムは何を実現したいのか？
- データの流れはどうなっているのか？
- 例外的なケースはどう処理すべきか？
これらを頭の中で（あるいは紙に書いて整理してもいいですが）組み立ててから、ようやくコードエディタを開く。これが遠回りに見えて、最短でゴールに辿り着く唯一の道です。
もし、仕様書が意味不明すぎて「どこから手を付ければいいか分からない」という時は、遠慮なく先輩にこう聞いてください。
「このドキュメントを読み解く上で、まず重点的に見るべきポイントや、読む順番を教えていただけますか？」
個人が分からないまま進むのは、チーム全体にとってのリスクなんですね。
・おすすめ書籍
世界一流エンジニアの思考法
https://www.maruzenjunkudo.co.jp/products/9784163917689
NG行動その7：ミスや遅れなどの悪い報告を後回しにする
ミスをした時や、作業が予定より遅れている時。「怒られるのが怖い」「自分で何とか挽回できるかも……」「まあいっか」と、ついダマになりがちですよね。これは人間の心理上、仕方のないことです。（自分もやってしまいがち）
ただし時間が経てば経つほど、それは負のエネルギーを蓄えて大損害に変化し始めます。
仕事における「やらかしました！」の報告は、何よりも鮮度が命です。
- 発生してすぐ報告： 「しょうがねぇな、一緒に直そう」で済む。
- 1日経って報告： 「なんで昨日言わなかったんだ？」と詰められる。
- 1週間経って発覚： チーム全員で徹夜、あるいは土下座案件。
このように、報告が遅れるほど、周囲の対応コストと怒りのボルテージは指数関数的に跳ね上がります。
ミスをした瞬間に白状すれば、あなたの評価は「ミスをした人」で止まりますが、隠し通そうとすれば「不誠実で信頼できない人」へと格下げされます。
「すみません、やらかしたかもしれないです！至急、リカバリーの相談をさせてください！」
この一言を、プライドを捨てて爆速で発信しましょう。「最速でごめんなさいを言えること」ってかなり大事です。
※ちなみに、この「ミスや遅延を報告しやすくする、職場における心理的安全性」はめちゃくちゃ重要なのですが、新人がどうにかできるものではないので割愛。我々経験者はあまり自分基準で考えずにビギナーに優しい環境を作らねばならないですね。。。
・おすすめ書籍
なぜ、あなたの仕事は終わらないのか スピードは最強の武器である
https://bunkyosha.com/books/9784905073413
NG行動その8：「自分は文系未経験だから」と技術に壁を作る
難解なロジックや知らないIT用語が出てきた瞬間、心の中で「あ、これは今の自分には関係ないやつだ」と、脳内のシャッターをガラガラと閉めてしまう。あるある。
でも、現場に出た瞬間、あなたが文学部出身だろうが経済学部出身だろうが、周りは1ミリも気にしていません。
文系・理系という境界線は、あなたが勝手に脳内に建設している思い込みのバリケードです。
実は僕、実務と並行して、学生向けのロボットプログラミング教室講師を3年ほどしていました。そこでは、順序立てて説明してあげれば、子供たちが大人顔負けのアルゴリズムを平気で組んでくるんです。
小学生にできて、大人の我々にできないわけがない。
ぶっちゃけ、プログラミングや設計の大部分で求められるのは、微分積分や線形代数などの高度な数学ではありません。むしろ、用語や考え方といった「時間をかければ誰でも理解できる知識」が中心です。
あなたはまだ、理解することに時間をかけていないだけです。
資格勉強、個人開発…今からでも我々にできる学習は大量にあります。
今すぐ自分に言い訳をするのをやめて、脳内の壁をぶ
ち壊しましょう。
・おすすめ書籍
キタミ式イラストIT塾 基本情報技術者
https://gihyo.jp/book/2025/978-4-297-15301-4
※応用情報を紹介したかったけど今年（2026年）で無くなるため…
NG行動その9：ツールや環境の仕組みをブラックボックスのままにする
「とりあえず、このボタンをポチッと押せば、なんかいい感じに動く」
そんな手順書通りの操作だけで満足していませんか？かくいう僕もそうでした。（中身も分からず、TeraTermの接続ファイルをダブルクリックする日々……）
中身の仕組みをブラックボックスにしたままツールを使っているうちは、エンジニアではなく単なるボタン押下代行マシーンです。
正常に動いている時はいいでしょう。しかし、ある日突然そのボタンが効かなくなった瞬間に詰みます。
裏側で何が起きているかを知らなければ、ログを読んで原因を突き止めることも、リカバリーすることもできず、ただ画面の前で途方に暮れるだけの置物になってしまいます。
プロの現場においても、理由は不明だが何故か動いたは「あるある」ですが、たまたま爆弾が爆発しなかったのと同じくらい恐ろしい状態だと認識してください。
- そのボタンの裏で、実際にはどんなコマンドが実行されているのか？
- どの設定ファイルが読み込まれているのか？各設定プロパティの意味は？
- データはどこから取得されているのか？
こうした裏側の仕組みに対して、エンジニアとしての好奇心を持ちましょう。正直、全ての手順の仕組みを毎回理解して行うのは無理がありますが、時間のある時に調べるのは誰にでもできます。
そして今はGoogleだけでなく、AIという心強い家庭教師もいます（広告も入らないしなんて便利なんだ…！）
「この操作の内部挙動を、専門外の人でも分かるように解説して」と投げかければヒントをいくらでもくれます。もちろん、鵜呑みはダメですが。正しい理解には、やはりIPAなどの資格試験がおすすめです。
仕組みを知っておくことは、トラブルに直面した時の最強の防御になります。
表面上の操作をなぞるだけの作業員で終わるのか、システムを自在に操るエンジニアになるのか。できれば後者のエンジニアが増えてほしいなと思ってます。
・おすすめ書籍
実務で役立つ ログの教科書 基礎知識から収集方法・分析手法・トラブルシューティング・パフォーマンス最適化・機械学習での活用まで
https://www.shoeisha.co.jp/book/detail/9784798192123
NG行動その10：ユーザーの視点を忘れ、作業自体が目的になる
「設計書にそう書いてあるから」
「指示通りに作ったから、私の仕事は終わりです」
そう言って、明らかに使いにくいボタン配置や、謎の挙動をスルーして実装していませんか？これは作業者が陥りがちな思考停止の落とし穴です。
上流工程がいかにずさんであろうと、使う人の気持ちを無視して作られたシステムは、ただの自己満足の塊です。
エンジニアの本来のミッションはコードを書くことではなく、システムを通じて誰かの課題を解決することのハズ。作業の完了そのものが目的になってしまったら、本末転倒です。
要件定義資料や各種設計書・仕様書は基本的に従うべきではありますが、「絶対的に変更不可能な聖書」ではありません。考慮漏れや不整合、使いずらいUI設計は普通に発生します。だって人間だもの。
ここで、文系出身であるあなたの強みを思い出してください。
専門用語に染まりきっていない、「普通の人」としての感覚。これこそが、最強の武器になります。
「これ、実家の父ちゃん母ちゃんでも、迷わず使えるか？」
もし答えがNOなら、勇気を持って「ここ、もっとこうした方が使いやすくないですか？」と声を上げましょう。間違ってたら反論されて終わりですが、別に誰も損してないし良いですよね。
使う人の利便性のためにより良い形を提案できると、エンジニア戦闘力アップです。
・おすすめ書籍
イシューからはじめよ――知的生産の「シンプルな本質」
https://eijipress.co.jp/products/2356
最後に：生存戦略としての心得
最初は出来ないことだらけで、「自分、無能すぎでは……？」と凹むこともあるでしょう（僕も毎日怒られてたポンコツでした）
でも大丈夫。
今バリバリやってる先輩たちも、昔はみんな何かしらのデータを飛ばしたり、トンチンカンな質問をしたりして、血を流しながら強くなってきました。
周囲とのレベル差や分からないことだらけで色々大変なことも多いと思いますが、走り続ければ意外と何とかなります。あなたの強みを生かして頑張れ！応援してます！