【情シス入門】SIerから社内SEに転職して驚いた！ここが変だよ事業会社

私はSIerでSEやプロマネを経験した後、事業会社の情シス(社内SE)に転職し、事業会社の情シスという職業がそれなりに気に入ってなんだかんだと続けていますが、転職した当初はそれまでの仕事のやり方や考え方も大きく異なり、色々と困惑しました。

今回の記事では、私が社内SEに転職して、個人的に感じた色々なギャップを紹介していこうと思います。

IT業界の技術者から社内SEへの転職を考えられている方は参考になるかもしれません。
但し、私の経験則や主観で紹介するため、実は偏っていて、参考にしてはいけないのかもしれません。

 

SIerから社内SEに転職して驚いたこと

当項では、今回の記事の主題である、SIerから社内SEに転職して驚いたことのあれこれを紹介していきます。

 

IT以外の仕事も多い

SIerにしろ、その他のIT業界で働くITエンジニアの仕事の多くはITに関する技術的な仕事です。
その組織やプロジェクトのなかでも、上に立場になるほど非IT的な業務も増えますが、それでも業務内容の多くがITに関連するものです。

社内SEもIT職種の一つという括りですが、所属する企業や組織によっては、ITとはあまり関係のない業務も多く驚きます。

自身の社内SEの経験でも、例えば以下のような業務がありました。

荷物の梱包作業や洗濯業務は、私が所属する拠点内の各部署で持ち回りの業務であり、情シスも特別扱いされることはなく、自部署の順番が来たら対応していました。

また、データ入力は普段パートさんにお願いしている業務でしたが、出勤するパートさんが少なかったり間に合っていない場合は、そのデータ入力業務を管轄していた情シスのメンバーが手伝い、実際にデータ入力作業をしていました。

家電などの機器の対応まで求められるのも日常茶飯事です。
ITエンジニアはITの専門家であり、家電の知識は非ITの社員と変わらないはずですが、一般的なイメージは違うようです。

SIerのようなIT業界では、エンジニアは専門性の高い仕事を受け持っており、会社はその専門性や能力に見合った賃金を支払います。
その為、非IT職であってもできるような作業をエンジニアにやらせることはお金の無駄でしかなく、IT以外の仕事の振るようなことは殆どありません。

しかし、事業会社の社内SEの場合、IT職ではありますが、総務などのバックオフィス系の部署と同列で扱われてしまうことも多く、その結果、ITとは関係のない業務が回ってくることも少なくはありません。

逆に、情シスは電子機器の専門家だから、電気で動く機械はすべて情シスで対応できるだろうと雑な認識で、オーディオや冷蔵庫などの家電製品の故障対応などが降ってくることもあります。

このように、洗濯や家電対応などの極端な事例は、部署間の業務の分担が曖昧な小さい会社ほど顕著に発生し、会社の規模が大きくなるほどこのような仕事の割り当ては減っていきます。

心に余裕があれば、「これも社内SEの仕事の醍醐味だろう」と思えるかも知れませんが、志が高くやる気に満ちた能力の高い人ほど、このような扱いで心にダメージを負います。

また、上記のような極端な例以外にも、事あるごとにワークフローシステムや紙での申請を求められつつハンコリレーで説明に回ったり、何かと社内向けの書類作成が必要だったりと、合理性や生産性を重んじるIT業界ではあまり行われない事務処理的な仕事に大きく時間を割くことも多々あります。

 

極端に仕事のできない人が居る

SIerのようなIT業界では、個人毎のITに関する適正の有無が顕著に反映される傾向があり、適性がある人は技術の習得も早く、どこの会社に所属していようが、職種が変わらない限りそれなりに活躍していくことができます。
逆に、適性の無い人の場合は、求められる能力に達することができず、最終的にはIT業界を去っていきます。
技術職である以上、個人の能力がシビアに見られます。

そのような世界で働いていた人が非ITの事業会社に転職すると、主に他部署のケースですが、たまに自部署でも極端に仕事ができない人が居て驚くことがあります。

