飯泉 純子　IIZUMI Junko
栗田 洋輔　KURITA Yosuke

本論文は、エンジニアリング・マインド誌Vol.6 特集「続ソフトウェア経済学」に掲載されたものです。

IT不良資産

　会計業務に係るソフトウェア開発やシステム構築を担当している人や、個人事業主としてソフトウェア開発に携わっている人を除いて、ソフトウェア技術者の多くは企業会計について詳しく知らないでしょう。しかし、「IT不良資産」という言葉を聞いたことがある人は多いのではないでしょうか。
　IT不良資産とは、開発／購入／構築したソフトウェアやITシステムが利用されなかったり、投資金額に見合う効果がなかったりして、企業会計上は「資産」として扱われているにも係わらず、それほどの価値がないと判断されるものです。では、この「企業会計上の『資産』」とは一体なんなのでしょうか。
　この論文では、企業会計の視点からのソフトウェアの価値評価や、会計や財務の分析手法を利用したソフトウェア開発方法の意思決定のためのツール（道具）について説明します。

財務会計と管理会計

　企業は通常、営利を目的として営業活動を行っています。営業活動には、資金を提供する株主、資金を融資する銀行、取引先、経営者や従業員といった、さまざまな利害関係者がいます。これらの利害関係者に対し、営業活動の正当性を説明したり、財務状況を開示したりする必要があります。また、税務署は公正な税の徴収を行うために会計情報を必要とします。
　財務会計は、企業外部の利害関係者に対して会計情報を提供することを目的とします。一方、管理会計は、企業内部の経営者や管理者などに対して、経営や管理に役立つ会計情報を提供することを目的とします。

貸借対照表と損益計算書

　貸借対照表（Balance Sheet: B/S）とは、企業のある時点における財務状況を表すものであり、「資産」「負債」「純資産」で構成されます（図1）。「資産」は企業が所有する財産を示します。「負債」は銀行などから借り入れて調達した資金や債権者に支払う義務がある債務を示します。「純資産」は「資産」から「負債」を差し引いた企業の正味の財産です。
　損益計算書（Profit and Loss Statement: P/L）とは、企業が営業活動を行った一定期間における経営成績を表すものであり、「費用」「利益」「収益」で構成されます（図2）。「費用」は営業活動におけるその期間の経費を示します。「収益」は営業活動の結果得られたその期間の収入を示します。「利益」は「収益」から「費用」を差し引いたその期間の損益を示します。

　　　　　
図１　貸借対照表の構成　　　　　　　　図２　損益計算書の構成

制度会計とソフトウェア会計基準

　制度会計は、財務会計を法的な制度面からサポートする規則です。前述したとおり、財務会計は、企業の外部の利害関係者に対して会計情報を提供することを目的としています。その方法が企業毎に異なっていたら、提供された会計情報を理解したり、他の企業と比較したりすることが難しくなります。制度会計によって、このような状況を防いでいます。
　ソフトウェア会計基準とは、ソフトウェアの開発にかかった費用を会計処理する際の基準の通称です。大蔵省（現在の金融庁）の諮問機関である企業会計審議会が、1998年3月に取り決めた「研究開発費等に係る会計基準」の中で、研究開発費に関する基準と合わせて示しました。

図３　減価償却における資産と費用の関係

　ソフトウェア会計基準では、ソフトウェアの開発にかかった費用のうち、どの部分が会計上の「資産（無形固定資産）」として扱われ、どの部分が「費用」となるかの基準を明示しています。「資産」扱いの開発費は貸借対照表に記載され、原則5年以内に定額法で減価償却します（毎年同じ額を資産から差し引く、図３）。一方、「費用」としては、支出した会計年度に経費として処理します。

　ソフトウェアの種類とその会計処理は表１のようになります。

表１　ソフトウェアの種類と会計処理

* 請負工事の会計処理：工事完成基準により、完成品までは仕掛品で資産計上し、完成後、売上計上時に売上原価の費用処理とする。

減価償却を用いた評価方法

　企業会計上のソフトウェアの価値を評価するとき、財務会計では必然的にソフトウェア会計基準に従うことになりますが、管理会計の場合もこれに従うべきでしょうか。つまり、ソフトウェア開発を費用とみなしたり、ソフトウェアを毎年価値が同額ずつ減っていく資産とみなすべきでしょうか。
　場合によってはそのような解釈が適切なこともあるかもしれませんが、特に自社利用のソフトウェアの場合は、以下の理由から減価償却を用いて評価するのは一般的には適切ではないと思われます。

