PowerBuilder で開発したソフトウエア資産の本来の価値

「オープンシステムは、どんなに素晴らしいシステムでも 10 年以上使い続けられない」

こう述べる方々は、「ビジネスとしてハードウエアメーカーもデータベースや Windows OS のバージョンアップを行い機能強化するため、古いソフトウエアが動かなくなる、それぞれのメーカー保証期間が有限だからである」と言います。また、そうしたメーカー都合に不満を持つ人々は非常に多いが、これは仕方のないことだとも言います。

だからと言って果たして「ホントにそうでしょうか?」。

確かに、ハードウエアはより高性能になり、同一スペック比較だと新しいモノの方が飛躍的に性能強化されているのが自然です。サーバー製品然り、クライアント PC やその他のデバイス機器も同じくです。

実際、PowerBuilder のような統合開発環境(IDE)は、そうしたハード・データベース・クライアント OS のバージョンアップに多少の時間差はあれど継続的に対応できるようバージョンアップしています。

Windows XP 時代に開発したプログラムをマイグレーションして Windows 10 OS 上で動作させているお客様が現実たくさんおられます。

つまり、冒頭の内容の意味は、「そのまま何もしないならば…」というコトを付記すれば納得できるでしょう。

資産価値1

一方で、この「10 年」という期間は、概ね世の中一般的には家電製品などの保証期間の上限的な認識があります。また、これは耐久年数とは違います。エアコンなどは 10 年経つと指定業者クリーニング対象から外れます。つまり、部品が破損しても交換部品が入手できないので責任を持ってクリーニング出来ませんよ…との意味ですね。

このような耐久消費財も概ね 10 年を一つの区切りとして保証期間を設定していることを考えますと、製造装置や自動車など同じくソフトウエア資産の価値は、「10 年以上も社会変化に対応し続けながら使えること自体、素晴らしい!」とそのソフトウエア資産の価値を再認識すべきではないでしょうか?


「マイグレーションしても、付加価値が上がるわけではない」

確かに、既存システムを最新環境に合わせるためにマイグレーションを行いますが、作業と同時に機能追加やアドオン開発せねば、そのソフトウエア資産の価値は変わらないとの見解…一見、納得します。

しかし、新しい環境下で既存システムが、エラーが頻発して実際に使えない状態=価値 0 になった場合、その逸失された価値はどれくらいなのでしょう?明らかにマイグレーションコストより損失する金額が高いものになります。例えば PowerBuilder で開発した既存システムを同じ機能やシステム範囲で他の言語や開発環境で新しく作り替えるならば、恐らく仕様書がシッカリと存在したとしても開発当時のコストを遥かに上回ることでしょう。人件費も消費者物価指数も確実に UP していますから…。社内にも担当しているベンダーにも PowerBuilder が扱えるエンジニアがいないんだ…となれば、マイグレーションが出来る PowerBuilder ベンダーに依頼すれば良いことです。

資産価値2

また、PowerBuilder の教育に多大なコストが…との心配ゴトもありますが、現在、Java や C# が出来るエンジニアであれば凡そ多くのコストは発生しません。既存の仕様を凍結してマイグレーションだけ完了するのであれば、潜在的な不具合(バグ)以外であれば対応は出来るものです。(システムの仕様を理解できている前提ですが…)その上、実際に PowerBuilder で開発したソフトウエアのマイグレーションで大半のコスト(工数)は、「現新比較」のテスト工数なのです。これは、テスト方法を色々と工夫して利用部門と協力して分散させることも出来ます。

確かにソフトウエア資産は、工業的生産物のような画一的なモノではなく、どちらかと言えば職人芸的なオンリーワンのモノに近い存在です。しかし、それはどの言語で開発しても同じです。大切なことは、ソフトウエア資産を価値あるものと判断したら、その価値を出来る限り長く維持・成長するためにはどうするのが最善か?と考え、十分に備えをしておくことが重要だと考えます。


「PowerBuilder のソフトウエア資産」の経済的価値の算定は?

