読者です 読者をやめる 読者になる 読者になる

suzukiyou blog

建築設計とかpythonとかその辺をとりあえずする

文書マネジメントに関する件

あけましておめでとうございます。
技術文書マネジメントに関するいろいろな技術例を見ていきます。
主にJIS Z 8245-1を見ていくこととします。

問題点の確認

文書を大量に扱うので、書籍・pdf・jpg・dxf等の様々なデータ(紙・電子データ混用)を適切に記録していかないとはかなくなります。
今まで超整理法っていうか「野口式押しだしファイリング」で、記録日をファイル名(およびプロジェクト名)をファイル名として共用ファイルに適当にぶち込んでおいたのですが、年末転属があり、引き継ぎをする羽目になってかなり死にました。死にたくないですね?

超整理法はスタック式管理のため、長期保存に向かない。例えばコンパイラ本には「統計的に、生存期間の短い変数はとことん短く、長い変数はとことん長い」と書いてあり、長い変数は参照を用いてヒープ領域に持っていく、ということがおこる。文書管理はとかく人力でやるので、どれが生存期間が長い変数なのだかよくわからんし(というか全部長い気がする)ヒープに持っていくその度ごとにアドレスを設定する(適切なフォルダに配置する)の、面倒くさい!やりたくない!

かと言ってgit的なリポジトリの運営は難しい。確かにプルしてマージ、コミットしてプッシュするのは有効、でもそれは「文書やコードの構造を理解していないと闇雲にファイルを追加してしまう」「文書の構造設計が完了している段階でなければ実質的には運用できない」という問題がある。やはり超整理法は必要です。

超整理法的な「スタック」文書管理とgit的な「バージョンによる」文書管理を同時に運用しなければなりません。しかしそれらは別物ですから、その間を埋めるなんらかの方法が必要です。

予想と適用する技術領域

超整理法

スタックの方向では、基本的に超整理法を行います。それぐらいだったら俺でも人力でも出来るという実績があるからです。
「超」整理法1 押出しファイリング (中公文庫)
「超」整理法―情報検索と発想の新システム (中公新書)
などでいいでしょう。
具体的には、スタック用フォルダ"%desktop%\stack\"をデスクトップにでも作って、ファイルには"YYMMDD_projectname_contents.sufix"という名前をつけてぶち込む。以上。

IT系バージョン管理

俺が既に把握している技術としてのバージョン管理は、git的なものと、.NET assembly的なものがあり、それぞれで思想が異なる。
俺の認識ではgitはテキストベースのファイルをdiffでどうにかするものだという認識があります。git上の管理においてはバージョン番号(ex .NET assembly例で、major.minor.build.revision)が明確に表現されていない、という認識がある(本当かどうかはわからない。多分うまいことやってるところもあるでしょう)。
.NET assemblyのような形式で、実際の物理ファイルとは別個にメタデータをもつという方が、文書のライフサイクルを考える上では有利という気がしますね。管理ファイルがテキストファイルに限定されないという点、発行の概念がある点などが有利、と思われる。その他.NET Frameworkでの思想には見るべきとところが多い。IL(中間言語)やメタデータの分離、メタデータの記述、公開鍵/秘密鍵によるセキュリティ等はそのまま文書管理においても使えそうな雰囲気がある。

参考

標準組織系文書管理

別の思想としてISO9001系の品質管理マネジメントシステムがあり、その辺なんかあるんじゃねーのと思いながらこの度よくよく調べると一連の規格があり、参照できそうな雰囲気がある。
参考
日本規格協会 標準化教育プログラム 電気電子10 技術文書 -文書作成・マネジメント-PDF

参照するのは、以下の規格です。
JIS Q/Z系

JIS C系

ISO 10303[STEP]

もともとIEC(国際電気標準会議)で文書マネジメントの考え方が出てきたらしく、歴史的な経緯からJISにも電気系が多い(というかIECの翻訳)のだが、オブジェクト指向に関してはどの分野でも適用可能と思われるので参考となる。一方電気系の出自の都合、配線だかブレーカだかの例が多いのは、まあ仕方ないっていうか……

文書分類ということで言えばZ8245-1とC0452-2でオブジェクト指向的に分類していけ、またC0454に従ってツリー状に配置していけ、というのが世の考えらしい。またライフサイクルについて言及があるのはZ8245-1である。メタデータ(索引的なもの)に言及があるのはZ8245-1だが、保存・台帳作成に当たってのダブリンコアメタデータについての言及がZ6017の附属書Cにある。

図書館系書籍管理

