機械設計 #43：自動機の要求仕様 — FATを議論にしない書き方

仕様書には、次のような一文が書かれがちです。

機械は安定して動き、モデル替えが速く、保全しやすいこと。

製作者は一つの意味で読み、機械所有者は別の意味で想像します。FATになると、「安定とは何時間か」「対象モデルはどれか」「速さはどの時点から測るか」「誰が段取り替えするか」「保全しやすさをどう証明するか」という議論になります。

これは受入れ会議だけの問題ではありません。プロジェクトの初期に要求が不十分だったということです。

より強い流れは次の通りです。

ステークホルダーのニーズ → 運転コンテキスト → 要求 → 受入れ基準 → 検証方法・ゲート → 証拠 → ベースライン・変更

本稿では、自動機の要求を明確、測定可能、追跡可能にする方法を説明します。契約、適用規格、機械のリスクアセスメント、案件固有の安全要求を置き換えるものではありません。

1. ニーズ、要求、制約、設計判断を分ける

ステークホルダーのニーズ

ニーズは、利用者が解決したい問題や得たい結果です。

生産チームは、プログラミング技術者に頼らずモデルを切り替えたい。

目標は理解できますが、これだけでは受入れできません。

要求

要求は、対象範囲と条件が明確で、検証できるシステムの義務です。

指定された状態と条件で、権限を持つ利用者が対象モデル間の段取り替えを実施し、参照する受入れ基準を満たすこと。

制約

制約は解決策を限定します。設置寸法、利用可能なユーティリティ、適用規格、承認済み部品群、必須インターフェース、環境やセキュリティの制限などです。制約には出所と理由を付けます。単なる好みを制約にしません。

設計判断

共通ベースと交換部品を使う、サーボか空圧かを選ぶ、QRコードかレシピ選択を使う、といった内容は設計判断です。早い段階で要求として固定すると、トレードオフを比較する前に解決策を狭めてしまいます。

2. 要求はWHAT、設計はHOWを決める

「位置へ速く到達するためサーボを使う」は、方式を先に選び、位置、荷重、時間、精度、再現性、検証方法を定義していません。まずは次のように結果を書きます。

機構は、定義した荷重条件で対象位置へ到達し、時間、精度、再現性の参照限界を満たすこと。

その後にサーボ、シリンダ、カムなどを比較します。顧客標準のプラットフォームのようにHOWが本当の制約なら、承認済み制約として記録します。

3. 一つの要求に一つの主な義務

「自動供給し、向きを確認し、不良を排出し、データを記録し、材料不足を警告する」という一文では、どれか一つが失敗した時の判定が不明です。供給、向き確認、不良ルート、記録、材料不足警告へ分けます。

細かく分けすぎる必要はありません。明確な主語、主な義務、関連条件、管理できる検証ルートを持たせます。

4. 数値の前に運転コンテキストを書く

「サイクルタイムはX秒以下」だけでは、モデル、材料、開始・終了イベント、オペレーター時間、上下流待ち、モード、ユーティリティ、リトライや排出の扱いが分かりません。精度にも対象量、基準、測定条件、計器と方法、サンプル計画、合否規則が必要です。

すべてを一文に詰め込む必要はありません。管理された定義書や検証仕様へ参照してもよいのですが、コンテキストをチャットの記憶に置かないことが重要です。

5. 曖昧な言葉を観察可能な特性に変える

「速い」「安定」「正確」「使いやすい」「保全しやすい」「頑健」「低不良」「完全自動」「互換」「必要な時」「合理的」は、受入れで争点になりやすい言葉です。禁止するのではなく、観察できる特性へ変換します。

「保全しやすい」なら、摩耗部品へのアクセス、交換時間と工具、基準の保持、復旧確認、診断情報、予備品の識別を定義します。「安定」なら、運転時間、モデル構成、停止分類、アラームとリトライ、出力品質、稼働率やスループットの定義を決めます。

6. 要求にIDと出所を与える

重要な要求には、固有ID、文、出所または所有者、必要な理由、前提、優先度や適用範囲、検証方法・ゲート、関連要求、リビジョンと状態を付けます。

