仕様（技術基準）

仕様とは、材料、設計、製品、またはサービスが満たすべき一連の文書化された要件を指すことが多い。^{[1]仕様は、多くの場合、}技術標準の一種である。

技術仕様またはエンジニアリング仕様 (仕様) にはさまざまな種類があり、その用語はさまざまな技術的コンテキストで異なる意味で使用されます。仕様は多くの場合、特定の文書やその中の特定の情報を指します。仕様という言葉は、広く「明示的にまたは詳細に述べる」または「具体的に述べる」と定義されています。

要件仕様とは、特定の材料、設計、製品、サービスなどが満たすべき文書化された要件、または文書化された要件のセットです。 ^{[1]多くの分野で、}エンジニアリング設計や製品開発プロセスの初期段階でよく使用されます。

機能仕様は要件仕様の一種であり、機能ブロック図を示す場合があります。^{[引用が必要]}

設計または製品仕様は、要件仕様のソリューションの特徴を説明し、設計されたソリューションまたは最終的に製造されたソリューションのいずれかを指します。これは、製造/生産をガイドするためによく使用されます。仕様という用語は、データシート (またはスペックシート) に関連して使用される場合があり、混乱を招く可能性があります。データシートは、アイテムまたは製品の技術的特性を説明し、多くの場合、人々が製品を選択または使用できるようにメーカーによって公開されます。データシートは、製造方法を通知するという意味での技術仕様ではありません。

「稼働中」または「維持中」仕様は、摩耗やメンテナンス（構成の変更）の影響を含め、何年も運用した後のシステムまたはオブジェクトの状態を指定します。

仕様は、公共部門と民間部門の両方において、さまざまな種類の組織によって開発される可能性のある技術標準の一種です。組織の種類の例としては、企業、コンソーシアム（企業の小グループ）、業界団体（業界全体の企業グループ）、国家政府（さまざまな公的機関、規制機関、国立研究所や研究所を含む）、専門協会（協会）、 ISOなどの目的別標準化団体、ベンダー中立で開発された一般的な要件などがあります。ある組織が別の組織の標準を参照（参照、呼び出し、引用）することはよくあります。自主的な標準は、政府またはビジネス契約によって採用された場合は必須になることがあります。

エンジニアリング、製造、ビジネスにおいては、材料、製品、サービスの供給者、購入者、ユーザーがすべての要件を理解し、合意することが重要です。 ^[2]

仕様とは、契約書や調達文書で参照されることが多い標準、または合意された一連の要件 (単数形で使用される場合が多い)を指します。いずれの場合も、仕様は特定の要件に関する必要な詳細を提供します。

仕様の標準は、政府機関、標準化団体（SAE、AWS、NIST、ASTM、ISO / IEC、CEN / CENELEC、DoDなど）、業界団体、企業などによって提供される場合があります。1994年6月29日にウィリアム・J・ペリー米国防長官が発行した覚書では、「パフォーマンスと商用の仕様と標準のより広範な使用」への移行が導入されると発表され、ペリーは当時これを「[国防総省]が取るべき最も重要な措置の1つ」と見なしていました。^[3]仕様には次の英国規格が適用されます。

• BS 7373-1:2001 仕様書作成ガイド^[4]
• BS 7373-2:2001 製品仕様。製品仕様の基準を特定し、製品の適合性を宣言するためのガイド^[5]
• BS 7373-3:2005、製品仕様。サービス提供の仕様を決定するための基準のガイド^[6]

設計/製品仕様は、必ずしも製品があらゆる状況で正しい、または有用であることを証明するものではありません。アイテムは仕様に準拠していることが検証されたり、仕様番号が刻印されたりする場合がありますが、これだけでは、アイテムが他の検証されていない用途に適していることを示すものではありません。アイテムを使用する人 (エンジニア、労働組合など) やアイテムを指定する人 (建築基準法、政府、業界など) には、利用可能な仕様の選択を検討し、正しいものを指定し、準拠を強制し、アイテムを正しく使用する責任があります。適合性の検証は必要です。