あとはこう、文書あるいは書籍、管理対象に対する目録作成・帳票作成のあたりでは、図書館系でやってることが参考になるかもしれない。ISBNとかから書籍データを取ってくる、とかいうような既知の技術があります。思ったよりいろいろな書籍データがwebで供給されているのだが、ダブリンコアメタデータと呼ばれるものを利用しているらしい。データ形式が規定されているので、これを参考にしてフィールドを作れそうな気がするから、リンクを貼る。

歴史的なところは置いておくとして、いろいろな組織がいろいろなダブリンコアメタデータ形式を作成しているというのが実体らしい。
日本では国立国会図書館のDC拡張記法DCNDLがあり、例えばISBNをキーとしてURLクエリでAPIを叩けば必要なデータが取得できる。
技術としてはXMLによるRDF記述を行っており、つまりXMLパーサで処理できるようだ。

検討事項

技術文書マネジメントシステムを構想していく前に、検討すべき事項が何か調べていく。

  • 文書の分類
  • 文書の構造化
  • 文書のライフサイクル
  • 文書のバージョン
  • 文書メタデータ

分類

標準組織型分類、JIS系に文書種類分類コード(DCC)がある。これはビジネス文書の分類が念頭にあるのでこれを見ていく。一応、図書館系の図書分類法というのがあるが、一般書籍の分類を念頭に書かれているので、ビジネス文書の分類としては不適です。国際的には国際十進分類法UDC、デューイ十進分類DDC、国内的には日本十進分類法NDC、国立国会図書館分類法NDLCがメジャーらしい。(図書分類法 - Wikipedia)

DCCの書式はJIS C 0451で諸々書かれている。
&(A1)(A2)(A3)(文書種類計数番号)でそれぞれ

  • A1:技術分野の表示
  • A2:文書種類主分類の表示
  • A3:主分類に大して個別に定義される副分類の表示

であり、後続文字の追加については自由であるとされている。

規格の趣旨としては4.1文書種類の分類一般で以下のようにあるので理解しておくべき。

文書種類の名称は、様々な表現が使用され、それらのうちの多数は標準化されていない。しかし、特定の使用者グループの間ではよく知られていることがある。さらに、文書種類が同じでも、異なった使用者グループでは異なった名称を用いている場合もある。そのため、文書種類の名称を使用することは、異なる団体・組織間のコミュニケーションには不適切である。
団体・組織間で授受される文書の共通の理解を得るため、文書種類分類コード(DCC)をこの企画で規定した。このコードは、文書種類の名称が定義又は規格化されていないことに関係がなく、情報の内容を理解する基準となる

つまり、よそ者とのコミュニケーション時にDCCを参照しなさい、規格で決めているから意味がわかるでしょう、と言った感じのものだ。自分が管理するためにDCCをつけるのではないですよ、ということです。実運用段階で直で使うにはレベルが高すぎてわけわかんなくなりそう。例えば異なるDCCをつけてしまうという懸念がある。しかしISO9001のような文書マネジメントシステムとしてDCC分類を行った場合には分類の効果があると思われ、文書マネジメントシステムで規定するべき事柄であるという印象がある。

附属書Aに(規定)分類記号が定義されていてA1については下のようになる。
(注:掲載する表は手で写しているのでなるべくリンク先を参照されたい)

DCC A1 技術分野
A 全体管理
B 全体技術
C 建設エンジニアリング
E 電気技術(制御・情報・通信技術を含む)
M 機械エンジニアリング(通常プロセスエンジニアリングを含む)
P プロセスエンジニアリング(Mとの区別が必要な場合)

A2についてはおおよそ以下のようになる。

DCC A2 概要
A 文書化記述文書
B 管理文書
C 契約および非技術文書
D 一般技術情報文書
Q 品質マネジメント文書及び安全性記述文書
T 幾何学的正常記述文書
E 技術要求及び寸法文書
F 機能記述文書
L 位置文書
M 接続記述文書
P 構成品リスト
W 運転手順及び記録

で合わせて書くと下のようになる。

