見出し画像

ソフトウェアの減価償却

Takashi Suda / かんた

以前、こんな話をしたんですけど案外ＩＴエンジニアというと、その大半が

　「プログラミングする」
　「システムを構築する」

のが仕事だと考えてしまいます。これは１つに、経営層や管理職層の売上や利益など収支を優先させた自社ビジネスの観点だけを植え付けてしまっていることが理由としてあげられます。まぁもちろん企業としては、重要なKPI、KGIとなりますからそれが悪いとは言わないのですが、それ"しか"伝えようとしないのはいかがなものかと思います。

結果、

　「納品するまでが仕事」

と多くの人が割り切って開発することになります。契約スコープが納品するまで（検収をあげるまで）というだけであって、システム開発を行う上での目線はもっと先を見据えなければ上手くはいかないというのに、企業はそれを正しく教えようとしないのです。

なかには「お客さまのために」「お客さまに寄り添って」などと対外的に宣伝している企業があるかもしれませんが、実際にそのような取り組みになっているかどうかははなはだ疑問です。よほど社内で意識改革を徹底させるような文化が醸成されていなければ、まず「企業」という形態をとっている限りは難しいでしょう。経営層にそこまで深い理解があるのかも疑問です。

画像1

プロジェクトが不採算に終わる理由は、そのほとんどが要件定義などの上流工程にあります。そしてそれは偏にプロジェクトスコープの骨子となる「要件」「仕様」の確定がさせられないまま無理に進めようとするマネジメント不備によるものです。

そしてその真因は

　「顧客目線」「相手目線」で進行しない

マネジメントやエンジニアリング、コミュニケーション（ネゴシエーション）となります。相手に気持ちよく答えを吐き出してもらうスキルが圧倒的に不足しているわけです。

このことも、結局は「お客さまのために」「お客さまに寄り添って」という意識が醸成されていないことによる弊害でテクノロジー、技術力、売上、利益、etc.…といった静的なスキルばかりを重要視しすぎて、顧客志向、コミュニケーション、マネジメントなどが疎かになりがちなことが理由なのかもしれません。

経営層や管理職がそういった取り組みに目を向けない…というのはともかくとしても、ＩＴエンジニアはＩＴエンジニアのプライドがあればこそ、システムとはソフトウェアとは、ハードウェアとはどのような存在なのか、お客さまの立場に立って今一度ただしく理解しておく必要があるのではないでしょうか。

高額なＩＴ資産は「固定資産」

ソフトウェアは一つひとつがとても高価なものです。

私たちが個人的に購入するパッケージ製品であればまだしも、私たちが提供するものは数百万～数億というものもあります。そして、企業の会計には「減価償却」という計算手続きがあります。お客さまを正しく理解したいなら、お客さまの企業運営にかかる法律についても知っておく必要がありますよね。

私は新人の頃、当時の会社には「入社後３年は必ず

　・資産管理委員会
　・ネットワーク委員会　等

のいずれかのワーキンググループに属して活動しなければならない」的な暗黙のルールがあって、その際に資産管理（購入時の資産管理台帳起票、月一の資産確認、年度末の棚卸、減価償却管理、等）を行っていました。そのため新人の時には減価償却の存在や、それにからむ法律やルールを叩きこまれました。

減価償却とは、

　長期間にわたって使用し経年劣化が生じる資産を取得した際に、
　取得に要した費用をその資産の耐用年数の間に分散して
　費用計上する会計処理

を指します。

　・費用を配分し
　・資産を適宜評価し
　・資金回収に貢献する

と言う意味でもとても重要なものなのです。
まぁ、この観点で見れる人はあまりいません。特に「資金回収」については、会計をよく理解していないと分からないでしょう。

とはいえ、耐用年数を客観的に判断することは難しいため、通常は品目ごとに細かく法律で定められた「法定耐用年数」の基準に従うこととなります。自動車や機械など、形のある資産は「有形固定資産」と呼ばれます。 一方でソフトウェアや特許権、商標権などの「無形固定資産」も減価償却の対象になります。

画像2

こんな感じで会社の資産を計上するということです。

画像3

