（ 1 ）問題提起とポイント

給料体系の異なる従業員等が、それぞれ異なる作業を、異なる時間で行っていれば、作業ごとに集計される原価は劇的に違っているはずです。それなのに、給料等の総額を、これまた全体の基準によって集計し配賦したのでは、算定結果もアバウトなものとなってしまいます。

より精緻な計算が、より正確な損益計算を可能にするばかりではありません。正確な原価の把握によって、経営判断で大胆な処理をより自在により説得力を持って行うことができるのです。

労務費原価計算の重要性

労務費原価計算というと、モノつくりの製造業で「製品1つを製造するのにいくらかかるのか」を算定するものというイメージが最初に出てきます。

しかし、製造業以外のサービス業の場合では、コスト構造として労務費がその大半となります。すると、「このプロジェクトにいったいいくらかかるのか（かかったのか）」ということになります。

実は、労務費原価計算をキチンと把握できるかどうかということは、経理的な小さな問題ではなく、つまるところ「販売価格をいくらに設定したらいいのか」という経営に直結する問題なのです。

とりわけ、ソフトウェア開発業は、仕事のタイプにおける労務費が会計上も大きな影響を及ぼすことになるため、仕事ごとのコスト把握は極めて重要となります。

ソフトウェア労務費の重要性

製造業の場合、原価計算の役割は、文字通り個々の製品の製造単価を算定することにあります。製造単価を算定するための基礎となる製造費用は、おもに材料費、労務費そして経費に区分されます。いっぽう、ソフトウェア開発業などの場合には、製造業の製造費用にあたるもののうち労務費（人件費）の占める割合がより高くなります。また、経費のうち外注費（業務委託費）であっても、その内容は人件費であることが少なくありません。

ソフトウェア開発業のコスト構造は、エンジニア等の人件費が重要な部分を占めるのではないでしょうか。外注費や業務委託費のたぐいも、その中味は人件費であることが多いと思われます。

ソフトウェア開発業の場合、労務費の発生態様の把握とその集計の方法が財務情報に大きな影響を与えます。製造業の場合には、主に当期の売上原価となるのか棚卸資産となるのかということが中心となりますが、ソフトウェア開発業の場合には、何が売上原価となり、何が研究開発費となり、また、何がソフトウェア仮勘定やソフトウェア勘定として資産計上され、そしてどれだけ減価償却され除却損や減損損失になるのかというように、損益ばかりでなく損益の区分も大きく変わることになります。

そして、もともと企業内の内部的な費用である労務費ですが、ソフトウェア開発業の場合には、もともと成果物が目に見えにくいばかりでなく、個々の作業が専門的であることが多いため、外部者からはわかりにくいことが少なくありません。

しかも、とくに技術部門が少人数の企業では、各エンジニアが、基礎研究、新製品開発、既存製品の機能向上、バージョンアップ開発、クレーム対応、営業のサポートなどいろいろな作業を日々目まぐるしく行っていることが少なくありません。複数の製品の開発や複数のプロジェクトを同時並行的に関わっているとさらに複雑になります。

このため、それぞれの費用や資産となる金額は、個々の数値の把握からその集計や配分いかんによっていかようにでもできることになります。

ドンブリ

労務費は、直接的な部分と間接的な部分とに分けることができます。このうち、直接的な部分すなわち直接労務費は、特定の製品やサービスなどに直接関連する費用は、賃率（時間当たり人件費）に特定の製品等の時間を乗じることで算定されます。もっとも簡便な方法としては、製造等にかかわる従業員等の一定期間の総人件費を総作業時間で除して、それぞれの製品やサービスなどに要した時間を乗じることが行われているようです。

しかし、この方法では、個々の従業員の給料（賃率）も、それぞれの作業に要した時間も異なるのに、いったんすべて合計してしまってから作業に配分されてしまいます。これでは、いかに個々の従業員の作業データをいかに正確に把握したとしても十分に有効に活用されていないことになります。

直接労務費以外の労務費すなわち間接労務費については、直接労務費の金額あるいはその基礎数値によって、個々の作業等に配分されることがありますが、基礎となる直接労務費などの精度が低いと、配分される間接労務費もそれなりの信頼性ということになります。

そして、算定結果からいくら差異分析を行っても、そもそも算定結果がドンブリでは、差異額にしてもその分析にしても、その有効性はおのずと限界があるように思われます。

精度のバランス

基礎的なデータが正確に把握されていれば、あとは集計や組替の問題になります。ですから、一部作業部分について経理的に除却したり、または、当初の作業について「その後の社内的な事情による解釈」により別の作業と判断したり、「もろもろのシミュレーション」をする際にも適切な情報を得ることができます。

どこまで精度をあげるかについては、詳細であればあるほうがよいことになりますが、コスト・ベネフィットの問題があります。個々の従業員等から得るデータの精度と、各人のデータを集計し加工して作られたデータの精度は、適切なバランスを取ることが望ましいと考えます。個々の従業員等から得るデータは正確であったとしても、その後の集計方法がざっくりしてしまってはバランスが悪く信頼性が低いと思われますし、逆に、集計方法がいかに精緻なものであったとしても素材である個々の従業員等のデータがざっくりしていてもやはりバランスが悪くなります。

