財務会計と管理会計の違い、そしてテクノロジー企業の管理会計

エンジニアやマネージャとして働いていると、会計の質問に答えを求められる場面が増えてくる。「この機能の開発にいくらかかったのか」「サーバを買うのとクラウドを借りるのはどちらが得か」「リリースまでの赤字はいつ回収できるのか」といった問いだ。

これらは決算書を読む力、つまり財務会計の知識だけでは答えが出ない。必要なのは管理会計の考え方になる。この記事では、大きい話から小さい話へ順番に降りていく。まず財務会計と管理会計の違い、次に財務会計の土台であるP/L・B/S・C/Fと複式簿記、そして管理会計が実際に扱うもの、つまりハードウェアの購入と減価償却、人件費、ライセンス費やクラウド利用料、ソフトウェア開発の資産化と償却を見ていく。

図はすべて操作できる。再生ボタンのあるものは、押すと時間の流れにそって数字が動く。

結論

• 財務会計は社外に向けて過去を報告する会計で、ルールは法律や会計基準で決まっている。管理会計は社内で未来を決めるための会計で、ルールは自社で決めてよい。両者は別の帳簿ではなく、同じ元データの切り直しにすぎない
• 財務会計はP/L（もうけ）、B/S（財産の残高）、C/F（現金の動き）の3つの表で会社を表す。3つがずれるのは、利益と現金が別物だからだ
• すべての取引は複式簿記で借方と貸方へ同じ額ずつ書かれる。だから「サーバを買う」は費用ではなく、現金という資産がサーバという資産に姿を変えただけになる
• 資産とは「これから先、お金を生むか、お金の支出を減らすと期待できるもの」。費用は「その期間で使い切った分」。同じ支出でも、効果が今月で終わるなら費用、来期以降も続くなら資産になる
• 資産はその後、減価償却や償却を通じて少しずつ費用へ変わる。つまり資産は将来の費用だ。現金はどちらの処理でも同じだけ出ている
• ソフトウェア開発では、調査段階は費用、開発段階のうち要件を満たす部分は資産、リリース後はその資産が償却として費用になる。運用や保守は資産にならず、その月の費用になる
• クラウドやライセンスは買い取りではなく借りているので、資産にならずその期の費用になる。同じ計算資源でも、買えば資産、借りれば費用と載る場所が変わる
• 管理会計の中核は、費用を変動費と固定費に分けて貢献利益（売上 − 変動費）を見ること。共通費を無理に製品別へ配賦すると、意思決定を誤りやすい
• リリース前の判断では、それまでに使った費用は埋没原価であり判断材料にしない。見るのは「これから追加でかかる費用」と「これから得られる収入」だけになる

前提

• 対象読者: 簿記や会計を体系的に学んだことはないが、開発やプロダクトの意思決定に会計の数字が絡んでくるエンジニア、テックリード、エンジニアリングマネージャ
• ねらい: 仕訳を切れるようになることではなく、会議で出てくる数字の意味を理解し、自分で粗い試算を組み立てられるようになること
• 断り: 記載する金額や年数はすべて例示にすぎない。会計基準と税制は国ごとに異なり、改正もある。実際の処理は税理士や会計士、監査法人に確認してほしい

財務会計と管理会計の違い

会計と呼ばれるものは、大きく2つに分かれる。同じ帳簿のデータを使いながら、目的が違うため見せ方も違う。

覚えておきたいのは、両者が別々の帳簿ではないという点だ。仕入や給与といった元データは共通で、それを法定のフォーマットに集計したものが財務会計、社内向けに切り直したものが管理会計になる。下の図で、同じ8件の取引が2つの型へ流れていくところを確かめてほしい。

同じ取引から出発しても、財務会計の型は「会社全体でいくら儲かったか」に答え、管理会計の型は「どの製品が固定費の回収に貢献しているか」に答える。着地する営業利益は同じで、途中の切り方だけが違う。

管理会計に「正解」はない。ルールが自由ということは、裏を返せば「何のためにその数字を見るのか」を自分で定義しないと、集計しただけで終わる。この点は監視ダッシュボードの設計と似ている。

財務会計の基本: 3つの表と複式簿記

管理会計は自由に設計してよいが、その材料は財務会計と同じ帳簿から出てくる。だから土台となる3つの表と、記録のしかたを先に押さえておきたい。

P/L・B/S・C/F は何を表すか

