Insight EdgeのLead Engineer 日下です。
ITエンジニアというと、どのような会社で働いているイメージがありますか？
多くの場合は、IT業界用語でいうところの「ベンダー企業」と呼ばれるSIerやソフトウェアベンダーなどのシステム構築関連業務を受託する会社か、「Web系」と呼ばれる自社でWebサービスを運営している会社で働いていることをイメージされると思います。一方、その他の業種の事業会社は、ITシステムを他社から調達して使用することから「ユーザー企業」と呼ばれており、ITエンジニアの働く場というイメージは薄いかもしれません。
本記事では、SIerで顧客向けシステム開発に従事した後、事業会社の内製ITエンジニアに転じた私自身の経験も踏まえながら、事業会社のITエンジニアの仕事の特徴や面白さについてご紹介します。
（以降では、ITエンジニアを指して「エンジニア」と略称します。）

事業会社のIT人材に求められるスキルの変化

「ユーザー企業」と呼ばれる事業会社においてもIT人材の役割や組織は以前から存在しており、「IT部門」や「情シス」と称され社内のOA系インフラやITシステムの導入・運用、システム開発プロジェクトのマネジメントなどを行ってきました。従来型のシステム開発プロジェクトにおける事業会社のIT部門の役割は、例えば以下のようなものがあります。

  • 利用者となる事業部門と連携しながら、システムの要件を定義する
  • システム開発ベンダー（SIer等）を選定、発注する
  • システム開発ベンダーの作業進捗や成果物の管理、レビューや検収を行う

これらの業務はベンダーコントロールと呼ばれ、システム設計やプログラミングとは別種のマネジメントスキル等も必要な高度な仕事なのですが、開発の現場からはやや離れているため、技術力を活かしたい／磨きたいエンジニアにとっては魅力的ではない仕事として映りがちになっていました。しかし、近年ではDXの隆盛にともない事業部門との密な連携や迅速な開発・検証サイクルを実現するために、ベンダー企業への外注比率を減らしエンジニア組織を自社に抱えてシステムを内製する事業会社が増えてきており、ベンダーコントロールだけでなくシステムの設計や開発作業そのものを自ら推進できるエンジニアの活躍の場が増えています。

IT人材白書
ユーザー企業の社内にITスキルを蓄積・強化するための内製化状況【DX取り組み別】
出典: IPA 社会基盤センター 「IT人材白書2020」※1

Insight Edgeもそのような潮流とともに生まれた内製エンジニア組織であり、技術の力を駆使して住友商事グループの多種多様なビジネスにスピーディに貢献することをミッションとしています。

内製エンジニアの面白さとは？

ここからは、事業会社の内製エンジニアの仕事について私が感じている魅力や面白さをお話ししていきたいと思います。前提として私の経歴にも少しだけ触れておくと、Insight Edgeに入社する前は大手SIerにて顧客向けシステム開発のシステムアーキテクトや開発リーダーを担当していました。SIerでのシステム開発というと大規模なシステムをウォーターフォールプロセスで開発していくイメージがありますが、私が担当していたのは顧客企業のDXを支援する情報系システムの構築が中心であり、クラウドサービスを活用したサーバレスアーキテクチャのシステムをアジャイルで開発し、自らもコーディングやテストを行うといったプロジェクトも担当してきたので、開発スタイルや技術スタックはInsight Edgeと似ている部分も多くあります。
以下の節では、内製エンジニアの仕事の特徴をより具体的にイメージしやすくなるように、SIerでの受託開発の経験に基づいた対比も交えながらご紹介していきます。

利用者との距離が近い

受託開発では、ユーザー企業とベンダーは契約によって成り立っている取引関係であるため、責任の分担や切り分けを明確化するために要件や見積もりの条件を文書で細かく記載したり、会話のやりとりも細かく記録を残すなど、資料作成やコミュニケーションのオーバーヘッドが大きくなる傾向があります。また、開発したシステムに対してさらなる改善を提案しても、ユーザー企業側に開発予算がつかなければ実行に移すことができないなど、契約関係の都合によりエンジニアとしての力を発揮できない場合があります。

