ソフトウェアエンジニアリングマネージャーに「このプロジェクトはいつ『始まった』か」と尋ねれば、スプリント番号で答えが返ってくるだろう。同じ質問をコントローラー(経理責任者)にすれば、1998年以来、自社利用ソフトウェアを規律してきた会計ルールのもとでは、要件が固まるまで誰もコードを書かないという前提に立つ、硬直的な3段階のチェックリストから答えを導き出すことになっていた。この10年でソフトウェアをリリースした経験のある人なら誰でも、もはやそんな仕組みでは動いていないことを知っている——そして2025年9月、FASB(米国財務会計基準審議会)もついにそれを認めた。
会計基準更新書(ASU)2025-06『無形資産—のれんおよびその他—自社利用ソフトウェア(サブトピック350-40):自社利用ソフトウェアの会計処理に関する的を絞った改善』は、旧来の段階別テストを完全に廃止し、単一の判断ベースの問いに置き換える——このソフトウェアが実際に完成し、意図された機能を果たすことは「可能性が高い」か、という問いである。自社でソフトウェアを開発するあらゆる企業にとって、とりわけ旧ルールが想定していなかったアジャイル開発チームにとって、この変更は開発コストがいつ、どれだけ損益計算書から貸借対照表へ移るかを左右する。
問題点:ウォーターフォール開発のための1998年のルールブック
ASU 2025-06が置き換える旧ガイダンス、ASC 350-40(元はSOP 98-1)は、「ソフトウェア開発」が直線的なウォーターフォールプロセスを意味していた時代に書かれたものだ。旧ガイダンスは、あらゆる自社利用ソフトウェアプロジェクトを3つの連続した段階に分割していた。
- 予備プロジェクト段階(Preliminary project stage) — コンセプトの立案、代替案の評価、ベンダー選定。ここでの費用はすべて発生時に費用処理される。
- アプリケーション開発段階(Application development stage) — 実際のコーディング、構成設定、テスト。ここでのコストは資産化される。
- 導入後段階(Post-implementation stage) — トレーニングと保守。再び費用処理される。
このフレームワークは、あるチームが3か月かけて要件定義書を書き、承認を得てから開発を始める、というやり方であれば問題なく機能する。しかし、チームが2週間スプリントを回し、増分的にリリースを重ね、レトロスペクティブのたびにスコープを見直すようになった瞬間、このフレームワークは破綻する。アジャイル環境では、「予備」と「アプリケーション開発」は連続したフェーズではなく、時には同じスプリントの中で入り混じっている。企業とその監査人は、ある2週間のスプリントが実際にどの段階に属するのかを何年も議論してきたが、正直な答えはしばしば「両方の要素がある、推測するしかない」というものだった。FASB自身のアウトリーチ調査でも、これがGAAPの中で一貫した適用が最も実務上困難な部分の一つだと、関係者から繰り返し指摘されていたことが明らかになっている。
解決策:3段階ではなく単一のテストへ
ASU 2025-06は、旧来のプロジェクト段階への言及をすべて削除する。その代わりに、単一の**「完成の可能性が高い(probable-to-complete)」認識基準を設定する。新ガイダンスのもとでは、企業は以下の両方**が同時に成立した時点で、自社利用ソフトウェアのコストを資産化する。
- 経営陣がプロジェクトを承認し、資金提供にコミットしていること。 これは新しい概念ではなく、旧ガイダンスにも存在していた。しかし、段階分析の中に埋もれていたこの要件は、今や2つしかないゲーティング条件の一つとして、より重要な役割を果たすようになった。
- プロジェクトが完成し、そのソフトウェアが意図された機能を果たすために使用される可能性が高いこと。 これこそが真に新しい要素であり、判断が求められる部分である。
2つ目の要件では、重大な開発上の不確実性が依然として存在するかどうかを評価する必要がある。FASBは、その不確実性の主な発生源として2つを挙げている。
- 実証されていない技術や新規性の高い機能 — その実現可能性が、実際のコーディングとテストを通じてまだ証明されていないもの。設計文書や仕様書ではなく、実際に動くという証拠が必要である。
- 未定義、あるいは依然として変動しているパフォーマンス要件 — 基準ではこれを「企業がそのソフトウェアに何をさせる必要があるか、例えば機能や特徴」と定義している。チームがプロダクトに何をさせるべきかについて、依然として実質的な議論を続けているのであれば、その不確実性はまだ解消されていない。
実務上、これは資産化のタイミングが、暦上のフェーズではなく実現可能性の証拠に連動するようになったことを意味する。あるチームが技術的に新規性の高い機能について、本格的な開発にコミットする前に2スプリントかけてスパイク(探索的検証)を行った場合、そのスパイクのスプリントは費用処理される——そもそも構築できるかどうかという不確実性がまだ解消されていないからだ。スパイクによってその実現可能性が証明され、経営陣が本格開発への予算をコミットした時点で、「完成の可能性が高い」基準が満たされ、アジャイルの儀式がどうであれ、それ以降の開発コストは資産化される。
なぜFASBは資産化額が大きくは変わらないと言うのか——SaaSは例外
FASB自身の見立てでは、ほとんどのオンプレミス型またはライセンス型の自社利用ソフトウェアについては、今回の改正が資産化の結果を劇的に変えることはないという——企業は実際のコーディングが始まった時点で既に資産化を行っており、新しいテストもほぼ同じ結論に着地する。違いは、段階のラベル付け作業が不要になる点だけだ。
SaaSやクラウド形態で提供されるために開発されるソフトウェアは話が別だ。 FASBは、これらのプロジェクトについては資産化額が減少すると明確に見込んでいる。その理由はこうだ。SaaS製品は、その性質上、継続的に構築・再構築されるものであり、開発期間の後半に至るまで、時には機能のリリース直前まで、重大な技術的・プロダクト的な不確実性が残り続ける。「完成の可能性が高い」テストのもとでは、この持続する不確実性のために、多くのSaaS開発コストは、旧来の段階モデルが示唆していたよりもはるかに開発の後半になるまで、資産化の基準をクリアできないことになる。その結果、SaaS製品のエンジニアリング人件費のより多くの部分が、複数年にわたって償却される資産ではなく、当期のR&D費用として計上されることになる。これは、実際のコードが一行も変わらないうちから、SaaS企業が報告するEBITDAと資産規模にとって大きな変化となる。
具体例:2つのチーム、2つの結果
従業員40人のSaaS企業が、自社製品向けにAI駆動の予測モジュールを構築することを決めたとしよう。同じ8か月の開発プロジェクトを、旧ルールと新ルールがどのように異なる扱いをするかを見てみる。
旧来の段階モデルのもとでは、経理チームは線引きを試みる。最初の6週間の要件収集とベンダー評価は「予備」(費用処理)であり、キックオフミーティング以降のすべては「アプリケーション開発」(資産化)である——たとえエンジニアリングチームがその後2か月間、選択した予測手法が本番データ量で許容できる精度を達成できるかを見極めるための探索的スパイクに費やしていたとしても。旧ルールの文言に忠実に従えば、いったん「段階」が切り替わると、それらのスパイクスプリントもしばしば資産化されてしまう。なぜなら、形式的にはキックオフミーティング後に発生したものだからだ。
ASU 2025-06のもとでは、経理チームは代わりにこう問う。この機能が完成し、意図通りに機能することが、いつ「可能性が高い」状態になったのか、と。最初の2か月間、精度に関するアプローチがまだ実証されていなかった場合——チームが3つの異なるモデリング手法をテストしており、どれが基準をクリアするか分からなかった場合——その探索期間全体は、暦上どの「段階」に該当するかにかかわらず、費用処理される。資産化が始まるのは、チームが検証済みのアプローチを選び、経営陣がその構築に予算をコミットした時点であり、この例では2か月目ではなく3か月目かもしれない。結果として、資産化される資産は小さくなり、当期のR&D費用は大きくなる。そして重要なのは、その数字がCFOにとって監査で実際に弁護可能なものになるという点だ。なぜなら、それは事後的に貼られた段階ラベルではなく、具体的かつ文書化された意思決定の時点に紐づいているからだ。
これはまさに、FASBがSaaSセクター全体で見込んでいる変化そのものだ。「キックオフコールの後だったからアプリケーション開発と呼んだ」というやり方は減り、「技術的リスクが解消されたスプリントを具体的に示せる」というやり方が増えていく。
適用開始日と経過措置
ASU 2025-06は、2027年12月15日より後に開始する年次報告期間、およびその年度内の中間期間について、上場・非上場を問わずすべての事業体に適用される。基準が発行された時点で、どの事業体も、どの中間期間・年次期間においても早期適用が認められる。
事業体は、次の3つの経過措置アプローチのいずれかを用いて改正を適用できる。適用開始日以降に発生した新規のソフトウェアコストのみに将来に向かって適用する方法、適用年度の期首以降に発生したコストに将来に向かって適用する方法、または表示されるすべての期間に遡及適用する方法である。この柔軟性は重要だ——ルールが発効した時点で大規模なプラットフォームの書き直しを進めている最中の企業も、遡及適用を選ばない限り、何年分もの資産化コストの履歴を巻き戻す必要はない。
中小規模のソフトウェア企業が今すぐすべきこと
2027年12月というと遠い先のように聞こえるが、実務上の準備作業は最終四半期になってから片付けられるようなタスクではない。特に、専任のテクニカル・アカウンティング機能を持たない、少人数の経理チームで運営している企業にとってはなおさらだ。
「完成の可能性が高い」という判断は、事後ではなくリアルタイムで記録し始めること。 旧来の段階モデルは機械的で、数か月後でもスプリントの日付からプロジェクトがどの段階にあったかを再構築できた。新しいテストが問うのはいつ技術的な不確実性がなくなったかであり、これは事後に再構築するのがはるかに難しい判断である。今のうちに軽量な習慣を作っておこう。エンジニアリングのリーダーシップと経理が、ある機能が技術的スパイクをクリアし、構築にコミットしたと合意した時点で、その日付を記録するのだ。その記録が、資産化開始日となり、監査の裏付けとなる。
まだ行っていなければ、工数管理やプロジェクトコード上で「探索」作業と「コミット済みの構築」作業を分けること。 Jiraのエピックフラグでも、独立したコストセンターコードでも、あるいは工数管理ツール上のタグ付きラベルでも構わない。ある機能がスパイク/プロトタイプの段階からコミット済みの開発へと移行した時期について、明確なデータの痕跡を残しておけば、監査中に記憶を頼りに再構築しようとするよりも、新基準の適用がはるかに楽になる。
どちらか一方を選ぶ前に、両方の経過措置オプションを試算すること。 もし貴社が旧来の段階フレームワークのもとでSaaS開発コストを積極的に資産化してきたのであれば、遡及適用によって、それらのコストがあたかも最初から費用処理されていたかのように再分類され、既存の資産化資産について一時的な評価減が発生する可能性がある。将来に向かって適用するアプローチであればその修正再表示は避けられるが、その代わり、適用後に新規プロジェクトが始まるまで、損益計算書には新しい方法論が反映されない。監査委員会がその判断を迫られる前に、両方のパターンで数字を試算しておこう。
早めに監査人と話し合うこと。特にSaaS企業であればなおさらだ。 FASB自身がSaaS開発について資産化額の減少を見込んでいることを踏まえると、監査人は、旧ルールのもとでの段階分類よりも、「完成の可能性が高い」という判断をより厳しく精査する可能性が高い——まさにそれがより主観的な判断だからだ。その判断を下すための、文書化されたリアルタイムのフレームワークを携えて2028年の監査に臨む企業は、事後にそれを再構築しようとする企業よりも、はるかに楽な対話ができるだろう。
クリーンな帳簿があれば、判断の根拠を示しやすくなる
あらゆる会計上の判断——そして「完成の可能性が高い」は紛れもなく判断である——は、その裏付けとなる記録の質によってしか正当化できない。もし貴社の勘定科目体系が既にR&D支出をプロジェクト別に分離しており、台帳の記帳がバージョン管理され、監査可能な状態にあり、バラバラのスプレッドシートに散らばっていないのであれば、ASU 2025-06のような基準の適用は、Slackのスレッドから履歴を再構築する作業ではなく、既存データにタグを付ける作業になる。Beancount.ioのプレーンテキスト会計は、そうした透明でGitバージョン管理された台帳をデフォルトで提供する——あらゆる記帳が追跡可能で、あらゆる変更がレビュー可能、ベンダーロックインもない。無料で始める そして、監査人からでも、買収者からでも、次のFASB改定からでも、どんな問いにも耐えうる帳簿を築こう。