Photo:Mint Images/gettyimages
そもそもなぜ基幹システム更新はトラブるのか？魔窟と化した旧システムを解きほぐし、最新技術も分かる人材をそろえなければ解決できない。なのに現場にそんな伝説のパーティーなどいるはずもなく……。特集『DX180社図鑑』（全31回）の＃12では、涙なしには語れない、基幹システム更新の現場のドロドロを、どうしようもなくカオスな企業ITシステムの実態に詳しいメンバーたちがこんこんと語った。（聞き手／ダイヤモンド編集部 鈴木洋子）
Henry @HighWiz 大手SIerの大規模プロジェクトのPMを経て総合コンサルで活躍中
よんてんごP @yontengoP ブラックIT企業を渡り歩く病人X（旧Twitter）er。最近はブラックでなくなったらしい
むぎSE @MUGI1208 社内SE社畜ツイッタラー。炎上プロジェクトの遭遇率が高め
shin @shin_ofshins ウェブとアプリに詳しいコード書く系スタートアップ経営者
かち @kachi_saas 諸事情で外資ITソフトウエアベンダーを卒業★した人
基幹システム移行なんて余裕！
そう考えていた時期が僕にもありました（コンサル談）
――ここまでるる基幹系システム更新にまつわるトラブルを見てきましたけど、そもそもなんでこんなに大変なんでしょうか。
Henry 僕もコンサルになったとき、業務フローの棚卸しをすれば基幹系システムの移行なんて余裕って自信あったけど甘かった。「『注文番号』と『注文ナンバー』と『受注番号』と三つあるんですけどどうなってるんですか」って聞くと、「この条件のときは『注文番号』で、この条件のときは『注文ナンバー』、この条件のときは組み合わせて使う」とか言われるわけですよ。
――その項目は全部異なるものなんだ。それどんな地獄かな。
Henry で、最初に「SAPの標準カラムはこれなのでどうこれらをマッピングするか決めてください」ってSIerに言われるわけですよ。で、そこのマッピングをミスるんですよ。
むぎSE（むぎ） すごい分かる。ミスりやすいですよね。
Henry データベースの中に入っているデータが、それだけだと意味を成さず、ロジックかませて組み合わせないと読み取れない、つまりデータベースになっていない状態が間々あるんですよ。項目名が内容と全く合致してないという。
例えば、「取引先」というカラムがあったとするでしょ。ここから受注したり請求したりすると思うでしょ。違うの。例えば大手のグループ企業と取引するときに、取引先名称はグループのホールディングスだけど、個別の契約に基づく受注先や請求先は各子会社で、それを区別するための判定ロジックに使うフラグが別のカラムにあって、みたいな。こういうのを読み解かないとデータベースを整理できない。
あとはテーブルの11列目と12列目になんか1とか3とかの数字が一個だけ入ってるんだけど「これ、何」って聞いたら「多分何かの計算で使われているフラグです」。「その計算式誰が知ってるの？」「いや分かんないけど10年前からこれで動いているんです」って。
こういう状態でSAPを入れるときに、じゃあ請求先のカラムには何をマッピングすればいいのか、ってことですよね。単純にデータベースを移行するよ、って横スライドしてもうまくいかない。要は実質的にはデータベースの単純な移行ではなく、一から作り直す必要があり、システムに関するコードなどのプログラムを読み解くことが必要だったのに、まさかデータベースがそんなふうになっているとは誰も思っていなかった。
よんてんごP（よん） 本来はテーブルもう一回作り直しましょうって話なんだけどね。僕も以前のクライアントで2000年以前と以降でテーブルの中身の使い方が全然違います、っていうのがあった。この辺の実態をどこまで調べたら、「ここまで調べ終わったから、安心してSAP移行しましょう！」って言い出せるかの基準が知りたい。結局何でつまづくかっていうと、既存システムの調査とか洗い出し不足だから。
――このあたりはSAP移行もそうだし、いろいろな基幹システム刷新が炎上するときのポイントになりそうな視点ですよね。そもそも元システムがひどい、という。そもそもなんでこんなことになるんでしょうか。こういう地獄データベース作っちゃ駄目ってルールないの？
