現場ヒアリングや合意形成に悩む企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、現場の要望を全部入れるのではなく、業務目的で整理することを重視して進め方を整理します。
この記事では、基幹システム再構築に現場部門をどう巻き込み、要望をどう整理すれば、使われるシステムになるかを整理します。現場ヒアリングの進め方に悩む推進担当者と、現場の協力を取りつけたい情報システム担当者に向けた内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
要望を「全部聞く」と「整理する」は別の作業
現場を巻き込む第一歩はヒアリングですが、聞いた要望をすべて機能に落とそうとすると、際限なく膨らみます。現場の声を丁寧に聞くことと、その声を業務の目的に照らして整理・取捨選択することは、まったく別の作業です。聞くときは全部聞く、整理するときは目的で仕分ける。この二つのモードを意識的に使い分けることが、現場巻き込みの要点です。
「あなたの意見を聞きたい」から始める
現場の協力を得るうえで最も大切なのは、最初の声かけの仕方です。「新しいシステムを入れるので協力してください」では、押し付けに聞こえます。「今の業務で困っていること、もっとこうなればいいのにという思いを聞かせてください」から入ると、主語が現場になり、参加への抵抗感が下がります。現場は「変えられる側」ではなく「変える側」だという位置づけが、プロジェクト全体の空気を決めます。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
よくある失敗は、ヒアリングをせずに現行踏襲で仕様を決め、完成後に現場から「使いにくい」と言われるケースです。現行踏襲は安全に見えて、実は現場の本当の不満を放置するだけの選択であり、投資に見合う改善を得られません。
逆に、ヒアリングで出た要望をすべて要件に入れてしまい、費用が倍に膨らむ失敗もあります。要望の背景にある業務上の目的まで聞き取り、その目的を達成する手段として要望以外の選択肢もあり得ることを示す。この「目的への翻訳」が、要望の取捨選択を合理的に行う鍵です。
また、一部の声の大きい人の意見がそのまま仕様になり、他の担当者の業務が考慮されないケースも要注意です。部門内でも業務は人によって異なるため、複数の担当者から聞き取り、全体像を組み立てることが偏りを防ぎます。
自社で確認できるチェックポイント
現場巻き込みの計画を立てる前に、次の点を確認しておくと、進め方が具体的になります。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
現場巻き込みならではの棚卸しポイント
基本のチェックリストに加えて、ヒアリング対象の部門と人数、各部門のキーパーソン、現場の繁忙期（避けるべき時期）、過去にシステム導入で現場と摩擦が起きた経験があればその内容を確認してください。特に過去の摩擦の記憶は、今回のアプローチを設計するうえで最も貴重な情報です。同じ轍を踏まない工夫を最初に組み込めるからです。
ヒアリングの結果は、要望と業務目的を対にして一覧表にし、優先度（必須・あると良い・今回は見送り）を付けて現場に戻してください。自分の声がどう扱われたのかが見える形で返すと、仮に見送りになった要望があっても、聞き捨てにされたという不信感を防げます。透明性が信頼を作り、信頼が協力を生みます。
現場巻き込みの工程で見落とされがちなのが、現場の成功体験を設計の中に組み込むことです。要件定義の途中でも「この機能はこう変わります」と具体的な画面イメージを見せ、「今の手作業が不要になりますね」と実感できる瞬間を作る。この小さな成功体験の積み重ねが、プロジェクト全体への前向きな空気を育てます。
延命・部分改善で対応できるケース
巻き込みの深さは、プロジェクトの規模に合わせて調整すべきです。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
小規模な部分改善なら、対象業務の担当者への短時間のヒアリングで十分です。大規模な再構築では、部門ごとにワークショップ形式で業務の流れを可視化する方法が、短期間で多くの知見を引き出せます。規模に合わない重い巻き込みは現場の反感を買い、軽すぎる巻き込みは仕様の漏れを生みます。
また、ヒアリングだけでなく、プロトタイプや画面モックを見せて反応を確かめる方法も有効です。言葉で伝えきれない操作感や画面の使い勝手は、触ってみないと判断できません。開発の後半まで現場確認を先延ばしにせず、要件定義の段階で触れる機会を作ることが、手戻りを防ぐ最良の手段です。
ヒアリングにかかる時間の目安は、部門あたり2〜4時間の面談を1〜2回、全体のワークショップがあれば半日〜1日を数回です。現場の時間を使うことへの遠慮から薄いヒアリングで済ませると、後からの仕様変更で何倍もの時間を失います。先に時間を使うほうが、総時間は少なく済みます。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
構築方式によって、現場巻き込みの力点は変わります。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
パッケージ導入では、標準画面と現場の業務の差を確認するFit&Gapの場に現場を入れることが最重要です。現場不在のFit&Gapは適合度の判定が甘くなり、稼働後の不満の火種を残します。
周辺開発で補うケース
周辺開発では、対象業務の担当者が開発の各段階で画面を触れる形を取ると、完成形のイメージが共有され、要望のずれが早期に修正できます。小回りの利く開発だからこそ、現場との距離を近く保ちやすい利点があります。
スクラッチ再構築が向くケース
スクラッチ再構築では、要件定義に現場のキーパーソンが深く関わり、業務フローを一緒に描くプロセスが不可欠です。開発会社は業務の答えを持っていません。現場から業務を引き出し、一緒に仕様に翻訳する共同作業です。
マクティズムの見解
マクティズムの見解として、現場部門を巻き込んだ基幹システム再構築の進め方では「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、現場の要望を全部入れるのではなく、業務目的で整理することを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
現場巻き込みの支援では、私たちが直接ヒアリングに同席することで、業務の話を聞きながら技術的な実現性と費用感を即座にフィードバックできるのが強みです。「それはすぐできます」「それは費用がかかります」がその場で伝わると、現場の期待値が最初から現実的な範囲に収まり、後の要件確定が格段に楽になります。対話の質を上げることが、結局は最短ルートだと考えています。
相談前に準備しておく情報
現場巻き込みの相談では、対象部門と人数、キーパーソンの候補、ヒアリングに割ける時間の目安、過去の摩擦経験が分かると、初回からヒアリングの設計を具体的に提案できます。現場の温度感を率直に教えていただくのが、最も助かる情報です。
実務では、ヒアリングの設計（対象・質問・時間・整理方法）を事前に計画し、聞き取り結果を要望一覧表として可視化したうえで、現場と一緒に優先順位を付ける流れをおすすめしています。
巻き込みの最終目標は、現場が「自分たちのシステム」だと感じてくれることです。そのためには、意見を聞いて終わりではなく、聞いた声がどう反映されたかを丁寧に伝え返す循環が欠かせません。この手間を省くと、稼働後の定着が苦しくなります。
現場の声を取り込んで作られたシステムは、教育のコストが少なく、定着が速く、改善要望も建設的になります。巻き込みの手間は、稼働後の運用で何倍にも回収される投資です。
巻き込みは、声かけと期待の共有、ヒアリングの実施、結果の可視化と返却、優先順位付けへの参加、プロトタイプの確認、の順で進めてください。すべての段階で「聞いて、返す」の循環を意識することが成功の鍵です。
巻き込みのタイミングは「できるだけ早く」が原則です。検討の初期から現場の声を入れるほど、方向のずれは小さく済みます。設計が固まってからの「確認」ではなく、固まる前の「一緒に考える」という関係をつくることが、巻き込みの本質です。
ヒアリングでは「理想の姿」だけでなく「絶対に困ること」も聞いてください。作業が増えるのが嫌、画面の切替が遅いのが嫌、二重入力だけはなくしてほしい——こうした「嫌なこと」のリストは、要件の優先順位を決めるうえで理想の要望以上に役立ちます。不満の解消こそが、現場にとっての最大の改善だからです。
そして、ヒアリングの最後に「他に気になっていることはありませんか」と一言添えてください。質問リストにない、でも現場がずっと気にしていたことがこの一言で出てくることがあり、それが最重要の要件だったというケースも少なくありません。
現場を味方にできたプロジェクトは、必ず成功します。巻き込みの手間を惜しまないでください。
聞く、返す、一緒に考える。この三つの動作を繰り返すだけで、現場との信頼関係は着実に積み上がっていきます。
よくある質問
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。ヒアリングの設計から一緒に行う形が、最も多い支援パターンです。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。はい。小規模なら対象業務の担当者との短時間面談だけで十分に機能します。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。業務フローの可視化やワークショップの運営も、一緒に行えます。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。はい。対象部門との面談数回程度から、柔軟に対応しています。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。現場の温度感をお聞かせいただくところから、進め方を一緒に設計します。
