本記事は
【Advent Calendar 2025】
7日目の記事です。
🌟🎄
6日目
▶▶ 本記事 ▶▶
8日目
🎅🎁
はじめに
こんにちは ! 入社2年目の清水です。
文系出身でプログラミング未経験のまま入社してから、気づけば2年目の終わりが近づいてきました ! 本当に早いものですね。
改めて振り返ると、入社当時は多くの不安がありました。
「情報系出身の人たちについていける気がしない」「プログラミング経験がほとんどない」
私もまさにそんな不安を抱えながら、エンジニアの道に踏み出しました。
今回の記事では、そんな私が実際にぶつかった壁と、文系としての強みがどう活かせたのかをまとめています !
今これを読んでいる方の中にも、IT業界に入りたいけど文系であることに引け目を感じていたり、1～2年目で壁にぶつかって悩んでいたりする方がいるのではないでしょうか…？
この記事が、あなたの背中を少しでも押せたら嬉しいです !
入社前 : 資格が「地図」になった
内定直後に始めたのは応用情報の勉強
プログラミング未経験の自分が、情報系出身の同期と肩を並べて働けるのか。
まず不安に思ったのは、基礎知識の不足でした。
そこで内定後すぐに着手したのが、 応用情報技術者試験（AP） への挑戦です !
入社前にIT資格を取得しようと思った理由は、この3つです。
- ITの基本を体系的に学べる
- 入社前の不安を少しでも減らしたかった
- 業務で必要となる知識を先に入れておきたかった
結果として合格することができ、入社前の大きな安心材料になりました !
「なぜ基本情報ではなく応用情報を選んだのか」「どうやって合格したのか」など、詳しくはこちらのブログにまとめています !
tech.nri-net.com
入社後 : ギャップと向きあった1年目
研修で「コードを書く楽しさ」に気づいた
入社後の社内IT研修はレベル別にクラス分けされていたため、自分のペースに合った環境で無理なくキャッチアップできました !
コードを書いて動かす経験がほとんどなかった私でも、毎日少しずつ理解が積み重なっていき、初めて「あ、コード書くの楽しいかもしれない」と思えた時期でした。
配属後に待っていたのは「非開発タスク中心の業務」
研修で開発を楽しめた反動で、配属後に驚いたのは 思ったよりコードを書く仕事が少なかった ことです。私が参画した維持管理プロジェクトは、当時
- アカウント管理
- 月初の定常レポート作成
- 顧客からの問い合わせ対応
- ログ調査やターミナル作業
など、非開発タスクが中心でした。
そのため、「エンジニアになったのに、結局コードはほとんど書かないの…？」という戸惑いが大きかったです。
研修でコーディングが楽しいと思えたこともあって、開発タスクが少ないことは正直ちょっと残念でした…。
ただ、その分顧客とのコミュニケーションが多かったので、早い段階で対応に慣れることができたのは良かったなと思います !
業務外で取り組んだAWS資格取得
業務では開発タスクが少なかったため、あまり経験が積めず、少し焦りを感じていました…。
そこで、入社前から取り組んでいた資格取得を継続的に進めることにしました !
その結果、1年目でAWS認定資格12種類すべてを取得（いわゆる全冠） !
開発経験が少ない中でも、クラウド・セキュリティ・機械学習など幅広い知識を資格勉強で補うことができました。
AWS全冠のスケジュールや学習方法についても、ブログにまとめています !
tech.nri-net.com
また、内定～1年目に取得した資格についてもブログにまとめています。
スケジュールや取得戦略についても書いているので、資格に興味がある方はこちらもぜひチェックしてみてください !
tech.nri-net.com
2年目 : 初めての大型プロジェクト
CI/CDパイプライン構築にゼロから挑戦
2年目に入り、初めて大きなプロジェクトに参画しました !
私に任されたタスクは、CI/CDパイプラインの構築。ただし、ここで大きな壁がありました。
- GitLab、Jenkins、Nexus などの知識がゼロ
- 顧客環境特有の独自ルールが多い
- そもそもCI/CDの概念が曖昧
完全にゼロからのスタートでした。
ずっと大きな案件に関わってみたいと思っていましたが、振られたタスクは全く知識のないCI/CDパイプラインの構築。どうやって進めていけばいいのか、不安でいっぱいでした…。
見積もりができず、後で苦しむ
プロジェクトに参画してすぐ、チームで進捗管理表の作成をすることになりました。
進捗管理表では、各タスクの内容やそれにかかる日数、期日を洗い出して、チーム全体のタスクを管理します。進捗管理表の作成にあたって、リーダーから「このタスク、どのくらいかかりそう？」と聞かれたとき、うまく見積もりができないことがありました。
1年目までは既知のタスクが多く、前回の見積もりを参考にすれば大体対応できたのですが、
全く知識のないタスクについては、どのくらい時間がかかるのか想像ができませんでした。
そのまま曖昧な見積もりで進めた結果、後々その見積もりに自分が苦しめられることになりました…。
コードレビューで直面した「文系ならではの壁」
プロジェクトでパートナーのコードレビューに立ち合ったとき、文系ならではの壁に直面しました…。
これまでの業務ではITの一般的な知識を扱ってきたものの、コードレビューで必要な「バグの発見」「保守性や可読性のチェック」「パフォーマンスの最適化」といった観点を、実際のコードにあてて確認する経験はほとんどありませんでした。
研修やプロジェクトでこうした観点自体は学べるのですが、情報系出身のメンバーだったら学んだ観点をもとにコードを読み、確認することが比較的スムーズにできるのに対し、文系出身の私はその土台が十分ではなく、レビュー観点をもとにコードを追うこと自体がとても難しく感じました。
コードレビューに立ち会うたび、常に手探りの状態でコードを追っていたのを覚えています。
文系だからこそ活かせた強み : 伝える力
この2年間で、顧客対応やCI/CDパイプラインの構築といった業務から、資格取得や社内ブログの執筆まで、さまざまなことに取り組んできました。技術スキルが不足していて苦労する場面も多くありましたが、その一方で、文系出身だからこそ活かせた強みもありました。 それが 「物事を整理し、相手にわかる言葉で伝える力」 です。 ここでは、特に役に立った3つの場面を紹介します。
1. 顧客対応で発揮した「伝える力」
1年目から顧客とコミュニケーションを取る立場だったため、仕様説明や要件のすり合わせ、問い合わせ対応などを任されることが多くありました。
そのときに強く感じたのが、文系だからこそ 「どこが分かりづらいか」に敏感になれる という点です !
自分自身、専門用語に苦戦してきた経験があるからこそ、
- この言い方だと伝わらないかも
- もっとかみ砕くならどんな表現？
- ここは図や例えがあった方がいいかも
を自然と考えるようになりました。
そのおかげで、知識量ではなく “伝わりやすい言葉を選べること” が大きな武器となりました !
2. エラー対応で役立った「整理する力」
CI/CDパイプライン構築では、予想外のエラーが何度も発生し、原因も複雑で戸惑うことばかりでした。
そんなときに頼りになったのが ”情報を整理して伝える力” でした。
エラー報告では、
- 背景 : どんな作業中にどんな状況だったか
- 現象 : 実際に何が起きたか
- 試行済み : どんな対応をどこまで試したか
この3つを簡潔にまとめてチームに共有していました。
その結果、状況がすぐに伝わり、問題解決までのスピードもアップしました。
技術的な理解が浅くても、情報整理でチームの動きをスムーズにできた瞬間でした。
3. 資格学習で活きた「まとめる力」
資格取得では、ただ勉強するだけではなく 「どう進めるか」 の戦略が大事だと思っています ! そこで私は、資格取得の学習スケジュールや勉強方法を社内ブログにまとめて公開してきました。
- どの順番で受けるか
- どの教材を使うか
- どこに時間をかけるか
などを文章にすることで、自分の考えも整理することができ、また多くの方に読んでもらうことができました ! 文系ならではの “考え方を構造化して伝える力” が活きた場面でした。
技術面ではスキル不足を感じる瞬間もありますが、文系ならではの強みは多くの場面で役立ちます。
こうした力は、顧客対応でも、チームでの作業でも、学習でも大きな武器になります。
未経験だと、最初から技術力を強みとするのは難しいですが、伝える力・整理する力は最初から強みとして活かせるスキルです。
まとめ
入社してから知識不足による壁に何度もぶつかりましたが、その分「どう伝えるか」「どう整理するか」という自分の強みに気づく時間にもなりました !
コードレビューや見積もりで悩んだ一方、顧客対応やエラー共有、資格学習の戦略づくりでは文系ならではの伝える力が大きな武器になりました。
技術力はもちろんこれから伸ばしていく必要がありますが、文系の強みは最初から現場で価値を発揮できます。
文系出身の私でもエンジニアとして成長できたので、同じように不安を抱えている方も、自分の強みを活かしながら一緒に頑張りましょう !