DCC A2 DCC A3 文書種類分類 情報の内容 文書種類の例
A A 総括文書 内容及び関連について一般文書に優先する管理文書 表紙・目次
A B 文書に関する一覧表 文書の内容を示す文書 文書一覧表・索引
B A 登録者 ビジネスパートナー・顧客・コンサル等の情報 ベンダーリスト・供給者一覧表・配布物一覧表
B B 報告書 管理に関する情報など 打合報告・状況報告
B C 往復書簡 書簡のようなもの 書簡
B D プロジェクト管理文書 アクティビティーに関する情報 文書交換リスト・作業時間計算表
B E 資源計画文書 時間・要員・材料の計画情報等 工程表・資源投入図表
B F 発送・保管・輸送文書 商品の発送に必要な情報 発送仕様書・発送リスト
B G 現地計画・現地組織文書 現地の構成情報等 要員の現地要件
B H 変更に係る文書 変更に関する文書 変更通知書・変更要求書
B S 安全性文書 安全計画等 消火防護計画書等
B T トレーニング仕様文書 トレーニング計画に関する文書 トレーニング説明書
C A 引合、計算、申込、検収の情報 同左 引合書・落札内示書・検収通知書
C B 承認用文書 承認・委託等の情報 適用承認書・承認許可書
C C 契約文書 契約の内容情報 契約書・検収完了書・受け渡し条件
C D 発注及び納品文書 発注情報 注文書・貨物引渡通知書
C E 送付文書 送付情報 送り状
C F 保険文書 保険情報 保険契約書・損害評価表
C G 保証文書 保証情報 保証証明書
C H 専門技術知識 専門家の意見等 専門技術資料
D A データ文書 仕様書的なもの データシート・寸法図・仕様書
D B 説明文書 システム・他の文書の技術的説明書 システム説明書・文書化構成説明書
D C 指示書およびマニュアル 製品等の取扱・据付説明書 製造指示書・据付指示書・検査指示書・取扱説明書
D D 技術報告書 技術に関する一般的所見情報 技術報告書・研究開発報告書
D E カタログ掲載文書 製品・サービスの範囲に関する情報 カタログ・リーフレット
D F 技術刊行資料 刊行物の形で技術内容の一般情報を示す文書 技術刊行物
E A 法的要求文書 技術制限・当局許可等 法令
E B 規格及び規制 標準化組織による指針 IEC・ISO・JIS
E C 技術仕様・要求文書 顧客要求を満たす適切な装置等の設計と引渡に必要な情報 要求仕様書・技術仕様書
E D 寸法文書 データ類の仮定値に関する情報 計算シート(技術の)
F A 機能全体文書 図示の形でシステムの機能・構造を全体的に表す文書 全体図・ネットワーク・ブロック線図
F B 流れ線図 システムの手順・流れなどの情報 ブロック線図・配管計装線図・フロー図
F C MMI配置文書 マンマシーンインターフェースの配置を示す文書 表示板配置図
F E 機能説明 システム等の機能的動作に関する情報 機能説明
F F 機能図表 機能的動作を優先順に示す線図 論理機能線図・シーケンス図
F P 信号説明 機能ユニットの入力または出力として定義される信号の情報 信号リスト
F Q 設定値文書 設定値等の情報 設定値リスト
F T ソフトウェア仕様文書 ソフトウェアに特定の情報を提供している文書 プログラム線図・コードリスト・設計説明書
L A 開発・調査文書 道路・インフラ・建築地の調査情報 土地計画図
L B 土木・基礎工事文書 建設地での土木工事・基礎工事に関する情報 掘削計画図・基礎図
L C 建物骨組文書 構造物の位置と特性に関する情報 配筋図・静荷重図
L D 現地位置文書 現地据付市に関する情報 据付図・配置図・ケーブル経路図
L H 建造物内位置文書 建造物の位置に関する情報 建築図
L U 機器内位置文書 キュービクル・盤等の構成部品の位置に関する情報 QB組立図・盤組立図
M A 接続文書 部品・組立品の物理的接続についての情報 ユニット接続図・端子接続図
M B ケーブルまたは配管文書 現地におけるケーブル・配管敷設に必要な情報 ケーブル線図・配管リスト
P A 材料リスト 主に据付調整に必要な資材の情報(ボルト・ネジ・工具・計測器)など 材料リスト
P B 部品リスト 対象物の交換に保管する部品情報 部品リスト・予備品リスト・ラベルリスト
P C 品目リスト 数量を特定せずに製造に必要な部品等を示す文書 品目リスト
P D 製品リスト及び製品タイプリスト 製品のタイプについての情報 製品リスト・製品タイプリスト
Q A 品質マネジメント文書 品質保証活動に関する文書 試験合格証・材料証明書・試験成績書・監査記録・不適合リスト・適合宣言
Q B 安全性記述文書 要員・使用者の人命健康、環境等についての危険や損害防止に関する情報を示す文書 安全性検討・危険度評価
T A 計画図 計画または構想段階における対象物の情報 概念図・設計図
T B 構造設計図 最終段階での対象物の情報を示す文書 寸法図・取合図・分解図
T C 制作及び組立図 制作及び組み立てに必要な情報 製作図・穴あけ計画・溶接計画
T L 配置文書 構成部品の配置に関する情報を示す文書 配置図
T Z 運転手順及び記録 システムの運転期間中の設定値等の記録 運転記録
W A 設定値文書 プロセスの運転に関する設定値情報 作業処方書
W T 履歴記録簿 特定の活動中のイベントの定期的な記録 運転履歴記録・保守点検記録

