「チーム俺達」。かつて西武ライオンズには大沼浩二をはじめとした勝利を献上する試合を面白くする投手が多数在籍しており、彼らをして２ｃｈなどでつけられたニックネームです。
その後ノーコン全般を意味するものとしてまたたく間に１２球団に広がりましたが、２ｃｈの衰退とともに忘れられたキーワードになっていました。
そんな「チーム俺達」を思い出させてくれる記事です。
まずは、前回のネタのリンクから。
大学院の先生の主張がボール球だった
今回のシステム更新作業は、どのような内容なのか。神戸大学大学院工学研究科 特命教授の森井昌克氏はいう。
「これまで生産・営業・会計など部門ごとで分かれていた古いシステムを統合型システムに置き換えるというもので、大がかりかつ難易度が高い作業であると考えられます」
全体的に憶測が多いというか、まあ当事者ではないので憶測の部分が多分に含まれるのは仕方ないにしても・・・
既に行われている報道から、江崎グリコでは既に Opentext Archive の SAP オプションを導入していることが明らかです。従って、少なくとも SAP 旧製品である ERP ECC6.0 を導入・利用した実績があるのは明らか。
つまり、「古いシステム」（汎用機とか UNIX の内政システム）からの移行は無いか限定的だったと推測できます。
古いシステムが「部門ごとで分かれていた」かどうかは、江崎グリコ側から言及された記事を見たことがありません。旧 ECC6.0 (+Opentext) を一部部門や一部機能に限定して使用していた可能性も無いわけではありませんが、実装していた機能に対して費用ばかでかくなるぞ。
大手 SIer の SE の投げたボール球
大手SIerのSEはいう。
通常、あらゆる障害発生を想定してコンティンジェンシープランを立てておくものだが、いったん旧システムに戻して業務は継続するといったプランなどをきちんと準備していなかったのか。あくまで報道を見る限りでの感想だが、部門ごとに乱立していた何十年も使われてきたシステムをパッケージソフトを使って一気に大規模なERPに統合するという計画自体、リスクが大きすぎて、ちょっと無理があったのでは。1年くらいの期間を設けて段階的に新システムへ移行していくという方法を取っていれば、今回のような障害は避けられた可能性がある。
「何十年も使われてきたシステム云々・・・」は、先の教授のコメントと同じなので割愛。コンテンジェンシープランとか切り戻しなどはコンサルが当然やって然るべきものなので、釈迦に説法かなと。
どちらかというと、カットオーバーと停止を繰り返しているので「稼働開始から障害までに発生したトランザクションが、中途半端な処理になったため整合性が取れなくなり、特に２回目に至っては有限な時間内でロールバックやリカバリーができない状態になった」といったところではないかと思います。
Oracle 想定ね。
５／１９追記：おかしな言説がどんどん出てくる
数十年に渡って各部門で業務に合わせてガチガチに作り込まれていた基幹系システムを、パッケージのSAPに統合して一気に全移行するという、リスクしか感じないとてつもない荒技をデザインして実行してしまうのに少々驚きです。
(知識のない素人がやったのか？と思うくらい通常では考えられないやり方です）
この note が出てきたので目を通して見たのですが、なんだこれ。
基幹系を「一気に全移行」するという手法は、普通に行われています。理由は簡単で、一気に移行しない場合は新旧複数のシステムが同時稼働することになり、時間が経過するにつれてデータがどんどん乖離していってしまうからです。
単純に社員マスタ等を例にすると、新システムの社員情報はどんどん更新されるのに、旧システムは更新されない。すると社員情報が一部で古かったり存在しなかったりという事態が発生してしまいます。
これの対策として、新システムから更新差分を抜き出し、なんとかして旧システムに反映させなければならない。あるいは、新旧両システムを同時にメンテし続けることになります。
社員マスタのみなら極端な負担にはなりませんが、複雑なリレーションが張られた企業の膨大なDBに対して行う、つまり多数のテーブルを不整合なく行う必要があります。
システムを平行稼働させて機能単位で順次切り替えていく場合、切り替えのフェーズ毎に同期させるデータを明らかにし、いつの時点でどのデータをどうやって同期させるのかを決めなきゃならない。
まあその手法もやったことがありますが、BASISのテクニックで一気にガツンと切り替えられる一括移行とは異なり、各データの持ち主たる多数の業務関係者の力量に委ねられます。こっちのほうがはるかに難易度が高い。
