開発会社に「現場を見てもらう」ときの段取りと確認事項
提案書には「貴社の業務課題を解決します」と書かれているのに、実際にヒアリングを受けてみると、こちらの紙帳票やExcel台帳の実態をほとんど理解していない——製造業の業務システム開発でよくある、発注前のすれ違いです。
製造業向けの業務システム開発では、提案書の完成度だけで開発会社を選ぶと、稼働後に「現場のやり方と合わない」という事態に陥りがちです。その分かれ目になるのが、契約前に「現場を見てもらう」段階をどう設計するかです。この記事では、現場視察の準備から当日の段取り、視察後の提案書の見極め方までを具体的に解説します。
なぜ「現場を見てもらう」段階が成否を分けるのか
業種名や業務フローの一般論だけでは、紙・Excel運用の実態は分かりません。舶用バルブメーカーでも建築設備会社でも、図面の管理方法、検査帳票の書式、部品表（BOM：Bill of Materials＝製品を構成する部品や材料の一覧表）の粒度は会社ごとに異なります。開発会社選定の比較軸として、実績数や業種特化度に加えて「現場・設備・業務の固有事情を理解しているか」が重視される傾向が強まっています。
提案書に書かれる業務フロー図は、多くの場合ヒアリングシートへの回答をベースに作られます。しかし現場の紙帳票は、記入者ごとに微妙に書き方が違ったり、欄外にメモが書き込まれていたりします。この「正式なフローには載らない運用」こそ、現場視察でしか把握できません。
現場視察前に準備すべき具体物リスト
視察を有意義にするには、開発会社に「見てもらうもの」を事前に揃えておくことが欠かせません。当日にその場で探し始めると、限られた時間が資料探しで終わってしまいます。
図面PDF、部品表（BOM）、見積用の価格表など、製品情報の元になる資料一式です。フォーマットが複数存在する場合は、代表的なものを2〜3種類用意します。
紙の日報、検査成績書、点検表など、現場で日々記入している帳票の実物（またはコピー）です。記入例が入ったものの方が、運用実態が伝わりやすくなります。
既存の基幹システムやExcel台帳の入力画面・一覧画面のスクリーンショットです。「どの画面から」「どの項目を」入力しているかが分かる状態で用意します。
あわせて、視察当日に質問へ答える担当者のアサインも決めておきます。設計担当、製造現場のリーダー、事務・経理担当など、部門ごとに聞かれる内容が異なるため、複数名で分担するのが基本です。
開発会社が現場で実際にチェックするポイント
経験のある開発会社は、現場に入ると次のような点を観察しています。
誰が、どのタイミングで、どの帳票に記入し、それが最終的にどこ（誰の手元、どのExcelファイル）に集約されるのか。データの流れを実際の移動距離や作業順序とあわせて確認します。
手書きの略語、部署固有の記号、欄外メモなど、マニュアル化されていない「暗黙の記入ルール」がどれだけあるかを見ます。ここが多いほど、システム化時の入力項目設計が難しくなります。
関数やマクロがどこまで組まれているか、ファイルが誰と共有されているか、更新のタイミングは月次か日次か。台帳の「壊れやすさ」もあわせて確認されます。
このExcel台帳、担当者が異動したら誰が引き継ぐのか。
視察当日の段取り例
視察を効率よく進めるには、以下のような段取りを事前に共有しておくとスムーズです。
受注・設計・調達・製造・検査・出荷という工程の順に案内すると、データがどう変化しながら流れていくかが把握しやすくなります。
「図面周りは設計担当」「検査帳票は品質保証担当」というように、質問内容ごとに回答者を決めておくと、その場で答えに詰まる場面が減ります。
秘密保持契約（NDA）の締結状況、図面や画面の撮影・スクリーンショット取得の可否は、視察前に必ずすり合わせておきます。当日になって「撮影不可」が判明すると、後の提案書作成に支障が出ます。
視察後の提案書で見るべき変化
現場視察の成果は、その後の提案書に表れます。ここで見るべきは「業種名だけの一般論」から抜け出せているかどうかです。
「製造業向けに生産管理システムを提案します」という一般論の提案書と、「御社の検査帳票◯◯の記入項目を、入力フォームの必須項目として再現します」という具体的な提案書には、明確な差があります。実際の帳票名・図面番号・Excel台帳のシート名まで踏み込んだ記述があるかどうかが、現場をどれだけ理解できたかの目安になります。
Before/Afterの例で見てみましょう。
検査担当者が紙の検査成績書に手書きで記入し、事務担当者がその内容を週次でExcel台帳に転記。転記後、営業担当が別のExcelから価格表を参照して見積書を作成する、という3段階の運用でした。
検査担当者はタブレット上の入力フォームで検査結果を直接入力。「登録」ボタンを押すと検査データが一覧画面に反映され、営業担当は同じ画面から価格表データを呼び出して見積書PDFを出力できるようになります。紙帳票からExcelへの転記工程が1本減り、二重入力もなくなります。
このように、現場視察で得た具体物ベースの情報が、入力フォームの項目設計や画面遷移、出力ファイルの形式にまで反映されているかを、提案書の段階で確認しておくことが重要です。
現場視察からPoC・スモールスタートへ
現場視察で課題の輪郭が見えたら、いきなり全社導入を目指すのではなく、特定の工程・特定の帳票だけを対象にしたPoC（Proof of Concept＝概念実証、小規模な試行導入）から始めるのが現実的です。検査帳票1種類、あるいは1つの製造ラインだけを対象にスモールスタートし、実際の使われ方を確認してから範囲を広げていきます。
なお、現場理解が不十分なままAI導入やシステム化を急いだ結果、うまく定着しなかったケースも報告されています。具体的な失敗の傾向については、中小製造業におけるAI導入の失敗事例で詳しく紹介していますので、あわせて確認しておくと、現場視察の段階で何を見落とすと危険かの参考になります。
まとめ
- 要点1：製造業の業務システム開発では、提案書だけでなく現場視察の段階で紙・Excel運用の実態を確認することが成否を分ける
- 要点2：図面・BOM・検査帳票・画面キャプチャなどの具体物を事前に準備し、担当者を割り振っておくことで視察の質が上がる
- 要点3：視察後の提案書は、業種名だけの一般論か、実際の帳票・図面まで踏み込んだ内容かで開発会社の理解度を見極め、PoC・スモールスタートへつなげる
本記事はAIを活用して作成しています。内容についての責任は当社が負います。AI活用ポリシー