附属書Bに「確立された文書種類」というのがある。例えば「AA:表紙」「LH:建築図」「QZ:監査記録」などが提示されている。これらは個別にJISやISOやIEC規格があったり、慣習的によく知られているものである、とされている。附属書Bでは確立された文書種類の最低限の情報内容、含まれうる情報要素の例が書かれています。

感想としては、マスター性の文書と、プロジェクト性の文書が混在しているよなーという感じがする。AA総括文書などはマスターの文書の一覧を示す文書とプロジェクトの文書一覧を示す文書の両方があったり、DAデータ文書はマスター性の文書ですが、同じものをプロジェクトに適用するとEC技術仕様/要求文書になってDDCが変わったりする。これらの仕分けをする必要があるんじゃないか?という気持ちがある。

構造化(および参照指定)

JIS C0454を見ると、文書及びオブジェクトの階層構造化ガイドラインが示されています。序文には以下のように書かれている。

この規格は、次によって、システムの構造化原則と文書の構造化原則とを関連付けることが出来る。
-主文書を用いた製品構造の情報・文書の体系化による、製造業における共通する業務の標準化
-技術的オブジェクトの一つの文書群において、補文書と明確に関連付けられる主文書の一般的概念を確立することによる、JIS C 0451の6.で示す指針の細目化および形式化
-文書の構造化における、JIS C 0452-1の構造化原則によるオブジェクトの概念の適用。幾つかの観点を持ってオブジェクトが系統的な方法でまとめられる点で、これまでの規格の範囲を超えている。

「システムの構造化原則(JIS C 0452-1)」と「文書の構造化原則(JIS C 0451)」を関連付けることが出来る、と書いている。この点については後で説明するとして、とりあえず文書の構造化については、「文書には文書構造があり、『識別部分』『仕様書部分』『改訂部分』『管理部分』がありますね(4.3.2)」「文書には主文書および補文書があり、分割されえますね(5)」「主文書は補文書を引用していますね(5.1)」のようなことが書いている。まあそうでしょう。そのとおりです。

システムの構造化原則についてはJIS C 0452-1を読む。
文書に書かれているのは物であって、ものの一意な指定をしたい。という気持ちでJIS C 0452-1を読むとそう書いてある。参照指定というのがそれ。
「オブジェクトの性質やら何やらについてツリー的構造を持たせて分類できますね?」ということが書かれているのが重要。まあ参照指定はともかくとしても、「建屋」の「空間」の「照明」の「スイッチ」の「型式」、「建屋」の「境界」の「壁」の「ドア」の「耐火構造」などというように、このオブジェクトをつなぐ「の」をドットに変えれば、おおなんかメソッドチェーンじゃん、みたいな感じがありますね?あれ。
JIS C 0452-2ではオブジェクトの目的またはタスクに対するオブジェクトの分類記号を定義している。例えばC:材料、エネルギー又は情報の保存<記録Recording><貯蔵又は保存Storing>には例としてタンク・コンテナ・蓄圧器・コンデンサ・ハードディスクなどが例示されており、これを用いてオブジェクトに記号を振っていくと、ツリー状の構造を自然に構成できますね?と書いてある。

こういう思想でSTEPとかifc(-xml)などが作られているのだなぁ、という気持ちがあります。ifcはBMIの書式の一つですが、詳しくはHome — Welcome to buildingSMART-Tech.orgを参照のこと。オブジェクトを構造化したいという気持ちがあり、ifcではオブジェクトをツリーとして表現します。ifcは異なるCAD間でのBMI記述の交換を可能とするものだと位置づけられていて、ifcファイル1つを渡すことで十分な情報を与えられるようにしましょうというものです。

個人的には、文書は主文書と補文書に分けて管理しましょうと言ってて、一方でオブジェクトは1ファイルで管理しましょう、と言っているような気がして、それどうなのです?矛盾しているのでは?と感じる。
運用においては文書とオブジェクトの差については注意が必要。例えば改定について、文書が改定されるのと、オブジェクトが改定されるのは確かに同じようなものです。しかし、オブジェクトの改定は文書の改定をもって記録されるわけで、オブジェクトの改定をオブジェクト自身に記録するわけにはいかない。文書は適当なフォルダにまとめれば簡単にリストが作れるが、一方でオブジェクトはそうではない。また文書からオブジェクトに対してのリンクは貼られるが、一方でオブジェクト側から文書にリンクすることは無い。このような差があるので、一般的に文書とオブジェクトの統一が出来るわけじゃないでしょう。
だいたい、一貫性の管理、人間じゃ無理では?人間がやったら絶対コミット漏れする。文書だけ更新してオブジェクト更新できてないとか間違いなく起こる。そういうようなDBを用いてモデリングするしかなくないですか?という思いがあります。

