構成管理をイメージしてみます．各構成品目が複数あり，それらを横に並べます，各品目は，図面でいえばサフィックスが増えていくように，プログラムでは各コンパイル単位のバージョンが増えていくように，速度差はあっても時間軸方向に縦に伸びていくとします．一つの構成・ベースラインはそれらに横串を刺したものとなります．私には，ベースラインは，波のようにイメージできます．
11月の葉山海岸（SPIN世話人会のあとで）
***
ソフトウェアの世界でここ十年ほどでよく使われるるようになった構成管理ということばは，もちろん，Configuration Management の訳語です．別の訳語もあります．形態管理という言葉で，いまでも航空宇宙の分野で良く使われていると思います（私は形態管理という名前で最初に覚えました）．
形態というのは見えるさまで，使用する部品が異なれば見え方にも影響してきます．例えば，自動車の部品表に色を指定することで，形状は全く同じでも識別することが可能な別の車となります．
さて，この形態管理或いは構成管理は，ハードウェアの世界とソフトウェアの場合とで，少し異なっているように思います．今回，その違いを考えてみようと思います．分かりやすくするために，ハードウェアでは＜形態＞という用語を用いて，ソフトウェアでは＜構成＞という言葉を使うことにします．同じものを異なる相でみたいというだけで，基本的には同じものです．特に区別しないで済むところは構成管理とします．
***
ハードウェアの場合は，完成品を頂点として，多数の部品を組み合せることで成立します（自動車の場合は，何万点の部品という云い方がされますが，アッセンブリレベルでの指定が多いので，ある車に関して，実際に部品表に記載される数はそれほど多くはないでしょう．また，概念的には木構造を構成しますが，構成はフラットに表現します）．この組合せにより，一つの＜形態＞が生まれます．
ソフトウェアの場合は，通常は，より細かな単位，例えばコンパイル単位を構成品目とします．”細かな”というのはもちろん相対的な云い方です．ここに，幾つかの特性の違いを見ることができます．例えば，ハードウェアの場合，構成する品目は基本的に図面によって示され，しかるべき手順に則った管理がなされます．図面を書くと上司のチェックを受け，例えば図面室で受理されて初めて品目としての準備ができます．一方で，ソフトウェアの場合，構成品目として一般にコンパイル単位を選択します．この品目は，いわゆるリファクタリングの過程で，品目による構成そのものが変更対象となります．また，そうすることが保守性の観点から推奨されています．従って，ソフトウェアの分野における＜構成＞管理ソフトウェアは，ファイルの分割や併合に対して柔軟に対応可能となっています．ハードウェアの＜形態＞管理にあるように番号を付けて，会社が存続する限り全社共通で管理するという文化になじまないことになります．
***
私が，形態管理という言葉を知ったのは，MIL-std-1679Aという規格です（これは以前にアイテムの回で触れました）．その後継となったDOD-std-2167Aでは，形態管理に関して興味深い使い分けをしていました．2種類の形態管理があります．一つは開発時の管理であり，もう一つは，出荷時の管理ということです．先の二つの訳語を用いると，前者が開発時の＜構成＞管理ですし，後者が出荷時の＜形態＞管理と対応しているということもできます．この区分は形態・構成管理を考える上できわめて重要になります．一つは経時的な問題であり，もう一つは発注者ー受注者問題です．
最初に経時的な問題から考えます．ソフトウェアで一般に使われる構成管理は，主として多人数での開発をサポートするためのものです．一つのコンパイル単位の変更が他に影響を及ぼすことが大きい（これはソフトウェアの特性です），従って，今の＜構成＞状態（ベースライン）を知ることが重要になり，短ければ半日という時間刻みで更新されます．一方で，機械設計などでいう＜形態＞管理の対象となる品目は，設計者の設計結果ですから，その時点では固定したものとして，変更は容易ではありません．設計というプロセスでみると前者がその進行状態の話であり，後者は完了時点での話と云うことになります．
次の，発注者ー受注者問題というのは，如何にその構造に構成管理を写像するかということになります．例えば基本設計が終了した後に，受注者側にその結果を受け渡すとすると，発注者側での＜形態＞は，その時点で確定します．即ち，発注者にとって，その後，如何に細分化されようが，（アッセンブリという）単一の品目として扱うということになります．一方で，受注者側では，単一であるアッセンブリを開始点として，開発時＜構成＞管理及び，発注者に引き渡すための＜形態＞管理を行うということになります．この関係は，受注者が更に発注者でもある場面においても同様に繰り返されます．
このように考えることで，実務における構成管理を比較的考えやすくなります．
***
しかしながら，形態・構成管理を実務に適用しようとする場合に，考慮すべき事柄は上記に限定されるわけではありません．先ほど経時的な問題を考えましたが，より長い時間スパンにおける経時的な変化がその一つです．例えば，モデルチェンジを行うような場合（ソフトウェア的にはバージョンアップでしょうか）にどう対応するかといことがあります．このときは，（形態・構成管理がきちんとなされていると前提で）変更管理の枠組みを適用することで，多くの場合は対処可能です．逆の云い方をすると，製品が変化するのは必然なので，形態・構成管理と変更管理は，本来不可分だということになります．
もう一点は，通時的な変化です．民間におけるシステム製品のように，多くの変異（Variation）を持つ場合の効率良い形態・構成管理の方法を考慮しないといけないということです（2167では軍用の二者関契約ですので，変異は余り大きな問題とはなりません）．先に開発時と出荷時を分けましたが，ここでもその区分は有効になります．例えば，パラメータによってふるまいを変更するということを，変異への対応手段として良く行いますが，この場合は，パラメータの生成器は開発時の構成管理の対象とし，生成されたものが出荷時の構成管理の対象ということになります．
***
さて，ここまでは一般的な構成管理の話になります．機能安全（例えば，つい最近発行された ISO 26262を例にします）についても基本は同じだろうと思います．結局はテストしましょうということで一般のプロセスの枠組みを用います．しかし，このままだと，一般のテストと同じ構図で，不具合の不在証明はできないという議論に辿り着きます．或いは，ここまでの構成の議論で考えた多様な変異に対しては，「全ての構成をテストすることが現実的でない場合，合理的にサブセットを選択しても良い（Part8 9.4.2.2 (c)」ということになっています．しかし，機能安全は最後の砦であり，全ての不具合を防止することを意図しているわけではない．あくまで安全性に関わる機能の故障に特化しているのですから，網羅性が担保されないのだとすると，「合理的構成の組（reasonable subset）」のみを選択してテストということが，該当する場面はないように思います．構成管理というのはきわめて色々議論されて安定した枠組みですが，こと機能安全との関係（更にはSILとの関係）を考えるときに，いろいろと議論すべきことがあるように思います．
(nil)