欧州連合および英国の公共部門の調達規則では、購買組織の要件を特定するために、差別のない技術仕様書の使用が義務付けられている。公共事業契約に関する規則では、1971年から「差別的な効果を持つ技術仕様書」が禁止されていたが、この原則は、1976年に採択された当時の欧州共同体の公共供給契約の授与手続きを調整する指令77/62/EECによって、公共供給契約にも拡大された。^[7]一部の組織では、スタッフやパートナー向けに仕様書作成のガイダンスを提供している。^{[8] [9]}公共部門の仕様書では、購入する商品やサービスに求められる特定の属性を特定するだけでなく、組織の現在の企業目標や優先事項についても言及されることがある。^{[8] : 3}

適切な仕様書の作成やフォーマット作成に役立つガイドや標準操作手順書が利用できる場合もあります。 ^{[10] [11] [12]} 仕様書には以下の内容が含まれる場合があります。

• 仕様の説明的なタイトル、番号、識別子など
• 最終有効改訂日および改訂指定日
• 文書の著作権、所有権、出所を示すロゴまたは商標^[13]
• 文書が長い場合は目次（TOC）
• 仕様、更新、および逸脱に関する質問を担当する個人、オフィス、または機関。
• 仕様の意義、範囲、重要性、およびその使用目的。
• 仕様の意味を明確にするための用語、定義、略語^{[14] [15]}
• 指定されたすべての特性を測定するための試験方法
• 材料要件: 物理的、機械的、電気的、化学的など。目標と許容範囲。
• 受け入れテスト（パフォーマンス テスト要件を含む）。ターゲットと許容範囲。
• 図面、写真、または技術イラスト
• 職人技
• 認定資格が必要です。
• 安全に関する考慮事項と要件
• セキュリティに関する考慮事項と要件 (適切な場合: 例: 政府機関や軍事機関、情報技術企業などに提供される製品やサービスの場合)
• 環境に関する考慮事項と要件
• 品質管理要件、受入サンプル、検査、受入基準、または、品質管理システムが運用されている場合は、仕様の範囲内の製品/サービスの提供に関わるビジネスプロセスを規制するために定められた品質保証要件。
• 仕様の施行を担当する個人、オフィス、または機関（仕様に定められた要件への準拠を確認するための監査の手配および実行を含む場合があります）。
• 完了および配送条件（多くの場合、標準化されたINCOTERMSを参照します）。
• 拒否、再検査、再審理、是正措置に関する規定
• 文書の追跡可能性と明確性を満たすために内容の指示が必要となる可能性のある参考文献と引用文献^{[15] [16] [17]}
• 必要に応じて承認の署名。 ^[18]サインオフ/バイオフイベントには特別な手順が適用される場合があります。
• 文書が社内で回覧される場合、時系列の開発、改訂、完了を要約した変更記録^[19]
• 詳細を拡張したり、説明を追加したり、選択肢を提示したりする付録と付録。 ^[19]

北米の仕様は、建築およびインフラストラクチャ プロジェクトの建設図面に付随し、図面を管理する契約文書の一部です。仕様では、コード引用と公開された標準を使用して、建築材料の品質と性能について説明します。一方、図面または建物情報モデル(BIM) では、材料の数量と場所を示します。名前と番号のガイド マスター ドキュメントは、MasterFormatの最新版です。これは、米国に拠点を置く 2 つの専門組織である Construction Specifications Canada とConstruction Specifications Instituteが共同で後援し、2 年ごとに更新される合意文書です。

文書と図面に食い違いがある場合、「仕様が図面に優先する」と考える傾向がありますが、実際の意図は、オーナーと請負業者の間の契約で明確にする必要があります。標準の AIA (米国建築家協会) と EJCDC (エンジニアリング共同契約文書委員会) では、図面と仕様は補完的であり、一緒になって完全な施設に必要な情報を提供すると規定されています。海軍施設司令部 (NAVFAC) などの多くの公的機関は、仕様が図面に優先すると述べています。これは、紛争が発生した場合、陪審員 (または調停者) にとって、図面よりも言葉の方が解釈しやすいという考えに基づいています。

