原価管理システムの要件定義は、原価計算ロジックの棚卸し、生産形態と連携範囲の整理、RFPへの反映の順に進めると、現場に合う提案につながります。
発注企業の視点から、原価管理システムのRFP・要件定義書・提案依頼書を具体的に扱います。全体像は原価管理システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・原価管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
自社の原価計算ロジックの棚卸し
原価管理システムの要件定義では、欲しい機能を並べる前に、自社が今どのように原価を計算しているかを徹底的に棚卸しし、見える形にします。長年の慣行や製品ごとの取り決めは言語化しないと、現場に合わないシステムになりやすいため、この作業は欠かせません。
現状の原価計算フローの洗い出し
まず、現状（AsIs）の原価計算フローを押さえます。経理や現場への聞き取りでは、材料費の集計、労務費の賃率、間接費の配賦基準、Excelでの集計方法を確認します。特に現場には、製品固有の配賦やベテランの判断など、明文化されていない計算が必ずあります。
- 実際の計算：規程の手順に加えて、現場の運用を記録する
- 例外処理：製品固有の配賦や担当者の判断を拾い上げる
- 配賦基準：複数ある場合に、根拠と適用範囲を明記する
経理、生産管理、製造現場の担当者に確認し、明文化されていない計算まで把握します。例外を見落とすと、移行後に原価が合わなくなるおそれがあるため、この作業は省けません。こうした地道な作業が、要件漏れを防ぎ、現場に使われるシステムにつながります。
ToBeの「あるべき原価管理の姿」の設計
AsIsを押さえた後は、導入後に実現したいToBeモデルを描きます。Excel集計の自動化、差異分析、月次決算の早期化など、目指す業務を具体化すると、そこから必要な機能を逆算できます。
- 現状を移す：現在の計算ロジックを、そのままシステムに載せる
- 計算を見直す：配賦の標準化など、業務改革を伴う形で計算を組み直す
どの方針をとるかは発注側が決め、業務改革を伴う場合は、社内の合意形成も要件定義に含めます。現状を移すだけなら早く済みますが、精度向上を目指すなら、ToBeであるべき計算を定義する必要があります。
riplaはフルスクラッチ受託の立場から、現状を起点にしたToBe設計を重視しています。
生産形態ごとに変わる原価管理の要件
原価管理の要件は生産形態で変わります。受注生産か見込生産か、個別受注か量産かで、原価を捉える単位が違うためです。
生産形態とシステムが合わないと、導入の失敗につながります。まず、自社の形態を明確にし、それに対応する原価計算の単位を要件に定めます。
個別受注生産で必要な案件単位の原価計算
個別受注生産は製品ごとに仕様が異なるため、案件（オーダー）単位の個別原価計算が要件になります。見積り時の予定原価と実際原価を照合して、案件ごとの利益を確定します。
- 原価の集約：案件番号やプロジェクトコードで、原価をまとめる
- 変更時の処理：追加発注や仕様変更で増える原価の扱いを定める
- 長納期案件：月をまたぐ仕掛品の評価方法
量産向けのパッケージは案件単位の管理に向かず、現場で使えない場合があります。一方で、受注生産向けの国内パッケージには、Excelダイレクト出力や専用の原価集計を標準で備える製品もあります。
個別受注を行う企業は、案件別の原価管理に強い製品を前提に要件を組み立てます。
見込・量産で必要な製品別の総合原価計算
見込生産や量産では、同じ製品を繰り返し作るため、製品単位・期間単位の総合原価計算が中心になります。一定期間の製造費用を、その期間の生産量で割って、製品原価を求めます。
- 計算の粒度：月次や週次など、どの単位で原価を出すかを決める
- 仕掛品とロス：仕掛品の評価と、歩留まり・ロスの反映方法
- 標準原価：マスタ管理と、差異の要因別分析を要件に含める
- 収益把握：製品別の収益を一覧できる形で、要件に盛り込む
量産では、標準原価との差異を分析する運用が効果的です。個別受注と量産の両方を扱う企業は、どの製品群にどちらの方式を当てはめるかを整理します。
生産形態が曖昧なままだと、稼働後に自社の原価計算方式へ対応できないと分かり、大きな手戻りが起きるおそれがあります。
ISA-95を前提とした生産管理・会計との役割分担
原価管理システムは、ERP・生産管理・MES・会計システムと連携して正確な原価を算出します。連携が前提のため、要件定義では各システムの役割を明確にしておきます。
境界が曖昧だと、データの二重管理や連携漏れが起きます。どのシステムが何を持つかを、データの流れとあわせて定義します。
計画層・実行層・原価の境界の定義
ISA-95の階層モデルでは、ERPが計画層に、MESや生産管理が実行層に位置づきます。原価管理システムは、この両層からデータを受け取ります。
- 生産実績：実績工数と実績数量を、生産管理・MESから取り込む
- 費用データ：材料単価と労務費の金額を、会計から取り込む
- 原価計算：原価管理システムでの計算と差異分析
- 会計への連携：確定した原価差異を、会計へ戻す
この流れを図にすると、各システムのマスタと連携インターフェースの要件が明確になります。日本固有の生産管理システムと、グローバル標準のMESは機能が重なるため、自社でどちらが各実績を持つかを整理します。
役割を図で示すと、RFPを受け取るベンダーが前提を把握しやすくなり、提案の精度向上につながります。一方で、境界があいまいなままだと、二重入力やデータ不整合を招きます。
Excel連携とデータ移行の要件
既存のExcel資産との連携は、原価管理の要件から外せません。曖昧なままだと、CSV変換時の文字化けや列ずれで作業が増え、現場の反発を招くことがあります。
- 部品表の取込：設計部門のExcelから、部品表を直接取り込む
- 集計結果の出力：CSV変換を挟まず、Excel形式で出力する
- 既存資産の活用：VLOOKUPやマクロを、そのまま活かせる状態にする
データ移行では、過去の原価実績をどこまで移すか、品目コードや工程コードをどう統一するか、移行したデータをどう検証するかを決めます。
Excelを完全にはなくさず、集計と差異分析はシステムで、分析や経営報告は使い慣れたExcelで行う段階移行が現実的です。この役割分担を要件段階で固めておくと、現場の納得感につながります。
Excel連携は原価管理システム特有の重要な論点なので、RFPに盛り込みます。
RFPに盛り込む項目と見積りの妥当性判断
要件を固めたら、RFP（提案依頼書）に落とし込みます。RFPの質が、ベンダーから返る提案と見積りの質を左右します。
機能だけでなく、原価計算ロジック、生産形態、既存システムとの連携前提も記載します。正確な提案を受けるには、必要な情報を揃えておくことが欠かせません。
RFPに必ず盛り込むべき項目
原価管理システムのRFPには、導入の目的とゴールとして決算早期化や差異分析による原価低減などを書いたうえで、次の4項目を盛り込みます。
- 計算方式：個別・総合の別と、標準原価の有無
- 機能・連携：集計、配賦、差異分析、収益把握と、生産管理・会計・Excelとの連携
- 非機能・移行：データ量に応じた処理速度、利用人数、セキュリティ、移行要件
- 計画・予算：想定スケジュールは一般に3〜6ヶ月で、予算感も記載する
目的から予算まで揃って初めて、ベンダーは精度の高い提案を返せます。
非機能要件では、自社の実データ量で集計が現実的な時間に終わるか、同時利用人数に耐えられるかを明記します。可能であれば、PoCで実機検証を求めます。
自社の実態を具体的に書くほど、見積りの精度が上がり、後のカスタマイズ費の膨張も防ぎやすくなります。一方で、「原価管理ができること」程度の曖昧なRFPでは、各社の見積りがばらつき、比べられなくなります。
費目別に見る見積りの妥当性
見積りは総額だけでなく内訳で判断します。原価管理を含む生産管理システムでは、中小でも初期費用800万〜1,500万円が目安です。
このうちカスタマイズ費は200〜300万円で、全体の3〜4割を占めるのが実態です。相場から大きく外れる見積りは、その理由を確認します。
- 従業員10〜30名：初期100〜300万円、5年TCO 400〜900万円
- 従業員50〜100名：初期400〜1,000万円、5年TCO 1,600〜3,400万円
- 費目の内訳：ライセンスから保守まで、費目ごとに分けて見る
カスタマイズ費が高い場合は、標準機能と要件が合っていない可能性があります。そのため、要件を見直したり、スコープを段階に分けたりすると、費用を抑えられることがあります。
導入前のコンサルは人月100〜200万円が目安です。また、マスター登録や現場教育を内製化すれば、200〜400万円を削減できます。
費目ごとに、必要性と内製化の可否を確認すると、妥当な投資判断につながります。
非機能要件とPoC・補助金申請の要件整理
機能要件に加えて、非機能要件とPoC・補助金申請の条件も整理します。原価管理は決算に直結し、大量のデータを扱うためです。
性能や検証の条件が曖昧だと、稼働後に集計が終わらない、想定外の負担が出るといったことが起こり得ます。そのため、要件段階で詰めておくことが、安定稼働とコストの抑制につながります。
処理速度・利用人数・セキュリティの非機能要件
非機能要件では、まず処理性能を定めます。原価計算は大量の実績データを扱うため、月次の集計が現実的な時間で終わるか、自社のデータ量で速度が落ちないかを確認します。
- 処理性能：自社データでの集計時間と処理速度
- 利用負荷：同時利用人数と、繁忙期のピーク負荷
- アクセス制御：役職や部門に応じた閲覧範囲
- データ保管：自社内に置くか、クラウドにするか
数万件の実績を流すと、集計に何時間もかかるケースもあります。RFPにデータ件数、利用人数、応答時間の目標を具体的に書くほど、提案の精度が上がります。
原価データには、製品別利益や得意先別採算などの機密情報が含まれます。そのため、権限を細かく設計すると、情報を守りながら必要な人に届けられます。
非機能要件は機能要件に埋もれがちですが、原価管理システムの安定稼働に欠かせない要素です。
PoCと補助金申請を見据えた要件整理
契約前のPoC（実機検証）を、要件定義に組み込みます。RFPには、自社の生データで原価計算を行い、標準機能への適合度を検証する機会を求める旨を明記します。
- 計算の確認：典型的な受注パターンを処理できるか
- 性能の確認：自社のデータ量で速度が落ちないか
- 操作の確認：現場がマニュアルなしで扱えるか
PoCでこれらを確かめておくと、契約前にカスタマイズ費の膨張を防ぎやすくなります。
補助金の利用を考える場合は、申請要件も整理します。原価管理を含む生産管理・業務システムは、補助率1/2〜2/3の補助金の対象になることがあります。
補助金は年度ごとに要件や補助率が変わり、申請には事業計画の作成と採択審査が伴います。そのため、補助金がなくても回収できる計画を立て、採択されれば有利になる順序で進めます。
PoCと補助金の条件を早期に織り込むことが、費用を抑えることにつながります。
まとめ
要件定義は原価計算ロジックの棚卸しから始め、生産形態に応じた方式を決めます。次に、ISA-95を踏まえて生産管理・会計・Excelとの役割を分け、その内容をRFPと見積りに反映します。
AsIsを見落とすと現場に合わなくなり、生産形態が曖昧だと原価計算方式が合わないおそれがあります。連携の境界を定めないままだと、二重入力が残ることもあります。
中小の初期費用は800万〜1,500万円が目安で、カスタマイズ費は全体の3〜4割が実態です。相場と内訳を確認したうえで、要件を具体化して見積りを判断します。
大切なのは、自社の原価計算を言語化し、生産形態と連携前提に合わせて要件を固めることです。
ToBeを描き、Excel連携を明記したRFPは、提案精度の向上とカスタマイズ費の抑制につながります。
riplaはフルスクラッチ受託と製造現場への伴走を組み合わせ、原価計算ロジックの棚卸しから、現場に定着するシステムの要件整理まで支援します。全体像は完全ガイドをご覧ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。