原価管理システムを開発・導入するうえで、プロジェクトの成否をもっとも大きく左右するのが要件定義です。とくに原価管理は、企業ごとに原価計算のロジックが異なり、配賦基準や標準原価の置き方、生産形態（受注生産・見込生産・個別生産）によって必要な要件がまるで変わります。これをいかに正確に要件として整理し、RFP（提案依頼書）や要件定義書に落とし込めるかが、現場に使われるシステムになるか、Excelに逆戻りするかの分かれ目になります。実際、自社の原価計算ロジックの整理を怠ったまま製品を選び、カスタマイズ費が当初見積りの倍近くに膨れ上がる失敗が後を絶ちません。
本記事は、原価管理システムのRFP・要件定義書・提案依頼書を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。自社の原価計算ロジックの棚卸しと整理、生産形態別の要件の違い、ISA-95を前提とした生産管理・会計との役割分担、Excel連携・データ移行の要件、そしてRFPに盛り込むべき項目と見積りの妥当性を判断する軸まで、原価管理の実務に即して掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。なお、全体像をまだ把握していない方は、まず原価管理システムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・原価管理システムの完全ガイド
自社の原価計算ロジックを棚卸しする進め方
原価管理システムの要件定義は、「どんな機能が欲しいか」のリストアップから始めてはいけません。出発点は、自社が今どのように原価を計算しているかを徹底的に棚卸しし、可視化することです。原価計算のロジックは、長年の慣行や製品ごとの細かな取り決めの積み重ねでできています。これを言語化しないまま製品を選ぶと、現場の実態と噛み合わないシステムができあがります。
現状の原価計算フローを可視化する
最初に行うべきは、現状（AsIs）の原価計算フローを可視化することです。経理、生産管理、製造現場の担当者に、「材料費をどう集計しているか」「労務費の賃率はどう決めているか」「間接費をどの基準で配賦しているか」「Excelのどのシートでどう組み上げているか」を細かく聞き取ります。ここで重要なのは、規程に書かれた建前ではなく、現場が実際に行っている計算や、属人的な例外処理まで拾うことです。
原価管理の現場には、「この製品だけは特別な配賦をしている」「ベテランが頭の中で按分している」といった、明文化されていない計算が必ずあります。これらを見落とすと、システムに移行した途端に原価が合わなくなります。AsIsの可視化は地道な作業ですが、ここで自社の原価計算ロジックを正確につかむことが、後の要件漏れを防ぎ、現場に使われるシステムを生む土台になります。配賦基準が複数あるなら、それぞれの根拠と適用範囲まで言語化しておきます。
ToBeで「あるべき原価管理の姿」を設計する
AsIsを可視化したら、次に描くのがToBeモデル、つまり「システムを導入した後、あるべき原価管理の姿」です。Excelで手作業していた集計を自動化し、差異分析まで回せるようにし、月次決算を数営業日早める。この新しい姿を具体的に設計したうえで、それを実現するために必要な機能を逆算します。ToBeを描かずに機能だけ決めると、機能はあっても原価管理の業務がつながらない、という事態に陥ります。
ToBeを描く際には、「現状の計算ロジックをそのままシステム化する」のか「この機会に計算方法を見直す」のかを意思決定する必要があります。属人的だった配賦をこの機会に標準化する、といった業務改革を伴うなら、その合意形成も要件定義のスコープに含めます。現状をそのまま移すだけなら早く済みますが、せっかくの投資で原価管理の精度を上げたいなら、ToBeの段階で「あるべき計算」を定義しておくことが、後悔のない導入につながります。riplaはフルスクラッチ受託の立場から、この現状から逆算したToBe設計を重視しています。
生産形態別に変わる原価管理の要件
原価管理の要件は、自社の生産形態によって大きく変わります。受注生産か見込生産か、個別受注か量産か、によって、原価をどの単位で捉えるべきかが異なるためです。生産形態と原価管理システムのミスマッチは、導入失敗の代表的な原因です。要件定義では、自社の生産形態を明確にし、それに合った原価計算の単位を要件として固めることが欠かせません。
個別受注生産は案件単位の原価が要件になる
個別受注生産では、製品が一品ごとに異なるため、原価を「案件（オーダー）単位」で捉える個別原価計算が要件になります。見積り時の予定原価と、実際にかかった実際原価を案件ごとに突き合わせ、案件単位で利益を確定させる機能が必須です。量産前提のパッケージをそのまま入れると、この案件単位の原価管理ができず、現場が使えないという事態に陥ります。
個別受注の要件定義では、案件番号やプロジェクトコードで原価を集約できること、追加発注や仕様変更が発生した際に原価をどう積み増すか、長納期案件で月をまたぐ仕掛品をどう評価するか、といった点を明記します。受注生産特化をうたう国内パッケージも存在し、こうした製品はExcelダイレクト出力や受注生産向けの原価集計を標準で備えています。自社が個別受注なら、案件単位の原価管理に強い製品を要件で前提にすべきです。
見込・量産は製品別の総合原価計算が要件になる
見込生産や量産では、同じ製品を繰り返し作るため、原価を「製品単位・期間単位」で捉える総合原価計算が中心になります。一定期間の製造費用を、その期間の生産量で割って製品単位の原価を求める考え方です。要件定義では、月次や週次でどの粒度の原価を出すか、仕掛品の評価をどうするか、歩留まりやロスをどう原価に反映するかを定めます。
量産では、標準原価を設定し、それとの差異を分析する運用が効果的です。要件定義では、標準原価のマスタ管理、差異の要因別分解、製品別の収益一覧を必須要件として盛り込みます。同じ製造業でも、個別受注と量産では原価計算の根本ロジックが違うため、両方を扱う企業では「どちらをどの製品群に適用するか」まで整理が必要です。自社の生産形態を曖昧にしたまま要件を進めると、リリース後に「自社の原価計算方式に対応していなかった」という致命的な手戻りが発生します。
ISA-95を前提に生産管理・会計と役割を分ける
原価管理システムは単独で機能するものではなく、ERP・生産管理・MES・会計システムと連携して初めて正確な原価を出せます。要件定義では、これらのシステムとの役割分担を明確にすることが欠かせません。役割の境界が曖昧だと、同じデータを複数のシステムで二重管理したり、必要なデータがどこからも来なかったりする事態が起きます。
計画層・実行層・原価の境界を定義する
ISA-95の階層モデルでは、ERPが計画層、MESや生産管理が実行層に位置づけられます。原価管理はこの両層からデータを受け取る立場です。要件定義では、「実績工数や実績数量は生産管理・MESから取り込む」「材料単価や労務費の金額は会計から取り込む」「原価計算と差異分析は原価管理システムが担う」「確定した原価差異は会計に戻す」といったデータの流れを図に落とします。
この境界定義があると、各システムが持つべきマスタや、連携インターフェースの要件が明確になります。日本固有の「生産管理システム」とグローバル標準の「MES」は機能が重複する部分があるため、自社の構成でどちらがどの実績を持つかを整理しておくことが重要です。役割分担を図で示せると、RFPを受け取ったベンダーも前提を誤解しにくくなり、提案の精度が上がります。連携の境界を曖昧にしたまま進めることが、後の二重入力や不整合の温床になります。
Excel連携・データ移行を要件に明記する
原価管理は既存Excel資産との連携が避けて通れません。要件定義では、「設計部門のExcel部品表を直接取り込めること」「集計結果をCSV変換なしでExcel形式でダイレクト出力できること」「既存のVLOOKUPやマクロを活かせること」を機能要件として明記します。これを曖昧にすると、移行時にCSV変換の文字化けや列ズレでかえって作業が増え、現場の反発を招きます。
データ移行も要件の重要項目です。過去の原価実績をどこまで移行するか、品目コードや工程コードの体系をどう統一するか、移行データの検証をどう行うかを定めます。原価管理ではExcelを完全に捨てるより、現実的に共存させて段階移行するほうが定着します。最終的な分析や経営報告は使い慣れたExcelで行い、集計と差異分析をシステムが担う、という役割分担を要件段階で固めておくことが、現場の納得感を生みます。Excel連携の要件は、原価管理システム特有の重要論点として、RFPに必ず盛り込んでください。
RFPに盛り込む項目と見積りの妥当性判断
要件が固まったら、それをRFP（提案依頼書）に落とし込みます。RFPの質が、ベンダーから返ってくる提案と見積りの質を決めます。原価管理システムのRFPでは、機能要件だけでなく、自社の原価計算ロジックや生産形態、既存システムとの連携前提を明記し、ベンダーが正確に提案できる情報を揃えることが重要です。
RFPに必ず盛り込むべき項目
原価管理システムのRFPには、以下を盛り込みます。導入の目的とゴール（決算早期化、差異分析による原価低減など）、自社の生産形態と原価計算方式（個別／総合、標準原価の有無）、必須の機能要件（集計・配賦・差異分析・収益可視化）、連携要件（生産管理・会計・Excel）、非機能要件（自社データ量での処理速度、利用人数、セキュリティ）、移行要件、想定スケジュール（一般に3〜6ヶ月）、予算感。これらが揃って初めて、ベンダーは精度の高い提案を返せます。
とくに非機能要件は見落とされがちです。「自社の実データ量で集計が現実的な時間で終わるか」「同時利用人数に耐えられるか」を要件に明記し、可能ならPoCで実機検証することを提案依頼の段階で求めておきます。RFPに自社の実態を具体的に書くほど、ベンダーの見積精度が上がり、後のカスタマイズ費膨張を防げます。逆に「原価管理ができること」程度の曖昧な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割）を知らずに見積りを受けると、費用膨張に気づけません。
要件定義で大切なのは、「機能を並べること」ではなく「自社の原価計算を正確に言語化し、生産形態と連携前提に合わせて要件を固めること」です。AsIsを可視化し、ToBeを描き、生産形態に合った原価計算方式を確定し、Excel連携を明記したRFPを作れば、ベンダーの提案精度が上がり、カスタマイズ費の膨張を防げます。riplaはフルスクラッチ受託と製造現場への伴走を組み合わせ、原価計算ロジックの棚卸しから、現場に定着するシステムの要件整理までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。