当記事における「仕事ができない」という文面の意味合いとしては、所謂「社会人力」の欠落を意味しています。

ITエンジニアでも社会人力が滑落した人はいますが、結局ITの能力が十分に備わっていれば、それなりに仕事にはありつけます。
ITエンジニアにおいて、仕事で必要な能力の評価と社会人力とは、それほど強い関連性はありません。

一方、非ITの事業会社で働く従業員の業務内容の多くは、自社の事業内容を元にした業務知識とともに、「社会人力」が強く求められます。
よって、非ITの事業会社では、仕事の遂行能力の評価基準として、この社会人力の有無は非常に大きいと言えます。

IT業界のエンジニアであれば、「仕事ができない」＝「ITの知識や経験が不足している」という式が成り立ち、評価基準は非常に明確です。

本人が努力をしても仕事ができるようになれなければ、その人に割り振れる仕事も無くなり、最終的に退職していきます。

非ITの事業会社の場合、個々の従業員の担当している仕事内容自体は、IT業界のエンジニアと比べると専門性の低いものが多く、比較的習得も容易です。

仕事自体の難易度より、その仕事を如何に社会人力を駆使して適切に進めることができたかが評価になります。

もし社会人力が劣っていた場合、仕事に対する高い評価を得ることはできませんが、元々割り振られる仕事自体の難易度は高くないため、普通より時間が掛かったりミスが多かったしても、仕事自体に付いていくことはIT業界よりも容易です。

また、その会社内で習得した業務知識は、その会社のなかだけでしか通用せず、ポータビリティのあるスキルではないことも多いため、社会で広く求められているITのスキルを持つITエンジニアと比べると、いざ転職をしようとしても苦労する可能性は高いです。

その結果、非ITの事業会社では、極端に仕事のできない人でも辞めることはせず、その会社に残り続けます。
また、会社はそのような人であっても容易に解雇ができないため、その人ができる範囲の仕事を与え、雇用し続けます。

このようなプロセスを経て、最終的には「窓際社員」が生まれます。
実力主義のIT業界では、あまりこのような事例は聞きません。

 

極端にパソコンを使えない人がいる

非IT系の仕事をされている人のイメージだと、SIerなどのIT業界の人は、全員パソコンに詳しいと思われがちですが、実態はそうではありません。

パソコンが動く仕組みに興味も知識もないが、ただの仕事道具としてパソコンを使用してプログラムを作っているエンジニアもいます。

本来は、自分たちの仕事道具がどのような仕組みで動き、どのような機器で構成されており、その組み合わせによって性能にどのように影響するかなどは知っておいてほしいものですが、そのような知識を持たなくてもできる仕事を与えられ、それを適切にこなしているのであれば問題はありません。

とは言え、IT業界で働く人であれば、「右クリック」と言えばマウスの右ボタンを押すのだなと理解できますし、デスクトップパソコンのモニター側の電源ボタンを押しても、パソコン本体の電源が入らないのを知っています。

パソコンを使ううえでの「常識」は備えているので、非IT系の職種の人たちもそれぐらいの常識は持っていると考えてしまいますが、非ITの事業会社のなかでは、時々極端にパソコンを使えない、知らない人に出くわします。

特に社内SEとして働いていると、ヘルプデスク業務でそのような人たちの対応をする機会も多々あり、目の前で対面してやり取りができないこともあり、対応は困難を極めます。

実際に私がヘルプデスクで対峙したパソコンを使えない人たちとのやり取り例は以下です。

個人的には、知らないことは仕方がないですし、それだけを理由にその人を見下したり軽んじたりすることはないのですが、得てしてそのような人は、パソコンに関する説明を真面目に聞いて理解しようとはしてくれず、また覚えようとする気を感じないことが多いです。

世の中の風潮として、何故かパソコンの分野については、「苦手」とか「わからない」といった発言が許容されがちです。

それ自体もおかしいと思っていますが、百歩譲って苦手意識を持つのは仕方ないとしても、それを仕事で使う以上、最低限の使い方を覚える努力は必要です。

