エグゼクティブ・サマリー
- 要件定義書は仕様書ではない。「ロボットに何を、どの条件で、どこまでやらせるか」を発注側の言葉で確定させる文書であり、設計手段はここに書かない。手段まで書くと、実現方式の責任が発注側に移ってしまう。
- 見積が各社でばらつく最大の原因は価格差ではなく、要件の曖昧さを各社が別々に解釈していることである。「小物部品」「なるべく速く」「基本的に無人」——この三語があるだけで、提案の前提はまったく揃わない。
- 最も抜けやすいのは、対象物のばらつき・例外処理・段取り替え・上流下流のインターフェース・停止時の運用の五つである。これらは設計後に露見すると、追加費用と納期遅延に直結する。
- 性能要件は裸の数字で書かない。「どの条件下で、どの母集団に対して、どう測るか」をセットで書く。「タクト10秒」ではなく「対象A群（構成比70%）を、常温・定位置供給の条件で、連続100サイクル計測の平均で10秒以内」と書く。
- 要件定義書は一度書いて終わらせない。PoCの結果で更新することを前提に版管理する。書けない項目は「未確定・PoCで確定」と明記して残す。空欄のまま出すと、埋めたのは受注側の想像になる。
なぜ要件定義書で案件の成否が決まるのか
ロボット導入の相談を受けていて、最も多く目にする失敗は「動くものはできたが、現場で使えない」である。原因をたどると、設計や施工の腕前ではなく、要件定義の段階に行き着くことがほとんどだ。
現場は自分たちの作業を熟知しているがゆえに、当たり前のことを書かない。「たまに材料が濡れている」「月末だけ倍量流れる」「この工程は熟練者が目視で選別している」——現場では説明するまでもない事実が、文書には一行も現れない。受注側はそれを知らないまま、書かれた条件だけで最適な設計を組む。結果として、平常時は完璧に動き、現場の実態では止まる装置ができあがる。
要件定義書の価値は、網羅性でも分量でもない。発注側と受注側が同じ絵を見ている状態をつくること、それだけである。分厚い仕様書を作っても、対象物のばらつきが一行も書かれていなければ、その文書は役割を果たしていない。
1. 要件定義書の立ち位置——構想と設計のあいだ
ロボット導入の7工程（①RXビジョン・構想策定／②要件定義・PoC・選定・組成／③構築スケジュール・ToBe業務設計／④システム設計／⑤開発・導入／⑥定着化／⑦運用）のうち、要件定義書は②の中心成果物である。前後の文書との役割分担を明確にしておく。
| 文書 | 工程 | 答えるべき問い | 書く主体 |
|---|---|---|---|
| RX構想書 | ① | なぜやるのか。どこを目指すのか | 発注側（経営＋現場） |
| 要件定義書 | ② | 何を、どの条件で、どこまでやらせるのか | 発注側（受注側が支援） |
| 提案書・見積 | ② | どの方式で、いくらで、いつまでに | 受注側 |
| 基本設計書 | ④ | どう実現するのか | 受注側 |
ここで重要なのは、要件定義書の主体は発注側だという点である。「要件定義もお願いします」とSIerに丸投げした案件は、後工程で必ず揉める。受注側が書いた要件は、受注側にとって実現しやすい範囲に自然と収まるからだ。それが悪意によるものであることはまずないが、結果として現場の実態が落ちる。
とはいえ、発注側だけで書き切るのも現実的でない。妥当な分担は、「何を・どの条件で」は発注側が書き、「その書き方でよいか・技術的に測定可能か」を受注側または中立の第三者がレビューするという形である。構想段階の整理についてはRX構想策定の作り方を参照されたい。
2. 標準目次——12章立て
自社に様式がない場合、次の12章を出発点にするとよい。項目を減らすのは構わないが、章立てそのものを崩さないほうが、複数社比較のときに効く。
| 章 | 内容 | 書かないこと |
|---|---|---|
| 1 背景・目的 | 何のために導入するか。上位の経営目標との接続 | 期待効果の願望的な数字 |
| 2 対象範囲 | 対象工程・対象ライン・対象品目。範囲外の明記が特に重要 | あいまいな「等」「など」 |
| 3 現状業務 | 現行の作業手順、工数、人員、実測データ | あるべき姿の混入 |
| 4 ToBe業務 | 導入後の作業手順、人とロボットの役割分担 | 装置の構造 |
| 5 対象物要件 | 品目、寸法、重量、材質、ばらつき、荷姿 | — |
| 6 機能要件 | ロボットが担う動作と判断 | 実現手段（機種名、方式名） |
| 7 性能要件 | タクト、精度、稼働率、処理量。測定条件つき | 条件のない裸の数字 |
| 8 インターフェース要件 | 上流下流の設備・システムとの接続、データ連携 | — |
| 9 運用要件 | 段取り替え、異常時対応、日常点検、操作権限 | — |
| 10 非機能要件 | 安全、保守性、設置環境、電源・エア、拡張性 | — |
| 11 制約条件 | 設置スペース、予算枠、稼働停止可能期間、既存設備の制約 | — |
| 12 前提・未確定事項 | 現時点で決まっていないこと、PoCで確定させること | 空欄のまま放置 |
12章を独立して置くことに意味がある。未確定を未確定として明記した文書は、受注側がリスクを見込んだ見積を出せる。未確定が隠れている文書は、受注側が想像で埋めるか、あるいは全社が大きめのリスク費を積むため、比較の意味が失われる。
3. 「どこまで書くか」——粒度の判断基準
要件定義でいちばん難しいのは、網羅性ではなく粒度である。細かすぎると設計の自由度を奪い、粗すぎると解釈が割れる。判断基準は一つ、「その項目がずれたとき、追加費用または手戻りが発生するか」である。発生するなら書く、しないなら書かない。
| 書きすぎのサイン | 適正 | 書かなさすぎのサイン |
|---|---|---|
| ロボットのメーカー・機種を指定している | 動作と条件を書き、方式は問わない | 「自動化する」としか書いていない |
| 架台の寸法や配線経路まで決めている | 設置可能スペースと制約を書く | 設置場所が未定のまま |
| 画面のボタン配置を指定している | 誰が何を操作できるかを書く | 操作者の想定がない |
| ハンドの形状を図示している | 対象物の形状・材質・把持可能面を書く | 対象物が「部品」としか書かれていない |
例外として、既存設備との整合や社内標準がある場合は、手段を指定してよい。ただしそのときは「なぜ指定するのか」を併記する。理由が書かれていれば、受注側から「この制約は外せます」という代案が出てくる余地が残る。理由なき指定は、代案の芽を摘む。
4. 対象物要件——ばらつきを書けるかがすべて
ロボットにとって最大の敵は、平均値ではなくばらつきである。対象物要件では、代表値だけでなく必ず範囲と例外を書く。
書くべき項目は次の通り。品目一覧（構成比つき）、寸法（最小・最大・公差）、重量（同）、材質と表面状態、変形の有無、荷姿・供給状態（バラ積みか整列か、定位置か）、汚れ・水分・油分の有無、温度条件（常温か否か）、そして「イレギュラー品」の内容と発生頻度である。
現場ヒアリングでは、次の三つの質問が効く。
- 「この工程で、いちばん厄介な品物は何ですか」——例外品が言葉で出てくる。
- 「手が止まるのは、どんなときですか」——異常系の実態が出てくる。
- 「新人に説明しにくいのは、どの判断ですか」——暗黙知として自動化が難しい判断が特定できる。
三つ目が特に重要である。熟練者が無意識に行っている判断は、要件定義書に書かれないまま自動化対象に含まれ、後で「AIで何とかしてほしい」という無理な要求に化ける。言語化できない判断は、いったん人が担う設計にするのが定石だ。
5. 性能要件——条件と測定方法をセットで書く
性能要件は、要件定義書の中で最も揉める章である。数字が一人歩きするからだ。次の形式で書くことを推奨する。
タクトタイム：対象A群（構成比70%）を、常温・定位置供給・段取り替えなしの条件下で、連続100サイクル計測した平均値で1個あたり10秒以内とする。段取り替え時間は含まない。B群（構成比25%）は15秒以内、C群（構成比5%）は要件対象外とする。
裸の「タクト10秒」と比べると冗長だが、この一文があるだけで、検収時の紛争はほぼ消える。押さえるべき要素は四つ——母集団（何に対して）／条件（どんな状態で）／測定方法（どう測って）／除外（何を含まないか）。
稼働率も同様である。「稼働率95%」は、分母に段取り替えを含むか、計画停止を含むか、チョコ停の定義をどうするかで、まったく別の要求になる。定義を書かない稼働率要件は、要件として機能していない。実運用でどう測り続けるかは定着化・運用設計の観点と合わせて確認するとよい。
6. インターフェース要件と運用要件——最も抜ける二章
設計後に問題が露見する項目は、ほぼこの二章に集中する。抜けやすい9項目を挙げる。
インターフェース要件
- 上流工程からの供給方法（誰が・どの容器で・どのタイミングで）
- 下流工程への払い出し方法と、下流が詰まったときの挙動
- 生産管理システムとのデータ連携（品目情報をどう受け取るか、実績をどう返すか）
- 既存設備との信号のやりとり（インターロックの範囲）
運用要件 5. 段取り替えの手順と所要時間、誰が実施するか 6. 異常停止時の復旧手順と、復旧できる人の範囲 7. ロボット停止中の代替運用（人手で回すのか、ラインを止めるのか） 8. 日常点検・清掃の項目と頻度 9. 操作権限の区分（オペレーター／保全／管理者で何ができるか）
7番——停止時の代替運用は、要件定義書に書かれていることがほとんどないにもかかわらず、導入後の満足度を大きく左右する。自動化した工程は人手のやり方を失っていくため、止まったときに何もできなくなる。「ロボット停止時は従来手順で1日◯個まで対応可能とし、そのための治具と手順書を残す」と書けている案件は、運用が安定する。
複数の設備やベンダーが絡む場合の接続責任の切り分けはコンソーシアム型導入のプロジェクトマネジメントも参照されたい。
7. 非機能要件——安全・保守・環境
安全については、要件定義書の段階で「リスクアセスメントを誰がいつ実施し、その結果を誰が承認するか」を書いておく。具体的な保護方策（安全柵か、監視センサーか、協働ロボットの力制限か）は設計側の領域であり、ここで決め打ちしない。ただしリスクアセスメントの実施と記録の残し方を要件として明記することは、発注側の責任である。
保守性では、消耗品の種類と交換頻度、予備品の考え方、遠隔での状態確認の可否、対応時間（平日日中か、24時間か）を書く。ここを書かないまま契約すると、保守費の前提が各社バラバラになり、初期費用だけで比較して後で総額が逆転する。5年TCOの積み方はロボット導入の投資対効果（ROI）の語り方で詳述している。
設置環境では、床の耐荷重と平坦度、天井高、電源容量、エア、通信環境、粉塵・温湿度、周辺作業者の動線を確認する。現場で測れば済むことなので、要件定義の段階で実測しておく。
8. 合意プロセスとレビュー——発注前に潰すチェックリスト
書き上げた要件定義書は、発注前に次の観点でレビューする。社内の第三者、または中立の立場の外部が読むと、抜けがよく見える。
| # | 確認項目 | 落ちていたら |
|---|---|---|
| 1 | 対象範囲に「範囲外」が明記されているか | 追加費用の温床 |
| 2 | 対象物のばらつきと例外品が書かれているか | 設計後の手戻り |
| 3 | 性能要件に条件・測定方法・除外があるか | 検収時に紛争 |
| 4 | 停止時・異常時の運用が書かれているか | 導入後に現場が混乱 |
| 5 | 上流下流とのインターフェースが特定できているか | 責任範囲の空白 |
| 6 | 段取り替えの担当と時間が書かれているか | 実稼働率が計画を下回る |
| 7 | 未確定事項が「未確定」として明示されているか | 受注側の想像で埋まる |
| 8 | 手段を指定した箇所に理由が併記されているか | 代案が出てこない |
| 9 | 現場のオペレーターが読んで違和感がないか | 定着しない |
9番は形式的なチェックに見えて、実は最も効く。要件定義書を現場のオペレーターに読ませ、「これで自分の仕事は回るか」を聞く。ここで出てくる指摘は、机上のレビューでは絶対に出ない。
そして、要件定義書はPoCの後に必ず更新する。PoCは要件の妥当性を検証する場であり、そこで判明した対象物のばらつきや処理時間の実測値は、要件定義書に反映されて初めて意味を持つ。PoCの設計についてはPoC（実証実験）の設計と評価を参照されたい。版数と更新日、更新理由を残す運用にしておくと、後任者が経緯を追える。
まとめ
要件定義書は、分厚さでも網羅性でもなく、発注側と受注側が同じ絵を見られるかどうかで評価される。押さえるべきは五つ——範囲外の明記、対象物のばらつき、条件つきの性能要件、停止時の運用、そして未確定事項の明示である。この五つが書けていれば、多少形式が崩れていても案件は前に進む。逆に、この五つが抜けた美しい仕様書は、設計後に必ず揺り戻しを起こす。よくある失敗の類型はロボット導入の失敗パターンと回避にまとめている。
RobiZyはロボットを売らないNPO法人であり、特定のメーカーやSIerの立場を持たない中立のコーディネーターとして、構想策定から要件定義、選定、導入、定着化までを伴走している。要件定義書のレビュー、現場ヒアリングの設計、複数社比較の進め方など、「まだ何を書けばよいか分からない」という構想段階のご相談を歓迎する。文書の形になる前の状態でこそ、中立の第三者が入る価値が大きい。まずは気軽にご相談いただきたい。