データ移行に潜むコンプライアンスリスク
データ移行とは、ソフトウェア開発…なかでも既に存在している現行システムから、新しいシステムへ切り替える際に、現行システムの中で使われていたデータを新しいシステムに移す作業のことを言います。
利用者…お客さまは、何千万、何億、何十億…と高額な業務システムの「器」だけが欲しいわけではありません。もちろんその中で取り扱われる「データ」だけが欲しいわけでもありません。
両方そろっていないと、それまで現行システムでできていたことができなくなってしまうのですから当然です。
両方そろって初めて「システム」は機能します。
しかし、ソフトウェア開発を「モノづくり」の延長線上にしかないと勘違いしている三流エンジニアにはそれがわかりません。
考えてもみてください。
今やスマホ１つでもデータの引継ぎができないせいで困った人がたくさん生じてしまう時代です。それを企業が求めないわけがないじゃないですか。
もしみなさんがお使いのスマホ、そのなかのアプリでデータが一切引き継げないようなものがあったらどうしますか？
機種変更するとすべてがリセットされてしまう…連絡先も、SNSも、各種アプリやゲームのアカウントも引き継げないとしたらどうしますか？
あるいは各アプリごとに有料だったとしたらどうでしょうか？
しかも、そのたびに個人情報のリスクが出てきたとしたらどう思いますか？
はい。
そうです。
ここでお気づきの方もいらっしゃると思いますが、データ移行とはすでにお使いのシステムを破棄し、新しいシステムへと切り替える際には必ず必要なことで、エンジニアはそのことを前提としてシステムを設計し、組み上げていく必要があるのです。
データ移行やその難易度、お客さまが大切に取り扱っているデータの中身を軽視して、作りたいように作るだけのエンジニアが「三流」であるという意味もお判りいただけたかと思います。
実際、データ移行やお客さまが取り扱うデータのことなんて全く考慮せずにデータモデルを設計してしまうSIer、プロジェクト、エンジニアというのは後を絶ちません。そのせいで、あるシステム切替時にとてつもない難易度のデータ移行負担を背負わされたこともあります。
データ移行にしわ寄せを集めた例
ある請元の大手SIerから依頼されたもっとも大変なデータ移行は、次のような内容でした。
・現行システムは日本各地にスタンドアロンに近い形で複製されたものがある。
・その数、20弱。それを１つに統合したい。
・データの一部は集計用にホストサーバーに日次（夜間）で集められている。
・しかし、基本的に各地のサーバー間で連携はしていない。
たとえば東京から大阪に荷物を送付しても、東京システムでは「大阪に送った」
という実績は管理されているが、大阪システムとは連携されておらず「東京から
届いた」とだけ管理されている。
紐づくキーもないし、１日に１回だけとも限らない
と、こんなデータ移行をすべて紐づけないと統合なんてできやしないというので、物理的につながりのないデータを、移行後にはすべて利用できるようにしなければならないミッションが課せられたわけです。
もちろんその大手SIerが悪いわけではありません。
そもそもシステムを提供する際にそのシステムをどのようなライフサイクルで見るべきかという点で深く考えていなかった現行システムを提供したSIerやエンジニアに問題があるのです。
当然、その請元の大手SIerもお手上げ。
色んなパートナー会社に打診しても、どこも請けようとはしませんでした。それほどの難易度だったということです。
そんなこんなで開発プロジェクトが始まって１年強。
移行業務だけ引受先がないまま「器」の開発だけが進む中、白羽の矢が立ったのが私でした。
その打診が来るちょこっと前に、その請元の大手SIerではちょっと国際問題になりかねないようなニュース沙汰になったシステム障害事故があって、それをごくわずかなメンバー引き連れて見事解決してしまったのが私でして…。
その際に作業をお手伝いいただいた請元の新人君たちから、私の知らないところで「神」と呼ばれていることを半年後くらいに聞きました。いや別に大したことしてないんで。ちょっと愚直な作業を、持ち前のハイパフォーマンスで短期間に済ませただけなんで。恥ずかしいったらありゃしない。
その功績から、当時の大手SIerの経営層にまで名前バレしてしまって
「sudaという人にやらせればいいじゃないか！」
ということになったのだそうです。私にも直接依頼はありましたけど、状況を聞く限り間違いなく大変なことになる（不可能とは言わない）ので「絶対ヤダ！」と言っていたのですけど、そこはそれ…しがないサラリーマンだったわけで…。
当時の上司から「大口顧客の副社長から直接依頼されたら断れないから、頼むよ…」といわれて半ば業務命令で泣く泣く担当することになりました。社員がどーなってもいいのか。
もちろん、すでに１年以上もの間開発を進めている次期システム開発チームはデータ移行の大変さなど知るはずもなく、好き勝手にデータモデルをこねくり回しているのでそのままデータを移動させて終わり…となるようなエンティティは何１つ残ってません。
37個あるエンティティを46個に仕分けするというだけでも大変なのに、前述のとおり
「そもそも複数拠点にあった関連性のないデータを１つにまとめる」
という巨大なミッションがあります。
ですが、これもなんとかしましたよ…。２年近くあったプロジェクト期間のうちリミットは残り８ヶ月を切った状態からのスタートで、色々な障害を乗り越えつつもギリギリ間に合わせることに成功しました。
しかも、大手SIerが見積った予算の半分以下で。
その余った予算を開発チーム側の炎上分に充てたのか、すべてが終わった時には大手SIerのなかで打ち上げが行われていましたが、その場でプロジェクト責任者の方が「大成功」と口にしていたのでスッと胸をなでおろした記憶があります。
…以来、その会社の同じフロアで働く方々から新たに「リーサルウェポン」という不名誉な名で呼ばれていた…ということをこれまた１年後くらいに聞きました。私の知らないところで勝手な呼び方しないで…。
その後、数年経ってそのSIerで作業している別のプロジェクトのメンバーに、品質保証部という立場となって訪問した際には、まだ覚えられていたのかフロアがざわつき、あるいは当時を知らないけれど噂を聞き付けた方々が様子を見に来たのか変な空気になっていました。
その数年間、私の噂ってどんな感じで広がっていたのでしょう…。
怖くて聞いてません。
それくらいシステム開発側というのは現行システムからのデータ移行のことや、次期システムへのデータ移行のことなど何も考えていないエンジニアが多いんですよ、ということです。
もちろんストレートコンバートできるシステムが良いシステムかというとそれもまた判断が難しいところがあります。結局は利用者、お客さまにとって最も使いやすいシステム、最も業務負担が少ないシステムこそが『良いシステム』です。現行システムがお客さまの業務と上手にマッチングしていないようであれば、劇的に変更を加えなければならないケースもあるでしょう。そのためにデータ移行が負担を背負うことだってあるでしょう。
ですが、開発側に立つとそこまで深く考えもしないで、現行システムのデータモデル設計者と次期システムのデータモデル設計者の板挟みにあって、その捻じれを一手に引き受け、かろうじてお客さまのビジネスを支えている縁の下の力持ちであるデータ移行担当者ということは知っておいてあげてください。
少なくとも私はそうした経験もあって、今では「器」であるシステム開発担当者よりはるかにデータ移行担当者に敬意を持つようになりました。
個人情報を取り扱う際の課題
さて。
少し話が脱線してしまいましたが、本題はここからです。
データ移行において昨今注意するべきことの１つに
「個人情報の取り扱い」
があります。
こと日本という国においては個人情報保護法という法律があります。他国にも似たようなものがあるかもしれませんが、少なくとも国際的に統一されるような代物ではありません。ゆえにＩＳＯなどとは連携していません。
そしてこの法律と強い結びつきがあるのがご存じプライバシーマークです。
今年もたしか改訂されて施行されたと記憶していますが、案外これがいろいろなところに影響を与えます。データ移行もその一つです。
ざっくりとプライバシーマークがデータ移行に影響を与える部分だけ抽出すると
事業主（お客さま）の個人情報の取り扱う目的が明確なこと
その目的を本人に伝えたうえで合意されていること
第三者利用（他社への提供）ルールが明確なこと
提供される（開発）側もそのルールに従うこと
匿名加工情報の取り扱い手順が明確なこと
などがあります。
一般に、SIerやエンジニアは「個人情報？マスキングすればいいべ？」程度にしか考えていません。上記箇条でいうところの「匿名加工情報」がこれに該当する…と考えているのでしょうが、匿名加工情報の条件や制約は結構面倒で、単純に個人名を別の文字に置き換えれば済むという話でもありません。そもそもマスキングすれば提供してもいいのではなく、その提供そのものを利用目的として合意していない以上、勝手な情報提供は許されません。
というかその程度にしか考えられないSIerはちょっと信用しないほうがいいと思います。なにより利用する側…お客さまのビジネスに支障をきたす恐れがあります。
にもかかわらず、安易に
「現行データを調査させてほしいから」
「移行設計をしたいから」
といって現行のデータを借用したいと言い出します。
もちろんそうしないとシステム開発に支障をきたす点については同情の余地はありますが、だからといって自分たちの都合ばかりを押し付け事業主やシステム利用者の社会的安全を脅かす可能性のある行為を許容していい道理はありません。
法を理解してないことを言い訳にすることもできませんし、理解していないからと言って許されることはないれっきとした犯罪行為となりうる可能性があるのです。事故が起きるか起きないかの話ではありません。
ちなみに。
大手SIerも含め、多くのSIerとお客さまとの間で取り交わされる一般的なNDA（秘密保持契約）の内容では個人データの取り扱いに関する十分な取り交わしはされていません（少なくとも個人情報保護法を十分に遵守できる内容とはなっていません）ので、その点にも注意する必要があります。
単純に機密情報を漏らさないと誓約すればいいという問題ではありません。
その際の過失について損害を払えばいいという問題ではありません。
特に個人情報保護法が改訂されてからは『個人情報』の定義が広くなり、匿名加工情報にすれば問題なし…というわけにいかなくなりました。仮名加工情報なるものもでてきたのでますますデータの取り扱いには配慮しなければなりません。
問題はこうしたデータを、個人情報を取り扱っている事業者からほかの事業者…すなわちお客さまから開発チームへ貸与する際の手続き的な問題がかなり大きな制約のせいで困難になっているということです。
①現在、本人たちに合意を得ている利用目的に合致しているか？
②利用目的に合致しない場合、本人たちの合意を得られるか？
③匿名加工情報、仮名加工情報に相当するデータの洗い出しは済んでいるか？
④第三者提供の手続きがお互いに整備されているか？
など考えることは山ほどあります。
もちろんそれらのデータに合致しないトランザクションテーブルであれば、貸与するのも容易です。しかし、匿名加工や仮名加工の必要なマスタテーブルやトランザクションテーブルの情報はそうもいきません。
また、ただ単に加工すればいいというものでもありません。
そもそも原稿データを調査する目的には、
「次期システムで禁則文字とする文字が含まれていないか」
という確認も含まれます。たとえば
「シングルクォーテーション(')を入力禁止する」
という設計にした場合、現行システムにそういったデータが大量に使われていた場合、「その設計を良しとするか」or「設計を見直してシングルクォーテーションを許容するシステムにするか」の再検討が必要なケースだってあります。
仮に、名前のなかにシングルクォーテーションが含まれていた場合、これを盲目的に加工してしまった状態のデータを開発チームに渡してしまうと、「個人名称にはシングルクォーテーションは使われていないから何も処理を加えなくてよし」と誤解してしまうことにもなりかねません。
事実、外国人の名前なども登録されているようなシステムでは、英字、数字、漢字、かなだけでなくそうした記号が用いられることは珍しくありません。
個人情報に対する調査方法
このような話をすると開発チームの人たちは
「じゃあどうすればいいんだ」
と言い出すところが大半でしょう。少なくとも私の身の回りのSIerやチーム、エンジニアはもれなくみなさんそうおっしゃいました。そう、自分たちではこの問題に対して「何一つ解決（Solution）できない」と言い切って見せたわけです。
じゃあどうするか？
そういった課題を解決するのがソリューションを生業とするエンジニアの仕事です。泣き言を言って他責にすることが仕事ではありません。プロジェクトとして立ち上げた以上、その進行におけるいかなる課題、問題でも解決できなければエンジニアリング、マネジメントとしては三流です。
では、具体的にこのような場合の解決策を１つ例として挙げてみたいと思います。
それは
調査用のDMLを作成すること
です。
DMLとは、データベースにおいてデータの検索・新規登録・更新・削除を行うための言語のことです。すなわち、SELECT文（検索）、INSERT文（新規登録）、UPDATE文（更新）、DELETE文（削除）などのSQL文を作成し、現行システムの運用担当者に実行してもらい、その実行結果をファイルにして送り返してもらう…というものです。
もちろんそのままのデータ一覧を抜いてもらうのは ✖ です。
それでは個人情報保護法に抵触します。
このようなときは、いわゆるSQL関数を駆使するのです。
特定の列（COLUMN）だけ抽出するのであれば、個人を特定しないデータもたくさんありますよね。
特定の文字が含まれているデータが存在するか？その数は？
→ COUNT関数（＋LIKE検索）どのようなカーディナリティとなっているか？その分布状況は？
→DISTINCT関数 + COUNT関数現在取り扱われてる金額の最大値は？
→MAX関数空文字は存在するか？NULL値が存在するか？
→DATALENGTH(カラム名) > 0
→IS NULL演算子
などいくらでも方法は出てきます。
こうしたDMLを作成してあげて、実行だけを依頼する形にすれば、個人情報保護法の指定する様々なしがらみには影響を受けることがありません。SQLクエリを.sqlファイルにしてあげれば、あとは実行をお願いするだけですよね。
特にCOUNT関数などで件数だけ調べるのであれば、そもそもデータそのものの情報でもないので絶対に抵触しないといえます（検索条件によほど悪意を載せない限り…）。
SELECT COUNT(*) FROM <table> WHERE <条件> INTO OUTFILE '/tmp/output.csv'
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
ESCAPED BY '\\'
LINES TERMINATED BY '\r\n'
;なんて内容にしちゃえば、簡易的なCSV形式になるのではないでしょうか（エスケープシーケンスとかもうちょっと見直す必要はありますけど）。
こうしてネタ明かしをしてしまうと他愛のないことですが、たったこれだけのことが開発チームの中で誰からも発案されないというのが実情です。
みなさんももしデータ移行で悩まれていたり、安易にデータ借用してしまっているようであるなら、参考にしてみてはいかがでしょうか。「事故さえ起きなければ大丈夫」と考えている方もいらっしゃるかもしれませんが、それは個人が勝手に判断していいものではありません。企業のガバナンスやコンプライアンスにも多大な影響を与えます。
すくなくともその責任が取れない立場にある人は無謀な挑戦に立ち向かうのではなく、回避する方向で検討されたほうが賢明です。
というか、エンジニアだからといって法に無頓着でいいと思うのはやめましょう。
いえ、エンジニアはまだしも、プロジェクトマネージャーを名乗るのであればそのプロジェクトの遂行に必要な知識の修得に惜しむようなことはしないようにしましょう。でなければエンジニアを含む多くのステークホルダーに迷惑をかけることになりかねません。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。