B/Sは左右に分かれている。左（借方）が資産、つまり持っているもの。右（貸方）が負債と純資産、つまりその資産を用意した元手だ。右で調達して左で運用していると読む。左右の合計は必ず一致する。

3つの表がある理由は単純で、利益と現金が別物だからだ。売っても入金が翌月なら利益は出ても現金はない。サーバを買えば現金は出ていくが費用にはならない。この食い違いを説明するために、P/LとC/Fを別々に作る。

複式簿記: すべての取引を2か所へ書く

複式簿記では、1つの取引を必ず借方（左）と貸方（右）へ同じ金額で書く。ルールは次の対応だけ覚えておけばよい。

• 借方（左）に書くもの: 資産の増加、負債の減少、費用の発生
• 貸方（右）に書くもの: 資産の減少、負債の増加、純資産の増加、収益の発生

たとえばサーバを600万円で買うと、次のようになる。

1（借）機械装置 600万円   ／   （貸）現金 600万円
2   資産が増えた                 資産が減った

左右が同じ額なので、B/Sの合計は動かない。そしてこの仕訳のどこにも費用という言葉が出てこない。だから「サーバを買った月に600万円の費用が立つ」ことはない。エンジニアの直感といちばんずれるのはここだと思う。

次の図では、設立直後の会社に取引を1件ずつ足していく。再生すると仕訳が1つずつ切られ、3つの表のどこが動き、どこが動かないかが見える。

注目してほしいのは次の3か所だ。

1. サーバを買うとソフトウェアを資産計上するは、B/SとC/Fしか動かない。P/Lは無反応で、利益は1円も減らない
2. クラウド利用料は、借りているだけなので資産にならず、その月の費用になる。買えば資産、借りれば費用と分かれる
3. 減価償却はP/LとB/Sを動かすが、C/Fは動かない。現金は購入時に払い終わっているからだ

そもそも資産とは何か

会計でいう資産は、次の3つを満たすものだと理解しておけば実務では足りる。

1. 過去の取引や事象の結果として、いま会社が持っている（支配している）
2. 将来、お金を生むか、お金の支出を減らすと期待できる
3. その金額を信頼できる形で測れる

現金や売掛金はもちろん資産だ。サーバも、これから何年か動いて売上を生むので資産になる。自社で開発したソフトウェアも、将来の収益獲得や費用削減が確実だと判断できるなら資産になる。逆に「優秀なチーム」は将来お金を生むが、金額を測れず支配もしていないので、B/Sには載らない。技術的負債も同じ理由で、会計上の負債ではない。

費用と資産の違い

支出は、大きく3つの行き先へ分かれる。

つまり資産と費用を分けているのは効果がいつまで続くかだ。実務ではそこに、金額の大きさ（日本の税務なら10万円未満は費用にできる）や、1年を超えて使うかという線引きが加わる。

そして重要なのは、この選択が何を変えて何を変えないかだ。

• 費用にすると、今期の利益がその分減る
• 資産にすると、今期の利益は減らない。代わりに将来の期に、償却という費用が待っている
• どちらにしても、出ていく現金は同じ

言い換えると、資産は将来の費用のかたまりだ。次の章から、そのかたまりがどう費用へ変わっていくのかを見ていく。

管理会計にはどんな領域があるか

管理会計はひとつの手法ではなく、領域の集まりだ。全体像を持っておくと、「いましているのは原価計算なのか、意思決定の試算なのか」を切り分けられる。

下段の原価計算が共通の土台になり、中段の計画・統制・評価が毎月まわり、上段の意思決定会計が単発の判断を支える、という構造で読む。エンジニアが巻き込まれやすいのは、土台の原価計算（クラウド費用のタグ付けや工数の按分）と、上段の意思決定会計（設備投資の比較、撤退の判断）だ。

テクノロジー企業では何が変わるか

製造業や小売業を前提にした会計の教科書をそのまま当てはめると、ソフトウェア企業では違和感が出る。原因は次の3点に集約される。

1. 原価の大半が人件費であり、それが固定費として振る舞う
2. 複製の限界費用がほぼゼロで、1件追加で売るコストが極端に小さい
3. 価値を生む資産の多くがソフトウェアやデータであり、B/Sに載る金額と実態が一致しにくい