IDがあれば、ニーズから設計、リスク、テスト、証拠まで追跡できます。並べ替えで変わる文書の行番号を恒久IDにしません。

7. Sourceと理由は別の問いに答える

出所は、契約、承認済みニーズ、規格、リスクアセスメント、インターフェース合意、社内標準など、義務を生んだものです。理由は、なぜ必要かを説明します。理由は変更影響を考える助けになりますが、隠れた別要求を入れてはいけません。

たとえば、選択モデルと交換部品の一致確認を要求し、その理由を誤ったレシピの起動防止とします。センサーを削る提案が出たら、同じリスクを別の管理で抑える必要があると分かります。

8. 前提を見える化して閉じる

部品は清浄、圧力は範囲内、上流は一個だけ送る、オペレーターは正しいモデルを選ぶ、ネットワークは使える、といった前提が外れると要求は崩れます。重要な前提には所有者、確認方法、期限・ゲート、外れた時の影響、代替要求または設計処置を付けます。

9. 書いた時点で検証ルートを決める

「製作後、何を証拠に合格と言えるか」を問い、検査、解析、実演、試験のいずれかを割り当てます。設計レビュー、FAT、FIT、SAT、SIT、安全妥当性確認、量産試験などがゲートになります。方法が思いつかない要求は、曖昧、文脈不足、実現不能、または複数義務の混在かもしれません。

10. VerificationとValidationを混同しない

Verificationは、製品が書かれた要求を満たすかを確認します。Validationは、要求と解決策が実際の利用コンテキストでニーズを満たすかを確認します。時間基準を満たす段取り替えでも、オペレーターの能力、レイアウト、現実の生産に合わなければ妥当とは言えません。

11. 通常、異常、復旧を含める

通常シーケンスだけでなく、部品不足・逆向き、フィードバック欠落、ユーティリティ中断、途中停止、通信断、モデル不一致、非常停止、再起動を扱います。無効条件での動作、安全・復旧状態、アラームと診断、リセット責任、仕掛品を残すか破棄するかを要求に含めます。PLC実装時に初めて決めるのでは遅すぎます。

12. インターフェースは両側で理解する

「AとBを接続する」だけでは不十分です。境界、交換する信号・データ・材料・エネルギー、方向と所有、状態と順序、タイムアウト、エラーとリトライ、復旧と再同期、互換性、セキュリティ制約を定義します。詳細なタグやアドレスは管理された仕様に置きます。

13. サイクルと精度だけを書かない

長く使う機械には、保全性、使いやすさ、データ、セキュリティ、引渡しの要求も必要です。アクセス、交換、復旧、診断、予備品、権限、表示、データの時刻と保存、遠隔支援境界、バックアップ保護、教育、文書、未完了項目を定義します。要求がなければ、納期が厳しい時に「できればよい」へ格下げされます。

14. 安全要求をリスクアセスメントへ追跡する

「安全でPL dを達成する」だけでは、ハザード、安全機能、必要性能レベルの決定方法、モード、停止・再起動、妥当性確認ルートがありません。適用規格とリスクアセスメントから導出し、過去案件の値を理由なく流用しません。要求、設計、検証記録を相互に追跡します。

15. 曖昧な一文を要求セットへ変える

「モデル替えが速く、取り違えず、操作しやすい」を、まずニーズへ戻します。訓練済みオペレーターが技術者なしで対象モデルを切り替え、誤品を作らないことです。対象モデル、交換部品、レシピ、治具、初期・終了状態、役割、ユーティリティを文脈にします。

そのうえで、モデル選択、ハードウェア一致確認、正しいレシピ版のロード、不一致時の起動禁止、操作ガイド、合意した時間、イベント記録へ分割します。検査、実演、不一致試験、時間測定、FAT/SATの各ルートを割り当てます。

16. 変更前に要求をベースライン化する

