ITプロジェクトの原価計算と外注管理の指針

外注費が原価の過半を占める構造を前提に設計する

システム開発やSIのプロジェクトでは、自社の直接工数よりも外注費の方が原価の大半を占めることが珍しくありません。この構造を前提とせずに、内製の工数管理だけに力を入れて原価計算の仕組みを設計してしまうと、実際の採算とはかけ離れた数字しか得られません。まずは案件ごとの原価に占める外注費の比率を把握し、その比率が高い案件ほど、発注書・検収・請求のプロセス管理に重点を置くという優先順位づけが必要になります。

検収基準を明確にし原価計上のタイミングを揃える

外注先から成果物が納品された時点と、実際に自社での検収が完了した時点にはズレが生じることがよくあります。このズレを放置すると、外注費の計上タイミングが月をまたいでしまい、案件別損益の月次比較が意味をなさなくなります。検収完了をもって原価計上する、あるいは進捗に応じて按分計上するなど、案件の性質に応じた基準をあらかじめ定め、営業・開発・経理の三者で共有しておくことが、原価計上のブレを防ぐ鍵になります。

多重下請け構造がもたらす原価の見えにくさ

IT業界特有の多重下請け構造では、元請けから見て二次請け、三次請けの原価構造がブラックボックス化しやすく、外注先からの請求金額が適正かどうかの判断が難しくなります。またこの構造は、実質的な指揮命令が発注元から下請けの作業者に直接及んでしまう、いわゆる偽装請負のリスクとも隣り合わせです。原価計算の精度を上げることは、単なる会計上の関心にとどまらず、契約形態の適正化という法務的なリスク管理にもつながっている点を見落としてはいけません。

内製と外注のコスト比較を仕組み化する

ある工程を内製するか外注するかの判断は、案件が始まる前の見積段階で最も重要な意思決定の一つです。自社の予定賃率で算出した内製コストと、外注先からの見積金額を並べて比較できる仕組みがあれば、価格だけでなく納期リスクや品質リスクも含めた総合判断がしやすくなります。この比較を毎回ゼロから行うのではなく、過去案件の実績データを蓄積し、類似案件の判断材料として使えるようにしておくことが、判断の精度とスピードの両方を高めます。

エンプレックス時代に見たSI業界の原価管理の難しさ

私はエンプレックスでCFOを務めていた時代、ITCRMソフトウェアの受託開発や導入支援といったSI型のビジネスの経営管理に深く関わりました。当時強く感じたのは、開発が佳境に入り仕様変更や追加対応が重なるほど、外注先への追加発注が現場の裁量で先行し、経理側での原価把握が後追いになりやすいという構造的な難しさです。この経験から、外注発注そのものを案件コードと連動させ、発注段階で原価が見える仕組みを整えることの重要性を痛感しました。

外注先ごとの実績データを次の見積に活かす

外注管理を単なる支払い管理で終わらせず、外注先ごとの品質・納期遵守率・追加費用の発生頻度といった実績データを蓄積していくと、次のプロジェクトの見積精度が着実に向上していきます。過去に追加費用が発生しやすかった外注先には、あらかじめ見積に一定のバッファを積んでおくといった判断ができるようになります。この蓄積は一朝一夕にはできませんが、200社を超える企業を見てきた中でも、この習慣がある会社ほど見積の的中率が高い傾向がはっきりと表れていました。

契約変更管理と原価計算を連動させる

IT開発案件では、要件定義後の仕様変更や追加開発が頻発します。これらを個別の追加契約として明確に切り分け、原価計算上も元の案件と紐づけつつ区分して集計できるようにしておかないと、当初見積との比較そのものが意味を失います。契約変更が発生した時点で速やかに原価計算システム側にも反映させる運用フローを整えておくことが、外注管理と原価管理を破綻させないための実務上の生命線になります。

まとめ

ITプロジェクトの原価計算は、外注費という自社の外側にあるコストをいかに正確かつタイムリーに取り込むかで、その精度の大半が決まります。多重下請け構造の複雑さに委縮するのではなく、検収基準や契約変更のルールをあらかじめ整えておくことで、見通しの良い原価管理は十分に実現できます。外注は管理し切れないブラックボックスではなく、ルールさえ整えれば見える化できる相手だと捉え直すことこそが、ITプロジェクトの採算改善への確かな近道です。