「なんか変な請求書が届いているんだけど」――顧客からのクレームで,請求処理システムに異常があったと分かった。開発に携わったSIベンダーのエンジニア 稲川春彦氏(仮名)は,「まさか,こんな処理パターンがあったとは」と原因に驚きながら,1000件にも上るクレームに耳をふさぎたい気持ちだった。

 稲川氏が担当したのは,ある商品をレンタルする会社の請求処理システム。オフコンで稼働していたが,ハードウエアの保守切れに合わせ,再構築する話が持ち上がった。予算は1億円。稲川氏は旧システムからデータを移行するチームのリーダーとして,1年におよぶプロジェクトにかかわった。

 プロジェクトが進むうちに,稲川氏は「自分がこれまで担当してきた顧客とはタイプが違う」と感じる。一言でいえば,わがままが過ぎた。担当者からは,「あれもほしい,これもほしい」と引きも切らず追加要件が舞い込む。その結果,最終的な投資額は当初予算の5倍に達した。こうした要件は,約20人の営業所長を全国から集めて行う,週2回の定例会議で出される。午前中に始まった会議は夕方まで続くが,その半分以上は,営業所長同士の言い合いに終始した。基本的な要件は決まるが,営業所ごとのローカル・ルールに話がおよぶと,「そんな値引きありか!」と怒声が飛び始める。

 長時間の会議が終わり,議事録を作り上げると,すぐに次の会議資料を作らなければならない。稲川氏は,そのような生活を半年間も強いられた。想定以上の作業量だったため,レンタル会社に対して追加の費用負担を求めた。「いっそのこと“そんなの払えない”と断られ,それをきっかけに作業を正常化したい」というのが稲川氏の狙いだった。ところが,「ああ,払うよ」と追加費用はあっさりと認められた。

 このプロジェクトのPMは稲川氏の上司が務めた。ただし,ユーザー企業側の厳しい要求に耐えられず,PMは2回交代した。開発規模は5倍に膨らんだのに,稼働時期をずらすことは許されなかった。新システムの稼働日を対外的に発表してしまったからだ。

 プロジェクトが終盤に入ると,無理な開発がたたり,バグや性能不足の問題が表面化してきた。PMがレンタル会社の担当者に報告すると,「明日までに直せ」というメールが届く。しかも,そこで対処策を考えていると,「何で返事がないんだ」というメールが1分ごとに送りつけられてきた。

 なんとか稼働時期は死守したが,ある要件が抜け落ちていた。同じレンタル商品でも,契約時期により請求処理が異なっていたのだ。古い契約には,レンタル開始から7年経った商品は請求対象外となる特例があった。一方,最近の契約では,7年目以降も請求する。稲川氏やPMはこの特例を知らされていない。古い契約データを単純に移行したところ,それまで対象外だった契約に対しても請求書が発行されてしまったのだ。

 障害の原因は,旧システムの仕様を要件定義で洗い出せなかったこと。かなり古い時期に定めた特例であり,レンタル会社の担当者も「料金が発生していなかったので,そんな契約があるとは思わなかった」という。

 旧データの移行に当たり,PMは事前にこうした特例の有無を担当者に確認した。ただ,「特殊な契約は無い」という言葉を鵜呑みにせず,自ら調査することはできたはずだ。このケースの場合,SIベンダーとユーザー企業の隙間は大きい。SIベンダーが隙間を埋めようと近づいても,ユーザー企業が“お金”の力で押し戻してしまう。

 ただ,要件を決める会議を見ても,このユーザー企業がシステム構築の経験に乏しいことは明らかだ。だからこそPMには,「担当者の言ったことは本当なのか」という冷静な目がほしかった。もし,旧システムの請求処理プログラムを分析していたら,“契約開始から7年が経過したか否か”を判定するロジックを見つけられたはずだ。システム構築のプロとして,隙間を埋める手立てはあった。