部品表とフィーチャ･オプション

　「仕様書によるアプリの動的制御」を実現したＯＳＳプラットフォーム「XEAD Driver」を使って、生産管理システムの開発を進めている。その複雑膨大な仕様の中から、生産管理システムに関する有用な知識をときどき紹介したい。今回は、品目毎の仕様のバリエーションを表すための工夫である「フィーチャ･オプション」について取り上げよう。

■有効期間で構成を切り替える

　工場で新製品が企画されて同じ仕様でずっと製造されることは稀で、さまざまな理由で仕様変更がなされる。これを「改版（かいはん）」という。改版にともなって、部品表や工程表の一部が切り替わることがある。これらの生産基本情報と改版とをどう統合するか。それは生産管理システムの設計課題のひとつだ。

　同一製品向けに部品構成を適宜切り替えるためによく用いられるやり方が、部品表への「有効期間」の組み込みである。モデル１では、品目Ａに関してＢとＣとＤが構成品として置かれている(*1)。ただし、Ｃは９月１日に失効するいっぽう、Ｄが同日に発効する。構成の一部がその日（改版日）に切り替わるということだ。

＜モデル１＞

【品目】品目id,品名,{品番}
　＋　　￣￣￣
　｜　　00001　Ａ　 ITEMA
　｜　　00002　Ｂ　 ITEMB
　｜　　00003　Ｃ　 ITEMC
　｜　　00004　Ｄ　 ITEMD
　｜
　└─∈【部品表】品目id＋構成行番,構成品id,構成比,発効日,失効日
　　　　　　　　　￣￣￣￣￣￣￣￣
　　　　　　　　　　00001　　　01　　00002　　2.0　　...　　...
　　　　　　　　　　00001　　　02　　00003　　1.0　　...　　9/1
　　　　　　　　　　00001　　　03　　00004　　1.0　　9/1　　...

　こうしたうえで、生産計画や製造指示を作成する際に日付指定で部品展開することで、その日における正しい部品構成が手に入る。上の例では、８月の日付を基準日として展開すればＡの構成としてＢとＣが手に入るし、９月の日付ではＢとＤが手に入る。

　このやり方はわかりやすいが、改版の実状を考えると問題含みである。特定日を改版の起点日とみなせることが多いとはいえ、その日にモノゴトがきれいに切り替わるわけではないからだ。改版後でも、顧客の都合や資材の在庫状況次第で「旧版」の製品を製造する必要が生じることがある。そのためには、製造指示であれば「製造予定日」とは別に「部品展開基準日」みたいな項目を置けばいいのだが、なんとなくイケてない。

■ＦＯで仕様を切り替える

　そこでお奨めしたいのが「フィーチャ・オプション(FO, Feature Options)」である（フューチャ・オプションではない）。「フィーチャ」とそれぞれのフィーチャが取り得る「オプション」の体系を品目毎に定めておく。そのうえで、個々の品目取引において「フィーチャ・オプション・コード(FOC)」を与えることで、品目のバリエーションが決まる。モデル２では、FOCの１桁目が「色」、２桁目が「サイズ」、３～４桁目が「版」であるようなFO体系の例がインスタンスとして添えられている。

＜モデル２＞

【品目】品目id,品名,{品番}
　＋　　￣￣￣
　｜　　00001　Ａ　 ITEMA
　｜
　└─∈【フィーチャ】品目id,F行番,フィーチャ名,桁数,順序
　　　　　＋　　　　　￣￣￣￣￣￣
　　　　　｜　　　　　00001　　01　　色　　　　　　1　　1
　　　　　｜　　　　　00001　　02　　サイズ　　　　1　　2
　　　　　｜　　　　　00001　　03　　版　　　　　　2　　3
　　　　　｜
　　　　　└─∈【オプション】品目id,F行番,OPT,摘要
　　　　　　　　　　　　　　　￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　00001　　01　B　　黒
　　　　　　　　　　　　　　　00001　　01　R　　赤
　　　　　　　　　　　　　　　00001　　02　M　　Ｍ
　　　　　　　　　　　　　　　00001　　02　L　　Ｌ
　　　　　　　　　　　　　　　00001　　03　00　　初版
　　　　　　　　　　　　　　　00001　　03　01　　２版

　この体系において、品目ＡのFOCとして"RM00"を指定すると「赤のＭサイズの初版品」と解釈される。"BM01"ならば「黒のＭサイズの２版品」だ。ちょうど「モンタージュ写真」のようなもので、"目"、"鼻"、"口"等は異なる「フィーチャ（造作要素）」に相当し、"パッチリ目"や"タレ目"はフィーチャである"目"の「オプション（造作要素が取り得る値）」に相当する。

　個々の取引においてFOCを指定することで、それぞれに要求されている仕様のバリエーションをモンタージュ写真のように精緻に指定できる。品番毎に自由にFO体系を設定できるので、微妙な仕様の違いが多いような製品を扱うような業種でとくに有効だ。仕様のバリエーション毎にいちいち品番を用意することで起こってしまう「品番爆発」を避けられるからだ。

■ＦＯで構成を切り替える

　フィーチャ･オプションと統合された部品表のモデリング例を見よう（モデル３）。「FOマスク」に注目してほしい。これが"****"（全桁ワイルドカード）であれば、FOCの値にかかわらずその構成品（品目Ｂ）が選択される。この例では、品目ＣとＤとが「版」のオプション値にもとづいて切り替わるようになっている。「工程表（製品毎に実施されるべき工程の一覧）」も同様に対処できる。

＜モデル３＞

【品目】品目id,品名,{品番}
　＋　　￣￣￣
　｜　　00001　Ａ　 ITEMA
　｜　　00002　Ｂ　 ITEMB
　｜　　00003　Ｃ　 ITEMC
　｜　　00004　Ｄ　 ITEMD
　｜
　└─∈【部品表】品目id＋構成行番,構成品id,構成比,FOマスク,選除
　　　　　　　　　￣￣￣￣￣￣￣￣
　　　　　　　　　　00001　　　01　　00002　　2.0　　****　選択
　　　　　　　　　　00001　　　02　　00003　　1.0　　**00　選択
　　　　　　　　　　00001　　　03　　00004　　1.0　　**01　選択

　便利なしくみだが、もちろん限界はある。異なるフィーチャ間のオプションの組み合わせの有効性に関しては、FOCの指定者が責任を持つ必要がある。上の例ではたとえば２版品では黒が無効になっていたとしても、そのような組み合わせのFOCを指定できてしまったりする。基本的には、そのような相互制約のない「直交関係にあるフィーチャ」を組み合わせてFOを体系づけする必要がある。

　また、製品の「梱包仕様」についてフィーチャ･オプションで対処すべきかどうかは微妙だ。確かに梱包の仕方にバリエーションがあるとすれば、同一製品向けでも包材や梱包方法が違ってくる。とはいえ、出荷時に梱包するためにFOC指定でいちいち製造指示する形をとるので、出荷作業が煩雑になるかもしれない。場合によっては、梱包仕様を管理するためのテーブルを別途用意したほうがいい。使いどころを見定めながら、フィーチャ･オプションを活用しよう。

*1.ユーザから見えない内部識別項目（品目id）がＰＫとされている点に注意。ユーザにとってのキーである「品番」は、ユニーク制約が付与されたただの属性として置かれている。したがって品番はいつどんなときでも変更可能である（やたらと変更すれば現場が混乱するだけだが）。