コンサルタント記事

後工程を見据え、三社をつなぐ。BIレポート導入を前に進める判断軸

2026年06月23日

SHARE

話者：谷中裕典
所属：ノムラシステムコーポレーション　PMOコンサルティング事業部　BIチーム

本シリーズでは、ノムラシステムコーポレーションで活躍するコンサルタントの現場をお伝えしています。BIレポート導入で私が最も大切にしたのは、レポート単体を見るのではなく、後工程まで見据えて前提を揃えることでした。

今回のテーマは、SAP S/4HANAのバージョンアップに伴うBIレポート導入です。このプロジェクトは、お客様・当社・大手SIの三社で役割を分担しながら進めるものでした。本記事では、BIレポート導入の現場で実践してきた課題解決の進め方と、三社でプロジェクトを進めるために学んだことをお伝えします。

同じ現場に向き合い続け、業務背景まで理解する

私はPMOコンサルティング事業部のBIチームに所属し、入社3年目を迎えました。研修を終えて配属されてからは、同じプロジェクトに継続して関わっています。

ひとつの現場に長く携わることで、BIレポートの設計や開発だけでなく、お客様の業務背景や関係者間の調整についても学んできました。BIとは、社内のデータを集計・可視化し、意思決定に活用する仕組みを指します。

そのなかで私が主に担っているのは、レポートの設計と開発です。お客様の要件をどのようにレポートへ落とし込むかを設計し、実装するかを考えています。さらに、そのレポートが後工程（データ連携や運用）や他の領域にどのように関わるのかを、現場のなかで一つひとつ学んできました。

同じ現場に継続して関わったからこそ、レポートを単体で見るのではなく、業務全体やプロジェクト全体の流れの中で捉える視点が身についたと感じています。

お客様と大手SIの間で担った役割

私が参画しているプロジェクトは、SAP S/4HANAのバージョンアップに伴うBIレポート導入支援です。当社が受け持ったのは、BIレポートの導入と、お客様との要件整理でした。BIレポートにおけるお客様とのやり取りは当社が担います。

お客様からレポートの要件を伺い、必要なデータを整理したうえで、大手SIへデータの抽出元となるCDSビュー（*1）の作成を依頼する流れでした。しかし、進める中で各社の役割が曖昧になる場面もありました。

そのため三社で打ち合わせを行い、対応範囲や判断基準を一つひとつ確認しました。認識のずれを解消することで、手戻りを防ぐことができたと感じています。

*1 CDSビュー：「SAP S/4HANA」などで採用されている、データベースからデータを効率的に取得・加工するためのデータ定義フレームワーク。

後工程を止めないために、必要なデータ準備を前倒しする

お客様の要件を整理し、大手SIへ必要なデータを依頼する中で、後工程への影響を強く意識するようになりました。

BIレポートは設計・開発が完了しても終わりではなく、適切に運用できるかを確認する必要があります。そして、テストを行うためには元データがそろっていることが前提になります。私が担当していた原価系レポートでは、大手SI側でデータが生成されるため、準備が遅れるとテストに進めないと想定していました。

そこで、ただ待つのではなく、当社で先に進められるデータ投入を先輩に確認しながら対応しました。すべてを当社で担えるわけではないため、当社で対応できる範囲と大手SI側に依頼するべきところを切り分けていました。

要件整理を行うだけでなく、テストまで見据えて前提を整えることが、後工程の遅延を防ぐうえで重要だと感じています。

後工程への影響を基準に、優先順位を見極める

データ準備に遅れが出る中で、すべての作業を同じ優先度で進めることはできません。そこで大切にしていた判断軸が、後工程への影響度です。

例えば、後続のテストや他領域の確認に関わるレポートは優先して対応しました。これらは別領域の結果と突合する必要があり、遅れると他領域にも影響が出るためです。

一方で、後工程への影響が小さいものは、関係者と調整しながら進めました。週1回の進捗確認では、テスト状況やデータ準備の進み具合を共有し、影響度を基準に優先順位を整理していました。

また、後工程への影響に加え、お客様にとっての重要度も考慮しました。例えば、バージョンアップ前後で数値が正しく引き継がれているかを確認する「現新比較」は、お客様にとって重要度が高かったため優先して対応していました。

プロトタイプとコードで認識のずれを防ぐ

優先順位を整理しても、設計内容の認識がずれていれば、後続工程で手戻りが発生してしまいます。開発担当者の中には海外の方もおり、日本語での会話は可能でも、設計書に含まれるニュアンスの解釈に差が生じていました。

本来、当社の役割は大枠の設計を整理して渡すところまででした。しかし、認識のずれが残ったまま進むと修正が重なり、テストや後続工程にも影響が出てしまいます。そこで、言葉だけで説明するのではなく、自分で一度確かめたうえで、具体的な形にして伝えることにしました。

まず行ったのが、解釈の違いが起きそうな部分を検証用のプロトタイプとして自分で作ることです。「これであれば実現できそうだ」と確認したうえで、細部まで伝えて依頼しました。完成イメージを具体的に示すことで、相手にも意図が伝わりやすくなります。

さらに、必要に応じて簡易的なコードも示しました。言葉だけでは細かな解釈に差が出る場合でも、コードで示すことで、実装イメージを共有しやすくなります。「このような形で修正できるのではないか」と伝えることで、認識のずれを減らすことができました。

担当範囲だけを見れば、そこまで手を動かす必要はなかったかもしれません。それでも自分で確かめてから伝えたのは、後続工程の手戻りを防ぎ、プロジェクトを前に進めるためです。

対等な関係とスコープ管理がプロジェクトを支える

プロトタイプやコードで認識をそろえても、プロジェクトでは計画や要望が変わることがあります。実際に途中で要望が変わり、修正対応が必要になった場面もありました。

その際に意識したのは、当社、大手SIerで対応できることを明確に分けることです。役割などに変化があった場合は早めに共有し、次に何を確認すべきかを整理するようにしていました。また、遅れが出た場合も冷静に、作業量や影響範囲を整理し、事実ベースで話すことが必要です。

その他にも、スコープ管理は重要です。対応範囲が曖昧なまま進むと、「ここまで対応してもらえると思っていた」や「そこまでは想定していなかった」といった認識のずれが生まれます。その結果、誰がいつ対応するのかが曖昧になり、進行にも影響が出てしまいます。だからこそ、対応範囲は都度確認し、役割を明確にすることが必要です。