• ソフトウェアはそもそも機械のような消耗品ではないので、使用年数が長くなることで価値が減るものではない。
• ビジネスプロセスが改善され、ソフトウェアが有効利用されるようになったケースでは、ソフトウェアの価値は増大していると考えるのが適切である。
• 会計上の償却が完了した後でも、保守・運用のためのランニングコストがかかる。

取得価額と再取得価額による評価

　では、管理会計ではソフトウェアをどのように評価するのが適切なのでしょうか。まずは資産価値の評価から考えます。
　財務会計では初期開発にかかった価額（取得価額）が資産価値になり、それが原則的には毎年一定額、減額するようになっています。これは前述のとおり、経営管理に役立つ真の資産価値を算出するには適切ではありません。
　それでは、同等のものを再開発したり市場価格で調達したりする場合にかかる価額（再取得価額）で評価するのはどうでしょうか。こちらの評価法の方が時価を反映できるという点では優れています。しかし、これも以下の理由から望ましくありません。

• 再開発にかかるコストをわざわざ試算しなければならない。
• 再開発コストの精緻な試算をしたとしても、管理会計の目的である経営管理にはあまり役に立たない。
• 自社にとっては価値がある（収益を生み出したり、経費を削減したりする）が、他社にとっては同等の価値があると判断できない場合、市場で価格付けできない。
• そもそも管理会計では、自社だけで使用するソフトウェアを市場価格で一律に評価する必要はない。

　特に３つめの理由は、市場で価格付けできない資産の本質と深くつながっています。市場において、ある価格で資産を売ることができるならば、その資産は最低でもその価格分の価値があるとみなすことができます。しかし、市場で価格付けできない資産は、オープンな基準で価値を決めることができません。

DCF法を用いた評価方法

　では、どうしたら自社利用ソフトウェアの価値を計算できるのでしょうか。それは、市場価格に基づいて価値を計算するのではなく、自社の基準で（ある意味勝手に）価値を計算するのです。自社内で経営管理に使う基準なので客観的に正確である必要はありません。要は「使える基準」であればよいのです。
　経営管理に使う基準ということは、ソフトウェアの資産価額を開発時における価額とは切り離して、ソフトウェアを運用することで得られるキャッシュフローから評価することは望ましいでしょう。具体的には、ソフトウェアの運用により直接的・間接的に得られるキャッシュを予想し、DCF法1にてキャッシュの（効果と費用を調整済みの）総和を求め、それをソフトウェアの資産価値とします。
　ただし、この方法はまだ一面的な評価しかしていないことに留意する必要があります。ソフトウェアは保守・運用にランニングコストを要するので、負債として解釈すべき面もあるのです。具体的には、ソフトウェアの負債としての部分はランニングコストを予想し、DCF法にて総和を求めます。これがソフトウェアの負債価額となります。
　貸借対照表では常に「資産 ＝ 負債 + 純資産」の関係が成立することから、資産価額から負債価額を差し引けば純資産価額が求められます。これがソフトウェアの真の価値です。
　この評価方法の特徴は、ソフトウェアの価値を開発にかかったコストとは無関係に、将来生み出す利益とランニングコストを元に評価するという点です。ソフトウェアの場合、投資を行う際には採算性について分析が行われるが、一度投資をしてしまえば、その後は評価が行われずに放置されてしまう例が多いようです。既存のソフトウェアがどのように使われ、どのような貢献をしているのか、また、どれほどのランニングコストがかかるのかを分析することは、業務を改善する際にも新規のソフトウェア投資を行う際にも重要な判断材料となります。そのためにも、自社で使用しているソフトウェアについて定期的に貸借対照表を作成してチェックを行ってはいかがでしょうか。
　例えば、既存のソフトウェアに対してリファクタリングを行うかどうかを判断する場合を考えてみましょう。リファクタリングを行うと、それ以降のソフトウェアの保守にかかる費用を削減することができます。これはソフトウェアの負債価額を減らすことに相当するので、図４のように貸借対照表は変化します。負債が減ることによってソフトウェアの真の価値（純資産）が増加しています。