またJIS Z 8245-1では文書及びメタデータのある文書タイプが挙げられている。
単体文書、複合文書、集合文書、文書セットの4つであり、以下引用のように書かれている。
ちなみに「集合文書」は「文書集合」とも書かれている箇所があり規格上で表記にゆれがある気がする。3.2.6定義部分では「集合文書」の表現で定義されているようだ。

4.3.1 単体文書 個々の文書は、メタデータに関係づけられている。(略)
さらに、この規格では、次により包括的な構造をサポートしている。
4.3.2 複合文書 文章は、結果としては2つ以上の種類の文書から構成されたものになる。例えば、技術仕様文書は、テキストファイル及び/又は画像的表現のファイルからなる。個々のファイルは、異なったソフトウェアアプリケーションによって作られる場合もある(略)。結果としての文書からは、それの前段階のプロセスはわからない。
複合文書に含まれる他文書とのリンクのマネジメントについては4.4を参照。(略)
4.3.3 文書集合 文書集合は、それぞれがそれ自身でメタデータとの関連付けを持っている独立した文書の集合である。文書集合はメタデータをもつが、必ずしも自身の単独の文書をもつ必要はない。(略)
備考 文書集合には、何がどのように集合しているかの"レシピ"が含まれている。このレシピは、文書集合のメタデータ又は文書自体の一部である。
4.3.4 文書セット 文書セットは、それ自身のメタデータを持つ。そのメタデータは、文書に含まれている文書のリストだけでなく文書セットの目的が記述されている。文書セットに含まれる各文書は、それ自身のメタデータを持っている。(略)
4.4 リンクされた文書 作成段階の文書のバージョンは、その構成要素となっている他の文書などに連結するリンクをはり付けてもよい。しかし、文書のバージョンが、例えば、承認及び発行のためにバージョン管理下に入る場合(すなわち、内容が固定化される場合)は、連結するリンクは許されない。能動的に変化するリンクによってバージョンの内容が変更してしまうからである。
備考 能動的に変化するようなリンクを持つ文書は、製造物責任などに関する問題が生じる可能性があることに注意を要する。

文書構造の類形とそのメタデータの張り方を規定した物となっているが、以下の表のようにまとめられるであろう。

文書類形 本文の有無 自身のメタデータ(バージョン)を持つ 構成要素文章を持つ 構成要素文章がメタデータ(バージョン)を持つ
単体文書 × ×
複合文書 ×
集合文書 ×
文書セット

単体文書以外ものに関しては他の文書を構成要素としてそれにリンクを貼るということが許される。しかしリンクを貼る際には構成要素文章がバージョン管理されているかどうかを注意する必要があるのだ、ということを書いています。バージョン管理されているということは下のほうでも書きますけどある目的に対する文書の「発行」を意図しているということを意味する。そこで発行につきまとう責任問題のパターンを分けるために「複合文書」と「文書セット」の差があるのだと読める。
集合文書はメタデータを持っている複数の文書を取り扱うための「フォルダ」めいたものだ、と考えられるが、発行を意図していないので構成要素文書はバージョン管理化のものでなくても良さげだなあ、と読める。マスターデータとかは実際発行されないので、そういう文書群は集合文書ですね。

ライフサイクル・成熟度

JIS Z 8245-1「技術文書マネジメント-第一部:原則及び方法」の適用範囲を見ましょう。

1.適用範囲
この規格は、オブジェクトに関係する文書をそのライフサイクルを通じてマネジメントするために必要なメタデータを定義する原則及び方法について規定する。ここで言う文書ライフサイクルとは、ある文書の概念的な着想の段階から論理的・物理的に削除されるまでの期間をいう。ここで規定する原則及び方法は、すべての文書マネジメントシステムの基礎となる。
この規格は、すべてのアプリケーション分野における基本規格であり、かつ、第2部(備考1参照)に対して適用できる枠組みを規定する。(略)
4.3 文書の概念
ここに示す文書の概念は、従来の紙による文書だけでなく、1単位(情報が格納された一つの容器)として扱われるコンピュータベースの情報も取り扱う。この単位で、識別、構成、処理、管理、交換及び伝達される。
この規格において文書は、単体文書、複合文書、集合文書又は文書セットのいずれかになり得る。
例を、次に示す。
‐テキスト文書、例えば、文字による記述又はメッセージ。
‐グラフィカル文書、例えば、製図、絵画、図形、図表
‐リスト、例えば、部品リスト。
ハイパーテキスト文書、例えば、SGMLXML、HTML上にリンクされた文書。
‐マルチメディア文書、例えば、テキスト、画像、ビデオ、音声を合成したもの。
‐電子情報パッケージ(バスメッセージ)、例えば、クエリーメッセージ、自動ログメッセージ。
‐CAxモデル、例えば、CAE、CAD、CAM、多観点のモデル。

