社内SE（情シス）の1日を公開｜「楽」も「大変」もリアルに語る

「社内SEって楽そう」「情シスは暇って聞くけど本当?」——転職先の候補に挙がっているけど、実態が分からなくて不安、という方も多いんじゃないでしょうか。私自身、転職活動中に同じことを何度も検索しました。

この記事では、引っ越し業から社内SEに転職して3年目の私が、ある1日のスケジュールと、楽な面・意外にしんどい面を正直に書いています。盛らずに、できるだけそのままの働き方をお伝えします。

「社内SE 楽」「情シス 暇」で検索したことがある人へ

「楽そう」「暇らしい」——社内SEや情シスを調べていると、よくこの言葉に出会います。実際にそう書かれている記事も多いですし、検索キーワードの候補にも並びます。

ただ、いざ転職を考える側になると、「本当のところどうなんだろう」と気になりませんか。私もそうでした。仕事内容のイメージが湧かないまま転職を決めるのは、正直怖かったです。

私は今、フレックス勤務の社内SEとして働いています。コアタイムなしで、定時は9時〜18時。日によって出社や退勤の時間を前後させながら働いています。今回は、その立場から見える「楽」と「大変」を、できるだけそのまま書いてみようと思います。

今の仕事に就くまでの経緯が気になる方は先にこちらも読んでみてください。

私の1日のスケジュール ── ある日の流れを公開

まずは、特別忙しくも暇でもない、わりと普通の日の流れを紹介します。コアタイムなしのフレックスですが、わかりやすさのために、ここでは標準的な9〜18時の日を例にしています。

• 9:00　出社、メールチェック
• 9:30　打合せ（プロジェクトの進捗確認など）
• 10:30　開発作業
• 13:00　昼休憩
• 14:00　打合せ（依頼元の部署とのヒアリングなど）
• 15:00　開発作業
• 16:00　ちょっと休憩、部内で雑談
• 16:30　開発作業の続き
• 18:00　退勤

ざっくり書くとこんな感じです。ただ、毎日この通りに進むかというとそうでもありません。打合せが1件もない日もあれば、システムトラブルが発生して半日その対応に追われる日もあります。

部内の人とたわいもない会話をしている時間も、思っているより普通にあります。飲み物を淹れに給湯室に行ったついでに、最近の案件の話をしたり、ちょっとした技術的な話をしたり。雰囲気としては、それほど張りつめていない方だと思います。

「開発」と一口に言ってもやっていることは様々

スケジュールの中に「開発」と書きましたが、これがコードを書いている時間ばかりかというと、そうでもありません。

実際にやっているのは、要件の調査、設計、コーディング、テスト、依頼元への確認など、けっこう幅があります。むしろコードを書いている時間は、全体の半分もないことが多いです。

それともう一つ、社内SEの開発は「ゼロから新しいものを作る」ケースが少ないと感じています。会社で使っているシステムは一通り揃っていて、発注の機能や納品書の機能はすでにある。新しい依頼が来ても、近いものを踏襲して必要なところだけ改修する、という進め方が多いです。

正直、暇な日はあるのか

これは正直に書きますが、あります。

案件が落ち着いている時期は、急ぎでやらなければいけないことがほぼない日もあります。そういう日は、業務を改善するツールを自作してみたり、新しい技術の勉強をしたり、たまっていたドキュメントを整理したりして過ごしています。

ただ、ずっと暇なわけではなく、波があります。システム開発の依頼が立て続けに入る時期や、PC入替のような単発だけど準備の多い案件があるときは、それなりに忙しくなります。

残業時間でいうと、通常の月は10〜20時間ほどに収まることが多いです。過去には45時間近くまで増えた月もありましたが、それは本当に例外で、ほぼ起こらないと言っていいくらいです。

社内SEが「楽」だと感じる部分と、意外にしんどい部分

ここからは、現役で働きながら感じている楽な面・大変な面を、両方とも書いてみます。

楽だと感じること

