岩井 孝夫
佐藤 三智子

本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが,この記事で焦点を当てたITマネジメントの本質は今でも変わりません。

情報システムの評価は,実際の業務データを使ってはじめて意味がある。つまりテスト・検証が十分になされていても,それだけでは業務に使える保証にはならない。機能的には完ぺきでも,システムの移行・導入がうまくいかないことが往々にしてある。どんな支障が出るのかをあらかじめ予想することはだれにもできない。ただ,「何かが起こる」ということを常に念頭においておかないと,問題が起こったときに右往左往するはめになる。

 輸入雑貨を扱うA商社では,長年の習慣で顧客企業に納入した商品の代金を商品納入後2~3カ月たってから請求してきた。商品の価格は,仕入れ先変更とか為替レートの変動があるので同じものでも常に変動する性格を持っている。そのために,納品書情報と日付別の商品価格変動表をコンピュータに蓄積しておき,請求書作成時点での納品データをピックアップして,納入時単価表を参照しながら請求金額を計算して請求書を作成するという厄介な手続きが必要だった。

 A社では,社内で機能改善の要望の強かった在庫照会や納入予測などの新機能を追加した販売管理システムとすることを狙ってコンピュータ・システムを再構築することになった。新システムでは,請求書作成も従来の面倒な請求金額計算方式を改め,納品書が回収されたら納入時点の単価を反映させて金額計算をしておき,売掛ファイルとして請求情報を顧客別あるいは商品別に累積する簡単なシステムとすることにした。

 この請求書作成方式の変更を含む新システムの開発は順調に進んだ。テスト・データを使用しての総合テストも大過なく完了し,従来の納品情報ファイルから新しい売掛管理ファイルへのデータ・コンバージョンも無事に終了した。

 ここまでは順風満帆に推移してきたが,システム構築の最終段階である新システムと旧システムとの並行本番処理に入ったところで,大きな問題が露呈した。それは売掛金の金額計算の問題である。旧システムではまず個別に金額計算をしておいて顧客ごとに全請求金額を集計した後に円未満を四捨五入していた。ところが新システムでは個別に金額計算した過程ですぐに円未満の四捨五入が行われており,顧客によっては旧システムに比べて数十円の請求金額相違が発生することが判明したのである。

 これは社内の会計処理にも影響を与える。それにもまして問題だったのは,計算方式変更に伴う請求金額の相違発生について顧客の了承を取り付けなければならないのに,それをまったくしていない点であった。結局,顧客の了承を取るために新システムの稼働は6カ月遅延してしまった。

移行・導入に伴う落とし穴
使い勝手の悪さに現場が反発

 製造業のB社では,長年使ってきた受発注システムの再構築に踏み切ることにした。システムが老朽化し,システム機能の変更要請への対応もままならなくなってきたし,専用端末機を採用していたので保守・維持費もかさむ問題を抱えていることが理由だ。そこで,積年のシステム改善要望にこたえ,併せてパソコンを使った端末機に切り替えてシステム維持費用を削減する狙いも込めて新受発注システムを構築することにした。

 新受発注システムの構築は,機能強化の検討に現場管理職も積極的に参画したこともあって順調に進んだ。情報システムの開発,テストの実施,マニュアルの整備も予定通りに進んで,新受発注システムは大きな問題もなく本番開始に入った。

 ところが,新システムの本番開始後3カ月もたたないうちに営業部門の受注業務担当現場から,「この新受発注システムでは業務上の使用に耐えない」,「旧システムに戻してくれ」という強いクレームが出てきた。システム担当者が驚いて実情を調査してみると以下のような状況が判明した。

 受発注システムにおいては,毎日大量に発生する受注伝票の入力は営業部門の事務担当者が行っている。今までは専用端末機用に用意された特別仕様の専用キーボードを使っていたので,受注データの入力は受注伝票を見ながら右端のテンキーボードで入力して,右下の入力終了キーを押せば1件の入力完了となった。ところが,新システムでは汎用のパソコン端末を採用したので,テンキーボード右下は多目的の Enterキーになっている。このため同じ目的には使えず,代替として鍵盤上部に配置されたファンクション・キーを使う設計になっている。入力担当者に言わせると一連の入力操作で指の動きが大きく上下に乱れて,入力効率が落ちる,腕が疲れる,結果として大量の受注伝票を短時間で入力するには不向きといったクレームであった。

 受注事務担当者と話し合う機会も何回か設けたが,やがて感情的な対立にまで進んでしまい,最後は時間と費用を追加してのシステム改修という事態になってしまった。新受注システム構築にあたったシステム担当者は,新システムでも大量の伝票入力が運用上の大きな鍵となることはわかっていたのだから,初期段階の仕様設計時点で,事務担当者らを交えた意見交換によって使い勝手に関する配慮もしておくべきだったと反省している。