その努力を「苦手」だ、「わからないから」とまったくしようとしない場合は、どうしても見下したり軽んじてしまいます。

 

役職による力関係が非常に強い

SIerなどのIT業界における会社内や部署内の組織は比較的フラットであり、役職はその組織内のマネージメント上の役割でしかなく、その人の組織上の地位という意味合いは薄いです。
あくまでITエンジニアは技術職であり、組織における地位や力関係については、役職などの会社が与えた役割ではなく、個人毎のITスキルや能力によるところが大きいためです。
よって、従業員に与えられた役職がその人の組織上の「地位」とはなりません。

一方、非ITの事業会社では、会社内の役職が、その人との力関係において大きく影響します。

企業の組織構成は会社によってまちまちですが、例としては、社長を頂点として、専務や常務などの役員がおります。
企業形態として事業部制であれば各事業部があり、その事業部ごとに部長が居ます。
また、その配下には課が存在し、課長がその課を管理します。

この社長を頂点として構成されるピラミッドがその企業の確固たるヒエラルキーして存在しています。
企業規模にもよりますが、平社員が社長と接する機会はまずありません。
また、社長の意見や指示は絶対であり、たとえ内容が理不尽であったり、非合理であったとしても、それを口に出すことはせず、社長の意見や指示に従います。
社長ではなく、専務や常務などの役員であっても、やはり強大な権力を持っていたりします。

会社によっては、社長や役員が神様のように崇拝されていたりして、我々ITエンジニアから見れば、まるで会社教の信仰のようで気持ち悪くもあります。
コーポレートガバナンスを取り入れた組織運営をしていたとしても、結局会社は社長がオーナーであり、社長の意見や行動が絶対という意識が強く、監査や権限分散が機能しないといった会社もよく見かけます。

このヒエラルキーは会社内で広く浸透されており、一企業の経営陣や管理職と従業員という関係だけではなく、仕事以外のプライベートな領域においても、これらの力関係が影響を与えます。

IT企業と非IT企業における従業員同士の力関係にこれほど差がでる要因の一つが、新卒採用主体の社員構成か中途採用主体の社員構成かの違いだと考えています。

IT企業では、自社の従業員を中途採用で雇用するケースが多いです。
尚、ITエンジニアは転職もし易いため、自社に不満があったり、より良い条件で採用してもらえる企業があれば、容易に転職していきます。
また、新卒で採用した従業員においても、一定期間を経て、同じIT業界の別の会社に転職して行く人は多くいます。
「転職」という行為が当たり前の選択肢として用意されている世界です。

そのため、ITエンジニアにとっての会社は、自身の労働力(及び技術)を提供し、その報酬として賃金をもらうために所属する組織でしかないという認識を持つ人が多いです。

一方で、非ITの事業会社の場合、会社にもよりますが、中途採用主体ではなく、新卒採用を主体として従業員の採用活動をする企業の方が多いです。
また、多くの従業員では、自社の業務知識を深めることがスキルアップとして扱われますが、その深めた業務知識はその企業内でしか活かせず、それまでの業務経験がそのまま転職市場で評価してもらえない場合があります。
また、IT企業とは異なり、年功序列で賃金を決めている企業も多く、長く一社に勤めるほど給与も上がります。

そのため、自社の待遇や仕事内容に不満があっても「転職」をせず我慢をしたり、他部署や他業務に配属希望を出して同じ会社で働き続けるケースが多いです。

その結果、非ITの事業会社で働く従業員にとっての会社は、賃金をもらうための単純な雇用関係だけではなく、もっと自身の生活や人生における深いところに位置するようになり、勤めている会社の経営者や上司、部下などとの力関係もより強く影響を受けることになります。

 

社長や役員の親族がやたらと居る

SIerなどIT業界の企業でも当然同族経営はありますし、経営陣の親族を社内の重要なポストに付けるような配置転換もありますが、IT企業の場合はそもそも創業して何十年も経っている会社自体が多くはないため、経営陣の世代交代を迎える時期に達していなかったりします。

