仕様は、顧客のニーズをシステム設計・製造する上での、顧客とシステムインテグレータが合意した重要条件や取り決めとなるので、抜け漏れないよう数値や共通の言葉で記入します。仕様を作る上で、顧客との打合せ根拠や証拠を書類で残しておくことも必要です。
仕様書は顧客が作成してもシステムインテグレータが作成しても構いませんが、一般的にはシステムを熟知しているシステムインテグレータが作成します。
仕様は顧客とシステムインテグレータ間の責任や費用を明確にする重要なやり取りとなります。顧客の要求事項や考え方、双方のイメージを具体的に、かつ3次元CADやシミュレータを用いてビジュアル化し、可能な限り詳細合意を得る事が重要です。特に使用機器、購入品メーカや型式は1社指定せず、同等品や同機能品で複数のものを選定できるようにしておくことで、コストや納期の比較や競争ができ、システムインテグレートする上で大変有利になります。
最終の姿を詳細に記述し、曖昧な表現は避けるようにします。仕様書において、顧客のシステム導入先の現地調査が必要な場合には、調査できること、できないことを明確にしておく必要があります。
また、仕様は要件の取り決めであるため、設計段階、製造段階、最終段階で確実に仕様がフォローされたものになっているか確認を行う必要があります。仕様の抜け漏れがなく、確実なモノづくりの提供は顧客の信頼を得る事にもつながります。
見積前提条件として、見積仕様書を作成します。
■見積仕様書
推奨される記載項目は下記の通りです。
〈全体〉
● システム概要
● 導入の目的・背景・経緯
● システムイメージ
● 設置レイアウト
● 処理対象（ワーク概要）
● 処理プロセス
● 顧客要求事項及び実現方法
● 想定運用
● 作業工程と役割分担
〈装置〉
● 基本仕様
● ユーティリティ仕様及び設置環境
● 製品サイズ・重量・材質
● タクトタイム（サイクルタイム）
● 装置塗装色（塗装箇所・塗装色番号・塗装方法）
● 装置各部の機能及び構造
● 画像処理仕様
● 操作方法
〈その他〉
● 支給品・貸与品
● 安全衛生
● プロジェクト日程
● 納品物件（完成図書）
● 検収条件
● 保証
※準備フェーズでは、概要レベルで見積仕様書を作成します。これを基に設計フェーズにて、詳細化した納入仕様書を作成します。
※また、製作者向けに、見積仕様書を基に、設計条件の他、工事条件、装置仕様条件などを記述した製作仕様書を作成します。
設備仕様書の内訳として、次の各仕様書を作成します。
■機械設計仕様書
機械設計（工程・構造など）の機器・方式などを定義します。また、予備実験（要素技術検証）を行った際には、その結果も含みます。
■図面一式
全体レイアウト図を始め、組立図などの設計図面一式を「承認図」として顧客からの承認を得ます。
● 全体レイアウト図
→全体組立図と顧客側の周辺に配置する台車、制御盤、他工程装 置、通路、付帯コンベアなどを記入したシステム全体図
● 全体組立図
→各ユニットの部分組立図全てを組み合わせた、装置全体の組立図
● 部分組立図
→各ユニットにフォーカスした組立図
■電気設計仕様書
電気設計における基本的な項目を定義します。
● システム全体配置図
● 電気系統図・信号系統図
● 装置概観図
● 配置図
● 部品表
● 設計根拠
● 制御盤・操作盤などの外形寸法図及び配置図
● 回路図（電源系統図、信号系統図、ネットワーク系統図含む）
● I/O マップ（DIO、CC-Link など、物理的接続が発生するもの）
● 配線仕様
■制御設計仕様書
制御設計における基本的な項目を定義します。
● 処理内容
● 動作フローチャート
● タイミングチャート
● PC（画面一覧及び画面遷移、画面構成、プログラム仕様）
● タッチパネル（画面一覧及び画面遷移、画面構成、プログラム仕様）
● ハンディターミナル（画面一覧及び画面遷移、画面構成、プログラム仕様）
● PLC（グローバルリレー、制御内容及びプログラム一覧、プログラム仕様）
● ロボット（制御内容及びプログラム一覧、ティーチングポイント、プログラム仕様）
■画像処理仕様書
画像処理（検査・計測など）の機器・方式などを定義します。また、予備実験（要素技術検証）を行った際には、その結果も含みます。
■部品表
装置の詳細設計が完了し、対象装置を構成する外販購入部品及び、加工製造品について、それぞれの部品の一覧を記載したリストです。装置組立に当たり、本リストを基に外販部品、加工部品を手配します。また、その入荷状況の管理にも使用します。
■部品図
各部分組立図で、機械加工が必要となる個別図面。
既に設計プロセス以降の実作業に入ったタイミングでは、安易な変更要求は基本的には受け入れるべきではありません。しかし変更の理由から、どうしても対応せざるを得ない場合もあり、その場合には適切な変更管理を行い、運用の実現性及び、プロジェクト管理への影響を最小限に抑える努力をします。
また、変更対応はたとえ簡単な対応であっても現場レベルでは行なうべきではありません。安易な対応が、他機能との連携において食い違いが発生し、更にドキュメントとの不整合の原因となる可能性があります。必ずプロジェクトとして変更管理を行い、関係者合意のもと変更対応を行ないましょう。
MIRAI-LABでは構想設計のWEB相談を受け付けております。自動化でお悩みの方は、初回無料ですので、是非お問合せ下さい。
