（ 4 ）人件費配分のためのデータ把握

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

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

大量のエンジニアをかかえ、個々のエンジニアは特定の作業のみに専従しているという形態はともかくとして、少数精鋭路線で、ひとりのエンジニアがあらゆる作業（研究開発、新製品制作、既存製品のバージョンアップ、カスタマーサポートその他）などにかかわっている場合には、ひとりのエンジニアの人件費が、会計上さまざまな項目に配分されることになります。

前回までで、その配分する前提となる人件費をキチンと月初から月末まで集計するためのヒントを申し上げました。

今回は、実際に配分するための作業内容の測定や把握についてコメントさせていただきます。

最低限把握しておきたいこと

作業内容の把握にはキリがありません。細かくしようと思えばとことん細かくできます。会計上の目的ばかりでなく、人事考課などの経営管理の目的にも利用されることもありえます。

ただ、細かく把握することで何をしたいのかが明確でないと、ムダなことになってしまいます。

バランスを考えた把握が必要になると考えられます。

いわゆる無形資産については、将来的には会計基準が整備される計画があるもようですが、現状では「研究開発費等に係る会計基準」に準拠できるような把握が必要になります。

まず、一般的に次のようなポイントがあります。

製造費用となるのか一般管理費となるのか
費用なのか資産の取得価額を構成するのか

さらに、ソフトウェア原価計算の特殊性に鑑みて主に次の点がポイントとなります。

作業の内容

既存ソフトの機能の著しい改良に要した作業
既存ソフトの機能の維持に要した作業
既存ソフトの機能の著しくない改良に要した作業
購入したソフトの導入やカスタマイズの作業
既存ソフトのマイナーバージョンアップの作業
既存ソフトのメジャーバージョンアップの作業

集計範囲を画するタイミングとして

最初に完成した製品マスターの完成時点（市場販売目的ソフトウェア）
製品マスターや購入ソフトウェアの著しい改良の終了時点
収益獲得または費用削減が確実になった時点
ソフトウェア制作の完了時点

データ把握のポイント

作業内容については、会計的（税務的に）な判断がしにくいところがあり、故意はまったくなくても、期首あたりの判断と期末あたりの判断では異なることはありえます。

「やっぱりこの作業はふたつに区分して把握すべきだった」など後になってから思うこともあります。

ただ、あまりにも細かい内容まで把握することは、従業員のモラル（士気）の低下を招くことになり、会計上の目的のために本来の開発作業などが支障をきたすという本末転倒なことになってしまいます。

データの計測については、「どのようにして作業内容を測定するか」にエネルギーが費やされることになります。それと同様に重要なのは、データをどちらかといえば批判的にチェックする側（監査や税務調査）に対していかにデータを信頼してもらえるかという点です。

と申しますのも、そもそも作業の内容が専門的なものであることに加え、誰がどんな作業をしたかということは、完全に企業内部のもので、外からはうかがうことが相当難しいものです。ヘンな話どうにでもできるものです。

「利益出すぎそうだから研究開発費ってことにしちゃおうか」「赤字になりそうだから新製品の制作ってことにしちゃおうか」ということです。

ただし、たとえば社内メールや開発計画や業務指示書などの非財務データとの間に矛盾があると、チェックする側は一気に色めき立ち、データに対する信頼性すべてに疑問を感じることになります。チェックする側も感情を持った人間ですから。このあたりの整合性をキチンと取っておくことが大切です。

逆に、「このメールの日付と一致してますよね」「このプレスリリースと一致してますよね」ということを積極的にアピールすることで、よい心証を持ってもらえる確率も高まるでしょう。

いっぽうで、「見解の相違」に対応できる粘り腰のあるデータ取りも求められると考えられます。

「見解の相違」が生じるポイントはあらかじめ予測することができます。未然に誤解を生じないような対応は必要ですが、立場の違いから生じる「見解の相違」が避けられないことがあります。それは、基準や法令の解釈そのものというよりも、事実の当てはめにあると思われます。

たとえば、研究開発費とは認められない作業内容として見解の相違があると想定される場合を想定して、ソフトウェア仮勘定にいつでも組み込んで再計算できる準備をしておくことが望ましいと考えられます。作業内容の集計をまた最初からやり直すということのロスは避けなければなりません。

労働法上のコンプライアンスの問題

作業内容について各従業員の申告に委ねようとする場合、経営サイドにとって躊躇することがあります。

それは、労働基準法上のコンプライアンスの問題です。

もろもろの事情により、本来ならば支払義務が生じる時間外手当、深夜残業手当、休日手当などが支給されていない場合に、これらの時間管理を申告させるということは、あるべき論はともかく現実問題として悩ましいという考え方があります。

ところで、ソフトウェア開発にかかわる従業員には、専門業務型裁量労働制（労働基準法38条の3）が適用されると考えられます。

しかし、専門業務型裁量労働制に係る労使協定を結んでいても、協定内容に違反していたり、深夜残業手当や休日手当が支給されていない場合もありえます。

裁量労働制が適用される従業員に対しては、労使協定で、対象業務を遂行する手段、時間配分の決定等に関して具体的な指示をしない旨を締結することが必要です。

このため、「裁量労働制なのに、なんで時間管理をされないといけないのか」という従業員からの疑問や誤解が生じるところです。

しかし、労使協定で、使用者（企業）が行う労働者（従業員）の労働時間の状況に応じた健康・福祉を確保するための措置と、従業員からの苦情を処理するための措置を講じることとなっており、それを担保する意味もあり、対象従業員の労働時間の状況を記録することを取り決めています。

そのため、業務を遂行する手段や時間配分については事前に従業員に指示することはできませんが、従業員から事後的に業務の内容を申告してもらうよう依頼することになります。

（つづく）