nav_CapEx-OpEx

財務部門がアジャイルソフトウェア開発に適切な資金を供給できるよう社内のアジャイル主義者が手助けしなければ、会社に必要以上の納税義務が生じたり、エンジニアの人員削減が必要になったり、監査指摘事項が見つかって収益を報告し直さなければならないリスクが増加したりする。

– アジャイル変革コーチ、ダン・R・グリーニング博士

資本的支出と業務費の概要

企業はSAFeポートフォリオに資金を供給する。これは、企業がビジネス上および財務上の目標を達成できるようサポートする技術ソリューションの開発に必要な資金である。この予算には、資本的支出(CapEx)と業務費(OpEx)の両方の要素が含まれる。

多くの企業では、会計基準に従って、販売用または社内用のソフトウェア作成に必要な工数の一部を資産計上している。上の引用に見られるように、それをアジャイル開発でどう行うかを理解しているかどうかによって、多くの企業におけるアジャイルの展開がうまくいくかが左右される。
この議論を行うのは、ソフトウェアの資産計上のプラクティスが、多くの企業ではウォーターフォール開発を前提として確立されているからである。そのため、事前の要求や設計フェーズのゲートが、開発コストの一部の要素を資産計上するきっかけとなるイベントを表すことがある。しかし、アジャイル開発では、これらの工程は、通常、継続的に行われ、多くの場合、段階ごとの公式のゲートは存在しない。そこで企業は新しい問題に直面する。アジャイル開発のパラダイムでこれらの費用をどう扱えば効率的かという問題である。

詳細

企業は、ソリューションポートフォリオを開発し管理できるよう、SAFeポートフォリオに資金を供給する。ポートフォリオ内での個々の価値のストリームへの資金の割り当ては、プログラムポートフォリオ管理の主導で行われる。プログラムポートフォリオ管理は、ポートフォリオ内のそれぞれの価値のストリームに、必要な資金を割り当てる。SAFeポートフォリオの 予算には、資本的支出と業務費の両方の要素が含まれることがある。

  • 資本的支出は、通常、ソリューションの構築に使用する計算装置や機械などの有形物的資産の購入やアップグレードや修理に必要な資金である。購入費用は資産として貸借対照表に記載され、その資産が使用されている間、損益計算書での経費となる。さらに場合によっては、特許やソフトウェアなどの無形資産の開発に要した人件費の一部も資本的支出として扱われることがある。
  • ソリューション開発における業務費は、ソリューション開発に関わる費用であり、給与や諸経費、外注費、原料費、消耗品など、ソリューション開発作業に直接関連するものが含まれる。これらは発生した期間の損益計算書に記載される。

通常、ソリューションポートフォリオの研究開発予算の大部分は業務費に費やされる。しかし、ポートフォリオの利害関係者は、価値のストリームそれぞれの経済的枠組みの一部として関与できるよう、資本的支出と業務費の両方を理解しなければならない。そうでなければ、正しい分野にお金が使われず、実際のポートフォリオ支出の経済的な結果が意図したとおりにならない。

特に、ソフトウェア開発費用の一部を資産計上すると、それが企業全体の財務成績に重大な影響を与えかねない。各ポートフォリオでは、そのような作業を会計上どう扱うかを理解しておく必要がある。このページの残りの部分では、ソフトウェア開発費用の資産計上について説明する

アジャイル開発におけるソフトウェア開発費用の会計処理

注:ソフトウェア費用の資産計上は、国ごと、あるいは企業ごとに異なる会計規則によって大きく左右される。さらに、環境によっては、(米国連邦調達の場合のように)まったく異なる規則が適用される場合もある。資産計上の財務会計を適切に実施する責任は、各企業にある。リーン-アジャイルへの変革を推進する責任者は、ビジネス利害関係者と協力して、新しい働き方が社内の会計手続きにどう影響するかを理解しなければならない。

ソフトウェア資産計上の概略

