経営情報システム（EIS）開発の発注/外注/依頼/委託方法について

経営情報システム（EIS）の発注は、判断とKPIの定義、データと利用範囲の整理、RFPと段階契約の順に進めると、意思決定の改善につながります。発注形態の選び方から、進め方、RFP、契約と費用、委託先の選び方まで順に見ていきます。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

経営情報システム（EIS）の発注・外注で最初に決める事項

記録から分析用の蓄積、意思決定向けの提示へと役割が広がります。

EISは、会計・販売・購買のデータを集め、経営層や事業責任者が意思決定に使える形で示すシステムです。ほかにも、次の業務のデータを集めることがあります。

在庫
生産
人事
営業

発注では画面の見た目よりも、誰がどの数字をいつ見て、どの判断や行動につなげるかを、発注側と委託先で合意しておく必要があります。

判断を遅らせている作業を先に特定すると、外注する範囲と優先順位が明確になります。

EISとBI・ERP・DWHの違い

発注範囲を決めるには、まず各用語の役割を把握しておく必要があります。

ERP：日々の受注、請求、仕入れ、在庫などを正確に記録・処理する役割
BI：データの集計・分析・可視化
DWH：複数システムのデータを集めて、分析用に蓄積する
EIS：これらを利用して、KPIや予算実績、予測、異常値を意思決定向けに示す

「EISを作る」とだけ伝えると、画面だけを指すのか、連携やKPI定義も含むのかが曖昧になります。そのため、RFPには業務、データソース、更新頻度、利用者、必要な判断を書いておきます。

たとえば、会計と販売を日次で確認する会社と、複数法人の連結や為替、予算シミュレーション、承認まで必要な会社では、設計が異なります。

発注の成功条件：意思決定の改善

成功条件は、会議準備の短縮、差異原因の早期特定、施策決定といった意思決定の改善で定めます。

会議準備：準備時間の短縮と資料作成日数
差異分析：原因の特定と、数値不一致の解消までの時間
利用と行動：転記シート数、ログイン率、会議後の行動完了率

資料作成日数や転記シート数などの効果指標を先に決めておくと、更新頻度も判断できます。たとえば、週次会議であれば日次更新で足りる場合があります。一方で、資金繰りや在庫の異常検知では、より短い更新間隔が必要になることもあります。ただし、更新頻度を上げると、連携、容量、監視、再送設計の負担が増えます。

ポイント

迷ったら、画面の見た目より、誰がどの数字をいつ見て、どの判断や行動につなげるかを先に決めます。用語の違いを発注前に押さえると、発注範囲のずれを防げます。

経営情報システム（EIS）の発注形態の選び方

EISの発注形態は、クラウドBI・SaaSを使う方式、DWHとBIを組み合わせる方式、パッケージとスクラッチ開発の3つから選びます。

迷う場合は、全社の完成形を最初から作るより、経営に直結する1つのテーマでPoCを行う方が安全です。そのうえで、データ品質と利用定着を確かめてから、範囲を広げていきます。

クラウドBI・SaaSを使う方式：小さく始めたい企業向け

クラウドBIは、標準の分析機能や認証基盤を使うことで、比較的短期間で始められます。費用と導入範囲は、次の項目で確かめます。

追加作業：KPI設計、連携、マスター統合、権限、テスト、教育、監視の見積もり
利用環境：Microsoft 365やAzureを使い、会計・販売データをAPIやDBから取得できる企業向け
複雑な業務：計画入力や承認、固有の配賦は、業務アプリや計画製品との組み合わせで補う
見積条件：作成者・閲覧者数、外部共有、容量課金、保管場所ごとの条件

Microsoftの日本向け価格ページによると、2026年8月時点でPower BI Proは、税抜2,098円のユーザー・月相当で、年払いです（出典：Microsoft「Power BIの価格」、2026年確認）。

DWH・レイクハウスとBIを組み合わせる方式：部門横断向け

部門や指標を後から追加するには、データ統合の設計と運用の責任を、あらかじめ明確にしておく必要があります。

DWH+BI：DWHやレイクハウスに複数ソースを集め、BIで部門横断の分析を行う形
共通ルール：共通マスターとKPI計算の中央管理
運用設計：連携、履歴、品質確認、再送、監査ログの設計
小規模PoC：会計・販売など1〜3ソース、10〜30KPIで始める検証
責任者：共通マスターの所有部署と更新担当者のRFPへの記載