在庫が積み上がる商売なら、原価計算は「モノ1つあたりいくらか」を追う作業になる。ソフトウェアでは追うべき対象が変わり、「どのチームが、どのプロダクトに、何か月分の時間を投じたか」という形になる。

売上原価（COGS）に何を入れるかも自社で決める必要がある。SaaSでは次の範囲を売上原価に含める例が多い。

• 本番環境のクラウド費用、CDN、データ転送
• サードパーティAPIの利用料のうち、提供に直接必要な分
• カスタマーサポートやSREなど、サービス提供の維持に直接関わる人件費
• 資産計上したソフトウェアの償却費

一方で、新機能を作る開発チームの人件費は研究開発費や販管費に置き、売上原価に入れないことが多い。この線引きを変えると粗利率が数十ポイント動くため、社内で定義を固定し、途中で変えないことが重要になる。

IT企業の費目はどこに載るか

費目ごとに「売上に連動するか」と「P/Lのどこに載るか」を並べると、打ち手の効き方まで見えてくる。

同じクラウドでも、完全従量課金なら左下の変動費、年間コミットを結んだ瞬間に左上へ動く。ライセンスは売上ではなく人数に連動するので、右側の準変動費として振る舞う。位置が変われば打ち手も変わる、というのがこの図の要点だ。

ハードウェアの購入と減価償却

ここからミクロに降りていく。まず、いちばん資産らしい資産であるハードウェアから見る。

買った瞬間に費用にはならない

前の章で見たとおり、サーバの購入は資産と資産の交換であって費用ではない。10万円以上の機器は原則固定資産としてB/Sへ計上し、使用する年数にわたって少しずつ費用にしていく。日本の税務では、取得価額に応じておおむね次のように扱いが分かれる。

特例には適用期限や対象法人の条件があるため、最新の要件は国税庁の情報で確認してほしい。

資産が費用へ変わっていく

減価償却は「高い買い物を、使う期間に配分する」だけの仕組みだ。収益を生んだ期間と費用を対応させるという費用収益対応の原則から来ている。

次の図では、資産として置かれた金額が毎年どれだけ費用へ移るかを再生できる。取得価額と耐用年数を動かすと、現金の支出と費用の計上がどれだけずれるかも変わる。

下の2本のバーが伝えたいことは、この節の結論そのものだ。現金の支出は初年度に100%終わっているのに、費用の計上は耐用年数をかけてゆっくり進む。利益とキャッシュフローがずれるのは、この差から生まれる。

定額法と定率法

1定額法: 毎年同じ額を費用にする
2  年間償却費 = 取得価額 ÷ 耐用年数
3  例) 600万円 / 5年 → 毎年 120万円（月あたり10万円）
4
5定率法: 期首の帳簿価額に一定率をかける
6  年間償却費 = 期首簿価 × 償却率
7  例) 600万円 / 5年（償却率 0.400）
8      1年目 240万円、2年目 144万円、3年目 86.4万円 …

定率法は初期に多く償却するため、早く費用化して税負担を前倒しで軽くしたい場合に選ばれる。資産の種類によって選択できる方法が決まっており、届出がなければ法定の償却方法が適用される。

法定耐用年数は資産ごとに細かく定められている。ITまわりでよく出るのは次のあたりになる。

区分の判定は実務上まぎらわしい部分があるので、最終的な判断は税理士に確認してほしい。なお法定耐用年数は税金の計算ルールであって、実態を表すとは限らない。GPUの世代交代が2年で来るなら、社内の投資判断は2年で回収できるかどうかで見るべきだ。財務会計上は5年で償却しつつ、管理会計では2年ぶんの負担として試算する、という使い分けは問題ない。

CapEx と OpEx

• CapEx（資本的支出）: 資産を買う支出。現金は先に出るが、費用は償却を通じて分割計上される
• OpEx（運営費用）: その期の費用になる支出。クラウドの利用料が代表例

サーバ購入とクラウドの比較で混乱が起きるのは、両者が同じ土俵に載っていないためだ。

 1案A: GPUサーバを購入
 2  取得価額 6,000,000 円 / 耐用年数 5年 / 定額法
 3  初年度の現金支出: 6,000,000 円
 4  初年度のP/L費用: 1,200,000 円（減価償却費）
 5  電気代・保守・設置場所の費用は別途発生する
 6
 7案B: 同等のGPUをクラウドで借りる
 8  月額 180,000 円
 9  初年度の現金支出: 2,160,000 円