ソフトウェア資産の資産計上規則は、国や業界に固有のものである。アメリカ合衆国の場合、米国財務会計基準審議会(FASB)が、公共の利益のために会計報告を行っている米国企業(米国証券取引委員会の規則の下に公表している会社など)向けに、一般に認められた会計原則(Generally Accepted Accounting Principals:GAAP)の指針を提供している。同様の組織が他の国にも存在する。たとえば、英国財務報告評議会(FRC)ではFASBとよく似た方針を提供している。さらに、米国連邦政府にも、連邦会計基準助言審議会の管理下に同様の基準がある。

米国財務会計基準審議会(FASB)86(ここ)で概要を参照できる)では、販売やリースやその他の方法で市場に出すコンピューターソフトウェアの費用について、会計処理の指針を提供している。FASB 86では、コンピューターソフトウェアプロダクトの作成時に社内で負担した費用は、技術的な実現可能性が立証されるまでは、研究開発費用として負担時に経費にしなければならないとされている。その後、ソフトウェア製造費用はすべて資産計上し、それ以降は未償却原価と正味実現可能価額の低い方で記録しなければならない。資産計上された費用は、プロダクトごとに現在および将来の収益に基づいて償却される。その年間最低額は、プロダクトの予想経済的耐用年数の残りの期間での定額償却分に等しい額である。このような目的のため、ソフトウェアプロダクトは、新規プロダクト既存プロダクトの機能を変更する新規の取り組みのどちらかに決められる。

FASB 86でのソフトウェアの分類

FASB 86では、ソフトウェア開発は大きく次の3つに分類される。

  • 販売用ソフトウェア – 主に独立ソフトウェアベンダー(ISV)によって、スタンドアロンプロダクトまたは統合プロダクトとして、販売用に開発されるソフトウェア。
  • 社内向けソフトウェア – 社内使用または企業内のビジネスプロセスのサポートだけを目的として開発されるソフトウェア。これについては SOP 98-1で詳しく説明されている。
  • 研究開発(R&D)組み込みソフトウェア – 有形プロダクトの構成要素のうち、そのプロダクトの本質的な機能を実現するために必要な要素であるソフトウェア。

資産計上の基準はこの分類によって異なる扱いがされるため、該当する指針を考慮しなければならない。

資産計上か支出かの基準

一般に、費用を資産計上するには、プロダクトが以下の基準を満たしていなければならない。

  • プロダクトが技術的に実現可能であると判断されていること。
  • 開発作業を継続することを管理者が文書で承認していること。
  • 開発用のリソースを管理者が確約していること。
  • プロダクトの開発と納品が成功すると管理者が自信を持っていること。

これらの基準が満たされると、表1に示すように、開発コストの一部を資産計上できる。

Table 1. Categories of expensed and capitalized costs
表1. 経費となる費用と資産計上される費用の分類

ソフトウェアの資産計上を始める前に、その具体的な作業が完了したという証拠の文書が、財務部門から通常は要求される。そのため、チームは規則をどう適用してどう報告すればよいかを知る必要がある。

ウォーターフォール開発における資産計上

従来、資産計上はウォーターフォールのステージ-ゲート開発のコンテキストで適用されてきた。準拠するソフトウェア開発ライフサイクル指針に具体的に記述されているのがほとんどはその開発手法だからである。ウォーターフォール開発には、「事前に決められたフェーズ」が明確に定義されていて、そのフェーズの中で要求を作成し、設計を行い、実現可能性を立証する。従来は、これが資産計上を開始するための便利なステージゲートとなっていた。その様子を図1に示す。

Figure 1. Capitalization in waterfall development
図1. ウォーターフォール開発における資産計上

SAFeにおける資産計上の選択肢

アジャイルリリース列車が価値を構築し納品する

しかし、アジャイルでは要求や設計が継続的に現れるため、資産計上の公式な前触れとなる正式のゲートは存在しない。そうではなく、SAFeを導入している企業は価値のストリームの中の長期的な価値のフローを中心に組織化されていて、価値のストリームはアジャイルリリース列車(ART)の人やその他のリリースによって実装される。ARTは固定されたプログラムインクリメントのリズムで作業を行い、独自の運営予算を持つ。