まずJIS Z 8245-1の規格の意図を説明すると、上のような感じで、結構包括的な規格なんですね、と言った感じ。媒体、文書の複合性等を包括する。
文書のライフサイクルというのがあり、それは着想から削除までの期間と規定する。それをマネジメントするという意図がある。
具体的にはライフサイクルを6.1で以下のように分類している。

No. ライフサイクル 活動例 管領 アーカイブ(長期保管領域) 管領域活動例
1 着手 検索・再利用・識別・分類・目次 × × なし
2 作成 編集・検索・再利用・半自動生成・回覧・参照・共同作業 × 検索・取出・閲覧・削除
3 確立 回覧・調査・統計・承認・発行 × 同上
4 使用 通知・購読・配布・全複写・部分複写・代替フォーマット提供・情報媒体提供・閲覧・内容分析 検索・取出し・閲覧・削除・フォーマット更新・代替情報媒体提供
5 改定 着手・検索・全面改訂・校正・記述・協調 同上
6 廃止 着手・検索・協調・承認・廃止・ファイル履歴・取出 同上
7 削除 着手・検索・協調・承認・消去(削除) × × なし

また文書のライフサイクルにおいて、活動に応じて成熟度が上昇していく。成熟度が上昇する際に「検討用」「設計用」「承認用」「決定版」「回覧用」「改定版」「完成版」などの発行目的に対応するバージョンがあり、バージョンによって管理される、というモデルとなっています。

バージョン

JIS Z 8245-1の4.5「文書のバージョン」では以下のように書かれている。

4.5 文書のバージョン
4.5.1 一般 文書を使用及び/又は処理する限定された環境の中では、新しい文書のバージョンの発行基準を定めなければならない。一般的に次の2種類の変更が発生する。
a) 情報の更新
b) 情報の可視的な表現の変更
発行された文書のバージョンの基礎となる情報が変更される場合、文書のバージョンを新しくしなければならない。
文書の表現の変更の場合は、必ずしもバージョンを新しくする必要はない。
4.5.2 バージョンの有効性 文書のバージョンは、一つ又は複数の定められた目的のために発行することが出来る。文書のバージョンのそれぞれの目的には、有効となる時期及び期間、すなわち、バージョンの有効性を宣言する。目的とともにその有効性が変わった場合は、新しいバージョンを作成せずに、目的を変更してその有効期間を延長してもよい。
4.5.3 連続的に有効性が遷移するバージョン 連続的に有効なバージョンを更新する場合、最新に発行された文書のバージョンが唯一効力を持つ。すなわち、新しく発行されたバージョンは、同じ文書のバージョンが発行される場合、"取って代わる/取って代わられる"という双方向の関係が新旧のバージョン間で確立されなければならない。先行のバージョンのメタデータに、それが後続のバージョンによって取って代わられることを記述する。また、後続のバージョンのメタデータに、それが先行のものに取って代わることを記述する。(略)
4.5.4 同時に複数有効性が存在するバージョン 同時に有効なバージョンが複数存在する方法が適用される場合、幾つかの発行された文書のバージョンが同時に有効である。すなわち、新しく発行された文書のバージョンは、同じ文書の以前に発行されたバージョンに自動的には取って代わることはない。
バージョンのそれぞれの決められた目的は、その目的の明確な終了、すなわち、決められた有効期限までは有効である。

ということで、文書は文書の発行目的の変更に伴って、バージョンを変更しなさい、ということですね。いろいろな文書があり、その中にはライフサイクルが長くて改定されうるものや、短くて改定されないもの、日毎に変わるので改定もクソもないものなどがありますが、多分文書タイプに応じた付番をつけとけばいいでしょう。長いものは.NET形式、短いものは日付管理とかそういう感じ。

一方で、文書が異なる(DCCが異なる)場合は、バージョンは一般に一致することはないでしょう、ということです。もちろん文書に対するバージョン管理だからこれでいいのだが、ここでオブジェクトの細々した変更はそれお前バージョン管理できるのかよ、という気持ちがある。また、有効期限とライフサイクルの関係も注意する必要がある。