建設仕様の標準的なリストは、建設に含まれる作業タイプと作業結果の広範なカテゴリである50 の部門に分類されます。部門はセクションに細分化されており、各セクションは建設作業の特定の材料タイプ (コンクリート) または作業成果物 (スチール製ドア) を扱っています。特定の材料は、作業結果に応じて、複数の場所でカバーされる場合があります。たとえば、ステンレス鋼は、フラッシングやシート メタルに使用されるシート材料として部門 07 でカバーされる場合があります。また、手すりなどの完成品の一部である場合は部門 05 でカバーされる場合があり、建物ハードウェアのコンポーネントである場合は部門 08 でカバーされる場合があります。仕様部門の元のリストは、外部から内部への建設の時系列に基づいており、このロジックは、新しい材料やシステムが建設プロセスに導入されるにつれて、今でもある程度従われています。

各セクションは、「一般」、「製品」、「実行」の 3 つの部分に分かれています。MasterFormat および SectionFormat ^[20]システムは、住宅、商業、土木、産業建設にうまく適用できます。多くの建築家は、かなり分厚い商業スタイルの仕様はほとんどの住宅プロジェクトには長すぎると感じており、そのため、より簡略化された独自の仕様を作成するか、ArCHspec (住宅プロジェクト用に特別に作成されたもの) を使用します。マスター仕様システムは、Arcom、Visispec、BSD、Spectext など、複数のベンダーから入手できます。これらのシステムは、米国全体で言語を標準化するために作成され、通常はサブスクリプションベースです。

仕様は、「パフォーマンス ベース」または「規範的」のいずれかになります。「規範的」では、仕様者は完成した作業で達成しなければならないパフォーマンスのみを記述します。「規範的」では、仕様者はアイテムに適用される製造基準などの特定の基準を記述します。「独自仕様」では、仕様者は各作業範囲で許容される特定の製品、ベンダー、さらには請負業者を示します。さらに、仕様は、特定の製品リストで「クローズド」にすることも、「オープン」では建設業者による代替品を許可することもできます。ほとんどの建設仕様は、パフォーマンス ベースと独自仕様の組み合わせで、許容されるメーカーと製品を指定しながら、満たさなければならない特定の基準と設計基準も指定します。

北米の仕様書は通常、作業の概要に限定されていますが、欧州の仕様書や土木工事では、部品表のように、平方メートルで構築される乾式壁の面積など、実際の作業数量を含めることができます。このタイプの仕様書は、仕様書作成者と積算士の共同作業です。このアプローチは、各入札者が図面と仕様書の両方に基づいて積算を行う北米では珍しいものです。ヨーロッパ大陸の多くの国では、米国で「仕様」と呼ばれる内容は、建築基準法または地方自治体の基準でカバーされています。米国の土木工事やインフラストラクチャ工事には、実行される作業の数量の内訳も含まれることがよくあります。

仕様書は通常、建築士事務所によって発行されますが、仕様書の作成自体は、建築家とさまざまなエンジニア、または専門の仕様書作成者によって行われます。仕様書の作成は、多くの場合、独立した専門職であり、建設仕様協会から「認定建設仕様書作成者」(CCS) などの専門資格や、建設仕様カナダから登録仕様書作成者 (RSW) ^{[21]などの専門資格が取得できます。仕様書作成者は}、下請け業者などの独立した組織である場合もあれば、建築家、エンジニア、または建設管理会社の従業員である場合もあります。仕様書作成者は、建設プロジェクトで自社製品を指定してもらうことを望んでいる建築資材メーカーと頻繁に会い、請負業者が提案書の見積もりに自社製品を含められるようにします。

2015 年 2 月、ArCHspec が稼働を開始しました。ArCH (Architects Creating Homes) は、住宅建築の改善を目的とする全米規模の建築家専門団体です。ArCHspec は、SFR (一戸建て住宅) 建築プロジェクトを設計する際に、資格を持つ建築家が使用するために特別に作成されました。より商業的な CSI/CSC (50 以上の区分の商業仕様) とは異なり、ArCHspec は、より簡潔な従来の 16 区分に加えて、区分 0 (範囲と入札フォーム) と区分 17 (低電圧) を使用します。これまで、多くの建築家が住宅設計の仕様を提供していませんでした。これが、ArCHspec が作成された理由の 1 つであり、住宅プロジェクト用のよりコンパクトな仕様で業界の空白を埋めることを目的としています。住宅での使用に適した、より短い形式の仕様書も Arcom から入手できます。この仕様書は、2004 年から米国とカナダの両方で採用されている 50 区分形式に準拠しています。16 区分形式はもはや標準とはみなされておらず、CSI や CSC、サブスクリプション マスター仕様サービス、データ リポジトリ、製品リード システム、および政府機関の大部分ではサポートされていません。

