ローコード開発が、環境変化に対応しやすく陳腐化しにくい基幹システムを作る：製造業DXが生む3つの価値（4）（1/2 ページ）

製造業でも多くの関心が寄せられている「DX」。本連載では、DX基盤を構築したその先で、具体的に「何が実現できるのか」を紹介する。最終回のテーマは「ビジネス環境への対応」だ。現場ニーズに即しつつ、ソースコードに極力手を加えずに基幹システムの追加機能を開発する上で、「ローコード開発」の意義に注目したい。

[栗田巧／Rootstock Japan，MONOist]

　今回は本連載最後のテーマである「ビジネス環境対応」についてお話しします。

　本題に入る前に、先日行われた世界最大のクラウドアプリケーションプロバイダーであるセールスフォースが開催したイベントのお話をご紹介します。セールスフォースが日本国内で実施したAppExchangのパートナーミーティングです。

　AppExchangeはセールスフォースが提供するビジネスアプリケーションのマーケットプレースです。パートナーミーティングでの話によると、コロナ禍で流動的な状況にある市場環境にもかかわらず、AppExchange関連の売り上げは前年比でかなりの成長を記録したようです。

　ミーティングでは、Salesforce Platformで運用する営業支援システム、決済代行サービスなど、国内パートナー3社による事例紹介も行われました。残念ながら、製造業に直結する内容ではありませんでしたが、クラウドアプリケーションが多くの産業分野や地方自治体のDX（デジタルトランスフォーメーション）基盤に欠かせない、ある意味で「標準仕様」の要素と見なされ採用されている現状を、改めて強く実感する機会でした。

　これまでの連載でお伝えした通り、海外ではオンプレミスなアプリケーションからクラウドアプリケーションへのシフトが産業界で急速に進んでいます。製造業も同様の傾向です。DXという言葉を方々で耳にするようになって久しいですが、こうした流行が終わらぬうちに、国内の製造業、ならびに製造業向けソリューションベンダーはクラウドアプリケーション採用に向けた取り組みを加速させる必要があるようにも感じます。

ソースコードの変更、追記が生む2つのデメリット

　さて、ここからが本題です。ビジネス環境は常に変化していますが、コロナ禍を経てそのスピードはさらに早くなっていくことは想像に難くありません。こうした環境下で今後、市場における自社の優位性を保ち、顧客満足度を高め、業務効率のさらなる向上を図っていくには、どうすれば良いのでしょうか。

　その答えは、「ビジネス環境の変化に順応して、自らも変化していく業務システム」の構築にあります。

　前段として、「従来のシステム像」について、基幹系システムを例にとって考察してみましょう。基幹システム導入プロジェクトが立ち上がると、まずは要件定義フェーズに入ります。要件定義からフィット＆ギャップ分析、ギャップ判定と進みますが、国内のシステム開発ではこの後、「現場の意見を尊重する」という大義名分のもと、現場の要望に合わせた一定規模の追加開発が実施されることが通例となっています。

　従来のオンプレミス製品の場合、追加機能の開発はプログラミング言語によるコーディングが一般的です。ソースコードを変更、追記することで、機能の変更や追加を実現します。

　こうした手法を全面否定するつもりはありませんが、少なくとも2つの大きな短所が指摘できるでしょう。

（1）追加開発の結果、ユニークなソースコードが出来上がってしまい、その後のシステムバージョンアップが難しくなりかねない。また、バージョンアップができないため、その後発生する要件全てが追加開発対象となり得る（新バージョンの標準機能で対応していたとしても利用不可）。

（2）単一ソースコード内に、オリジナルのコードと追加コードが混在してしまうため、それぞれを区分管理できず、ライセンス保守費用に加えて、追加開発機能も保守対象となるケースがある。追加で開発した機能の保守費用が、ライセンス単体の保守費用を上回るケースも少なくない。

　現実には、（a）ライセンス保守費用を毎年支払っているにもかかわらず、基幹システムのバージョンアップができない、（b）予算制約から追加開発が行えず、結果、システムが対応しない業務要件を増加させてしまう（場合によってはExcel管理が復活する）といった事態が生じている企業もあります。

　つまり、基幹システムが最大のパフォーマンスを発揮できるピークはシステムの本番稼働時点で、その後は経年に伴い陳腐化していくのです。年月が経つにつれ、ビジネス環境の変化に順応できない基幹システムになりかねません。