ついでに.NET Frameworkのバージョンの付け方の指針も確認しましょう。めんどくせぇので詳細は省きますが、.NET Framework(Microsoftの共通言語基盤CLR)上ではネイティブの実行ファイル(PE)単体はなく、少なくともアセンブリのような実行コード(IL)とIL内のクラスなどの記述を含んだメタデータがセットとなったモジュールがあります。一つ以上のモジュールをまとめて一つの名前・バージョン・カルチャ・署名(これらをまとめてマニフェストという)をつけると一つのアセンブリという単位のまとまりが出来る。アセンブリに対して、CRLは別のプログラムをリンクしたりいろいろ出来る。署名をすると、共有可能なアセンブリとなります。(署名をしなくても使えることは使えるが同一ディレクトリなどに制限される。)共有アセンブリに対するリンクでは、CLRがバージョンチェックをしてくれるのでDLL地獄にならない、というよさがあります。
アセンブリマニフェストのバージョンの形式は、メジャー番号.マイナー番号.ビルド番号.リビジョンです。だいたいのパッケージのバージョンでは、メジャー番号は後方互換性がない場合に増えて、そうでないときはリリースごとにマイナーバージョンが増える。微妙なパッチとかバグフィックスの場合はビルド番号やリビジョンが増える。

有効期限とライフサイクルに関して、例。

  • ある機械製品があり、複数の部品の組み合わせで出来ている。
  • 製品自体の仕様書があり、複数の部品a,b,cの仕様書と、部品リスト・組立図をまとめた製作用図書がある。

この製品について以下のように文書を発行していくことを考えよう。
1)この製品をプロジェクトに用いることになり、要求仕様を提示することになった。
2)プロジェクト中に要求される製品の仕様の変更があり、それにともなって部品aが変更になった。
発行すべき文書およびそのバージョンを考える。マスター、初版発行後、改定後の文書とバージョンを考えると以下のようになる。

マスター文書 マスターDCC マスターバージョン 初版文書名 初版DDC 初版バージョン 改定後バージョン
× × × 文書表紙 MAA 1 2
製品文書構成リスト MDB xxx 要求仕様文書構成リスト MAB 1 2
製品仕様書 MDA xxx プロジェクト用製品要求仕様書 MEC 1 2
製品部品リスト MDC xxx プロジェクト用部品リスト MPB 1 2
製品組立図 MDC xxx プロジェクト用組立図 MFA 1 2
部品a仕様書 MDA xxx 部品a仕様書 MEC 1 2
部品b仕様書 MDA xxx 部品b仕様書 MEC 1 1
部品c仕様書 MDA xxx 部品c仕様書 MEC 1 1

まずマスターデータ文書からプロジェクト時の製品仕様要求文書を作る際に、文書種類分類コードが変更されて、別の文書となり、バージョンを1から取り直す事となる。この時プロジェクト文書からマスター文書への参照を張っておいたほうがいいが、マスターデータの有効性は消えない。
改定時は、部品b,cについては有効なので生きてるが、その他の改定前プロジェクト文書は無効としなければならない。また、製品要求仕様書以下は文書リストによって参照されるが、文書リストの参照は有効になった改定後バージョンの文書を参照するようしなければならない。

あと細々ですけど、作成段階においては作成者が、承認段階においては承認を要する(いくらかの)組織内で、発行段階においては複数の組織内で通用するバージョンが必要になるということが有ります。.NET方式でいいんじゃねえかな。

  • major ver.->発行バージョン
  • minor ver.->承認用バージョン
  • build ver.->作成者バージョン

くらいの雰囲気とか。

メタデータ

メタデータの内容

これもJIS Z 8245-1で定義されているものを参考にする。

まず指針としては5.使用環境に関連した文書のメタデータにかかれていて、おおよそ以下の注意がある。

  • 文書ライフサイクルに関連したメタデータがある
  • オブジェクトを作り出すビジネスプロセス(製品ライフサイクル)に関連したメタデータがある。
  • ビジネスプロセスを運用している組織の一般的知識ベースの生成維持管理に関連したメタデータがある。
  • あるプロジェクトの中での製品に関する情報を示すメタデータは文書のメタデータには含めないほうが良い。