画面ごとに元システムへ接続すると、同じ売上でも集計条件が食い違う問題が生じがちです。一方で、データエンジニアリングにより、初期費用と運用費が増えます。

パッケージ・スクラッチ開発の判断基準：独自業務の多さ

既存業務を標準化できるか、独自機能が競争力に関わるかを見極めたうえで、方式を選びます。

パッケージ：標準業務を短期に統合でき、ERP刷新時はFit to Standardが基本
製品適合：SAP Analytics Cloudの分析・計画・シミュレーションと既存ERPとの適合性
スクラッチ：独自の配賦、承認、計画、行動管理が競争力に直結する場合の選択肢
保守負担：OS、クラウド、API、法制度への対応と、5年程度の費用の比較

独自画面を増やす前に、標準機能で代替できない理由を確かめます。また、独自要件は連携や拡張の形で持たせると、保守の負担を抑えられます。

EIS開発の発注・外注の進め方と順番

会社を探す前に社内の意思決定とデータを整理しておくと、提案と見積の精度が上がります。発注は、次のとおりに進めます。

目的と効果指標を決める
現行業務を調査し、KPI辞書を作る
発注形態を仮決定し、RFPを配布する
提案と見積を比較し、契約する
要件定義、PoC、本開発を行う
移行と定着を進める

目的・現行業務・データソースの洗い出し

洗い出しでは、目的、データ、品質の順に現状を確かめます。

目的：「月次連結資料を5営業日以内に作る」など、困っている場面の具体化
データ源：会計、販売、購買の各システムを一覧にします。ほかに、次のデータ源も一覧に加えます。
- 在庫
- SFA
- 勤怠
- Excel
- 外部API
管理状況：所有部署、更新頻度、保持期間、欠損・重複、手作業の記録
マスター：会社・部門・顧客・商品コード、勘定科目の照合

目標の具体例には、営業利益の差異を翌営業日に確認する、在庫異常を週次で検知するといったものもあります。

遅延の主な原因は、画面よりも元データの定義と品質です。そのため、発注前にサンプルを見て、連携できない列や個人情報を洗い出しておくと、追加のデータクレンジング費用を抑えられます。

KPI辞書：数字の意味と責任者の統一

候補会社との比較に使えるよう、指標の意味と計算の決まりを1つの辞書にまとめます。辞書には、指標定義、計算条件、運用条件、優先度の4つを書きます。

指標定義：指標名、定義、計算式、分子・分母、対象期間
計算条件：税区分、返品・取消、予算比較、元データの扱い
運用条件：更新頻度、責任部署、閲覧役職
優先度：MUST、SHOULD、WANTの3段階に分けたうえで、必須指標から検証

売上、受注、粗利、稼働率の意味は、会社ごとに異なります。そこで、同じ定義書を候補会社に渡し、見積と成果物を比べます。

MUSTは売上・利益・キャッシュ・予算実績、SHOULDは部門・顧客別分析です。WANTには、AI検索や高度なシミュレーションを含めます。

PoCでは、MUSTの数値一致と、判断への有用性を確かめます。また、AI機能を加える場合は、元データの信頼性を先に整えます。

PoCと受入基準の設計

PoCの実施条件と本開発の受入基準は、契約の前に定めておきます。

PoCの範囲：1〜3ソース、10〜30KPI、1〜3画面での連携と使い勝手の確認
PoCの条件：期間、データ、成果物、費用、終了条件
受入基準：数値、取込時刻、権限、CSV、監査ログ、障害時の再処理

本開発に進まない場合のデータや設計書の扱いも、あわせて合意しておきます。経営会議や予算レビューでは、経営者、経理、情シス、現場責任者が評価に加わります。

受入では、見た目の確認だけでなく、数値、速度、権限、運用の観点で確認項目を作ります。

ポイント

迷ったら、目的と効果指標、データの洗い出しを発注の前に済ませます。PoCの受入基準も契約前に決めておくと、本開発に進む判断がぶれにくくなります。

EISのRFPと要件整理の記載項目

業務の範囲と運用・アクセス条件を同じ前提で提示できます。

