「ITは経営戦略そのもの」といった言葉は筆者がITコンサルを始めた20年前から存在していて、「そのためにIT部門は何をすべきか」といった議論がずっと行われてきた。
しかし現実には、多くの企業でIT部門は「事業を変える部門」ではなく、「既存システムを止めない部門」「開発ベンダーを管理する部門」「コスト削減の対象」として扱われている。その結果、ITは経営の武器にならず、むしろ変化を妨げる制約になっている。
この状況は、20年たっても何も変わっていない。 企業のIT担当役員は相変わらず高いコンサルフィーを払い続けている。あげくは、CIOを外部から招いて、ベンダーを入れ替えるなど、同じことの繰り返しをしている。
「IT」を「DX」に変えたところで、なにもトランスフォーメーションは起きていない。
以下は、コンサルファームが作る提案書の「IT部門の課題」からの抜粋である。 目にした方も多いだろう。またこれか、と思った方は、何度もコンサルタントに期待しては裏切られた経験があるに違いない。
IT部門の本来の役割
IT部門の本来の役割は、大きく分けると次の5つに整理できる。
1つ目は、事業戦略をシステム構想に翻訳することである。経営が目指すビジネスモデル、顧客体験、業務プロセスを理解し、それを実現するためにどのようなデータ、アプリケーション、基盤、外部サービスが必要かを設計する。
2つ目は、全社最適の視点でデータと業務プロセスを整えることである。事業部門ごとに個別最適でシステムを作り続けると、データは分断され、顧客や商品、取引の情報を横断的に活用できなくなる。経済産業省のDXレポートでも、既存システムが事業部門ごとに構築され、過剰なカスタマイズによって複雑化・ブラックボックス化することがDXの阻害要因として指摘されている。
3つ目は、技術的負債を管理することである。短期的な要望に応じて改修を積み重ねるだけでは、システムは徐々に複雑化し、変更コストが上がり、いずれ事業変化に追随できなくなる。IT部門は、目先の開発だけでなく、将来の変更容易性、保守性、セキュリティ、運用性を含めて設計する責任を持つ。
4つ目は、外部ベンダーを使いこなすことである。外部委託自体が問題なのではない。問題は、判断基準や設計思想を自社が持たないまま、要件定義から設計、開発、運用までを丸投げしてしまうことである。IT部門は、外部パートナーを活用しながらも、アーキテクチャ、品質、リスク、知識の蓄積については自社側で主導権を持つ必要がある。
5つ目は、セキュリティとレジリエンスを経営課題として扱うことである。システム障害やサイバー攻撃は、もはやIT部門だけの問題ではなく、事業継続、顧客信頼、サプライチェーン全体に影響する経営リスクである。
役割が十分に果たせていない現状
多くの企業では、IT部門が本来担うべき役割を十分に果たせていない。典型的には、次のような状態に陥っている。
第一に、IT部門が「守りの部門」になっている。システムを止めないこと、障害を起こさないこと、コストを抑えることが主な評価軸となり、事業を変える提案や新しい仕組みの構想に十分な時間を割けない。
第二に、既存システムの維持に人材と予算を奪われている。経済産業省のDXレポートは、老朽化、肥大化、複雑化、ブラックボックス化したITシステムが、経営・事業戦略上の足かせとなり、戦略的なIT投資に資金や人材を振り向けられない状態を指摘している。
第三に、IT部門が事業部門の「御用聞き」になっている。事業部門から出てきた要望をそのままシステム化し、全社としてのデータ設計や業務標準化を十分に検討しない。その結果、部門ごとの個別最適が積み重なり、後から全社横断のデータ活用をしようとしても、データの定義や粒度が揃わない。
第四に、障害やインシデントへの備えが形式的になっている。金融庁の「金融機関のシステム障害に関する分析レポート」では、冗長構成が意図どおり機能しない、障害復旧手順・体制の整備不足、外部委託先管理の不十分さ、BCPや危機管理体制の不備などが、実際の障害事例として指摘されている。
開発ベンダー丸投げに陥る理由
日本企業のIT部門が開発ベンダーへの丸投げに陥りやすい背景には、構造的な理由がある。
最大の理由は、IT人材がユーザー企業側に少ないことである。経済産業省のDXレポートでは、日本ではITエンジニアの多くがベンダー企業に所属しており、ユーザー企業側にノウハウが残りにくい構造が指摘されている。さらに、多重下請け構造の中で、実際に現場作業をしている下請け企業にノウハウが蓄積され、発注元であるユーザー企業には知識が残りにくい。
次に、契約と調達の仕組みが丸投げを助長している。多くの企業では、システム開発を「仕様を決めて発注し、納品物を受け取る」取引として扱う。そのため、発注側は要件定義書やRFPを作ることに注力し、開発の過程で仮説検証を繰り返しながら事業を改善する発想になりにくい。
また、失敗責任を外部化したい心理もある。システム開発は不確実性が高く、仕様変更や障害も起こりうる。社内で責任を持って内製するよりも、大手ベンダーに発注した方が、形式上はリスクを移転できるように見える。しかし実際には、顧客影響、業務停止、データ不整合、セキュリティ事故の責任は、最終的には発注企業に残る。
さらに、社内に判断できる人がいないため、ベンダーの提案を評価できない。技術選定、アーキテクチャ、テスト方針、運用設計、セキュリティ対策について、発注側が十分に理解していなければ、ベンダーから出てくる提案の妥当性を評価できない。結果として、価格、会社規模、過去の取引実績といった表面的な要素で意思決定してしまう。
人材育成がうまくいかない理由
IT部門の人材育成がうまくいかない理由も、単なる教育不足ではない。
第一に、必要な人材像が定義されていない。IPAの「DX動向2024」では、日本企業ではDXを推進する人材不足が深刻化しており、特に事業会社で不足が大きいこと、また自社に必要なDX人材像や評価基準を持たない企業では人材不足がより顕著であることが指摘されている。(IPA)
第二に、育成の場がない。研修でクラウド、AI、データ分析、アジャイル開発を学んでも、実際のプロジェクトで意思決定し、設計し、運用し、改善する経験がなければ、実務能力は身につかない。ところが、多くの企業では重要な開発や運用の実作業を外部に出しているため、若手や中堅社員が技術的な経験を積む機会が乏しい。
第三に、IT人材のキャリアパスが曖昧である。高度な専門性を持つ人材を育てるには、技術を深めるキャリア、事業とITをつなぐキャリア、プロダクトを持つキャリア、セキュリティやアーキテクチャを担うキャリアなど、複数の道筋が必要である。しかし、従来型の人事制度では、ゼネラリスト的な異動や管理職昇進が中心となり、専門性を継続的に高めにくい。
第四に、IT部門が魅力的な仕事を持っていない。既存システムの保守、ベンダー調整、稟議資料作成、障害対応ばかりでは、優秀な人材は集まりにくい。事業に近い場所で、顧客価値や収益に直結するシステムを作る経験がなければ、IT部門は成長の場として見られない。
問題事象の事例
みずほ銀行のシステム障害
2021年のみずほ銀行の一連のシステム障害では、金融庁が業務改善命令を出した。金融庁は、2021年2月から9月にかけて顧客に影響を及ぼすシステム障害が計8回発生したこと、直接原因として開発・障害対応における品質検証不足、保守・運用管理態勢の不備、委託先管理の不十分さ、危機対応訓練の不足などを指摘している。(金融庁)
さらに重要なのは、金融庁が技術的な直接原因だけでなく、経営・組織の問題を指摘している点である。執行部門がIT現場の実態を十分に把握しないまま安定稼働を過信したこと、保守・運用に必要な人員配置や維持メンテナンス経費の削減を進めたこと、取締役会がシステムリスク管理態勢を十分に整備していなかったことなどが問題とされた。(金融庁)
この事例は、IT障害が「システムの問題」ではなく、「経営がITの実態を把握できていない問題」であることを示している。
金融機関における外部委託先管理の不備
金融庁の2024年の分析レポートでは、資金清算機関のシステム更改において、委託元による外部委託先のレビュー体制やテスト内容の確認が十分でなかったこと、外部委託先への牽制が不十分だったことにより、為替業務が一部金融機関で不能となる事案が挙げられている。また、プロジェクト固有のリスクを踏まえたBCPや大規模障害を想定した危機管理体制が十分でなかったため、復旧に時間を要し、多くの顧客に影響が及んだとされている。
これは、外部委託そのものではなく、発注側がレビュー、テスト、リスク管理、BCPを主導できていないことが問題であることを示している。
小島プレス工業へのサイバー攻撃とトヨタ国内工場停止
2022年には、トヨタ自動車の仕入先である小島プレス工業がサイバー攻撃を受け、トヨタの国内全14工場が停止する事態となった。小島プレス工業の調査報告書では、子会社が特定外部企業との専用通信に利用していたリモート接続機器の脆弱性をきっかけに不正アクセスを受け、ランサムウェアにより一部のサーバや端末のデータが暗号化されたことが示されている。(トヨタイムズ)
この事例は、企業のITリスクが自社内に閉じないことを示している。サプライチェーンの一部で起きたシステム停止が、大企業の生産活動全体に影響を及ぼす。IT部門は、自社システムだけでなく、重要取引先、外部接続、クラウドサービス、委託先まで含めたレジリエンスを考える必要がある。
根本原因：ITを「経営能力」として扱っていない
これらの問題の根本原因は、ITを「経営能力」として扱ってこなかったことにある。
ITをコストセンターと見なすと、経営はIT投資をできるだけ抑えようとする。すると、既存システムの保守費は削られ、技術的負債は放置され、人材育成は後回しになる。その結果、システムは複雑化し、変更できなくなり、さらに維持コストが増える。
ITを外注可能な作業と見なすと、社内に知識が残らない。最初は効率的に見えても、長期的には自社の業務、データ、システム構造を理解する人が減り、ベンダーの提案を評価できなくなる。やがて、事業を変えたい時に、どこをどう直せばよいのか分からない状態になる。
ITを事業部門の要望処理と見なすと、全社最適が失われる。各部門の要望を個別に実現するほど、システムは複雑化し、データは分断される。短期的には現場満足を得られても、中長期的には全社の変化対応力を低下させる。
ITを専門家だけの問題と見なすと、経営がリスクを理解できない。みずほ銀行の事例が示すように、経営がIT現場の実態を把握せず、安定稼働を過信し、必要な人員やコストを削減すれば、現場の対応力は弱体化する。(金融庁)
つまり、企業のIT部門の課題は、IT部門単体の能力不足ではない。経営、事業部門、人事制度、調達制度、ベンダー構造を含む、企業全体の設計問題である。
これからのIT部門に求められる方向性
これからのIT部門は、単なる運用管理部門でも、ベンダー管理部門でもなく、事業変革の中核機能になる必要がある。
そのためには、まず経営がITをコストではなく投資として扱う必要がある。デジタルガバナンス・コード3.0でも、DXに投じる資金はコストではなく価値創造に向けた投資である、という考え方が示されている。
次に、IT部門は事業部門と一体になって、業務・データ・システムを再設計する必要がある。単に要望を聞いて開発するのではなく、事業のあるべき姿から逆算して、どの業務を標準化し、どのデータを共通化し、どこに競争領域を置くのかを考える。
さらに、すべてを内製化する必要はないが、少なくともアーキテクチャ、データ設計、セキュリティ、品質、運用、ベンダー評価に関する中核知識は社内に持つべきである。外部ベンダーは「丸投げ先」ではなく、事業成果を共に作るパートナーとして活用する。
最後に、人材育成を研修だけで終わらせてはいけない。実プロジェクトで責任を持たせ、作ったものを運用し、障害や改善を経験させることでしか、IT部門の実力は高まらない。必要なのは、知識教育ではなく、事業とシステムの両方に責任を持つ経験の設計である。
おわりに
企業のIT部門が抱える問題は、単に「人が足りない」「技術が古い」「ベンダーに依存している」という表面的な問題ではない。根本には、ITを経営の中核能力として扱ってこなかった歴史がある。
これからの企業競争力は、業務、データ、ソフトウェア、セキュリティをどれだけ一体で設計できるかに左右される。IT部門は、システムを守るだけの部門から、事業を変える部門へと役割を変えなければならない。
その変革は、IT部門だけでは実現できない。経営がITを理解し、事業部門が業務変革に責任を持ち、人事が専門人材を育て、外部ベンダーとの関係を再設計する必要がある。IT部門の課題とは、実は企業経営そのものの課題なのである。