アジャイル型ソフトウェア開発契約と収益認識についての考察
一時点で認識すべき収益か、一定の期間にわたって認識すべき収益か。
個人的収益認識会計基準で特に迷いやすいものランキング第1位のこのテーマ、いろいろ考えたものをメモしておく。
従前は受注制作ソフトウェアの契約や会計処理に悩むことは少なかった
受注制作のソフトウェア開発は成果物であるソフトウェアの開発と引渡しを目的とする請負契約が主流であった。
このパターンにおいては、
①ソフトウェアの開発と引渡し
②引渡し後の保守・運用の受託
③運用開始後のソフトウェアの追加開発・改修
というフェーズが明確であり、契約もこれらの単位で結ぶことが多かった。
ソフトウェア業界の契約慣習として請負契約か準委任契約かを区別することに敏感であることから、①③はソフトウェアの完成を目的とするから請負契約、②はそうでないから準委任契約、とほぼ無思考で考えればよかった。
収益の認識という点においては、「工事契約に関する会計基準」に従って、目的物の引渡し（実務上は検収書類の受領）による計上（工事完成基準）を基本に、規模の大きな開発においては工事進行基準を適用し、一定期間にわたって（原価比例法などで）収益を計上することが通常であった。
4. 本会計基準は、工事契約に関して、施工者における工事収益及び工事原価の会計処 理並びに開示に適用される。 本会計基準において「工事契約」とは、仕事の完成に対して対価が支払われる請負契約のうち、土木、建築、造船や一定の機械装置の製造等、基本的な仕様や作業内容 を顧客の指図に基づいて行うものをいう。
5. 受注制作のソフトウェアについても、前項の工事契約に準じて本会計基準を適用する。
ところで工事会計基準が「『「工事契約』とは仕事の完成に対して対価が支払われる請負契約のうち、土木、建築、造船や一定の機械装置の製造等、基本的な仕様や作業内容を顧客の指図に基づいて行うものをいう」（4項）としていたのは、請負契約には無形の仕事の完成（例えば貨物運送）も含まれていたため、建築物、造船、ソフトウェアなど目的物を限定することを意図したものである。
この定義自体は民法のそれと変わるところはない。
（請負）
第六百三十二条 請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。
（報酬の支払時期）
第六百三十三条 報酬は、仕事の目的物の引渡しと同時に、支払わなければならない。ただし、物の引渡しを要しないときは、第六百二十四条第一項の規定を準用する。
このように工事会計基準は、民法の定めと大きく違わず、かつ実務上定着していた契約慣行を基礎に会計処理を定めていた。
しかも請負契約は「仕事の完成・引渡し」と「対価の支払い」が対価関係にあることが明確であるので、目的物の引渡しという現実の事象を基準に処理をすることが明瞭なのである。
すなわち、
「開発・改修」＝「請負契約」＝「引渡し時収益計上」（原則）
「保守」＝「準委任契約」＝「一定期間か特定のイベントごとか、契約書の定めにのっとり収益計上」
という、法と会計の盲目的な取り扱いができた。
むしろソフトウェア業界においては目的物が目に見えないがために循環取引のような架空取引こそが問題視されていたように思う。
請負契約でないソフトウェア開発の登場
しかし昨今は、契約締結時に仕様や完成時点を定義することが難しい（あえてしない）開発手法と契約類型がみられるようになってきた。
代表的なものがアジャイル開発である。
本来的な意味でのアジャイル開発においては、ソフトウェアの開発と評価を短期間で繰り返す。さらに「開発→完成→リリース・運用」という明確な区切りをもうけず、「完成したものからリリースし、劣後していた開発分を追加でリリース、リリース済みの分は運用して発見された問題を改善していく」など、「開発工程、運用工程」のような明確な区切りがない。
それゆえ、従来のような開発フェーズ＝開発契約、運用フェーズ＝運用・保守契約、という明確な区切りがつけにくい。
さらにプロジェクトのなかで、実装すべき要件の追加・優先順位変更を行うので、契約時に基本的な仕様すら確定できない。そのため契約仕様どおりの目的物の完成を約束する請負契約が馴染まない。
それゆえ、IPAのモデル契約ではアジャイル開発契約は「ベンダ企業が専門家として業務を遂行すること自体に対価を支払う準委任契約を前提」であるとした。
履行割合型準委任契約に基づくアジャイル開発の収益認識
IPAのアジャイル開発モデル契約は履行割合型準委任契約
IPAのモデル契約において示された報酬設計は「人員の単価と稼働時間により算定する」というものである。
これはエンジニアの役務提供を対価関係とした履行割合型準委任契約を前提としているからである。
一定の期間にわたり充足される履行義務かどうかの判定
これからすれば、履行義務は「役務の提供」であり、一定の期間にわたり充足されるものとして処理することが考えられるので、基準と照らし合わせることになる。
（一定の期間にわたり充足される履行義務）
38. 次の(1)から(3)の要件のいずれかを満たす場合、資産に対する支配を顧客に一定の期間 にわたり移転することにより、一定の期間にわたり履行義務を充足し収益を認識する（適 用指針[設例 7]）。
(1) 企業が顧客との契約における義務を履行するにつれて、顧客が便益を享受すること
(2) 企業が顧客との契約における義務を履行することにより、資産が生じる又は資産の 価値が増加し、当該資産が生じる又は当該資産の価値が増加するにつれて、顧客が当該資産を支配すること（適用指針[設例 4]）
(3) 次の要件のいずれも満たすこと（適用指針[設例 8]）
① 企業が顧客との契約における義務を履行することにより、別の用途に転用する ことができない資産が生じること
② 企業が顧客との契約における義務の履行を完了した部分について、対価を収受する強制力のある権利を有していること
(1)について、義務を履行する（契約に基づく業務を進める）につれて、ユーザが便益を享受するとは言い切れない。なぜならアジャイルとはいえある程度のソフトウェアが出来上がる必要があり、かつ引渡しかリリースの承認を得て初めて意味があるので、単に履行を進めることがユーザが便益を享受するとはいえない。
(2)について、ユーザの環境で稼働しているソフトウェアの改修などであれば、履行により資産の発生や価値が増加しているといえる余地がないか、適用指針設例4では顧客の土地上における建物の建設工事をあげているので、これにあてはめられそうにも考えられる。しかし、設例はなぜこれが顧客が支配しているとするのかの理由が示されていない。
「支配」の意義について、収益認識会計基準は以下のように定義している。
37. 資産に対する支配とは、当該資産の使用を指図し、当該資産からの残りの便益のほとんどすべてを享受する能力（他の企業が資産の使用を指図して資産から便益を享受することを妨げる能力を含む。）をいう。
この点、建築途中の請負目的物については、引渡しがなされるまで全部または主要部分の材料を提供した者に原始的に帰属するのが通説・判例である（注文者の土地に建物を検知した場合においても。大判昭和3年12月26日など）。
これからすれば、設例のケースではいまだ注文者は所有権を得ておらず、したがって支配を獲得しているとはいえないはずなのである。
これらの点や、事実上撤去が困難である建物と違い、消去が容易なソフトウェアが果たして同列に扱えるであろうか、個人的には疑念がぬぐえないため、(2)を適用するのは困難であると考える。
最後に(3)。
①についてはユーザ固有のニーズに基づいたものであることがほとんどであろうから、ほぼ満たすと考えられる。
②については微妙な問題である。IPAのモデル契約においては「人月」が対価関係にあり、直接はソフトウェアと対価関係にない。また、ソフトウェアの引渡しができなくとも、一応は報酬請求権が発生するようになっている（引渡しが一切できなければ善管注意義務違反を問われるであろうが）。
この点、履行割合型準委任契約の報酬に関する民法648条3項を根拠にすれば、例え契約が中途で終了したとしても、既にした履行の割合に応じて報酬を請求することができるため、「履行を完了した部分について、対価を収受する強制力のある権利を有している」を満たすことができると考えられる。
（受任者の報酬）
第六百四十八条 受任者は、特約がなければ、委任者に対して報酬を請求することができない。
２ 受任者は、報酬を受けるべき場合には、委任事務を履行した後でなければ、これを請求することができない。ただし、期間によって報酬を定めたときは、第六百二十四条第二項の規定を準用する。
３ 受任者は、次に掲げる場合には、既にした履行の割合に応じて報酬を請求することができる。
一 委任者の責めに帰することができない事由によって委任事務の履行をすることができなくなったとき。
二 委任が履行の中途で終了したとき。
よって履行割合型準委任契約のアジャイル開発は、一定の期間にわたって収益が計上する第一ハードルは超えられそうである。
第二ハードル「進捗度の見積り」
第二ハードルとして、一定の期間にわたって収益が計上するには「履行義務の充足に係る進捗度の見積り」ができないといけない（基準41項、44項）。
見積もることができないときは、救済的に「当該履行義務を充足する際に発生する費用を回収することが見込まれる場合には、履行義務の充足に係る進捗度を合理的に見積ることができる時まで、一定の期間にわたり充足される履行義務につい て原価回収基準により処理する」（基準45項）
人月単価での報酬設計で、かつ民法648条が適用できる状況であるならば、45項の費用回収見込みを満たすことができると考えられるため、進捗度が見積もれなくとも原価回収基準に基づき計上することができる。
工数の記録が原価の算定と報酬の算定の両方に用いるため、この点も実務上の困難は少ないと考えられる。
以上から、人月単価による報酬設計の履行割合型準委任契約でのアジャイル開発は、一定の期間にわたり収益を認識でき、進捗度か発生原価に基づく収益額を計上することになろう。
契約書の締結が遅れた場合（先行着手）は？
往々にしてユーザとの契約書締結が遅れることがある。
このケースはアジャイルに限らず、すべての契約において影響がありうるテーマである。
原則として、契約の成立は口頭でも成り立ち、合意のない事項は民法商法その他の法律による。
そして収益認識会計基準も、口頭などにより契約を承認し、約束していることを認めている。
19. 本会計基準を適用するにあたっては、次の(1)から(5)の要件のすべてを満たす顧客との 契約を識別する。
(1) 当事者が、書面、口頭、取引慣行等により契約を承認し、それぞれの義務の履行を約束していること
(2) 移転される財又はサービスに関する各当事者の権利を識別できること
(3) 移転される財又はサービスの支払条件を識別できること
(4) 契約に経済的実質があること（すなわち、契約の結果として、企業の将来キャッシ ュ・フローのリスク、時期又は金額が変動すると見込まれること）
(5) 顧客に移転する財又はサービスと交換に企業が権利を得ることとなる対価を回収する可能性が高いこと
当該対価を回収する可能性の評価にあたっては、対価の支払期限到来時における顧客が支払う意思と能力を考慮する（適用指針[設例 2]）。
したがって契約書の締結がなされていないからといって、ただちに収益・原価の計上ができないということではない。
しかし契約書による明文の合意事項がない限り、履行義務の識別などに困難が伴い、かつ場合によっては契約の成立自体が否定される可能性はある（ユーザ・ベンダの間で上層部の決裁が必要であることは前提になっていたこと、契約書の文言修正作業が行われている段階で、確定していなかったこと、ユーザ企業は契約書締結前に作業を行うことを求めたわけではないこと、などを理由に、契約は成立していないと認定した東京地判平20年9月30日など）。
保守的に考えるならば、特に19項(5)に疑義があるとして、契約書の締結ができていない時点での収益認識は避けるべきとなるだろう。
契約書以外の資料から、業務内容が明確に合意されており、内示書の交付などが行われているならば、契約書が締結されていないとはいえ収益の認識を始めることは考えられる。
外注や調達原価の発生が先行してしまっている場合は？
現実にはアジャイル開発の遂行に外注を用いる場合、外注先への対価の支払いもまた業務の進捗、人月、または月額固定額に設定していると思われるので可能性は低いが、外注費と必要機材の調達経費を契約当初に一括で多額の支払いをしてしまっている場合は、報酬はあくまでも投入人月により生じるため、原価の発生額が見込み報酬額を上回ってしまう事態になる。
この場合は費用の回収が見込めるとは言えないため、原価回収基準によることができないと考えられる。
したがって進捗度を合理的に見積もることができる時または費用を回収することが見込まれる時（累積の報酬額が発生原価額に達した時などであろうか）まで、収益を計上しないことになる。
人月単位での報酬設計でないアジャイル開発の場合は？
では、「アジャイル開発」と言いながら報酬については「契約前見積額に基づく金額を引渡し時一括支払い」のような請負的な報酬設定にしている場合はどのように考えるべきであろうか。
契約の類型
契約の本旨として、特定仕様のソフトウェアの完成を約束するものではないから準委任契約である。
そのうえで、報酬の定めに関しては成果報酬型である、成果報酬型準委任契約と解す可能性がある。
（成果等に対する報酬）
第六百四十八条の二 委任事務の履行により得られる成果に対して報酬を支払うことを約した場合において、その成果が引渡しを要するときは、報酬は、その成果の引渡しと同時に、支払わなければならない。
２ 第六百三十四条の規定は、委任事務の履行により得られる成果に対して報酬を支払うことを約した場合について準用する。
この場合、民法648条の2にいう「成果」がなんであると規定・解釈されるかが問題になる。
本来的なアジャイル開発であれば、複数のソフトウェアの漸次的リリースと運用・保守が伴うはずである。したがって「成果」としてどの部分を取り上げるかの解釈に困難を伴う。
また例えば、見積時にA、B、Cのモジュールや機能（仕様は明確でない）の開発を予定し、固定報酬の契約をしたとする。
仮にCのリリースができなかったとしたとしても、契約時の固定報酬が支払われるなら、成果に対して報酬を支払うとは言えない可能性がある。
無理に解釈するならば、「A、B、Cを見込んでいるがいずれか１つでもリリースすることができれば成果をなしたとして一定額の報酬を支払うことを約した」とすることもできるが、合理的な意思解釈としては難しいと思われる。
したがって、「Aをリリースできれば●万円、Bをリリースできれば●万円…」のような定めがない限り、「契約期間において、固定報酬に基づき役務を提供することを約した契約であって、報酬については期間満了時に支払時期を設けた履行割合型準委任契約」と捉えるのが合理的であろう。
収益の認識
収益の認識については、上記のとおり履行割合型準委任契約として一定の期間にわたり認識することになると考えられる。
ところで、上記のとおり報酬の支払いが契約期間満了を条件としているため、契約資産を認識すべきであろうか。
以前のnoteでも書いたとおり、収益認識会計基準における契約資産の定義自体に腑に落ちなさはあるが、定義的には「時の経過以外の条件」が必要になる。
今回のケースでは、例えば4月1日から6月30日を契約期間とする契約で、期間満了時に（人月報酬であろうと固定報酬であろうと）支払うことと取り決めていた場合、4月分の報酬は、5月以降の時点においては確定しており、あとは契約期間満了を待つのみである。
したがってこれは「時の経過を条件とする」ため、契約資産ではなく債権として月次処理としては売掛金を計上すればよいのではないか。
蛇足①アジャイル開発モデル契約のジレンマ
アジャイル開発のモデル契約の登場が、ソフトウェア業界の契約慣行に１つの歪みを生んだ。
最初に述べたように、準委任契約とはもっぱら保守・運用の受託契約に用いられた。
それゆえ「準委任契約ではソフトウェアの開発は伴わない」という誤った認識が一部で広まってしまった。
またSES契約のように、準委任契約が用いられるのは「エンジニアの労務提供が目的であり、特定のソフトウェアを完成することを約束するものではない」というベンダの説明から、多額の投資を伴うソフトウェア開発の発注者からすると準委任契約でのソフトウェア開発はあり得ない、という拒否感を覚える、請負至上主義ともいうべきものを露見させた。
アジャイルソフトウェア開発宣言には「契約交渉よりも顧客との協調を」とあるのに、アジャイル開発への理解とソフトウェア開発契約への無理解が相まって契約交渉が難航するケースがあるのは皮肉である。
蛇足②完成と引渡しは違う
建築請負契約やソフトウェア開発請負契約に関する裁判例では、「完成」とは「予定された最後の工程まで終了したこと」であるというのが通説である。
そして「引渡し」とは有体物を念頭にした概念で、「所持を移転すること」であるとされている。そもそも完成と引渡しの関係についても解釈が分かれており、ソフトウェア開発における引渡しの解釈もいくつかあるが、パターンとしては以下が考えられるため実際の場面ごとに考える必要がある。
①ソフトウェアのマスター媒体の受け渡し
②注文者の管理するサーバへのアップロード
③ＩＤ・パスワードなどソフトウェアが利用できるようになる情報の通知
完成と引渡しの違いから、完成していながら注文者が引渡しを拒んだ場合が問題になった事例が存在する。
この場合、現行民法では受領遅滞または受領拒否として整理できるならば、受注者は債務不履行責任を免れる（債務が消滅するわけではない）が、報酬請求権が確定したとまではいえない。
完成時と引渡し時、どちらが履行義務の充足時点？
さて、現行収益認識会計的には履行義務の充足があってはじめて収益が認識されるが、完成と引渡しを別のものであると解したとき、果たしてどちらの時点が履行義務が充足された時であろうか。
完成をめぐる裁判例においては、ベンダは目的物の開発にかかる最後の工程（開発されたソフトウェアに対するデータ移行の完了や予定されていた運用テストの完了など）を終えていることを理由に報酬の支払いを求める。完成していると認められないとき、この求めは棄却される。
このことからすると、「完成に至った場合は引渡しがなされていなくとも報酬請求権を獲得するから、収益を認識する」ということも成り立つようにも思える。
しかしこれは例外的なケースであって、支払いに関する疑義が相当程度あるから、保守的に考えて収益を認識すべきではないだろう。
原則論として、民法633条を根拠に考え、引渡しを基準にすべきと思われる。現実的には、完成時点はなお受注者の内部状態であって、引渡しを完了させるときに注文者の検収書類が発行されるから、これにあわせるべきである。
この記事が気に入ったらサポートをしてみませんか？