一方、ある程度の規模の非IT系事業会社の場合は、創業から十分な時間が経過している場合が多く、社長の世代交代が意識された人事が行われたり、縁故採用や縁故配置移動などによって、社内の重要なポジションに社長や経営陣の親族が割り当てられだすようになります。
また、その会社がグループ会社や子会社なども保有している場合は、創業者が居る本体の会社ではなく、周囲のグループ会社や子会社側で実績を積ませ、世代交代時に本体の会社に移ってくるケースもあります。

これらの親族社員は、初めからその立場を社内全体に対してオープンにしている場合と、あまり公にしていないケースがあります。
例えば、社長の1等身、2等身ぐらいであれば苗字も同じである可能性が高いですし、周知の事実として扱われますが、社長の親戚みたいな等身だと苗字も違っていたりして、その人が親族だということを一部の社員しか知らないといった扱われ方が多い感じがします。

親族がその会社や関連会社に次々入り込んでいくことで、気が付いたら主要なポジションは親族が大半を占めていたなんてこともあったり無かったりします。
地方、非上場、創業からそこそこ時間が経過した企業であれば、大半が上記のような感じです。

更に、会社の登記簿謄本などを取得すると、社内では名前を聞いたこともない社長や役員の親族が会社の取締役としてずらっと並んでおり、何の縁故もない社員の私はゲンナリします。

同族経営自体に良い悪いと安易に言えるものではないのですが、社員の能力の有無ではなく、血筋で重要なポジションへ抜擢したり経営方針を委ねるといった行為は、合理性や効率性を重視するITエンジニア的思想とは相反するものだと個人的には感じます。

 

レガシーな基幹システムのリプレイスは困難

SNSなどでは、レガシーなシステムを使い続ける企業や組織は今どきのITエンジニアからか軽んじられる傾向があり、私自身もSIerに勤めていた頃は同じように考えていました。
最近のIT業界のエンジニアから見れば、サーバー環境であればAWSのような便利なサービスもあるし、開発言語も洗練されたフレームワークが充実しており、大昔に開発したオンプレベースの古い基幹システムなんかはさっさと作り直せばよいと思うことでしょう。

また、最近では様々なSaaSもあり、いちいち業務システムをスクラッチで開発すること自体が時代遅れであり、月額の利用費用を支払ってそういったクラウドサービスを利用した方が良いという意見も良く見ます。
他にも、ERPに切り替えればいいじゃんと言われることもあります。

実際にそのようなレガシーシステムを運用している我々も、できることならそうしたいです。

しかし、「レガシーな基幹システムのリプレイス」は、口で言うほど簡単なものではなく、それを実現するには、あまりに多くの課題を解決していくことになります。

企業のシステム運用の実態について詳しくないITエンジニアがイメージする「古い基幹システムを使い続ける理由」の一つに、「リプレイス費用をケチっている」といった認識があります。

確かに、規模の比較的小さい企業の場合は、そのような理由でリプレイスをせずに使い続けているケースもいますが、多くの企業では、逆に「お金を出してリプレイスをしてもらえるならやってほしい」と考えています。

レガシーなシステムにおいて、リプレイスが困難な理由の例は以下です。

リプレイスが困難なのは、莫大な費用が掛かるからではなく、現実的に今のシステムを作り変えることがあらゆる理由で難しいからです。

稼働し始めて長時間が経過した基幹システムでは、開発当初に関わった自社の担当者も既に退職済みといったケースはよくあります。
また、開発を請け負ったシステム会社も今は存在しないとか、会社自体は存続していたも、当時開発に関わった開発者が既にいないこともあります。

また、そのシステムの運用を担当している情シスでも、システム全体の仕様を把握できておらず、局所的、断片的な理解しかできていない場合も多いです。
また、どの機能をどの部署がどのような業務で使用しているかなども、システムの規模が大きくなればなるほど把握が難しくなります。

そのようなシステムでは、設計書などのドキュメントも残されていないケースが多いため、そのシステムの表面的な振る舞いや生成されるデータを解析することでしか仕様を確認する術がなかったります。

