製造業システムの要件定義で確認する項目

要件定義の成果物

• 対象業務の範囲と対象外の明示（どこまでを今回作るか）
• 現行業務フローと、将来の業務フロー
• データ項目表（マスタ、トランザクション、履歴）
• 画面・帳票の一覧と、それぞれの利用者・利用場面
• 外部連携仕様（相手システム、方式、タイミング、失敗時の扱い）
• 非機能要件（性能、可用性、権限、ログ、保守時間帯）
• データ移行方針と検証方法
• テスト・教育・切替の計画
• 見積の前提条件と、除外事項

これらは特定の開発会社に依存しない形で作れます。他社への見積依頼にもそのまま使えるため、要件定義だけを先に切り出して発注する進め方は合理的です。

対象業務と例外の確認

• 対象業務の始まりと終わり（どの伝票・指示から始まり、何をもって完了か）
• 登場人物と役割（入力する人、承認する人、結果を見る人）
• 例外パターン（特急、分納、仕様変更、手配替え、返品、再検査）
• 例外の発生頻度と、現在どう処理しているか
• 締め処理（日次・月次で何を確定させるか、遡って訂正できるか）
• 現在Excelで行っている計算・判定のロジック

例外の扱いが要件定義の中心です。標準フローだけを定義したシステムは、稼働後に「例外のときだけExcel」という運用を生み、データが分断されます。

マスタ・トランザクション・履歴

端末・設備・ネットワーク

• 現場で使う端末（PC、タブレット、ハンディ、既設の現場端末）と、その台数・設置場所
• 入力方法（キーボード、バーコード、QR、RFID、音声、設備からの自動取得）
• 手袋・粉塵・油・照明など、現場環境による制約
• 工場ネットワークと情報系ネットワークの分離状況、通信の可否
• 通信断が起きる場所と、その間の運用（オフライン入力の要否）

外部連携

• 連携先システムの名称・バージョン・保守ベンダー
• 連携方式（API、CSV、DB、EDI、メール取り込み）と、テスト環境の有無
• どちらのシステムを正とするか（マスタ単位で決める）
• 同期のタイミングと、遅延が許される時間
• 失敗時の扱い（再送、通知、手動取り込み、保留）
• 相手システム側の改修が必要か、その費用は誰が持つか

権限・ログ・性能・可用性

• 権限（誰がどのデータを見られるか、原価・単価の閲覧制限）
• 承認フロー（誰が、どの条件で承認するか、代理承認の可否）
• 操作ログ・変更履歴の記録範囲と、改ざん防止の要求水準
• 同時利用者数と、ピーク時（月末、繁忙期）の負荷
• 止められない時間帯と、保守作業を行える時間帯
• バックアップと復旧目標（どこまで戻せれば業務が続くか）

データ移行・テスト・教育・切替

1. 移行対象と年数を決める（全件移行が必要とは限らない）
2. 表記ゆれ・重複の整理基準と、判断する人を決める
3. 移行後の検証方法（件数、合計、抜き取り）を移行前に合意する
4. テストは本番相当のデータで、現場の担当者自身が入力して確認する
5. 教育の対象者、方法、所要時間を決める（交代制なら全直をカバーする）
6. 切替方式（一斉切替か並行稼働か）と、戻す条件をあらかじめ決める

見積依頼書に含めると比較が揃う項目

• 対象業務と対象外の明示
• 利用者数、拠点数、端末の種類
• 連携先システムと方式、相手側の協力可否
• 移行データの範囲と現状の品質
• 非機能要件（権限、ログ、性能、保守時間帯）
• 希望時期と、決裁のスケジュール
• 見積の内訳区分（要件定義／開発／移行／テスト／教育／保守）の指定

よくある質問

要件定義にはどのくらい期間がかかりますか。

対象業務の数と、社内で意思決定できる体制があるかで変わります。1業務に限定し、関係者が決まっていれば数週間規模、複数業務にまたがる場合はそれ以上を見込みます。期間を短くする最大の要因は、発注者側で「決める人」が決まっていることです。

現場が忙しく、ヒアリングの時間が取れません。

全員に長時間のヒアリングを行う必要はありません。実際に使っているExcelや帳票を見せてもらい、そこに現れる項目と例外から質問を絞る方法をとります。そのうえで、確認が必要な点だけを短時間で聞く形にします。

要件定義の成果物は他社への見積依頼に使えますか。

使えます。特定の技術構成に依存しない形（業務、データ項目、連携、非機能、移行）で作るため、複数社へ同じ条件で見積を依頼でき、比較の前提が揃います。