はじめに
前回の記事では、DX推進に必要な要素として 3つの知識領域 と 3つの仕様領域 があり、とりわけ 「暗黙的仕様」（現場が言語化できていない／していない固有の仕様）をどう扱うかで、DXの進め方が大きく変わる、という話をしました。
進め方（案）は大きく3つあり、いずれにもメリット・デメリットがあります。
ただし現実のDX推進では、コストや期間、人員といったリソースに制約があり、理想に対して「どこかで割り切る」判断が必要になります。つまり、各案のトレードオフを踏まえて案を選定することになります。
今回は、前回の 知識×仕様（3×3）のマトリクス を、時間軸（=理解・合意形成に要する時間） も含めて捉え直し、どのように進めるのが現実的かを整理します。
数学的基礎
まず、9つの象限（3×3）を数式として表現しておきます。ここでは「厳密な数学」というより、議論をブレさせないための記法として使います。
知識集合と仕様集合
知識集合と仕様集合を以下のように定義します。
-
知識集合
$$
K={K_1,K_2,K_3}
$$ -
仕様集合
$$
S={S_1,S_2,S_3}
$$
各要素は以下のとおりです。
-
$K_1$：ドメイン知識
-
$K_2$：デジタル知識
-
$K_3$：特有知識（現場のデータ流通・前後工程・Excel運用などの固有事情）
-
$S_1$：一般仕様
-
$S_2$：表出的仕様（固有だがヒアリング等で表出できる仕様）
-
$S_3$：暗黙的仕様（固有で、表出しきれない／しにくい仕様）
工数（作業時間）の行列
この知識集合×仕様集合を理解し、要件化し、合意形成する作業工数を、行列として表現します。
ここで $t_{ij}$ は「$K_i$ と $S_j$ の組み合わせを扱う工数（時間）」です。
\mathbf{T} =
\begin{pmatrix}
t_{11} & t_{12} & t_{13} \\
t_{21} & t_{22} & t_{23} \\
t_{31} & t_{32} & t_{33}
\end{pmatrix}
総工数（総時間）は次のように置けます。
$$
T_{\text{total}}=\sum_{i=1}^{3}\sum_{j=1}^{3}t_{ij}
$$
ポイントはシンプルで、暗黙的仕様（$t_3$）の各セルが重い、ということです。
そして「重い」ことの意味は、単に作業量が多いだけではなく、現場の観察・試行錯誤・合意形成といった“時間経過が必要な活動”を含む、という点にあります。
案を数式で示す
ここから、前回の記事で示した3つの案を、工数モデルとして表現してみます。
1．「暗黙的仕様」を諦めて、とりあえずリリース
「暗黙的仕様（$S_3$）」をスコープから外し、一般仕様と表出的仕様（$S_1, S_2$）だけで進める場合です。
$$
T^{(1)}=\sum_{i=1}^{3}\sum_{j=1}^{2}t_{ij}
$$
この場合、対象は 3（知識）×2（仕様）= 6セル になります。
短期リリースしやすい一方で、暗黙的仕様が大きい領域を踏み抜くと、リリース後に運用が崩れる（＝後工程で爆発する）リスクが残ります。
2．「暗黙的仕様」を理解領域に含め、リリース
暗黙的仕様（$S_3$）も含め、3×3の全セルを対象にする理想形です。
$$
T^{(2)}=\sum_{i=1}^{3}\sum_{j=1}^{3}t_{ij}
$$
対象は 3×3=9セル です。
ただし暗黙的仕様の掘り起こしは、ヒアリングだけでは終わらず、観察・試行・合意形成が必要になります。結果として コストと時間が膨らみやすい 進め方になります。
3．現行仕様と決別し、業務の本質を基にシステム構築
ここで言う「現行仕様と決別」は、乱暴に“現場を無視する”という意味ではありません。
現行のデジタル実装や、現場の属人的な手順（=特有知識）に強く引きずられない、という意味です。
この案では、暗黙的仕様（$S_3$）を全領域で無理に回収しに行くのではなく、ドメイン（$K_1$）に絞って時間をかけて検証する、という考え方を取ります。
まず、一般仕様・表出的仕様（$S_1,S_2$）については、知識領域3つすべてで扱います。
$$
\sum_{i=1}^{3}\sum_{j=1}^{2}t_{ij}
$$
次に、暗黙的仕様（$S_3$）は ドメイン領域（$K_1$）だけ を対象にし、時間をかけて理解を“0→1”に近づけるプロセスとして積分で表現します。
$$
\int_{0}^{1} t_{13}(x)dx
$$
よって全体は次のように書けます。
$$
T^{(3)}=
\sum_{i=1}^{3}\sum_{j=1}^{2}t_{ij}
+
\int_{0}^{1} t_{13}(x),dx
$$
デジタル知識およびドメイン知識に関する暗黙的仕様（象限のグレー部分）については、本案では対応不要とします。理由は、現行仕様をリセットしゼロベースで検討を行うため、これらを前提とした整理が不要となるためです。
この案のポイントは次のとおりです。
- 「暗黙的仕様」を 全セルで回収しない（=時間とコストが破綻しやすい）
- ただし「暗黙的仕様」を ゼロにもしない（=運用で爆発しやすい）
- 暗黙的仕様のうち、致命傷になりやすい ドメインの暗黙（$t_{13}$） を最優先で時間をかけて検証する
- 結果として、検討対象は 6セル + 暗黙の1セル（時間をかけて検証） = 実質7象限 のイメージになる
ここまでで「筋は分かった」としても、次に問題になるのが どうやってこの時間（積分で表した部分）を確保し、現実に回すか です。
現実案
私はDXに長く関わる中で、失敗も成功も見てきました。特に、スクラッチをパッケージへ置き換える文脈（いわゆる Fit to Standard / F2S）で、「理念も腹落ちもないまま進めて失速する」ケースを多く見ています。
ただ、これまで整理してきたとおり、DXの成否は結局のところ 暗黙的仕様をどう扱うか に収束します。ここを放置すると、どれだけ差分一覧を作っても、どこかで破綻します。
そこで、私がうまくいったプロジェクトで共通していた「攻略パターン」を、案3の考え方（暗黙はドメインに絞って時間をかけて検証）に寄せてまとめます。
差分分析だけでは足りない（業務の“本質”を取りに行く）
パッケージ導入では、現行とパッケージの機能差分を洗い出すことが定石です。もちろん重要です。
しかし、それ“だけ”では足りません。なぜなら差分分析は、現行の手順（=特有知識）を前提にしやすく、暗黙的仕様の源泉（なぜそれが必要なのか） に届きにくいからです。
本当に重要なのは、現行手順の写経ではなく、業務の本質（目的・制約・守るべき原則） を理解し、それをシステム仕様に落とすことです。
時間軸を設計する（積分部分を“予定に落とす”）
暗黙的仕様の検証は「頑張ります」では進みません。時間が必要な活動なので、最初から時間軸に埋め込む必要があります。例えば以下のように、段階を分けます。
-
0〜2か月：現場に入り、言語化できる仕様（表出的仕様）を出し切る
ヒアリング＋既存資料＋データの流れの棚卸しで、まず $S_2$ を固めます。 -
3〜6か月：ドメイン暗黙（$t_{13}$）を観察・試作で炙り出す
現場観察、例外ケースの収集、プロトタイプでの確認、会議での合意形成を回します。
ここが積分（0→1）に相当します。 -
7〜12か月：段階導入（小さく出して検証し、拡げる）
いきなり全社展開せず、運用が回る単位で出し、暗黙の“残り”を潰します。
「要件定義に数千万円」より「1年張り付き」が安い場合がある
暗黙的仕様を本気で減らすには、現場に入り、一定期間“当事者”として回す必要があります。
少数でよいので、ITリテラシーが一定あり、かつ現行を理解する人材 が、半年〜1年レベルで業務に入り込むのが効きます。
要件定義で大きな金額を投じるよりも、1年張り付いて暗黙を溶かすほうが、結果的に安くつくケースもあります。これはエスノグラフィーの発展形として捉えることもできます。
もちろん、社内の合意形成は簡単ではありません。外部委託だけに任せるのも難しいです。
だからこそ、経営者や上司が腹をくくって、必要なら「現場に人を出す（兼務ではなく一定期間コミットさせる）」という意思決定をしない限り、暗黙的仕様は減りません。
この意思決定ができたとき、DXプロジェクトの成功確率は大きく上がると考えています。
おわりに
今回の「現実案」は、DXで 業務改革とシステム再構築を同時に進める 場合に、特に有効だと考えています。
一方で、プロジェクトの目的や制約（期限・予算・影響範囲）が異なれば、案1や案2が適するケースもあります。重要なのは「どれが正解か」ではなく、暗黙的仕様をどう扱うかを明示したうえで、時間軸とコストを含めて設計することです。