社内SEの転職活動について（１）

どうも、うまけいたです。

私事ですが、今月息子が遂に幼稚園に入園しました！うちの息子は性格的に落ち着きのない子ですが登園するときに暫くはママ離れが出来ないだろうと踏んでいたのですが、初日から幼稚園に着くやいなやママチャリ後部座席から飛び降りて教室へ駆け抜けていったそうです。

ママ「(　ﾟдﾟ)ﾎﾟｶｰﾝ…」

いやちょっとは名残惜しんであげて息子よ！

さて本題。

今回は社内SEへの転職活動について記載していきたいと思います。

僕がSIer企業から社内SEへの転職を目指したきっかけは、はっきりいうとSIerのピラミッド構造でいう上でも下でもない中途半端な真ん中の立ち位置で残業にまみれながら、苦しみながら働くスタイルに嫌気がさし、ある程度時間の融通がきく仕事スタイルが望めると聞いた事がきっかけで目指すこととなりました。

転職活動して今の企業に内定もらえたのが20代後半の時でしたが、当時から社内SEは募集あっても1・2名程度が大半でそこまで間口の広い求人ではありませんでした。

当時登録していた転職エージェントからも20代で社内SEになるよりある程度経験を積んだ30代以降で社内SEになる人が多いとは言われていたので直ぐ内定もらえるとはあまり思っていませんでしたが、案の定転職活動は苦戦しまして内定出るまで大体4～50社は受けたと思います。

• 転職エージェントについて

当時利用したエージェントはDODAとリクルートエージェントという大手2社を利用しました。

この2社を利用してみての感想ですが、エンジニアの公開・非公開求人数的にはリクルートエージェントが多く、たまたまかもしれませんが当時ついた担当の方もリクルートエージェントの方が親身になって転職活動をサポートしてくれたので個人的にはリクルートエージェントをお勧めします。

ただ、大手企業を目指す方であればリクルートエージェントでもDODAでも掲載されてますし、求人数の多さについても選定企業にこだわりを持っている方であれば、大半は入社の選択肢にはならないケースが大半かと思いますのでリクルートエージェントとDODA、ビズリーチ等の大手に登録しておいて、より良い担当者に巡り合えた方で転職活動を本格的に進めていければ良いのではないかと思います。

大体どの転職サイトのエージェントもサポート期間の目安は３か月程度となっていますが、リクルートエージェントを利用した際には6か月くらいかけて転職しました笑

大手企業の社内SEを志望して活動していましたが、スキル不足もあって中々内定もらえなかったのですが当時担当いただいた方が親身なって励ましてくれて、悩んでいる事があれば何でも相談してほしいといった姿勢の方であったため、腰を据えて後悔のない転職活動を行う事が出来、とても感謝感謝でした。。

1回目の転職は自分の考えていることとか感覚だけで転職活動するのは非効率なやり方と思ってて、理由は新卒で入社した会社で経験したことが本当に市場価値があるものかどうかの基準をエージェントの方なら判断出来ると思い、それによって転職活動による自分の価値基準が見直されて一旦は在籍会社でスキルを磨きなおすようにする等といった選択肢の幅も広がるようになると思います。

・大手転職エージェントを中心に複数登録しておいて、ついてくれる担当者が自分の事を思って親身になってアドバイスをしてくれるかどうか等、担当者の良し悪しによって本格的に利用するエージェントを決める。

1回目の転職活動においては、上記のやり方を行えば転職した際においても後悔する事も少なくなると思ってます。

• 社内SEの年収について

社内SEの求人に関する年収ですが、肌感覚で20代後半～30代前半くらいで大体500万くらいの求人が多かったと思います。会社の規模にもよるかと思いますが、社内SEは売り上げを上げてくれる部署ではないのでその分評価もされにくい立ち位置なので入社後の年収UPも大きく上がる事を期待できるものでもないかと思います。社内SEでいかにして年収を上げていくようにするかについては、別記事で掲載していきたいと思います。