パソコンのソフトウェアが減価償却できるというと、なかなかイメージが湧かないと思います。なぜなら、減価償却と言うと普通は建物や機械、車、パソコンといった形あるものをイメージするからです。

パソコンのソフトウェアは、CD-ROM等を買ってきてダウンロードしたり、ウェブ上で購入してダウンロードしたりするでしょう。また、外注して特別に作ってもらうこともあるでしょう。場合によっては自社で開発することもあるかも知れません。

いずれにしても、ソフトウェア自体には形はありません。
したがって、減価償却と言われてもピンとこないのは無理もありません。

しかし減価償却は、価値が減っていってしまう資産ならば何に対してもあてはまるテクニックです。そのため資産に形があるかないかは関係ありません。ソフトウェアのような形のない資産も減価償却はできます。

ただし、形のあるものと全く同じように扱うことはできず、独特のルールがあります。

パソコンのソフトウェアはそもそも形のないものなので、ハードウェア等と違って物理的な意味で「ポンコツ（老朽化）」になることはありえません。そうだとすればソフトウェアが「ポンコツ」になったかどうかは時代遅れになってしまったかどうかで判断せざるを得ません。

しかしその判断も一筋縄ではいかないでしょう。なぜなら「アップデート」や「バージョンアップ」等がされることもあるからです。

これからソフトウェアの減価償却のルールを説明しますが、そういったことを踏まえて定められていると思ってください。なお、30万円未満のソフトウェアについては、パソコン本体のような形のある資産と同じ扱いがされます。

したがって以下は当初の価値、つまり入手した時の価格が30万円以上の
比較的高額なソフトウェアについての話だということでお読みください。
押さえておいていただきたいポイントは次の３点です。

　・ソフトウェアの当初の資産価値の計算方法は２通り
　・実際に使わなくても入手した時から減価償却の対象になる
　・減価償却の期間は使用目的によって２通り


ソフトウェアの当初の資産価値の計算方法

ソフトウェアを手に入れる方法は大きく分けて２つあります。

「外部の業者等から既製品や外注して制作してもらったものを購入する方法」と、「自社で制作する方法」です。

そして、計算方法は、それぞれ、以下に挙げた金額の合計です。

【購入したソフトウェア】
　・代金の額
　・代金以外で購入時にかかった費用
　・実際に使える状態にするためにかかった諸費用

【自社で制作したソフトウェア】
　・原材料費
　・労務費
　・経費の額
　・実際に使える状態にするためにかかった費用

そして、資産価値の評価額を入手した時から複数年にわたって減価償却費として計上していくことになります。ここでまず一つ、「入手した時から」というのが有形の資産との大きな違いです。


実際に使わなくても入手した時から減価償却の対象

ハードウェアや車、パソコンといった形のある減価償却資産の場合、実際に事業に使わなければ減価償却資産ができません。しかしソフトウェアの場合はそうではありません。

実際に使わなかったとしても入手した時から減価償却の対象になります。

なぜかというと、ソフトウェアは言ってみれば技術に関する情報のカタマリです。そういう情報は実際に使えるかどうかよりも、むしろ持っていることそれ自体の価値の方が大きいと考えます。知識や情報自身に価値があるため、それを自分のものにした時点から、その知識や情報が時代遅れになるまでがその固定資産のライフサイクル…という考え方をされることになります。したがってソフトウェアの減価償却は入手した時から始まります。


減価償却の期間は使用目的次第

ソフトウェアの減価償却の期間、つまり何年かけて減価償却するかについてのルールはそのソフトウェアの使用目的によって違います。具体的には以下の通りになっています。

画像4

なお償却の方法は、それぞれの年度に均等に振り分ける「定額法」が使われます。きちんと法律で定められているんですね。

これらの区別はイメージとしては、自社にとってそのソフトウェアの情報がどの程度重要なのかによって決まります。そしてそれは自社がそのソフトウェアの中の情報の核心を握っているかどうかで分けて考えるのが分かりやすいと思います。

　自社が情報の核の部分を握っているソフトウェアは３年

３年で償却することとされているソフトウェア、つまり「コピーして売るための原本」「研究開発用」のものはいずれもソフトウェアの情報の核心部分を握っているものです。このようなソフトウェアは情報の鮮度が落ちるのが早いのです。