RFPは、同じ前提で提案を受けて、内容と価格を比べるための文書です。背景、目的、範囲、現行環境、データ、利用者を含めます。さらに、非機能要件、納期、予算、提案形式、質問期限も記します。

決め切れない項目は、「提案を求める」と明記しておきます。そうすると、候補会社の設計力も評価できます。

RFPの対象範囲・データ・利用者の書き方

提案の前提をそろえるため、範囲、データ、利用者、画面の条件を記載します。

対象範囲：全社か部門か、単体かグループか、会計だけか販売・在庫までかの区分
データ：システム名、件数、履歴、頻度、接続、Excel、品質課題
利用者：役員、事業部長、拠点長、管理職、現場、情シスの人数と役割
画面と頻度：KPI、分析機能、出力可否、更新間隔

画面要件には、フィルター、ドリルダウン、予算差異、前年差を含めます。さらに、予測、アラート、コメント、レポートも含めます。

更新間隔は、数分、1時間、日次、月次のどれかで示します。曖昧な表現のままだと、要件定義の後に追加費用が生じる原因になります。

RFPの非機能要件とセキュリティ

情報保護と運用継続に関する要件も、RFPに記載します。

継続性：可用性、性能、バックアップ、障害通知、復旧目標、保持期間の定め
アクセス：監査ログ、認証、SSO、多要素認証、権限、共有、出力制御の範囲
委託条件：リージョン、再委託、設計書・ソースの引き渡し条件
閲覧範囲：役職・部門・拠点ごとの定めと、実ユーザーでの検証

経営情報には、人件費、顧客情報、取引条件が含まれる場合があります。そのため、閲覧範囲を設計しておく必要があります。

たとえば、Power BIのRLSは、行単位で閲覧データを絞る仕組みです。ただし、Microsoftの公式文書では、管理者・メンバー・共同作成者にはRLSが適用されないと説明されています（出典：Microsoft Learn「Power BIでの行レベルのセキュリティ」、2026年更新）。

受入時には、RLSだけに頼らず、ワークスペース権限、列保護、出力制御も確認します。

候補会社への質問の統一

提案を同じ観点で比べるため、候補会社に同じ質問をします。

実績：類似案件のソース数、利用者数、期間、担当範囲、定着状況
提案体制：担当チーム、KPI定義、連携方式、PoCの進め方
開発と運用：標準機能との境界、遅延要因、導入後の体制を尋ねる

営業担当だけで回答が完結し、データモデルや運用設計の担当者が説明に加わらない場合には、注意が必要です。一方で、データや利用部門の抵抗を質問し、リスクと前提を見積書に記す会社は、認識の差を減らしやすい傾向があります。

安い提案に決める前に、前提の記載が他社より少なくないかを確かめます。

ポイント

決め切れない項目は「提案を求める」と書き、対象範囲、データ、利用者、閲覧範囲を具体的に示します。RLSだけに頼らず、権限や出力制御も受入時に確かめます。

EIS開発の契約形態と費用相場

費用は、ライセンス・クラウド料と受託費に分けて考えます。受託費には、要件定義、連携、KPI設計、画面の開発費が含まれます。さらに、移行、教育、保守の費用も入ります。EIS単体の公定価格はありません。

ここに示す金額は、NotebookLMの調査ノートに整理されたERP・経営管理案件と公開BI価格を基にした推定です。ソース数、KPI数、利用者数、権限、更新頻度、マスター品質によって、金額は変わります。

次の金額は、予算計画に使うためのレンジです。要件定義の後に改めて算定し直す前提で使います。

初期費用の目安：PoCは300万〜800万円程度

予算を検討するときは、対象範囲に対応するレンジを参照します。いずれも確定価格ではなく、調査ノートのスコープ別整理に基づく目安です。

小規模PoC：1〜3ソース、10〜30KPI、1〜3画面、日次更新。300万〜800万円、2〜4か月が目安
部門横断EIS：3〜8ソース、DWH、共通マスター、複数部門権限、予算実績・予測。800万〜2,000万円、4〜8か月が目安
グループ経営EIS：2,000万〜5,000万円以上、8〜18か月の可能性
ERP刷新を含む場合：1,500万〜4,000万円以上、半年から2年以上となるケースも

この目安は、多拠点・多法人で、連結、為替、複雑な権限、監査、データ品質整備、会議や計画のワークフローまで含む場合のものです。

