システム開発業の原価管理：売上原価の範囲・工数×賃率の計算と月次レビューの手順

IT企業やシステム開発業の原価管理がうまくいかない原因の多くは、現場の入力精度ではなく費用の区分にあります。同じエンジニアの給与でも、売上原価に入れる会社と販売費及び一般管理費に残す会社があり、どちらも会計基準に違反しません。区分が決まらないまま工数を集めても、案件別の粗利は動くたびに意味が変わります。この記事では、原価計算基準と収益認識会計基準の条文を起点に、売上原価に入れる費用の線引き、工数と賃率で原価を積み上げる手順、月次の原価レビューで何を見るか、原価率をどう読むべきかを順に整理します。

まとめ：システム開発業の原価管理で最初に決める3つのことと月次レビュー

結論から示します。システム開発業の原価管理は、次の3点を先に文書で決め、月次のレビューで回せば実務が安定します。

• 売上原価の範囲：どの職種・どの作業を売上原価に入れるかを機能で定義する。原価計算基準にも財務諸表等規則にも「エンジニアの給与は売上原価」という規定はなく、決めるのは自社です。
• 賃率：人件費を工数に乗せる時間単価を、会社負担の法定福利費を含めて算定する。原価計算基準三二(二)が直接労務費を「実際の作業時間又は作業量に、その賃率を乗じて計算する」と定めており、IT企業でもこの形が原型になります。
• 間接費の配賦率：期首に予定配賦率を置く。原価計算基準三三(二)は「間接費は、原則として予定配賦率をもって各指図書に配賦する」としており、月末に実績を割り振る運用は原則から外れます。

この3点を決めたうえで、毎月の原価レビューでは「完成時総原価の見込み」「未承認工数」「案件間振替」の3つを必ず確認します。3点が決まっていない状態では、工数管理ツールを入れても出てくる数字は安定しません。以下では、原価計算の枠組みがIT企業とどこで噛み合わないのかから見ていきます。

原価計算基準にソフトウェアの語が1つも無いという前提と財務諸表等規則の扱い

日本の原価計算の土台は、企業会計審議会が昭和37年11月8日に設定した原価計算基準です。ところがこの基準の全文（約27,000字）を検索すると、「ソフトウェア」「役務」「サービス」「受注」という語は1件も出てきません。基準が想定しているのは、材料を仕入れて製品を作る生産形態です。

それでもIT企業が原価計算基準を使えるのは、三一の個別原価計算がそのまま読み替えられるからです。条文は「個別原価計算は、種類を異にする製品を個別的に生産する生産形態に適用する」「個別原価計算にあっては、特定製造指図書について個別的に直接費および間接費を集計し、製品原価は、これを当該指図書に含まれる製品の生産完了時に算定する」と定めています。この「特定製造指図書」を「案件番号」または「プロジェクトコード」に置き換えたものが、IT企業のプロジェクト別原価計算です。工程の考え方はプロジェクト別原価計算の基本構造と総合原価計算との実務上の違いに整理しています。

もう一段ずれるのが開示側です。財務諸表等の用語、様式及び作成方法に関する規則（e-Gov法令検索）の75条は、売上原価を「期首棚卸高」「当期商品仕入高又は当期製品製造原価」「期末棚卸高」の3科目で掲記せよと定めています。棚卸資産を持たない受託開発では、この3科目は成立しません。その場合の逃げ道が77条で、「区分して記載することが困難であると認められる場合又は不適当と認められる場合には、適用しない。この場合においては、売上原価の内訳を記載した明細書を損益計算書に添付しなければならない」と規定しています（2026年10月時点の現行条文で確認）。IT企業の売上原価の中身は、規則が形を決めているのではなく、自社が作る明細書が決めている。この一点を押さえると、次の線引きの話が実務判断だと理解できます。

売上原価に入れる費用と販管費に残す費用の線引き：人件費・外注費・クラウド

エンジニアの人件費を売上原価に入れる判断基準は人でなく時間で決める

「IT企業の人件費は原価か販管費か」という問いに、条文レベルの正解はありません。原価計算基準三七(一)は、販売費及び一般管理費の形態別分類の例として「給料、賃金」を挙げています。つまり給与という費目そのものは、原価にも販管費にも入りうるという前提で基準が書かれています。

