アドオンは技術的負債なのか？アドオン開発の未来を考える
INDEX LINK
はじめに
日本のSAP ERP業界はアドオン開発主体の導入が一般的でした。
近年はFit to Standardのお題目のもとに標準状態での導入も増えてきましたが、まだまだアドオン開発の需要は旺盛です。
しかし、ここにきて「アドオンは技術的負債である」という見方も出ています。
果たして本当にアドオン開発は負債なのでしょうか。
今回はアドオン開発の未来を考えてみたいと思います。
1.なぜアドオンは技術的負債とみなされるのか
経済産業省が2018年9月に公開した「DXレポート」において、「2025年の崖」の原因とされたレガシーシステム。
このレガシーシステムには、アドオン開発が多用された旧来のモノシリック型ERP、つまり「ERPレガシー」が含まれています。
アドオン開発×モノシリック型ERPは非常に親和性が高く、これまで多数の日本企業がこのERPレガシーに依存してきました。
しかし、その結果、以下のような事象が散見されるようになりました。
1-1.モノシリックといいつつ一貫性がない
まず問題とされるのが一貫性のなさです。
モノシリック型ゆえにアーキテクチャを変更せず、業務も変更しないという矛盾を抱えたまま開発が続けられ、「20～30年以上前に構築された古いシステムつぎはぎだらけ」のまま放置されている例が多くみられます。
放置といっても2年に1度程度は軽微な改修が加えられるのですが、そのたびに影響調査の工数がかさみ、「どんな軽微な改修であっても時間とお金がかかる」という状態に。
また、プロジェクトが立ち上がるたびに担当者が入れ替わり、「あるべき姿」がはっきりしないままアドオン開発が続けられた結果、機能間の整合性が取れていないこともあります。
こうしたシステムはもはや「今」だけを支える自転車操業のような存在で、将来性を見出すことが難しいのではないでしょうか。
1-2.仕様書や設計書が残っていない（欠けている）
こちらもアドオン開発を乱発したことで起こりやすい事象です。
比較的大きな改修についてはドキュメントが残っているものの、小規模なものについては何かが欠けていることがあります。
改修や追加開発案件は、「要件定義書」「仕様書」「設計書」がひとつなぎになっていなければ、後任の人材に意図が伝わりません。
よくあるのが「要件定義がなく、急に設計書だけが出てくる」というケース。
要は要件定義フェーズをカットして工期を短縮しているのですが、アドオン開発の「目的・背景」が一切わからないので後任者は混乱します。
とはいえ、何らかの対策をせざるを得ないわけで、設計書から意図を読み取って半ば無理やり開発するわけです。
これが何度か繰り返されると、「目的・拝啓」が朧気なまま機能が数珠つなぎになっていき、数年後に「負債」とみなされるケースがよくあります。
1-3.コードが長すぎて整備性が悪い
モノシリック型のシステムでは、モジュールや機能ごとに分割・独立した仕様ではないため、異様にコードが長いことがあります。
数十万ステップから数百万ステップ、時には数千万ステップといった規模になるため、何をするにも労力が必要です。
たった数十行のコードを追加するために、数日間の影響調査とテストを繰り返す、という生産性のない仕事をしなくてはなりません。
あたかも雪だるま式に膨れ上がった負債のように、「常に利子（労力）が必要」なのです。
例えば以下のようなパターン。
・数千万ステップのコードを解析すると、あとから一部だけを改変したと思える部分が複数あった。
汎用モジュールの再利用ではなく、独自のコードを追加しているが、設計書上は同じ処理をやっていることになっている。
・もともとは構造化プログラミングでしっかり作られたアドオンプログラムであるが、影響調査をやらないままに手を入れたためにかなり複雑なルーチンが追加されている。
また、多層構造のループ処理も多く、設計書を見ても何をしているのかよくわからない。
・グローバル変数やローカル変数の命名規則に一貫性がなく、設計書上は同じ処理をやっているにもかかわらず使用されている変数が異なる。
こういうパターンのアドオンプログラムは解析に時間がかかるだけではなく、設計書のメンテナンスにも労力を要します。
何しろ過去の担当者はすでにいないわけですから、関係各所から情報を集めて設計書をメンテナンスしなくてはなりません。まさに負債ですね。
2.アドオンプログラムの「技術的負債」から脱却するには？
正直なところ「設計書に従って、シンプルかつ素直に作り直す」のが最適解だと思います。
しかし、費用や工期の関係上、こういった対策は見送られることがほとんど。
また、ECC6.0までのいわゆる「ERPレガシー」は、パッケージのバージョンアップに合わせて大規模なプロジェクトが立ち上がることが多く、「負債」はそのタイミングでしか解消できない可能性が高いわけです。
2-1.いっそのこと「クリーンコア」に乗っかるのもあり
SAP ERP界隈の人間であれば「クリーンコア」という用語を聞いたことがあるかもしれません。
「クリーンコア」とはSAPが近年提唱している戦略のひとつです。
ERPのコア機能を可能な限りカスタマイズせず、SAPが提供する標準機能を最大限に活用する方法論のことを指します。
Fit to Standardとほぼ同じことを言っているように聞こえますが、そのあたりは用語の定義の違いなのかもしれません。
SAPによれば「クリーンコアは、標準データモデルを活用し、オープンAPIの標準化を図ることで、SAPのERPをクラウド上で最適化する」とのこと。
「コスト効率の良いERP基盤を基にして、拡張や差別化を構築し、メンテナンスやオペレーションの複雑性を解消する」との説明もありました。
つまりは、最初から「アドオン開発による技術的負債」を残さないように配慮した方法論と言えるでしょう。
解析が不可能なほどに入り組んだコードを無理に再利用するよりは、クリーンコア戦略に乗ってシステムを一新する方法が経済的かもしれません。
まとめ
今回は、アドオン開発の技術的負債について解説しました。
「すべてを新しくする」ことが正しいとは限りません。
しかし、ERPレガシーは企業の重要な業務・ノウハウが詰め込まれたものであり、不具合によるリスクは極めて高いわけです。
したがって、中途半端にメンテナンスを続けるよりも、クリーンコアやFit to Standardに準拠した刷新が良いような気がします。
実際に最近のプロジェクトは「DX」のお題目のもとに過去の業務ノウハウ（つまりERPレガシーに残されたコード）を破棄する流れもあります。
SAP ERP導入を進める人材側としては、クライアントに対して技術的負債のリスクをうまく説明できるようにしておきたいですね。
経験の面から言っても、「レガシーをメンテナンスする」ことより「クリーンな状態で新規導入する」ことのほうが蓄積は多いと思います。