売上ノルマや営業的なプレッシャーがないのは、やはり大きいです。SIerだとシステムそのものが商品になりますが、社内SEはあくまで社内の業務を支える側。基幹システムが止まれば一大事ではあるものの、安定稼働しているシステムが突然全部止まることはそうそうありません。「商品として開発し続ける」ような緊張感は、かなり少ない方だと思います。

相手にするのが基本的に社内の人だけ、というのも気持ちの面で楽です。一度円滑なコミュニケーションが取れる関係を作ってしまえば、そこから先はかなりやりやすくなります。ただ、最初の関係づくりに苦労した人にはきつい面もあるかもしれません。

開発がゼロベースになりにくい点も大きいです。先ほど書いたように、すでにあるものを踏襲しつつ改修するスタイルなので、案件ごとの労力は思ったより少なめで済みます。

「最新技術を追いかけなくていいのが楽」という声を見たことがあります。たしかにその面はありますが、私としては、これは楽というよりエンジニアとしては危ういラインだと感じています。社内SEでも、最新の情報を集めて学び続けないと、外に出られなくなる感覚は正直あります。

意外に大変なこと

外から見えにくい大変な部分もあります。

まず、ヒアリング力がかなり求められます。依頼元の部署が「こんな感じにしたい」と曖昧に話してくることも多く、本当の要望を引き出してシステムに落とす作業は、コーディング以上に頭を使います。

例えば、「前に作ってもらったあの感じで、ちょっと別のやつ作れない?」というような依頼があります。依頼する側は、自分の頭の中にイメージはあるけれど、それをシステムの形として言語化できていないんです。これをヒアリングせずに受けてしまうと、出来上がったときに「こういうのが欲しかったんじゃないんだけどな…」となり、最悪の場合は作り直しです。だからこそ、最初に「どんな場面で使いたいのか」「なぜそれが必要なのか」を、こちらから丁寧に聞いていく必要があります。社内SEのコミュニケーションについてはこちらの記事でも詳しく書いています。

ドキュメントが残っていない問題も根が深いです。以前、トラブル対応で急ぎの修正が必要になったとき、プログラムを確認していくと「なぜこういう処理にしているのか」が分からない箇所が出てきました。開発時の設計資料を探しても、そもそもドキュメント自体が残っていない。結局、コードを一つずつ読み解きながら対応するしかなく、想定以上に時間がかかりました。歴史のある会社ほど、こういう問題は根が深い気がします。

「動いて当然」という文化も、地味にこたえる部分です。システムが安定して動いていることがゴールなので、ちゃんと動かしても評価されにくい傾向はあります。経営層にIT理解がないと、なおさらです。

トラブル発生時のしんどさも書いておきます。社内SEは基本的に自分たちしか頼れないので、原因が分からないトラブルが起きると、孤独感も含めて本当にきついです。

それから、これは会社によりますが、できる人とできない人で業務量に差が出やすい構造もあります。スキルがある人ほど依頼が集中し、結果として負担が偏る——現場のリアルとして感じている部分です。

「楽」か「大変」かは、結局なにを求めるかで変わる

ここまで書いてきたとおり、社内SEは楽な面も大変な面もどちらも本当です。どちらが大きく感じるかは、その人がキャリアに何を求めているかで変わってくると思います。

体感ベースですが、自分のペースで腰を据えて働きたい人や、ノルマや営業のプレッシャーから離れたい人には合いやすい働き方かもしれません。逆に、最先端の技術に触れ続けたい人や、頑張った分だけ評価や給与に跳ね返ってほしい人には、物足りなさを感じる場面が出てくる気がします。

私自身は、満足している部分もある一方で、技術や評価の面で天井を感じることもあります。だから「社内SE=楽でおすすめ」と一方的に言うのは違うかな、というのが今の率直な気持ちです。

この『天井』の感覚は、放っておくとじわじわ閉塞感に変わっていきます。私それを感じた時期のことは社内SEとして閉塞感を感じたときの話に書きましたので良ければ一緒に読んでみてください。

社内SEを検討している方が、この記事を読んで「自分の場合はどうかな」と考えるきっかけになればと思います。