AI時代に問われるIT部門の再定義──DXを成立させるガードレール設計組織へ
itpjstudy
AI活用が急速に広がる中で、多くの企業が「AIによって何が変わるのか」に注目しています。しかし、現場レベルでは、AI以前から進められているDXそのものが、十分に成果を出し切れていないケースも多く存在します。
背景には、技術の問題ではなく、業務部門・IT部門・ITパートナの役割構造そのものの問題があります。
本記事では、数十年前から言われているBPR（Business Process Reengineering）から、昨今のDX、そしてAIへと続く流れを整理しながら、IT部門の本質的な役割を「御用聞き・仲介者」から「ガードレール設計組織」へ 再定義します。
AI時代を語る前に、DXが直面している現実を理解する
AIはインパクトの大きいテーマですが、その前提となるDXが機能していなければ十分に効果を発揮できません。まずは、現場で起きている構造的な問題からお話していきたいと思います。
DXは「システム導入成功」と「業務変革未達」が共存している
プロジェクトの成功をカットオーバーだと定義すると、多くの企業では、プロジェクト自体は成功しています。
- システムは予定通り稼働
- 予算・納期も達成
- ベンダー成果物も完了
しかし、その一方で、業務は、次のような状態に留まっているケースは少なくありません。
- 細かい改善はあるものの、業務プロセスは基本的に現行踏襲ベースになった
- 現場レベルの改善が多く、組織レベルの大きな動き・統廃合はなかった
- システム導入までは全社の注目が集まっていたが、効果刈り取りには労力が割かれていない
👉 「システムは変わったが、業務は変わっていない」
結果的にうまく行っていないDXの問題は、ここにあります。
IT部門が、御用聞き・調整機能に留まっている
IT部門の役割が、次のような役割に留まっているプロジェクトは、多く見られます。
- 業務部門の要望ヒアリング
- ITパートナへの依頼・調整
- 進捗・コスト管理
このような役割に留まっている場合、IT部門は、組織や業務の設計者ではなく、翻訳者・調整者です。
この機能が無いと、いまの業務を続けることができません。
いまの業務ができなくなると、大変ですね。その機能が実現できるかどうか、ITパートナに確認します。
こういった立ち位置では、業務構造そのものに踏み込むことは難しいと言わざるを得ません。
AIはDXを置き換えるものではない
AIは、DXの上位互換なツール・方法論ではなく、むしろ、DXのベースがあることを前提に、そのうえに載る技術です。
- DX未整備企業 → AIは部分最適に終わる
- DX成熟企業 → AIは意思決定の高度化に効く
👉 AIは、DXの「完成度」を増幅する技術であり、DXの下地がなければ、効果を発揮できない
業務改革の原則は、BPRの時代から変わっていない
業務改革の構造は、実は30年以上大きく変わっていません。AIは新しい概念ではありますが、役割構造の原則を変えるものではありません。
業務改革の設計主体は、一貫して業務部門である
BPRの時代から一貫している原則は、明確です。
- 業務を理解しているのは、業務部門
- 効果の大きさを評価するのも、業務部門
- 最終責任を持つのも、業務部門
👉 「何をどう変えるか」は、業務部門が決める領域
IT部門は、変革を成立させる制約条件を定義する
IT部門の本質は「変革そのもの」ではありません。むしろ、役割は逆で、
- 何ができないかを定義する
- 何を守るべきかを定義する
- どこまで自由にしてよいかを定義する
という制約設計の領域です。具体的には：
- データ定義
- セキュリティ設計
- アーキテクチャ設計
- AI利用ポリシー
👉 業務が考える自由な組織・業務プロセスが成り立つための、前提条件を定義する
ITパートナは、システム実装と専門性の提供者
ITパートナは重要な役割ですが、本来的には、高度なITスキルを活かした実装面に重きがあります。もちろん、ある業務領域のスペシャリストとして、最新の業界情報やベストプラクティスを、業務メンバに共有することがありますが、業務を決めるのは、あくまで業務メンバです。
- 技術実装
- 知見補完
- リソース提供
👉 意思決定の主体ではない
なぜ、現在のような役割分担が定着したのか
本来は、業務部門があるべき業務を決定、IT部門は制約条件・前提条件を定義、ITパートナはシステム実装を担当するべきです。しかし、現在の多くのプロジェクトでは、ITパートナに大きく依存した形態で、IT部門は御用聞き・調整役に留まっています。また、業務部門は、形式上の意思決定を行っていますが、実質、IT部門・ITパートナに頼り切っていることが多いように見受けます。
こうなった背景には、幾つかの要因があります。
ERP導入自体が、経営課題
ERPは、企業の基幹業務を支援するシステムです。そこで、昔から構造改革では、基幹業務システム（＝ERP）が重要な要素となっていました。しかし、ERP導入は、非常に難易度の高い取組みです。
そのため、ERPの黎明期の頃から現在に至るまで、「業務改革」を語る以前に、「ERPを稼働させること」が大きな経営課題になっています。
- 技術的に難しく、ユーザ企業だけで対応できない
- 長期のプロジェクトになりがちで、たいてい数年がかりの全社取組みになる
- 投資コストが大きく、失敗したときのリスクが大きい
ERP導入自体は、本来的には手段でしかありませんが、それ自体が経営課題になるほど、難易度の高いものです。
👉 システム導入自体が、そのものが経営テーマとなる
IT部門は御用聞き、ITパートナに依存
その結果、専門的なスキル・知識を持つITパートナに依存する構図が出来上がりました。
多くのプロジェクトで、ITパートナが、情報収集→あるべき姿の提示→実装・テストを一元的に担う。業務部門やIT部門が、ITパートナの成果物をレビュー・承認するという形が定着しました。
👉 設計（あるべき姿の提示）の外部化が、常態化
Fit to Standardという考え方が、ITパートナ依存を助長
ERPは、それぞれのERP固有の業務プロセスのテンプレートを持っています。それらのテンプレートから乖離した業務プロセスを実装しようとすると、追加コストが掛かります。結果、Fit to Standardという考え方が提唱されるようになり、なるべくERPの持つ機能に合うように、業務プロセスを考えることが定着しました。
- ERP標準制約
- カスタマイズコスト
- 開発期間の制約
ERPテンプレートが持つ機能は様々で、広範囲に渡ります。そのため、ユーザ企業が単独で向き合うには難易度が高く、ITパートナへの依存が高まっていくことになりました。
👉 「理想の業務の追及」ではなく、「ERPで実現できる業務の見極め」が重要
AIで、既存のガバナンス構造が急に変わる訳ではない
AIはインパクトのある技術ですが、企業への導入は段階的に進んで行きます。
AIは、まずERP・SaaSの機能拡張として普及する
現実には、AI導入は、次の形を中心として進んで行っているように見ています。
- ERPへのAI機能追加
- SaaSの自動化
- BIの高度化
👉 既存構造の延長として導入される
業務・IT・パートナの基本構造は当面維持される
そのため、短期的には、役割分担は大きく崩れないと考えられます。
- ITパートナが、ERP/SaaSの基盤上で/延長線上で、AI機能を提供
- IT部門は、その導入管理
シャドーAIとEUC領域が新たな統制課題になる
また、AIは容易に使えるため、現場利用が急増します。
- 個人利用のAIツール
- 部門単位の生成AI活用
- データ持ち出しリスク
そのため、EUC（エンドユーザコンピューティング）の領域で、以前から問題になっていたIT部門が管理できていない野良マクロ、野良RPAといった問題が、AIにおいても課題になってきます。
👉 統制の難易度はむしろ上がる
中期的に、IT部門は「御用聞き・仲介者」から「ガードレール設計組織」へ進化する必要がある
中期的には、AIは、従来のERP/SaaSがカバーしていた領域を超えて、ユーザ企業の業務を変えていくことが予想されます。そのインパクトは、ERPやSaaSが登場したときのものとは、比較にならないほど大きいと考えられています。
そうしたときに、重要なのは、どう業務を設計するか以上に、どう制約条件を設計するかということです。AIでは、自由に作れる範囲が飛躍的に大きくなりますが、逆に、抱えるリスクも大きくなるからです。
データ・セキュリティ・アーキテクチャの標準を設計する
企業内でAIやデータ活用が広がるほど、個別最適の設計は限界を迎えます。IT部門が担うべきは、以下のような「共通基盤の設計」です。
- データ定義の統一（マスタ・コード体系）
- システム間連携の標準化
- アクセス権限とセキュリティ設計
- AIが参照するデータの品質管理ルール
ここで重要なのは、「便利さ」よりも「一貫性」です。
👉 一貫性が崩れると、AIもDXも個別最適に戻ります。
また、現場では次のような問題が起きがちです。
- 部門ごとに同じ指標の定義が違う
- AIの入力データがバラバラ
- 判断結果の説明ができない
👉 これを防ぐのが「ガードレール設計」
意思決定ロジックの透明性と再現性を担保する
AIが業務に組み込まれると、「なぜその判断になったのか」が説明できない状態は大きなリスクになります。例えば：
- 与信判断
- 採用判断
- 需要予測
- 価格決定
これらはすべて「意思決定の自動化・半自動化」に向かいます。IT部門の役割は、ここで変わります。
- ブラックボックスを許容しない
- 判断根拠を追跡可能にする
- 人間がレビュー可能な構造を作る
💬「AIがそう判断しました」では済まされない世界になる
そのためには、モデルそのものよりも意思決定プロセスの設計が重要になります。
業務変革を成立させる制約条件を提供する
IT部門の役割は「自由を広げること」ではなく、むしろ逆です。
- どこまで自由にしてよいか
- どこから先は統一すべきか
- どの条件を満たさないとリリースできないか
これらを定義することが重要になります。
つまりIT部門は、
「やりたいことを実現する部門」ではなく
「やってはいけないことを明確にする部門」
に近づきます。
これは一見ネガティブに見えますが、実際にはむしろ逆で、変革の再現性を担保する重要な手段です。
IT部門はリスキリングだけでは変われない
IT部門の変革は「スキル不足」の問題ではなく、「構造の問題」です。つまり、個人の努力だけでは解決しません。
従来の役割定義と評価制度が変革を阻害している
多くのIT部門では、長年、以下のような評価構造が定着しています。
- トラブルを起こさないことが評価される
- 予定通り進めることが評価される
- 新しい挑戦は、リスクとして扱われる
この結果として「変えないことが最適解になる組織」が生まれます。DXやAIのような変化に対応するには、この評価軸そのものを変える必要があります。
外部人材の採用と組織の再構成が不可欠である
リスキリングは重要ですが、それだけでは構造は変わりません。理由は簡単で、
- 過去の成功体験が強すぎる
- 既存の業務モデルが、評価と直結している
- 組織文化は、内部だけでは変わらない
そのため必要なのは、AIプロジェクトを実際に経験・リードしてきた人材、つまり、どういう組織・役割が正解なのか、実体験として知っている人です。
- DX経験者の採用
- データアーキテクトの導入
- プロダクト型思考の人材投入
です。
👉 外部の視点が入らない組織は、過去の延長線から抜け出せない
IT部門自身が変革対象であるという認識が必要
ここが最も重要なポイントです。IT部門は「変革を支援する側」ではなく、まず変革されるべき対象です。
これは現状が問題だという話ではなく、変革の順序の話です。
- IT部門が変わる
- ガバナンス構造が変わる
- 業務部門との関係が変わる
- 初めて、DX/AIが動く
という流れになります。
今回の記事でお話したことは、決して新しいことではありません。何十年も前から言われてきたことです。AI時代が本格化するに際して、これまでも必要だった「カードレール設計組織としてのIT部門」が、いよいよ不可避な要件になってきたということなのです。
ただし、IT部門が変わるというのは、簡単なことではありません。旗振り役であるCIO自身が、旧来のあり方に最も囚われている場合もあります。外部からの風も取りこみつつ、どう変わって行けるかが、今後の企業のDX/AXの分岐点になると考えます。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
