情報システム部門やIT企画で仕事をしていると、IT投資決裁の場でこう聞かれる場面がありますよね。
- 「どれくらいで投資回収できますか？」
- 「その効果、金額で言うと？」
- 「TCOはいくらですか？」
システムの要件は語れる。ベンダーとの交渉もできる。稟議の書き方もわかっている。それなのに、お金の処理の話になった途端、急に自信がなくなる。そんな経験はないでしょうか？
本当は「一度ちゃんと整理しておかないとな」と思っているかもしれません。でも会計の本を開くと、仕訳や勘定科目の話から始まってしまう。自分の仕事とどう繋がるのかが見えないまま、そっと閉じる。
私もそうでした・・・。
担当者として稟議を書いていたころは、それでも何とかなっていました。見えていなかったことに気づいたのは、部門のIT予算を統括する立場になったときです。
予算の費目一覧を開いたら、減価償却費が独立した費目として並んでいました。しかも、システムの利用料や委託料とほぼ同じ規模で載っている。
自分が決めた投資ではありません。過去に誰かが承認した開発が無形資産（形のない資産）として残っていて、今年の予算を地味に圧迫している。これを見たときに、発注する立場に必要な会計の知識は、仕訳を覚えることではないと気づきました。
大事なのは、自分の発注が、この先どこに・いつ・どう効いてくるのかを読めることです。
この記事では、システム開発を発注する立場が押さえておきたい会計の知識を整理します。情シス・IT企画・事業側PMが対象です。扱うのは全体像と使う場面まで。個々の会計処理の詳細には踏み込みません。
この記事でわかること
- 発注する立場に会計の知識が要る理由
- 投資（Capex）と費用（Opex）の見分け方
- 発注のどの場面で、どの知識が効いてくるのか
なぜ発注する立場に会計の知識が要るのか
まずは、情シスやIT企画などシステムの発注側にいる人が、なぜ会計の知識を必要とするのか、まとめてみます。
① どこにお金を使うかを決める立場だから
情シスやIT企画にいると、ベンダーへの発注の権限を持つことになります。つまり、どこにお金を使うかを決められる立場です。実は、かなりの強権です。
仕事をしていると、現場や企画からこんな相談を受けますよね。
「この画面、改修できないですかね？」
「来月から使いたいんですけど、なんとかなりませんか？」
ここで効いてくるのが会計の知識です。期初の予算にないことは、基本的にはできません。でも、予算の知識がないまま安請け合いをすると、結局実現できずに終わります。信頼を落とすのはこのパターンです。
逆に、知識があると打ち手が増えます。
- ROIを試算して効果が見込めるなら、優先度の低い案件と入れ替える
- 費用側に空きがあれば、開発ではなくSaaSで実現する案を出す
- リリースを次年度にして、先行開発を提案する
お金の使い方を知っていれば、事業の要望に応える選択肢が増えます。
② 稟議は「会計の言語」でも審査されるから
稟議を審査するのは、IT部門の責任者や経営・経理・事業企画です。彼らが見ているのは、技術的な妥当性ではありません。
- いくらキャッシュが出ていくのか
- それに見合うリターンがあるのか
- どの期のPL（損益計算書）に、いくら乗るのか
この3つに答えられていない資料は、内容が良くてもNGになります。逆に言うと、審査する側の言語で書けているかどうかが通過率を左右します。
いくら定性的に良さそうな未来を語っても、利益貢献しないものはすぐに弾かれてしまいます。
③ 今日の発注が、数年先のPLに影響するから
開発して資産になったものは、数年にわたって少しずつ費用になります。つまり、今日の発注は「今年のお金の使い方」を決めているのではありません。数年分の予算枠を先に取っていることになります。
そして途中で開発をやめると、残った分が一括で費用に乗ります。始めるときも、やめるときも、判断が数年単位で効いてくる。ここが発注という仕事の重さですね。
では、ここからはシステムを発注する立場に必要な「会計の知識」について、解説していきます！
発注のタイムラインで見る「いつ、どの知識が効くか」
もちろん、簿記を勉強しましょうという話ではありません！情シス・IT企画に必要な会計の知識は、そこまで多くありません。
予算を組むところから、システムを捨てるところまで。仕事の流れに沿って知識を並べると、どこでどんな知識が必要になるかが見えてきます。
概観は、次のようなイメージです。
ここから、それぞれのフェーズで効く知識を見ていきます。
① 予算策定：投資と費用を分ける
来年度の予算を組むとき、まずやるのが投資（Capex）と費用（Opex）の仕分けです。
| 投資（Capex） | 費用（Opex） | |
|---|---|---|
| 会計上の扱い | 資産→減価償却で費用化 | 当年で一括費用化 |
| 主な費目 | システムの新規構築・機能追加など | 維持管理費、クラウド利用料、ライセンス費用など |
例えば、既存システムの機能追加プロジェクトであれば、多くの場合「投資」として扱われます。一方で、SFDCのライセンス料金は「費用」です。では、SFDCに機能を追加するプロジェクトの予算はどちらでしょうか？
多くの場合「投資」として扱われます。SFDC自体はお金を払って使っているだけです。ただ、付け加えた機能を自社が保有し、将来の利益に繋がると言えるなら、そこにかかるお金は投資とみなされます。
ただし、SaaS基盤の上に作る機能は、資産計上できるかどうかの判断が分かれやすいところでもあります。経理と早めに確認しておくと安心です。
ちなみに、どちらもキャッシュは同じだけ出ていきます。違うのはBSとPLへの乗り方です。
- 投資：投資は資産としてBSに計上。その後に減価償却費として数年に分けてPLに乗る
- 費用：費用はその期のPLに丸ごと乗る
この違いが、予算を削る場面で効いてきます。同じ100万円でも、投資を削るのと費用を削るのではPLに与える影響が変わる。ここは記事の後半で実体験として書きます。
もうひとつ、予算策定で見落とせないのが過去の投資の償却費です。今年の予算には、自分が決めていない過去の開発の償却費が最初から乗っています。
使える枠は、そこを引いた残りになるというのも重要なポイントです。
② 投資決裁：TCOとROIの考え方
企画を立て、要件を作り、見積もりを取ったあとは、社内の投資決裁を仰ぎますよね。
その時に必要な知識として、TCOやROIというものがあります。コストを出すためにベンダーに開発費用を見積もりますが、投資決裁の場でみられるコストというのはそれだけではありません！
そこで出てくるのが、TCO（Total Cost of Ownership：総保有コスト） です。これは、そのシステムを持ち続けるために出ていくお金の合計です。例えば、こういったものをすべて含んだコストのことです。
- 調査費用
- システム開発費用
- 保守・運用委託費
- ライセンス更新費
- 移行・教育にかかる費用
- クラウド・SaaSの利用料（※）
- 将来やめるときの廃棄・移行費用（※）
※ 利用料を何年分見るか、廃棄費用を含むかなどは各社のルールに依存
例えば、AWS上に新規のシステムを構築するとします。この場合は、開発にかかる費用と、AWSの利用料がかかります。これらをひっくるめてTCOという考え方です。ちなみに、どれくらいの利用料をTCOに含めるのかは、会社ごとにルールがあると思うので確認しましょう。
投資決裁の場に出す資料に、ベンダーから取った見積もりだけを積んでしまうと危険です。その他を積み損ねると、審議の場で「総額がわからない」と止まります。
現場だと、開発のコストはしっかり積むものの、ライセンスやクラウドの利用料が抜けているケースが散見されます。要注意です！
次に、ROI（投資対効果） です。得られる効果をかかった費用で割ったものです。(ざっくり言うと、ROI=得られる効果÷かかった費用 です)
日本語で書くと簡単ですが、実際にどの数字を置くのかが問題です。かかった費用のところも、ベンダーが出した見積額だけなのかTCOなのかでROIも変わってきます。もちろん、ここはTCOを置くのが基本です。
さらに、分子におく「得られる効果」のところも、どんな数字を置くのかは重要です。売上増加額や、コストの削減額を置くのが正しいのですが、社内工数の削減時間・削減額は原則NGです。社内工数というのは、つまり社内人件費です。人件費は固定費なので、削ることができません。結果として、キャッシュアウトは減らないので、ROIは立たないのです。
ROIのたて方は非常に重要なので、こちらの記事で詳しく解説しています。
また、投資決裁の場で審議されるときに、このコストが「投資」なのか「費用」なのかも問われるポイントです。
投資であれば、資産化され、その後は数年にわたって減価償却としてPLに費用が乗ってきます。一方で、費用であれば、今年のPLにそのまま全額計上されます。使うお金に対して、どれだけ効果があるのか？という観点以外にも、使ったお金が事業のPLにどう影響するかも問われることがあるため、注意が必要です。
特に、PoCにかかる費用は要注意。PoCで簡単な仕組みを実装したとしても、原則としては費用として扱われます。投資にはなりません。というのも、作られたものが将来の収益獲得や費用削減に繋がると、まだ確実には言い切れない段階だからです。
投資に該当するのは、作られたシステムによって、将来の収益獲得または費用削減が確実と認められる場合です。ちょっと難しいですが、PoCは費用処理されると覚えておきましょう！
③ 契約・発注：計上月・見積もりの内訳
契約を結ぶ段階で意識するのは2つです。
ひとつは計上のタイミング。費用や資産が計上されるのは検収した月です。年度末ぎりぎりの納品予定は、検収が1か月ずれるだけで予算年度をまたぎます。今年度の予算で消化するつもりが、来年度に食い込む。予実管理が崩れる典型パターンなので要注意です。
もうひとつは見積の内訳。作業内容によって扱いが変わります。
- 事前調査・PoC・ライセンスなど → 費用
- 保守・維持管理 → 費用
- 新規構築・機能追加 → 投資
ひとつの見積書にまとめて書かれていると、後から切り分けられません。発注する側が、最初から内訳を分けて出すよう依頼しておくのが実務のコツです。
特に、予算管理にあたり、投資枠と費用枠で予算を分けている場合は、内訳をよく確認しましょう。
例えば、クラウド利用料を投資用の予算枠で取っていた場合。実際は、投資ではなく費用扱いです。他の費用予算から借りてこないといけなくなります。なぜなら、投資と費用では当年のPLへの影響が変わるから。
投資も費用も同じ予算でしょ？と思っていたら、大間違いです。投資と費用の違いは、改めて押さえておきましょう。
④ 開発中〜稼働：償却はいつから始まるのか
意外と知られていないのが、開発中は減価償却が始まらないという点です。
制作途中の支出は「ソフトウェア仮勘定」としてBS（貸借対照表）に積み上がります。仮勘定のあいだは償却しません。完成してソフトウェアの勘定に振り替えられたタイミング（リリース）から、償却が始まります。自社利用のソフトウェアであれば5年以内で費用化していくのが一般的です。
ここから何が言えるかというと、リリースが遅れると、翌期のPL計画がずれるということです。
4月稼働で年間まるまる償却が乗る想定だったのに、6月稼働になれば、その期の償却費は10か月分に減る。予算上は「浮いた」ように見えますが、翌々期に後ろ倒しされているだけです。
進捗管理は、品質やスケジュールの話だと思われがちです。実際にはPL計画にも直結しています。現場のPMはそこまで把握しなくても良いですが、マネジメントラインの人は意識しておきたいところです。
⑤ 運用〜刷新：運用コスト
稼働したら、運用フェーズのコストは基本的に費用（Opex）です。利用料も保守費も、その期の費用としてそのままPLに乗ります。
だからこそ、予算圧縮の議論では真っ先に候補に挙がります。PLに直接効くからです。ただし現に使っているものなので、実際に削れる余地は多くありません。ここが運用コストの厄介なところです。
そして、もっと厄介なのがやめるときです。
減価償却が終わっていない資産を廃棄すると、残っている未償却の金額が除却損としてその期に一括で計上されます。3年経過した時点で刷新すれば、残りの期間の分が一度に乗る計算です。
つまり、刷新の投資決裁には新システムの投資額と、旧システムの除却損の両方が乗ります。新しいシステムの見積だけを持っていくと、決裁の場で数字が足りません。
ここまでが知識の全体像です。次は、これを知らなかったころの私の失敗を書きます。
実体験：「費用100万円」と「投資100万円」は同じ100万円ではなかった
何が起きたか
翌年度の予算を策定していたときの話です。
前提として、予算はPLベースで組みます。翌年の売上・コスト・利益の計画があり、そのコストの中にIT投資が含まれる。全社方針で、予算は一定率以内に収める必要がありました。利益計画を達成するには、翌年のPLに乗るコストを減らすしかありません。
まず見たのが費用です。ただ、SaaSのライセンス費用は削れません。現に使っているユーザーがいる以上、事業運営に直結していて止められない。保守費も同じでした。
そこで私は、開発の予算を落とす案を持っていきました。「100万円分の開発を見送ります」と。資産計上される前提の開発案件です。
予算策定の担当者から返ってきたのは、こんな言葉でした。
「それだと、PLはほとんど変わらないですよ」
何を誤解していたか
言われて初めて気づきました。私は「100万円削る」を1種類の行為だと思っていたのです。実際には2種類ありました。
| 削る対象 | キャッシュアウト | 初年度のPL | 翌年度以降のPL |
|---|---|---|---|
| 費用（ライセンス等）100万円 | 100万円減る | 100万円減る | 変わらない |
| 投資（開発）100万円 | 100万円減る | 20万円程度しか減らない | 償却費が発生しなくなる |
投資として計上されたものは、5年で償却するなら初年度に乗るのは20万円分です。しかも稼働月からの月割になるので、実際はもっと小さくなります。
キャッシュアウトはどちらも同じ100万円です。でもPLへの効き方はまったく違いました。私が求められていたのはPLの改善だったので、投資を削る案では答えになっていなかったわけです。
この経験から学んだこと
学んだのは、削減の議論を始める前に何を守りたいのかを先に決める、ということです。
- PLを守りたい → 費用（Opex）を削るしかない。ただし事業運営に直結していて削りにくい
- キャッシュを守りたい → 投資（Capex）を削るのが効く
そしてもうひとつ。投資を削っても今期のPLはほとんど軽くなりませんが、翌期以降のPLは確実に軽くなります。将来の償却費が発生しなくなるからです。効果が1年ずれて出てくる。
だから予算の議論では、今期の話をしているのか、来期以降の話をしているのかを揃えないと噛み合いません。会計を知らなかったころの私は、この2つを同じテーブルに乗せて話していました。
投資と費用の違いは、教科書では1行で説明されます。でも実務では、削ったつもりで何も削れていないという形で現れてきます。
まとめ
発注する立場に必要な会計の知識を整理してきました。
軸になるのは、投資（Capex）か費用（Opex）かという仕分けです。どちらもキャッシュアウトは同じでも、PLへの乗り方がまったく違う。この一点を起点に、TCO・ROI・資産計上・減価償却・除却といった知識が、タイムライン上でつながっていきます。
タイムラインで押さえる
| フェーズ | 必要な知識 | 知らないと？ |
|---|---|---|
| 予算策定 | 投資と費用の仕分け、過去の投資の償却費 | 削ったつもりでPLが動かない |
| 投資決裁 | TCO、ROI、資産計上できるかどうか | 総額が示せず止まる、単年の費用が膨らむ |
| 契約・発注 | 検収月と計上月、保守と機能追加の切り分け | 予算年度をまたぐ、後から切り分けられない |
| 開発中〜稼働 | ソフトウェア仮勘定、償却の開始時点 | リリース遅延で翌期のPL計画がずれる |
| 運用〜刷新 | 運用コスト、除却損 | 刷新の決裁で数字が足りない |
明日から使える形にすると、確認すべきことは3つに絞れます。
稟議を書く前に、経理に確認しておきたい3つ
- この案件は資産計上できるか（効果の説明で要件を満たせるか）
- 資産計上する場合、償却年数は何年で見るか
- 稟議に載せる金額は、稼働後の運用費を何年分まで含めるか
発注する立場に必要な会計の知識とは、自分の発注が、この先どこに・いつ・どう効いてくるのかを読めることです。
細かい仕訳を覚える必要はありません。ただ、いま自分が承認しようとしている金額が、どの期に、どんな形で会社の数字に現れるのか。ここは説明できるようにしておきたいところです。
おまけ：やりがちなNGパターン
NG① 初期構築費だけで投資決裁に臨む
私自身がやってしまった失敗です。
あるシステムの投資決裁の資料を作ったときのこと。AWS上に構築する構成だったのですが、稟議書に初期の構築費用しか記載していませんでした。稼働後に毎月かかるクラウドの利用料が、どこにも入っていない。
- 稟議に載っているのは開発費とベンダー委託費だけ
- 稼働後のクラウド利用料・SaaSライセンス・保守費が入っていない
- 結果として、審議の場で「これでは総額がわからない」と指摘され、出し直しになった
TCOの考え方が抜けていると、そもそも正しい投資額がわかりません。当然、ROIも計算できません。分母が間違っている比率には意味がないからです。
稟議に載せる金額は、構築費＋稼働後n年分の運用費で積む。何年分で見るかは社内ルールに合わせて先に確認しておくとスムーズです。
NG② 刷新の稟議に、旧システムの除却損を積んでいない
既存システムを新システムに置き換える案件でよく起きます。
新システムの投資額は精緻に積んである。ベンダー見積も取ってある。でも、いま使っているシステムの未償却残高が資料に出てこない。
- 「新システムは1億円です」と説明する
- 経理から「旧システムの除却損が乗るので、今期のPLインパクトはもっと大きい」と返される
- 決裁の場でタイミングそのものを再検討することになる
刷新の判断は、機能や技術の話だけでは決まりません。償却期間のどこにいるかも判断材料になります。あと1年待てば除却損がほぼ出ない、というケースもあるからです。
刷新の稟議は、新システムの投資額＋旧システムの未償却残高をセットで示す。未償却残高は経理に聞けばすぐ出してもらえます。
NG③ 「開発だから資産計上」と決めつけて経理と握っていない
稟議の段階で「これは投資枠なので、単年のPL負担は小さいです」と説明してしまうパターンです。
ところが経理の判定で費用処理になると、その期のPLに全額が乗ります。想定していた予算の前提が崩れます。
- 効果（将来の収益獲得または費用削減）の説明が弱く、資産計上の要件を満たさない
- 構想・PoC段階の費用まで投資枠で見込んでいた
- 結果として、単年の費用が想定より大きく膨らむ
資産計上できるかどうかは、企画の効果の説明の強さとつながっています。稟議を書く前に、経理と扱いを確認しておく。これだけで手戻りがかなり減ります！
関連記事