用語集
本稿では、用語を次のように定義します。
ドメイン
ここでは、業務の領域を指します。
たとえば「請求」「支払」「配送」「返品」などです。
仕様
ここでは、システムが提供すべき個別の機能や振る舞いを指します。
たとえば「請求」ドメインであれば、「請求情報入力」「請求情報検索」「請求書印刷」などが仕様にあたります。
幹
対象ドメインを成立させるために最低限必要な仕様群です。
たとえば「請求」であれば「請求書印刷」は幹に含まれます。一方で「請求書一括印刷」は便利ではあっても、請求ドメインの成立そのものには必須ではないかもしれません。
同様に「予算管理」であれば、「実績入力」は幹に含まれますが、「予算・実績差異分析」は業務によっては枝葉として扱える場合があります。
枝葉
幹には含まれない追加仕様です。
あると便利だが、なくてもドメインの中核業務は回る、という性質のものを指します。
多くの場合、企業固有の運用や、長年の現場最適の結果として生まれます。
作りこみ仕様
標準機能では賄えず、個別開発・追加実装が必要になる仕様です。
枝葉に属することが多いですが、業種や法制度の都合によっては幹に含まれる場合もあります。
現行踏襲
ユーザー企業がよく使う「現在のシステム仕様はこうなっているので、新システムでも同じにしたい」という考え方です。
ただし実務では、その背景や例外条件まで正確に共有されないことが多く、結果として発注側と開発側で情報の非対称が発生しやすくなります。
リーン検証
小さく作り、小さく試し、短いサイクルで学ぶ検証方法です。
最初から全体最適を狙うのではなく、重要な部分から順に検証し、得られた学びを段階的に全体へ広げていきます。
背景・目的
前回は、仕様には「一般的仕様」と「固有仕様」があり、さらに固有仕様の中には「表出的仕様」と「暗黙的仕様」があることを説明しました。
このうち特に厄介なのが暗黙的仕様です。
暗黙的仕様は文書化されておらず、現場の慣習や担当者の経験に埋め込まれているため、表に出して明文化するだけでも大きなコストと時間がかかります。
モダナイゼーションが難しいのは、単に古い技術を新しい技術に置き換えるからではありません。
「何を再現すべきか」が分からないからです。
だからこそ重要なのは、現行システムを丸ごと再現することではなく、業務の本質を見極めたうえで、何を残し、何を捨てるかを決めることです。
言い換えると、モダナイゼーションの成否は「暗黙的仕様をどれだけうまく扱えるか」に大きく左右されます。
本稿では、その延長線上にあるもう一つの論点、すなわち現行仕様の複雑度について考えます。
現場では、ユーザー企業から「ちょっとした仕様追加」「少しの機能改善」が軽く依頼されることがあります。
しかし開発側から見ると、その一つの追加が他の仕様に連鎖し、工数・設計・テスト・移行難易度を大きく押し上げることがあります。
そして厄介なのは、依頼する側だけでなく、受ける側もその影響を十分に定量化できていないことです。
その結果、「対応できます」と答えた後で、実際には全体を大きく複雑化させてしまう。
本稿では、この構造に少しでもメスを入れたいと思います。
そのうえで、「現行仕様と決別し、業務の本質を基にシステムを構築する」ことが、ある条件下では最も合理的な方針であることを示します。
DXを前に進める仕様と、複雑化を招く仕様
近年、業務をシステムの標準機能に合わせ、極力カスタマイズを行わないという考え方が広がっています。
いわゆる F2S（Fit to Standard） です。これは、システムの標準機能に業務プロセスを合わせるアプローチとして広く説明されています。
この方針自体は非常に合理的です。
ただ、実際の開発現場では次のようなことが起こりがちです。
・パッケージ導入を前提に始まる
・要件定義が進む
・各部門から個別事情に基づく例外要件が出る
・標準機能では吸収できなくなる
・結果として大規模なカスタマイズに戻る
この流れは珍しくありません。
たとえば、要件を詰めていくと次のような仕様が出てきます。
▲商品は、こういう場合は○○円、この場合は××円、その他は△△円
こうした仕様がすべて悪いわけではありません。
しかし、例外条件が多く、個社固有の運用に強く依存する仕様は、F2Sを妨げやすく、結果としてカスタマイズを肥大化させる温床になります。
一方で、次のような方針はDXと相性がよい仕様です。
この業務改革では、紙のやり取りを廃止する
入力は一度だけにし、後続プロセスでは再入力しない
承認は電子化し、処理履歴を残す
これらは個別条件を増やすのではなく、業務そのものをシンプルにし、標準化する方向に働きます。
つまり、仕様には大きく二種類あります。
・業務をシンプルにする仕様
・例外をシステムに埋め込む仕様
前者はDXを前に進めやすく、後者は現行踏襲や過度な作りこみを招きやすい。
この違いを見極めることが重要です。
なぜ仕様追加の工数は直線的に増えないのか
開発現場で見積もりが難しくなる理由の一つは、仕様追加のコストが足し算では済まないことです。
直感的には、仕様Aに加えて仕様Bが増えたら、工数も「A分 + B分」で済みそうに見えます。
しかし実際には、AとBの相互作用が発生します。
たとえば、
・画面入力と帳票出力の整合
・料金計算と請求タイミングの整合
・例外処理と承認フローの整合
・権限制御と検索条件の整合
など、仕様同士の接点が増えるほど、設計・実装・テスト観点が増えます。
この関係を簡単に表すと、総工数 H は次のように考えられます。
$$
H = \sum_{i=1}^{n} c_{ii} + \sum_{1 \leq i < j \leq n} c_{ij}
$$
- $c_{ii}$ : 仕様 $i$ 単体を実装するための工数
- $c_{ij}$ : 仕様 $i$ と仕様 $j$ の関連性によって増加する工数
- $n$ : 仕様の総数
つまり、工数は「各仕様の単体工数の総和」だけで決まるのではなく、仕様間の相互作用によって発生する追加コストの総和にも左右されます。
たとえば、「A機能を追加した結果、関連するB機能にも影響が及び、プログラム改修やテストケースの追加が必要になる」といったケースがあります。
このような、仕様同士の関係性によって生じる追加工数が、上式の右辺第2項にあたります。
追加仕様が重い本当の理由
ここで、新しい仕様 k を一つ追加したとします。
そのとき増える工数は、単純に $$c_{kk}$$ だけではありません。
$$
ΔH = c_{kk} + \sum_{i=1}^{n} c_{ik}
$$
つまり、新仕様そのものの工数に加えて、既存のすべての関連仕様との調整コストが上乗せされます。
この式が示しているのは非常に単純です。
・仕様追加の負担は、「その仕様がどれだけ大きいか」だけではなく、
・既存仕様とどれだけ深くつながるかで決まる
ということです。
仕様が増えるほど、潜在的な相互作用の数も増えます。
少なくともペアの組み合わせだけでも、仕様数を N とすると
$$
N(N-1)/2
$$
だけ存在します。
もちろん、実務ではすべての仕様がすべてに依存するわけではありません。
しかし、複雑な現行システムほど依存関係が密になりやすく、結果として見積もりが崩れやすくなります。
これが、「たった一つの仕様追加」が、なぜプロジェクト全体に重くのしかかるのかの正体です。
「幹」から作るという考え方
では、どうすればよいのでしょうか。
私が重要だと考えているのは、まず幹を作ることです。
言い換えると、そのドメインが成立するために最低限必要な仕様だけを先に定義することです。
たとえば、請求ドメインであれば、まず押さえるべきなのは次のような流れです。
・請求対象データを登録できる
・請求内容を参照できる
・請求書を出力できる
・請求結果を追跡できる
この段階では、価格の特殊条件や一括例外処理、帳票レイアウトの細かな差分などは入れません。
まずは最低限回る業務フローを描き、そこに必要な仕様だけを幹として定義します。
この姿勢を持つだけで、議論の質が変わります。
・それは本当にドメインの成立に必要か
・それは後からでも足せるか
・それは標準機能で代替できないか
・それは一時的な現場運用で吸収できないか
こうした問いが立つようになります。
枝葉を入れる前に問うべきこと
枝葉の仕様を否定したいわけではありません。
問題は、枝葉を幹より先に議論してしまうことです。
たとえば、価格体系が複雑な仕様が出てきたときは、まず次を確認すべきです。
・なぜそこまで細かい条件分岐が必要なのか
・それは売上や利益にどれだけ効いているのか
・運用で代替できないのか
・システム化によるメリットは、複雑化コストに見合うのか
・その仕様は「今も必要」なのか、それとも「昔からある」だけなのか
こうした問いを通じて、枝葉の仕様を
・入れる
・後回しにする
・運用で吸収する
・そもそも捨てる
のどれにするかを判断します。
幹の後に入る仕様には、しばしばマーケティング上の意図、現場都合、対外説明、あるいは単なる慣習が混ざります。
だからこそ、「なぜ必要か」を繰り返し問う必要があります。
現行踏襲の幻想
DXやモダナイゼーションの議論で、もっとも強い言葉の一つが「現行踏襲」です。
しかし、現行システムに実装されている仕様が、そのまま「あるべき業務」を表しているとは限りません。
そこには次のようなものが混ざっています。
・過去の制度や組織構造に合わせた制約
・旧システムの性能限界を補うための回避策
・一部担当者しか知らない運用ルール
・誰も理由を説明できない例外処理
・すでに意味を失った歴史的経緯
こうしたものまで含めて再現しようとすると、新システムは最初から複雑になります。
しかも厄介なのは、その複雑さの多くが明文化されていないことです。
つまり「現行踏襲」は、安心の言葉に見えて、実際には不確実性を新システムへ持ち込む言葉でもあります。
本当にDXを成功させたいなら、まず議論すべきは「現行がどうなっているか」だけではなく、
「これからどうあるべきか」です。
ただし、現行踏襲をゼロにすればよいわけではない
ここは誤解されやすい点です。
現行踏襲を避けるべきだと言っても、すべてを捨てればよいわけではありません。
業務変更を急激に進めすぎると、現場が混乱し、かえって生産性や信頼性を落とすことがあります。
特に注意が必要なのは、次のようなケースです。
・対外的な信用に直結する帳票や通知
・法令・監査対応に関わる処理
・現場教育に大きな時間を要する手順
・一時的に人手で吸収できない業務量
こうした領域では、あえて一部を現行踏襲する判断もありえます。
重要なのは、「何となく残す」のではなく、デメリットを理解したうえで意図的に残すことです。
最後は経営判断が必要になる
幹と枝葉を整理し、効果と複雑性を見極めても、最後に残る論点があります。
それは、「現場は必要だと言うが、全体最適では不要に見える仕様をどうするか」です。
この場面で必要なのは、プロジェクトマネージャーの裁量だけではありません。
必要なのは、事業・収益・組織のあり方に責任を持てる立場の判断です。
つまり、社長・CEO・役員などの経営層です。
ただし肩書きだけでは不十分で、重要なのは
・全体最適で判断できること
・部門最適に引きずられないこと
・捨てる判断に責任を持てること
です。
DXやモダナイゼーションは、単なるシステム導入ではなく、業務の再定義です。
だからこそ、最終局面では経営判断が不可欠になります。
実務での進め方
私なら、全体の進め方を次のように置きます。
1. 幹を策定する
ドメインの成立に必要な最小仕様を定義する。
2. 枝葉候補を列挙する
現場要望や現行踏襲要求を棚卸しする。
3. 作りこみ仕様を最小化する
標準機能で代替できるもの、運用で吸収できるものを除く。
4. 業務フローを再設計する
新システム前提の業務として整理する。
5. リーン検証を行う
幹から小さく検証し、必要ならピボットする。
6. 経営判断を入れる
枝葉の採否や、現行踏襲の許容範囲を決める。
7. ユーザーへ展開する
変更理由と期待効果を伝えたうえで移行する。
8. 微調整する
現場混乱や対外影響を見ながら、必要最小限の補正を入れる。
特に重要なのは、リーン検証でピボット可能な状態を残しておくことです。
これを誤ると、導入後に「思ったより回らない」と判明しても引き返せず、プロジェクト全体が停止するリスクがあります。
まとめ
モダナイゼーションやDXの現場で本当に難しいのは、技術の刷新そのものではありません。
何を再現し、何を捨てるかを決めることです。
その判断を誤ると、現行踏襲によって複雑な仕様をそのまま持ち込み、仕様間の相互作用によって工数・期間・移行難易度が雪だるま式に膨らみます。
だからこそ重要なのは、次の４点です。
このうち1つでもかければ、そのプロジェクトは失敗する確率が高くなるか、プロジェクトは完了しても業務改革ができない不完全な結果になってしまうでしょう。
・ドメインの幹を先に定めること
・枝葉を「本当に必要か」で問い直すこと
・現行踏襲を前提にせず、業務の本質から再設計すること
・経営判断ができる人を参画させること
DXを成功させるために必要なのは、「今あるものをうまく残す」ことではなく、
これから必要なものを見極め、不要な複雑性を持ち込まないことだと考えています。
最後までご連頂き、ありがとうございました。