情報システムをコーポレートエンジニアリングにアップデートする

コーポレート部門とは、いわゆるバックオフィスの部門で、CSR、総務、労務、法務、経理、経営企画、内部監査委、それに情報システムなどで組織を構成する。

こういったコーポレート部門の社員のキャリアはとても描きにくい。エンジニアであれば、ITSSなどにあるように、技術の専門別に技術レベルのレイヤーを登っていけばいいのでイメージしやすい。専門技術の他に、アプリエンジニアなら業務ドメインの知識を持っていた方が望ましいが、インフラエンジニアであれば広く深い技術の方が重視される。

一方、コーポレート部門の社員は、担当業務の関連法令のほか、担当業務の自社規程に沿ったオペレーションを行うことを求められる。それはリーダになっても同じである。リーダとメンバの違いは、分掌の業務のカバレッジと組織のマネジメントである。

基本的に仕事はサイクルの定型業務と社員からの申請を起因とする特徴を持っている。

このような業務を是としてオペレーションしているから、業務改善は現行業務の無駄取りか、業務のサービスを受ける社員の評価の改善になってしまう。

原則として、自社規程を守らなければ、コンプラ違反で業務監査で指摘され、是正を求められるからルール通りにやることが一人ひとりの社員に強要される。

情シ部門はコーポレート部門の業務システムのほかに、PC、社内NW、情報セキュリティなど幅広い技術をカバーしなければならない。定常的なシステム運行のほかに、システムのリプレースの企画、導入プロジェクトの実施、現行システムの小改善などのプロジェクト型のタスクやアドホックなPCトラブルなど即対応の依頼を受けやすい業務もある。

ややもすると、技術的にトレンドから取り残されてしまいがちだ。なぜなら、一度入れたシステムは相当出来が悪くない限り、償却が終わるまでは使い続けられるし、最悪なのは、保守切れになっても使い続けられ、それこそレガシーな技術のお守りしなければならない技術環境を自ら作り上げてしまうためだ。

そういったエンジニアとしての不幸な環境を自ら作ってしまうと、エンジニアの技術志向は内を向くようになる。それが続くわけだ。なぜならお守りをするシステムの技術更新はされないからである。

これが定着してしまうと、情シのエンジニアは内ばかり見ているから、外の市場に出てこない。そもそも目が外に向かない。結果、人材が取れないし、技術の古いエンジニアしかいないことになってしまう。

そうしないためにも業務システムはクラウドのSaaSを選択肢に入れるべきだし、SaaSはAPIを叩いてシステム連携するアーキテクチャを採らなければならない。

こうしたアーキテクチャを取る方針を立てることは次のメリットがある。