DXが進まない企業の多くは、原因を「IT人材の不足」に求めます。しかし本当に欠けているのは、エンジニアの頭数ではありません。自社の業務プロセスを可視化し、システム要件として再定義できる人材です。総務省「令和4年版情報通信白書」では、DX推進の課題として「人材不足」を挙げた企業が日本は67.6%にのぼり、米国の44.8%を大きく上回っています。この差は採用市場の問題である以上に、日本企業の多くが「開発力」を補えば解決すると誤認している体制設計の問題を映しています。
技術とビジネスの分断が招くプロジェクトの頓挫
DXプロジェクトの現場では、技術とビジネスの間に明確な分断が起きています。
ITエンジニアは、企業独自の商習慣や業務フローを理解していません。一方で現場の業務担当者は、自部門の課題をシステム要件として言語化できません。両者をつなぐ「翻訳」の役割が体制上どこにも割り当てられていないため、開発は要件定義の段階から行き詰まります。
これは個人の能力不足ではなく、体制構築のミスです。DX推進に不可欠なのは、複雑な業務を構造的に可視化し、システム要件へ翻訳する「業務モデリング能力」であり、この役割を担うのがビジネスアナリストです。この機能を組織のどこにも配置しないまま、ITエンジニアの採用だけを進めても、プロジェクトの構造的な欠陥は解消しません。
ビジネスアナリスト不在の組織で起きる典型的な機能不全
自社の体制に次の兆候が多く当てはまるほど、業務モデリング機能の欠落が深刻です。
- 要求定義のすれ違い：IT部門と業務部門で要件の解釈が異なり、開発の手戻りが常態化している
- PoCの乱立：業務課題の解決ではなく、最新技術の導入自体が目的化している
- 現行プロセスの単純なデジタル化：非効率な既存業務を見直さず、そのままシステムに置き換えている
- ベンダーへの丸投げ：自社で要件をコントロールできず、プロジェクト管理を外部に依存している
- 目的を欠いたトップダウン：経営層の指示が「とにかくDXを進めろ」という抽象的な内容にとどまっている
ITスキル偏重の体制とビジネスアナリシス重視の体制を比較する
最新技術の導入を優先する体制と、業務プロセスの再設計を前提とする体制では、プロジェクトの成果に明確な差が生じます。両者のチーム編成の違いは次の通りです。
| 比較項目 | ITスキル偏重の推進体制 | ビジネスアナリシス重視の体制 |
|---|---|---|
| 中核となる人材 | エンジニア、データサイエンティスト | ビジネスアナリスト、業務設計専門家 |
| プロジェクトの起点 | 導入したい最新技術やツール | 現場が抱える本質的な業務課題 |
| 要件定義の主体 | IT部門および外部ベンダー | 業務部門とIT部門をつなぐ専任者 |
| 開発アプローチ | 現行業務の単純なデジタル化 | 業務プロセスの抜本的な再設計 |
| 人材不足への対応 | 高度IT人材の採用難で停滞する | 社内の業務理解者をリスキリングする |
技術主導の体制は、システムの完成をゴールと錯覚しがちです。結果として、現場の実態に合わない、使われないシステムが量産されます。ビジネスアナリシスを重視する体制は、業務課題の抽出からスタートし、技術はあくまで課題解決の手段として位置づけられます。
業務モデリング能力を社内で育成する手順
業務変革を牽引する人材に必要なのは、プログラミングスキルではなく、複雑な業務を構造化し再設計する「業務モデリング能力」です。必須要件は次の3点に集約されます。
- 業務プロセスの可視化能力：属人化した業務をフローチャート等で客観的に記述する力
- 課題の構造的把握能力：表面的な問題にとらわれず、根本的なボトルネックを特定する力
- システム要件への翻訳能力：再設計した業務プロセスを、エンジニアが理解できる要件として定義する力
多くの企業が陥る失敗は、現場社員に向けた一律のプログラミング教育です。非IT部門の社員に必要なのは、コードを書く技術ではなく、自部門の業務を抽象化し、論理的に再構築する思考法です。育成の基本フレームワークは次の3段階です。
- 現状（As-Is）の可視化：現行業務の全手順と入出力データを洗い出す
- 非効率の特定と排除：ムダ、重複、属人的な判断基準を特定し、業務から切り離す
- 理想（To-Be）の設計：デジタル技術の活用を前提とした新たな業務フローを構築する
誰を最初の育成対象にするか
社内公募や適性検査でビジネスアナリスト候補を選ぼうとすると、選定基準が曖昧になり長期化しがちです。優先すべきは、システム部門の経験ではなく、複数の部門をまたいで業務を回してきた実務経験です。具体的には、次の条件に当てはまる人材が候補になります。
- 特定の業務プロセスについて、担当者以上に全体の流れと例外処理を説明できる
- 他部門との調整業務（申請の受け渡し、承認フローの管理など）を日常的にこなしている
- 「このやり方はおかしい」と感じた業務改善の提案を、過去に一度でも行ったことがある
エンジニア経験の有無は必須条件ではありません。むしろ、現場の業務を熟知した人材に業務モデリングの型を教えるほうが、エンジニアに業務知識を教えるより短期間で機能し始めます。
実行時の落とし穴
業務モデリング機能を新設しても、既存の業務部門から独立した「デジタル推進室」に隔離してしまうと機能しません。業務課題の当事者から切り離された場所で要件を定義しても、現場の実態と乖離した仕様になりがちです。ビジネスアナリスト機能は、事業部門の意思決定の近くに置く必要があります。
もう一つの落とし穴は、育成を「研修一回」で終わらせることです。業務モデリング能力は、実際のプロジェクトで現状の可視化から要件定義までを一通り経験しなければ定着しません。最初の案件は、範囲を絞った業務プロセスひとつに限定し、小さく成功体験を積ませる設計が有効です。なお、ベンダーへの丸投げが常態化している組織は、RFP作成と要件定義の内製化から着手したほうが、業務モデリング人材の育成も同時に進みます。
DX推進における人材不足の本質は、プログラマーの不足ではありません。自社の業務構造を理解し、それをシステム要件として定義できる人材の欠如です。DXが失敗する構造的な原因の中でも、この体制の欠陥は最も見過ごされやすい要因のひとつであり、採用ではなく体制設計から着手する必要があります。
