江崎グリコ殿のＳＡＰ切り替えトラブル（在庫が合わないので出荷できない）は原因不明のままに続いています。パッケージのバグが原因とは思えないので一体何が起きているのでしょうか？
ところで、このトラブルの背景に「2025年の崖」があるという指摘があります。「2025年の崖」というのは経済産業省が2018年に発表した「ＤＸレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～」にでてきた言葉です。ＤＸレポートでは「日本にはCOBOLベースのレガシーシステムがたくさん残っているので2025年までにシステム刷新を集中的に推進する必要がある」と紹介されています。
労働基準法改正が原因となっている2024年問題とは違い、なぜ2025年までなのかははっきりしません。2025年に関する記述として出てくるのは、ＳＡＰ社のＥＲＰの旧バージョンが2025年にサポート停止されるということくらいです（その後ＳＡＰ社のサポート停止は2027年以降に延長されました）。オープン系新システムの代表といえるＥＲＰのサポート停止問題が、レガシーシステムを使い続けているリスクとどう関連するのかはよくわかりません。2025年の崖にはこの矛盾があったのでその後忘れられていたのですが、江崎グリコ問題で唐突に浮上してきました。
2025年はさておき、ＤＸレポートが指摘したオープン系ソフトのサポート停止問題（レガシーではないことに注意）は日本の企業経営に大きな影響を与えています。ＳＡＰ社の新バージョンＥＲＰ（Ｓ／４ＨＡＮＡ）への置き換えだけではなく、国産のＥＲＰパッケージでもサポート停止問題が直撃しています。ベンダから多大な移行工数発生と億単位のバージョンアップ（移行）費用を請求されて困っている企業が続出しています。理不尽な多額請求に不満を持ってベンダ変更を模索する企業もでてきています。上場企業で定番化しつつあったＳＡＰの財務会計でさえ日本製の安い財務会計パッケージにダウンサイジング検討する企業もいます。
旧システムのサポート切れ対策に追われてＤＸなどの新ＩＴ技術を活用したビジネス展開どころではないという企業もいます。オープン系システムのサポート停止問題が日本の経済成長の足かせとなっているといっても過言ではありません。こんなことなら自社で個別開発したレガシーシステムを使い続けていた方がよかったと後悔するケースも多いようです。
オープン系ソフトのサポート切れ問題が厄介なのは、今回だけ対応すればいいということではないことです。業務システムの大幅な機能追加を必要としなくても、ベースとなっているＯＳやデータベースソフトの改修に伴うバージョンアップは引き続き起こることが予想されます。そのたびに数千万円や億単位のバージョンアップ費用と移行工数が発生していてはたまりません。企業としては何らかの対策を講じる必要があります。
どんな対策が考えられるか
- システム仕様を整理しておく
バージョンアップ費用がベンダ任せになってしまう背景には、ユーザ企業がシステム仕様をよく理解していないことがあります。この状態だとバージョンアップの影響分析やテストがベンダの言いなりになるのは避けられません。ローコード開発ツールによる開発の場合は、システム内のリポジトリを使うことで最新仕様を管理することができますが、パッケージの仕様はブラックボックスなのでどうしてもベンダ任せになりがちです。
こうならないようにするためにカスタマイズ開発したりアドオン開発した部分はもちろんのこと、パッケージの標準機能に関しても自社はどういった機能を使って業務処理をしているのかを整理しておきましょう。自社だけで整理が難しい場合は、当社で整理のお手伝いをすることもできますのでサポート切れが直前に迫っているなどの手遅れ状態にならないうちに一緒になって整理しませんか。
２．ソフト保守内容を確認する
多くのパッケージソフトはソフト保守料を徴収しています。一般的には標準売価の１５％程度の年間費用が発生しますが、この費用で何をしてくれるのかがはっきりしていません。とくにカスタマイズ部分の扱いは曖昧なことが多く、ソフト保守料を払っているのに高額なバージョンアップ代を要求されることもあります。また、パッケージ自体が作り直しになった場合は、ソフト保守料ではなく、新たに購入費用を請求されたりします。
ソフト保守料が保守目的よりもベンダの開発体制維持目的に使われているのは周知ですが、だからといって不透明なままでいいというわけではありません。ソフト保守料に関しては金額だけでなく、サポート内容に関しても十分に確認しておきましょう。今からでも遅くありません。
３．自社開発も考える
最近、自社内や懇意のソフトハウスを使ってシステム開発する企業を中心にパッケージを使わないという選択をする企業が増えています。中小企業では昔からAccess、FileMaker、桐、MagicなどのＤＢ処理ツールを使った個別開発システムが使われていましたが、中堅企業や大企業でも、仕様管理ができるローコード開発ツールを使ってシステム開発するケースが増えています。たとえ利用ツールがサポート停止になっても仕様情報を押さえておけば、別のツールを使った新システムへの移行も比較的容易にできます。パッケージベンダロックインといった事態への対抗もしやすいです。ＥＲＰに現場EXCELが重なった複雑な業務システムに追い込まれている企業の皆様は、ぜひローコード開発ツールの利用を検討してみてください。