[オピニオン from CIO賢人倶楽部]

2024年6月12日(水)CIO賢人倶楽部

　エンタープライズITにおける組織課題の大きな比重を占める問題、それが情報システム（情シス）子会社の存在です。優秀なところもありますが、筆者の知る限り、事業運営や存在価値において問題を抱える情シス子会社が多くを占めるように思います。情シス子会社がなぜ生まれ、問題点が何で、問題解決にはどうすればよいかについて私見を述べます。

情シス子会社のパターン

①コストダウン型

　最も多い情シス子会社のパターンがこれです。事業会社は金を生む事業こそが主軸であって、そうではないバックオフィス業務は外部サービス化されていきます。その第一歩が子会社化。給与水準や待遇が本社よりも低下します。その後、多くの会社が次の②に移行していきます。

②ベンダー売却型

　（親会社の経営者から見て）付加価値を生まず、専門能力もそれほどない情シス子会社は、次のステップへ進みます。例えば大手ITベンダーへの売却です。多くの場合、合弁会社という形を取り、10年ほどITベンダーにフルロックインされるような独占的契約を結びます。同じ人たちが同じ様な仕事を続けますが、立場は外部ベンダーに変わるのです。ここからITベンダーらしく、自社のソリューションを外販できるような③の会社に進化できればよいのですが、多くはそうはなりません。

③ソリューション外販型

　元々は社内用に開発したシステムをパッケージ化して外販し、事業会社化するパターンです。製品が良いと外販比率が高まり、情シス子会社というよりもIT事業会社に変身していきます。外販比率が8割ぐらいになると、経済的にも精神的にも親離れしていきます。それに伴い、親会社の事業部門からは不平不満が増大します。

　他社の案件で忙しく、自社の案件が疎かになっている、と。親会社との関係もビジネスライクに変化して行き、親会社としても身内感が薄れて、外部ベンダーの1社として見るようになり、改めて内部に開発部門を持った情シス部門を持ちたいと思うようになります。

④エンジニアファースト型

　大手銀行などが作るFinTech系スタートアップに多いパターンです。本社の人事評価制度などにとらわれずにデータサイエンティストやAIの専門家を厚待遇で採用するなど、優秀なエンジニアを確保するために別会社を作るわけです。エンジニアファーストで作られる子会社であり、エンジニアはプロフェッショナルとしてのアウトプットが求められ、それに応えられる人のみが生きて行ける世界です。筆者はこのパターンは積極的に評価しています。

情シス子会社のタイプ別の問題点

　①や②の情シス子会社にはどんな問題があるでしょうか？ 1つは親会社とのKPIの不一致です。情シス子会社は売上と利益が主要なKPIになります。そのKPIが、事業会社の親会社と一致しないことでさまざまな不都合が起こります。

　例えばムダなシステムでも作れば情シス子会社の売上成績は上がりますから、子会社のエンジニアは「こんなシステム化、やめた方がいいですよ」が言いにくくなります。親会社から来たシステム案件の妥当性を、システムのプロとして議論する場面が減少します。システムの運用費用も同じで、下げると子会社の売上と利益が減少します。

　デジタルトランスフォーメーション（DX）の実践は、社内業務プロセスのシステム化とは次元が異なります。自社のプロダクトやサービスのデジタル化の実践を、トライアンドエラーを繰り返しながら、高速にプロダクト開発していく組織が求められます。

　何を頼むのにも「システム開発要請書」のような書類を書かなければならない、PoCを行うために社内で「見積書」が行き来するような組織運営からイノベーションは生まれません。

●Next：情シス子会社の改善、こうしてはどうか？