後で説明するようにARTは一部の実現可能性検証や研究作業にも加わるが、ARTの作業の大部分は、実現可能性の分析が終わった後の、ソフトウェア資産の構築や拡張が中心である。列車上のアジャイルチームは、実装作業を行うことで、必要な直接労働の大部分を担う。その他の専任リソースには、プロダクト管理リリース列車エンジニア(RTE)、1人以上のシステムアーキテクト、その他の特別なスキルを持った人などがいる。ARTはプロダクトの実装と継続的な拡張の両方を行うため、ARTの作業の多くは資産計上できる。

以下のセクションでは、実施可能な次の3つの方法について説明する。

  • ART費用の割合による資産計上
  • ストーリーポイントによる資産計上
  • タスク時間による資産計上

ART費用の割合による資産計上

ART費用の割合による資産計上は、もっとも粒度の粗い(かつオーバーヘッドのもっとも少ない)資産計上手法である。この手法では、各プログラムインクリメントに関連付けられた直接費と間接費の一定の割合が資産計上される。この割合は、実現可能であると立証されたプロダクトの構築と拡張に作業のどれだけの部分が充てられるかの見積もりと、新規プロダクト候補の要求と設計および既存プロダクトの保守に割り当てられた時間の割合に基づいて決められる。この割合は、おそらく、担当するプロダクトやサービスにより、ARTごとに大きく変動する。図2に示すように、SAFeでは、ART予算内の投資全体が戦略の意図に一致したものになるよう、各ARTがプログラムバックログに対してキャパシティの割り当てを行うことを推奨している。

Figure 2. Program increment backlog with capacity allocation
図2. キャパシティの割り当てが行われたプログラムインクリメントバックロ

キャパシティの割り当ては、ARTの現在のコンテキストやニーズを反映して、時々に(多くはPIごとに)変更される。新しいフィーチャーに割り当てられる割合は、現在のプロダクトの構築と拡張への投資を表し、資産計上の割合として使われることもある。しかし、後で説明するように、今後のフィーチャーのためにアーキテクチャー滑走路を拡張する作業の一部が資産計上の対象に含まれることもある。

ただし一部の企業においては、ART費用の割合による資産計上では抽象度が高すぎて、現在の資産計上方針と合わないことがある。その場合には、ストーリーポイントによる資産計上またはタスク時間による資産計上を使用することができる。これらについてこの後のセクションで説明する。

ストーリーポイントによる資産計上

SAFeでは、エピック、フィーチャー、およびストーリーを使用して、ポートフォリオプログラムチームというそれぞれの抽象レベルに応じたシステムの動作を記述する。エピックは取り組みのコンテナの役割をするが、ここに含められる取り組みは、規模が大きいため、分析や軽量ビジネス企画が必要であり、投資とROIの見込みを理解できなければ承認されない。そのため、明らかに新しいビジネス価値の可能性を表してはいるものの、それらが資産計上のための要件を満たすのは公式な承認が済んだ後である。つまり、承認の前に行われた作業はどれも、資産計上できないことになる。これには、潜在的な作業をポートフォリオカンバンシステムの中で移動させるのに携わる人(主に企業とエピックオーナー)の工数のほか、設計 イネイブラー、調査、プロトタイプ作成、その他の実現可能性確認のためのストーリーを実行するためにチームが行った作業も含まれる。ただし、エピックを実装してよいと承認された後では、作業の大部分を資産計上することができる。この様子を図3に示す。

Figure 3. Epic requirements, analysis, and design stories are not capitalized; implementation stories may be
図3. エピックの要求、分析、設計のストーリーは資産計上されない。実装のストーリーはされる可能性がある。

フィーチャーはソリューション価値を向上させる

SAFeのフィーチャーは、ユーザーのニーズを満たすシステムサービスである。そのため、アップグレードや機能強化の資産計上要件を明らかに満たしている。しかし、エピックと同様に、フィーチャーもそれ自体が実装されるわけではない。アジャイルチームは、そのすべての作業を、フィーチャーをストーリーに分解することで行う。ストーリーの多くはそれ自体が新しい価値を納品するものであり、その他のストーリーはそれらのストーリーをサポートすることで価値を追加する。そのため、ストーリーはすべてが資産計上の候補となる。その様子を図4に示す。

Figure 4. Stories that implement features can be capitalized
図4. フィーチャーを実装するストーリーは資産計上することができる

ストーリーポイントから費用への変換