実務で分けるなら、費目ではなく機能で判定します。特定の案件の成果物を作るために費やした時間は売上原価、案件に紐づかない時間は販管費です。同じエンジニアでも、要件定義から検収までの作業時間は売上原価、社内勉強会や採用面接の時間は販管費になります。判定を人ではなく時間に対して行う点が要点で、これを守らないと稼働率の低い月に原価だけが膨らむためです。人件費を原価に含める範囲や賃率の考え方そのものは原価計算における人件費の扱い方｜原価に含める範囲・賃率の出し方・販管費との線引きで扱っています。

外注費・ライセンス費・クラウド利用料を直接費と間接費に分ける5区分

案件に直接紐づく協力会社への外注費は、迷わず売上原価です。判断が割れるのはライセンス費とクラウド利用料で、次の順に見ると整理できます。

共通の開発ツールを販管費に落とすと、開発部門のコストが見かけ上軽くなり案件の粗利が過大に出ます。開発活動のために消費した以上は間接費として売上原価に入れ、配賦で案件に配る扱いが素直です。なお自社サービスの開発費をソフトウェアとして資産計上する場合は費用処理と別の判断が要るため、経理担当者が最初に理解すべきソフトウェア資産化の定義と会計基準上の位置づけを先に確認してください。

販管費に残す費用と、原価計算基準三九による技術研究費の別建て

営業部門、管理部門、経営層の人件費と、それらが使う家賃・通信費は販管費です。判断に迷いやすいのが、案件に紐づかない技術検証や新技術の調査です。原価計算基準三九は「新製品又は新技術の開拓等の費用であって企業全般に関するものは、必要ある場合には、販売費および一般管理費と区別し別個の項目として記載することができる」と定めています。研究開発的な工数を案件原価にも一般管理費にも混ぜず、技術研究費として独立させておくと、粗利の悪化が案件のせいか投資のせいかを後から切り分けることが可能です。エンジニアの稼働を案件・社内投資・非稼働の3つに分ける発想は間接工数とは？直接工数との違いと区分の判断基準・直工率の計算方法で詳しく扱っています。

工数と賃率でプロジェクト原価を積み上げる手順：賃率の算定から予定配賦まで

賃率の作り方と月給40万円・法定福利費約15.7%での時間単価の試算

原価計算基準三二(二)は、直接労務費を「当該指図書に関する実際の作業時間又は作業量に、その賃率を乗じて計算する」と定めています。監査の側からも同じ形が求められており、日本公認会計士協会の監査基準報告書540実務ガイダンス第2号（建設業及び受注制作のソフトウェア業における収益の認識に関する監査）の付録18項は、人件費について「職位に応じて適切な賃率等が設定されている場合、これに適切に見積もられた工数を乗じた計算」を実行予算の積上げ方法として挙げています。

賃率の分子は給与総額ではなく、会社負担の法定福利費を含めた人件費です。東京の協会けんぽ・40歳未満・令和8年度の料率（協会けんぽ 令和8年度保険料率）で会社負担分を積むと、健康保険9.85%と子ども・子育て支援金0.23%の折半分が5.04%、厚生年金18.300%の折半分が9.15%、子ども・子育て拠出金0.36%が事業主全額、雇用保険の事業主負担が0.85%、労災保険（その他の各種事業）が0.3%で、合計は月額給与のおよそ15.7%です。

賃率は462,800円÷160時間＝2,892.5円を円未満四捨五入した値です。端数処理の方法は社内規程で先に決めて固定してください。この賃率にSE（システムエンジニア）の案件別の実作業時間を乗じた額が直接労務費です。賞与や退職給付を月次に按分するかどうかで賃率は1割前後動くため、算定式は年に1回見直し、期中は固定して使います。期中に賃率を変えると、同じ工数でも月によって原価が変わり、案件間の比較が成り立たなくなります。

工数の記録にJICPA実務ガイダンスが求める日報の規定・承認・モニタリング

