要件定義書に並んでいる「要件」の多くは、要件ではない
MESの要件定義書に最も多く書かれている文は、次の形をしています。
「製造実績を工程単位で登録できること」
これは要件ではなく機能の名前です。この一文からは、いつ登録するのか、誰が登録するのか、何を登録単位にするのか、登録しなかった場合に次工程へ進めるのか、が一切読み取れません。ベンダーはこれを読んで「標準機能で対応可」と回答し、実装フェーズで初めて認識のずれが露見します。
要件になっているかどうかの判定は単純で、その文だけを読んで、実装者が画面と処理を一意に決められるかです。決められないなら、それは要件ではなく見出しです。
MESの要件定義でずれが生まれる箇所は、経験上ほぼ次の5つに集中します。
論点1・2：現行踏襲と、後回しにされる例外処理
論点1：「現行どおり」という要件。 現行システムやExcel帳票を指して「現行どおりでお願いします」と書かれた要件は、必ず紛糾します。現行の仕様を完全に文書化している企業はまれで、実際の運用は文書化されていない例外処理の集合体だからです。ベンダー側は「現行の帳票を再現する」と解釈し、発注側は「現行の運用がそのまま回る」と解釈します。この2つは別物です。
対処は、現行踏襲を要件から禁止することではなく、現行踏襲と書く場合は対象を成果物単位で特定することです。「現行の作業日報（様式QA-012）と同一項目・同一並び順で出力できること」であれば、判定できます。
論点2：例外処理の先送り。 要件定義の前半は正常系の議論で進み、例外処理は「あとでまとめて」となりがちです。しかしMESの実装工数は、例外処理が支配します。次の5つは、どの工場にも存在するにもかかわらず要件定義書に書かれないことが多い項目です。
- 手直し・再作業：不良と判定したものを直して同じ工程に戻すとき、実績と工数はどう記録するか
- 途中投入・飛び番：工程を飛ばす、または途中から入る指図をどう扱うか
- 判定保留：検査結果が出るまで次工程へ進めるのか、止めるのか
- 設備故障時の代替設備：ルーティングと違う設備で作った実績をどう残すか
- システム停止時の運用：紙に書いて後から入力するのか、入力を待つのか
この5つを要件定義の最初の2週間で洗い出すと、その後の設計が安定します。逆に後半に回すと、追加開発として見積が跳ね上がります。
論点3・4：データの粒度と、「止める権限」の所在
論点3：粒度とタイミング。 MESの設計判断で最も後戻りが高くつくのが、実績データの粒度です。粒度は「どの単位で、いつ、誰が」の3点で決まります。
| 決めるべき項目 | 選択肢の例 | 決めないと起きること |
|---|---|---|
| 実績の登録単位 | 指図単位／ロット単位／個体単位／時間単位 | 稼働後に集計粒度を変えられず、原価計算に使えない |
| 登録タイミング | 工程開始時／完了時／両方 | 仕掛（WIP）の数量がERPと合わない |
| 登録の主体 | 作業者手入力／設備からの自動取得／混在 | 自動取得前提で設計し、後から手入力画面を追加開発 |
| 数量の扱い | 良品のみ／良品＋不良／投入＋産出 | 歩留まりが計算できない |
| 時刻の基準 | 端末時刻／サーバ時刻／設備時刻 | 監査で時系列の整合を説明できない |
最後の「時刻の基準」は地味ですが、規制産業では監査で必ず問われます。複数拠点にまたがる場合はタイムゾーンの保持方法まで決めておく必要があります。
論点4：誰が止められるか。 MESの本質的な価値は記録ではなく統制、つまり条件を満たさない作業を成立させないことにあります。ところが要件定義では「〜を記録できること」ばかりが書かれ、「〜の場合は次工程へ進めないこと」が書かれません。
止める要件を書くときは、必ず3点セットで書いてください。①どの条件で止めるか、②誰が解除できるか、③解除した記録をどこに残すか。この③が抜けると、稼働後に「解除が常態化して誰も止まらないMES」になります。実際、稼働1年後に監査で問題になるのはほぼこのパターンです。
論点5：非機能要件を数値で書けているか
機能要件に比べて、非機能要件は驚くほど雑に扱われます。しかしMESは24時間稼働の現場に置かれるため、非機能の不備は稼働直後に必ず表面化します。最低限、次の項目は数値で書いてください。
- 応答時間：現場端末のバーコード読み取りから画面遷移まで何秒以内か（実務上は1秒以内が目安）
- 同時接続数：ピーク時の端末数と、その1.5倍で動作すること
- 稼働率と計画停止：月次のメンテナンス窓は何曜日の何時から何時間取れるのか
- ネットワーク断時の動作：何分間オフラインで作業を継続できるか。復旧時のデータ同期はどうなるか
- データ保持期間：オンラインで何年、アーカイブで何年。規制産業では製品寿命＋αが要求される
- 帳票の出力性能：月次の全数出力に何分かかってよいか
このうちネットワーク断時の動作は、MESに固有かつ影響が大きい項目です。事務系システムなら「復旧を待つ」で済みますが、ラインは止められません。オフライン継続の要否は、機能要件ではなくアーキテクチャの選択を左右します。
なお、MES購買における要件の重みは統合性に移っています。Rockwell Automationが17カ国1,560名の製造・産業オペレーション意思決定者に実施した調査（2026年7月28日公表）では、MES購買要件の第1位に「統合性」を挙げた回答が44%、ERP・PLM・品質・OTと完全に統合できていると回答したのは23%でした。連携要件を後回しにすると、この23%側に入れないということです。連携の設計はMES-ERP連携の設計で個別に扱います。
そのまま使える書き換え例
要件文の善し悪しは、抽象論よりも対比のほうが伝わります。実際の要件定義書でよく見る文と、判定可能な形に書き直した例を並べます。
| よくある要件文 | 判定可能に書き直した要件文 |
|---|---|
| 製造実績を工程単位で登録できること | 作業者が端末でロット番号をバーコード入力し、良品数・不良数・不良コードを登録できること。登録は工程完了時に行い、登録前は次工程の開始を不可とする |
| トレーサビリティを確保できること | 完成品のシリアル番号から、投入した材料ロット・作業者・設備・工程パラメータを3分以内に一覧で出力できること |
| 現行の帳票を出力できること | 現行の作業日報（様式QA-012）と同一項目・同一並び順のPDFを、指図単位で出力できること |
| 未校正の設備を使わせないこと | 設備マスタの校正期限を超過した設備が指図に割り当てられた場合、作業開始を不可とする。品質管理者の権限で解除でき、解除者・解除時刻・理由を監査証跡に記録する |
| 使いやすい画面であること | 現場端末の1画面あたり入力項目を5項目以内とし、手袋着用状態でタッチ操作できるボタンサイズ（最小44px相当）とする |
書き換えの型は共通しています。「主体・トリガー・対象・判定基準・不成立時の挙動」の5要素を入れることです。5要素のうち3つ以上が書けない項目は、その時点で業務側の合意が取れていないというサインです。要件定義の場で気づけば設計変更で済みますが、テスト工程で気づくと仕様変更になります。
よくある質問
要件定義はベンダーに手伝ってもらってよいですか？
手伝ってもらって構いませんが、その場合は選定後のベンダーに依頼することになるため、順序に注意が必要です。選定前に必要なのは網羅的な要件定義書ではなく、比較可能なRFPです。RFPの段階では、上に挙げた5論点のうち論点2（例外処理）・論点3（粒度）・論点5（非機能）だけを自社で固め、詳細はベンダー確定後に共同で詰めるのが現実的です。
要件定義にどれくらいの期間をかけるべきですか？
1工場・1ラインの範囲で3〜4か月が目安です。これより短い計画は、例外処理の洗い出しを省略している可能性が高く、実装フェーズで取り戻すことになります。逆に6か月を超えて長引いている場合、原因は要件の量ではなく決定権の所在です。プロジェクト体制の決裁ルールを先に見直してください。
「Fit to Standard」で進めるなら、要件定義は不要ですか？
不要にはなりません。ただし目的が変わります。Fit to Standardでは、要件定義は「作るものを決める」作業ではなく「標準機能に合わせて業務のどこを変えるかを決める」作業になります。変える対象を特定するには、現行業務の例外処理を把握している必要があるため、論点2はむしろ重要度が上がります。詳しくはFit to Standard を貫くための意思決定を参照してください。