図４　リファクタリングによる貸借対照表の変化

　ソフトウェアのこのような価値評価は、ソフトウェアを開発する企業だけでなく、ソフトウェアを保有・運用するすべての企業にとって有効です。つまり、いわゆるユーザー企業にとっても、その企業が保有・運用するソフトウェアの負債を減らし、価値を高めるための投資判断の材料として利用することができます。開発企業はこのような評価を踏まえた上で、ユーザー企業への提案をすることが求められるようになることが考えられます。

パッケージ・ソフトの損益分岐点分析

　損益分岐点分析は、さまざまな場面で利用できる便利な分析ツール（道具）です。ここでは、パッケージ・ソフト（市場販売を目的とするソフトウェア）を例にして損益分岐点分析について説明します。
　パッケージ・ソフトの場合、売上高は売れたパッケージの本数に比例します。また、パッケージの開発と、配布・導入に費用がかかります。図５では、開発費には売上とは関係なく一定のコスト（固定費）がかかり、配布・導入には売上に比例したコスト（変動費）がかかると仮定したときの総コストを示しています。売上高の線と総コストの線がクロスしたところで、売上高が総コストを上回り、利益が出ます。このポイントが損益分岐点です。

図５　パッケージソフトの損益分岐点分析図

　パッケージ・ソフトの開発について意思決定を行う場合、このように損益分岐点分析を行い、予想される売上本数が損益分岐点における本数（利益が得られる最低本数）よりも大きいかどうかで判断を下します。
受託開発の損益分岐点分析
　損益の「見える化」という意味でも損益分岐点分析は有用であり、特に製品を大量生産する場合によく使われますが、適用対象はそれだけには限りません。損益分岐点分析はスケールメリットが有効な分野ではどこでも有効であると考えられます。

図６　特定分野の受託開発の損益分岐点分析図

　それでは、EC（電子商取引）サイトの受託開発を専門に行うベンダーを例にして考えてみましょう（図６）。通常、受託プロジェクトが増えれば増えるほど、売上高は伸びますが、開発にかかるコストも増加します（図６の破線：毎回全開発の開発費）。
　このベンダーの場合、ポイントとなるのは、プロジェクト間に共通する部分が多いことです。発注したクライアントによってバックエンドは全く異なるかもしれませんが、ECサイトを新規構築するのであればフロントエンドの部分で同一のソフトウェア（例えばWebアプリケーションフレームワーク）、同一のプログラミング言語、同一の開発環境、同一の人材、同一の開発プロセスを利用できる可能性が高くなります。したがって、このような共通部分をうまく利用することによって、スケールメリットが生じるのです。

　図６の点線（高効率な開発費）は、初めのプロジェクトを開始する前に、ある程度のコストをかけてECサイトのフロントエンドの効率的な開発方法を考え、実際の開発時には開発体制を整え、それが成功した場合です。初めは効率的な開発方法を探るためにコストがかかっているので、損失が発生していますが、プロジェクト数が増えると売上高がそれまでのコストを上回り、利益を生み出せるようになります（損益分岐点１）。また、さらにプロジェクト数が増えれば、開発方法を洗練しなかった場合よりも総コストが減り、初めにコストをかけたことがデメリットからメリットになります（損益分岐点２）。
　ここで面白いのは、非常に効率的で洗練された開発方法・開発体制を構築しても、それがメリットとなるのはプロジェクト数次第ということです。苦労して非常に洗練された開発体制を構築しても、プロジェクト数が少なければ、その構築にかかったコストが無駄となってしまうかもしれません。その意味で、ベンダーにとっては、現在のプロジェクトだけでなく、将来のプロジェクトを見据えることが重要となるのです。

損益分岐点分析のその他の活用

