第十二章｜移行は、すべての結果が出る日だ
移行の日は、
ただの作業日ではない。
それまでに積み上げてきた
段取り、言葉、判断、合意。
そのすべてが、
一日の中で一気に表に出る日だ。
この章では、
移行を「最後の工程」としてではなく、
プロジェクト全体の答え合わせの場として捉える。
なぜ移行で事故が起きるのか。
そして、移行を成功させるために
本当に必要だったものは何だったのかを振り返る。
１.移行の1日に、プロマネの成果が発揮される｜言葉の定義がズレると事故が起きる
―― 準備の差が、一日で可視化される瞬間の話
同音異義語に気をつけろ
以降、移行についての筆者の意向を、遺稿代わりに記す。もちろん冗談だ。ただ、これほど、同音異義語を、変換という作業において間違いやすい単語もあまりないので、優れた社会人たるあなたは、間違っても間違わないようにすることをお勧めする。
データ移行、システム移行、業務移行。一口に移行と言っても、３つの種類がある。それぞれ担当者が違うが、移行推進と一つの呼び方をされたりする。
エンタープライズリソースプランニング（ERP）
グリコという世界的企業が２０２４年に何を起こしてしまったか。他山の石はたくさん事例を知っておくことが慣用なので、ご紹介しよう。
そのためにはERPという仕組みの歴史を紐解く必要がある。筆者は、２０００年頃にIT業界に飛び込んだが、当時のシステム、特に基幹システムと呼ばれる情報群は、ホストコンピュータに多額の投資をしていることもあり、その企業の業務をすべて組み込んだ、完全カスタマイズであった。
要求分析は、その企業特有の文化であろうが、特有のデータレコードであろうが、すべて洗い出して、ベンダーはそのとおりに要件定義のまとめを支援した。そして基本設計に入れば、もう仕様は凍結したはずなのに、あとからあとから「伝え漏れてたけど」という要求が出てきて、画面設計書をベンダーが提出すると、「今のシステムとなんら変わらないように作ってくれ」と突き返されてしまっていた。
関連企業、サプライチェーンの一角に組み込まれた中堅・中小企業は、そういう大企業の、いわば勝手に定められた標準に合わせるために、自社のシステム投資よりも優先して、大企業に合わせるための開発をしなくては、取引が打ち切られてしまうので、仕方なく合わせていた。
例えば流通小売業の王者と呼ばれるダイエーは、かつて日本一の売上を誇ったものだが、ある中小企業が、自社の製品であるDVDを、ダイエーの流通網に乗せてもらおうと腐心して、営業活動がみのり、取引ができるようになった。その後に、ダイエーから、「うちと取引するからには、EDIデータのヘッダーレコードに●●を付与してもらわないと、伝送が通らない」と言われ、それに対応するソフト探しに人も金も時間もかけ、たった一種類のSKUを商品マスタに登録してもらうために、大きな投資を強いられることとなった。
トヨタ自動車を親玉に持っているSCMのピラミッドの中でも、同様のことが多数発生しており、そのシステムに対応していなければ、取引ができないという、本末転倒な日本独自の商習慣があった。
そして、ダイエーやトヨタ自動車が、多くのシステムベンダーを巻き込み、巨大な帝国を作り上げ、システムにおいても、もはや変えることができないだろうと、半ば日本人が諦めかけた１９９９年、その黒船はやってきた。
世にいうSAP革命である。多くの企業の書棚にも、ベストセラーなので、１冊ある。ドイツのSAPがもたらした革命は、業務にシステムを合わせるのではなく、システムに業務を合わせてしまおう、という、一大コペルニクス展開であった。
SAPの、当時出ていたパッケージという概念（これも、この頃から流行し始めた言葉である）には、世界中のありとあらゆる業種業態の、最適解と思われる基本かつ基幹の業務システムがあらかじめ用意されており、導入に当たっては、そのモジュール群の中から、自社の業務が「目指すべき」理想の業務に合わせて、機能を「選択」していくという手法を取った。そしてここが何より大事で、かつ、日本に受け容れられなかった理由でもあるのだが、カスタマイズは最小限、どうしても必要な場合のみ、そして、カスタマイズの費用は別途で莫大になる、ということだった。
そもそも、SAPのR/3を導入するライセンス料も馬鹿高い。１００人の社員がいたら、ライセンス料金だけで１億円、という高額なものだ。
今でこそサブスクなどで、一人当たりのライセンスという考え方は定着したものの、世界中の業種業態にオプティマイゼーションされてるとは言え、スクラッチ型開発でもないシステムに多額の投資を行うなんて、それまでの日本では考えられなかったことだ。そして、日本人が、システムに合わせて普段の業務を改善する、なんて、鼻で笑われる構想だった。トヨタにはトヨタのやり方、日産には日産のやり方、ホンダにはホンダのやり方があって、それを共通部品で代用するなんてことは、業務をする側も、システムを構築するベンダーも、考えただけで恐ろしい。自分たちの食い扶持を、ドイツ製だかなんだか、黒船だかなんだか知らないが、奪おうとしていることに対して、漠然とした不安が募り、軽く見たいという気持ちがあった。
しかし、国際化の波は、日本独自の商習慣にも影を落とし始めた。まずは会計分野だ。この頃から盛んに、国際会計基準（IFRS）が騒がれ始め、日本の会計が一部変更され、国際化を謳うためには、国際会計基準で書類を作らなくてはならなかった。同時期にSAPは、モジュールとしてFI（財務会計）を強く牽引し、財務会計の分野はそれほどカスタマイズが多くないため[3]、そのために数億円のホスト級のサーバーを用意し、FIモジュールを運用する企業が出始めた。
一度先鞭をつけてしまうと、次は流通にまで手が及ぶ。流通の中でも小売業は、大手を始めとして独自の商習慣で成り立っている側面が強かったが、仕入れ、発注、在庫管理など、考えてみれば定量のものばかり扱うのだから、システムの共通化も早晩訪れることになる。
大手が始めてしまえば、あとは右に倣えである。川下の方の企業は、致し方なくSAPと連携する仕組みを導入し、徐々に標準化されていく。
SAPのもう一つの側面は、大福帳データベースと呼ばれる。企業の経営資源管理を、海外の言葉でERPと省略するが、いままで当たり前のようにバラバラになっていたデータベースを、論理的に一つのデータベースとすることで、名目上はどんな立場の人でも、欲しいデータを必要なときに（オンデマンド）抽出できて、加工すれば経営者向けのダッシュボードになる、という触れ込みだった。
従来の経営レポートなどは、下からの積み上げ方式で、何営業日もかかって集計し、そこに、レポート提出者の恣意的な観点が注釈として付加され、経営者にとっては歯がゆいものであった。それを、毎朝、パソコンを立ち上げたら、ダッシュボードで昨日までの売上累計や、昨年対比、果ては株主への配当金など、すぐに確認できるとあっては、経営者が飛びつかないはずがない。経営者が白といえばカラスも白くなるのが商売なので、多くの経営者へのプレゼンに成功したERP、特に黒船であったSAPは、製造業、流通業、配送業、小売業と裾野を広げていった。
グリコの失敗を復習する
さて、グリコの話に戻ろう。そもそも、昨今の日本の文化では、大手のSIerやファームと呼ばれるどこぞの偉そうなやつらが、川上/川下の意味でしかない上流工程/下流工程を、人間の上流/下流と勘違いさせたまま仕切っている。そしてERPを導入するプロジェクトにおいては、企画段階からファームが入って（よく知られた監査法人系のファームだ）、ERP、特にS/４ Hanaを導入すれば起きるであろう期待効果をプレゼンし、多額のコンサルティングフィーを持っていく。前述したとおり、ERPは1999年以降、様々なパッケージが生まれては消え、ドイツの後を追って日本の大手SIerが自社製品を作り出し、それを導入するコンサルティングフィーとライセンス費用でがっぽり稼ぎたいと目論んだ。グリコのような国際企業からすると、ERPをSAPにするのは悲願であったろう。
現場の業務をSAPの標準テンプレートに合わせるため、いくつかのカスタマイズを実施し、開発が進み、移行を迎えた。しかし、移行本番で上手くいかず、切り戻しポイントを超えても導入が進まず、結果として、グリコの製品は出荷できなくなった。
グリコを扱う小売店の事情を考えてみよう。小売店は、棚が空くことを極端に嫌う。売り切れは機会損失だ。売れている商品があれば、在庫が常にあるように発注するし、特売の品であれば、一日に何回でも補充して、客数×客単価ではじき出される売上増に向けて、日々頑張っている。
グリコがシステム移行に失敗して、出荷できなくなった際に、「システム不具合なら仕方がない」とか「それは大変だ。システムが復旧するまで棚を大切に空けておいてあげよう」という小売店は、皆無である。
数週間も経ったころには、グリコの製品は他の競合他社の製品に棚割が変更されて、姿をみなくなった。これでは、システムが復旧したときであっても、戻る棚がないのだ。
これはただのシステム移行のエラーだけで片付く問題だろうか。移行本番に至るまで、ウォークスルー含めて、何度も何度も繰り返し移行を計画したはずだ。データ移行・システム移行・業務移行。移行担当者の心はどのようなものであったか。切り戻しポイントとは、ダメな場合に、以前のバージョンのシステムに戻るための最終地点であるが、それを過ぎて、データベースが上書きされてしまったら、現在の24時間365日運用体制において、もはや元には戻れないのだ。
誰の責任かの犯人捜しは、素人に任せておけばいい。コンサルティングファームだって、SIerだって、金銭を払ってもらうからには、プロジェクトの成功を願っているはずだ。悪意のあるプロジェクトメンバーはいない。コンサルティングファームだって、フィーだけもらってサヨナラではない。ゴーイングコンサーンで、未来へ続く事業に対し、汚点は残したくないはずだ。
移行担当者または移行責任者のせいだろうか。このような大きなシステム移行であれば、リハーサルは10回に及ぶ場合もある。計画時からデータベースの移行にどの程度の時間がかかるか、秒単位まで計測し、それを積み上げて、バッファを考慮して移行時間を決める。移行責任者が適当に決めたわけではない。
プロジェクト全体で、無理・無駄・無茶がなかったか、こういうところに弊害が出てしまったのは無念だろう。
委託と請負の法律上の扱いの差が、このような事態になったのだろうか。日本人の品質に対する意識は高い。そして2002年のみずほ銀行の時のように、拙速なシステム切り替えが害を生むということは十二分にわかっているはずだ。
誰もが責任は取りたくないものだが、ネットの掲示板では、コンサルティングファームがやり玉に挙がっていた。みんな、そんなにコンサルに痛い目にあっているのだろうか。そんなに、トンビに油揚げを攫われた経験が多発しているのだろうか。
コンサルを信じるな。これは技術者の巷間でよく言われる言葉ではあるが、彼らも彼らで、所属する会社のため、そしてプロジェクトの円滑な推進のために身を細らせて闘っている。
移行の担当者も責任者も、そしてその移行プロジェクトを牛耳るPMOも、要所要所で適切なアウトプットを出して、プロジェクトの承認を得て次工程に進んでいる。アプリケーションの開発にばかり力が入る日本の文化は否定しがたいが、システム移行について、グリコの影響でまた注目が高まることとなった。
エンジニアを目指す人からは少しばかり、縁遠い世界かもしれない。しかし、移行が成功して初めて、アプリケーションは日の目を見ることになる。移行がうまくいかなくても旧システムが稼働していてくれれば、コンチプランとして事業は続けることができる。保守切れなど、様々な要因があって、旧システムが使えなくなるということはあるが、事業の継続という大目的に立ち返れば、無理にでも動かす、というジャッジも下されるだろう。新システムでの商品出荷がうまくいかなくて、旧システムに戻ることもできなくて、4か月の予定しない出荷停止となった。機会損失は莫大だ。
移行の3要件
移行には大きく分けてデータ移行、システム移行、業務移行の3種類がある。時と場合によって、また、戦略によって業務移行が先でデータ移行が最後などという事態も起こりえるが、プロジェクトで線を引っ張っている以上、同時期に展開されることも多い。
データの移行は、極めて繊細だ。データが1レコード欠けてしまっても、問題の検出は簡単ではない。100行くらいのデータであれば、目視で確認できるだろうが、人間は、数万、それ以上のデータの整合性を確認することは本質的にできないため、100％の移行ができたかどうかは、ベンチマークを信じるしかないのだ。
企業間の争いから生まれる無駄な不整合もある。RDBMSは大手のメーカーがいくつか代表的なものを出しているが、例えばオラクルのデータベースを使っていた企業が、経費削減のためにMy SQLというLAMP環境を目指したとする。データは簡単にエクスポートとインポートができればそれに越したことはないが、普段皆さんが使用しているExcelのように、コピー＆ペーストすれば済むというものではなく、オラクルも自身の会社の売上を守るべく、そんな簡単にできないようにしているのではと邪推したくなるような複雑なつくりをしている。
データベースは、あなたが思い浮かべるような表形式ではなく、正規化されたエンティティが大量に点在しているようなものだ。然るべきバックアップが常に取られており、どこを停止点とするか、その前後のバッチ処理をどうやって止めるのか、停止時点のデータをどのように戻すのか、そしてバッチ処理とオンライン処理をどのように開局していくのか。この、1日乃至2日で終わってしまう移行計画の中で、寸分たがわぬタイムチャートで行われる。
試しに100件のデータを移行したら10分だったから、1万件だとその100倍、などという考えが適用しないことは想像に難くないだろう。構造が複雑になればなるほど、データの移行には時間がかかる。そしてデータのコンバーターがうまく動かないというような事態が発生しないように、入念な準備をする。
システム移行はデータ移行も含める場合もあるが、データが入る箱を先に移行して、空っぽの状態のデータベースを、従前のシステムと同等に動き、またシステムの運用期間に増加するデータ量を計算し、バッファを考慮して設計し、移行する。システムの移行後、最初のオンライン開局は、システムが動くかどうか、そしてデータベースがきちんと、想定した時間で返答があるか、何重にもチェックする項目がある。
それらを包含して、業務移行も行う。それほど影響のない事例を先に挙げておくと、新営業日報システムが稼働する社員数50人の会社があるとして、移行当日、いろいろバタついても、「最悪の場合は、昨日までの形式の日報で入力すればよい」となる。
しかし、影響が巨大なシステムが世の中には多数ある。例えばクレジットカード会社のホストマシン2台を、1台にまとめてダウンサイジングするという業務移行があった場合、その業務移行は、マシンそのものの新しいプログラムが動くのはもちろん、コールセンターや、入会案内をする各小売店の受付の業務、加盟店を管理する側のシステムや業務そのものの刷新。一つにボトルネックが発生すればその他のシステムにも影響が出て、引いてはエンドユーザーである、一般消費者が、小売店で買い物ができなくなるかもしれない。もちろんそのような事態にならないように、クレジットカードのシステムは分散処理を施して、一つの会社の障害程度でストップしないような仕組みを敷いてはいるが、それでも、「●●カードが使えない時間帯があった」というニュースは、ＳＮＳを通じて、真実がどこにあるかはともかく、拡散されてしまう。企業のブランドイメージにとっては大変な痛手となる。バグがあったかなかったかという責任論よりも、経営層の責任論に直結する。
業務の移行は、オペレーターが見る画面も変わり、データの処理の仕方も変わるかもしれない。ＥＲＰを「新たに」導入するのならば、従前の、微に入り細に入りフルカスタマイズしたシステムから、ＥＲＰの概念に合わせた業務への大変革が訪れるので、システムを使う人間側が、システムに翻弄される。
実際にシステムを使う人間に決定権はあまりない。経営層が導入を決定するが、プレゼンではピカピカキラキラの輝かしい未来像しか説明されないので、リスクや問題がどういう展開になるか、経営層は誰も予想しえない。内心ビクビクしているのは現場担当者の方だ。そしてその予感は、往々にして実際に的中してしまう。だからこそ、技術者は、ノルマ通り作るという頭の構造を捨てて、プロジェクト全体を俯瞰するような、マクロの視点を持って、プロジェクトに取り組んでいただきたい。
※本note記事は、これまでに公開してきた記事をもとに、構成を見直し再編集したものです。
👉第十三章（最終章） 最後はミクロで差がつく：現場を守る基本動作
【 固定リンク 】
プロジェクトマネジメントは、言葉でできている