そのシステムを運用する情シスなどシステム担当者自身も「よくわからんけど動いているから、ヨシ！」といった感覚で関わっています。

言ってみれば「奇跡のバランス」で現在システムが稼働している状態であり、それを壊して作り直そうとするのは正気の沙汰ではありません。
「レガシーな基幹システムのリプレイス」とは、それほど大変な行為だと言えます。

因みに、この大変な行為を職業にしているが「ERPコンサル」です。

顧客の基幹システムの機能や関連業務を調査し、ERPの標準機能で置き換え可能か否かを精査します。
置き換えができない場合はアドオンとしてERPに対してカスタマイズをするか、業務自体を見直すかを検討します。
その基幹システムで蓄積された大量のデータをERPにコンバートしながら移管しつつ、炎上覚悟で基幹システムをERPに切り替えます。

我々情シスが十数年以上リプレイスできなかったシステムを、ふらっと来た社外のコンサルが半年や1年程度の準備期間を経て簡単にERPへ移行できる訳もなく、システム規模が大きいほど高い確率でトラブルが起こります。
切り替えに失敗した場合は、切り替え対象が基幹システムである以上、顧客の業務は止まり、その顧客の事業規模によっては事件としてメディアで報じられます。

これがERPコンサルの過酷な仕事内容ですが、そのような大変な仕事だからこそ多くのITエンジニアより高い給料を得ています。

基幹システムをリプレイスするにあたり、移行先がERPだろうが、スクラッチで開発しようが、複数のSaaSに分解して移行しようが大変なことに変わりはありません。
この大変さは実際にレガシーな基幹システムを内部の人間として日々運用してみないとなかなか理解ができないかと思います。

とは言え、大変だからやらなくても良いわけでもなくて、いつかはやらないといけないものなのですが、取り敢えず、レガシーな基幹システムのリプレイスはものすごく大変な行為だと理解しておく必要があります。

 

時々Excelの達人が居る

Microsoft Officeは、OA事務業務にするうえで欠かせないソフトウェアですが、そのなかでもExcelは、Office製品のなかでも最も使用頻度の高いソフトです。

SIerなどのIT企業のエンジニアも日常的に使用はしていますが、設計書などのドキュメント作成や、データの加工作業、簡単な集計表の作成程度の使い方しかしていないケースが大半です。

一般的なイメージとしては、ITエンジニアであれば、Excelも当たり前のように詳しいだろうと思われがちですが、実際には初心者に毛が生えた程度の使い方ぐらいしか知らない人も多くいます。

一方、非IT系事業会社でOA事務業務をメインで担当しているような人だと、その人の仕事の大半がExcelを使用した作業であり、一日中Excelを起動しているといったケースも多いです。

また、Excelを使って行う作業も、ITエンジニアのようにドキュメント作成などの限定された範囲の用途ではなく、担当業務ごとにその用途も多岐にわたります。

その結果、OA事務作業を主として行っている社員の場合、Excelに実装されている様々な機能を熟知し、作業内容に合わせて適切に機能を取捨選択しつつ活用できる能力が非常に重要になります。

特に昨今では「リスキリング」と称し、国を挙げて会社員の学び直しを推進しており、その学び直しの対象として最も期待されているのが、Excelの技術習得を主とした会社員のOA能力の向上です。

よって、非IT職種の人たちを対象にしたパソコン教室や、Excel教室などのIT系スクールは非常に活況です。

また、書店には非常に多くのExcel教本が並び、インターネットでもExcelの技術を学べるウェブサイトも充実しており、様々な方法でExcelを学ぶことができます。

このよう、ITエンジニアより事業会社の非IT系職種の社員のほうがExcelに関わる業務は多く、また、Excelの技術を学ぶことにより得られる業務上のメリットも大きいです。

また、IT企業では自身が業務上使用するソフトウェアをある程度自由に選定することができ、また使用できるソフトウェアの種類も豊富ですが、非IT系事業会社の場合、自社のセキュリティポリシーによる制約により、自身の端末に自由にソフトウェアをインストールすることが許可されていない場合も多いです。

