経営情報システム（EIS）開発の進め方/やり方/流れや方法/手法/工程/手順

経営情報システム（EIS）の開発は、KPIの定義、データの整備、段階的な導入の順に進めると、経営判断と業務改善につながります。全体は要件整理から定着までの6段階で、各段階で仕上げるものと次へ進む条件をそろえながら進めます。

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

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

経営情報システム（EIS）の全体像

EISはExecutive Information Systemの略称で、経営者や役員、事業責任者が、会社全体や事業別の重要指標を短時間で確認し、意思決定につなげる情報システムです。そのために、会計や販売などの業務データを集約します。購買や在庫、生産のデータも集めます。さらに、人事や営業のデータも対象に含めます。

そのうえで、売上や粗利、キャッシュ、予算実績差異などの指標を、ダッシュボードやレポートで提示します。

EIS・BI・ERP・DWHの違い

EISは経営判断を支える目的の側を指し、BI、ERP、DWHは、そのデータを記録・蓄積・分析する仕組みにあたります。

• EIS：経営層の判断を支える目的と業務プロセスを指す概念です。
• BI：データを分析・可視化する製品や仕組みを指すことが多いです。
• ERP：会計や販売などの日々の取引を記録・処理する基幹システムです。
• DWH：複数システムのデータを分析しやすく蓄積する基盤です。

EISでは、ERPや業務システムをデータソースにして、DWHやBIを組み合わせる構成が一般的です。たとえば、販売管理が受注を記録し、会計が売上と原価を確定します。そのうえで、DWHで顧客・商品・部門のマスターをそろえ、BIで経営ダッシュボードに表示します。

売上を出荷基準と請求基準のどちらで数えるか、粗利に標準原価と実績原価のどちらを使うかは、社内で決めておく必要があります。特に、数字の意味と使い道は、製品を選ぶより先に定義します。

EISの導入を検討すべきサイン

日々の集計や数字の確認で、次のような課題があれば、EISの導入を検討できます。

• 集計作業：複数のExcelを使って、会議資料を手作業で作成している。
• 数字の不一致：同じ指標でも、部署ごとに集計結果が異なる。
• 原因把握の遅れ：月次締め後まで、予算差異の原因が分からない。
• 採算確認の手間：拠点別・商品別・顧客別の採算確認を、毎回依頼している。

経営者が見たい日に数字を見られない場合や、担当者が休むと集計が止まる場合も、EISの効果が出やすいサインです。ただし、課題がダッシュボードの不足とは限りません。元システムの入力ルールが不統一なら、その場合は先にデータを整える必要があります。

取引処理そのものが限界なら、ERPや業務システムの刷新が必要になります。そのうえで、「何を見て、何を判断し、誰が何をするか」を確認し、EISで対応する範囲を分けます。

経営情報システム（EIS）の進め方・開発工程

EIS開発は、要件整理、選定、設計開発、テスト、稼働、定着の6段階で進めます。各段階では、仕上げるものと意思決定者、次工程へ進む条件を明確にします。画面の見た目より先に、KPI定義、データ責任者、更新タイミング、権限を確認します。経営課題と技術課題を分けて扱うと、議論が整理しやすくなります。

フェーズ1：要件整理と目的・KPIの決定

要件整理では、最初に目的を絞り、効果を測る指標を選び、KPIの定義を残してから、初回の範囲を決めます。

1. 目的を絞る：改善したい意思決定を3つ程度にしぼり、利用場面と期限を決める。
2. 効果を測る：集計時間、資料作成日数、差し戻し件数、差異の発見時点、アクション完了率を指標に含める。
3. KPI辞書を作る：名称、定義、計算式、期間、単位を記載します。除外条件、データソース、更新頻度、責任者、閲覧役割も書き添えます。
4. 初回範囲を決める：更新頻度、保持年数、予算・実績・見込の扱いを整理し、MUSTとWANTを分けます。

目的は、利用場面と期限まで言葉にしておきます。たとえば、「経営会議を効率化する」という目的に、会議前営業日までに予算差異と原因候補を確認する、という場面と期限を添えます。

