SIerとは
IT業界の中でも、顧客企業の課題を分析するとともに、それを解決するようなシステム開発を企画から運用まで執り行う業界のことを指します。
多くの顧客企業は、「IT化を進めたいけど、どうすれば良いかわからない」という曖昧な課題感でSIerに依頼します。
SIerは顧客企業に真摯に向き合いながら、一緒に課題を発見していきます。
そして、業務を効率化したり、企業のサービスに付加価値を与えたりするようなシステムを一から開発することで、課題解決に貢献します。
IT業界の他の分類（ソフトウェア、ハードウェア、Webなど）との違いを知りたい場合は、こちらのサイトがおすすめです。
SIerの職種は、大きく分けて営業とSEに分類されます（企業によっては別にコンサルがいたり、SEしかいなかったりします）。
顧客の課題把握を担当してざっくりとシステムの方向性を定めるのが営業で、システムの中身を詰めるのがSEというイメージです。
企業によって異なりますが、システム開発におけるコーディングは協力会社に委託するケースが多いです。
そのため、SEはシステムの設計だけでなく、協力会社の進捗を管理する必要があります。
入社して数年すると、システム開発プロジェクトをリーダーとして引っ張っていく立場になります。
開発体制や規模は、所属部署やその上司、プロジェクトの内容に大きく依存します（いわゆる配属ガチャというものです）。
プロジェクトによっては、SIerの社員が1人で協力会社の進捗を管理したり顧客企業を相手したりすることもあります。
SE志望であっても、入社時にはITスキルの有無は問われません。
入社から数ヶ月の間の研修で、ITの知識や最低限のプログラミングスキルを身につけます。
プログラミング経験のない理系学生はもちろん、文系学生でも入社することができます。
SIerの雰囲気
在宅勤務がしやすい業界として知られています。
ただし、顧客次第では（特に法人など）客先常駐をしたり、打ち合わせをしたりする関係で、出社している顧客に合わせて在宅ができないケースもあるようです。
社内外の関係者との密な報告・連絡・相談をしながらプロジェクトを進めていきます。
チャットツールでの議論に留まらず、会議に参加する時間が意外と長いです。
多人数のチームで一緒に仕事をするため、どの企業でも協調性が強く求められます。
入社してすぐの研修では同期で関わる機会が多いため、期間中はほぼ毎日飲み会に行くこともあるとか。
様々な社員の方から、研修期間後も同期間の繋がりが続いているというお話をよく聞きますね。
ちなみに、選考の場においても異常なほどに協調性が重視されます。
GDでは正直なところ、MECEなどのフレームワークを意識して論理的に議論を進めたり、クリティカルな意見を出したりする必要はありません。
そのような姿勢よりかは、「メンバーをいかに否定せずに、終始笑顔で議論を結論まで持っていくか」が大切です。
明らかに間違っている意見を話している人がいたとしても、その人を一旦肯定した上で、補足する形で意見を述べると良いでしょう。
また、私が某SIerの二次面接を受けた際には、FBで「挫折経験はチームで取り組んだことを話してください」と言われました。
ESでも別途チームのガクチカが求められたので、実際に働く様子を明確にイメージさせるためには誰かと一緒に取り組んだエピソードが肝になるようです。
SIerを選んだきっかけ・理由
お世話になっていたメンターさんのアドバイスがきっかけでした。
就活当初は他の業界を志望していたのですが、その業界一本で戦うリスクの高さから、SIerをおすすめされました。
Twitterで優遇があると見た夏ISにいくつか申し込み、参加しました。
実は当時、志望業界とのミスマッチが起きていて絶望していたんです（私の自己紹介記事参照）。
夏ISに参加した際に、SIerの仕事内容が苦にならないことに気付いて志望を変えました。
私自身、0から1を生み出すよりも、1を10にする方が好きでして……
ある程度方向性が定められたシステムを具体化するSIerのSEは、私が好きなことそのものでした。
さらに、志望業界の性質上諦めていた、首都圏勤務も（企業によっては）叶えられるとわかって、SIerに対する関心がさらに高まりました。
業界研究・企業研究のやり方
選考対策（というか面接で話せる志望動機の形成）のために企業理解を深めていただけで、業界研究はそれほどしていませんでした……
志望度は首都圏勤務がどれくらい叶うかと、社員の雰囲気で決めてしまいました。
何をやるか以上に誰とやるかを大事にしているので、決め手はほぼ直感でした。
夏ISでほぼ決め切った上で、OB訪問を通じて懸念点を質問することで解消していました。
企業の志望動機を作るにあたっては、その企業で「自分がやりたいこと」を先に見つけるようにしました。
正確に言うと、「何かしらの原体験を準備して、自分のやりたいこととして話せそうな事業内容」ですね。
まず、企業の事例（例：富士通）をざっと眺めて、これなら話せる体験談がある！というものをいくつかピックアップします。
エピソードは熱量を持って話せることであれば何でもよくて、ガクチカや研究でなくてもOKです（私は趣味の話をしていました）。
次に、事例を参考にしながら、ITを駆使してその企業で解決できそうな課題を見つけます。
最後に、それらを以下のようなフローで再構成すれば、志望動機の完成です。
- ITで解決したい課題を述べる
- 解決したい理由を述べる
- （必要であれば）解決手段がITである理由を述べる
- 事例を引用して、その企業でなければ解決できないことを示す
事例を引用する段階で、他社で似た事例がないか調べることで独自性を確認していました。
ただ、このような話し方をしてしまうと、「配属希望が通らなければ弊社に行きたくないということか？」と質問されてしまいます。
中期経営計画などのIR資料を見たり、OB訪問をしたりして、企業理念や開発体制の独自性などで他社と差別化しましょう。
コメント