そのような企業では、業務の効率化や省力化、自動化などしたい場合に、自端末でインストールされているExcelの機能を駆使する以外に選択肢が無い場合もよくあります。

このように様々な事情により、非IT系の事業会社の社員には、ものすごいスキルを持つExcelのエキスパートが稀に存在します。

このような人たちが作ったExcelツールは、その人の作業や、部署の作業の効率化に大きく貢献していますが、その判明、作り込まれたExcelツールの運用や保守は業務の俗人化にも繋がります。
作成者の退職や移動に伴い、そのExcelツールに依存した業務自体が停止してしまう恐れもあり、情シス視点で言えば、取扱いが難しい問題でもあります。
また、同様に「Microsoft Access」でも俗人化の問題をひき起こしがちです。

IT業界のITエンジニアから見ても、事業会社に勤めるMicrosoft Officeのエキスパート達のスキルには驚かされますが、IT業界のようにそのスキルが無条件で賞賛されるとは限らず、企業によっては業務の俗人化を回避するために、過度な作り込みを禁止したり、自社の社員でできるような作業であっても、システム会社などに外注するケースもあります。

このあたりのIT業界と非IT系事業会社の考え方の違いも、最初はかなり戸惑うことになります。

 

部署間のヒエラルキーは現場系が頂点

SIerなどのIT業界でも、部署によって社内における力関係は変わりますが、これまでの記事でも解説したように、ITエンジニアは所属組織よりも個人ごとのスキルや能力を重視する傾向にあり、社内おける自部署の力の強弱を意識することは比較的少ないと言えます。

一方、非IT系事業会社の場合は、個人の能力より集団での貢献度や影響度が重視されるため、所属組織による社内の力関係の強弱をより顕著に感じる場合が多いです。

非IT系事業会社において、社内で最も優遇され発言力が強いのは「現場系」の部署です。

この記事で呼称する「現場系」とは営業部や製造部など、その企業において利益を直接生み出す部署のことを指します。
「直接部門」とか「プロフィットセンター」などとも呼びます。

逆に、社内おいて力関係が弱くなりがちなのは、総務や経理などのバックオフィス系部署です。
「間接部門」とか「コストセンター(あまり好きな呼び方ではないのですが)」などと呼んだりもします。

事業会社の役員なども、バックオフィス系部署出身者より、現場系部署の出身者の方が多いことからも、その会社の部署間のヒエラルキーが垣間見えます。

事業会社の情シスの場合、社内の様々な部署を横断しながら仕事を進めますが、現場系部署の業務改善を目的とした予算は簡単に承認され、バックオフィス系部署の業務改善を目的とした場合は途端に承認を渋られることは日常茶飯事です。

これは、現場系部署に対する投資は収益の拡大が狙えますが、バックオフィス系部署に投資をしても、直接的に収益を伸ばすことは難しいと考えると、当然な経営判断だと言えます。

尚、当記事の主題である、情シス(社内SE)もバックオフィス系部署の括りに入ります。

情シスの場合、業務内容もITに関するものが多く、業務内容の必要性や重要性を経営陣や他部署に理解してもらうことは簡単ではありません。
さらに、情シスの部署長や個々の社員が自社への貢献度合いを上手くアピールできていない場合、本来は社内の重要な役割を担っているにもかかわらず、社内のヒエラルキーにおける最底辺に甘んじているケースも多く見られます。

このあたりの考え方の違いも、個々の能力が重視されるIT業界出身者から見ると違和感や不合理を感じるポイントだと思います。

 

最後に

今回の記事では、SIerなどのIT企業に勤めていたITエンジニアが非IT系事業会社の情シス(社内SE)に転職して驚いたことを、自身の実体験を交えて紹介させていただきました。

尚、実際には会社によって社風や社内ルール、仕事や組織に対する価値観、情シスに求める役割は様々であり、この記事で書いてきた内容がどれも当てはまるわけではありません。
冒頭でも記載したように、あくまで話半分で読んでいただければと思います。

今回も長々と読んでいただきありがとうございました。
それでは皆さまご機嫌よう！