データ移行が厄介なのは、その遅効性にある。
知らない人は「旧システムのDBから抜いて、新システムにデータを移すだけでしょ？」なんて簡単に言う。だがそれは、酷い目に遭ったことがないから。
データ移行は、調べれば最初にすべて分かる、という仕事ではない。データをもらって調べて初めて、次に何を調べなければならないかが分かる。調査や検証を厚くしても、契約前の段階で、不確実性をすべて消すことができない。
だから、「できます」と約束したことが、できるかどうか、怪しくなってくる。そのころには、費用も納期も決まっている。おいそれとは動かせない。
悪くすると、システム切替の当日になって、新システムに反映できないことが判明する。明日からサービス開始なのに、移行テストで扱わなかった古い年代のデータや、移行リハーサル後に追加・更新されたデータなど、汚れていたり、データそのものが読めないなんてことがある。ざらにある。ざらにある。
なぜ、そんな不具合があったのか？ 調べている猶予は無い。だから現場の人たちは、超人的なパワーと結束力で、なんとかしてしまう。ログや一時ファイルから読み取って補完したり、過去の蓄積データから錬成したりクレンジングしたり、とにかくサービス開始できるよう、「なんとか」する。
努力と根性でなんとかできてしまうと、その苦労は「無事に稼働しました」の一言に圧縮される。何が足りず、何を根拠に補い、どこを直したのか。作業の記録は残っても、判断の経緯までは残らない。振り返りでも、「あのときは大変だった」という思い出話になる。
まして、世間様にそのまま公言できる話でもない。「お客様からいただいたデータを、そのままでは使えなかったので、徹夜でつじつまを合わせました」とは、成功事例の壇上では口が裂けても言えやしない。
こうして、次のプロジェクトでも「データを移すだけでしょ？」が繰り返される。
もちろん、毎回なんとかなるわけではない。
これは、「なんとか」ならなかった現場である、国際確認検査センターのデータ移行の話だ。
しかも、移行当日よりもずっと以前に、問題が見えており、ユーザに説明していたにも関わらず、移行の遅効性が爆発した話だ。
■3行まとめ
3行でまとめる。
- 「旧システムのDB構造の情報は全部出せる」というユーザを信じ、ベンダはDB構造を解析する工数を積まず、移行費の見積もりを180万円に抑えた
- 契約後、「平成14年版」のDB構造情報が開示できないことが発覚。ベンダは「平成15年以前のデータ」は移行できないと説明し、ユーザは「全部必要」と主張
- 契約は変わらず、「平成15年以前をデータ移行の対象外とする」と記載した文書が無いため、裁判所は「平成15年以前のデータ」も移行対象とし、ベンダの主張を退けた
なお、この「DB構造の情報」について、判例には具体的には示されていない。スキーマなのかER図なのか分からない。
分かっているのは、移行対象のデータは、各年度ごとにあることと、旧システムは、平成14年版と平成16年版があり、DB構造情報が違っていることだ。
平成14年版のDB構造情報が分からないのに、全てのデータを移行せよ―――なんて、ベンダからすると無理な話に見える。これを、「裁判所は現場を分かっていない」と読むと、教訓を取り逃がすことになる。裁判所は、そこを理解した上で契約に戻っている。
「言った」「言わない」と空中戦になるとき、裁判所はどこを見るか？
ここからは私の理解だが、裁判所は「合意できていた時点」まで戻っているように読める。争っていないところ、直近で双方の意思が一致していた時点――すなわち契約の時点だ。おかしくなってくるのは、合意できていた時点より後なのだから。
■合意できていた時点＝10月16日
本案件の場合、平成19年10月16日となる。
最初に結んだ契約の後、開発の追加や作業が増えたため、金額と納期を変更している（金額は1680万円から3045万円へ、納期は同年12月末頃から翌年2月末へ変更）。そして、この日は、契約変更とともに、重要なやり取りがされている。
まず、10月16日は、ベンダが旧システムのDB構造情報を受け取った日でもある。
ベンダも慎重に進めてはいた。
DB構造情報が必要であることは打合せの都度伝えていたし、9月には「10月中旬までに情報を取得できない場合には、移行を作業範囲から除外する」という提案までしている。この日に提示した資料にも、必要な情報の開示がない場合はデータ移行の一部は実施できないこともあり得る、という記載もあった。
ところが、この日にDB構造情報が提示された。なので、「移行を除外する」という説明をしなかったのだ。判決に残っている発言はこうだ。
「今日、（必要な情報を）いただきましたので、そこは説明を割愛させていただきます」
本当は、DB構造情報が不足していたのだが、もらったばかりのこの時点では分からない（まだ調べてないからね）。だから、この発言でベンダを責めるのは酷だろう。
また、ベンダは、移行作業を除外することで、費用を削減できるという提案をしている。過去データは、必要な分だけを手入力すれば、総額を抑えることができるという案だ。
だがユーザは、手入力はできない、過去のデータは全部必要だと伝えた。ベンダは「確かに、はい」と、過去データ全てが移行対象だということに合意した。
2日後の10月18日、ベンダは要件定義書を作成する。そこには、移行作業の対象外とするデータが4項目、書かれている。
- 法改正で新設された項目
- ユーザの管理対象外の項目
- 旧システムの仮保存機能で保存された項目
- システムで管理の対象外の項目
そして判決は、こう続ける「平成15年以前のデータについては何らの記載もない」。
■おかしくなるのは、11月に入ってから
もらった情報を解析したところ、データが不足していることが判明する。
「旧システム」と一言で丸めているが、実は、「平成14年版」と「平成16年版」の2種類が存在する。そして、もらったDB構造情報は「平成16年版」だけだった。これでは、平成15年以前のデータを移行できない。
ベンダはこう問い合わせる―――最大限努力はするが、実施不可能だった場合の対応を検討する必要がある。手入力での移行はできないか、書類としての保存はどうか、そもそも移行が必要な理由は何か。
ユーザはこう応える。
- 平成15年分だけでも1,000件以上あるため、手入力は現実的ではない
- 法令で過去15年間の保存が義務づけられている
- 持ち帰り検討し、代表者に相談する
そしてどうなったかって？
判例には、「持ち帰り検討結果」が書かれていない。
そのまま、翌年のリリースに突入する。
- 2月：ベンダは機器を設置し、ソフトウェア一式とマニュアル等を交付
- 3月：移行作業中に旧システムの端末が停止。サーバを再起動したところデータ不整合が生じ、業務影響が発生し、ユーザは契約解除の意思表示をする
■裁判所の判断
「情報が出ないので移行の対象外」 vs 「全件と約束した以上は全件」という対立構造に、裁判所はどのような判断を下したのか。
裁判所の判断を箇条書きにすると、こうなる。
- データの一部が移行されないと、要件定義書の「現行業務を変更することなく運用ができる」という目的に反する
- ユーザは、法令により15年間の書類保存義務を負っており、1000件以上の手入力は現実的ではない旨を説明している
- 要件定義書の移行の対象外4項目に、「平成15年以前のデータ」の記述が無い
- ベンダは「必要な情報の提供を受けたと誤解していたとはいえ」、「確かに、はい」と了解している
ベンダは「平成14年版」のDB構造情報が必要だと言っていた。それが無いと、全部の移行はできないと、あれほど言っていた。ユーザは、持ち帰り検討すると言った。それはどうなったのか？
判例に書かれていないのが全てだろう。少なくとも、平成15年以前のデータを移行対象から外す合意が成立したとは認められていない。合意がなされていない以上、認められない約束となる。
判決を読んでいて息を呑むのは、あれほど口を酸っぱくしてきたベンダの説明が、判断部分でこの一言に圧縮されていることだ。
（ベンダの担当者が）旧システムのデータベース構造に関わる情報の開示がない場合、データ移行作業の実施は困難になる旨を繰り返し説明していることなどを考慮しても
「考慮しても」、それだけだ。
裁判所は、ベンダ担当の努力の量も、説明の回数も、実現可能性も、量っていない。契約はどうなっているか、どこまで合意されており、どこまでやったか、それだけを量っている。説明は事実であって、合意ではない。裁判所が探していたのは、合意のほうなのだ。
「平成14年版の構造情報がないなら、その部分は対象外だ」という見解は、技術者としては完全に正しい。事実が変われば、約束も変わる。
だが契約は、事実では動かない。合意でしか動かない。
契約した時点では、あり得ない約束ではなかった。構造情報がもらえる前提なら、全件移行はあり得る約束だった。あり得なくなったのは後からである。そして、後からあり得なくなったからといって、約束は消えない。
これが、移行の遅効性の本質だ。
ここからは想像だが、「持ち帰り検討します」のまま、返事がこないユーザに業を煮やし、自分で「なんとか」しようとしたのかもしれぬ。もらったDB構造情報から類推し、平成15年以前のデータも復元する方法を検討していた可能性もある（ただし、どこにも書いていないので、あくまで可能性の話だが……）。
そして、「なんとか」ならなかった。
■「後から分かった」ことを交渉の場に乗せる
ここから導ける教訓は何か？
移行が遅効性を持つということは、「後から分かること」が必ず出てくるということだ。「後から分かること」は、必ず、出てくる。これは、移行の失敗ではなく、移行という作業に付きまとう性質といってもいい。
この事件の9月から12月は、移行の遅効性そのものだった。「足りない」「なお足りない」「何が足りないか分かった」「それは手に入らない」―――4ヶ月かけて、分からないことを減らしていく作業だった。
問題は、この「後から分かった」ことを、どうやって交渉の場に持ち込むかだ。
ここで、似て非なる「後から追加された」と区別しておく必要がある。
この2つは、よく似ているが全く異なる。
「後から追加された」もの―――すなわち、契約後にユーザから出てきた新しい要望―――これは、まだ扱いやすい。少なくとも、交渉のテーブルには乗る。「これは追加要望ですね」から議論がスタートするからだ。金額と期間で揉めるにしても、揉める土俵はある。
だが、「後から分かった」ものは、こうはいかない。
「調べたところ、平成14年版の構造情報が無いと、移行できないことが分かりました」―――このような「後から分かった」報告に対するユーザの返事は、しばしばこうだ。
「それくらい、契約前に洗い出して見積もっておけよ」
予知能力者でもない限り、無理な相談だろう。
「後から分かった」という言い方は、ベンダ側の認識の変化に見える。ユーザは「私のせいじゃない」と思っている。だから、「そちらの調査不足（あるいは見積もり不足）でしょ」と突っぱねられる（たとえ契約前に「旧システムのDB構造情報は、全部出せる」と言っていたとしても！）。
さらに「後から分かった」という言い方は、ベンダ側の落ち度を告白しているように聞こえる。「調べたら、こうでした」は、ユーザに「調べ足りませんでした」と聞こえる。
「判明しました」「発覚しました」という言い方には、主語がない。言うほうは中立のつもりで使う。だが聞くほうは、主語を補って聞く。補われる主語は、たいていベンダである。
ユーザの後出し情報によって「後から分かった」にも関わらず、あたかもベンダのせいであるかのように見られる。ややもすると、議論の土俵にすら乗ってこない。これは、やりきれない。
だから、言い方を変える。「後から分かった」と言う前に、相手の要望や、後出し情報を置くのだ。
変更前：開示いただいたDB構造情報を調べたところ、「平成14年版」が無いため、全データの移行ができないことが判明しました。
変更後：ご要望として、全データの移行が必要だと伺っております。この実現のために「平成14年版」のDB構造情報が必要なのですが、開示いただいた中にありません。
要するに、「あなたの要望から派生した事実」という体（てい）で話を切り出す。変更前も変更後も、同じ事を言っているのだが、ユーザの印象は変わる。少なくとも「全データの移行」のために動かなければ、と動機付けが与えられる。
ユーザの立場からしても、入りやすい。見知らぬ「平成14年版」よりも、「全データの移行」という、自分の口から出たフレーズから始まる話のほうが、まだ受け入れやすい。「人は自分の言葉を裏切ることはできない」（チャルディーニ『影響力の武器』第3章）。この特性を大いに活かそう。
ここで初めて、ユーザが交渉のテーブルに着席する。手入力の移行や、書類での保存、そもそもなぜ移行が必要なのかを尋ねるのは、その後の話だ。
■交渉のテーブルでの「悪い問い」
では、交渉の場で何を質問するか？
まず、質問してはいけない問いがある。
「なぜ、平成14年版のDB構造情報が開示されないのですか？」
「なぜ、過去のデータの全てが必要なんですか？」
「なぜ、手入力だとダメなのですか？」
そもそも最初に、「全部出せる」と約束したのに、出せなくなった。移行に必要なことは何度も説明していた。なのに、なぜ出せない？そもそも昔のデータは必要なの？ベンダからすると至極もっともな問いだろう。しかし、これは尋ねてはいけない「悪い問い」だ。
これを聞くと、ユーザは嫌がる。というより、怒る。
なぜ、こんなことを知っているのか？かつて私が、相手を怒らせる、というかブチ切れさせたことがあるからだ（もっとも、私の場合は営業担当になるが）。
その営業担当は、「移行元データは、正しいものが全部ある」と勝手に判断し、移行元データの調査は不要だとして工数を積まなかった。ところが、移行作業中に、データの相当数が汚染されていたことが発覚する。
切羽詰まっていた私は、「なぜ、ちゃんとしたデータが出せない？」と会議の場で詰問したところ、相手も売り言葉に買い言葉で、「知らんがな、オマエがなんとかしろ！」とブチ切れて物別れとなる。
約束を破ったのは相手なのに、その理由を問うと、怒る。
その理由は2つある。
1つは、「なぜ」という矛先が相手に向いているから。
「なぜ」という聞き方は、理由を問うているようでいて、実は、非難が混じっている。特に、問題が発覚して責任の所在が争われている場面では、この聞き方は詰問に聞こえやすい。相手は、被告席に立たされたような気分になるだろう。
もう1つは、相手は答えを知らないから。
最初の時点では、全部だせると本気で思っていた。後になって分かったこと（移行の遅効性）。安易な判断だったかもしれないが、悪意はない。単に知らなかっただけだ。知らないことを問い詰められて、答えられる人間はいない。
そして、答えられないとき、人は答えられる唯一のことを言う。
「知らんがな、必要だから必要なのだ、なんとかしろ」
こっちに責任だけが降りかかってくる、この答えに着地させてはいけない。
では、どうすればよいか？
■主語を「相手の要望」にする
まず、「相手の要望」を主語にする。こんな風に。
「全データの移行が必要」だと伺っています。その実現のために、どのようにすればよいか、必要なものを整理させてください
人は、自分が最初に言ったことを守ろうとする。心理学では一貫性の法則と呼ぶが、現場ではもっと素朴なものになる。すなわち、一度「全データが必要」と言ったら、次の会議でも「全部必要」と言う。
だから、提案交渉は、相手の言葉である「全データの移行」から始める。
これを、ベンダ側の言葉―――例えば、「移行範囲の見直し」とか「対象データの絞り込み」で切り出すと、相手は、「全データの移行」が攻撃されたと身構える。
だが、相手が守るべき「全データの移行」を最初に持ってくることで、聞きやすくなる。そして、「なぜ」という詰問を「どのように」と置き換えることで、対決的な空気から、建設的な場にする。
相手の要望「全データの移行」は1ミリも動かさず、その目的に焦点を当てて、問い直す。その上で、その目的を「どのように実現するか」「実現にあたっての制約は何か」「時期など、動かせる要素があるか」を問う。
「『全データの移行が必要』なのは、法令で15年間の保存義務があるからと伺っております。根拠となる条文を一緒に確認できますか」
「『保存している』と言うために、何ができている必要がありますか？監査などで求められたときに出せればよいのか、一定の時間内に提示する必要があるのか、教えてください」
「新システムへの取り込みが完了するまで、旧システムで参照できれば業務は継続できますか？」
「過去データについて、日常的に検索するものと、照会があったときに取り出せればよいものを分けられますか？」
保存義務があることと、通常業務の中でシステム検索できることは、別だ。
判例のどこにも書いていないが、ひょっとすると、必要なものだけPDFでダウンロードできれば足りるのかもしれない。旧システムを参照専用として残せばよいのかもしれない。このヒアリングの中で、ひょっとすると「平成15年以前の過去データの扱い」が切り分けられるかもしれない。
結果的に、「なぜ、出せない？」から始まるディスカッションと同じ内容だと思うかもしれぬ。その通り、論理の流れは実質的に等しい。
だが、相手はロジックではなくパトスで動く人間だ。攻撃されていると感じたら、敵認定され、交渉は対決モードになるだろう。一方、「自分の要望」の実現に向けて、その「目的」に焦点を当てている限り、実質的に同じ問いをしていても、目的達成のための共同作業となるに違いない。
もちろん、「悪い問い」を「よい問い」に変えたからといって、このプロジェクトが助かったとは言えない。移行以外にも火種は抱えていたし、「平成14年版のDB構造情報」は、どんな聞き方をしても出てこなかったかもしれない。
それでも、交渉の入口は作れる。
「なぜ、出せないのですか」と問えば、相手は自分を守ろうとする。「ご要望を実現するために、必要なものを一緒に整理させてください」と切り出せば、参加してもらいやすくなる。人は、自分が出した言葉を守ろうとする。その心理に沿って、同じ問題に向き合う入口を作るのだ。
入口に立ってもらえれば、次の話ができる。何を守るべきなのか。方法は変えられるのか。どの制約なら動かせるか。費用や期間をどこまで調整できるのか。そして、誰が、いつまでに決めるのか。
「説明したのに、伝わらない」と嘆きたくなる場面はある。こちらは何度も説明している。資料も渡した。議事録にも残した。それでも相手が動かないと、もっと詳しく、もっと強く説明したくなる。
そんなとき、一度、問いを変えてみる。
「相手は、この説明を聞いて、何を判断すればよいのだろう？」
問題の説明を、相手が判断に参加できる問いに変える。相手の要望から始め、その目的を確かめ、選べる方法を一緒に考える。
よい問いだけで、プロジェクトを救えるとは限らない。だが、「そちらでなんとかしてくれ」と閉じられかけた話を、「では、どうするか」という協議へ進める入口にはなる。
最近のコメント