お金を得る事を求めるのであれば、残業を満額支払ってくれるSIerに在籍して残業しまくった方がよっぽど稼げると思います・・・( ﾟДﾟ)

後は手っ取り早く年収を上げるとしたらやはり転職活動して自分をより高く評価してくれる企業を探す事だと思いますが、実は直近で自分の市場価値確認のため、社内SEになって５～６年経過した今、再度転職活動を行ってみました笑

そこでまた改めて気づいた転職活動における価値・意義・市況の変化等々についてを別記事で纏めていきたいと思います。

転職活動においては企業側に評価してもらう立場ではありますが、逆にこちらが企業を評価し、入社するか否かを決める立場でもあるので、気になった事はエージェントや企業側へ伝えて、ぜひ後悔のない転職活動を行ってほしいと思っています！

それでは、また！

社内SEの対人関係について

こんにちわ、うまけいたです。

今回は社内SEの対人関係について、前職のSIer時代との違いを交えながら記載していきたいと思います。最後までお付き合いいただけると幸いです。

社内SEの対人関係については基本的に「所属部署内」「他部署」「外部取引先（ベンダ等）」大きくこの３つに分ける事が出来ると思います。更に他部署の中でも管理部門系のシステムなのか、売上等を管理する現場系のシステムなのかで社員の質のようなものも変わってきます。

• 所属部署との対人関係について

基本的には友好的な感じ。ただ、少人数のシステム部署内の役職的には課長と部長、この２つしかないとした場合、少しでも出世欲の強い人とかがいるとギスギスする時があり、例えば、他部署からシステムの改修要望があった時に手作業の運用の改善で事足りるはずのものを敢えてシステム改修を引き受ける事で、自分の株を挙げようとする人がいたりとか。。

更に要望の依頼主の役職に応じて（偉ければ偉いほど）安易に引き受けて自分の手柄として評価を高めようとする輩が少なからずいますので、結構、自分の良き仲間であるはずの所属部署の同僚に対して嫌な面も目に付く事は多々あります・・。実際に、仲が悪くなって席が隣どおしなのに会話を一切しない人とかもいたりして、そうなった場合は大抵どちらかが辞めざるを得なくて転職していく事態になります。。

また、社内SEだと基本的に少人数の仲間・同僚でチームを組んでシステム保守・運用やリプレース対応等に当たっていく事となり、社内SEである限りは異動等もないためメンバからひんしゅくを買って嫌われるような事があったら仕事を続け辛くなります。。

例えば、SIerに勤めている場合はプロジェクト単位で作業する事になりますが、そのPJでメンバとのコンフリクトが発生してそのチームで作業がし辛くなったとしても、次の

プロジェクト現場に異動してしまえば、それまでの対人関係は一旦リセットされます。

仮に同部署内の人間同士で関係が悪化したとしても、現場のロケーションが違うため顔を合わせる機会もそんなにないので、そこまで苦にはならないはずです。

そのため、SIerの頃と比べると周囲との人間関係についてはより一層仲間への気配りを大切にしながら業務を推進していく必要があるといえます。

• 他部署との対人関係について

担当システムの内容にもよるかと思いますが、基本的にはシステム部門の方が立場が弱いです。例えばユーザからの問合わせでシステムに不具合があるから調査してくれっていわれた時に、ユーザ自身の操作方法に誤りがあって指摘をした場合でも平気でシステムのせいにされる事もあります。

これだけ聞くと社内システムを利用するユーザが幅を利かせて情シスである社内SEの立場が弱くて損な職種じゃん・・・と思われるかもしれませんが、ゲームを攻略する感覚でクセのあるユーザとの付き合い方を学ぶ姿勢が大事と思います。

また、業務上困っている事等をシステム通じて解決してあげた場合にはとても感謝される職種でもあり、社内SEとして働く以上、複数の業務アプリの運用やインフラの管理、予算管理等々やらなければいけない事も多岐に渡るため他部署との対応についても優先度つけながら対応を進める必要が生じますがやり甲斐のある職種であると思います。

