小売業基幹システム再構築の失敗例をケーススタディから学ぼう！

小売業基幹システム再構築は、「再構築」という単語のニュアンスから、“現行機能やユーザーインターフェースには不満はなく、現行小売業基幹システムは今後の企業戦略にも十分貢献可能であるが、IT技術の進化において現行のシステムが継続利用困難になっているため作り直す“との意味合いが感じられます。

したがって、現行の小売業基幹システムの入れ替えや刷新をする意思決定をすでにされているのであれば、別のブログに関連記述があるので、そちらをぜひお読みください。

（関連ブログはこちら小売業基幹システム入れ替え失敗の共通点　）本ブログでは、入れ替えやリプレースではなく、現行の小売業基幹システムの再構築を行った際に、間違った方法を採用して失敗した事例をケーススタディから研究し、あるべき方法を記述していきたいと思います。

小売業基幹システム再構築は現実的か
小売業基幹システム再構築失敗のケーススタディ(1)
小売業基幹システム再構築失敗のケーススタディ(2)
小売業基幹システム再構築の失敗例をケーススタディから学ぼう！～まとめ～

小売業基幹システム再構築は現実的か

そもそも過去における小売業基幹システムに関する大きな手直しは、古くは昭和の終わりに対する西暦への対応から始まり、消費税の導入や税率の変更、西暦2000年対応、更にはPC＋Windowsの発達に伴うネオダマ（ネットワーク、オープンシステム、ダウンサイジング、マルチメディアもしくはマルチベンダーの略称）への対応であり、大抵は小手先で行うことが多かったのですが、小手先対応が不可能になった時点で再構築もしくは入れ替えを行いました。

多くの場合は、機能を追加する目的でプロジェクトを立ち上げるのですが、並行して激変するIT技術の発達を無視できるはずもなく、既存小売業基幹システムを放棄し、継続利用が必要な機能を作りつつ、追加すべき機能を構築する方法が採用されました。

その方法は、大きく分けると「オリジナルでフルオーダー開発する方法」と「既存パッケージソフトウェアをベースにカスタマイズを加える方法」があります。現時点においては後者が現実的であり、カスタマイズも極力しない方向が主流になっています。

つまり、企業活動が唯一無二で他に類を見ない業務内容や最先端技術を持つのであれば別ですが、特に小売業においては同様もしくは類似した業務内容が大半であり、それらへの導入実績を持つわが国の小売業基幹システムには、必要な機能や技術例が豊富にあります。

したがって、小売業基幹システムについては、パッケージソフトウェアをカスタマイズするほうが有力選択肢と言えます。

小売業基幹システムを再構築するのであれば、次の2つの事例を参考にしていただき、小売業基幹システム再構築の失敗を回避していただければ、業界に長年お世話になったものとして喜びに堪えません。

小売業基幹システム再構築失敗のケーススタディ(1)

まず紹介させていただくのは、小売業基幹システムの再構築をする際に、要件定義でプロジェクトをスムーズに進捗させるために、別途費用が必要になることを曖昧にしたまま要件定義書に「現システムの業務内容を継承」「現状の機能を網羅する」という記述を入れて合意したケースです。

ユーザー企業から見ると要件定義書には多くの抜け漏れがあったのですが、「現システムの業務内容を継承」「現状の機能を網羅する」との記述があるので、抜け落ちた要件は現行小売業基幹システム同等の機能が追加されると期待したのです。

残念ながら期待むなしく、検収時点でも必要な要件が網羅されていなかったので、話し合いでユーザー企業が費用を負担する追加要件として合意しました。

ところが驚くなかれ、追加要件を含めた不具合が解消されたとして、システムベンダーが再度検収を依頼したのですが、またもや重要な要件が漏れているとしてユーザー企業は検収と費用の支払いを拒み、お互いの調整では合意が不能になって、判断を裁判所に委ねることになりました。

このプロジェクトでは、パッケージソフトウェアをカスタマイズして開発する形式で行うことをシステムベンダーが提案し、提案書にも「現システムの業務内容を継承」「現状の機能を網羅する」と記載されていたので、ユーザー企業はパッケージソフトウェアをカスタマイズして開発する形式の持つ前提を深く思考せず了解していました。

結果として裁判所の判断は、“「現システムの業務内容を継承」「現状の機能を網羅する」との記載が、「現行システムと同等」の機能を持つものとして合意され、そもそも「現行システムと同等」は具体的にどのような水準・内容のものをいうのかは明らかにならないものである。

今回のようにパッケージソフトウェアをカスタマイズして開発する形式を採用した場合には、持っている機能をそのまま利用することが前提であり、カスタマイズは最小限に抑えるように開発するのが合理的である“

としています。

つまり、要件定義書に具体的なカスタマイズの記載がない限り、小売業基幹システム再構築の機能はパッケージソフトウェアに従うことになります。

ユーザー企業は小売業基幹システム再構築の素人であり、言った言わないに拘わらずユーザー企業が満足する機能の定義責任を玄人であるシステムベンダーに求めることはできないのです。

小売業基幹システム再構築に関してこのような事態を避けるために、現行システムと同等とする場合はパッケージソフトウェアを利用することを避けるべきです。

また、費用面で有利なパッケージソフトウェアを利用するのであれば、この時に行う要件定義はパッケージソフトウェアの内容説明とカスタマイズに留めるのではなく、業務知識を持つメンバーが参加し、完成予定の小売業基幹システムをイメージしながら利用した業務のリハーサルを行って、実際の業務の流れに沿った小売業基幹システム再構築のプログラムを使った操作の問題箇所を指摘すればよいのです。

小売業基幹システム再構築失敗のケーススタディ(2)

もう一つは、長年の改修を積み重ねて利用してきた小売業基幹システムが企業の新しい取り組みに追いつかなくなり、小売業基幹システム再構築を決断して、RFPを提示してシステムベンダー複数社の提案内容を検討し、大手システムベンダーにパッケージソフトウェアを中核にした定額報酬で発注したケースです。状況としては以下です。

対象範囲は部分的に稼働したものの、途中で検収を受けた後の外部設計に追加要件が発生。

大手システムベンダーからカスタマイズが大きくなりすぎることが発覚したとの理由により、「現在開発中のシステムを捨ててでもフルオーダーで開発することが望ましい」として開発を “無期限で停止する” 旨をユーザー企業に通告しました。

一方、大手システムベンダーはRFP記載内容に沿った開発を定額報酬で請け負ったのであり、追加機能については費用の追加負担を要求。

しかしながら、ユーザー企業はRFPに “ITの専門家がいない” と明示しており、「ベンダーとして適切な指導等をせずに要件定義を進めた」として、パッケージソフトウェアを中核とした開発の放棄と費用追加について「適時に適切な助言をせず、適切な対処方法の提示もしなかったので“プロジェクトマネジメント義務違反”である」と主張し、大手システムベンダーの要求を拒絶。

このような事態を避けるためには、結果的に大手システムベンダーが通告したように、小売業基幹システム再構築に際してパッケージソフトウェアを中核にした開発を採用してはならず、フルオーダーで開発することが望ましいといえます。

こう記述すると大向こうから「分かっちゃいるけど・・・」との声がかかり、「後出しジャンケンだ！」との誹りも受けそうですが、そもそもユーザー企業に “ITの専門家がいない” つまり ”業務内容と小売業基幹システムを繋ぐメンバーが社内にいない” のであれば、依頼するシステムベンダーにユーザー企業の業務と小売業基幹システムに関する豊富な知見を持つ技術員が在籍していることを確認した上で契約し、適時に適切な助言と、適切な対処方法の提示による適切な指導を受けることが必要なのです。