工数入力の運用ルールは、現場の使いやすさだけで決めるものではありません。JICPA実務ガイダンス付録22項は、作業日報に基づいて人件費を集計している場合の内部統制として、作業日報の作成に関する規定、作成された日報が実態に合っているかを確認するモニタリング、日報を変更する際の手続、そして日報の承認の4点を挙げています。

入力率だけを追いかけている組織は、このうち承認とモニタリングが抜けがちです。承認者が不在のまま集めた工数は、原価計算の入力データとしては使えても、決算数値の裏づけにはなりません。工数管理の運用が崩れる構造的な要因は開発現場で工数管理が破綻する背景と見積もり精度を左右する構造的要因で整理しています。

間接費は予定配賦率が原則：月末の実績按分で閑散期の案件が赤字に見える理由

ここが実務で最も原則から外れやすい箇所です。原価計算基準三三(二)は「間接費は、原則として予定配賦率をもって各指図書に配賦する」と明言しています。(三)では部門間接費の予定配賦率を「一定期間における各部門の間接費予定額又は各部門の固定間接費予定額および変動間接費予定額を、それぞれ同期間における当該部門の予定配賦基準をもって除して算定する」とし、(五)で予定操業度を「原則として、一年又は一会計期間において予期される操業度」としています。

月末に実際発生した間接費を、その月の工数で割って配る運用は、基準が原則としている方法ではありません。この方式では、案件が少ない月ほど1件あたりの間接費が跳ね上がり、閑散期の案件だけが赤字に見えます。期首に年間の間接費予定額と年間の予定総工数を置いて配賦率を固定し、実績との差額は原価差異として期末に処理する形に切り替えると、月次の粗利が案件の実力を映すようになります。たとえば年間の間接費予定額が2,040万円、年間の予定総工数が24,000時間なら、予定配賦率は1時間あたり850円です。

収益認識会計基準が変えた原価の期間帰属：進捗度・原価回収基準・付け替え防止

進捗度の見積りに原価総額を使うとき原価計算の精度が売上を決める仕組み

2021年4月1日以後開始する事業年度から収益認識会計基準（企業会計基準委員会：改正企業会計基準第29号「収益認識に関する会計基準」等の公表）が適用され、工事契約に関する会計基準（企業会計基準第15号）は廃止されました。「工事進行基準」「工事完成基準」という用語は現行制度には存在しません。受託開発は、一定の期間にわたり充足される履行義務に該当すれば、履行義務の充足に係る進捗度に応じて収益を認識します。

進捗度の見積りにコストを使う場合、分母は工事原価総額の見積り、分子は決算日までに発生したコストです。つまり原価計算の精度が、そのまま売上計上額の精度を左右する関係です。進捗度を合理的に見積もれないが発生する費用の回収が見込まれる場合には、見積もれるようになる時まで原価回収基準で処理します。JICPA実務ガイダンス付録25項は、この判断が漏れなく行われているか、つまり原価回収基準を適用していない案件について承認を得ているかまで内部統制の論点としています。

プロジェクト間の原価付け替えを止める理由コード・承認・外注請求の検証

案件別の原価が動くと、収益の計上額もそれに伴って動く関係です。だからこそ実務ガイダンス付録23項は「関連のない他の識別された履行義務に係る認識の単位との間の発生したコストの振替及び付け替えの防止」を独立の論点として立て、振替を行う際の振替理由と手続を定めること、外注業者からの請求書についてどの案件のコストでどのような作業を実施したかを事後的に検証できるようにすることを求めています。付録21項(1)⑤では、他案件のコストや関連性のない外注費（架空外注費を含む）が発生したコストに混入して進捗度が過大に見積もられるリスクの防止を挙げています。

赤字案件の原価を黒字案件に付け替える操作は、社内では調整に見えても、会計上は収益の前倒し計上に直結します。振替に理由コードと承認を必須にし、承認なしの案件間振替をシステムで禁止するところまでやって、はじめて原価データが決算に使える品質になります。

システム開発業の原価管理レビュー：月次で見る5指標と予実差異の読み方

