移行をナメると高くつく―――建設現場リース物件管理システム事件
「データ移行作業」を軽視するのは、営業担当者に多い。
旧システムにあるデータを抜いてきて、新システムに入れるだけだから、いわばコピー＆ペーストみたいなものだろうと考える。データ形式に違いがあっても、一括変換の移行プログラムを通すだけの手間に過ぎないと見なす。
かつて、営業担当がこんなことを言ってきた―――「移行元データは旧システムの過去データで、XMLファイルだから、ちょこっと直すだけで、新システムに入れられるよね。確認も含めて3日でできるよね。これサンプル」。1日あれば、変換して新システムに入れられるだろうという目論みで、顧客と約束してきたという。
ところが、移行プログラムが異常終了しまくる。
調べてみると、拡張子がXMLなだけで、中身が改変されているものが多数見つかった。旧システムの運用担当者が、勉強のために編集していたらしい。幸いなことに、どう修正すればよいかは判別できた。ただし、どのファイルが汚れているかは、移行プログラムを走らせてみないと分からない状況に陥った。
仕方なく、移行プログラム異常終了 ⇒ 汚染ファイルを人手で修正 ⇒ 移行プログラム再走行を繰り返すハメになり、最後は付きっきりで面倒を見た。汚染ファイルは30程度、徹夜は1晩で済んだが、移行作業は1週間かかった。
最終的には間に合ったのだが、移行の遅れについて、営業担当が、「移行プログラムの不具合です」と言い放ったことは絶対に忘れない（こいつはヨソでも間違いを起こすのだが、それはまた別の話）。
移行をナメると高くつく。
- プロジェクトの終盤、サービス開始の直前になるため、時間的に切迫している
- 動いている旧システムから抽出するため、仕掛り中の情報などを後から戻って取り直すのは困難
- 旧と新の狭間にある中間データで、両方の仕様に関わるため、解析難度が高い
- 異常の場合、旧システムに元々あった不具合か、抽出したデータの不具合か、新システムに反映した後の不具合か、切り分けが困難
移行は、「なにもなければ」データを抜いて入れるだけの時間と手間になる。しかし、「なにか問題があったとき」手遅れとなりがちだ。時間的余裕は無く、新旧両システムのデータと、移行プログラムそのものに熟知している必要があり、場合によっては旧システムの運用まで把握するため、緊急にユーザへの協力を仰ぐことだってある。
そして「問題があったとき」、現場の努力でなんとかする場合が多い。データが汚れていれば、ユーザに突き返している時間が無いから、こっちでクレンジングする。たとえ旧システムの運用の不具合だったとしても、新システムで「いい感じ」に動くように直してしまう。そういう、臨機応変の対応が、プロジェクトの完遂につながる。現場はそう信じて頑張る。
そういう「なんとかする」が、桁レベルで通用しなくなることがある。汚染ファイルが30個なら、完徹一晩で済むかもしれぬ。だが、10万件だったら？
■3行まとめ
3行でまとめる。
- 建築現場に足場などの資材をリースする会社が、事務処理システムを2300万円で発注した（うち、データ移行費は70万円）
- 納期から4か月半遅れてデータ移行工程を終えたが、システムは動かなかった。デリバリ（入出庫）データと請求のデータに不整合があったためだ
- ユーザは契約を解除。ベンダは既払い報酬・売買代金・弁護士費用あわせて2100万円の支払いを命じられた。ベンダの反訴は棄却、過失相殺も認められなかった
建設現場リース物件管理システム事件と呼ばれている。
様々な判例を見てきたが、これほどきれいな負け方はない。よくあるのは、ユーザとベンダの双方に何かしらの責任を認め、それを何割かで割って取り分を切りなおす判断だ。この裁判では、それをしていない。
ベンダの落ち度は丸ごと勘定され、「申し開きのない」失敗となっている。
そして、データの不整合の総数が判明したのは、プロジェクトが破綻してから2年後で、別の後継ベンダが数えたときだった。その数、10万7316件。被告となったベンダは、自分が移行したデータの不整合が何件あったか、最後まで知らないまま終わっている。
ただし、これは何もしなかったベンダの話ではない。ヒアリングを重ね、例外処理の手順書まで作り、納期後もシステムを動かそうと調査を続けていた。それでも、移行元のデータの状態に気づかず、補正方法も決めないまま進めたことが、致命傷となった。
■移行の恐ろしさ
移行がいかに恐ろしいかは、ベンダが述べたこの一文を読んだ方が早い（なお、これはベンダの言い分であって、裁判所が認めたものではなく、むしろこの理屈を退けている）。
「移行の対象となるデータは、原告の過去10数年分のデータである上、原告は毎月約1000件の請求書を作成していたから、被告がこのような膨大なデータについてデータ不整合の有無を確認することは、開発期間が10か月程度、報酬額が2310万円程度の小規模なシステム開発プロジェクトである本件請負契約において、現実的ではなく、実際上不可能であった」
負けた側の言い分だが、現場感覚としては分かる人が多いだろう。データに不整合があり、それが移行の失敗を招いたのだから。そして、この言い分こそが、事件の核心になる。
この不整合は、どこで起きているのか？ 判例から作成した模式図がこれだ。
図の赤点線が不整合の箇所になる。
不整合が起きるメカニズムは次の通り。
- 建築現場で足場の資材を貸出す
- 貸出・返却結果はデリバリデータに反映される（※）
- デリバリデータを元に、請求データ・請求書を作る
通常であればデリバリデータは最新化されているが、「滅失」や「リース止め」により、※にデータが反映されない場合がある。滅失とは、貸し出した資材が紛失や破損で、通常の請求ができなくなった状態をいう。リース止めとは、資材は現場に残っているものの、特定の日以降、リース料の請求をしない扱いにするものだ。
こうした特殊な場合には、デリバリデータからコピーした「中間ファイル」を作成し、それを手入力で訂正していた。そして、訂正内容は「手書きデリバリ台帳」で管理していた。
その結果、デリバリデータと請求データは、整合性が取れていない状態だった。そうした状態で、月に1,000件の請求書が作成され、過去10数年分の蓄積があったことになる。これを「70万円」で移行するのは無理があるだろう。
■チャンスはあった
ベンダは知らなかったのだろうか？
そうではない、別にベンダはサボっていたわけではない。契約前の2010年11月から、分かっている限りで合計6回、ヒアリングを行っていた。それぞれの機能や画面、運用方法、請求・入金管理など、順序や網羅性は教科書通りである。
例外処理についても、専用の回を設けてヒアリングを行っている。さらに、「滅失が発生した場合の運用」と「リース止めが発生した場合の運用」とに分けて手順書を作成し、ユーザに渡している。
旧システムでは中間ファイルと手書き台帳を経て請求に渡る流れは、その手順書に書かれていた。だから、全く知らなかったというわけではない。
知らなかったのは、その「件数」だ。例外処理が何件あるかは、訊けば手がかりを得られたかもしれないが、訊かなければ最後まで分からない類の情報だ。
では、ユーザは伝えなかったのだろうか？
そうではない、別にユーザも協力を怠っていたわけではない。2011年6月に契約した、まさにその日の打ち合わせで、ユーザはこう説明している。
「現在はデリバリ台帳を手書きで作成している。システムがあまり信用できないため、L（業務1課）が手入力した帳票とデータの突合せを行っている状態である」
現行システムを「あまり信用できない」と、はっきり述べている。その理由として、①入力ミス、②滅失・リース止めに対応できていないことまで説明している。
そして、ユーザは移行対象として以下を挙げて、そのデータを一式、ベンダに渡している。
- デリバリデータ
- 請求データ
- 経理データ
- 在庫データ
- 以上を含む十数年分のデータ
旧システムのバックアップも渡されている。中身に何が入っていたか、裁判所は認定していないものの、ユーザはバックアップデータを提供しており、ベンダはこれを調査・分析することによりデータの不整合の件数や理由を把握し得ることがうかがわれる、と述べている。
つまり、ベンダは「知らなかった」という訳ではないし、「知らなかった」では済まされなかったのだ。
判決は、ベンダの契約当時の認識を、こう認定している。
「滅失・リース止めはそれほど頻繁に発生せず、入力ミスも多くないと推測し、データ不整合は多数に上らず、移行後に手作業で修正することで対応可能と見込んでいた」
判決文はこの通り。「推測」「見込んでいた」という推測の根拠が何だったのかは、記されていない。そして裁判所は、ここを刺している。
「被告がデータの移行業務に当たり、原告の業務における滅失・リース止めの発生頻度について尋ねたことや、本件旧システム上のデータを調査・分析したことをうかがわせる証拠はない」
書き方に注目してほしい。「尋ねなかった」ではなく「尋ねたことをうかがわせる証拠はない」とある。この書き方の方が、実は怖い。もし、尋ねていたなら、尋ねた結果が何であるか、残っていたはずだといえるから。
ユーザは現行システムを「あまり信用できない」と述べ、ベンダはその頻度を「推測」した。「たぶん少ないだろう」の反対語は、「たぶん多いだろう」ではない、「知らない」である。
「滅失」「リース止め」という言葉は、例外の顔をしている。耳慣れない言葉だからといって、頻度も例外とは限らない。貸し出した足場が戻ってこないことが、日常的なのか頻繁に起きないのかは、現場に訊く必要がある。
だから、この事件から得られる「よい質問」はこうなる。
「滅失って、月にどれくらい出るのでしょうか？」
「その例外処理をしている方は、どなたですか？」
「その方が『今月は多いな』と思うのって、何件くらいのときですか？」
例外処理だからといって、頻度も例外的とは限らない。
また、移行という作業を独立したプロセスだという観点からは、こんな「よい質問」が挙げられる。
（見積もりレビュー時）「この移行の見積もり70万円の内訳を教えてください。単にデータを入れるだけのように見えますが、移行元データの正しさ（整合性）を調べるタスクは見積もっていますか？」
この質問は、ユーザへ見積もりを出す前のベンダ内部でのレビュー時に投げかけたい。あるいは、見積もりを提示されたユーザがベンダに確認する際にも有効だろう。
■移行の「正しさ」とは
移行前後の時系列はこうなる。
2012年4月 新旧のシステムを並行稼働させ、移行作業を開始
2012年4月23日 契約上の納期（新システムの開始予定日）
2012年9月 データ移行作業が完了したことをベンダが報告
そして、9月の議事録では、8月末の締め分について、
・全631現場
・不具合あり…229現場
うち 移行データの問題…88現場
合計欄のバグ…103現場
その他…38現場
と報告されている。
バグならまだマシだ。想定通りでない原因まで突き止められ、いつ直せるかといった対応の話に持っていけるから。
問題なのは、「原因不明の不整合が多数存在することが判明した」というベンダの主張だ。表面的な現象としては、①過去の基本料が出る、②基本料が出ない、③過去出庫の請求が出る等といったものだが、なぜそうなのかが特定できなかった。
切り分けが出来ていない以上、旧システムにある元々の問題なのか、移行プロセスの中で起きてしまった不具合なのか、分からない地獄に陥っている。
ベンダの「原因不明の不整合が多数あった」という主張に対し、裁判所はこう付け加えている。
「これらの事象については、被告のデータの移行に問題があったことによって発生したものであることも否定し得ない」
答えが分かっている今から振り返ると、元々の旧システムにあった不整合が、移行で火を噴いたと単純化できる。だが、調べていなかった以上、その問題はベンダが引き受けることになってしまう。
つまり、2012年4月～9月において、移行の「正しさ」について、確かなことを言える人は、ベンダにはいなかったのだ。
では、何をもって「正しい」と判定したのか。
破綻後の協議で採られたのは、新旧のシステムでそれぞれ請求書を出力し、内容を比較して差異に赤ペンを入れる方法だった。1件1時間かかったと議事録にある。
注意してほしいのは、照合の単位が「現場」であって、レコードではないことだ。「88現場で移行データに問題がある」ところまでは分かる。だが、その現場のどのレコードのどの値が、なぜ違うのかは、この方法では出てこない。
その結果、1件ずつ人が調べることになり、1件1時間かかり、時間切れになる。
この段階になって初めて「受領したデータに問題があるため、補正にはご協力や追加費用が必要です」と申し出ても、交渉は難しい。実際、補正作業は請負業務の範囲外と主張したのに対し、ユーザは契約書に明記された業務だとして受け入れなかった。
従って、移行の「正しさ」について質問を投げかけるなら、炎上するずっと前、すなわち、見積もりや、移行リハーサルの検討の時点で済ませておく。
「移行をしたとき、データが合わなかった場合の話をしたいのですが……」
「不整合が見つかった場合、原則としてユーザへ差し戻しますか。それともベンダ側で補正しますか。例外的に扱いを変える条件も整理しておきませんか」
（更問い）「ベンダ側で補正するなら、その値が業務的に正しいということは、誰の判断になりますか」
どちらで補正するか、10分で済む話だろう。補正する人と、その「正しさ」を判断する人など、担当名まで割り振っておく。破綻後の協議事項なら撥ねつけられるが、平時なら調整できる。
■「正しい」移行とは
プロジェクトが破綻してから2年の月日が経ち、後続のベンダが移行を行った。その方法は以下の通り。
- 旧システムの移行対象のデータを抽出
- 移行プログラムによる自動補正（107,316件）
- 新システムへ移行し、新旧を並行稼働
- 追加で45件を手動でデータパッチ
移行をナメると高くつく。
ただし、高くつくのは、不整合が多いからだけではない。不整合が何件あるかを知らず、何が「正しい」かを決めず、どう補正するかを、移行本番になるまで決めていなかったことが致命傷だといえる。
次に見積書で「データ移行作業」の一行を見たときは、「70万円」と「10万7316件」を思い出そう。この2つの数字の間にあるものは、技術力の差ではなく、数えたかどうかの差になる。
最近のコメント