要件定義書が「機能一覧の写経」になる
MESの要件定義でよく起きるのは、ベンダーの標準機能一覧をベースに要件表を作ってしまう進め方です。行が製品側の機能単位で切られているため、自社の業務が2つの機能にまたがる場合や、逆に1機能の一部しか使わない場合に、要件が正しく表現できません。結果として「標準機能で対応可」と合意したはずの項目が、設計フェーズで「その運用は想定外」となって戻ってきます。
もう一つの問題は、要件の粒度が揃わないことです。「作業実績を登録できること」という1行と、「加工開始時刻を、設備からの信号で自動取得し、手入力による上書きを職制承認つきで許容すること」という1行が、同じ表に同じ重みで並びます。前者は合意にならず、後者だけが合意になります。
要件定義書に必要なのは網羅性ではなく、行の切り方と、合意した定義を書き残す欄です。
テンプレートの収録内容（286要件・9領域）
Excel版（1シート1領域、フィルタ・集計マクロ付き）で配布しています。行の構成は「要件ID／業務領域／要件文／優先度（MUST・SHOULD・COULD）／根拠（規制・顧客要求・社内規程）／合意された定義／確認方法／担当部署」の8列です。
| # | 領域 | 要件行数 | 主な論点 |
|---|---|---|---|
| 1 | 受入・投入 | 22 | 材料ロットの引当、投入実績、代替材の扱い |
| 2 | 製造指示・実績 | 34 | 指示の分割・併合、実績登録の粒度、時刻の正 |
| 3 | 品質・検査 | 31 | 検査計画、規格値、逸脱時の停止、再検査 |
| 4 | トレーサビリティ | 24 | 前方・後方追跡、系譜の深さ、追跡所要時間 |
| 5 | 設備・保全 | 19 | 稼働状態の定義、停止理由コード、保全連携 |
| 6 | 作業者・力量 | 16 | 資格の有効期限、無資格者の作業抑止 |
| 7 | 在庫・仕掛 | 21 | 仕掛の定義、ERP在庫との差異調整 |
| 8 | 連携インターフェース | 31 | 粒度・タイミング・キー、再送と重複排除 |
| — | 機能要件 小計 | 198 | |
| 9-a | 性能 | 18 | 同時接続、応答時間、バッチ処理時間 |
| 9-b | 可用性・BCP | 12 | 停止許容時間、切替方式、ネットワーク断 |
| 9-c | セキュリティ | 21 | 権限モデル、監査証跡、OT側の分離 |
| 9-d | 運用・保守 | 15 | 監視、バックアップ、バージョンアップ |
| 9-e | データ移行・保存 | 12 | 初期移行、保存年限、削除・匿名化 |
| 9-f | 国際化・多拠点 | 10 | 言語、時刻、単位、データ所在 |
| — | 非機能要件 小計 | 88 | |
| — | 合計 | 286 |
書き方の実例を4つ
1. 優先度は3段階にして、MUSTを全体の3割以下に抑える
MUST／SHOULD／COULDの3段階で運用します。実務上の目安は、MUSTを全要件の30%以内に収めることです。半数以上がMUSTになっている要件定義書は、優先度が機能していません。テンプレートには領域別のMUST比率を自動集計するシートを付けてあり、30%を超えると色が変わります。
2.「合意された定義」欄が本体である
要件文の隣に、その要件で使った言葉の定義を書く欄を設けています。たとえば「仕掛」。工程間バッファにある品物を仕掛と呼ぶのか、投入済み・完成未計上のすべてを仕掛と呼ぶのか。この定義がずれたまま進むと、ERP在庫との突き合わせ設計で必ず衝突します。マスタ設計の記事でも触れていますが、定義の合意はマスタ設計より前に済ませておく項目です。
3. 連携要件は「粒度・タイミング・キー」の3点セットで1行にしない
領域8の31行は、連携先ごとに3行を1組として設計してあります。たとえばERPへの生産実績連携なら、①粒度（オーダー単位か、ロット単位か、時間区切りか）②タイミング（都度か、日次バッチか、しきい値到達時か）③キー（製造指図番号か、独自の実績IDか）を別々の行として合意します。1行にまとめると、必ずどれかが曖昧なまま残ります。
4. 非機能の「保存年限」は削除要件とセットで書く
保存年限の要件だけを書いて、削除の要件を書かない例が非常に多く見られます。10年保持と決めたなら、11年目のデータをどうするか（物理削除・アーカイブ移送・匿名化）まで書きます。ここが空欄だと、稼働5年目にデータベースの肥大化として顕在化し、性能要件の未達につながります。
286要件を収録したExcel版テンプレート（MUST比率集計シート付き）を無料でお送りします。貴社の業種に合わせた領域の追加・削減もご相談いただけます。
使い方の推奨手順
- 削る作業から始める。 286行すべてが自社に必要ということはありません。まず自社に無関係な領域を丸ごと落とし、残った行の要件文を自社の言葉に書き換えます
- 領域ごとに責任者を1名決める。 品質は品証、設備は保全、連携は情シス。8領域を1人で埋めると、粒度が揃う代わりに現場と乖離します
- 「合意された定義」欄を先に埋める。 要件文より定義が先です。定義が書けない要件は、まだ要件になっていません
- スコープの記事と往復させる。 要件を書くほどスコープは膨らみます。領域単位で「今回はやらない」を確定させ、COULDへ落とすのではなく表から外してください
要件定義書に書くと後で困る3つのこと
要件が固まったら、そのままRFPの第5〜7章へ流し込めるよう、RFPテンプレートと列構成を揃えてあります。
無料ですか。あとから営業されませんか
無料です。ご請求いただいた資料への課金は一切ありません。ご相談の希望を書いていただいた場合のみご連絡し、それ以外で継続的な営業のご連絡をすることはありません。
すでに他社パッケージの導入が決まっています。使えますか
使えます。要件定義書は製品非依存の書式にしてあります。導入が決まっている場合は、優先度欄を「標準機能で充足／設定で充足／追加開発／運用でカバー／今回は対応しない」の充足方法欄に読み替えて使うと、そのままフィットギャップ表になります。
既存システムのリプレースです。現行機能の棚卸しにも使えますか
使えます。要件文はそのまま、優先度欄の代わりに「現行で実現済み／現行では未実現／現行にあるが使っていない」の3区分で埋めてください。3つ目に該当する行が多いほど、リプレース時にスコープを削れる余地があります。
