CaFeterria

『データドリブン経営を定着させるために
～ BI運用とプロジェクト推進の現場で見た成功と失敗のリアル ～』　執筆者：井上千尋

https://www.crossfields.co.jp/cms/wp-content/uploads/2026/01/magazine_vol48.pdf

近年のビジネス環境は、デジタル技術・生成AIといった新たなツールの発展に伴って、

指数関数的に変化しています。

先行きが不透明なこうした状況において、経験や勘を中心とした旧来的なやり方では、

もはやビジネスは立ち行かなくなってきました。

本稿にも触れられているとおり、データ活用の重要性が叫ばれ、

多くの企業がDXを掲げるようになった今、

「データドリブン経営」という言葉は一般的となり、多くの企業でBIを導入し、

データに基づいた迅速な意思決定を試みています。

一方で、BIの導入とは裏腹にBIの運用が定着しないケースもたびたび見聞きすることがあります。

本稿では、多くのBI基盤導入や基幹システムの導入に携わってきた弊社コンサルタントが、

なぜBIは「作ったのにつかわれない」のかという課題の分析から始め、

BIの運用を根付かせるため、実務の中で見えてきた普遍的な原則を紹介しています。

是非ご一読ください。

本番移行では、想定外のトラブルが発生することが少なくありません。

私自身も直前での仕様変更が移行データに与える影響を十分に考慮できず、

移行後に問題に気づき補正作業を行った経験があります。

こうした事態を防ぐには、入念な移行リハーサルの実施が不可欠です。

移行リハーサルでは、各マスタやトランザクションデータが取り込まれること、

取込エラーの原因分析や各タスクの所要時間を計測することも大切です。

ただそれ以上に、移行データを用いて実際に後続業務を回し、

データの整合性を確認することが非常に重要です。

例えば、会計システムを導入するにあたっては、

移行した債権データに対して漏れなく請求締処理が出来るか、

請求書の請求金額や繰越金額は正しいか、

通常の締日とは異なるタイミングで請求するなど

イレギュラー処理を行った場合でも問題はないかなど

想定される業務フローに沿って、

正しい結果が得られるか検証することが重要であると考えます。

【投稿担当：R.T.】

入出金に関する会計仕訳の起票は、付加価値を生まないルーティンワークだけに

経理・財務部門にとっては自動化を進めたい作業の一つである。

特に中堅・中小企業では、自動化が進んでいないことが多い。

実現には多様なサービスを活用する必要があるため、

それなりの投資額になってしまい、先送りにしてきた背景がある。

本稿では、比較的安価に導入可能なサービスをご紹介したい。

■入出金データの収集：例）BizHawkEye等
複数の金融機関取引を、同一インターフェースで操作可能とするマルチバンクサービス。

入出金明細データの取得を自動化

■入金内容の把握：例）仮想口座サービス
かなり以前から金融機関が提供する入金内容の特定の容易化を目的としたサービス。

仮想口座番号をキーにして入金内容を把握

■出金内容の把握：例）SMBCパーフェクトクリア等
口座引落の明細特定の容易化を目的とした、支払用仮想口座サービス。

仮想口座番号をキーにして出金内容を把握

上記サービスを組み合わせて会計システムにデータを取り込み、

取引内容に応じた仕訳パターンを会計システムに設定すれば、仕訳生成の自動化が可能となる。

【投稿担当：R.T.】

私はSAPの導入PJに参画しており、FMのチームに所属しています。

FMは「予算管理」の機能です。

『予算管理はCOを利用すればよい』と考える人もいると思います。

FMは予算の管理・執行を担います。

特に使用可能額の上限を定め、その範囲内でのみ支出可能とすることが出来る点は特徴的です。

例えば、上限が100万円の場合、100万円を超過した支出はブロックすることが可能です。

一方、COは組織内部の収益・費用の分析と管理を担います。

「どの部門が利益に貢献しているのか」など、経営分析に焦点を当てています。

FM導入時の大事な点を2つ紹介します。

1つ目は「予算管理ルールの明確化」です。
FMはルールベースで動くため、予算チェックタイミングや予算超過時の動作（エラー/警告/許可）などのルールを定める必要があります。

2つ目は「他モジュールの理解」です。
「予算管理」という特性上、FMは他モジュールと密接に連動するので、FMの担当者がFI,MM等の知識を持っていることで効果的な導入が可能です。

FMとCOと両立させることで、予算管理と経営分析の両方が実現可能であり、「予算統制とコスト管理」や「中長期的な予算計画・経営計画の改善」などに役立てられると思っています。

【投稿担当：R.M.】

私は現在システム導入PJ支援に携わっており、このPJではアジャイル開発手法を取り入れてシステム開発を行っています。

また開発の際は、業務に必要な最低限の機能に絞り込み優先順位を付けてリリースするスモールスタート方式を採用しており、なるべく短サイクルで要件定義～リリースまでできるようにしています。

この開発手法の良いところは、短期リリースかつ毎回リリースする機能範囲が限定的なため、都度ユーザーから具体的なフィードバックをもらえ、迅速に改善要望対応ができることです。

