概要
研究段階の支出は資産計上できない
PoC・技術検証は「将来の収益獲得又は費用削減が確実」とまだ言えない研究段階の支出であり、実務指針上は発生時に費用処理する。
破棄された設計は経済的便益を生まない
要件変更で使われなくなった制作費は資産性を失う。そのままB/Sに残すと将来の一括減損リスクを積み上げる。
機能維持と機能追加は会計処理が違う
バグ修正のような機能維持のための費用は資産計上できない。資産計上できるのは新機能の追加・機能改良のみ。
「利益が良く見える」は判断根拠にならない
資産計上の可否は客観的要件で判定する。償却年数も実務指針・税務の原則（5年以内）に照らして設定する。
問題
ECサイト MOps 販促システムチームで、会員向け「誕生日クーポン自動配布バッチ」機能を3ヶ月かけて内製開発し、先月リリースした。経理部から「今期の費用計上について確認したい、ソフトウェア資産として計上できる金額を教えてほしい」と依頼があり、後輩PdM見習いが Bad 会計処理メモを作成し、そのまま経理へ提出しようとしている。
あなたはMOpsチームのシニアエンジニア（証券会社出身で財務諸表の読解に明るい）として、このBadメモをレビューし、実際に経理・監査が検証に使えるレベルへ再設計することになった。以下のメモには 7つの問題点が潜んでいる。問題点を全て洗い出し、Good 会計処理メモへ再設計してください。
制約・前提条件（正）
- エンジニア単価: 80万円/月（160時間=20人日 → 1人日=4万円）
- プロジェクト工数内訳（実績、合計120人日）: PoC・技術検証（配信基盤の実現可能性検証、研究段階）20人日 / 要件定義・基本設計25人日（うち10人日は法務レビューで要件が大幅変更となり当初設計が丸ごと破棄され現行仕様に一切使われていない）/ 開発・実装40人日 / テスト・QA15人日 / リリース後バグ修正（既存機能の不具合対応のみ、新機能追加なし）10人日 / 間接費按分（マネージャーレビュー5人日＋共通基盤チームサポート5人日を一律按分、いずれも各自の所属部門で人件費計上済み）10人日
- 会計基準の要点: 「研究開発費等に係る会計基準」（企業会計審議会）により研究開発費は発生時に費用処理する。「研究開発費及びソフトウェアの会計処理に関する実務指針」（会計制度委員会報告第12号、日本公認会計士協会）により、自社利用のソフトウェアは将来の収益獲得又は費用削減が確実であると認められる場合にのみ資産計上し、それ以外は費用処理する。資産計上後は原則として利用可能期間（通常5年以内）で定額法により償却する
- 税務上の耐用年数: 法人税法上、自社利用のソフトウェアの耐用年数は原則5年（無形減価償却資産の耐用年数表）
- 後輩メモは、研究段階のコスト・破棄された設計・機能維持のための保守費用・重複する間接費按分のいずれも資産計上対象から除外しておらず、償却年数の根拠も資産計上の判断根拠も示していない
期待する回答形式: 問題点の列挙（番号付き） + フェーズ別コスト分解表（資産計上対象／費用処理対象の仕分け） + 資産計上額とP/L影響試算（Bad版とGood版の当期費用比較） + 5年間の累計費用化スケジュール比較表 + 減損リスクの説明 + 経理への説明文
悪い会計処理メモ (Before)
このメモには 7つの問題 が隠れています。見つけてみてください。
Bad メモ — 全額資産計上・10年償却・利益調整が動機
件名: 誕生日クーポン自動配布バッチ 開発費用の会計処理について
プロジェクト全体（PoC・技術検証〜要件定義〜開発〜テスト〜
リリース後の保守3ヶ月分まで）の工数は合計120人日でした。
このすべてをソフトウェア資産として計上したいと考えています。
← 問題①②③④: 研究段階・破棄済み設計・保守費用・間接費按分
を区別せず一括で資産計上対象にしている
資産計上額 = 120人日 × 4万円/人日 = 480万円
償却年数: 10年（長く使うシステムなので余裕を見て設定）
← 問題⑤: 実務指針・税務の原則(5年以内)から逸脱、根拠なし
年間償却費 = 480万円 ÷ 10年 = 48万円/年
資産計上すれば当期の費用計上は48万円だけで済み、
今期の利益が良く見えるので、この処理で進めたいです。
← 問題⑥⑦: 判断根拠が利益調整のみ、フェーズ別内訳もなし問題点サマリー（7点）
1研究段階(PoC・技術検証20人日)を資産計上対象に含めている
2要件変更で破棄された設計(10人日)を資産計上したままにしている
3機能維持のためのバグ修正(10人日)を資産計上に含めている
4直接attributableでない間接費按分(10人日)を資産原価に含め二重計上している
5償却年数を根拠なく10年に設定し、実務指針・税務の原則(5年以内)から逸脱している
6「利益が良く見える」ことが資産計上の判断根拠になっている
7フェーズ別内訳が一切示されず監査が検証できる根拠資料になっていない
ヒント（段階的開示）
ヒント1 — 方向性
Badメモの罠は3系統。(1) 研究段階と開発段階を区別していない——PoC・技術検証は「将来の収益獲得又は費用削減が確実」とまだ言えない研究段階の支出であり、実務指針上は発生時に費用処理すべきだが、Badメモはこれも資産計上対象に含めている。(2) 「資産計上できる費用」の範囲を誤解している——機能維持のためのバグ修正費用、経済的便益をもたらさなくなった破棄済み設計、直接attributableでない間接費按分は、いずれも資産計上できないにもかかわらず一律で合算されている。(3) 判断の動機が会計基準ではなく利益調整になっている——「資産計上すれば今期の利益が良く見える」という理由だけで処理方法を選んでおり、客観的な要件（将来の収益獲得又は費用削減の確実性）を検討していない。加えて償却年数10年にも根拠がなく、実務指針・税務双方が原則とする5年以内から逸脱している。
ヒント2 — アプローチ
- 問題①: PoC・技術検証（研究段階、20人日）を資産計上対象に含めている → 研究開発費として発生時に費用処理する
- 問題②: 要件変更で破棄された設計（10人日）も資産計上したままにしている → 経済的便益をもたらさなくなった制作費は資産計上せず費用処理する
- 問題③: リリース後のバグ修正（機能維持、10人日）を資産計上に含めている → 機能維持のための費用は資産計上できず、資産計上できるのは新機能追加・機能改良のみ
- 問題④: 直接プロジェクトに専従していないメンバーの間接費按分（10人日）を資産原価に含めている → 各部門で既に人件費計上済みのコストを重複してプロジェクト原価に付け替えている
- 問題⑤: 償却年数を根拠なく10年に設定している → 実務指針・税務ともに自社利用ソフトウェアは原則5年以内で償却する
- 問題⑥: 「資産計上すれば利益が良く見える」ことが判断根拠になっている → 将来の収益獲得又は費用削減の確実性という客観的要件で判定すべき
- 問題⑦: フェーズ別の内訳が一切示されておらず、経理・監査が後から検証できる根拠資料になっていない
ヒント3 — 誘導
【フェーズ分解】
資産計上対象 = 要件定義・設計(有効分) + 開発・実装 + テスト・QA
= (25-10)人日 + 40人日 + 15人日 = 70人日
資産計上額 = 70人日 × 4万円 = 280万円
費用処理対象(即時) = PoC・技術検証 + 破棄された設計 + リリース後バグ修正
= 20人日 + 10人日 + 10人日 = 40人日
当期費用処理額 = 40人日 × 4万円 = 160万円
間接費按分(10人日)は資産原価にもプロジェクト費用にも含めない(重複計上回避)
【償却】
年間償却費 = 280万円 ÷ 5年 = 56万円/年
【初年度P/L影響】
Bad版: 48万円(480万円 ÷ 10年)のみ
Good版: 160万円(即時費用) + 56万円(初年度償却) = 216万円
差額 = 216 − 48 = 168万円 → Bad版は初年度利益を168万円分過大表示問題点分析（7点）
| # | 問題点 | 分類 | 改善方法 |
|---|---|---|---|
| 1 | 研究段階(PoC20人日)を資産計上対象に含める | 資産性なし | 研究開発費として発生時費用処理 |
| 2 | 破棄された設計(10人日)を資産計上したまま | 資産性なし | 経済的便益喪失分は費用処理 |
| 3 | 機能維持のバグ修正(10人日)を資産計上 | 資産性なし | 機能維持費用は発生時費用処理 |
| 4 | 直接attributableでない間接費按分を資産原価に含める | 二重計上 | 各部門計上済みのためプロジェクト原価から除外 |
| 5 | 償却年数10年に根拠がない | 期間設定 | 実務指針・税務の原則(5年以内)に修正 |
| 6 | 利益が良く見えることが資産計上の動機 | 意思決定 | 将来の収益獲得又は費用削減の確実性で判定 |
| 7 | フェーズ別内訳が不在で監査に耐えない | 文書化不足 | フェーズ別コスト分解表を根拠資料化 |
資産計上フロー図 — Bad（全額資産計上）vs Good（フェーズ分解）
模範解答
修正①②③④: フェーズ別コスト分解表（資産計上対象／費用処理対象）
| フェーズ | 工数 | 会計処理 | 根拠 |
|---|---|---|---|
| PoC・技術検証 | 20人日 | 費用処理（研究開発費） | 将来の収益獲得又は費用削減が確実とまだ言えない研究段階 |
| 要件定義・基本設計（有効分） | 15人日（25−10） | 資産計上対象 | 現行仕様に使われており確実性がある |
| 要件定義・基本設計（破棄分） | 10人日 | 費用処理 | 要件変更、経済的便益をもたらさない |
| 開発・実装 | 40人日 | 資産計上対象 | 新機能の実現に直接attributable |
| テスト・QA | 15人日 | 資産計上対象 | 完成に必須の直接attributableな工程 |
| リリース後バグ修正 | 10人日 | 費用処理 | 機能維持のための費用 |
| 間接費按分 | 10人日 | 計上対象外（除外） | 各部門で計上済み、直接attributableでない |
| 合計 | 120人日 | ||
資産計上額 = (15+40+15)人日 × 4万円 = 280万円 / 当期費用処理額 = (20+10+10)人日 × 4万円 = 160万円（間接費按分10人日はプロジェクト原価から除外し、各所属部門の既存費用として扱う）
修正⑤⑥: 資産計上額とP/L影響試算（Bad版 vs Good版）
| 項目 | Bad版 | Good版 |
|---|---|---|
| 資産計上額 | 480万円（120人日全額） | 280万円（70人日のみ） |
| 償却年数 | 10年（根拠なし） | 5年（実務指針・税務上の原則） |
| 年間償却費 | 48万円 | 56万円 |
| 当期即時費用処理額 | 0円 | 160万円（研究段階+破棄分+バグ修正） |
| 初年度の費用計上額（合計） | 48万円 | 216万円 |
差額168万円——Bad版は初年度利益をこの分だけ過大表示している。120人日すべてを資産化し償却期間も引き延ばすことで初年度費用をわずか48万円に圧縮しているが、このうち160万円分（研究段階・破棄済み設計・保守費用）はそもそも実務指針上の資産計上要件を満たしておらず、資産計上すべきでない支出を資産として先送りしているに過ぎない。
5年間の累計費用化スケジュール比較
| Year | Bad版（10年償却、年48万円） | Good版（即時160万円＋5年償却、年56万円） |
|---|---|---|
| 1 | 48万円 | 160+56 = 216万円 |
| 2 | 48万円 | 56万円 |
| 3 | 48万円 | 56万円 |
| 4 | 48万円 | 56万円 |
| 5 | 48万円 | 56万円 |
| 5年累計 | 240万円 | 440万円（=160+280、全額費用化完了） |
| 5年後のB/S残存簿価 | 240万円（480−240、資産として残存） | 0円（280万円は5年で償却完了） |
Good版は5年で実際に価値を生んだ70人日分の資産（280万円）を完全に償却し終える一方、Bad版は5年経過後も240万円がソフトウェア資産としてB/Sに残り続ける。この残存簿価には、本来資産計上要件を満たさない研究段階・破棄済み設計・間接費按分の支出が事実上まだ混入したままであり、実態を反映していない「見せかけの資産」がB/S上に居座り続けることになる。
減損リスクの説明
特に問題なのは、要件変更で破棄された設計（10人日=40万円相当）が、Bad版では資産としてそのまま計上され続けている点である。この部分は既に現行仕様で使われておらず経済的便益を生まないため、本来は発生時に費用処理すべきだった。仮にこのままB/Sに残り続け、後から監査や決算レビューでその事実が発覚すれば、当該部分について減損損失として一括計上する必要が生じる。日常的に発生時費用処理を積み重ねる代わりに、発覚したタイミングで一度に損失を認識することになり、決算での説明対応コストも発生する。Good版のように資産性のない支出を都度費用処理していれば、このリスクは発生しない。
経理への説明文
誕生日クーポン自動配布バッチの開発費用（合計120人日）に
ついて、実務指針（研究開発費及びソフトウェアの会計処理に
関する実務指針）に基づき仕分けを行いました。研究段階の
PoC・技術検証（20人日）、開発中の要件変更で破棄された
設計（10人日）、リリース後の機能維持のためのバグ修正
（10人日）は、いずれも「将来の収益獲得又は費用削減が
確実」という資産計上要件を満たさないため費用処理とし、
当期に160万円を計上します。
実際に現行仕様として利用されている要件定義・開発・テスト
の70人日分のみを資産計上対象とし、資産計上額は280万円
です。償却年数は実務指針・法人税法双方の原則である5年
（定額法）とし、年間償却費56万円で計上します。
当初案（全額資産計上・10年償却）は初年度の費用計上を
48万円に圧縮できますが、資産性のない支出160万円分を
資産として先送りするものであり、将来の減損リスクを
抱えます。今回の仕分けにより、当期の費用計上は216万円
となりますが、会計基準の要件に沿った、監査に耐える処理
になります。ポイント解説
1ソフトウェア資産計上の核心は「工数がいくらかかったか」ではなく「将来の収益獲得又は費用削減が確実か」である — 研究段階の支出は、いくら工数をかけていても資産計上できない。
2機能維持のための費用（バグ修正）と、機能追加・機能改良のための費用（新機能開発）は会計処理が異なる — 資産計上できるのは後者のみであり、リリース後の保守費用を無条件に資産化してはならない。
3経済的便益をもたらさなくなった制作費は、資産計上せず費用処理（または既に資産計上済みなら減損処理）する — 要件変更で破棄された設計は、その時点で資産性を失っている。
4資産計上できるのは直接attributableな費用のみであり、間接費按分の重複計上に注意する — 各部門で既に人件費計上済みのコストをプロジェクト原価に付け替えると二重計上になる。
5償却期間は実務指針・税務双方の原則（自社利用ソフトウェアは通常5年以内）に照らして設定する — 恣意的に長期化すると各期の費用負担を過小表示し、実態と乖離したB/Sを作り出す。
6「利益が良く見えるから」は会計処理を選ぶ理由にならない — 資産計上の可否は客観的要件で判定し、その判断根拠をフェーズ別に文書化して監査に耐える形にする。
実務への応用
MOpsチームでは今後も内製開発のたびに同様の資本化判定が発生する。CFO・経理から「この開発費は資産計上できるか」という問い合わせが都度来るため、プロジェクトのタイムトラッキングをフェーズ（PoC・要件定義・開発・テスト・保守）で区別して記録しておくことが、後から正確な資産計上額を算定するための前提条件になる。特に、開発中の要件変更で一部の設計が破棄されるケースはMOpsのようなキャンペーン系機能では頻繁に起こるため、「破棄された工数を資産計上対象から除外する」というチェックをリリースのたびに行う運用ルールにしておくとよい。
証券会社経験との接続: 上場企業の有価証券報告書をレビューする際、無形固定資産（ソフトウェア）の増減明細を見る機会があったが、資産計上基準を甘く運用している会社ほど、数年後に一括で多額の減損損失を計上し株価に影響を与えるケースが見られた。今回のBad版のように「資産計上すれば今期の利益が良く見える」という動機で処理を歪めることは、将来の減損という形で必ず跳ね返ってくる。エンジニアとしても、今の開発費用の仕分け判断が数年後の財務諸表にどう表れるかを意識する必要がある。
今日のまとめ
内製ソフトウェア開発費の資産計上は「いくら工数がかかったか」ではなく「その費用が将来の収益獲得又は費用削減を確実にもたらすか」で判定する。研究段階の支出・要件変更で破棄された設計・機能維持のための保守費用・重複する間接費按分は、いずれも資産計上の対象外である。これらを一律に合算して資産計上し、償却期間を根拠なく引き延ばすと、当期利益を過大表示するだけでなく、資産性のない支出をB/S上に「見せかけの資産」として先送りし、将来の一括減損というリスクを積み上げることになる。
次のステップ
- 発展問題: リリース1年後、誕生日クーポン自動配布バッチの一部機能（配信対象を絞り込むセグメント判定ロジック、資産計上額280万円のうち開発工数換算で15人日=60万円相当）が、事業方針の変更により使われなくなり、別のロジックに置き換えられることになったとする。このとき、(1) 残存簿価のうちいくらを減損損失として計上すべきか、(2) 減損の兆候をどのタイミングで認識すべきだったか、(3) 今後同様の事態を早期発見するために、開発チームと経理がどのような連携プロセスを設計すべきか、の3点を踏まえた提案をせよ。
- 参考: 研究開発費等に係る会計基準（企業会計審議会）、研究開発費及びソフトウェアの会計処理に関する実務指針（会計制度委員会報告第12号、日本公認会計士協会）、法人税法上の無形減価償却資産の耐用年数、固定資産の減損に係る会計基準