以下の内容はhttps://www.three-wise-monkeys.com/entry/2025/01/22/080000より取得しました。


「崖」のまえでプロジェクトを振り返ります

2018年に経済産業省より「DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~」が展開されました。タイトルの「崖」という強い表現が印象的です。「崖」でなく「壁」なら、まあよくある表現かと思うのですが「崖」にしたことで、企業がDX化を本気で取り組まねばならないことがよく伝わる内容になってました。


~「DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~(経済産業省)」より

そして「2025年の崖」は、もう来てます。

このレポート、前のブログで書いたのですが、全体を端的に表現すると「2000年代に導入したSAPシステムを見直し、クラウド、モバイル、AI技術をマイクロサービス、アジャイル開発で置き換えましょう。」と書いてます。

www.three-wise-monkeys.com

わたしは2000年から約7年間、参画した主要なプロジェクトは、SAPシステムの導入現場でした。SAPとは、ドイツに本社を置くソフトウェア会社のSAP社が提供しているERPパッケージ製品です。当時、大企業の多くがSAPの導入をしたことから、SAPはERPパッケージをリリースしているITベンダーの代表格として認識されています。

社会的に注目されたプロジェクトもありました。ドキュメンタリーを制作するため、テレビの取材班が来たこともあります。

あの頃は「働き方改革」なんてものはありません。月300時間働いた記憶もあります。22時に退社しようとしたら、同僚から「今日は早いね~」と、言われる現場でした。

SAPシステムの導入プロジェクトは、業務要件をシステムで実現したい利用者と、パッケージの標準機能を使わせたいコンサルタントがこんな感じで夜な夜な議論しました。

(利用者)仕入先に対して有償支給している部品のケースはどう定義するんですか?

(コンサルタント)無償支給に出来ないのですか?その方が、会計処理もシンプルになります。

利用者が求める業務要件と、SAP標準機能のGAPとなった部分は、アドオンと呼ばれる開発仕様書が作成されました。SAPシステムのアドオンとは、標準機能にない顧客独自の要望に合わせた機能を開発することです。アドオンは主に「ABAP」というSAP独自の言語を使用してプログラム作成を行います。アドオンの多くは帳票系の「レポートプログラム」です。ほかに画面を作成する「Dynpro(ディンプロ)」と呼ばれるものもあります。

ABAPの開発をするエンジニアは、ABAPer(アバッパー)と呼ばれます。これはSAPのコンサルタントとは別なスキルを必要とします。

「2025年の崖」のレポートで指摘されている企業システムの問題点は、SAPのアドオンです。SAPを短期的な観点でシステム導入し、結果として、長期的に保守費や、運用費が高騰している状態を問題視しています。ERPパッケージの標準にない機能を安易にアドオンしたことで、結果として保守性の悪いシステムを企業は使い続けているのです。

あの頃、SAPの導入現場にいた者として、このレポートで指摘していることは、非常に理解できます。

ただ、結果から問題点を指摘するだけでは、その原因にたどり着くことは出来ません。SAPシステムの利用企業が、パッケージの標準機能を適用しなかった原因を振り返る必要があると思います。

あのとき、わたしが強く感じたのは、SAPのコンサルタントの多くは、利用者の業務を理解してないことです。SAPのコンサルタントは「会計(FI/CO)」や「購買(MM)」といった、モジュールと呼ばれる業務分野毎に分けられてます。彼らが知っているのは、SAPの標準機能です。コンサルタントは、それを「ソリューション」と呼んでたのですが、業務そのものを理解してないので、言葉に説得力がありませんでした。

これは、料理に例えると、調理経験のないコンサルタントが、頭で覚えたマニュアル上のレシピを料理人に伝えてるイメージです。

かなり奇異に感じる状況です。コンサルタントが利用者を納得させて、SAP標準機能を適用できなかったのは、そもそも現場の業務を知らないで、コンサルティングをしているからです。

一方、コンサルタントも自らが提案するソリューションをシステムの利用者に適用させることに、特別な信念はなかったと思います。

なぜなら、彼らはSAPの導入ベンダーの立場でプロジェクトに参画してます。ベンダーにとって、アドオン開発することは、受託開発の売上を獲得することです。アドオン開発を見込んで、ABAPerも確保してます。さらに、アドオンが発生すれば、システム稼働後の保守を確約することにつながります。

アドオンの数が膨大になりすぎると、開発者のリソースが足りなくなってしまいますが、適度!?なアドオンはベンダーとしてありがたい仕事です。

手慣れたSAPのコンサルタントは、利用者の要件を聞きながら、

(コンサルタント)まあ、その部分は「標準アドオン」ですね。

と、相槌をうつことも多々ありました。

こうして、多数のアドオンがある保守性の悪いシステムが大企業に導入されていきました。

当時といまを比較しても、システムを導入する現場の状況は何も変わってないようにみえます。

DX化を提唱するコンサルタントは、現場の業務への理解は相変わらず薄く、絵に描いた理想論を掲げているように見えます。システムの利用企業は、頼りにならない自社の社内システム部門より信頼できる、ITベンダーに開発や保守を依存してます。

正直、そのなかで、クラウド、モバイル、AI、マイクロサービス、アジャイル開発・・・というITのトレンドを担いでシステムを刷新しても、本来の目的であるはずのDX化による経済効果が期待できるとは思えないのです。




以上の内容はhttps://www.three-wise-monkeys.com/entry/2025/01/22/080000より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14