SEの業務経験は活かせる？私が社内SEに転職して役立ったSE時代のスキルとは

SIerのSE（システムエンジニア）から社内SEへの転職はワークラインバランス、働きやすさなどの理由から目指される方が多く人気職種となっています。実際のところ、内定をもらい転職してもうまくやっていけるか不安に思われる方もいると思います。

私も今の会社へ入社した当初は知名度もある大企業であったことから不安もありましたが、これからお伝えする転職前のシステムエンジニア時代の経験があったため、社内でも重宝されていると感じています。そんな私がSE時代に培った経験として社内SEになっても活きるスキルをお伝えしたいと思います。

些細なことでも意外と社内SEになっても役に立つことがあると思っています。私の経験で言えばExcelの関数でも活かせることが多々ありました。ホントこんなことで！と驚いたことがあるくらいです。

私が感じるシステムエンジニア時代の最も活きる経験はシステムエンジニアという忙しい職種で業務を過ごし続けてきた経験だと思います。私はプライベートもある程度犠牲にして働いてきた経験は効率的に業務をこなすための財産であったと振り返って思っています。私の場合は終電を逃し、深夜バスのバス停でコンビニで買ったおにぎりなどの夜ご飯を片手に帰るようなこともありました。笑

そのような忙しさでなんとか早く終わらせなきゃと悩みながら、身につけた経験が今回の記事に載せた技術・スキルであり、お伝えしようと思います。

この記事を見ると以下のことがわかります。

自己紹介

社内SEとは（SIerとの違い）

社内SEとは、企業のIT部門（情報システム部門など呼び方は様々）に所属する社員のことを言い、ITツールなどを導入し社内業務の効率化やコミュニケーションの活性化など、社内のIT利活用を促進することがミッションとなります。

一方、SE（システムエンジニア）とは、IT企業に属するエンジニアであり、クライアント（顧客）企業より受注したシステムやサーバーなどのハードウェアを構築、または保守運用などを担うエンジニアを言います。

社内SEは発注側、システムエンジニアは受注側となり、顧客と業者の関係になります。

SIer企業のシステムエンジニアはアサインされたプロジェクトのメンバーとして、システム開発における要件定義、設計、開発、運用保守など、発注者（社内SE）から委託された業務を担います。基本的にはプロジェクトの終了やプロジェクトからのリリースなどにより担当したプロジェクトを離れ、別プロジェクトで業務をします。プロジェクトによって担当する役割やクライアント、必要な技術も変わってきます。

一方社内SEは企業のシステム担当となり、クライアントが所属する企業の同僚となりクライアントは変わりません。担当したシステムにおいても導入から、運用保守までのサイクル全体を受け持つことになるため、1つのシステムに対して長きにわたって関わっていくことになります。

SIerのSEと社内SEでは上記の様に役割が異なりますが、SEの経験を活かすことが十分に可能です。私も転職した当初は不安もありましたが、SE時代に培ったスキルを活かせる場が多分にあります。
（もちろんSEとは業務内容が異なるので、考え方を改めなければならないこともあります。）

SE時代の経験が活きたスキル

コミュニケーション

社内SEになると、プロジェクトマネージメントが中心となるため社内調整や業務ユーザとの要件調整など調整業務が大半となります。また、システム構築の際にはベンダーとも要件定義、開発など各工程での諸調整も行うため、社内外とのコミュニケーションが重要となります。

社内SEのおけるコミュニケーションはSEと比べて全く異なるものではなく、SE時代の経験を活かすことが可能だと私は思います。SEの方であれば、システムの要件定義や設計作業を進める時に要検討事項などの調整でユーザと会話することがあると思いまし、私もそのような経験をしてきました。基本的にはその要領で進めれば問題ないと思いますし、人に説明する場数は圧倒的にSE時代の方が踏んでいますので、説明する力は確実についていると思っています。