10  初年度のP/L費用: 2,160,000 円

P/Lの費用だけを比べると案Aが安く見えるが、現金は初年度に600万円出ていく。逆に5年間の総額で比べると、案Aは600万円と運用費、案Bは1,080万円となり、稼働率が高いほど購入が有利に傾く。比較するときは、次の3つを必ず揃える。

1. 比較期間（3年なのか、5年なのか）
2. 現金の流出と、P/L上の費用のどちらを見ているのか
3. 電気代、ラック代、保守、故障対応の工数といった隠れた費用

稼働率と、償却済み資産の罠

購入したハードウェアの費用は、稼働率と関係なく同額発生する。つまり典型的な固定費だ。GPUを1台買って稼働率が20%なら、実質的な単価は5倍になる。クラウドが選ばれる本質的な理由は単価の安さではなく、稼働率の低い時間帯の費用を持たなくてよいことにある。

減価償却費は、その期に現金が出ていかない費用だ。この性質から次の指標がよく使われる。

1EBITDA ≒ 営業利益 + 減価償却費 + のれん償却費

設備投資の規模が違う会社を比べるときに便利な指標だ。ただしEBITDAは「設備投資が不要」を意味しない。償却対象の資産はいずれ更新が必要で、そのときには現金が出ていく。

逆に、耐用年数を過ぎた資産を使い続けると償却費がゼロになり、その部門の原価が見かけ上下がる。実態は何も改善していないのに数字だけが良くなるので、部門間や年度間の比較では注意したい。想定より早く価値が失われた場合は減損を検討する。収益性が著しく低下し、投資額の回収が見込めなくなったときに、帳簿価額を回収可能な金額まで一気に引き下げる処理だ。

人件費: エンジニアの時間を金額に直す

ソフトウェア企業でいちばん大きい費用は人件費だ。ここを金額に直せないと、他のすべての試算が始まらない。

給与ではなくフルコストで見る

年収800万円のエンジニアにかかる費用は、800万円ではない。会社が実際に負担する金額を積み上げる必要がある。

1フルコストの構成例（年間）
2  給与 + 賞与                      8,000,000 円
3  法定福利費（社会保険料の会社負担）  1,200,000 円  ※おおむね給与の15%前後
4  採用・教育の按分                   400,000 円
5  PC、ライセンス、SaaS、開発環境       500,000 円
6  オフィス、光熱費、管理部門の按分     900,000 円
7  ------------------------------------------------
8  合計                            11,000,000 円

「給与のおよそ1.3倍から1.5倍」を目安にする会社が多いが、比率は業種と地域で変わるので、自社の実績から出したほうがよい。

時間単価（チャージレート）を作る

工数を金額に換算するには、フルコストを年間の稼働時間で割る。

1年間稼働時間 = 8時間 × 240日 = 1,920時間（有給や研修を引くと 1,700〜1,800 時間程度）
2
3時間単価 = 11,000,000 ÷ 1,800 ≒ 6,100 円/時間
41人月（160時間）≒ 980,000 円
54人チームの1か月 ≒ 3,900,000 円（以降の図では月400万円として扱う）

この単価があると、「この機能に3人で2か月かかった」という工数を、そのまま「約590万円の投資」に翻訳できる。会議の議論が一気に具体的になる。

工数の取り方は粗くてよい

正確さを求めて15分単位のタイムシートを導入すると、入力の負担と数字の信頼性が釣り合わなくなる。おすすめは次の運用になる。

1. 四半期のはじめに「チーム × プロダクト」の按分率を決める（例: プラットフォームチームは製品A 60%、製品B 40%）
2. 期中は大きな変更があったときだけ按分率を見直す
3. 大型プロジェクトだけ、エピック単位で人月を別に集計する

管理会計の目的は原価の正確な再現ではなく、意思決定を助けることにある。小数点以下を合わせる労力は、多くの場合ムダになる。来月の判断に間に合うことのほうが価値は高い。

ライセンス費とクラウド利用料

人件費の次に大きいのが、買わずに借りているものの費用だ。

借りているものは資産にならない

クラウドやSaaSライセンスは、所有権を得るわけではなく、期間や量に応じて使う権利を買っている。だから原則として資産にならず、その期の費用になる。同じ計算能力でも、サーバを買えばB/Sに資産として残り、クラウドで借りればP/Lに費用として消えていく。この違いが、次のような形で経営の数字に出てくる。