• 外部取引先との対人関係について

業務アプリを運用いただくベンダさんだったりについては発注・受注関係がある手前、基本的に何か問題起こされるような事はないですが、アプリの品質の部分だったり費用的な問題だったり取引先によって様々あり、ベンダ毎に対応の仕方を考えなければいけなかったり、長くシステムの開発運用等を担当いただいているベンダについては多少こちらを見下すような雰囲気になる事はあります。ただ、他部署との対人関係においても同様ですが一方的な指示を行うとか相談事項等があるときに発注側の立場を利用して聞く耳を持たないような姿勢になるのではなく、助け合いの精神で推進するよう心がければ殆どうまくいくものと思います。

社内SEとしての対人関係について一言で表すと、

関係者間で信頼関係を構築出来れば、その後の業務は

鬼に金棒

かな笑

３つに分けて紹介した社内SEの対人関係について、各々詳細や対応の仕方等も別記事で記載していけたらと思います。

それでは、また！

社内基幹系システム移行計画策定時のポイントについて

今回は社内システムのサーバ移行やリプレース対応において事前に計画すべきポイントについて何点かご紹介していこうと思います。

社内SEとしていくつかのシステムのサーバ移行・リプレース等を経験してきましたが、特に人事・経理向け等の社内基幹システムにおいて旧システムから新システムへの移行失敗は、大トラブルに直結してしまいます。

理由としては、移行失敗によって例えば給与計算業務や会計の決算業務等が滞り、会社の事業活動そのものに影響が出てしまう事が想定されるためですが、システム移行を問題なく終えるための移行計画を入念に作成しておく事が大事です。

システム移行の成功・失敗については単純にシステムが動かない以外にも、品質・コスト・納期の遅延等といった様々な観点が絡み合うため、様々なフェーズで様々な計画にそって対応を行っていく必要がありますが、具体的には、以下のような様々な角度から移行計画を行う必要があると考えます。

• 移行対象データの策定

移行データについては、そのデータ量が多くなればなるほど移行にかかる作業量や、当初想定の移行データに過不足がないかどうかのチェック作業等が膨らみ、工数や納期にも影響が出てきます。そのため、単純に移行前のデータを全て移行先システムへ移行する前提で移行作業を進めるのではなく、きちんと各々のデータに対して要不要の精査を行う必要があります。

が、これまでの経験上ユーザ側の立場からすると移行前のシステムで保有しているデータは全て移行先システムへ持っていってほしいと言われるケースが多いです。。

特に基幹系システムにおいてはトランザクションデータ等も膨大な量になってしまうため、マストな感じでないなら移行をしない選択も作業工数削減のためとしては有りかと思います。

ただし、移行しないデータはどうするのか？等の代替案を何かしら示す必要があると思うので、例えば利用頻度の少ないデータについては移行元システムから出力したデータを共有フォルダ等に格納しておく事で有事の際にはいつでもデータ閲覧出来る状態にある事を予めユーザ側に調整しておく等の対応を行う。

システム移行の際にはこのような移行対象とするデータの策定及びそのために必要な調整作業も含めて、計画しておく事が重要と考えます。

まぁシステム移行の時だけでなく、社内SEとしては常日頃からあらゆるトピックに対してユーザとの調整を行っていって、上手いことシステム作業側に有利に(?)働きかける事が出来るかどうか行う事が求められるのですけどね。。それが中々難しいのですがその辺りの内容はまた別記事で掲載していこうと思います。

• 全体スケジュールの策定

システム移行の際には全体スケジュールを策定する必要があります。全体スケジュールの策定では、プロジェクトの開始日と終了予定日の中でシステム移行作業を含めた全ての「作業内容」や「作業期間」、「担当者」等の情報を記載し、システム移行までの予定が計画通り進んでいるのか遅れが発生しているのか、その作業担当者は誰なのかを明確化・資料化して関係者間で共有する事が重要です。