　近年、アジャイルプロセスが話題になっていますが、この損益分岐点分析は、アジャイルプロセスを誤った方法で適用すると全体最適ではなく部分最適になってしまうことを示しています。アジャイルプロセスではソフトウェアの拡張性・汎用性・再利用性よりも最短時間・最小コスト・最小リスクで開発することを重視しています。しかし、とにかく手っ取り早くシステムを構築すればよいというのは誤った解釈です。ECサイト構築の例では、初めから最小コストで開発することを目指した場合、図の点線ではなく破線の方を選ぶことになり、これは部分最適です。しかし、同じようなECサイト構築プロジェクトの数が増えた場合は、点線を選んだ方が総コストを抑えることができるため、全体最適に近づくでしょう。
　もちろん実際はこの図のように単純ではありません。それに、同じようなプロジェクトを複数回経験する過程の中で、特別なコストをかけなくても効率的な開発方法を発見できると考える方がむしろ自然かもしれません。しかし、ソフトウェア開発においてスケールメリットが効く部分を探り、そのような部分があれば、有効な投資を行うことを積極的に考えてみる価値はあるでしょう。
　その他の投資判断に対しても損益分岐点分析は有効に活用できます。例えば、開発効率向上のために人材教育に投資する場合、保守・運用・拡張のコストを削減するためにリファクタリングを行う場合、業務の効率を上げるためにBPR(Business Process Reengineering)を行う場合などでも、損益分岐点分析を利用することができます。

製造業との比較

　製造業の世界では、大量生産を効率的に行うためにベルトコンベア生産方式が長く用いられてきました。しかし、近年では、テクノロジーの急速な変化や、多種多様なユーザーのための多品種少量生産に対応するために、セル生産方式が用いられる例が増えています。セル生産方式では、ベルトコンベア方式ほどのスケールメリットは得られませんが、ラインの構築・解体のための時間・コストがかからないため、テクノロジーの急速な変化に柔軟に対応できるという長所があります。また、部品のモジュール化が進んでいることも、セル生産方式を促進する一因となっています。状況の変化によって、有効な生産方式が変わってきたのです。
　ところで、現在のソフトウェア業界はどうでしょうか。ソフトウェアのオープン化・モジュール化が進み、様々なベンダー製品あるいはオープンソースのソフトウェアを組み合わせることがごく一般的になってきました。また、情報システムが巨大化・複雑化する中で、ユーザーの要求は昔よりも詳細になっています。ソフトウェア業界も製造業界と似たような状況に置かれているのです。
　このような状況の変化によって、近年はソフトウェア・セル生産方式が話題になっています。製造業と同じようにソフトウェア開発の世界にもセルを持ち込み、変化に対して柔軟に対応しようとするものです。
　前述したECサイト構築の例では、開発の効率化のための初期投資がベルトコンベア生産方式のラインに対応しています。洗練されたラインを構築することで、多くのプロジェクトを効率的に進めることを狙っています。しかし、製造業と同じように、ソフトウェアの世界もテクノロジーの変化が激しくなり、ラインを構築しても、それが稼動する頃にはすぐに時代遅れになるリスクがあるのです。この場合、初期投資は回収されず、無駄な費用となります。また、セルを構築した場合も、ベルトコンベアのラインを構築した場合と比べれば少ないですが、やはり初期投資が必要であることには注意が必要です。

アジャイル・セル生産方式

　このような問題を解決するには、ソフトウェア・セル生産方式の柔軟性とアジャイル開発方式の俊敏性を足し合わせたアジャイル・セル生産方式が有効であると考えています。これは、アジャイル開発方式の部分最適性をなるべく維持しつつも、全体最適も視野に入れようというものです。具体的には、単一のプロジェクトにおいて最短時間・最小コストで開発を進めつつも、開発のノウハウは保存・共有するという手法をとります。再度似たようなプロジェクトを進めることになった場合には、以前のプロジェクトにおいて蓄積されたノウハウを再利用するため、無駄な試行錯誤を省略することができます。また、ノウハウは再利用するだけではなく、磨きをかけたり、新しいものを追加したりという作業も行います。
　この場合の、損益分岐点分析を図示すると図６と同じようになります。点線は開発の効率化のために初期投資を行う場合、破線はアジャイル・セル生産方式の場合です。最初のプロジェクトから最短コストでの開発を目指すので、大規模な初期投資は行いません。そのため、状況が変化しても大きな損失を出すことはありません。ノウハウの再利用により、１プロジェクトあたりのコストを抑え、損益分岐点２に達するプロジェクト数をできるだけ多くすることが目標となります。

　この論文では、技術者には馴染みの薄い企業会計の視点からのソフトウェアの価値評価や、会計や財務の分析手法を利用したソフトウェア開発方法の意思決定のためのツールについて説明しました。今や会計の視点は事務部門の人々のものというだけではなく、エンジニアの常識にしていく時代です。

■