連邦政府とその機関の調達を規定する米国の連邦調達規則では、図面と仕様書のコピーを建設現場に保管しなければならないと規定されている。^[22]

エジプトでは、仕様は契約書類の一部となっています。住宅建築国立研究センター (HBRC) は、建設仕様と規則の開発を担当しています。HBRC は、土工、左官工事など の建築活動を扱った 15 冊以上の書籍を出版しています。

英国における仕様書は、建物の建設に付随し、その建設を管理する契約文書の一部です。これらは、建築家、建築技術者、構造エンジニア、造園家、ビル設備エンジニアなどの建設専門家によって作成されます。これらは、以前のプロジェクト仕様書、社内文書、またはNational Building Specifications (NBS) などのマスター仕様書から作成されます。National Building Specifications は、英国王立建築家協会(RIBA) が商業グループ RIBA Enterprises (RIBAe) を通じて所有しています。NBS マスター仕様書は、幅広く包括的な内容を提供し、仕様作成者がプロジェクトのニーズに合わせて内容をカスタマイズし、最新の状態に保つことを可能にするソフトウェア機能を使用して配信されます。

英国のプロジェクト仕様の種類は、規範的とパフォーマンスの 2 つの主なカテゴリに分類されます。規範的仕様では、必要なものの一般的な説明または独自の説明を使用して要件を定義しますが、パフォーマンス仕様では、コンポーネントの特性ではなく結果に重点が置かれます。

仕様はビルディング インフォメーション モデリングの不可欠な部分であり、非幾何学的要件をカバーします。

医薬品は通常、さまざまな薬局方によってテストされ、認定されます。現在存在する医薬品規格には次のものがあります。

• 英国薬局方
• 欧州薬局方
• 日本薬局方
• 国際薬局方
• 米国薬局方

上記の基準に該当しない医薬品については、他国の薬局方、工業規格、または標準化された処方集などから評価することができます。

• 英国小児用国家処方集
• 英国国立処方集
• 国家処方集

食品製造業でも同様のアプローチが採用されており、その中でもコーデックス委員会が最高基準を定め、続いて地域基準と国家基準が定められている。^[23]

ISOによる食品・医薬品規格の適用範囲は現在のところあまり実りがなく、地域や国の憲法による厳しい制約のため緊急の議題としてはまだ提示されていない。^{[24] [25]}

仕様やその他の基準は、上で述べたように外部から課されることもありますが、内部の製造および品質仕様も課されることがあります。これらは食品や医薬品だけでなく、加工機械、品質プロセス、包装、物流（コールドチェーン）などにも存在し、ISO 14134やISO 15609に例示されています。^{[26] [27]}

仕様の明示的な記述の逆は、仕様外の観察に対処するプロセスです。米国食品医薬品局は、まさにこの点に対処する拘束力のない勧告を発表しました。^[28]

現在、食品および食品製品に関する情報や規制の多くは、自動化された情報処理、保管、伝送の方法や技術を適用することが難しい形式のままです。

食品および食品製品に関する情報を処理、保存、転送できるデータ システムが効果的かつ効率的に動作するには、食品および食品製品に関するデータの表現に関する正式な仕様が必要です。

デジタルコンピューティングシステムでの使用に必要かつ十分な明瞭性と精度を備えた食品および医薬品データの正式な仕様の開発が、いくつかの政府機関および標準化団体から始まりつつある。米国食品医薬品局は、医薬品メーカーが医薬品ラベルの情報を電子的に提出するために義務付けられている「構造化製品ラベル」の仕様を発表した。^{[29]最近、ISOは、ISO 11238の発行を通じて、食品および医薬品の}規格と規制物質に関するデータの正式な仕様の分野で一定の進歩を遂げた。 ^[30]

多くの状況、特にソフトウェアでは、相互運用性の問題など、互換性の欠如によるエラーを回避するために仕様が必要です。