原価の区分と賃率が決まっても、数字を誰も見なければ管理になりません。システム開発業の原価管理で「レビュー」と呼ぶのは、案件ごとの実績原価と見込みを月に1回突き合わせ、完成時の着地を修正する会議体のことです。原価管理全体の目的と4ステップは原価管理とは？目的・進め方4ステップと差異分析からシステム化の判断まで解説にまとめているので、ここではIT企業の受託案件に絞って、レビューで見る項目と手順を具体化します。

月次の原価レビューで確認する5指標：消化率・完成時総原価・粗利見込み・未承認工数・振替

レビューの議題は、毎月同じ5指標に固定します。項目を固定すると、前月との比較で異常が浮きます。

「要説明の目安」の10%や10ptは、社内規程で決める閾値の一例です。条文で定まった数値ではないので、案件規模に合わせて置き直してください。大事なのは、閾値を超えた案件だけを議題にして、全案件を毎回読み上げない運用にすることです。

完成時総原価の見直しと工事損失引当金の判定をレビューで回す3段階

レビューの中心は、完成時総原価（業界ではEACとも呼ぶ）の見直しです。手順は3段階に分けます。第1に、プロジェクトマネージャーが残作業を工数で積み直し、賃率と予定配賦率を掛けて残原価を出します。第2に行うのは、実績原価と足して完成時総原価を更新し、実行予算との差を説明する作業です。第3に、完成時総原価が契約金額を上回った案件を、損失引当の検討対象として経理へ回します。

この3段階目を月次レビューに組み込んでおくと、JICPA実務ガイダンス付録27項が論点とする「実行予算等の見積額を検討し、計上について承認を得る」流れが、決算期だけの作業ではなくなります。逆に、完成時総原価を期末にまとめて見直す運用では、損失が見えた時点と計上する時点がずれ、四半期ごとの業績が大きく振れる原因になるためです。予算と実績を案件単位でつなぐ考え方はプロジェクト予算管理とは？案件別の予実管理・工数連動の原価把握と進め方を解説でも扱っています。

SQLで案件別の予実差異と完成時粗利を出すクエリ例とテーブル構成

工数と外注請求がデータベースに入っていれば、レビュー資料は1本のクエリで作れます。次の例は PostgreSQL 16系を想定した書き方で、テーブル名と列名は説明用の仮のものです。前提は4つのテーブルで、timesheets（日報：案件・等級・作業日・時間・承認日時）、labor_rates（等級別・年度別の賃率）、vendor_invoices（外注請求：案件・請求日・金額）、projects（案件：契約金額・実行予算・完成時総原価の見込み・状態）です。

-- 案件別の予実差異と完成時粗利（2026年9月締めの月次レビュー用）
WITH actual AS (
  SELECT t.project_id,
         SUM(t.hours)          AS hours,
         SUM(t.hours * r.rate) AS labor_cost
  FROM   timesheets t
  JOIN   labor_rates r
         ON r.grade = t.grade AND r.fiscal_year = 2026
  WHERE  t.approved_at IS NOT NULL            -- 承認済みの工数だけを原価に入れる
    AND  t.work_date <= DATE '2026-09-30'
  GROUP  BY t.project_id
),
vendor AS (
  SELECT project_id, SUM(amount) AS outsourcing_cost
  FROM   vendor_invoices
  WHERE  invoice_date <= DATE '2026-09-30'
  GROUP  BY project_id
),
cost AS (
  SELECT p.project_id, p.contract_amount, p.budget_cost, p.eac_cost,
         COALESCE(a.labor_cost, 0)
       + COALESCE(v.outsourcing_cost, 0)
       + COALESCE(a.hours, 0) * 850 AS actual_cost  -- 850円/時間＝期首に決めた予定配賦率
  FROM   projects p
  LEFT JOIN actual a ON a.project_id = p.project_id
  LEFT JOIN vendor v ON v.project_id = p.project_id
  WHERE  p.status = 'active'
)
SELECT project_id,
       actual_cost,
       ROUND(100.0 * actual_cost / NULLIF(eac_cost, 0), 1) AS consumption_pct,
       eac_cost - budget_cost                                AS eac_overrun,
       contract_amount - eac_cost                            AS forecast_gross_profit,
       CASE WHEN eac_cost > contract_amount   THEN '損失引当を検討'
            WHEN eac_cost > budget_cost * 1.1 THEN '要説明'
            ELSE '' END                                      AS review_flag