どういうことかというと、まず「コピーして売るための原本」は外に売る商品としてのソフトウェアを作る源となる設備のようなものです。ソフトウェアの技術が日進月歩で進歩しているので３年も経てば時代遅れになり、コピーして売ろうにも売り物にならなくなってしまうだろうということです。

たとえば、年賀状作成ソフトなんかは毎年のようにバージョンが更新されて販売されていますよね？ウィルスセキュリティソフトなども3年ごとに更新されるライセンス販売をされていたりしないでしょうか。

次に、「研究開発用」のものについても研究開発は日進月歩で行われるものです。したがって、３年も経てば時代遅れになって使い物にならなくなるだろうと予想されます。

　自社が情報の核の部分を握っていないソフトウェアは５年

「コピーして売るための原本」「研究開発用」以外のソフトウェアは、自社が情報の中核を握っているとは言えない、という扱いを受けます。したがってその情報の鮮度をそれほど深刻に考える必要がないので、償却期間は５年と長めになっています。５年で資産価値がゼロになるというわけです。

イメージしやすいのは外から購入して自社の業務に使うソフトウェアです。つまり、私たちＩＴ業界の企業から購入するシステム等はここに加わることになります。

これらはソフトウェアの情報の核心を自社で握っているものではありません。利用するだけです。したがって購入先からアップデートやバージョンアップのプログラムをもらうなり買うなり、運用保守などを依頼して、ある程度長く使うことができるものです。

つまり、「コピーして売るための原本」「研究開発用」と比べるとそれほど情報の鮮度を気にしなくて良いということです。そのため償却期間は５年となっています。


業務に使わないと減価償却できないのが原則

資産を減価償却するには、実際に業務に使わなければなりません。

なぜなら資産は事業用、つまりあくまで会社がお金を稼ぎ出すための道具だからです。したがってたとえば買っただけで使わずに放置してあるようなものは減価償却できません。

この説明だけ読んで「つまらない」と感じた人は、もう少しエンジニアとしての視野を広げた方が良いかも知れません。自分たちが購入するものだけでなく、自分たちが作り納品しているものもこの減価償却が適用されていると知っておくべきです。

先ほど説明したように、減価償却期間が固定で５年と定められている以上、
お客さまにとって納品された"それ"は最低５年は金額に見合った、あるいはそれ以上の成果を出せないと、システムに対して、ソフトウェアに対して、そしてそれらを作った私たちに対して

　支払った金額ほどの価値もないとるに足らない存在

と言うことになります。

たとえば1000万で購入されたのであれば、ソフトウェアとして年間200万程度の価値を生み出せなければなりません。言い換えるなら、新規にシステムを導入する前と後でビジネス的に200万以上の良い変化（効率化や利益改善）が起こせないとならないということになります。

もし、これから新たに始めるというのであれば導入しなかった場合とした場合との間で試算した結果、200万以上の利益差がでなければなりません。

みなさんは見積り時や要件定義時にそのようなことを考えて、「要件」や「仕様」に向き合っていますか？

企業や管理職の方々はそのような姿勢や覚悟を社員に、部下に意識づける働きかけをしていますか？

また、保守・運用と言う側面から考えた場合、５年は最低でも保守・運用または改修などのサポート依頼があっても対応できるような作りでなくてはなりません。

たとえば

・言語やライブラリ、ＯＳや開発ツールのサポート期限は大丈夫か？
　仮に切れたとしても代用できるアテはあるのか？

・代用のアテが無い場合、バージョン等に依存した作りを行っていないか？
　設計書やプログラム等の構成も再利用性を考慮したものになっているか？

などを検討しておかなければなりません。

再三再四説明しているように、

　プロジェクトのライフサイクルはプロジェクト終了までであっても
　ソフトウェアのライフサイクルは稼働してから廃棄されるまで
　システムのライフサイクルはお客さまのビジネスが変化するまで

です。
そのことを念頭に置けないＩＴエンジニアは２～３流から脱することはできません。なぜなら「利用者」を見ていない作り手のエゴだけでモノづくりをしていることになり、それはとてもプロフェッショナルとは呼べない姿勢であるからです。

いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。