設計者が作成した成果は、設計者本人だけが理解できる状態では不十分である。企業は知識を蓄積する必要があり、後任者は前任者の成果を理解できなければならない。「標準」の判断基準の一つは、新人が規則だけを頼りに、自分が作成していないﾌﾟﾛｼﾞｪｸﾄを識別できるかにある。
ﾃﾞｰﾀ管理の目的
ｸﾞﾛｰﾊﾞﾙ主ｷｰ
各従業員が作成したﾘｿｰｽは企業のﾘｿｰｽとして蓄積される必要がある。担当者が離任した後に、引き継ぎ不能なﾃﾞｰﾀの黑洞となってはならない。
検索と識別は基本要件であり、検索ではkeyの設計が最も重要となる。連番配布がﾈｯﾄﾜｰｸ接続に依存する場合、出張、在宅勤務、休暇、残業中にも番号を取得できるのが理想である。継続接続ができない場合や、切断状態を前提とする必要がある場合は、ｵﾌﾗｲﾝで一意ｷｰを作成する手段が必要となる。社員番号と連番の組合せ、またはUUIDは有効なｵﾌﾗｲﾝｷｰである。
UUIDは一意ｷｰを得る数学的な方法である。欠点は32文字と長く、口頭で伝えられずｺﾋﾟｰしかできないこと、内容が具体的でないことにある。
社員番号と連番には現実的な意味があるが、UUIDにはない。UUIDの唯一の利点は、DBに1ﾌｨｰﾙﾄﾞだけで保持できることである。
社員番号と連番は2ﾌｨｰﾙﾄﾞ必要で、巨大なDBでは検索負荷が大きく増える。文字列連結で1ﾌｨｰﾙﾄﾞにすれば現実的な意味を保ったまま運用できるため、こちらを推奨する。
ｸﾗｳﾄﾞｻｰﾋﾞｽで単機動作を考慮する必要があるかは、最終的にﾕｰｻﾞ満足度の問題である。ﾈｯﾄﾜｰｸｻｰﾋﾞｽが未接続時に利用できないのは当然であり、実際に単機動作が必要な場面が存在するかを判断すればよい。
ｻｰﾊﾞが提供するのはｻｰﾋﾞｽではなく規則である。規則は人が制定し、人が実行する。制定時には業務に適合する柔軟性を確保し、実行時にはｺｰﾄﾞで統一して強制する。
ﾌﾟﾛｼﾞｪｸﾄ名の設定
ﾌﾟﾛｼﾞｪｸﾄ名には連番、社員番号、UUID、名称、その他の情報を使用できる。
接頭辞拡張：図面番号やその他の識別子に企業接頭辞を付ける企業は多い。例えば「北京嵐月」なら「LY-ﾌﾟﾛｼﾞｪｸﾄ1」とする。機能上の意味は少ないが、一般的な選好である。
量化権限値：誰が参照でき、誰が変更できるかを数値で表す。ﾌﾟﾛｼﾞｪｸﾄAの権限値が80、ﾕｰｻﾞBが50なら、Bは変更可能となる。数値による権限判定方式である。
休眠：DB検索速度を高め、長期間使用していないﾃﾞｰﾀを圧縮するための技術的措置である。
作成日時、担当者、説明は文字どおりの項目であり、追加説明は不要である。
ﾃﾞｰﾀﾃｰﾌﾞﾙ実装：平文には主ｷｰ、社員番号と連番、接頭辞拡張、名称を含める。暗号文には権限、休眠、作成日時、担当者、説明を含める。
ﾌｧｲﾙ保存規則：ﾌｧｲﾙを見つけられること
ﾌﾟﾛｼﾞｪｸﾄごとに固定のﾌｫﾙﾀﾞ構成を作成する。単機環境ではﾌｫﾙﾀﾞが最も直感的な識別手段となる。
- 階層は固定し、可能な限りﾌﾗｯﾄにする。規則を知らなくても目的の場所を一目で確認できるようにする。
- 必要なﾌｫﾙﾀﾞは管理者が事前定義する。
- 技術上必須のﾌｫﾙﾀﾞ以外は、管理者による削除・変更を許可する。
- 規則を確定した後はｺｰﾄﾞで自動作成し、外部担当者が位置を特定できない任意ﾌｫﾙﾀﾞの増加を抑える。
上図のSW、Prod、BackはSWTDOの固定ﾌｫﾙﾀﾞであり、設計原本、生産ﾌｧｲﾙ、ﾊﾞｯｸｱｯﾌﾟを保存する。その他のﾌｫﾙﾀﾞは削除・変更できる。
ﾌｧｲﾙが存在することと、ﾘｿｰｽとして再利用できることは異なる。
ﾌｧｲﾙを見つけられない状態は、ﾘｿｰｽの黑洞の始まりであり、担当者変更時に資料を失う最初の段階である。
ﾌｧｲﾙ名設定の考慮点
以下では、すべてのﾌｧｲﾙ名にｸﾞﾛｰﾊﾞﾙ主ｷｰを含めることを前提とする。
企業のﾌｧｲﾙ名規則は多様で、すべての企業に通用する唯一の規則は存在しない。SWTDOは独自の規則を押し付けず、企業が規則を定義できるﾌﾟﾛｸﾞﾗﾏﾌﾞﾙな方式を提供する。
SWTDOはﾌｧｲﾙ名を要素に分解し、ﾕｰｻﾞが要素を組み合わせて命名要件を実現する。
要素の主な分類は次のとおりである。
- 固定式：入力値をそのまま出力する。Cus1はCus1、空白は空白、ｺﾛﾝはｺﾛﾝのまま出力する。
- 関数式：実行時に情報を生成する。短日付は当日の日付、ﾌﾟﾛｼﾞｪｸﾄ名は現在のﾌﾟﾛｼﾞｪｸﾄ名を出力する。
- 判定式：ﾌｧｲﾙ種別や位置に応じて出力する。部品はP、ｱｾﾝﾌﾞﾘはU、第3階層のｱｾﾝﾌﾞﾘ配下なら3を出力する。
- 呼出抽出式：ﾌｧｲﾙ属性から値を抽出する。属性が一意なﾃﾞｰﾀ源に従うことが前提である。属性の参照方法も複数あるため、最終的な組合せは4種類に限定されず、複数方式の二次的な組合せが可能となる。
この要素組合せ方式で、実装不能な企業ﾌｧｲﾙ名はこれまで見つかっていない。材料など一部のSolidWorks専用関数は不足するが、対応する実装方法は存在する。以前のBOMには部品番号専用の抽出関数があった。
MakeOrBuyという分類も粗い。Makeには溶接工場、射出成形工場、機械加工、さらに布料工場での加工も含まれる。
車ｶﾊﾞｰ、ｿｰﾗｰﾊﾞｯｸﾊﾟｯｸ、ﾄﾞﾛｰﾝ用落下傘などの設計例からも、製造分類の多様性が分かる。粗い分類では配布問題を解決できず、最終的にはﾕｰｻﾞ定義が必要となる。ﾌｨｰﾙﾄﾞを固定するのではなく、ﾌｨｰﾙﾄﾞを定義できる仕組みを提供する。詳細はBOM標準化で説明する。