たとえば、2 つのアプリケーションが Unicode データを共有しているが、異なる正規形を使用したり、互換性のない方法で誤って使用したり、相互運用性の仕様の最小セットを共有していない場合は、エラーやデータ損失が発生する可能性があります。たとえば、Mac OS X には、分解文字のみを優先または必要とするコンポーネントが多数あります (したがって、UTF-8 でエンコードされた分解のみの Unicode は「UTF8-MAC」とも呼ばれます)。特定の例では、合成文字を処理する OS X のエラーと、ファイル名をコピーするときに分解文字を合成文字に置き換えるsambaファイルおよびプリンタ共有ソフトウェアの組み合わせにより、混乱を招き、データが破壊される相互運用性の問題が発生しました。^{[31] [32]}

アプリケーションは、入力コード ポイントを保持し、内部使用のためにアプリケーションの推奨正規形にのみ正規化することで、このようなエラーを回避できます。

このようなエラーは、バイナリ比較の前に両方の文字列を正規化するアルゴリズムを使用することで回避することもできます。

しかし、さまざまなファイル システム ドライバー、オペレーティング システム、ネットワーク プロトコル、および何千ものソフトウェア パッケージ間で相互運用可能であることが期待されるソフトウェア間の共通仕様の最小セットが不足しているため、ファイル名のエンコーディングの非互換性によるエラーは常に存在していました。

形式仕様は、実装の開発に使用できるソフトウェアまたはハードウェアの数学的記述です。これは、システムが何をすべきかを記述するものであり、必ずしもどのようにすべきかを記述するものではありません。このような仕様があれば、形式検証技術を使用して、候補システム設計がその仕様に関して正しいことを証明できます。これには、設計の実装に大規模な投資を行う前に、誤った候補システム設計を修正できるという利点があります。別のアプローチは、証明可能な正確性の改善手順を使用して、仕様を設計に変換し、最終的には構造上正しい実際の実装に変換することです。

(ハードウェア、ソフトウェア、またはエンタープライズ) システム開発において、アーキテクチャ仕様とは、そのシステムの構造、動作、およびその他のビューを記述したドキュメントのセットです。

プログラム仕様とは、コンピュータ プログラムに期待される動作の定義です。非公式な仕様の場合は開発者の視点からユーザー マニュアルとして考えることができ、公式な仕様の場合は数学的またはプログラム的な用語で定義された明確な意味を持ちます。実際には、多くの成功した仕様は、すでに十分に開発されたアプリケーションを理解して微調整するために作成されますが、安全性が重要な ソフトウェア システムは、アプリケーション開発の前に慎重に指定されることがよくあります。仕様は、安定性を維持する必要がある外部インターフェイスにとって最も重要です。

ソフトウェア開発において、機能仕様（機能仕様書、スペック、機能仕様ドキュメント (FSD)とも呼ばれる）は、コンピュータ プログラムまたは大規模なソフトウェア システムの動作を記述するドキュメントのセットです。ドキュメントでは通常、ソフトウェアシステムに提供できるさまざまな入力と、システムがそれらの入力にどのように応答するかを記述します。

Webサービスの仕様は、多くの場合、品質管理システムの傘下にあります。^[33]

これらのタイプの文書は、特定の文書がどのように書かれるべきかを定義しており、文書の命名、バージョン、レイアウト、参照、構造化、外観、言語、著作権、階層、フォーマットなどのシステムが含まれますが、これらに限定されません。 ^{[34] [35]}多くの場合、この種の仕様は指定されたテンプレートによって補完されます。^{[36] [37] [38]}

• Pyzdek, T、「品質エンジニアリング ハンドブック」、2003 年、ISBN 0-8247-4614-7 
• ゴッドフリー、AB、「ジュランの品質ハンドブック」、1999 年、ISBN 007034003X 
• 「化学およびプロセス産業向け仕様」、1996 年、ASQ Quality Press、ISBN 0-87389-351-4 
• ASTM E29-06b 試験データ内の有効数字を使用して仕様への適合性を判断するための標準的方法
• 化学情報とモデリングジャーナル
• ジャーナル・オブ・ドキュメンテーション、エメラルド・グループ・パブリッシング、ISSN  0022-0418