FROM   cost
ORDER  BY forecast_gross_profit;

ポイントは2つあります。1つ目は、承認日時が空の日報を集計から外していることです。これで未承認工数が原価に混ざらず、別のクエリで未承認の件数を数えれば5指標の4番目がそのまま出ます。2つ目は、間接費を実績按分せず、工数×予定配賦率で載せていることです。月によって配賦額が跳ねないので、消化率の推移がそのまま案件の進み具合を映します。エクセルで同じ計算をする場合の列設計はエクセルで原価計算する方法｜原価率・売上原価の計算式と崩れない表の設計が参考になります。

レビュー会議を形骸化させない運用：出席者・締め日・差し戻し基準の決め方

原価レビューが形だけになる典型は、「資料は出るが誰も判断しない」状態です。避けるには、出席者を案件のプロジェクトマネージャー、開発部門長、経理担当の3者に固定し、判断の権限を持つ人を必ず入れます。日程は日報の締め日から5営業日以内に置きます。それより遅いと、翌月の作業が進んでしまい手当てが間に合いません。

差し戻しの基準も、あらかじめ決めておく事項です。完成時総原価の見込みに根拠となる残工数の内訳が無い場合、案件間振替に理由コードが無い場合は、その場で承認せず翌週までの再提出とします。基準を文書にしておけば、レビューの記録がそのまま監査で問われる内部統制の証跡になります。

受託開発・SES・SaaSで変わる原価設計：集計単位・直接費・採算の見方

同じIT企業でも、契約形態が変われば原価の集計単位が変わります。

SESは1人あたりの単価と賃率を突き合わせるだけなので、案件別原価計算そのものは軽く済みます。ただし待機期間の人件費をどこに置くかで採算の見え方が変わり、待機を売上原価に残すと稼働中の要員の利益が見えなくなります。待機工数は間接費に振り、稼働率とセットで管理する形が扱いやすい設計です。

SaaSで難しいのは、開発費を資産計上するか費用処理するかで売上原価が大きく動く点です。自社利用ソフトウェアの制作費は、将来の収益獲得または費用削減が確実であると認められる場合に資産計上する扱いで、この判定を経ずに全額を売上原価に入れると初年度の原価率だけが跳ね上がります。PoCや要件定義の費用をどちらに置くかの判定基準はシステム開発費の資産計上と費用処理｜判定基準・PoC・要件定義の扱いを参照してください。

原価率と粗利率の目安：情報通信業の営業利益率8.4%と他社比較が成立しない理由

業種平均として参照できる公的数値は、財務省の法人企業統計調査（年次別調査）です。2026年9月1日公表の令和7年度の結果の第4表「売上高利益率の推移」から、情報通信業と全産業を抜き出すと次のとおりです（金融業、保険業を除く）。

情報通信業の営業利益率は全産業を3.0ポイント上回ります。令和4年度の9.5%から令和6年度の8.2%まで下がった後、令和7年度は8.4%へ持ち直しました。自社の営業利益率を測る基準としては、この8%台前半が実勢に近い水準です。

一方で、「システム開発の原価率の業界平均」を他社と比べる作業には意味がありません。法人企業統計調査や中小企業実態基本調査は業種別の売上原価を収録しているので、情報通信業の平均原価率を計算すること自体はできます。しかしその平均は、ここまで見たとおり区分方針がばらばらな各社の数字を足し合わせたものです。エンジニアの人件費を売上原価に入れるか販管費に残すかは各社の判断なので、原価率が60%の会社と80%の会社の差は、採算の差ではなく区分方針の差であることが普通に起こります。原価率が上がればその分だけ売上総利益率、つまり粗利率が下がりますが、この粗利率も同じ理由で他社と横並びにできません。比較するなら、区分の定義に左右されない売上高営業利益率を使うか、自社の原価率を時系列で追ってください。区分方針を変えた期は、前期の数字も新方針で組み替えないと比較になりません。

原価管理をエクセルで続けるかシステム化するかの判断条件と見送ってよい場面

