制度会計とAgile開発・"Stupid Finance team!"

まず質問した人

our Finance team has instructed us to code all of our hours to one of the following categories: Analysis, Design, Build, Test, Post Launch Support.

弊社の経理チームが、私たち開発チームの勤務時間を「分析」「設計」「開発」「テスト」「サポート保守」に区分して報告するように要求してきました。

Obviously, this feels pretty non-agile. The response to questions on this has been that this coding follows Generally Acceptable Accounting Principles for capitalized/non-capitalized software development expenses, and that we don't have a lot of flexibility in this. Has anyone experienced this or is anyone familiar with the Accounting Principles for software?

これってAgileと馴染まないですよね。なんでこんなことをするのか経理チームに聞いたら、ソフトウェア開発における設備投資費用とそれ以外とを制度会計(GAAP)の原則で調べなければいけないんだ、という答が返ってきました。こんなのに付き合ってはいられません。誰か同じような状況に遭遇した人はいませんか? どうやって対処しましたか?

一発目回答はRon Jeffries

Last I knew about this (and I knew it well at that time), I decided that I could make up the numbers to be reasonable and that would suffice. So I did that.

自分の場合は、この種の数字はそれなりにでっちあげても大丈夫だと思ったし、実際にそうした。

BTW I was at that time a VP of a publicly held corporation of some magnitude, so I wasn't just screwing around.

その時の自分はそれなりの規模の上場企業の副社長だったので、馬鹿な事はしなかったよ。

三発目回答: Roy Morien

My experience is that the 'Finance team" is usually about 20 years behind contemporary thinking in software development. I base my opinion partly on my participation in ADP Auditing course in the Australian Government, using CICA auditing courses.

会計監査の講義を受けた経験から言わせてもらうと、こういう「会計チーム」の連中はソフトウェア開発技術と比べて20年遅れているよね。

This request is nonsense and is based on that ignorance.

この手の(制度会計に関する)要求は、技術音痴だからでてくるわけだ。

So, what to do? Easy! You divide up your hours into what looks like reasonable proportions, and give those figures to the Finance team. They won't have any clue about how realistic or otherwise those figures are, and they will probably be happy that you have 'filled in the blanks', which is the usual aim of such requests anyway.

じゃ、どうすればいいか?簡単です。働いた時間をそれっぽく分割して、会計チームに渡せば良い。連中はその数字が正しいかどうか判断しようがないんだから。要は空欄埋めてもらえればそれでハッピーになれるような人達です。

When the auditors come to inspect the books it is unlikely that they will challenge these figures. If they ask for an explanation, you just tell them that it is your considered opinion, as a software development professional, that those figures represent a reasonable allocation of time between those various functions, although you never do any of the alone. SO those figures can be seen as providing a 'true and correct' view of the cost allocaion.

仮に会計監査が入ったとして、監査人がこれらの数字にケチをつけてくる可能性は低いでしょ。もし、監査人が説明を求めて来たら、ソフトウェア開発のプロとして、これらの数字は適切に割り当てられていると主張すればいいわけです。たとえAgileがこうした工程を踏まなくても、ね。

Stupid Finance team!

会計チームのアホ!

まとめ

Agileは制度会計が期待しているようなソフトウェア開発工程を踏まないが、どの工程でどれくらいの原価を投入したかは「それっぽい数字」を出せば問題ない。