アジャイルチームが管理するのは、見積もりではなく実際のストーリーポイントである。というのも、これが、よく使われているバーンダウンチャートに不可欠なものだからである。さらにSAFeでは標準化された見積もりを使用するため(反復計画を参照)、ストーリーポイントの工数は、1つの管轄範囲内のどのチームでもほぼ同じである。これは、きわめて摩擦の少ない資産計上手法となる。

  1. ストーリーは、資産計上の扱いに応じて「種類分け」される(資本的支出または業務費)
  2. チームはストーリーポイントという共通の単位を使って、実際のストーリーポイントを見積もり、追跡する。
  3. 会計処理では、各管轄範囲のストーリーポイントごとに平均コストを計算し、それに応じて資産計上を行う。

ただしストーリーポイントには、プロダクトオーナースクラムマスターがつぎ込んだ時間や、システムアーキテクトやRTEなどが行った作業が含まれない。しかしこれらの役割は一般的に、「システム機能向上に直接関係する間接労働」とされるため、資産計上対象のストーリーポイントに対して間接費を追加することで、このコストを含めるよう調整できる。

その他の作業

エピックやフィーチャーは、そのまま資産計上処理の候補となる。しかし、SAFeの成果物の中には、より具体的なコンテキストで財務処理を理解しなければならないものがある。たとえば次のようなものである。

非機能要求(NFR)。これはパフォーマンス、品質、使いやすさに影響する。エンドユーザーにとっての機能的価値を向上させるものも、そうでないものもある。企業では、全般的な方針としてNFR関連作業を資産計上しないと決めることもできるし、NFRを種類ごとに分類してNFRを実装するストーリーが適切な扱いを受けるようにすることもできる。

イネイブラー。システムの基礎となる技術に投資するためのものである。主に保守のためやユーティリティとして存在するものもあれば、明らかに新しい価値をもたらすものもある。この場合も、企業では、全般的な方針としてこれらの作業を資産計上しないと決めることもできるし、種類ごとに分類してこれらのイネイブラーを実装するストーリーが適切な扱いを受けるようにすることもできる。

リファクタリング。外から見たシステムの動作を変えずに中のコードベースを改善するためのものである。そのため、リファクタリングは一般的に資産計上の対象とはならない。

タスク時間による資産計上

紹介した中でもっとも粒度の細かい手法がタスク時間による資産計上である。このモデルでは、資産計上可能な各ストーリーを実装するためのタスクに関連付けられた実際の労働時間が費用に変換され、資産計上される。標準的なスクラムやXPのほとんどのトレーニングでは、そのようなタスクの扱いが規定されている。そこではストーリーを「人時」の工数で見つもった個々のタスクに分割する。このタスクそれぞれは、1人の担当者が1日以内で終了できるものである。例を図5に挙げる。

Figure 5. Tasking a story in hours
図5. ストーリーを時間単位のタスクとして処理する

SAFeでは特別にタスクの扱いを規定していないが、これまで我々が見てきた経験では、多くのチームにとってタスクを使用することは有益であるように思える。また、SAFeのARTおよびポートフォリオのメトリックスでは、ストーリーを使ったバーンダウン(およびバーンアップ)チャートを重視しているが、多くのチームは残り時間の見積もりを使って反復のバーンダウンチャートを計算している。さらに、個別原価計算や支出報告や請負仕事などのさまざまな理由で、多くの環境では時間管理が必須なため、タスク管理が追加の負荷にならない可能性がある。

いずれにしても、資産計上にタスクを使用すると便利な場合がある。

  1. ストーリーは、資産計上の扱いに応じて「種類分け」される(上述のとおり)
  2. チームは実際に費やしたタスクの時間を管理する(元の見積もりは資産計上には関係しない)
  3. 会計時には、資産計上可能なストーリーに実際にかかった時間を費用に変換する

ただし、チームが現在タスクを使用していないのであれば、資産計上のために無理にタスク(およびそれに伴う勤務時間記録表、ツール、管理のオーバーヘッド)を導入しても、全体として経済的な利益にならない可能性がある。その場合には、費用の割合による資産計上 ストーリーポイントによる資産計上 の方が好ましいかもしれない。


さらに知りたい場合

Last update: 4 November 2015