「社内SEの仕事内容って、求人サイトの説明を読んでもいまいちピンと来ない」――そんな気持ちでこの記事にたどり着いた人が多いんじゃないかと思います。
職務内容欄には「社内システムの企画・運用」みたいな文言が並んでいますけど、結局のところ毎日どんな業務をしているのか、どこが楽でどこが大変なのか、そこが見えてこないんですよね。私自身、社内SEへの転職を考えていた頃に同じことで悩みました。
私は前職がSIer（クライアント先のシステム開発を請け負う会社）、前々職も社内SEで、現在は再び中小企業の社内SEとして働いています。社内SE経験は通算で約4年というところです。結論から言うと、社内SEの仕事内容は「開発と問い合わせ対応の同居」が本質で、マルチタスクが苦にならない人にはハマる働き方、集中型の人にはしんどい働き方になりがちです。
この記事ではまず仕事内容の全体像をざっくり整理して、もっと深掘りして読みたいテーマがあれば、それぞれの個別記事へご案内していきます。なお、ここで書くのは中小企業の社内SEの一例です。企業規模や業界で実態は本当に大きく変わるので、その前提で読んでもらえると嬉しいです。
私の社内SEとしての立ち位置
書いている人間の前提を共有しておきます。
私は中小企業の社内SEで、販売管理システムの機能開発と、社内からの問い合わせ対応を担当しています。販売管理システムを使うのは社内の営業・物流・経理などのメンバーで、彼らからの要望や依頼を受けながら、開発と運用の両方を回している、という働き方です。
繰り返しになりますが、これは中小企業勤務の場合の話です。大企業の社内SEだと、もっと役割が分業化されていたりします。同じ「社内SE」という肩書きでも別物だと思ってください。
社内SEの仕事内容｜全体像
中小企業の社内SEが日常的に手を動かしている業務を、ざっくり並べるとこんな感じです。
- 自社システムの機能開発・改修（私の場合は販売管理システム）
- 社内からの問い合わせ対応・トラブルシューティング
- ユーザー権限や商品マスタ・取引先マスタの追加・修正
- システム上では直せないデータの DB（データベース）直接修正
- 月次・年次の定例作業（棚卸対応など）
- 外部ベンダーへの改修依頼・調整
- システム障害の一次対応
要するに、開発（自分でコードを書く仕事）と、運用・問い合わせ対応（社内の困りごとを解消する仕事）の両方を、1人のSEが行ったり来たりしながら回す形です。SIer時代のように「プロジェクト1本に集中して納期まで走り切る」スタイルとは、根本的に動き方が違います。
ちなみに、よくある「PCが繋がらない」「プリンタが動かない」「パスワードを忘れた」といったヘルプデスク系の対応は、私の会社では発生しません。ここは会社によって本当にバラバラで、社内SEがヘルプデスクも兼ねている職場もあります。求人を見るときに必ず確認したいポイントの一つです。
社内SEの1日｜割り込みと開発の同居
1日の流れもざっくり書いておきます。
朝はまず、その日のタスク一覧化とメール・チャット確認から入ります。日中はそこから自分の開発タスクを進めていきますが、社内からの問い合わせや作業依頼が割り込みで入ってくるので、一日中コードに集中できる日はそれほど多くありません。
機能開発と問い合わせ対応の比率は日によってまちまちで、問い合わせがほぼゼロで開発に集中できる日もあれば、半日以上が問い合わせ対応で潰れる日もあります。残業は通常月で月10時間以内に収まっていますが、システム入れ替えなどの節目では一時的に忙しくなります。
時刻ベースのタイムスケジュールや、割り込みが入ったときの動き方を具体的に知りたい方は、こちらの記事で詳しく書いています。
「楽すぎ」と言われる実態
社内SEは「楽すぎ」「天国」みたいなラベルで語られることが多いですが、私の感覚としては、楽な部分と楽じゃない部分がはっきり分かれています。
楽だと感じるのは、上司・同僚・職場が固定されることや、外部のクライアントに比べて納期プレッシャーが軽いこと、残業が少ないことです。SIer時代の客先常駐と比べると、メンタル面の安定感はかなり違います。
一方で楽じゃないのが、問い合わせの多さとマルチタスクの常態化です。1つのタスクに集中したいタイプにとって、頭の中で組み立てた処理の論理が問い合わせ1つで吹き飛ぶのは地味にしんどい瞬間で、「楽すぎ」というラベルは業務スタイルとの相性次第で体感がまるで違います。
業務シーンごとに「どこが楽でどこが楽じゃないか」を切り分けたい方は、こちらでより細かく書いています。
入社前後のギャップ｜後悔ポイントの概要
実際に働いて、入社前のイメージとのギャップが大きかったポイントは次のあたりです。
- 自社開発の比率が想定よりずっと高かった（ベンダー管理寄りで動けると思っていたら、自分がコードを書く側だった）
- 問い合わせ対応の量が想像以上に多く、開発に集中できる時間が短い
- 業務の都合上、休日に稼働する場面がある
- 最新技術（クラウド・生成AIなど）を仕事の中で扱う機会が少ない
どれも、求人票や面接の表面的なやり取りだけだとなかなか見えてこない部分です。私は「ベンダーに開発を依頼して進捗を管理する立場」をイメージして入社したので、自社開発比率の高さは個人的に小さくない後悔ポイントでした。
5つのギャップとして、入社前にどう確認しておけば防げたか・どんなタイプが特に後悔しやすいかまで踏み込んだ話は、こちらで詳しく書いています。
向いている人・やめておいた方がいい人
ここまでの仕事内容を踏まえて、ざっくり向き不向きを整理するとこんな感じです。
向いていそうな人:
- マルチタスクが平気で、問い合わせ対応と開発の同居が苦にならない
- レガシー寄りの技術スタックでも気にならない
- 安定した環境で長く働きたい
やめておいた方がいい人:
- 1つのタスクに集中して没頭したい
- 仕事の中で最新技術を扱いたい
- 顧客との緊張感ある仕事の方が燃えるタイプ
ただ、上の整理だけで判断するのは少し危ういです。「向いてないかも」と感じる5タイプを、それぞれ業務エピソードと自己診断ポイント付きで掘り下げた記事があるので、本気で転職を検討している方はこちらに目を通してから決めることをおすすめします。
まとめ｜社内SEは「条件が合えば」悪くない選択肢
最後にまとめます。
社内SEの仕事内容は、自社システムの開発と社内からの問い合わせ対応を行ったり来たりする働き方が中心です。マルチタスクが平気でレガシー寄りの開発も気にならない人にとっては、SIerと比べて環境は安定していて、外圧プレッシャーも少ないので悪くない選択肢だと思います。
逆に、集中型で1つのタスクに没頭したい人や、先端技術を仕事で扱いたい人には向きません。「楽すぎ」「勝ち組」というラベルだけで決めると、自分の業務スタイルとミスマッチして後悔する可能性があります。
そして冒頭でも触れた通り、企業規模や業界によって、同じ社内SEでも実態は大きく変わります。今回の話はあくまで中小企業勤務の私の一例です。求人を見るときは、ラベルではなく現場感（休日出勤・残業・問い合わせ量・技術スタック）でチェックしてみてください。それだけで、入社後のギャップはかなり減らせるはずです。
各論をさらに深掘りしたい方は、関連する4本の記事もあわせて読んでみてください。
コメント