SaaSタイプのERPをFit to Standard で進めるためのToBeヒアリングとは① ヒアリングの重要性と業務ヒアリングの進め方

2025-01-23

ヒアリングほど担当者の能力に差が出る仕事はないでしょう。聞く内容やその聞き方によって、ユーザー企業の担当者は尊敬もするし、落胆もします。ましてや、変革が求められるERPプロジェクトならなおさらなことです。今回の記事では、そのヒアリングについて、さらにERPをFit to Standard で進めることに特化した手法として解説します。

ヒアリングの目的と進め方

ヒアリングは、プロジェクトの初期段階で行います。目的は、次フェーズの「業務構築」で実施するCRP（Conference Room Pilot：実機検証）に向けたモデル構築です。ヒアリングの内容は大きく三つに分かれます。

業務
システム
分析

プロジェクト開始時にはすでにビジネスプロセスモデルやビジネスデータモデルの概要がまとまっているはずなので、それらを元に、業務鳥瞰図や想定されるシステム間インターフェース、品目・BOM・顧客・仕入先といった主要マスターの定義をまとめておきます。“まとまっているはず”といっているのは、プロジェクト開始前にこれらを確認できていないと、ユーザー側と導入範囲（スコープ）の認識が合わない可能性があり、WBSやそれにより算出される見積金額の精度に大きな誤差が生じることになるからです。

現場を視察する意義

先ずは現場を視察します。製造業の場合であれば、全ての工場と主要な物流センター（DC）の現場に訪問して、モノの動き、人が何を見て、何を判断し、何を行うのか、レガシーシステムをどのタイミングで利用し、何を入力するのかをおおよそ把握します。

現行のAs-Is業務はシステムをバッチ処理で使用していることが多いため、新しい仕事の仕方（リアルタイム処理）になると何がどの様に変わるのかを捉えることが重要です。リアルタイム化は経営や管理部門にとってメリットがありますが、現場にとっては負荷が増えることも少なくありません。そのため、負荷をどう軽減するかという対策を考える必要もでてきます。

現地視察に際しては、工場や物流センターのレイアウト図、取り扱い製品、および生産量の情報を準備します。これにより、視察時の理解が深まり、その後のまとめ作業やBOMなどのビジネスデータモデルの構築に活用することができます。

現場情報を元に主要マスターの仮設モデルを構築

現場視察の結果を踏まえ、主要マスターに関するヒアリングをブラッシュアップします。例えば、BOMの場合、工程や設備、工程間にある在庫がフロー在庫かストック在庫かを確認し、中間品の可否やバッチ単位などを仮に決めていきます。また、モノの動きが「一個流し」なのか「パレットや通い箱」なのかによって、製造オーダーやロット、検査オーダーのまとめ方、シリアル番号の運用なども変わります。

さらに、Man（人）、Machine（設備）、Material（原材料）、Method（方法）の制約条件を洗い出すことも大切です。たとえば設備には生産量やメンテナンス時間、段取時間などの制約があります。これらはユーザーが要求事項として明示しなくても、導入ベンダー側で必ず把握しておかなければなりません。

こうした制約条件はやがて要求事項の優先度（MoSCoW）整理の際に参照され、実機検証で評価する対象になります。

ヒアリング開始前に合意すべきこと

ヒアリングに着手する前に、次の点をユーザー企業と合意しておきます。

ヒアリングの目的
ヒアリングの進め方とルール
ヒアリングの成果物
ヒアリングのスケジュールと対象者
ヒアリング時に準備する資料

業務ヒアリングの目的

ここからは業務ヒアリングを中心に解説します。主な目的は下記の通りです。

業務プロセスにおけるインプット・アウトプット、および確認作業や判断基準の確認
業務に関与する部門および関係者の特定
既存の課題や懸念事項の把握、改善機会の洗い出し
ERP標準プロセスの特定
業務要件の優先順位付け
運用移行の方針および計画策定

あらかじめヒアリングボードを用意し、RFPなどで既に起票されている要求事項（MoSCoW）をリスト化しておきます。業務プロセスの流れに沿って要求事項を確認することで、一問一答スタイルのヒアリングでは見落としがちな全体像と要求レベルを正確に把握できます。

※Ｂｉｆコンサルティングでは、Miroを用いてヒアリングを行うので、ヒアリングシートではなく、ヒアリングボードと呼ぶようにしています。詳しくは記事「miroで実現するERP導入プロジェクトの新たなステージ」を参照して下さい。

ヒアリングルールの設定

次に、ヒアリング時のルールをユーザーと合意します。例えば、

ヒアリングではERP機能の確認を行わない
建設的な議論を行う
人の意見を否定しない（ブレストのような発想で）
「これは常識」や「当たり前」と言ったバイアスのかかった発言をしない