また、粗利率が基準を下回ったら、責任者が翌営業日までにコメントする目標も置けます。経営層の指標と現場の改善指標がつながっているかも、あわせて確認します。

初回リリースでは、KPIを増やしすぎないようにします。

フェーズ2：製品・開発会社の選定

候補には、スクラッチ開発やローコードも含まれ、どの方式が合うかは目的によって変わります。

• 短期で数字を見たい：クラウドBIが候補です。
• 既存ERP中心の統合：ERP付属の分析機能を検討します。
• 複数システム横断：DWHとBIの組み合わせが候補です。
• 独自の計画・承認・シミュレーション：競争力に直結するなら業務アプリ開発が候補です。

製品名より先に、データソース数や利用者数、更新頻度に加えて、機密区分と将来の拡張範囲も比べる観点をそろえます。候補の会社には、同じRFPを渡し、提案を同じ条件で比べます。

費用は、初期費用やライセンス、連携、DWHの費用を分けて提案してもらいます。移行、テスト、教育、保守、追加開発も、別の項目として示してもらいます。

機能数だけでなく、KPIの設計や実データを使う短期PoCも評価します。障害時にどこまでを誰が受け持つかも見ます。

設計書やデータモデル、設定情報を開発会社から引き渡してもらえるかも確認します。導入後も、改善会議を運営できるかを確かめます。

Microsoft 365やSAP、Oracleなどを使っている企業は、認証と接続の方法、契約や解約時の移行方法も確認します。

フェーズ3：データ・画面・権限の設計と開発

取り込んだデータは、KPIモデル、画面、通知、会議資料へつながります。そのため、データ、画面、権限は一続きに設計し、開発範囲を整理します。

• データの流れ：業務システムやExcel、APIのデータを、DWHかデータレイクへ取り込みます。
• 連携運用：再送、欠損時の扱い、締め後の再計算、過去データの修正履歴の決定。
• 画面構成：経営層向けの全社サマリー、事業部長向けの部門分析、現場向けの原因分析を用意し、部門から顧客、案件まで掘り下げられるようにする。
• 権限設計：役員は全社、事業部長は自部門、拠点長は自拠点を閲覧できる設定。出力、共有、印刷、管理者権限の確認も含む。

データソースが3つあっても、顧客名や商品コードがそろっていなければ、連携費用と検証の工数が大きく増える可能性があります。

Microsoftの公式情報によると、Power BIのRLSは閲覧できる行を制限する仕組みです。ワークスペースでは管理者や閲覧者などで権限が異なります。そのため、役割ごとにテストします。

フェーズ4：データ・権限・業務シナリオのテスト

画面の表示だけでなく、実データと業務の動きを次の観点で確かめます。

• データテスト：元データと売上、粗利、営業利益、受注残などの重要KPIを、複数の締め月と例外データで照合する。
• 権限テスト：役割ごとの表示範囲を確認し、権限漏れがないかを確かめます。
• 業務シナリオテスト：月次締めや予算変更を再現し、経営層、現場、情シスが判断、行動、運用できるかを見ます。
• 障害テスト：更新遅延や連携失敗を想定して、障害復旧とデータの再取り込みを試す。

差異が出た場合は、原因と修正担当者を記録します。受入テストには、経営企画や経理、事業部が参加します。情報システムや、個人情報・セキュリティの担当者も加わります。

経営層は会議で判断できるか、現場は原因を掘り下げて行動できるか、情シスは運用できるかを確認します。そのうえで、操作手順と問い合わせ先を決め、重大な数値差異が解消していることを完了の条件にします。

フェーズ5：段階的な稼働と数字の並行確認

まずは優先する指標から切り替え、全社の指標を一度に変えないようにします。並行確認では、差異と運用課題を把握します。

1. 段階導入：会議で使う売上、利益、予算実績から始め、対象部門やデータソースを増やします。
2. 並行確認：最初の1〜2回の月次会議で旧Excelや従来レポートと照合し、差異を仕様、更新遅れ、元データ誤りに分けます。
3. 稼働判定：アカウント、更新時刻、監視、バックアップ、ログを確認します。問い合わせ窓口と障害時の連絡網も確かめます。

