コーポレートエンジニアについてゆるく考えてみる　コーポレートエンジニアとは編

はじめに

こんにちは、SmartHRという会社でコーポレートエンジニアをしているkoipaiです。

前回の記事では、ぼくのコーポレートエンジニア遍歴についてちょっと自分語りをさせてもらいました。

この記事からは、ぼくのかんがえるコーポレートエンジニアとはなんなのかについて書いていきたいと思います。

前回の記事を読んでいただいた方にはおわかりかと思いますが、ぼくは基本的にいわゆるスタートアップとかベンチャー企業とよばれる業界での情シス経験がメインですので、その視点でのお話だとおもって読んでいただけるとうれしいです。

コーポレートエンジニアとは

よく「コーポレートエンジニアってどんなことするんですか？」と聞かれることがあります。

正直なところ、ぼくもコーポレートエンジニアがなんなのか、まだ明確な答えは持っていません。

コーポレートエンジニアという呼称自体、結構最近できた言葉で、あまり一般的な呼称ではないのかな、というのがぼくの個人的な感想です。

じゃあ、どういう人を指すんだろう、ということなんですが、ぼくの私見では、コーポレートエンジニアとは、情シスとか社内SE、シス管、最近ではコーポレートITと呼ばれている仕事の人達と同一のものかなと思っています。

ただ、あえて「コーポレートエンジニア」という新しい言葉を使うからには、それまでの情シスとは何か違うものがある、差別化をしたいという背景があります。実際、ぼくたちが探しているコーポレートエンジニアも、いわゆる情シス言葉だけでは定義できない領域のスキルセットをもった人を探しているという事実からも、いままでの情シスとはちがうなにかがコーポレートエンジニアという言葉には含まれている、そういう話をしていきます。

情シスってそもそもなんだっけ

コーポレートエンジニアの話のまえに、まず情シスについての考え方を整理したいと思います。

情シス、あるいは情報システム部門とは、社内のIT、システムを主管する部門だと、ぼくは考えています。また、自社プロダクトを持っている企業の場合、プロダクト自体は情シスの管轄外というのがぼくの観測範囲では一般的です。

また、企業によって、社内のシステム、使用する機器やサービス、規模、リテラシーetctecは千差万別です。したがって、情報システム部門に求められるスキルセットも企業によって様々であるというのがぼくの解釈です。

情シスを取り巻く環境の変化

そんな中で、新しい言葉を定義する必要がでてきた理由のひとつには、企業のIT環境の変化があると思います。

SaaS、クラウドの利用の増加によって、これまで情報システム部門の業務の大きな割合を占めていたインフラ管理が不要になる状況が生まれつつあります。

また一方で、領域毎に異なるサービスを組み合わせて使うことや、これまでITを利用しなかった領域にもIT活用の範囲が広がっており、サービス管理の比重が増加しているということもあります。

従業員リテラシーの変化もあります。ITエンジニアの存在や、ビジネスサイドにおいてもITについての専門的な知識を持つ従業員が増加しており、非IT専門職以外の従業員でも、ITサービスを利用して業務を行うのが当たり前になっています。

変化の中で求められる情報システム部門の新たな役割

そうした環境の中で、IT部門には、ITの利活用で企業成長を促進する役割としてのニーズが高まっています。

そのため、これからの情シスには、ITに関する広範かつ高度な知識、技術力が求められ、また、企業内における商材、ビジネスモデル等非技術領域に関しても深い理解が求められます。

新たな価値創造や、自動化、効率化などの業務推進に関わるカイゼンをミッションとしてシステム導入、開発を含め、最適なソリューションを提供するためのプロジェクトを実行するのが、ぼくの考える理想の情報システム部門です。

ここまでくると、もはや従来の情シスや社内SEという言葉だけでは、あまりに指し示す範囲が広く、スタートアップのような企業体においては、必要な人材を定義しきれないという課題がでてきます。

新しい職種を定義する必要性が新しい言葉を生んだのではないかというのがぼくの仮説です。

コーポレートエンジニアという職種

はじめにコーポレートエンジニアは情シスと同じですよ、という話を書きました。

しかしながら、こう考えていくとどうもコーポレートエンジニアという言葉はもっと細かく位置づけをしたほうが理解がしやすそうです。

そんな中で、メルカリさんのITチームの記事にぼくは結構影響を受け、以下のように職種を考えるようになりました。

# エンジニア職
- コーポレートエンジニア
  - 複雑・高度化するIT需要に応えるため、社内サービス、ツールを内製するエンジニア
  - 基本的にコードを書く人
- システムエンジニア
  - システム導入に当たる技術支援、検証、運用を行うエンジニア
  - 必要に応じてカスタマイズなどのためにコードも書く
  
# テクニカルサポート職
- いわゆるヘルプデスク
- 従来と異なるのは、マニュアルベースの業務ではないという点
  - 高いITリテラシーとキャッチアップ能力、コミュニケーション能力が求められる
  
# マネジメント職
- いわゆるマネージャーとしてチームの舵取りやチームビルディングをやる人
- PMとして部署外との調整や、コーポレートエンジニアリング組織が主管しないサービスの最適化を行う人

こんな感じです。

ただ、あくまでこれは理想の組織構成で、肌感では社員100人あたりにつき一人情シス系人材がいればいいかなと思ってます。

なので、たとえばSmartHRが探しているコーポレートエンジニアというはなしになると、この中で、エンジニア職とテクニカルサポート職が両方できる人みたいなイメージになります。

職種ごとのバックグラウンドの仮説

どこにそういう人がいるんだろうという話もチーム内ではよくしています。

ぼくの考えでは、多分いわゆる情シスをやってきた人、では全くはまらないんじゃないかな、というのが感覚です。

エンジニア職でいうと、社内サービス≒社内Webサービスなので、多分Webエンジニア的なスキルセットのひとがいいんじゃないかなあと思ったりシます。インフラもできると嬉しい感じです。

システムエンジニアという視点で見ると、Sierのプリセールスとかやってた人が近そうかなと思ったりします。

テクニカルサポート職は一番むずい気がしています。基本的にはサポート業務なのでユーザーサポートなどの職種の人が最も適正があるのかなあ、とか。

マネジメント職はまだSmartHRではいらないかな、と思いつつ、採るとしたら、EMやってた人、PMやってた人、組織が大きくなるとデザインも考えられると嬉しいかなーという感じです。

コーポレートエンジニアになろう

と題してみたものの、そんなにかんたんな話じゃないなとも思ってます。

というのも、Webエンジニアなどからの転職と考えると、業務内容的には、どうしてもプロダクトエンジニアと比べると成長性に乏しいように思えるし、対人業務や単純作業もぶっちゃけあるのでそこ懸念で、敬遠されそうだなーとか。

一方で、テックサポート職でコーポレートエンジニアという冠をつけると、プログラミング経験がない、などを理由に敬遠されそうだなーとか。

市場的に情シスの括りだと平均給与と差が出たりして後々の転職難しくなっちゃうかなーとか。

いろいろ、新しい職種はむずかしい事が多いですね。

ということで、次回はコーポレートエンジニアになりたいという人の向けに、コーポレートエンジニアの面白さについて書けたらなと思ってます。

ではまた。