レビュー後は、リビジョン、未解決課題と前提、承認者、トレーサビリティ、検証範囲を固定します。変更には申請、理由、設計・ソフトウェア・リスク・試験・文書・費用・日程への影響、承認、追跡表の更新、再試験または再妥当性確認が必要です。メールだけで要求を変えると、FATが古い基準を試すことになります。

17. 自動機要求レビューのチェックリスト

[ ] ニーズとステークホルダーが明確である。
[ ] HOWを早期に固定せず、WHATを記述している。
[ ] 各行に主な義務が一つある。
[ ] 固有IDと出所がある。
[ ] モード、モデル、材料、境界、運転条件が明確である。
[ ] 曖昧な言葉を観察可能な特性へ変えた。
[ ] 前提に所有者と閉鎖ゲートがある。
[ ] 受入れ基準と検証ルートがある。
[ ] 実現可能で矛盾しない。
[ ] ニーズ、設計、リスク、試験へ追跡できる。
[ ] 通常、異常、復旧を含む。
[ ] インターフェースの所有、時間、エラー、復旧が明確である。
[ ] 保全、診断、データ、セキュリティ、引渡しを含む。
[ ] 安全要求がリスクアセスメントへつながる。
[ ] ベースラインと変更手順が明確である。

まとめ

FATは、双方が「合格」の意味を初めて定義する場所ではありません。良い要求には出所とIDがあり、運転コンテキストで結果を明確にし、真の制約以外では解決策を固定せず、受入れ基準と証拠ルートを持たせ、ニーズ、設計、リスク、試験、証拠へ追跡し、変更管理の下でベースライン化します。

この連鎖があれば、FAT/SATは証拠を集める工程になります。「速い」「安定」「使いやすい」の意味を会議で交渉する必要がなくなります。

18. 要求レビューを設計チームの日常にする

要求レビューは、文書を一度承認して終わりではありません。設計レビュー、ソフトウェアの実装レビュー、FAT準備、SAT準備で同じIDと受入れ基準を再確認します。現場から新しい前提や例外が出たら、要求、リスク、テスト、教育、引渡しへの影響を一緒に更新します。

変更を急ぐ場合でも、最低限の記録を残します。誰が要求を解釈し、どの条件を採用し、どの証拠を取るかが分かれば、後でベースラインへ戻せます。短いレビューを繰り返すことが、FAT直前の大きな議論を防ぎます。

19. Traceabilityを実際に使う

トレーサビリティ表は監査用の飾りではありません。要求IDから設計項目、リスク管理、ソフトウェア変更、試験ケース、証拠、偏差、教育項目へリンクします。リンクが切れた時は、その要求が未実装なのか、証拠が保存されていないのか、変更の影響評価が足りないのかを判断できます。

小さくても一貫した表を維持すれば、担当者が変わっても同じ意味でFATを準備できます。

20. 仕様を現場の言葉へ翻訳する

オペレーター、保全、品質、ソフトウェア、顧客の代表をレビューへ入れます。各担当が同じ要求をどう解釈するかを確認し、専門用語、役割、表示、異常時の判断を明確にします。技術的に正しい文章でも、現場の行動へつながらなければ検証可能な要求とは言えません。

レビュー結果は、承認済みの用語集と例へ反映します。これにより、同じ「リセット」「再起動」「復旧」が文書ごとに違う意味になることを防げます。

この確認を早い段階で行うほど、設計者の意図と現場の操作の差を小さくできます。要求は書類を完成させるためではなく、同じ結果を作り、同じ証拠で合否を判断するための共通言語です。

共通言語をベースラインへ残します。判断と証拠を同じ表で追跡します。チーム全員で確認します。確実に記録します。

公開参考資料

ISO/IEC/IEEE 29148:2018 — Requirements engineering: https://www.iso.org/standard/72089.html
IEEE — IEEE/ISO/IEC 29148-2018: https://standards.ieee.org/ieee/802.1Q/6937/
NASA — How to Write a Good Requirement: https://www.nasa.gov/reference/appendix-c-how-to-write-a-good-requirement/
IEC 62381:2024 — FAT, FIT, SAT and SIT: https://webstore.iec.ch/en/publication/67572

MINATAの技術記事をすべて見る