見つかった差異は隠さず、KPI辞書と運用ルールに反映できる仕組みを作ります。

会計や請求のデータを扱う場合は、電子帳簿保存法やインボイス制度の保存・確認要件を確認します。

個人データを扱うなら、個人情報保護委員会のガイドラインを踏まえ、法務や税務の担当者と照らし合わせます。

EISには経営機密が集まります。そのため、外部共有やダウンロードの設定を、初期設定のまま使わないことが大切です。

フェーズ6：会議と業務への組み込みと定着

研修は一度行って終わりにせず、経営会議や予算レビューでEISを使う運用にします。

1. 会議で使う：会議前にEISを確認し、異常値や予算差異の原因にコメントして、担当者と期限を決めます。
2. 効果を測る：画面利用率だけでなく、次回会議での完了状況を確認します。資料作成時間や会議時間、差異発見日数、アクション完了率、予測と実績の差も追います。
3. 運用を見直す：毎月または四半期ごとに、KPI、定義、データ品質、権限、ライセンス数を点検します。

AIによる異常検知や自然言語検索には、信頼できる元データとKPI辞書が必要です。AIは分析の入口に使い、最終判断と説明責任は担当者が持ちます。

利用されない画面を増やすより、会議で使う指標に絞るほうが定着につながります。

経営情報システム（EIS）の費用相場とコストの内訳

EISの受託開発費は、公開定価が少なく、データソース数、KPI数、利用者数、更新頻度によって変わります。また、マスターの品質や権限の複雑さも費用に影響します。

ここに示すレンジは、NotebookLMリサーチで整理したERP・BI関連の相場、公開ライセンス価格、公開事例をもとにした予算の目安です。

EIS固有の公定価格ではないため、提案を依頼するときは前提条件をそろえ、要件整理のあとに算定し直します。

スコープ別の初期費用の目安

スコープ別の初期費用は、データソース数や連携範囲、権限、対象業務によって異なります。ここに示すのは、要件やデータ品質、会社規模で変わる推定値です。

• 小規模PoC：300万〜800万円程度が目安です。
• 部門横断EIS：800万〜2,000万円程度が検討レンジです。
• グループ経営EIS：2,000万〜5,000万円以上のケースがあります。
• 基幹システム刷新を含む場合：1,500万〜4,000万円以上が参考です。

小規模PoCは、1〜3個のデータソースと10〜30個程度のKPIが前提です。画面は1〜3画面で、日次更新とします。

部門横断では、3〜8個のデータソースを横断し、共通マスターと予算実績を整えます。予測や部門別の権限まで含めます。

多拠点・多法人、連結、為替、複雑な権限、監査ログ、計画ワークフローを含む場合、2,000万〜5,000万円以上になることがあります。大型案件では、さらに増える可能性があります。

金額はリサーチノートの整理値です。EIS単体とERP刷新の対象範囲は、分けて見積もります。

開発費・ライセンス・運用費の内訳

開発費は作業ごとに分けて確認します。ただし、配分の合計が必ず100%になる固定ルールではなく、データ整備や権限の難しさを比べる目安です。

• 要件定義・KPI設計：全体の10〜15%程度です。
• データ連携・DWH：全体の20〜35%程度です。
• 画面開発：全体の20〜35%程度です。
• テスト・移行・教育：全体の15〜25%程度です。
• PM・セキュリティ・運用設計：全体の10〜20%程度です。

ライセンス費は開発費と分け、作成者や閲覧者、外部利用者などのほか、容量、環境数、契約期間で算出します。

Microsoftの日本向け公式価格では、Power BI Proは年払いで税抜2,098円／ユーザー／月相当です。50人が同じプランを使う場合、単純計算で年間約126万円になります。

この金額は、2,098円×50人×12か月で求めた税抜のライセンス費だけです。DWHやクラウド、監視などを含めると、年間の費用は大きく変わります。保守や追加開発、教育も加わります。

受託費とサブスクリプションは、一つの金額に混ぜず、分けて扱うことが大切です。