実際に利用後すぐに、「通常業務パターンとは別に、特定のイベント時においては業務担当者が変わる別の業務パターンが発生するため、そのパターンにも対応できる機能を実装して欲しい」と言った要望があり、業務影響が出る前に対応することができました。

特にシステム導入PJの経験が少ないユーザーの場合、要件定義からシステムリリースが短期間である方が業務とシステム機能の紐づきを容易にイメージでき、PJとしての達成感も得られるため、アジャイル開発の方が向いていると感じました。

【投稿担当：K.I.】

私が参画しているプロジェクトでは、基幹システムはアジャイル型とウォーターフォール型を組み合わせたハイブリッド型、周辺システムはウォーターフォール型で開発している。

このように開発手法の異なるシステム間のインターフェース開発を行う場合、基幹システムと周辺システム間の積極的なコミュニケーションによってマイルストーンを同期したうえでスケジュールの調整を図り、自システムの開発を遅延させないよう対応することが重要になると考える。

私が担当する人事システムとの連携では、基幹システム側の要件検討が遅延しており、開発遅延リスクを抱えていた。
そこで、基幹システム側には、人事システムとして要件確定が必要な時期を提示し、その期限内に要件が確定できないか調整しつつ、人事システム側とは、基幹システム側からの要件に依存しない機能を先行して開発する方向で対応した。

両システムの間に立つ調整役として、今後も双方の進め方や作業内容を理解し、密にコミュニケーションを取りながら進めていく所存である。

【投稿担当：G.F.】

打合せの度に印刷される資料、積み上がった書類に埋もれた机。ペーパーレス業務の浸透が進んでいない企業には、従来の仕事のやり方とのギャップや、そもそもやり方を変える事それ自体への抵抗等、様々な理由があり変革が困難と言われていますが、本当にそうでしょうか。

例えば、経理部門の日次業務の一つである伝票と証憑の突合確認では、審査の品質を維持しつつある程度のスピードで処理する必要があり、証憑の確認に際しての“見やすさ”は重要な要素です。

そんな中で単純にペーパーレスの推進だけを掲げても、ひとつのPC画面でウィンドウを切り替えたり分割しての作業となり、かえって業務効率が低下しかねません。

だからといってペーパーレス化が不可能というわけではなく、例えば上のケースではサブモニターを用いることで紙印刷した場合の文書の見やすさに近づける等、対策は考えられます。適切な支援を行うことでペーパーレス化は十分に実現可能であると考えます。

【投稿担当：W.K.】

最近、十数年ぶりに要件定義フェーズの重要性を再認識する状況に遭遇しました。

（詳細は割愛しますが、クロージングフェーズで要件の認識相違が発覚）

要件定義フェーズは、操作マニュアルやイメージ図等を使った所謂「紙芝居」で議論が進むケースが多く、認識相違が発生しやすいフェーズと考えています。

紙芝居を見ながら実際に動作しているシステムをイメージできるようにコミュニケーション頻度・密度を上げつつ、様々なモノを活用しながら進めたつもりでしたが、少しだけ足りていなかったなと反省しています。

「準備8割・実行2割」という言葉がありますが、PJの”準備”にあたる要件定義フェーズが非常に重要であることを改めて肝に銘じていきたいと思います。

【投稿担当：C.I.】

例えばデータ連携テストをする際、連携元システム、EAI、連携先システムと、システムごとに担当者を配置する体制がセオリーかなと思います。

しかし、セオリー通りでは上手くいかないこともあります。

私もセオリー通りの体制でデータ連携テストを実施し、なかなか解消されないエラーに四苦八苦する経験をしました。
EAI内のマッピングが複雑化・ブラックボックス化する中、連携元システム担当としてEAIの仕様を深く理解しないままテストを進めた結果、EAI側でエラー発生時に主体的に原因究明できず、EAIチーム任せとなり解決に時間を要してしまったのです。

もし体制として、システムを跨いで横断的な確認を行う担当者がいれば、上記のような苦労は無かったかと思います。

しかし実際はそのような担当者は不在でした。
テストをスムーズに進めるためには、担当システムを飛び越えて仕様理解を深める等、こうした体制の不備を姿勢でカバーしていくことが大切だなと感じました。

※EAI：複数の異なるシステムを連携させ、データやプロセスを統合する仕組み、またはそのツールのこと

【投稿担当：T.O.】

皆さんはユーザが安心して利用できるシステムを構築するには、何が重要だと思いますか。

導入実績、要件定義、セキュリティ・・・色々な観点が挙げられると思いますが、システム開発の最後の砦として、テスト工程が非常に重要であると考えます。

特に10～20年以上利用されている、いわゆるレガシーシステムとの連携が必要となる場合は、仕様がブラックボックス化していることが多く、改修した機能が他の機能に思わぬ影響を及ぼすことや、未知の仕様によって想定外の挙動になることもあります。

そのため、本番同様の検証環境を用意し、開発者の思い込みを排除した網羅的なテストを行うことが最低限必要です。

具体的には、第三者によるテスト仕様書レビューやツールを用いたテスト自動化、また、過去の失敗事例などナレッジの共有を図ることで、テストおよびプロジェクト全体の品質向上に寄与すると考えます。

【投稿担当：T.N.】