• 購入は、初年度の利益への影響が小さく（償却分だけ）、現金への影響が大きい
• クラウドは、利益への影響がそのまま出て、現金への影響も同じ額になる
• 購入は稼働率のリスクを自社で持つ。クラウドはそれを単価に含めて相手に持たせている

クラウドは本当に変動費か

クラウドは変動費の代表例として語られやすいが、実態は契約によって変わる。

• 完全従量課金で、負荷に応じてスケールする構成: 変動費に近い
• 1年や3年のコミットメント契約、予約インスタンス、専用線: 実質的に固定費
• 最低ノード数を確保した常時稼働のKubernetesクラスタ: 準固定費

コスト削減の打ち手も、この分類で変わる。変動費なら1リクエストあたりの効率改善が効き、固定費なら契約の見直しやリソースの統廃合が効く。ライセンスも同じで、席数課金は人数に連動する準変動費なので、未使用席の棚卸しがそのまま効く。

固定費の考え方

ソフトウェア企業の費用はほとんど固定費

開発者の給与は、リリースの有無や売上の増減と関係なく発生する。オフィスも同じだ。つまり費用構造が固定費に強く偏る。ここから次の性質が導かれる。

• 売上が損益分岐点を超えるまでは、売上が増えても赤字が続く
• 損益分岐点を超えると、増えた売上の大部分が利益になる（オペレーティングレバレッジ）
• 売上が急減したとき、費用は同じ速度では減らせない。だから固定費の水準は「最悪期に耐えられるか」で決める

貢献利益と損益分岐点

1貢献利益     = 売上 − 変動費
2貢献利益率   = 貢献利益 ÷ 売上
3損益分岐点   = 固定費 ÷ 1件あたり貢献利益

この記事で使う試算例を置いておく。以降の図もこの数字で動いている。

1前提: 月額 10,000 円のSaaSを法人向けに提供する
2  1社あたり変動費（クラウド + 決済手数料）: 2,000 円
3  1社あたり貢献利益: 8,000 円（貢献利益率 80%）
4  月間の固定費（運用と改善のチーム + 共通費）: 3,500,000 円
5
6損益分岐点: 3,500,000 ÷ 8,000 = 437.5 → 438社

438社に届くまで単月は赤字で、そこを超えると売上の80%がそのまま利益に乗ってくる。ソフトウェア事業の損益がS字を描くように見えるのは、この構造による。

配賦の罠

共通で発生する費用を、何らかの基準で各製品や部門へ割り振る作業を配賦と呼ぶ。配賦そのものは悪くないが、意思決定に使うと事故が起きる。次は年間の数字を売上比で配賦した例だ。

1配賦した損益（共通費 3,900万円を売上比で配賦）
2  製品A: 売上 1億円 / 直接費 4,000万円 / 配賦された共通費 3,000万円 → 利益 3,000万円
3  製品B: 売上 2,000万円 / 直接費 1,000万円 / 配賦された共通費 600万円 → 利益 400万円
4  製品C: 売上 1,000万円 / 直接費 700万円 / 配賦された共通費 300万円 → 利益 0円
5
6「製品Cは儲かっていないから撤退しよう」
7  → 撤退しても共通費 300万円は消えない。他製品へ付け替わるだけ
8  → 実際に失われるのは 1,000万 − 700万 = 300万円の貢献利益
9  → 会社全体の利益は 300万円減る

撤退や継続の判断で見るべきは、配賦後の利益ではなく、貢献利益と回避可能固定費（やめれば本当に消える固定費）になる。

同じ理由で、現場のマネージャに本社費の責任を負わせても行動は変わらない。自分で動かせないからだ。管理会計では費用を「その責任者が意思決定で動かせるか」で分け、チームの評価には管理可能費だけを載せる。

ソフトウェア開発の資産化と償却

ここはエンジニアの仕事といちばん近い論点だ。自分たちが書いたコードは、会計上どう扱われるのか。

フェーズによって扱いが変わる

支出の性質がフェーズごとに変わるので、会計の扱いも変わる。

次の図は、この流れを1本のタイムラインで動かしたものだ。エンジニアの工数が資産へ積まれ、リリース後に償却として費用へ戻っていくところを再生できる。