などが挙げられます。特に「ERP機能の確認」については、ユーザーは新しいシステムが自分たちの業務にマッチしているか不安なので、ヒアリング内容によってはどうしても新しいシステムの機能を質問してしまうものです。しかし、これをやってしまうとベンダーは聞きたいことを聞くための時間が失われますし、そもそも機能検証は、次のフェーズで十分に実機検証するのですから、ヒアリング中にこのことに時間をかけるのは質、量ともに適切ではないのです。また、「常識」や「当たり前」といった発言は、ユーザー自身が問題に気づいていなかったり、質問者を萎縮させる恐れがあるので控えてもらいます。

ヒアリング日程と資料準備

ヒアリングを円滑に進めるには、キーパーソンが参加できるスケジュールを確保しておくことが重要です。事前準備をして挑まないと難航します。従って、プロジェクト開始時に、ユーザーが参加できる曜日と時間帯を毎週5〜6枠ほど確保しておくと、必要に応じてスムーズにアサインできるでしょう。

各チームで確保するセッション枠は、例えば以下のように想定します。

2セッション：定例会（週次進捗会議、チーム課題検討会）※1セッションあたり1時間
3〜4セッション：ヒアリング、トレーニング、CRP など　※1セッションあたり2時間

また、ヒアリングで準備しておくとよい資料としては、次のような例が挙げられます。

組織図
部門や課ごとの概要業務と従業員数
KPI、および KPI に影響を与える事象や問題点

ここまで準備できれば、ヒアリングの下準備はひととおり整ったといえるでしょう。

鳥瞰図から詳細フローへ

具体的なヒアリングの進め方として、先ずは業務鳥瞰図をERPシステムにあらかじめ用意された詳細なプロセスフローに沿って分解します。ここでは、「To-Beヒアリング」を意識し、ERP標準機能をベースに議論を進めることがポイントです。しかし、それでは「現行（As-Is）の必須業務が漏れないか？」という不安がでてきますが、後述する「トリガーイベント」の手順を踏めば、抜け漏れのリスクを防げます。

この際、業務フローごとにユーザーと概要の認識合わせを行い、ヒアリングボードを使って業務の用途・目的・流れを確認します。その上で、ERPが備える機能に沿って詳細な業務手順を洗い出していきます。ERP機能をベースにヒアリングすることで、次のような効果が得られます。

ユーザーが現行とは異なる新しい仕事の仕方に気付ける
ベンダー側が、CRP（実機検証）に必要なコンフィグレーションを早期に決定できる

As-Isヒアリングでは、ユーザーが「知っていてできていること」と「知っているができていないこと（ニーズ）」を把握できます。さらに、To-Beヒアリングでは、ERP機能を基にしたヒアリングを組み合わせることで、ユーザーが「知らずにできていなかったこと」に気づかせることができるのです。

ただし、機能に沿って業務を確認しているうちに、ユーザーはどうしても「今のシステムでのやり方」と比較してしまいがちです。そのため、あくまで「機能に沿ってヒアリングする」だけであり、詳細な機能説明まで踏み込まないよう注意が必要です。機能の説明に入ってしまうと、ヒアリングの本来の目的である“業務要件の深掘り”が阻害される可能性があるからです。

トリガーイベントの視点を押さえる

“必須”のAs-Is業務を漏れなく確認するためには、トリガーイベント（業務が動き始めるきっかけ）を把握する視点が役立ちます。例えば、顧客注文や仕入先からの納品といった外部イベント、在庫の発注点割れや仕損発生といった内部イベント、定期的に行われる棚卸などの定期イベントなどが挙げられます。これらをヒアリング時に意識しておくと、業務フローの起点がどこにあるのかを明確にでき、重要なプロセスを見落とすリスクを低減できます。

詳しいトリガーイベントアプローチの活用方法や具体例については、後日、ヒアリングのアペンディクスとして取り上げます。まずは、業務フローを俯瞰（鳥瞰図）しながら「どのイベントが、誰に、何の作業を促しているのか」を大まかに確認しておくだけでも、ヒアリングの効率と精度が向上します。

To-Beヒアリングの深掘り例

To-Beヒアリングでは、ERPシステムを設定（コンフィグレーション）するための基本情報を収集し、それを基に詳細を深掘りしていきます。例えば、生産計画立案を取り上げる場合、最初に以下のような基礎的な情報を確認します。

計画対象品種、計画期間、計画バケット、タイムフェンス
需要情報の種類（需要予測、顧客内示など）

次に、例えば以下のような質問を切り口にして、業務の詳細に踏み込み、さらに深掘りしていきます。

システムが立てた計画を人が変更するタイミングとその理由

ここでのポイントは、計画変更の作業をそのまま受け入れるのではなく、原因を追究し、計画変更をなくすにはどうすればいいかを検討することです。ある食品製造業では、計画変更の業務をなくし、自動発注によってペーパーリードタイムをゼロにした事例もあります。欠品を防ぐための手作業を安全在庫の管理でカバーできるとわかれば、自動化が可能になるわけです。