精度を高めるといってもやはり程度の問題があります。やたらと精緻化してみたものの、複雑すぎて入力ミスが多くて信頼性が低くては本末転倒です。最低限、外部者から「それなりにキチンとやっている」との心象を得られるレベルならばよいのではないかと思われます。

基本的なポイント

人件費をより正確に計算するための基本的なポイントは次のとおりです。

個々の従業員等の作業内容を適切に把握する
個々の従業員等の作業内容と個々の従業員等の人件費と紐付ける
毎月の給料だけでなく賞与や法定福利費も把握する
勘定科目の体系を概算計上と実額計上分とに区分する
ワークシートはチェックがしやすくフレキシブルにする

個々の従業員等の作業内容を適切に把握する

個々の従業員等の作業内容を適切に把握することは、財務諸表に重要な影響を及ぼします。とくに一人数役でエンジニアがいろいろな作業をこなしている場合には、一人の作業が、「研究開発費」「ソフトウェア仮勘定」「ソフトウェア売上に対する原価」「通常の販売費及び一般管理費」となり、財務諸表の内容を劇的に変えることになります。

また、個々の従業員等の作業内容を適切に把握することによって、カットオフ、つまり、会計基準が要求している「製品マスター完成時点」までのコストや、実際の製品完成時点までのコストをより正確にすることができます。売上や仕入れは期末付近の取引をキチンを把握しているわりには、人件費関係についてはなぜか実際のアクティビティとは無関係に、月単位などで分断してしまうことがあります。新製品のリリースや研究開発の終了が月末に行うわけでもないかぎり、これでは財務内容にゆがみを生じさせることになります。より実態に近い集計をしようとすれば、たとえば月ベースでの集計をしてから、日割りで算定するような考え方もあります。

個々の従業員等の作業内容と個々の従業員等の人件費と紐付ける

個々の従業員等の作業内容を適切に把握しても、財務諸表は金額で示されます。すなわち、個々の授業員等の作業内容と個々の従業員の人件費がきちんと紐付いていなければなりません。せっかく作業内容は細かく集計したとしても、作業している個々の授業員等のお給料は違うわけです。高給の従業員とそうでない従業員が行っているのに、単純に作業時間の合計で計算してしまったら、なんのために細かく作業内容を把握したのかということになってしまいます。個々の従業員ごとに作業別のコストを算定し、これを集計した方がより実態に近くなります。

毎月の給料だけでなく賞与や法定福利費も把握する

さらに注意したいのは、個々の従業員の人件費といっても、給料だけではありません。かなり雑に扱われることが多いのですが法定福利費も重要になります。給料はキチンと集計しても、法定福利費がアバウトでは、やはり十分とはいえません。また、賞与や退職給付費用の問題もあります。事後的に支給対象期間の給料に上乗せして再計算しなければなりません。厳密に言えば、「個々の従業員のパフォーマンスに基づくボーナスなのか、全社的な業績向上に伴うボーナスなのか」によって原価性はどうなのかといった検討も必要になるのかもしれませんが、そういう話はともかく、まずは、賞与、そしておろそかになりがちな賞与に対する法定福利費もキチンとおさえる必要があります。

勘定科目の体系を概算計上と実額計上分とに区分する

これを可能にするには、勘定科目の体系自体も変える必要があります。おすすめしたいのは、実際の金額を計上する（補助）科目と、概算計上する（補助）科目を分けることです。賞与も実際の支給まで待っていられないため概算計上しているでしょうし、健康保険や厚生年金の正確な金額も月半ば付近にならないとわからないとすると月次決算の締めに間に合わないこともあります。こんなときに、ひとつの勘定の中で概算額と実際額が同時に入っていると、概算額の戻しと実際額の計上でミスを犯すこともあります。なにより検証がしにくくなります。このことは、会計上ばかりではありません。同時に、税務用、すなわち「損金として認められるか認められないのか」とキチンと区分したり、「概算計上なので消費税を仕訳で認識しない」ためにも有用です。

ワークシートはチェックがしやすくフレキシブルにする

数値を作るワークシートは、チェックがしやすい検証性の高いものにすべきです。作成者本人ではなく他人もチェックしやすくする必要があります。ワークシートはおのずとシンプルなものになるでしょう。

賞与や法定福利費などは、後になって正確な数値が判明するため、コストを再計算することになります。このため、概算額で計算する「会計用（月次計上用）のワークシート」と実際の金額で（事後的に）計算する「本来のコストを算定するためのワークシート」を持つことになります。

また、ワークシートはフレキシブルなものである必要があります。当初作成してもいろいろ不具合が出たり、実際の作業等の変更に対応してフォーマット自体も変更したほうがよいことが少なくありません。あまりに硬直的で細かく作りすぎてしまうと、現実の経営環境が変わっているのに、従前のフォーマットで作らなければならないというなんとも本末転倒な事態になってしまいます。

もうひとつ、ワークシートのフレキシブルでなければならない理由は、「万が一間違えていた」場合にもすぐに対応できたり、「オカしいと指摘された」場合にもすぐに修正できることです。当初はある製品の開発作業ということでやっていた作業だったものの、結果として途中でキャンセルとなったり、あるいは、作業形態は同じでも、解釈の違いでやはり研究開発費だったということもありえます。そういう場合でも対応できることが大切です。

（つづく）