「調整ばかりでスキルがない」と感じている社内SEへ
社内SEや情シスの仕事をしていると、ふと不安になる瞬間があります。
一日中、問い合わせ対応をして、会議に出て、現場とベンダーの間に入り、障害対応の連絡をしていた。
忙しかったはずなのに、終業後に思う。
「あれ、今日の自分って、何のスキルを積んだんだろう」
コードを書いたわけでもない。
サーバーを深く触ったわけでもない。
設計書をゼロから作ったわけでもない。
そういう日が続くと、「自分は本当にIT職として成長できているのかな」と不安になることがあります。
自分も、高卒で社会人になり、最初はITとは別の仕事をしていました。
その後、人事異動を経て社内SEを経験し、今はSIerで運用保守をしています。
社内SE時代は、自社開発でバリバリ手を動かすというより、外注先とのやり取りや社内調整が多い環境でした。
だから、「このままで大丈夫なのかな」という不安は、かなり身近なもので私も感じていました。
資格を取れば少し安心できるかもしれない。
でも、資格を取っても不安が消えきるわけではない。
そんな感覚がありました。
今回の記事ではこの調整ばかりでスキルが身についていない不安感との向き合い方を紹介していきます。
調整業務の中には「翻訳」がある
ITのスキルというと、どうしても
「自分で構築できる」
「自分でコードを書ける」
「自分で障害原因を突き止められる」
みたいなものを想像しがちです。
もちろん、それは大事です。
技術を軽く見ていいとは思いません。
ただ、社内SEの仕事はそれだけでは回りません。
社内SEは、技術と現場の間に立つことが多い仕事です。
現場の人は、必ずしもITの言葉で困りごとを説明してくれるわけではありません。
「なんか遅い」
「前みたいにできない」
「この作業、毎回めんどくさい」
「システムのせいで仕事が止まる」
そういう言葉の中から、何が本当の問題なのかを拾う必要があります。
一方で、ベンダーや外注先には、現場の状況をある程度整理して伝えないといけません。
現場の不満をそのまま投げるだけでは、相手も動きにくい。
逆に、ベンダーの回答をそのまま現場に返すだけでも、現場には伝わらないことがあります。
ここで必要になるのは、ただの伝言ではなく、翻訳に近い仕事です。
技術の言葉を現場の言葉にする。
現場の困りごとを、技術側が判断できる形にする。
ベンダーの回答を、利用部門が納得しやすい言葉にする。
これは、画面上でコードを書くような仕事ではないかもしれません。
でも、システムを会社の中で使い続けるためには、かなり大事な仕事だと思っています。
調整業務の中には「課題整理」がある
もちろん、ただ言われたことを右から左に流すだけだと、スキルとして残りにくい面はあります。
「現場から問い合わせが来たので、ベンダーに確認しました」
「ベンダーから回答が来たので、現場に伝えました」
これだけだと、自分の介在価値が見えにくいです。
私も社内SEなりたての頃、間に入りすぎてただの伝書鳩状態で仕事をしていて、自分に価値を感じない時がありました。
「で、何がしたいの？」
と聞かれると答えが出せずに困ってしまうことも多々ありました。
でも同じ問い合わせ対応でも、少し見方を変えると違ってきます。
自分はどう思うのかを伝えて最適な方向に進める。
たとえば、問い合わせ内容を分類する。
よくある質問をまとめる。
現場ごとにバラバラだった依頼の出し方を整理する。
ベンダーへの確認事項を事前にまとめて、やり取りの往復を減らす。
会議で曖昧だった論点を整理し、次に誰が何をするかを決める。
こういうものは、全部「課題整理」に近い仕事です。
最初から立派な成果でなくてもいいと思います。
売上を何億円上げたとか、システムをゼロから刷新したとか、そういう話ばかりが実績ではありません。
日々の仕事の中で、誰かの困りごとを少し整理した。
無駄なやり取りを少し減らした。
判断しやすい状態を作った。
止まっていた話を前に進めた。
それも、社内SEとしての大事な仕事です。
調整業務の中には「合意形成」がある
社内SEの仕事では、技術的に正しそうな答えがあっても、それだけでは進まないことがあります。
利用部門の事情がある。
予算の都合がある。
ベンダー側の工数がある。
上司の判断が必要なこともある。
現場ごとに優先したいことが違う場合もある。
その中で、誰か一人の希望だけを通すのではなく、関係者が動ける形に整えていく。
これも、地味ですが大事な仕事です。
「会議に出ていただけ」と感じる日もあるかもしれません。
でも、その会議で論点を整理したなら。
次の担当者を決めたなら。
現場とベンダーの認識違いを見つけたなら。
止まっていた依頼を前に進めたなら。
それは、ただ座っていただけではありません。
調整業務は、何もしていない仕事ではありません。
ただし、黙っていても評価される仕事でもありません。
ここが少し難しいところです。
ただし、そのままだと伝わりにくい
調整業務は、その場が終わると消えやすい仕事です。
障害が復旧した。
問い合わせが解決した。
会議で方針が決まった。
ベンダーとのやり取りが終わった。
その瞬間は確かに大変だったのに、あとから振り返ると「いつもの対応」で終わってしまうことがあります。
職務経歴書を書こうとしたときにも、手が止まりやすいです。
「何を書けばいいんだろう」
「結局、自分は何をしたんだろう」
「調整と問い合わせ対応しかない」
そう感じてしまう。
でも、それは価値がなかったという意味ではありません。
価値がなかったのではなく、言葉になっていなかっただけかもしれません。
大事なのは、何を調整したのか。
どんな課題を整理したのか。
誰と誰の間に入り、どんな状態まで進めたのか。
その結果、現場やシステム運用がどう変わったのか。
ここまで分解して、ようやく「経験」として伝わりやすくなります。
まずは3つだけメモしておく
いきなり職務経歴書を書こうとすると、けっこう大変です。
なので、最初は日々の仕事を少しだけメモしておくくらいでいいと思います。
見るポイントは、まず3つで十分です。
誰の困りごとだったか
自分が何を整理、判断、調整したか
結果として何が少し良くなったか
たとえば、問い合わせ対応をした日なら、ただ「問い合わせ対応」と書かない。
「利用部門から申請画面の入力方法について相談。よくある誤入力を確認し、暫定対応として手順書に注意点を追記した」
このくらいでも、あとから見返すとかなり違います。
もちろん、毎日きれいに書かなくて大丈夫です。
まずは週に1回でもいいと思います。
「今週、自分は何を受け止めて、何を整理して、どこまで前に進めたのか」
それを少しだけ残しておく。
その積み重ねが、あとから自分の仕事を説明する材料になります。
最後に
「調整ばかりでスキルがない」と感じるのは、かなり自然なことだと思います。
手を動かしている実感が少ない。
技術職として置いていかれている気がする。
外注先の方が詳しくて、自分は間に立っているだけに思える。
そういう不安は、社内SEや情シスの仕事をしていると出てきやすいです。
でも、調整業務そのものが無価値なわけではありません。
現場と技術の間に立つこと。
困りごとを整理すること。
関係者の認識をそろえること。
少しでも運用を良くすること。
それは、社内SEだからこそ積める経験でもあります。
ただし、その経験は、自分で言葉にしないと見えにくいです。
調整業務は、何もしていない仕事ではありません。
でも、そのまま「調整しました」と書くだけでは、職務経歴書では弱く見えやすいです。
このあたりをもっと具体的に、
「外注管理ばかりだった社内SE経験を、職務経歴書にどう書くか」
「実績がないように見える仕事を、どう実績として整理するか」
という視点でまとめた記事も書いています。
外注管理や調整業務が多くて、職務経歴書に何を書けばいいか悩んでいる方は、こちらも参考になると思います。
このnoteでは、未経験寄りからIT職に入った人や、社内SE・情シス・運用保守で働く人に向けて、キャリアの不安を少しずつ言葉にしています。
「自分の経験って、ちゃんと次につながるのかな」と感じている方は、よければ見てみてください。