文書ライフサクル内の活動に関連したメタデータについては、各ライフサイクルにおいてメタデータに含めるべき情報の例が6.に書かれている。

  • 着手段階
    • 識別用
      • 組織をもととした文書識別
      • 国際文書ナンバリングシステム、例えばISBN、ISSN
      • IDDNなどのデジタル出版物の国際的な識別子
      • 国際商品コードシステム、例えばJAN/EAN/UPC
    • 分類用
      • 契約上の識別子ならびにパートナーである組織及びその役割
      • 作業指示書の識別子
      • プロジェクトの識別子
      • 所有者、著者及び関連組織のデータ
      • 文書識別システム
      • 文書の役割
      • 文書の内容を示す文書の表題
      • 文書で使用する言語
      • 記載されたオブジェクト(への参照)
      • 発行日、有効期限
      • 作業分類体系における特定のノードとの対応
      • 文書化体系における特定のノードとの対応
      • 文書分類システム
      • 文書の作成に使用する国際規格、地域規格、契約文書のリストへの参照
      • 内外の承認用・製品検査用の仕様書として利用する文書リストへの参照情報
      • 文書のバージョン履歴(置換・更新)
      • セキュリティ等級
      • メタデータ及び関連文書内容へのアクセス権
      • 国家的、地域的又は組織的な契約で定めた譲渡制限
      • 契約又は業務指示書で規定された利用上の権利又は責任
      • 著作権特許権等の権利保護
      • 適用する評価及び承認手続き
      • 複数の言語によって表現された同一の情報を持つ文書がある場合は、原典の識別
      • 電子文書の作成に使われたテンプレート及び出典の識別
  • 作成段階
      • 成熟度
      • キーワードリスト
      • 抜粋又は要約
      • 文書の出典
  • 確立段階
    • 承認用
      • 作成者、送付日、要求日
      • 調査者、調査日、調査手順
      • 調査時コメント
      • 承認者、承認日、承認手順
      • 承認時コメント
    • 発行用
      • 作成者、送付日、要求日
      • 発行者、発行日、発行手順
      • 発行する文書バージョンの有効性
      • 発行目的
      • 発行目的と関連する製品のバージョン、ビジネスプロセスへの参照
      • 発行時コメント
  • 使用段階
      • 文書の使用実績
    • 配布用
      • 配布リスト、配布先リスト
      • 受信先の識別、住所とかメールアドレスとか
      • 関係者の役割
      • 配布リストへの申込
      • 物理的送付の場合の配布フォーマット仕様
      • 配布内容の一部である文書セットのバージョン
      • 発送作業の識別
      • 受取証
      • 参照した文書のバージョンのアクセス履歴情報
    • 閲覧用
      • 文書のバージョンにアクセスするのに必要なすべてのデータフォーマットに関する情報
  • 改定段階
    • 内容改定用
      • 新しいもののもとになった文書のバージョン
      • 他の文書のバージョンとの関係、置換又は影響
      • 変更責任者
      • 改定内容
      • 改定日
      • 変更の理由及び変更指示に関する事項
    • 発行目的の改定、廃止
      • 文書のバージョンの相互関係の履歴(取って代わる/取って代わられる)
      • 変更責任者
      • 改定内容
      • 改定日
      • 変更の理由及び変更指示に関する事項
  • アーカイブ段階
      • 保管期限
      • 書込アクセス権
      • 書込セキュリティ等級
      • 使用したソフトウェアおよびバージョン
      • 使用したプロセッサおよびバージョン
      • 使用した圧縮ソフトおよびバージョン
      • 使用した暗号化ソフトおよびバージョン
      • デジタル署名の使用有無
      • 記録媒体に応じたデータのリフレッシュ周期
      • 関連データを伴う物理的搬送媒体の更新履歴
      • フォーマット更新履歴
      • システム変更履歴
      • アクセス履歴
      • データ媒体の物理的な場所
      • 論理アドレス、パスとかファイル名とか
      • 内部索引リスト
  • 削除段階

メタデータの形式

ビジネス文書のメタデータ項目としては上記の項目ぐらいで問題ないと思うが、メタデータの電子形式は特段規定されてない。.xmlや.configを利用すれば良いでしょう、という気分ですが、この辺は図書館系のダブリンコアおよびその発展系を見て、そういう雰囲気で作ると楽かもしれない。

図書館系メタデータは、ダブリンコアおよびその拡張がよく使われている。
まず(シンプル)ダブリンコアというのがあり15の項のものがDublin Core Metadata Element Set(DCMES、ISO15836)で規定されている。さらにより細かい情報を定義できるような拡張プロパティおよび符号化スキームが追加されてこれがDCMI Metadata Terms(DCterms)が公開された。また国立国会図書館でもっと細かい書誌情報プロパティが追加されたものがあって、DCNDLという。この際ダブリンコアメタデータの内容は置いとくとして、国会図書館のがResource Description Framework(RDF)形式で公開されていて、これが参考になるでしょう。RDFXML内で記述することが出来るから、公開されているのは、RDF/XML形式ですね。またxml形式もある。
国立国会図書館ダブリンコアメタデータ記述(DC-NDL)実例集 | 国立国会図書館-National Diet Library
下の方に「2.資料の種類との記述例」というのがあるのでそこ見てください。xml形式のほうが楽そう。

総括

いろいろ調べたがJIS C 0451系とZ 8245-1系を写すだけみたいになってしまった。
メタデータの実際の作成を行ってみて、システムを考えていきたい。