SAPの日本郵船事例は、2025年7月に稼働した会計基幹刷新です。大規模な事例を、EIS単体の費用や納期として読み替えないよう注意します。

見積書の費目の分け方：データ連携・画面・保守の費用

見積もりは、費目ごとに比べます。ここに示す割合は案件によって重なることがあり、合計が必ず100%になる固定比率ではありません。

要件定義・KPI設計：10〜15%程度
データ連携・DWH：費用内訳の20〜35%程度
画面・レポート：20〜35%程度
テスト・移行・教育：15〜25%程度
プロジェクト管理・セキュリティ・運用設計：10〜20%程度

データクレンジング、過去データ再計算、マスター統合、機密情報の権限設計は、初期見積もりの後に増額されやすい項目です。

たとえば、Power BI Proを50人が使う場合、2,098円×50人×12か月で、年間約126万円の税抜ライセンス費になります（出典：Microsoft「Power BIの価格」、2026年8月確認）。

この額には、受託開発、基盤、容量、監視、保守、教育は含まれません。そのため、見積書では、初期費、ライセンス、クラウド、連携を分けて示してもらいます。さらに、追加開発、月額保守、問い合わせも別にします。

要件の確定度に応じた請負・準委任の組み合わせ

契約の形は、要件の確定度と成果物の明確さに応じて選びます。

準委任：業務の遂行に報酬を払い、成果物の完成は約束しない契約。現行調査、KPI整理、要件定義、設計、PoCに向く
請負：成果物を完成させる契約で、検査・受入を伴う本開発向け
組み合わせ：要件定義・PoCは準委任、本開発は請負、保守は月額の準委任または保守契約に分ける形

準委任では、範囲、体制、稼働時間、報告、意思決定者、成果物を定めます。さらに、社内レビューの日程も計画に入れます。

請負では、画面、計算、連携、テストを具体化します。さらに、性能、権限、納品、検収、瑕疵対応も具体的に定めます。特に、元データや業務ルールが決まらないままだと、変更や追加費用をめぐって争いになりがちです。

ポイント

要件定義やPoCは準委任、本開発は請負のように、工程ごとに契約を分けると双方のリスクを調整できます。見積もりは費目ごとに比べます。

委託先の選定と見積比較で確認すべきポイント

自社の発注範囲に近い実績かを領域ごとに確かめます。

委託先は、知名度や総額だけでなく、経営管理の理解、データ統合、製品適合、セキュリティ、管理、導入後の支援で選びます。大規模SIerが合う会社もあれば、小規模PoCに強い専門会社が合う会社もあります。自社の規模と課題に対して、提案範囲が広すぎたり狭すぎたりしないかを確かめます。

委託先の得意領域と自社の発注範囲の照合

自社の依頼範囲と候補会社の得意領域が合うかは、次の観点で比べます。

経営・業務改革：指標定義と実装、両方への支援の有無
製品活用：既存ERPやMicrosoft製品への習熟度
データ統合：複数システムやデータ品質に関する実績
独自機能：計画・承認アプリの開発と保守力

実績は、自社との類似性で見ます。たとえば、利用者規模、ソース数、法人構成、更新頻度、行レベル制御の必要性を比べます。

IBMのEtihad Airways事例では、財務ダッシュボードを9か月で構築しました。その対象には、データ構造、モデリング、アーキテクチャ、オンプレミスとクラウドのセキュリティが含まれます（出典：IBM「Etihad社」事例、2026年8月確認）。

期間だけでなく、9か月に含まれた作業範囲まで読み取ります。

見積比較：総額より前提・成果物・除外範囲

総額を比べる前に、前提、費目、除外範囲、保有コストを順に確かめます。

前提：ソース、KPI・画面・利用者数、頻度、履歴、権限、テスト、教育の照合
費目：要件定義、連携、DWH、画面、移行、マスター、セキュリティ、監視、保守、ライセンスの内訳
除外範囲：「別途」などの金額・算定方法の質問と、安値の理由の確認
総保有コスト：3年程度のライセンス、クラウド、保守、追加開発、内製工数を含めた合計

高い見積もりでも、複数法人の統合、監査、移行リハーサル、引き継ぎを含んでいる場合があります。そのため、単純に割高とは言えません。

安い見積もりの場合は、要件定義、品質整備、テスト、教育、管理、障害対応が除外されていないかを確かめます。

