社内SEは楽
社内SEに興味のある方なら一度はこの言葉を目にしたことがあるかと思います。ネットで検索しても頻繁に見かけますし、社内SEをやっている私自身もよく「楽そうでいいね」と言われることがあります。
このように世の中的には「社内SEは楽だ」というイメージが先行していますが、果たして実際のところ社内SEは楽なのでしょうか？
インターネットで調べてみると、一方では、「情報報システム部門は人数も少ないし、なんでも屋として無茶振りされる上に、給料も上がんない！超絶ブラック！」なんて極端な意見もちらほら見かけます。
その一方で、「社内SEはめちゃめちゃ楽！暇すぎる！この世の天国！」なんて書いている人もいます。しなしながら、その方の経歴をよくよく読んでみると、前職が壮絶ブラックだったり激務コンサルだったりつよつよエンジニアだったりして、環境やスキルが自分と違いすぎて参考にならない場合が多い印象です。
結局のところ、「楽な部分もあれば大変な部分もある、環境による」といった一般論に終始するしかなく、具体的にどんなところが楽でどんなところが大変なのか、実際のところがどうなっているのかが明確に書かれていないことがほとんどでした。
過去に自分が社内SEへの転職を検討していた際も、ネット上の曖昧な情報ばかりを目にしながら、自分なんかが本当に社内SEの仕事をやっていけるんだろうか…と不安でたまらなくなりました。
何しろその当時の私にはITスキルがほとんどありませんでした。世の中で言われている「社内SEは楽」というのは高スキルの人の話であって、私のようなスキルも経験もろくにないような人間はどうせ社内SEなんてやっていくのは難しいんだろうな…
そもそも一人社内SEという言葉があるように少数精鋭である必要があるため、スキルの無い自分なんかがなれるわけないよな…と悲観的に考えていました。
そこでこの記事では、スキルの無い状態で社内SEになり、現役で社内SE業務に従事している私が、「社内SEは本当に楽なのか？」ということを掘り下げて解説していきます。
社内SEは本当に楽なのか？
社内SEの仕事って、本当に楽なんですか？
この疑問に対する結論を先に言ってしまいますと、
社内SEは本当に楽です！断言します。
それでは、何をもって社内SEが楽だと断言するのか？について掘り下げて理由を説明していきます。
社内SEが楽である４つの理由
私が社内SEを楽であると判断する理由を４つ挙げます。
・仕事への責任が軽い（ベンダー側とは責任の取り方が異なる）
・成果が必要ない（売上や利益率などの分かりやすい指標がないため、目標達成に追われる心配がない）
・スキルが無くても大丈夫（自分にできないことは外部へ委託することもできる）
「社内SEは楽」である詳しい解説
社内SEが楽な理由１．仕事の絶対量が少ない
社内SEの楽な仕事：ヘルプデスク業務
社内SEになったら避けて通れない業務の１つとして、「ヘルプデスク」業務があげられます。エンドユーザからの問い合わせに対応することですね。
ここでいうエンドユーザとは、社内のすべての人間（営業・エンジニア・事務職・派遣社員・社長などなど、パソコンや社内システムを使う人全員）を指します。
多くの社内SE業務では、まずはヘルプデスク業務を通じて会社全体の仕事の流れを把握することが多いでしょう。ヘルプデスクの仕事は地味ながら重要であり、縁の下の力持ち的な存在です。
そんなヘルプデスク業務は突発的に発生するものであり、ユーザから「緊急で対応する必要がある」と言われれば、今やっている作業を中断してでもすぐにでも取り掛からなければならないこともあります。そのため、事前に予定を立てておくことができません。
しかしながら、問い合わせの多くはその場で解決できることがほとんどです。
例えばこんな問い合わせが多いです
- インターネットに繋がらない → LANが抜けてる
- キーボードがおかしくなった → NumLockを押して戻せなくなった
- ログインできない → パスワード忘れかNumLockのどちらか
「こんなの当たり前でしょ！こんなこと問い合わせするやつなんているわけない！」と思われるかもしれませんが、悲しいかな世の中の一般的な会社ではこれが普通なのです。
そしてこれらは一度マニュアルを作ってしまえば、次回は同じ問い合わせが来たらマニュアルを案内するだけで終わります。
ちなみに「問い合わせする前にマニュアル見ろよ！」とも思いますが、意外とエンドユーザは自分からはマニュアルを見てくれません。これを改善するにはユーザの意識改革を行う必要がありますが、なんでもかんでもマニュアルを見ましょうという流れになるとメンテナンスも大変になってしまうたあまりお勧めしません。
社内SEの楽な仕事：ルーティンワーク
社内SEの仕事というのは、週に1度や月に1度だけというようなルーティーンワークが結構多いです。
例えばWindowsUpdateなどもその１つです。
WindowsUpdateの際はネットワークに負荷がかかったり、更新プログラムの不具合により端末が起動しなくなるなどのトラブルが起きることもしばしばあり、問い合わせが増える傾向があります。
このような発生すると分かっている事象に対しては、いくらでも事前に対策することができますので、トラブルが発生しないような仕組みを作ってしまうことで、トラブル対応にかかる負荷を回避することができます。
（WindowsUpdateについては、私がどのような仕組み化をしているかは別の記事でまたの機会に書きたいと思います。）
また、社内SEの仕事は、安定的にシステム環境を提供するということが仕事の１つですので、月に1度くらいの頻度でシステムが安定稼働しているかの定期チェックを行います。
ファイルサーバやメールサーバのドライブの空き容量の推移をチェックしたり、インターネットの負荷状況をチェックしたり、イベントログからエラーが出ていないか、スパムメールのすり抜け率など様々な観点から確認を行い、とりまとめてレポートを書き起こしています。
このようなデータを取得してレポートにまとめる作業は、手作業でやっていると時間ばかりかかってしまいますが、一度自動化したやると次回から何もしなくても勝手にレポートが出来上がります。
逆にシステムに突発的な障害が発生した場合には、すぐにでも対応する必要があります。このような突発的に発生するシステム障害にも対応できるだけの余裕をもったスケジュールを組んでおく必要があるといえるのです。
社内SEが楽な理由２．仕事への責任が軽い
私は社内SEになる前はソフトウェア開発の仕事をしていましたが、そこでは仕事の責任がとても重いものでした。
プロジェクトが遅延してしまったり、稼働後の不具合により業務を止めてしまった場合の影響度が多きすぎて、ただの若手平社員にもかかわらず常に責任が重すぎました。
この常に責任が付きまとうということで、精神的に疲弊していた部分が大きかったと思います。
社内SEとして仕事をする上で、ベンダー側と最も大きく違うのはこの点かもしれません。
社内SEに責任がないわけではありません。しかしベンダー側にいた頃に感じていた責任と比べると、比較できないほどに楽です。
例えば業務システムの開発１つとっても大きく違います。基幹システムの開発は外部ベンダーへ委託をしていますが、この開発プロジェクトに遅延が発生したとします。
この時、ベンダー側は上司からもお客さんからもプレッシャーをかけられます。
その時の精神状態としてはこんな感じ。
なんとかしてプロジェクトを軌道に乗せなければやばい！サビ残や休日出勤なんていくらでもするからなんとかしなきゃ！ああああうまくいかない、あああああああどうすればいいかわからない…
やばいやばいやばいやばいやばいやばいやばいやばいやばい…..
夜も仕事の夢をみてうなされ、朝会社にいくのが本当に嫌でした。
一方、委託する側である社内SE側の心境はこんな感じです。
ちょっと遅れてんなー、まあバッファとってるから最悪リスケすればいいか、とりあえずここらでベンダーさんのお尻叩いて、プレッシャーかけておいた方がいいかな
あーリスケになっちゃったわクソ、ベンダーさんから報告書もらって部長に報告しなきゃ、あと業務部門の偉いさんにも裏でちょこっと根回ししとくか、あ、今日飲み会だっけ早くあがろっと
同じプロジェクトの遅延をとってみてもこのくらい心境が違います。
この精神的な負担の軽さが、社内SEが楽といわれる最大の理由だと考えています。
社内SEが楽な理由３．成果が必要ない
社内SEの仕事は目に見える成果の指標がありません。
例えば営業ならば四半期毎などの売上目標があり、その目標を達成することが成果として評価に繋がります。
ベンダーSEも同様です。プロジェクトの受注額に対して維持しなければならない利益率が定められており、その範囲内でプロジェクトを遂行することが成果として評価されます。（ちなみに基準となる利益率を割ってしまう場合はサビ残を強いられることもあります）
一方で、社内SEの仕事は利益を生みません。そのため、目標金額や利益率といった分かりやすい達成目標という評価の指標がありません。
社内SEが楽な理由４．スキルが無くても大丈夫
社内SEはスキルが無くても大丈夫です。スキルが無くても務まります。
それはなぜでしょうか？
それは、自分にスキルが無くてできないことがあるのであれば、その仕事を外部へ委託すればいいからです。
結論：社内SEは楽です
社内SEとして大事な心掛け
ひとりで背負わないこと
エンドユーザには親切にすること
楽な社内SEに興味が湧いた、転職してみたいと思われた方は、転職に関する記事も参考にしてみてください。
コメント