はじめに
会社として「DXを進める」と声高に言っている一方で、上層部がそれを自分事として捉えず、部下や担当者に対して叱咤だけが飛んでいる――そのような状況をよく目にします。
私自身、現場に入り込んでプロジェクトの動きを見てきましたが、うまくいかない理由は「担当者の知識不足」といった単純な話ではないと感じています。
一方、米国などではトップダウンが強く、かつ経営層がITの知識をある程度持っているケースも多いため、相対的にシステム変革が進みやすい印象があります（もちろん例外はあります）。
私はいくつものDX案件に関わる中で、「なぜうまくいかないのか」を考える機会が増えました。昔は「情シス部が先頭を切って推進しなければならない」という空気があり、弱い立場になりがちな情シス部がドメイン知識を十分に持たないままデスマーチに巻き込まれていくこともありました。事業部側はそれをどこか他人事のように見てしまう、という構図もあったように思います。
一方で現在は、「事業部こそが先頭を切って推進しなければならない」という風潮に日本全体が寄っています。しかしその結果、ITリテラシーが十分でない事業部が、さらに「プロジェクトをまとめた経験がない」という致命的な事情も重なって、頓挫してしまうケースを多く見ています。そうなると情報システム部門にも飛び火し、結局どちらにとっても良い結果になりません。
このような状況を少しでも打破するために、どうすればよいのかを整理してみました。
また、私は近いうちに独立して起業し、ITコンサルタントとして活動したいと考えています。現職で見えている状況を客観的に捉え、解決方法をサジェスチョンすることは、今後の自分にとって重要なインプットになるはずだと考え、この記事を書きました。
私は本を読むのが好きで、欧米・日本のマネジメントやDX関連の書籍も幅広く読んできました。そのインプットを踏まえて書いているため、一般にあまり語られていない切り口も含まれているかもしれません。結果として、私の思い違いが含まれる可能性もあります。
ただ、DX案件の失敗で「何が起きているのか」「どうすれば少しでも改善できるのか」をできる限り突き詰めて考えてみましたので、興味があれば読んでいただけると嬉しいです。
DXに必要な「知識」について
DX推進で必要となる「知識」には、大きく3つあると考えています。
それは「ドメイン知識」「デジタル知識」「特有知識」です。以下、それぞれ説明します。
-
ドメイン知識：その事業を行う上で必ず必要となる知識です。
例えば会計であれば「減価償却費」の理解が必要で、これは「投資費用」と密接に関連しています。こうした知識がないと、業務継続できるシステム構築は難しくなります。 -
デジタル知識：ITやシステムに関わる知識です。
例えばシステム構築では、Webブラウザから利用するならWebサーバが必要で、データを扱うならデータベースサーバが必要になる、といった基本があります。この知識がないままドメイン知識だけで進めると、最終的に「Excelのお化け」を運用で抱え込まざるを得なくなりがちです。 -
特有知識：「ドメイン知識」「デジタル知識」だけでは網羅できない、その会社・その現場に固有の知識です。
例えばDX化したい仕組みにおいて、該当のExcelファイル（例：P/L表）が「どのデータをインプットとしているのか」、また「後続でどのように利用されるのか」といった前後関係・依存関係の理解が該当します。これも把握が必要です。
この3つの知識を揃えて、はじめてDXを遂行できる土台ができます。
ただし、これらの知識には次章で示すように「一般仕様」と「固有仕様」があり、さらに固有仕様には「表出的仕様」と「暗黙的仕様」があります。ここを考慮しないと、プロジェクトは簡単に崩れます。
DXの「仕様」について
次に、上記3つの知識に関して、ユーザ部門側とIT部門側の間で**「情報の非対称性」**が起こる場合があります。
この背景として「一般仕様」と「固有仕様」があり、さらに「固有仕様」は「表出的仕様」と「暗黙的仕様」に分かれる、と整理できます。
-
一般仕様：世間一般に知られている仕様です。「ドメイン知識」や「デジタル知識」に多く含まれます。
ユーザ部門へのヒアリングがなくても、ベンダー側に知見が蓄積されていることが多く、ここは比較的問題になりにくい領域です。 -
固有仕様：対象企業にのみ存在する仕様です。
一般にこの領域の情報非対称性を排除するには、ユーザ部門からのヒアリングやインタビューが必要です。それでも表出が難しい場合は、エスノグラフィー等を用いて一定期間観察し、実態から仕様を掘り起こす方法もあります。
ただし固有仕様はさらに、次の2つに分かれます。- 表出的仕様：固有仕様ではあるものの、ヒアリングや観察などの手段で「情報の非対称性」を解消できた仕様です。
- 暗黙的仕様：固有仕様であり、かつユーザ側からベンダー側にアウトプットできていない（またはできない）仕様です。ここが残ったままDXを進めると、プロジェクトが混乱したり頓挫したりする原因になり得ます。
したがって、可能な限り「固有仕様」のうち**「暗黙的仕様」**の領域を小さくしてDXに臨む必要があります。
ただし、領域を小さくするには時間とお金がかかる点は重要な留意事項です。
以下、整理すると次のようになります。
| 知識＼仕様 | 一般仕様 | 固有仕様（表出的） | 固有仕様（暗黙的） |
|---|---|---|---|
| ドメイン知識 | 業界・会計・法務など「一般に共有される業務知識」です。 例：減価償却、売上計上、在庫評価の基本など。 |
自社ルールとして明文化・説明可能な業務仕様です。 例：自社の勘定科目運用、承認フロー、部門別の締め手順（資料・規程・ヒアリングで表出できます）。 |
現場の判断・例外処理・慣習など、言語化されにくい業務仕様です。 例：「このケースだけはこうする」「担当者の経験で調整する」など（放置すると運用混乱の火種になります）。 |
| デジタル知識 | ITの一般知識（方式・技術要素・原則）です。 例：Web/DB、権限、監査ログ、バックアップ、性能、セキュリティの基本など。 |
自社のIT環境として説明可能な制約・設計情報です。 例：既存システム構成、ネットワーク制約、認証方式、運用手順書、非機能要件（資料・関係者ヒアリングで表出できます）。 |
暗黙に存在する依存関係・ブラックボックス・属人運用です。 例：誰も全体を把握していない連携、秘伝の設定、実は手作業で辻褄を合わせている運用、シャドーITなど（移行・改修で爆発しがちです）。 |
| 特有知識 | 「よくある型」として一般化された周辺知識です（完全な一般仕様ではないが、パターンとして再利用しやすい領域です）。 例：Excel集計→転記→承認→報告、マスタ整備不足に起因する突合の典型など。 |
自社固有の入出力・データ流通・利用関係を説明可能にしたものです。 例：P/L表が参照する入力データ一覧、作成タイミング、後続（会議資料・予実管理・経営報告）での使われ方、IF一覧（棚卸しで表出できます）。 |
「そのExcelはなぜそうなっているのか」を誰も説明できない、もしくは説明しても漏れる領域です。 例：会議直前の手修正、非公式なデータソース、担当者しか知らない計算根拠、月末だけ発生する調整など（要件定義の抜け・手戻りの主要因になります）。 |
ではどのように進めていけばよいのか
コンサルタントは理路整然と「まずは現行業務を整理して……」と言いますし、上司や役員もそれをロジカルに理解しきれないまま「なぜウチはDXが進まないのか」と口にしがちです。
しかし根本的には、上司や役員がDXを「自分事」として背負えていないことが大きいと感じます。仮に「DXが失敗したら責任を取る」という前提に置かれたとき、意思決定の質や優先順位は変わるのでしょうか。
現実には、担当者側に責任が寄ってしまう場面もあり、日本企業の構造的な課題だと思います。
とはいえ愚痴だけでは前に進みませんので、現実的に取り得る進め方の案を整理します。
1．「暗黙的仕様」を諦めて、とりあえずリリース
一般的な「システム再構築」では、部分的にこの判断が行われていることもあると思います。
暗黙的仕様をユーザから引き出すのはコストと時間がかかるため、そこを割り切り、ステークホルダーのスコープを小さくして早期リリースを狙うやり方です。
ただし、暗黙的仕様の領域が大きすぎる場合、リリース後に運用が回らず、大混乱を招く可能性があります。
2．「暗黙的仕様」を理解領域に含め、リリース
理想的なDXに近い進め方です。
ただし繰り返しになりますが、暗黙的仕様を把握するのは非常にエネルギーが必要で、コスト・時間も膨らみやすく、リリース時期が大きく遅れる可能性があります。また、最悪の場合、暗黙的仕様の領域がいつまで経ってもなくならないという事態が発生することもあります。
3．現行仕様と決別し、業務の本質を基にシステム構築
一見すると面白い発想で、「世間一般の業務はどうなっているのか」という視点で、0ベースで業務を再構築していく進め方です。
ただし、完全に現行仕様を排除することは現実的には難しいため、新仕様への採否判断が必要になります。ここでは「デジタル知識」「ドメイン知識」、そして現行仕様（固有仕様）を深く理解した上で判断できるポスト（人）が必要です。
要するに、デジタルとドメインの両方を理解し、かつ会社の実情も一定把握している人材を準備する必要があります。経験上、そうした人が1〜2名でもプロジェクトにいると、成功確率が上がったと感じる場面は多いです。
システム構築は、大勢を集めるよりも「少数でもよいので優秀な人材を集める」ほうが結果的にうまくいくことがあります。そういう側面があると思います。
メリットとデメリット
ここで改めて、上記3案のメリットとデメリットを表に整理します。
| 案 | 概要 | メリット | デメリット | 向いている状況 | 主な注意点 |
|---|---|---|---|---|---|
| 1. 暗黙的仕様を諦めて早期リリース | 暗黙的仕様は割り切り、スコープを絞って出す | 早く出せる／予算を抑えやすい／意思決定が単純化しやすい | リリース後に運用が回らないリスク／現場の不満が爆発しやすい | まず価値検証したい、段階導入したい | 暗黙的仕様の「残存量」を見誤ると致命傷になります |
| 2. 暗黙的仕様も含めてリリース | 暗黙的仕様を可能な限り表出・理解してから出す | あるべき姿に近い／運用定着しやすい／手戻りが減りやすい | コスト・時間が重い／期限遅延しやすい | 失敗が許されない基幹領域、全社影響が大きい | 経営の覚悟（予算・人材・期間）がないと破綻しやすいです |
| 3. 現行仕様と決別し本質ベースで再構築 | 世間標準や本質から業務・システムを作り直す | 構造的な改善が狙える／将来拡張しやすい可能性 | 採否判断が難しい／現行との摩擦が大きい／人材要件が高い | 競争力強化が目的、変革の必要性が高い | 「デジタル×ドメイン×現場」をわかる少数精鋭が鍵です |
終わりに
私はここ数年間DXに携わる中で、DXプロジェクトの成功・失敗には一定の「構造」があると感じるようになりました。この記事ではそれを「知識」「仕様」という切り口で整理し、どのような推進方法があり得るかを示しました。
次回は、上記の案について不足しがちな**タイムスケール(時間軸)**の議論をしたいです。
例えば「現行仕様と決別し、業務の本質を基にシステム構築」は、「では今日からやろう」と着手しても、失敗しそうだという直感は多くの方が持つと思います。これを、例えば「1年目はリーンに実行」「2年目は試験的に実行」「3年目に全展開」のように、時間軸で設計する議論も必要です。そこを掘り下げたいと考えています。
長い文章を読んでいただき、ありがとうございました。