内製エンジニア組織では、開発対象となるシステムの所有者が自社（または同じ資本系列の会社）であるため、契約関係による堅苦しさや駆け引きなどに気を取られることなく、エンジニアとして心置きなく技術力を活かすことができます。また自社内で利用するシステムであれば、利用者との距離が近いことから喜びや不満の声が届きやすく、自分の仕事の成果を身近に感じることができるため、やりがいを感じやすいことも面白さの1つです。このように、システムを利用する事業部門との組織的／心理的な距離が近く、かしこまらずに気軽なコミュニケーションができるため、ビジネス価値を高めるための仕事に集中しやすい関係性にあります。

新しい技術を試しやすい

受託開発のプロジェクトでは、世に出てから時間が経ち事例も豊富な、いわゆる「枯れた技術」が好まれます。ユーザー企業がベンダーにシステム開発を発注するということはIT技術やプロジェクト管理に対する専門性をベンダーに求めているため、ベンダー側は社内や業界内に利用実績やノウハウが蓄積されていて信頼性が高く、扱える要員を確保しやすい技術を選択する必要があるためです。また、ユーザー企業はベンダーの成長のためではなく今のプロジェクトを成功させるためにお金を払っているため、そのような関係においてベンダーが実績の少ない新しい技術を採用することは、ベンダー側の学びのためにユーザー企業を実験台にするような話であり、長期的かつ強固な信頼関係がなければ難しいと言えます。

一方、内製エンジニア組織の場合、目先のプロジェクトの成功だけに限らずエンジニア組織が成長することも自社の成長につながるため、受託開発のプロジェクトと比較すると不確実性に対する試行錯誤やチャレンジングな技術選定がしやすい傾向があります。特にDX分野においては、本番システムの開発に先立ち、ビジネス側との認識・課題共有や実現性・価値検証を目的としたプロトタイプを開発する機会が多くなります。このような検証用プロトタイプの場合、利用者の期待品質が本番ほど高くないことや、検証の結果をもとに本番システムの開発に向けて採用技術を再検討するチャンスがあるなど、本番システムの開発に比べて新たな技術を試しやすい状況であり、そのような機会を活用してビジネスに貢献しながらもエンジニアのスキルアップも意識した技術選定ができます。
Insight Edgeでの最近の例を1つ挙げると、今春に正式リリースされたAWS Amplify Studioを用いた迅速なモックアップ開発やアプリケーション開発を試行しています。

「作らない」ことも重要

開発エンジニアにもかかわらず「作らない」ことが重要というと不思議に感じるかもしれませんが、自社でシステムを内製する場合、自社ビジネスの付加価値や生産性を向上させることが目的であり、開発することはあくまでも手段になります。したがって、ビジネス価値に見合うかどうかを常に意識して開発することが重要です。

受託開発の場合、開発やシステム運用などの作業を受注すること自体がベンダー企業のビジネスそのものであることから 作る＝売上 となるため、ベンダー内部で効率的に作るための工夫はするものの、基本的に「作ることありき」な提案に傾きやすくなります。
一方、事業会社で内製する場合、事業部門のビジネスの収益向上が目的であるため、作る＝コスト となります。そのため、投資対効果の低いシステムや機能はそもそも作らないという判断をすることもありますし、作る場合でもSaaSやPaaS等のマネージドサービスやノーコード/ローコード開発ツールの活用を検討して「コードを書かない」という選択をすることも多く、作らない/コードを書かないための考え方やスキルも重要になります。
私自身はコーディングも苦にならないタイプのエンジニアではあるものの、上記のような「作らない」技術を活用して少ない工数で要件を満たせるシステムを実現できたときは、複雑なプログラムを書いて実現したとき以上に嬉しく感じることも多々あります。

まとめ

本記事では、事業会社の内製エンジニアの仕事の特徴や面白さを、システム開発ベンダーとの比較を交えながらご紹介しました。Insight Edgeでは、住友商事グループの事業領域を対象に、内製エンジニア組織として様々なDXプロジェクトを実施しています。事業部門と密に連携し、ビジネス価値を重視した開発を推進しながらもプロジェクトの特性に応じて新たな技術にチャレンジするなど、エンジニアとしても成長できる組織づくりを行っています。
本記事を読んでいただき、より詳しい情報を聞きたい方、興味のある方は、是非HPからお問い合わせください！