コストや期間が限られているシステム化には割り切りが必要だが、人は「現状」に固執しがちなもの。特に、パッケージソフトウエア導入プロジェクトでは、機能のミスマッチが炎上の火種になりやすい。目的・目標を再確認して方針を定め、方針を実務に反映できる指針とプロセスに落とし込もう。
BPRだって言ったじゃないの！
プロジェクトマネジャー（PM）の玉田圭は、目をぱちくりさせた。
「印刷機能、ですか？要件定義でも、外部設計時にもそんな話は出なかったと思いますけど」
黒川経理グループ長は、顔をしかめた。
「まあ、設計書になかったのは確かだけどね。必要なのは事実なの。会計締めの3時前に、入力伝票を束にして突き合わせチェックしてるのよ。2年前の監査法人の指摘でチェックすることになったの。監査指摘なんだから、無視できないでしょ？」
「はあ、しかし…」
玉田PMは、後の言葉を飲み込んだ。しかし、遅過ぎる。結合テストも半ばを過ぎた今になって機能追加を求められたら、ただでさえタイトなスケジュールがズタズタになってしまう。
そもそもこの場は、2次リリース分の伝票の要件定義セッションなのだ。玉田は話題を変えた。
「今日は支払伝票と振替伝票について、でしたね」
黒川がうなずいた。
「まず、処理取消機能について確認したいんだけど」
「処理取消機能？『でんでん丸』の標準機能には、処理を取り消す機能はありません。一度入力した伝票の情報は即座に管理会計機能に連携するので、取り消しはできないんです」
「じゃあ、伝票入力を間違えたらどうするの？」
「伝票修正機能を使います。修正を入れると、自動的に差額の逆伝票仕訳を吐き出します」
「それじゃダメなのよ。取消処理がうちの標準なんだから。あのね、新人が実機で伝票入力の練習できるのも、処理取消があるからなんだから」
玉田は頭を振った。
「トレーニングに実機を使うのは、問題があるような気がします。見直しを考えられてはいかがでしょう」
「ダメよ。今やってることができなくなるんだったら、何のためにパッケージを導入するのか分からないわ」
黒川はにべもなく否定した。
やれやれ。玉田はため息をついた。パッケージを活用してBPR（ビジネス・プロセス・リエンジニアリング）をするという話はどこへ行ったのだろう（図1）。業務をパッケージに合わせて簡素化するという方針が示されたにもかかわらず、ユーザー代表の黒川はことごとく現行事務に固執しようとする。
