ダイヤモンドオンラインの記事を読んでいると、プッチンプリンやカフェオーレなど17ブランドが出荷停止に追い込まれるまでの大きな影響があったシステム障害の引き金となったシステム刷新はデトロイトトーマツコンサルティングが主幹ベンダーであったことが報じられていました。
当初は5月中旬の復旧を目指していましたが、システムの復旧は難航していて、6月中の復旧を目指すことに予定が変更されています。
障害が発生したのは4月3日、基幹システムを刷新した新システムに切り替えたことで発生しました。商品の受発注や出荷業務に影響が発生しました。復旧を進めたうえで、4月18日に出荷を一部再開しましたが、出荷データの不整合が生じたため、翌日の19日に出荷を停止しました。
現行システムの設計書
今回の江崎グリコのトラブルについて、詳細な原因は判りませんが、一般的に刷新時に発生しやすい原因は従来から運用を続けてきた所謂、現行システムの設計書などのドキュメントが、プログラムソースと合っていないことがあります。
どうしても、システムの度重なる機能追加が長年にわたって行われると、正しく動作することを優先せざるを得なく、ドキュメントをあとから直そうとしますが、また次の案件が入ってきてしまいドキュメントが結局直せずにプログラムと設計書が乖離していくことがあります。
システムを初期構築するときと比較して、保守や機能追加をする段階では費用を捻出することが難しく、結果、保守体制が脆弱な状況が続くと、設計書とプログラムの乖離は発生しやすくなります。
新システムを現行システムの設計書をもとに開発すると、現行のプログラムの動作とは合わなくなってしまうため、刷新システムの開発を行う前に現行システムの設計書へ現行プログラムに書かれている情報をもとに復元しなければいけません。この復元が曖昧な状況であると、刷新システムの開発が困難を極めることになります。
同値性確認試験
また、システムの結合試験や総合試験とは別に、現行システムと刷新システムの同値性確認試験を実施することが普通です。同じトランザクションデータをぶつけたあと、結果が現行と刷新で同じになることを確認します。
仮に刷新システムで大きな機能追加などをしてしまうと同値性試験が困難になるので、刷新システムをポーティングしただけの状態で現行と同値性試験ができていれば安心です。今回の江崎グリコの場合、この同値の確認がどの程度行われていたかは判りません。
移行またはサービス開始後の現行システムへの切り戻し
サービス開始に伴うリスクが高いプロジェクトは、移行中のトラブルやサービス開始後のトラブル状況によっては、現行システムに切り戻すジャッジポイントを設けることが多いです。サービス開始後に刷新システム側で受けたトランザクションデータを現行システム側にもかぶせておいて、現行システムをスタンバイ状況にしておきます。これも、機能追加を多く実施していると対応が困難になってしまいますが、大切な考慮ポイントです。
システム刷新の教訓蓄積が大事
システム刷新はどのお客さん、どのプロジェクトマネージャーにとっても滅多に実施することではありません。また、他のお客さんで発生した事象に関する教訓がなかなか共有されることもないため、次に活かすことができないことが大きな課題だと思います。ぜひ、江崎グリコには今回の原因と教訓を共有してほしいと思っています。
コメント