アジャイル開発は工事進行基準と相性が良いという仮説

アジャイル開発は工事進行基準と相性が良いという仮説について考えたことをメモ。

【元ネタ】
Twitter / z200: スクラムを例に取ると、リリース（および検収）と売上・請求フローを組み合わせることは可能かと。開発で試したことはありませんが、制作現場では有効でした。 RT @akipii: そういう考え方もあるのか RT @z200: アジャイル開発は、工事進行基準との相性も良さそうだな。

【続報】ソフトウェア開発の売上げ計上タイミング：むささびの視線：ITmedia オルタナティブ・ブログ

ソフトウェア開発の売上げ計上タイミング：むささびの視線：ITmedia オルタナティブ・ブログ

販売管理～売上の計上時期（売上計上基準）

【1】ソフトウェアの受託案件が一括請負契約の場合、例えば1年間頑張って作った後、ユーザの受入検収が完了して初めて売上計上されるのが普通。
作って納品しておしまい、ということは普通はないだろう。
ユーザが使ってみて、確かに使えるね、という承認をもらわなければ、ユーザはお金の支払に首を縦に振ってくれない。

そして、実際の受入検収時に、バグを見つけた、この機能が足りない、この機能が使いづらい、といった障害や改善要望がたくさん押し寄せる時が多く、そう簡単に売上計上できない場合が多いのではないか？
しかも、ソフトウェアを納品した後の1年間は、瑕疵担保責任がSIに発生し、普通は無料で障害修正を行う時が多い。
だから、新規顧客のシステム開発は赤字になるリスクが大きいと思う。

最近は、システム監査やコンプライアンスが厳しくなったために、工事完成基準のように、システム全てを作った後に売上を一括で丼勘定で計上するやり方が適用しにくくなった。
工事進行基準に合わせて、システムの開発中の進捗度合いで売上がとれていないのに、売上を立てていく必要がある。
多分、実際は進捗度合いに合わせた売上金額を計算して、「売掛金//売上」として計上していると思う。
そして、最後に検収された後に、顧客からSIの銀行口座に振り込まれた時に、「当座預金//売掛金」として仕訳が立つのだろう。
でも、ウォーターフォール型開発では、設計・開発・テストの工程単位で開発しているために、例えばドキュメントを全部作ったとしても、動くシステムは一つも動いていないのだから、設計工程だけで売上が上がるということは正直現実的でないだろう。

【2】でも、アジャイル開発の場合は、工事進行基準と相性が良いのではないかと考える。
理由は、製品(完成した成果物)の基準が明確であることと、イテレーション単位に出荷可能な製品をリリースできることの2つがあるからだ。

アジャイル開発では、スクラムのように、スプリントの最後には出荷可能な製品が出来上がる。
「出荷可能(shippable)」とは、ユーザにデモで見せることができるレベルを指している。
つまり、デモがベータ版であっても、未実装の機能が半分あっても、少なくともユーザが手に取って受入検証できるレベルでなくてはならない。
その意味では、製品という完成した成果物の基準はとても明確だ。
受入検証できるからこそ、売上という尺度で、製品(現物)の価値を測定することができる。

また、スクラムでは、各スプリントの最後にスプリントレビューを実施し、プロダクトオーナーだけでなく、ユーザや上司などのようなステークホルダーにデモを見せて、評価してもらう。
つまり、スプリントと言う定期的な期間ごとに、デモで検証できる現物を見ながら、ステークホルダーは価値を測定することができる。
すなわち、工事進行基準の観点では、スプリントを経るたびに、少しずつ売上という価値(出来高：EV)が計上されていくし、その売上という価値は、スプリントレビューでステークホルダーの承認も得ているので、きちんとした証拠も残る。

逆に、ウォーターフォール型開発では、工事完成基準のようにプロジェクトの最後までずっと売上＝0円で、最後にいきなり多額の売上高が計上されるパターンか、工事進行基準を適用して、動くシステムが作れない状況のままプロジェクトの最後まで仮の出来高(設計書は完成しているがシステムはバグだらけ)でしか売上を計上できないパターンしかないだろう。

【3】そんなことを考えると、ソフトウェア開発のようなビジネスが増えている現実において、会計原則がその流れに追いついていない感触を持っている。
ソフトウェア開発の産業は、製造業や小売業とは全く違う性質を持つ。
そもそも、出来高ないし現物という基準や納品するという概念が、従来の製造業とソフトウェア産業では全く異なるからだ。

そんな状況で、アジャイル開発は「定期的に現物をユーザに届けることで価値を定期的に確認する」プロセスを取り込むことで、ユーザにいち早く価値を届けられるだけでなく、ビジネス上の売上という価値基準も明確になる仕組みがある。

特に、アジャイル開発はソフトウェア開発特有の特徴をうまく生かしている点があるから、その特徴に見合った会計原則なり会計基準が早く出現するといいのではないかと思ったりする。