理由としては、基幹系システムのようなシステムを移行する場合、そのシステムが他のシステム群に何かしらのデータ連携しているようなケースが多く、DB連携やバッチプログラムによって他システムへデータ連携している場合は連携先システム側の方でデータ取得のための向き先を移行元システムから、移行先システムへと変更を行う必要があり、連携システム群が多ければ多い程、多くの関係者を巻き込む事になります。

そのような変更作業を行う場合に、具体的にいつ頃にそのような作業を行う必要があるのか、移行までに向けた全体スケジュールをユーザ含めた関係者間で常に把握しておく必要がありますが、

全体スケジュールの明確化・資料化によって当初全体スケジュールで策定した各作業の早まりや遅延が本番移行日に影響を受けるか否かにおいてアンテナを張る事ができ、影響を受ける場合にはシステム移行によって影響を受ける関係者に対して素早く情報共有を行う事が可能となるため、上述した「全体スケジュール」の策定・計画しておく事が重要です。

• 移行作業に係るタイムチャートの策定

移行当日においては実施する作業内容の抜け漏れが発生した場合、システム移行の失敗に直結する事態となってしまい、ユーザ側への事情説明・再調整・報告書の提出や各種周辺システムに対する再調整等といった対応を余儀なくされてしまいます。

また、システム移行の際には事前にユーザ側と移行時間を調整した上での対応となるケースが多く、実際の作業が計画した時間の範囲内に沿って行われているかチェックするために、事前に移行の作業内容及び各作業時間の詳細を計画する事が重要となります。

具体的には、以下のような項目を作業内容単位で事前に計画する必要があると考えています。

1. 作業日（前日作業なのか当日なのか等）

2. 作業開始時間

3. 作業終了時間

4. 作業時間

5. 作業内容

6. 作業結果（OK or NG等）

7. 作業担当者（ベンダ側なのかユーザ企業側なのか等）

8. 備考

• 移行時の体制について

移行時においてベンダ側及びユーザ側の担当者を明確にし、システム移行当日にあたって以下の必要最低限以上の要員を確保する事が必要であると考えます。

1. 作業ベンダ側⇒2名以上

2. 社内システム部門⇒1名以上

3. ユーザ側⇒1名以上

上記の理由としては、主な作業者として想定されるベンダ側の担当においては作業者とは別に確認者を用意する事で、作業者の作業漏れやミスに気づいて対応を行えるようになり、トラブルを未然に防げる可能性があるため、ベンダ側は2名以上は必須であると思います。

ユーザ側においては、ベンダとユーザの橋渡し役になるシステム部門担当者1名と、システム部門側からの移行作業に係る報告を受けるユーザ側担当者1名以上の要員を確保する必要がある。ただし、システム部門担当とユーザ側担当においてはベンダからの報告を受けて何かしらの判断・各所への調整対応を行う事が出来る人材が担当する事がポイントであると考えます。

• コンティンジェンシー計画について

システム移行時において事前に想定される障害を洗出し、万が一その障害が発生した場合に被害を最小限に抑えるために事前計画しておく必要があります。

具体的には、旧環境で取得しておいたバックアップを新環境への適用が完了しないような場合や、移行したシステムから周辺システムに対して意図せぬデータが連携されてしまっているような事象が発生した場合には一時的にシステム移行の切替を取りやめ、旧環境を継続利用する等といった対応を事前に策定する事で、不測の事態がもたらす被害を最小限に抑えられるため、システム移行においてコンティンジェンシー計画の策定が重要です。

今回いくつか社内基幹系システム移行計画策定時のポイントについて記載させていただきましたが、もっと経験重ねるともっと色々な事に気付けるようになるんだろうな。。

本テーマについては今後も継続して記事にしていきたいと思います！

それでは、また！

社内SEになるまで

初めまして('∀')前職SIerから現職で事業会社の社内SEやっております、うまけいたです。

このBlogでは、新卒でとあるSIer関連の企業に入社して以降、僕が何をどう思って事業会社の社内SEになったのか、社内SEとして働いて感じている事や業務上のノウハウ等々をご紹介する事で、何か1ミリでも読んで下さる皆様のお役に立てるような記事を配信していきたいと思います！ではいくー。