ロックイン・変更管理・運用分担の確認

ロックインを防ぐには、契約で何を受け取れるかと、運用でどこまで任せるかを先に確かめておく必要があります。確認する分野は、引き渡し、SaaS、受託開発、運用分担の4つです。

引き渡し：データモデル、KPI辞書、ETL、画面仕様、権限、テスト、マニュアル、ソースや設定の範囲
SaaS：出力形式、解約後の保存、再利用データ、値上げ・プラン変更通知
受託開発：OSS・外部サービスのライセンス、再委託先、障害窓口
運用分担：監視、KPI変更、ユーザー・権限管理、照合、復旧、問い合わせの担当決め

RLSやSSOを使っていても、退職・異動時の権限変更が遅れると、情報の漏えいにつながります。そのため、自社の情シスと委託先の役割を、平常時と障害時に分けておきます。

ポイント

総額ではなく、前提、除外範囲、3年程度の総保有コストを同じ条件で比べます。委託先は、自社の発注範囲と得意領域が合うかで選びます。

経営情報システム（EIS）の発注・外注でよくある質問

発注前の準備、更新頻度、Excel移行、費用について、よくある質問に答えます。自社の判断材料として使ってください。

EISの開発は中小企業でも外注できますか？

外注できます。たとえば、会計と販売の売上・粗利・予算実績など、経営判断に直結する範囲から始めると、PoCの予算とリスクを抑えられます。

利用者、ソース、KPI、更新頻度を絞り、成果を確かめてから対象を広げていきます。

EISはリアルタイム更新でないと意味がありませんか？

必ずしも必要ではありません。会議の頻度、検知後に対応できる時間、元システムの更新時刻を基に、日次、時間単位、数分単位から選びます。

ただし、頻度を上げると連携、監視、容量の費用が増えます。そのため、目的に必要な粒度を、RFPで定義しておきます。

Excelに散在するデータもEISへ移行できますか？

移行できる場合もありますが、ファイル形式と管理ルールの確認が欠かせません。

列名、コード、更新者、計算式を調べ、重複、欠損、履歴の保管場所も確かめます。そのうえで、正式なデータソースにするファイルと、廃止するファイルを分けます。

Excelを連携する場合も、入力規則、ファイル名、保存場所、エラー時の連絡先、最終承認者を決めておかないと、属人化が残ります。

EISの保守費用はどのくらい見ておくべきですか？

一律の相場はありません。保守費用は、ユーザー数、ライセンス、容量、ソース数、更新頻度によって変わります。さらに、監視、問い合わせ、追加開発の範囲でも変わります。

初期300万〜800万円程度のPoCとは別に、ライセンス・クラウド・保守の年額を見積もり、範囲が広がったときの追加単価も確かめます。

初期費用だけでなく、3年程度の総保有コストで比べます。

経営情報システム（EIS）の発注・外注方法まとめ

発注時は、改善したい判断を起点に、KPI、データ、利用者、更新頻度、機密区分を整理します。製品や会社は、その後に選びます。

クラウドBI、パッケージ、DWHとBI、スクラッチを比べたうえで、小さなPoCで実データと利用定着を検証します。

発注前のRFPと比較基準の統一

RFPには、目的、範囲、KPI辞書、連携、画面、権限を記します。さらに、セキュリティ、性能、移行の前提も書き添えます。教育、運用、納期、予算の前提も、RFPに含めます。

見積もりは、初期開発、ライセンス、クラウド、連携を分けてもらいます。さらに、移行、教育、保守、追加開発、除外範囲も分けて、同じ条件で比べます。

上流は準委任、本開発は請負など、工程に応じて契約を組み合わせると、発注側と委託先の双方のリスクを調整できます。

最初の一歩：経営課題とサンプルデータの共有

初回相談の前に、必要な資料と、委託先に確認したい内容をそろえておきます。

共有資料：経営会議資料、KPI、会計・販売データ、現行Excel
業務情報：利用者の役割と、改善したい作業時間
提案確認：データ品質や権限の難しさを踏まえた、実現範囲とリスクの説明力

EISは、数字の定義と意思決定の運用を継続的に改善する仕組みです。そのため、発注範囲には効果測定と定着支援も含めておきます。

▼全体ガイドの記事
・経営情報システム（EIS）開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。