IBM公開のEtihad Airways財務ダッシュボード事例は、データ構造・モデリングや、アーキテクチャ、オンプレミスとクラウドのセキュリティ設計を含みます。構築は9か月で完了したと説明しています。

2025年に公表された日本郵船のSAP S/4HANA Cloud導入は、経営基盤の刷新です。そのため、EIS単体の期間とは比べられません。公開事例は工程を読む材料で、期間を断定する根拠にはなりません。

経営情報システム（EIS）の見積もりを取るポイント

見積もりは、金額だけでなく前提をそろえて比べます。RFPには、目的、利用者と役割、対象業務を記載します。KPIやデータソース、更新頻度などの条件も書き添えます。

画面数や権限、連携方式などの条件を示し、移行とテストの範囲、稼働希望時期、保守条件も書きます。未確定の事項は「提案してほしい事項」と明記し、各社が同じ条件でリスクを見積もれるようにします。

見積もり前の準備事項

見積もりを頼む前に、社内の材料をそろえておく必要があります。

• 現状資料：経営会議資料、Excel集計、元システムの帳票を集め、数字の出どころを確かめます。
• データ一覧：システム名、管理部署、接続方法、更新時期、保存期間を一覧にします。欠損や重複、マスター管理者も整理します。
• KPI：定義と計算式をまとめ、経営層、部門長、現場の指標に分類します。
• 成功条件と実データ：導入前後の値や測定方法を決め、連携、クレンジング、性能を見積もれるサンプルを用意します。

目標の例には、資料作成を月5営業日から2営業日以内にすることや、差異の原因を翌月から当月中に特定することがあります。また、対象部門の月次ログイン率を一定水準以上にする目標も置けます。

具体的な目標値を置けない場合でも、計測方法は決めておきます。効果を測れないと、画面が完成しただけで成果になってしまい、改善予算を確保しにくくなります。

開発会社の提案の比較項目

価格と追加費用の前提を分けて、各社の提案を同じ基準で比べます。

• 基本費用：初期費用、月額・年額ライセンス、クラウド・DWH、連携、マスター整備、画面開発を分けて示す。
• 導入・運用費：移行、テスト、教育、保守、追加開発単価を確認します。
• 追加費用：Excel整備、過去データ再計算、APIのない連携、海外拠点の為替換算、行レベル権限、外部共有の監査対応を確かめる。

見積もりに含まれない前提や、別料金になる作業、価格が変わる条件も確認します。

技術の評価では、実データを使う短期PoCを行います。KPIの再現性や集計速度、掘り下げ表示を確かめ、権限の切り替えやエラー表示も見ます。

実際の欠損やコードの揺れを見るには、実データに近い条件が必要です。会社の規模や知名度よりも、データソース数や利用者数などの条件と運用体制が近い事例を確認します。

稼働後も、担当者が支援を続けるかを聞いておきます。

見積もり後の予算超過の防ぎ方

契約の前に、初回範囲と将来の拡張を分け、変更管理のルールを決めておきます。

• 工数を見込む：KPIを追加すると、連携や計算式、テスト、権限、マニュアルの工数も増えます。
• 変更を管理する：要件変更の効果、追加費用、納期、既存機能への影響を記録し、承認者を決める。
• 補助金に依存しない：採択を前提にせず、不採択時の自己負担額でも進められる計画にします。

定額の開発でも、データ品質の改善や基幹システム側の改修が別の範囲になるかを確認します。

中小企業庁のデジタル化・AI導入補助金2026は、AIを含むITツールの導入を支援します。対象者や登録ツール、対象経費、申請枠などの要件があり、補助率や締切も確認が必要です。

スクラッチ開発費や独自のデータ整備費が、そのまま対象になるとは限りません。支援事業者と公募要領を見て、対象条件を確かめます。

経営情報システム（EIS）についてよくある質問

導入の前によく寄せられるのは、リアルタイム性や企業規模、Excelからの移行などです。判断に直結しやすい疑問を、順に取り上げます。

EISは中小企業にも必要ですか？

Excel集計の属人化、拠点別の数字の不一致、月次報告の遅れが判断を遅らせるなら、中小企業にもEISの考え方が役立ちます。