実際に現在も稼働しているソフトウエア資産、5 年以上前に開発して減価償却もとっくに終わっているのだから、会計処理上は限りなく「0 円」…?では、ありませんよね。むしろ、経済的価値は UP しているのではないでしょうか?つまりは、業務に必要=「必需品」であり「便利品」ではないからです。

しかし「客観的なソフトウエア資産の価値を算定なんて…どうやって?」と頭を悩ます方々も多いと思いますが、そもそも既存ソフトウエア資産の経済的価値を算定する目的とは?に立ち戻れば、社内システムに限って言えば、いくらでも算定基準が作れます。なぜならば、対象となるソフトウエア資産を開発する当時に、キャッシュアウトしたのは明らかに自社なのです。極論すれば外部指標の類の調査も必要はありません。

資産価値3

そのソフトウエア資産に払った金額がすなわち出発点と捉えれば良いのです。後は、「ソフトウエア資産の経済的価値の社内算定基準」を全社で一旦、決めて他のソフトウエア資産もその基準で算定すればいかがでしょうか?もちろん、経年の運用上で変更は生じるものですが決めるのは自社です。もちろん、この評価の時に同業他社との比較観の必要性もあるので、参考にすれば良いと思います。

図のように、「ソフトウエア資産の経済的価値」を純顧客価値すなわちソフトウエアを活用して得られる価値ですが、派生的な価値の判断もやはり自社独自の基準が必要になりますね。もっと簡単に…??

 

例えば、基幹システム(販購買・物流システム)で考えれば、時代が変われども当時このシステム導入の大きな目的は、①売上高を如何に上げるか?②コスト(仕入・経費など)を如何に抑えるのか?であったはずです。であれば、このシステムの本稼働時期での①や②が当時、どれだけだったか?そして、毎年のこの基幹システムを使って活動した結果、①や②がどう変化したのか?単純に「初年度導入費(あるいは減価償却費)+その関連経費など諸々の年間コスト合計」を「初年度の①や②の年間合計」で割った数値(%)を基準として、売上高増加分やコスト圧縮分の基準%分は「ソフトウエア資産の経済的価値」とみなす…とするのも一つです。また、既存ソフトウエア資産と全く同じシステムを現在のテクノロジー(開発言語や環境)で開発したとしたらいくらになるか…?「計算された見積算定金額=既存ソフトウエア資産の現在の経済的価値」としてみなす…でも構いません。恐らく、マイグレーションコストとは比較にならないほどの高額になると推察されます。要は、予めそうした社内算定基準をルール化するだけで毎年のモニタリングにもなるはずです。もちろん、削減された人件費(労務費)や業務改善によって生み出された余剰戦力を新たな業務や取引拡大に…も必要だったりしますが複雑になり過ぎることは回避したいものです。最終的にはソフトウエア資産の経済的価値を求める目的は、経営判断に必要だからです。意思決定するのは自社であり経営陣に説明する立場ならば、経営判断の重要な指標として必要なものではないでしょうか?一方で、「ソフトウエア資産の経済的損失」の尺度も必要です。ビジネスモデルが大きく変わりシステムが合わなくなる、開発者も居ない、OS や DB のバージョンも古い…使い続ける上でのリスクが大きいので、このリスクを回避し、現在および将来に亘って成長を支援するシステムに投資するべき時が来た…があります。その時は、既存ソフトウエア資産の経済的価値ではなく、経済的損失があるとの判断と考えます。DX 時代には、IT システム投資は色々な業務や分野で必要になります。しかも、変化のスピードも速く投資 & 回収判断も必然的に早さを求められる。「数ある社内システムのソフトウエア資産としての経済的価値・損失」という指標をこうした状況での意思決定の判断材料としても自社の間尺にあったオリジナルな算定基準として創る時期に来ているのではないでしょうか?PowerBuilder は、他のクラウドシステムとのシームレスな連携ができる API を用意しています。そうした機能も考慮しつつソフトウエア資産の本来の価値を考え、長く活用して欲しいものです。

特別記事 一覧を見る
PowerBuilder マイグレーション
PowerBuilder学習、動画で始めちゃう?