ここまでの仕組みを、どの道具で回すかを決めます。判断は案件数の多さより、月次レビューと監査の要件を手作業で満たせるかで決まります。

システム化を採用する条件は、次のいずれかに当てはまる場合です。同時に走る受託案件が20件を超え、レビュー資料の作成に締め後3営業日以上かかっている。一定の期間にわたり収益を認識する案件があり、進捗度の根拠として承認済み工数と外注請求の紐づけを残す必要がある。案件間振替の承認履歴を監査法人から求められている。この3つのどれかに当たるなら、日報・賃率・配賦・振替承認を1つのデータベースで持つ構成へ移す時期です。

見送ってよい場面もはっきりしています。案件が10件未満で、検収基準（完了時に一括で収益認識）の案件しかなく、上場や監査の予定もない会社なら、エクセルと日報の承認ルールで足ります。ここで高価なパッケージを入れても、入力の手間が増えるだけです。

パッケージの工数管理ツールで足りないのは、自社の賃率規程・予定配賦率・振替の理由コードをそのまま組み込みたい場合です。一創では、既存の会計システムや勤怠データと連携させた原価管理システム開発を受託しており、案件別の予実差異や完成時粗利をレビュー資料として出す仕組みまで含めて設計できます。ツールのタイプ別の比較軸は原価管理システムの比較で見る6つの軸｜タイプ別選定基準とランキングの読み方にまとめています。

よくある質問

システム開発業・IT企業の原価管理について、よく寄せられる質問に答えます。

IT企業の人件費は売上原価と販管費のどちらに入れますか？

どちらでも会計基準に反しません。原価計算基準三七(一)は販売費及び一般管理費の形態別分類の例として「給料、賃金」を挙げており、給与という費目が販管費に入ることを前提にしています。実務では、特定案件の成果物を作るために費やした時間を売上原価、案件に紐づかない時間を販管費とし、人単位ではなく時間単位で判定する方法が扱いやすい設計です。

システム開発の原価率に業界標準の目安はありますか？

公的統計から平均原価率を計算することはできますが、比較の物差しにはなりません。売上原価の範囲が各社の方針で決まるため、原価率も粗利率も他社と横並びにできない指標だからです。業種平均として参照できるのは法人企業統計調査の売上高営業利益率で、情報通信業の令和7年度は8.4%（全産業5.4%）でした。

SES事業でも案件別の原価計算は必要ですか？

必要です。SESは要員×月が集計単位になるため計算自体は軽く済みますが、契約単価と賃率の差が採算そのものなので、賃率を持たないと1人あたりの利益が見えません。待機期間の人件費は間接費に振り、稼働率と合わせて管理します。月次の原価レビューでは、待機工数の推移を稼働率と並べて確認すると、要員計画の遅れが早く見えます。

システム開発業の原価管理レビューは誰がどの頻度で行いますか？

月1回、日報の締め日から5営業日以内に、プロジェクトマネージャー・開発部門長・経理担当の3者で行う形が回しやすい設計です。議題は原価消化率、完成時総原価の見込み、完成時粗利の見込み、未承認工数、案件間振替の5指標に固定し、閾値を超えた案件だけを扱います。完成時総原価が契約金額を上回った案件は、その場で損失引当の検討に回します。

赤字が見込まれるプロジェクトはいつ損失を計上しますか？

損失が見込まれ、その金額を合理的に見積もることができる時点で引当計上します。JICPA実務ガイダンス付録27項は、工事損失引当金の計上方針、収益総額の見積方法、原価総額の見積方法を定めたうえで、実行予算等や販売直接経費の見積額を検討し、計上について承認を得ることを内部統制の論点としています。案件完了を待って損失を認識する処理は認められません。

関連記事

• 原価計算における人件費の扱い方｜原価に含める範囲・賃率の出し方・販管費との線引き
• プロジェクト別原価計算の基本構造と総合原価計算との実務上の違い
• 経理担当者が最初に理解すべきソフトウェア資産化の定義と会計基準上の位置づけ
• 間接工数とは？直接工数との違いと区分の判断基準・直工率の計算方法
• 原価管理システムの比較で見る6つの軸｜タイプ別選定基準とランキングの読み方