刷新のたびに旧仕様が蘇る——現行踏襲が消えない構造と抜け出し方

システム刷新のプロジェクトが動き出すと、要件定義の場でほぼ必ず出てくる言葉がある。「今まで使えていた機能は全部残してほしい」。

新しい技術で古い課題を解消するはずの取り組みが、なぜ旧仕様の再現に収束してしまうのか。「一度白紙に戻そう」と言っても現場の抵抗に遭うだけなのは、そこに構造的な理由があるからだ。現行踏襲から抜け出すには、まずそれが「誰の何の問題か」を整理することから始める必要がある。

「現行踏襲」という要件は誰が作るのか

現行踏襲の要件は、誰か一人が意図的に積み上げているわけではない。複数の立場から出る「リスク回避」が重なった結果として現れる。

• 担当者レベル: 毎日使う操作が変わることへの不安。慣れた手順が消えると、自分の仕事のやり方そのものが揺らぐように感じる。
• 管理職レベル: 説明責任の問題。「なぜあの機能を削ったのか」と後から問われたとき、根拠を用意できなければリスクを背負う。
• プロジェクト責任者レベル: 「削った機能で現場が困る」という事態を避けたい。スコープを絞ることが安全でも、削除の責任だけは取りたくない。

積極的に現行踏襲を望む人がいなくても、「全部残す」という合意が最も安全な着地点として成立してしまう。

現行踏襲は「機能の問題」ではなく「合意形成の問題」だ。要件リストを見直す前に、誰のどんな不安が積み上げているかを解きほぐすことが先決になる。

旧仕様を新技術で再現することのコスト

現行踏襲のまま刷新を進めると、新しいシステムに旧システムの制約まで移植される。

たとえば、かつての帳票レイアウトが特定の業務フローを前提にしていた場合、その帳票を新システムでも再現しようとすれば、業務フローもセットで引き継ぐことになる。技術は新しくなっても、業務の動き方は変わらない。

さらに深刻なのは、「なぜこの機能があるのか誰も知らない」という状況が刷新のたびに持ち越される点だ。使われていない機能も、「いざというとき必要かもしれない」という理由で残り続ける。刷新のサイクルを重ねるほど、本来の目的と切り離された機能が蓄積していく。

DXに「完了」を設けない設計の考え方でも触れているように、システムの課題は一度の刷新で解消されるものではない。だからこそ、一回の刷新で持ち込む負債は少ない方がいい。現行踏襲はその負債の主要な供給源になっている。

用途から問い直す——現行踏襲を抜け出す三つの手順

現行踏襲から抜け出すには、「機能リスト」ではなく「業務目的」を起点に据える必要がある。次の順序で進めると、合意形成が現実的になる。

1. 業務目的の棚卸し: 機能ごとに「誰がこれを使って、何を判断しているか」を書き出す。操作の名前ではなく、その機能によって何が決まるのかを問う。
2. 使用実態の可視化: アクセスログや利用頻度データを使い、実際に使われていない機能を洗い出す。「使われているかどうか」と「あると安心かどうか」は別の問いとして扱う。
3. 削除への合意形成: 機能を削ることで困る関係者を具体的に特定し、その業務目的を別の手段で満たせるかを先に示す。困る人が誰もいないと確認できれば、削除への合意は得やすくなる。

改善の順番をどこから決めるかという問いとも重なるが、何から手をつけるかより、何を手放せるかを先に見極める方が、刷新の質は上がる。

「現行踏襲をやむを得ない慣習として放置するか、設計の問題として扱うか」で、刷新の結果は大きく変わる。機能の数を維持することではなく、業務の目的を達成することが刷新の本来の意義だ。要件定義の段階からこの問いを立てることが、最初の一歩になる。

アルゴラのしぼるでは、システム刷新の要件定義段階から伴走し、現行踏襲の構造を整理する支援を行っている。