よくある間違い
DXアンチパターン¶
1. 現状の業務をそのままシステム化しようとする¶
概要¶
現在の業務手順を一切見直さず、そのままシステムに置き換えるアプローチです。 紙やExcelでやっている作業を、そのまま「入力画面」や「ボタン」に置き換えるだけの発想です。
一見すると安全に見えますが、実際には非効率な業務をそのまま固定化してしまうことになります。
なぜ起きるのか¶
主な理由は次の通りです。
- 現場の業務を変えることへの抵抗
- 「今の業務が正しい」という思い込み
- 要件定義の時間不足
- IT部門が業務改善まで踏み込めない
結果として、「業務改善」ではなく「デジタル化だけ」になってしまいます。
典型的な例¶
例1：紙の申請書をそのままシステム化¶
紙運用 1. 申請書作成 2. 上司承認 3. 部長承認 4. 総務確認
これをそのままシステム化すると 1. 入力画面 2. 上司承認ボタン 3. 部長承認ボタン 4. 総務承認ボタン
になります。
しかし実際には、以下の通り業務自体を整理できる可能性があります。 - 部長承認は形骸化している - 総務確認は不要 - 同時承認で良い
例2：Excelの列をそのまま入力項目にする¶
Excel - 顧客名 - 担当 - 備考1 - 備考2 - 備考3
そのままシステムにすると - 顧客名入力 - 担当入力 - 備考1入力 - 備考2入力 - 備考3入力
しかし実際は、以下のケースがよくあります。 - 備考は自由記述で良い - 入力不要な項目が多い
このアンチパターンの問題¶
① 非効率がそのまま残る¶
業務の無駄が固定化されます。むしろ「システムなのに遅い」状態になります。
② 変更が困難になる¶
一度システム化すると、以下の工程が必要になります。 - 仕様変更 - 改修 - テスト
つまり、非効率な業務を固定化してしまうという問題が起きます。
③ システムの価値が出ない¶
本来システムの価値は「自動化」「入力削減」「情報共有」「ミス防止」ですが、単なる置き換えではメリットがほとんど出ません。
回避策¶
① まず業務を疑う¶
重要な問い - この作業は本当に必要か - 誰のための作業か - 自動化できないか - まとめられないか
② 業務の理想形を考える¶
順序としては、以下の通りです。 1. 理想の業務設計 2. 業務整理 3. システム化
よくある失敗は、「①システム化 → ②業務合わせ」です。
③ 「入力を減らす」ことを優先¶
良いシステムの特徴は、以下の通りです。 - 入力が少ない - 自動処理が多い - 確認が簡単
2. レアケースもシステム化して仕様が複雑化する¶
概要¶
頻繁に起きないケース（例外処理）まで、最初からすべてシステムで対応しようとするアンチパターンです。
結果として、以下のようなシステムになります。
- 画面が複雑
- 条件分岐だらけ
- 保守が困難
システム開発が失敗するパターンは色々とありますが、これは「90%の仕様が1%のためにつくられる」が該当します。 日本の職人気質(≒完璧主義)は、車や半導体製造装置のように「モノづくり」には強みですが、情報システム開発とは相性が悪いです。
思いついたことを何でもシステム化するのでなく、発生頻度に応じてシステム化対象・レベルを切り分けることが重要です。
| 発生頻度 | 対応 |
|---|---|
| 日常業務 | システム化 |
| たまに発生 | 簡易対応 |
| ほぼ発生しない | 手作業 |
なぜ起きるのか¶
よくある理由は次の通りです。
- 現場が「例外」を全部要求する
- 仕様変更を嫌がる
- 将来を過剰に想定する
- 完璧主義
その結果、「1%のための90%の仕様」が作られます。表現を帰ると「90%の仕様が1%のためにつくられる」
典型例¶
例：注文システム
通常の流れ 1. 注文 2. 出荷 3. 請求
しかし現場から、以下のような例外が要求されます。 - 特別割引 - 緊急出荷 - 分割配送 - 代理注文 - 特殊税率 - 海外配送 - 特別承認
これをすべて仕様化すると、条件分岐が膨大になり、システムが非常に複雑になります。
このアンチパターンの問題¶
① 開発コストが爆発する¶
複雑度は単純に増えません。「ケース数 × 組み合わせ」で増えます。
- 例外が1つ → 少し複雑
- 例外が5つ → 非常に複雑
② テストが非常に困難¶
テストケースが「通常」「例外A」「例外B」「例外A+B」「例外A+C」...と増え続けます。
③ 保守が壊れやすい¶
システムは「修正 → 別の部分が壊れる」という問題が起きやすくなります。
特に例外処理が多いと、誰も仕様を理解できない状態になります。
回避策¶
① 「頻度」で判断する¶
| 発生頻度 | 対応 |
|---|---|
| 日常業務 | システム化 |
| たまに発生 | 簡易対応 |
| ほぼ発生しない | 手作業 |
② 例外は手作業で処理¶
多くの成功プロジェクトでは、「95% → システム処理、5% → 手作業」という設計になっています。
③ 最初はシンプルに作る¶
理想的な進め方は、以下の通りです。 1. 通常業務のみシステム化 2. 運用開始 3. 必要な例外だけ追加
この方が、開発速度、品質、保守性のすべてが向上します。
まとめ¶
業務システム開発で最も多い失敗は、次の2つです。
アンチパターン①：現状業務をそのままシステム化する¶
結果 - 非効率が固定化 - システムの価値が出ない
アンチパターン②：レアケースまで最初から仕様化する¶
結果 - システムが複雑化 - 開発・保守コストが増大
重要な考え方¶
システム化は「業務改善」であり、「現状業務のデジタル化」ではありません。