大事なのは、開発した月ではなく、使う月に費用が載るという点だ。開発中はP/Lが軽く見え、リリース後に償却費という形で毎月効いてくる。「廃止する」を選ぶと、残っていた未償却残高が一気に費用へ落ちる様子も確かめられる。

各基準での扱い

日本基準では、おおむね次の考え方になる。

• 自社利用のソフトウェア: 将来の収益獲得または費用削減が確実と認められる場合に無形固定資産へ計上し、原則5年以内の定額法で償却する。確実といえない段階の支出は費用処理する
• 市場販売目的のソフトウェア: 最初に製品化された製品マスターが完成するまでの費用は研究開発費として費用処理し、それ以降の制作費を資産計上する。償却は見込販売数量などにもとづき、残存有効期間は原則3年以内とする

参考までに、他の基準では次のように整理されている。

• US GAAP: 社内利用ソフトウェアは ASC 350-40、販売目的ソフトウェアは ASC 985-20 が扱う。開発段階（application development stage）や技術的実現可能性の到達以降を資産計上の対象とする考え方が基本になる。近年は見直しが進んでいるため、最新の基準を確認してほしい
• IFRS: IAS 38 が無形資産を扱う。研究局面の支出は費用、開発局面の支出は6つの要件をすべて満たす場合に資産計上する

管理会計の立場と、資産計上の副作用

管理会計では、この区分に振り回されないほうがよい。会計処理の区分と関係なく、出ていく現金は同じだからだ。社内の投資判断では、会計処理と切り離して「このプロダクトに通算いくら投じたか」を素直に積み上げる。

資産計上には次の副作用がある点も知っておきたい。

• 当期の費用が減るため、利益は良く見える。しかし現金は同じだけ出ている
• 償却は翌年以降に必ずやってくる。開発を続けるかぎり、償却費は積み上がる
• 「資産計上できる工数」を増やす動機が働くと、工数の付け方が歪む

リリース前後の考え方

最後に、時間軸をもう一段広げる。開発からリリース、回収までを1枚で見ると、現金と会計上の損益がどうずれるのかがはっきりする。

会計処理を切り替えても、棒（現金）はまったく動かず、線（会計上の損益）だけが動く。ここが図の要点だ。そして累積キャッシュの谷が、投資の深さと回収までの距離を表している。

リリースまで: 増分だけで判断する

まだ売上が立たない期間は、費用だけが出ていく。ここで見るべきは損益ではなく、投資額と回収の見通しになる。

1✗ 誤り: すでに1億円かけた。ここで止めたら1億円が無駄になる
2○ 正しい: 完成まであと追加で4,000万円かかる。
3          リリースできれば年間3,000万円の貢献利益が見込める。
4          すでに使った1億円は、続けても止めても戻らない

すでに使った費用は埋没原価であり、比較の対象から外す。判断材料は「これから追加でかかる費用」と「これから得られる収入」に限られる。

投資判断でよく使う指標は3つある。初心者はまず回収期間から入るとよい。

 1回収期間法: 投資額 ÷ 年間の増分キャッシュフロー
 2  例) 4,000万円 ÷ 3,000万円 = 約1.3年
 3  長所: 直感的で計算が速い / 短所: 回収後の利益と時間価値を無視する
 4
 5正味現在価値（NPV）: 将来のキャッシュフローを資本コストで割り引き、投資額を引く
 6  NPV = Σ( CFt ÷ (1 + r)^t ) − 投資額
 7  NPV > 0 なら、その投資は価値を生む
 8
 9内部収益率（IRR）: NPVがちょうど0になる割引率
10  資本コストを上回っていれば投資に値する

割引率 r は資本コストを使うが、社内の粗い試算なら「その会社が他の投資で期待している利回り」程度の理解で十分だ。重要なのは精度ではなく、将来のお金は今のお金より価値が低いという前提を式へ織り込むことだ。

不確実性が高い開発では、最初に全額の投資を決めるより、フェーズごとに再評価するほうが合理的になる。調査フェーズで実現性と需要を確かめ、実現性が確認できたら本格的に投資し、リリース判定でもう一度採算を計算する。各ゲートで「ここまでの費用は忘れて、これから先だけで判断する」を徹底する。

リリース後: 粗利率とユニットエコノミクス

リリース後は、次の構造で数字を見る。

