社内SEの仕事内容と転職時の注意事項【楽なのに不幸】

社内SE歴（社内システムの企画・運用部署）5年くらいの私がお答えします。
結論、仕事は楽です。でも幸せとは限りません。
その理由も記事で書きます。配属希望を出す前の自分に伝えたい。

仕事内容

大きく社内ITインフラ・社内システムの「企画・構築」と「運用・保守・ユーザのサポート」業務があります。綺麗な言い方をすると、会社のIT戦略を企画から実行まで担うわけですが、要は社内のITリソースを用意し、その後の面倒もみるITに特化した総務みたいなものです。

企画・構築

例えば社内システムを企画する場合、現状の業務や新しいシステム対するニーズを社員にヒアリングし、分析の上、改善に繋がるコンセプトを作り上げます。

システム開発をすることになれば、開発会社への発注手続きをするし、自社開発の場合は自らプログラミングすることもあるでしょう。

システムが完成したら、システムの操作マニュアルを作ることや、システムを使う社員への説明会を企画し、また説明会の講師になることもあります。

運用・保守・ユーザのサポート

システムの利用がスタートしたら、システムに異常が起きてないか監視したり、システムを使う社員からの問い合わせに対応したりします。

異常が起きた場合は、原因を究明し対策を講じます。場合によってはシステム運用会社と連携して問題を解決します。

楽ですか？

結論、労働時間と仕事の難易度の観点から、通常のSEと比較すると楽だと言えるでしょう。

労働時間

昨今の働き方改革による残業規制により、無茶な働き方を求められるケースはあまりありません。そもそも、社外から利益をもたらす営業のような部門と異なり、社内SEは利益をもたらさないコストセンターと言われる部署です。したがって、如何に効率的に、労働時間を抑えるかが会社に対する貢献になるとされます。そうした背景から、残業時間は通常のSEと比較しても明らかに短い傾向があります。
「今日やらないといけないことだけやれば良い」という教えが、社内SEから転職した後も私の中に根付いています笑。

仕事の難易度

通常のSEと比較すると、仕事は易しいと思います。他部署から異動してきたSEが「これで（仕事が）まわるって、外に出てる部署が聞いたら怒られるよ笑」と驚いていたことが印象的です笑。

理由はお客様（ユーザー）が社内の人間だからです。例えばコミュニケーションひとつとっても、かかるストレスは大きく違います。上司に送るメールより家族に送るメールのほうが圧倒的に楽なのと同じです。

最悪、問題（納期遅延、システム障害）が起きても、迷惑を被るのは自社です。これが他社だと売上に響いたり、会社のイメージ低下に繋がります。だからといって問題を起こして良いというわけでは決してありませんが、切羽詰まった状況において、この差は結構大きいです。

幸せですか？

私が社内SEをしていたときは、仕事は楽なのに満足できないという少し不思議な状態でした。また、私の周り、先輩・後輩・上司を見ても、不満そうに働いている人がまあまあいました。

それはなぜか。仕事のやりがいを感じることが難しい職場だからです。ここで言うやりがいは「感謝の言葉をもらうこと、仕事が認められること」「自分の成長を実感できること」の2点です。

感謝の言葉をもらうこと、仕事が認められること

「企画・構築時」と「運用・保守・ユーザのサポート」に分けて説明します。

企画・構築時

新しくシステムを導入した場合、基本的にユーザーの業務は導入前と変わることになります。もちろんシステム導入するからには、これまでの業務がより効率化される、システムに入ったデータから新しい知見がもたらされる、など会社としてメリットがある（と判断された）はずです。

しかし、現場のユーザーは、忙しい業務の合間、新しいシステムの使い方を覚えないといけません。これまで慣れたプロセスを変えることで、反発が少なからず生じます。
ユーザーによっては、「余計なシステムを作って仕事が複雑になった」と捉えられてしまう場合もあります。

「このシステムが導入されて良かった」という言葉は中々聞けるものではありません。

運用・保守・ユーザのサポート

パソコンが立ち上がる、インターネットに繋がる、メールが送れる、残業申請ができる、休暇の申請ができる…、これらは会社で働く上で当たり前のことですよね？

社内SEに連絡がくるのは、この当たり前が崩れたときです。「インターネットに繋がらない」「申請するとエラーになる」「システムにログインできない」など。
つまり、ユーザーとのコミュニケーションはマイナスをゼロに戻すところなので、あまり感謝をされる機会がありません。

自分の成長を実感できること

他社に対してシステム開発をしているSEは、プロジェクト単位で仕事をします。つまり、顧客企業が新しくシステムを入れ替える、改修するといったタイミングでプロジェクトを起こし、納品と共に次のプロジェクトに移ります。

一方社内SEの場合、そうしたシステム導入が終われば、システムの運用・保守のフェーズに移ります。

この違いが成長（市場価値向上）速度に差をもたらします。

他社に対してシステム開発をしているSEの利点は以下の通りです。

• SEとして成長するための最高の機会であるプロジェクト経験を多く積める
  （最新の技術と、プロジェクトマネジメントの現場を経験できる）
• プロジェクト単位で仕事をするため、様々な企業の事例が自らに蓄積される
• 他のベンダと協力する機会も多いため、多様なSEから仕事の進め方、考え方、業界の事情など大いに刺激を受けることができる

私が社内SEをしていた頃は「同世代の他社SEってどれくらいデキるんだろう」とか、「このやり方って他社ではどうやっているんだろう」といった疑問をもつことがよくありました。基本的に自社の中で溜まったノウハウをベースに仕事を進めるため、大きな変化を感じにくいんですよね。そのため、ある程度仕事になれた段階で、成長の実感が減っていきました。

おわりに

正直に話すと、社内SEは、新卒、ないし若手の段階で就くべきではないと感じています。新人時代というのは丁寧に仕事を教えてもらえる開幕ボーナス期間です。この期間は可能な限り多くのことを吸収することが、努力コスパ的によろしいです。

ただし、社内SEに就いたとしても、必ずしも成長できないというわけではありません。成長できるポジションを探して志願する、資格に手を出す、副業をやってみる、など、打開策はあります。今、新人の自分にアドバイスをするとしたら、「要件定義に参加すること」「ベンダー系の資格をとりまくること」「実装を進んで行うこと」「実装に強い先輩と仲良くしておくこと」ですかね。この辺はまた別途記事を書こうと思います。