一方において、構造設備においては機能仕様書を作成する機会はほとんどない。
その理由は単純である。
ITアプリケーションには、数多くの機能が存在する。
一方で、構造設備は、1プロセス：1機能：1システムである。
例えば、「打錠プロセス」は「打錠機能」のみで「打錠機」によって実行される。
また「造粒プロセス」は「造粒機能」のみで「造粒機」によって実行される。
滅菌プロセスも、充填プロセスなどもほぼ同様である。
1システム＝1機能であるため機能仕様書の作成は必要ないのである。
2010年10月21日に発出された「医薬品・医薬部外品製造販売業者等におけるコンピュータ化システム適正管理ガイドライン」において要求仕様書や設計仕様書とは異なり、機能仕様書の記載内容（コンテンツ）に関する要求事項が記載されていない。
筆者は本ガイドラインが発出される前のパブリックコメントにおいて、機能仕様書に関してもコンテンツ要求を明確にするべきであると主張した。
しかしながら、厚労省 監視指導麻薬対策課からの回答は現状で問題ないとの見解であった。
そもそも本ガイドラインを作成したメンバーは、構造設備の専門家ばかりである。したがって、機能仕様書には馴染みがなかったのではないかと推察する。
ガイドラインでは、機能仕様書に関する要求事項が以下のように示されている。
４．開発業務
4.4 機能仕様に関する文書の作成
開発責任者は、供給者に要求仕様書に記載された要件に対応した具体的なコンピュータ化システムの機能と性能を記載した機能仕様に関する文書（以下「機能仕様書」という。）を作成させ、承認するものとする。
つまり、機能仕様書は供給者（サプライヤ）に作成させるが、そのレビュと承認はユーザ企業（製薬企業、医療機器企業）の責任である。
したがって、機能仕様書の表紙には少なくとも5名の署名が入ることとなる。
供給者側：作成者、レビューア、承認者
ユーザ企業側：レビューア、承認者
機能仕様書は、URSに記載した要求事項をコンピュータ化システム設計に対する要求事項として十分なレベルまで定義するものである。
機能仕様書は、承認されたURSをもとに作成しなければならない。
通常、機能仕様書は通常、要件定義フェーズにおいてユーザとサプライヤが打合せる事によって作成する。
つまりユーザがURSを説明し、サプライヤがその実現方法について検討する。
いわば機能仕様書は、ユーザとサプライヤとの合意書であるといえる。
つまり多くの仕様書の中で、機能仕様書がユーザも供給者も理解できる唯一の文書なのである。したがって非常に大事な文書であるともいえる。
リリース後の変更などは、機能仕様書をもとに検討するのが良いだろう。また変更回数も機能仕様書に対するものとしてカウントすることが適切である。
機能仕様書執筆時に、URSと機能仕様書のトレーサビリティマトリックスを作成することによって、ユーザの要求事項がもれなく機能仕様書において定義されたことを保証すること。
]]>
Comment