1売上
2 − 売上原価（クラウド費用、サポート人件費、ソフトウェア償却費 など）
3 = 売上総利益（粗利）
4 − 販管費（営業、マーケティング、管理部門、新機能の開発費 など）
5 = 営業利益

SaaSの粗利率は70%から85%程度に収まることが多いと言われる。これを大きく下回る場合、提供コストの構造に特殊な事情がないか疑ってみるとよい。

顧客1件あたりで採算が合っているかを見る指標群が、ユニットエコノミクスだ。全社の損益が赤字でも、ここが健全なら規模の拡大で黒字化する道筋を説明できる。

1CAC（顧客獲得コスト） = 営業・マーケ費用 ÷ 新規獲得顧客数
2LTV（顧客生涯価値）   = 顧客あたり月次貢献利益 × 平均継続月数
3CAC回収期間          = CAC ÷ 顧客あたり月次貢献利益
4
5目安としてよく引かれる水準
6  LTV / CAC   > 3
7  CAC回収期間 < 12か月
8  Rule of 40  : 売上成長率(%) + 営業利益率(%) ≧ 40

これらはあくまで経験則であり、業種や事業のステージによって適切な水準は変わる。数値を絶対視せず、自社の時系列の変化を追うほうが役に立つ。

リリース後の開発にも、費用処理と資産計上の線引きがある。バグ修正や性能の維持、セキュリティパッチのように現状を保つ支出は費用、明確に新しい機能を追加して将来の便益が見込める支出は資産計上の余地がある。実際の判定は基準と監査法人の見解に依存するため、境界事例は必ず相談してほしい。

サービスを終了するときは、未償却の残高が除却損として一括で費用になる。終了の意思決定より前に収益性の著しい低下が判明していれば、減損を検討する。「もう使っていないのに帳簿に残っている資産」は棚卸しの対象で、クラウド移行のあとに旧設備が放置されているケースは珍しくない。

エンジニアの仕事は、管理会計でどう扱われるか

ここまでの話を、日々の仕事の単位で並べ直す。

こうして並べると、「コードを書く」という同じ行為が、フェーズによって資産と費用のどちらにもなると分かる。そして管理会計の側では、どちらであっても投じた時間と、返ってくる金額で評価される。会計処理の区分に振り回されず、この対応関係だけ押さえておけば、経営との会話はかなり噛み合うようになる。

実務での始め方

いきなり本格的な仕組みを入れる必要はない。次の5ステップなら、スプレッドシートで始められる。

1. チームごとの月次フルコストを出す（人数 × フルコストの月割り）
2. プロダクト別に、売上と直接費（クラウド、決済、外部API、専任メンバーの人件費）を集計する
3. プロダクトごとの貢献利益を計算する
4. 共通固定費は配賦せず、全社で1行にまとめて置く
5. 月次で並べ、傾向の変化を追う

半年ほど続けると、どのプロダクトが固定費を回収し、どれが投資段階にあるかが数字で見えるようになる。配賦や精緻な原価計算に手を出すのは、そのあとで十分だ。

注意点

• 会計基準と税制は国と時期で変わる。この記事の数値や年数は例示であり、実際の処理は必ず税理士や会計士に確認してほしい
• 資産計上の判断は、監査を受ける会社では監査法人との合意が前提になる。エンジニア側の一存で決められる話ではない
• 管理会計の数字を人事評価へ直結させると、成果ではなく数字を作る行動が生まれる。まずは意思決定の材料として使う
• 精度よりも定義の一貫性が重要になる。売上原価の範囲や按分の基準を変えるなら、過去の数字も同じ定義で引き直す
• 配賦を細かくするほど納得感は下がる。配賦せずに済ませる設計を最初に検討する
• 財務会計の締めと管理会計の速報は数字がずれる。ずれること自体は問題ではないが、どちらの数字を見て話しているかは常に明示する

参考

• 国税庁 No.2100 減価償却のあらまし：償却の基本と償却方法
• 国税庁 No.5403 少額の減価償却資産になるかどうかの判定の例示：10万円と20万円の線引き
• 国税庁 No.5408 中小企業者等の少額減価償却資産の特例：30万円未満の特例と適用条件
• 企業会計基準委員会（ASBJ）：研究開発費等に係る会計基準など、日本基準の一次情報
• IAS 38 Intangible Assets：IFRSの無形資産。研究と開発の区別
• FASB Accounting Standards Codification：US GAAP。ASC 350-40 と ASC 985-20