私の意見ですが、システムエンジニア時代はきちっと要件決めなきゃあとでとても大変になるのが見えているので、決めること、勝ち取ることを明確にして臨んだ経験があって効率的なコミュニケーションが取れているのだと思っています。

社内SEになって感じることではありますが、専門的な用語を使うSEさんをたまにお見かけするので、システムのことを全く知らない方を意識した会話ができれば、完璧だと私は思います。

プログラミングスキル

社内SEになるとプログラミングをする機会はほとんどなくなってしまうものの、ソースコードを書かないローコード開発などを社内で行う場合は、プログラミングスキルを活かすことができます。

例えば、最近流行りのRPAを例にすると実現したいことをロジックに分割したり、条件によって処理を変えたりなどして処理全体を作成していく必要があります。基本的にロジックの組み立て方は言語に大きく依存しないことだと思いますので、開発する際には今までの経験を生かして作成することが可能だと思います。

私もRPAの導入に関わったことがあるのですが、パッケージ選定の際に現行業務で行なっているRPAの処理と同様のものを作成し、効果検証を行なったのもSE時代の経験があったからだと思っています。

また、プログラミングスキルがあればベンダーの見積もりの妥当性判断ができたりするので、かなり重宝されるのではないかと思います。

資料作成やデータ集計

社内SEになって、資料の精度は圧倒的にSEやITコンサルの方が高いと感じました。入社したての頃はPower Pointの技やExcelの関数などドキュメント作成について色々聞かれました。

SEからの転職を経ずずっとプロパーで社内SEをされている方のPower Point資料を見ますが、お世辞にも見やすい資料ではないなと思うことがあります。文字だけの資料とか、オブジェクトの形、大きさがバラバラなどで見にくい資料などなど。

他にはExcelの関数やピボットテーブルでの集計もできない方も事業会社にはいらっしゃいます。Excelでの集計など加工方法についてはGoogle検索である程度調べれば可能であるのですが、調べ方がわからないのだと思われます。

私の所感になってしまいますが、ドキュメント作成やデータ集計などの作業に関しては圧倒的にSEの方が出来が良いことが多いので、仮に社内SEに転職してもかなり有効なスキルとして活用できると思います。

納期や期日に対するコミットメント

事業会社の社員（社内SE含む）の中には納期に対するコミットメントが圧倒的に低い方がいます。もちろん全員ではありませんが、いるのが事実です。私も調整事項があって社内の業務ユーザに宿題として依頼してもなかなか進まないことがあり、納期に対する考え方の違いに戸惑いながら業務をしています。

SIerやコンサル会社の方は基本的にはプロジェクトのWBSに沿って、担当タスクをこなすことが求められますので、納期までにどの様に対応するかを考え、タスクを進めていくことになると思います。

事業会社の社内SEであれば調整先が社内の人間であるため納期調整がSEと比べ容易であることから、安易に納期を先延ばしにする方もいます。止むを得ない事情であれば良いのですが、やればできる、間に合う範囲であれば間に合わせるべきだと思います。

納期や期日に向けた仕事の段取りについてはSIerやコンサル会社の方が圧倒的に優れていますので、社内SEに転職したとしても有効だと思います。

他にも

中途採用の背景によると思いますが、採用要件に自身の経験が完全にマッチしているのであれば、そのスキルも多いに活用することが可能です。

私が転職した時はERPパッケージの開発、運用保守経験が必要とされていましたので、入社後もERP関連のプロジェクトに配属されたことから、前職の知識はかなり活用することができました。

他にも、インフラやセキュリティなど他の領域においてもSE時代の専門知識や経験を活かす場はもちろんあると思います。

結論：SE時代の経験は社内SEになっても活きる！

発注側と受注側という違いはありますが、社内SEになっても私は前職までの経験は大いに活かせていると感じています。立場の違いこそありますが、過去のシステム開発や運用保守の経験をベースにして業務を進めています。

逆に過去のSE経験があったからこそ社内でも重宝されているスキルもありますので、SE→社内SEへの転職に関しても大きなギャップを生むことはないのではないかと思います。