この様な粒度のヒアリングを200業務ほど行い、検証モデルの精度を高めていくのです。

複数工場の標準化

もう一つ重要な論点は、標準化です。たとえ複数の工場がそれぞれ異なる製品を製造していたとしても、生産チーム全体をひとつの単位としてまとめてヒアリングを行うことで、共通点を見つけやすくします。これにより、工場間の類似性をユーザー自身が認識しやすくなり、標準化への意識が高まります。

一方で、工場ごとに個別でヒアリングを実施すると、共通性の判断をベンダー側に委ねざるを得なくなり、ユーザー側での意識変革が進みにくくなるリスクがあります。標準化を進めるには、共通点の発見プロセスをユーザーと共有し、主体的な取り組みを促すことが重要です。

ヒアリング結果の可視化

工場ごとの違いを把握する際には、ヒアリング結果を可視化します。業務確認フローの近くに工場ごとに仕切りを入れた表を用意し、A工場で得た事実や要求、B工場で出た課題などを整理し、共通項と相違点を見比べます。ユーザーが自分たちで評価・比較できるようになると、標準化の判断がしやすくなります。

ヒアリング結果は付箋で表すとわかりやすいです。付箋の色分け例は以下の通りです。

黄色：現時点の事実や具体的状況（現状）
緑色：改善の機会やアクション（あるべき姿／要求）
赤色：解決すべき懸念事項（問題）

例えば、「受注入力に手作業で20分かかる」は事実、「人が足りない」は意思、「入力を自動化してほしい」は要求、といった具合に分けます。後の実機検証で活用しやすくなるよう、この整理を徹底します。

問題の原因を追究する姿勢

ヒアリングでは、問題を表面的に捉えず、その原因を追究することが重要です。例えば、「在庫が多い」という言葉をそのまま受け入れるのではなく、事象と基準の差を捉え、ビジネス的な影響や根本原因を特定する視点が必要です。このアプローチにより、課題を具体化し、対策の効果を定量化できるようにします。

こうした視点は、部門間連携を把握する際にも役立ちます。公開予定の記事では、部門間の視点の違いが問題発見を難しくしている実例（利害関係者の視点の把握）を紹介しながら、さらなる深掘り方法を解説します。詳しくは「2月13日公開予定の記事：問題発見から対策までのフレームワーク」をご覧ください。

部門間連携の確認

業務ヒアリングの最後は、部門を横断した情報連携をしっかりと確認することの重要性について説明します。例えば、製造部門では生産の作業実績を1日の終わりにまとめて計上している一方で、物流部門は在庫引当や出荷処理をリアルタイムでコンピュータに登録しているケースを挙げます。

製造部門が日中の進捗を即時にシステムへ登録しない状態だと、物流部門が参照する在庫や生産量の情報が最新ではなく、データにズレが生じる可能性があります。こうした部門間のタイミングの差から、以下のようなビジネスインパクトが発生します。

品揃えが見えにくい：
日中に生産が遅れたとしても、製造部門が実績を計上するのは1日の終わりのため、物流部門が最新の進捗を把握しづらく、対策が遅れる。
在庫・生産量との整合が取りづらい：
物流部門はリアルタイムで在庫を引き当てていても、製造側の生産実績が追いついていないため、実際には在庫がないのに出荷が可能と判断してしまったり、その逆が起きたりするリスクがある。
正確な納期回答が難しくなる：
営業担当が最新の生産進捗を把握できず、顧客へ提出する納期が実情と合わなくなる可能性がある。
管理コストの増大：
それぞれの部門が別々のタイミングで情報を更新しているため、問い合わせや追加確認が増え、業務効率が低下する。

なお、こうした問題が表面化していないように見える場合でも、在庫量に注意が必要です。在庫を多く抱えていることで一時的に問題を覆い隠している場合があり、実際には在庫過多によるコスト増大や管理の複雑化といった別の課題を抱えている可能性があります。

業務ヒアリングでの最終的な説明としては、これらの問題を解決するためには、

製造部門の作業実績をできる限りリアルタイムに反映できる仕組みを検討する
物流部門との情報連携を円滑化する

といった対策が必要となることを伝えます。川上（製造）から川下（出荷）まで、一貫した情報共有が行われるようにシステムや運用を見直し、部門間の連携を強化することを業務課題として真剣に取り組むことが求められるのです。

まとめ

今回の記事では、ヒアリングの重要性と業務ヒアリングの進め方について解説しました。目的やルールを明確にし、現場視察やTo-Beフローに沿った深掘りの情報収集で真の問題を洗い出すことが、Fit to Standard導入につながります。

次回は、この業務ヒアリングの成果をどのようにシステム面に反映するのか？　いわゆる「システムヒアリング」にフォーカスして詳しく見ていきます。

※次回記事：2025年1月30日公開予定