まずは範囲を絞って始めることもできます。たとえば、会計と販売の2つのデータソース、重要KPI、経営会議の1画面から始めるPoCも選べます。

初期費用300万〜800万円程度は、小規模レンジの目安です。対象を絞って効果を確かめ、必要な領域へ広げると、投資の判断をしやすくなります。

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

リアルタイム性そのものより、意思決定に必要な更新頻度で選びます。たとえば、月次会議で見る利益や予算実績は、日次や締め後の更新で足りる場合があります。

在庫や受注、キャッシュ、障害監視では、時間単位やリアルタイムの更新が必要な場合があります。ただし、頻度を上げると、連携や性能の検討が増えます。監視やクラウドの費用も増えます。

KPIごとに、いつ見られれば判断できるかを決めておきます。

ExcelのデータをEISへ移行できますか？

移行はできますが、Excelをそのまま取り込めば正確なEISになるとは限りません。まず、列名や商品コード、顧客名などの表記を確認します。日付や単位、計算式、入力ルールも見直します。

重複や欠損、表記の揺れを整え、重要な元ファイルは保管しておきます。取り込んだあとは、複数月の集計値を突き合わせます。

Excelを完全にやめるか、予算入力などの一部に残すかも、運用設計の中で決めます。

AIに経営判断を任せられますか？

AIを使う場合は、利用範囲と判断の進め方、運用の準備を整えておきます。

• 活用範囲：異常値検出、予測候補、自然言語検索、原因分析を補助し、意思決定の速度と検討材料を改善します。
• 判断：経営判断を全面的に任せず、最終判断は担当者が行います。
• 運用準備：KPIの定義、更新時刻、予測の前提、確認者、判断記録を整える。

マスターに誤りがあったり、未確定のデータを分析したりすると、もっともらしい誤った解釈が出る可能性があります。

EISの導入後の保守費用はいくらですか？

保守費用は、BI・DWHのライセンスやクラウド料、連携監視、障害対応の範囲で変わります。さらに、OSやサービスの更新、KPIや画面の追加、問い合わせ、教育の範囲によっても変わります。

保守は、初期費用の一定割合とせず、定型保守と障害対応時間、軽微な変更の上限、追加開発単価を分けて契約します。

利用者数や容量で課金される場合、契約終了時のデータと設計書の引き渡しも、見積もりの段階で確認します。

まとめ

EIS開発では、経営判断に必要な数字を定義し、信頼できるデータを適切な権限で届けて、会議や業務の行動につなげることが目的です。

EISとBI、ERP、DWHの役割を分け、EIS単体で進める範囲と基幹システム刷新の範囲を明確にします。

6フェーズと判断基準のつなぎ方

EIS開発では、各フェーズで仕上げるものと、次へ進むための判断条件を確かめます。

• 要件整理・選定：目的とKPI辞書を定め、RFPと比べる観点を整えます。
• 設計開発・テスト：データモデル、画面、権限を整え、数値、権限、業務シナリオを確かめます。
• 稼働・定着：並行確認と障害対応を行い、会議運用と効果測定につなげる。
• 進行条件：各段階の承認者と次へ進む条件を定め、画面追加や要件の膨張を抑える。

KPIやデータ品質、権限などは、見積もりの前から関係部署と確認しておきます。

小さく始めて効果を確認しながら広げる進め方

EISは、範囲を絞って効果を確かめ、運用に合わせて広げていきます。

1. PoCで確かめる：重要KPIを選び、実データで数値、権限、更新、利用者の反応を確認します。
2. 費用を比べる：開発やライセンス、クラウド、連携の費用を分けます。移行や教育、保守、追加費用の条件も分けて比べます。
3. 支援先を選ぶ：要件整理やデータモデル設計が難しい場合は、経営課題とシステムの両方を理解する会社の提案を判断材料にする。

EISは導入後も、経営指標や業務の変化に合わせて改善していく基盤です。効果を測ったうえで、次のKPIやデータソースを加えていきます。

▼全体ガイドの記事
・経営情報システム（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を創業。