IT未経験2年目、分かっていなかったのは技術だけじゃなかった

IT未経験でIT企業に入社し、
現在2年目のSEとして現場で働いています。

入社後、10月の配属までに半年間の研修があり、
コードの書き方や、考え方の基礎は一通り学びました。

ただ、現場に出てみると、
自分の中にあった前提と、
現場で求められる考え方の間に、
ずれを感じる場面が何度もありました。

この記事では、
1年目の自分が当たり前だと思っていた前提や、
その前提が現場でどうズレていたのかを、
今の視点から並べて書いています。

何かを教えたり、結論を出したりするつもりはありません。
ただ、考え方の選択肢の一つとして、
こんな視点もあった、という記録です。

この記事で書くこと
・IT未経験で現場に入って感じた違和感
・当時、自分が置いていた前提
・その前提がどこでズレていたのか
・２年目の今も判断に迷うこと

章1：IT未経験で現場に入って、想定と違ったこと

実装よりも「どう考えたか」を説明する場面が多かった

現場に出てまず感じたのは、
修正内容そのものよりも「なぜそう判断したのか」を説明する場面が多い、ということでした。

修正が正しく動くかどうか以上に、
どの選択肢を考え、その中からなぜそれを選んだのか。
判断に至るまでの考え方を、言葉で示すことが前提になっていました。

正解や例のない状態で、最初の一歩から考える必要があった

もう一つ想定と違ったのは、
タスクにはある程度の確認順や進め方が示されるものだと思っていたことです。

実際には、「まず何を確認するか」から自分で考える必要がありました。

タスクには、完成形や明確な手順が用意されていないことがほとんどでした。
小さな修正に見えても、影響範囲や確認順を自分で切り分ける必要があります。

特に本番環境や Git 操作を意識するようになってからは、
「とりあえず動かす」という判断を簡単には取れなくなりました。

修正が想定通りに動くかを確認するために試すことはあります。
ただ、その前に確認しておくべき前提があると意識するようになったからです。

たとえば、変更の影響範囲や、元に戻す方法が明確かどうか。
そうした点を整理してからでないと、手を動かしにくくなりました。

何を基準に判断すればいいのか分からなかった

当時の自分は、
どこを基準に判断すればいいのか分からないまま、立ち止まることがありました。

たとえば、どの修正方法を選ぶのか、
どこまで影響範囲を広げて確認すべきなのか。
そうした判断を求められていることは分かっていても、
何を優先し、どこまでを「十分」とするのかという軸を、自分の中に持てていませんでした。

求められているものが、
自分の想定していた働き方と違う、という感覚はありましたが、
それをどう言葉にすればいいのかは、まだ分かっていなかった気がします。

---

当時は、
その違和感がどんな前提から来ているのかを、
まだ自分の中で整理できていませんでした。

今振り返ると、
その背景には、1年目の自分が無意識に置いていた
いくつかの前提があったように思います。

その前提を、今の視点から言葉にすると、
次のような考え方だったように思います。

章2：1年目の自分が、今見るとズレていた考え方

当時、当たり前だと思っていた前提

当時の前提
・考えれば分かる
・理解してから質問すべき
・正解や手順はある程度用意されている
↓
行動
・一人で考え続ける
・整理してから質問する
・最初の一歩が遅くなる
↓
結果
・手が止まる
・進捗が遅くなる
・判断基準が分からないまま作業する

わからないのは考える時間が短いからだと思っていた

当時の私は、「分からないのは、まだ十分に考えていないからだ」と捉えていました。
時間をかけて考え続ければ、いずれ答えにたどり着けるはずだ、と思っていたのです。

ある程度理解してからでないと、質問してはいけないと思っていた

自分なりに整理できてからでないと、上司に質問してはいけない気がしていました。
すぐに聞いてしまうと、「考えていない」と思われるのではないか、
自分の思考力や理解力が鍛えられないのではないか、
そんな前提を自分の中に置いていました。

何から確認すればいいのか分からないまま、立ち止まっていた

その結果、一歩目が分からないまま行き詰まり、進捗が悪くなることもありました。
雛形や参考になるコード、使えそうなメソッドがあるかどうかも分からない状態で、
すべてを一から作ろうとしていたのです。

今なら、こう考える

前提や判断基準の有無を先に確認する

今なら、自分が把握できていない範囲ですでに結論が出ていたり、
判断基準や仕組みが用意されている可能性を、先に考えます。

まずは Wiki や過去のやり取りを確認し、
それでも見当たらなければ上司に確認する、という順番を取るようになりました。

思考を整理するための質問もしてよい

考えること自体は大切ですが、
理解が不十分な段階で質問することで、
今どこで詰まっているのかを共有できることもあります。

完成形を前提にするのではなく、
方向性やヒントだけをもらう、という形で進められる場面もありました。

章3：それでも、外さなかった線

今振り返ると、1年目の自分には、
「ここは外さない」という線だけを意識して動く癖がありました。

積極的に前に出るというよりも、
判断を誤らないことを優先するような動き方だったと思います。

当時の動き方	今意識していること
判断を誤らないことを優先	判断理由を言葉で説明する
分からないことは整理してから質問	途中段階の認識を共有する
手を止める判断が多い	影響範囲を先に考える
一人で考えてから動く	前提を最初に共有する
正解を探そうとしていた	判断基準を意識する

質問・確認のしかた

分からない点があっても、すぐに質問することは少なかったです。
一度自分の中で状況を整理し、
どこが分かっていないのかを切り分けてから、上司に相談していました。

質問する際も、完成形を前提にすることはほとんどありませんでした。
「ここまで分かっている」「この前提で考えている」といった
途中段階の認識を共有し、方向性のみを確認していました。

止まる・待つ判断

Git 操作や本番環境に関わる作業については、
すぐに実行せず、影響範囲を確認してから進めていました。

不明点が残っている状態で、そのまま作業を進めることは避けていました。
一度手を止めて確認や修正を挟む判断をすることが多かったと思います。

説明の仕方

現在は、後輩に作業を依頼する場面もあります。
その際は、手順だけでなく、
その作業がどこに影響するのかも併せて伝えるようにしています。

説明に時間がかかることもありますが、
必要な情報は最初にまとめて共有する進め方を取っています。
後から前提を補足するより、その方が混乱が少ないと感じているからです。

こうした動き方は、
当時から無意識に続けてきた判断の癖だったように思います。

章4：今も判断に迷っていること

今も判断に迷う場面
・情報が足りないのか分からない
・判断の言葉が持てない

2年目になった今も、
判断が止まる場面はあります。

特に、これまで書いてきた前提や動き方を踏まえたうえで、
次のような状態に陥ることがあります。

情報が足りないのか分からない状態

情報を集めれば判断できる、という段階ではあるものの、
どこまで確認すれば十分なのかが分からず、
手を止める判断が難しい場面があります。

影響範囲を見積もるために必要な情報が、
どこまで揃っていればよいのかが判断できず、
調査を続けてしまうこともあります。

判断の言葉が持てない状態

判断自体は求められているものの、
なぜその選択を取るのかを、
自分の言葉で整理しきれない場面もあります。

選択肢は見えているのに、
どこを基準に判断すべきかを言語化できず、
理由を曖昧にしたまま判断を保留してしまうことがあります。

最後に

ここまで、1年目の自分が当たり前だと思っていた前提を、
今の視点から振り返って書いてきました。

ただ、今も判断に迷う場面は残っています。

迷いも含めて、今の自分の状態をそのまま書いています。

同じような立場で働く人や、
そうした新人を見る側にとって、
考え方の一例として置いておければと思います。