• 前職SIer時代における働き方について

大学時代に情報学科に所属していた事もあり必然的にIT業界志して就職活動を行い、中堅SIer企業に新卒入社しました。当時新卒社員だけでも80人程いて、合宿研修の夜に相部屋になった同期と恋バナで盛り上がったりして楽しかったなぁ（遠い目）

そんな話はさておき。。

暫くして配属先の新入社員歓迎会で部長に接待していた時の事言われた言葉

部長「お前、地獄を見たいか？(￣ー￣)ﾆﾔﾘ」

私「は、はい！」←大馬鹿野郎

鶴の一声（もとい、悪魔の一声）で決まった最初の現場が、ミッションクリティカルなシステム開発の現場でした。うきうきわくわくで向かった最初の現場。

研修で学んだプログラミング技術を生かして業務に貢献するぞ！とウブな私は活き込んでいました。

がしかし・・・実際にはやる事といえば下請け会社の入館申請の管理やCVSを使った資材の管理手順等といった事務的な作業ばかり・・

そんな矢先、突如商用アプリのトラブルが発生する事となりました。。

商用アプリのトラブルにより、復旧作業のために現場に向かえとの号令がかかり、

アプリの仕組そのものについても理解してないのにも関わらず、有識者と一緒に現場へ。。

現場につき、相手先の運用担当者複数名に取り囲まれながらいざ復旧作業開始。

といっても自分は何もわかっていないのでただ見守っているだけ。その間もミッションクリティカルなアプリのため、１秒でも早く復旧しろと相手先からのプレッシャーが半端ではなく、罵声も浴びてとても理不尽に思いましたが、元はといえばこちらが悪いので、ただ耐えるだけなのでした。。

その場は何とか復旧作業が終わり、事なきを得ましたがその後のシステム改修・運用においては非常に短納期かつ高品質を求められる事もあり何人もの人が体力の限界を迎え、病院に運ばれていく様を見てきました。

あの3.11の大震災の時ですら、地震発生直後に避難を促してる人に対して誰一人耳を傾けず、作業の手を止めるものはおらず、今思えば新興宗教にのめりこんで抜け出せない人たちの集まりの如く、ただただ異様な光景でした。。

あの時はこれがいわゆる「社会の荒波」なんだと思い込み、この環境に耐えれるようにならないと、一人前の社会人になれないと思ってましたが今思えば当時の現場、当時の所属していた会社そのものが売上を上げるためにはどんなにキツくても頑張り続けろという志向であり、それに疑問も持たずに従っていました。

ここまで極端ではないかもしれませんが、このような環境のSIer系の企業は未だに多いのではないかと思っています。

• 一念発起して社内SEへ

その後、軽く鬱になりかけながらも数年経て今後のキャリアについて知り合いに相談した結果、社内SEを目指してみてはとアドバイスを貰い、考えた末社内SEへのキャリアチェンジを目指し、転職を果たしました。

社内SEになってみて、開発やシステム保守等は基本的にベンダにお任せ（丸投げ）するものが多く、ユーザの要望をヒアリングしてシステムに落とし込む作業、システムの予算管理・課題管理等が基本的なタスクとなるため、IT技術力の向上を求める人は合わないと思います。

ただ、中には内製に力を入れる企業の応募もチラホラとあったので、社内SEであっても技術を高められるような職場は存在します。

また、立場的に売り上げを上げる必要がない代わりに、システムに掛かる無駄なコストの削減を求められ、経営状況によってはシステム導入等のIT投資にかけるコストを削減されて目新しい業務に携わる事も出来なくなる可能性等も多々あります。

しかし、基本的に相手先が社内の人間なので労働時間の融通等もSIer時代に比べて大分利くようになりましたし精神的に追い込まれるような事もありません。

社内SEとして今後考えていかなければいけない問題・課題も多々ありますが、また別記事で掲載していきたいと思います。

それでは、また！