はじめに
はじめまして。
SIerで5年ほど働いたあと、体を壊したことをきっかけに事業会社へ転職しました。
そこから気づけば10年以上、いくつかの会社で社内SEとして働いています。
今後も転職することはあるかもしれませんが、やっぱり自分は社内SEタイプだなと思っています。
改めて「社内SEってなんだろう？」というのを、自分なりに整理してみたいと思います。
エンジニアと社内SEのちがい
同じ“システムを扱う仕事”でも、立ち位置は結構違います。
エンジニアは システムの品質にこだわって作って動かす人。
一方、社内SEは 運用が回ることを最優先に考える人です。
品質が高いことは結果的に楽になる要素ではありますが、
品質そのものにこだわりすぎても、現場からすれば「で、何にそんな時間かかってるの？」となることもあります。
つまり、運用を回すためのシステムであり、システムありきの運用ではない。
システムそのものよりも、“どう回すか”に頭を使うのが社内SEの仕事だと思っています。
極論、システムがなくても運用が回るならそれはそれで本望です笑
かくいう私も、システムを作り込むよりも、どうやって運用を回すかを考えるほうが性に合っています。
というか、新卒時点で化物クラスのエンジニアと出会い、「あ、勝てない」と思ってしまったのが原因かもしれません。
そんなこんなで、ときには力技のSQLでデータを直して
「ほら、業務できるね！」ということもしています。
もちろんIT統制はちゃんと守っています笑
納得が大事
社内SEをしていると、
「なんでそんな仕様にしたの？」「もっとこうできないの？」と聞かれることがあります。
自分が続けてきて強く思うのは、理解よりも納得が大事だということです。
業務部門の最前線で働く人たちは、仕組みや技術仕様にそこまで興味があるわけじゃない（と思います）。
興味があれば説明してもいいけれど、大事なのは「なるほど、それなら仕方ないね」と思ってもらえること。
納得してもらってリリースできるならOK、
障害が起きても納得してもらえているなら、ある意味それもOK。
（もちろん、本当は出しちゃいけないけど）
翻訳家としての社内SE
社内SEは、現場の言葉とシステムの言葉を行き来させる翻訳者のような仕事だと思っています。
現場の要望をシステム部門に伝え、
システム側の制約や仕様を現場に返す。
その間で、両者が納得できる落とし所を見つけることが重要で、
どこで落とすべきかの勘所は、ある意味センスを問われるところでもあります。
そして、少しの危機感
……とはいえ、最近ちょっと危機感もあります。
扱うシステムがレガシー寄りで、
JavaScript？ TypeScript？ Ruby on Rails？ Git？ Docker？ K8S？ ナニソレオイシイノ？
状態になってる自分が怖いです。
運用を回すイメージで仕事を進めてきましたが、
「作る世界」には少しずつ置いていかれている感覚があります。
何かの足しにでもなればと思って、Kiro開発を始めてみました。
今後のQiitaでは、そういった内容も少しずつ残していけたらと思います。
まとめ
社内SEは“裏方の裏方”かもしれません。
でも、なんとなく中途半端で何でも屋な立ち位置が嫌いじゃないんだと思います。
システムにこだわらず、現場の納得感を最優先にしながら、
今日も運用を回していこうと思います。