create-engineering
PMS Instance
クリエイト・エンジニアリング テナント設定 / Create Engineering — Tenant Configuration
目的: 汎用 PMS DDD モデル (
docs/ddd/pms/) をクリエイト・エンジニアリングの業務に適用するためのテナント固有設定を、業務設計者・実装者が読み下せるナラティブとして記述する。 位置付け: 本ドキュメントは DDD モデルの「インスタンス」であり、業務設定値・採番規則・例外フローのうち、クリエイト・エンジニアリング固有のものだけを扱う。共通定義 (区分マスタの基本構造、ステータス遷移、アグリゲート定義) は DDD 共通ドキュメントを参照する。 生データ SSOT:docs/ddd/pms/instances/create-engineering/interview-findings.md(2026-04-28 インタビュー所見)。本ファイル中の数値・固有名詞・運用ルールはすべて当該所見に基づく。新事実は所見側に追記し、本ファイルは派生として更新する。 対比対象:docs/ddd/pms/instances/tamari/configuration.md(タマリ工業のテナント設定)。本ファイルは同フォーマットを踏襲しつつ、機種マスタ駆動 (catalog-with-options) の業態に合わせてナラティブ寄りに記述する。
1. サマリ (Tenant Summary)
| 項目 | 値 | 備考 |
|---|---|---|
| 業種 | 装置製造業 (機種マスタ駆動 + カスタムオプション) | 新設機・据付・修理・部品交換のミックス事業 |
| 主キー (案件追跡) | BDI ナンバー (製造番号) + 機種コード | 1 筐体ごとに付番。修理・部品履歴・据付履歴の長期トレースに使用 |
| 現行基幹システム | テックス (TechS / テクノス) | 中小企業向け生産管理パッケージ。利用範囲は限定 (§8 参照) |
| 業態 | 量産機種 (例: 130F) + 客先別カスタムパーツ (例: 延長ホッパー) | 親 BOM/子 BOM 自動展開、差分 5% 程度 |
| 世代管理 | I シリーズ〜 G シリーズの 4 世代 | 形式によって部材・シャフト径が変わるため部品マスタ側でリビジョン保持 (§9 参照) |
| 主要商社 | 内藤、ユニソル、山善、東洋、横瀬 | 「ほぼほぼ横瀬さんが一番多い」 |
| 取引方針 | 個人保証 (代表者個人保証) は受け付けない | 中西電気との過去経緯から方針確定 |
新システムでの位置付け: クリエイト・エンジニアリングはタマリ (案件主導 / job-shop) と異なり、機種マスタを起点とした見積・受注・BOM 展開 をベースとする。主キーは案件番号 (交番) ではなく BDI ナンバー (機械シリアル) + 機種コード の組み合わせであり、修理・部品交換のような中長期サービスを同一筐体に紐づけて追跡することを要件とする。
未確定項目 (要確認): 正式社名 (株式会社の前後表記)、決算月、締日、消費税率、税込/税抜区分。これらは
tenant-config.yaml側でnull + # 要確認として保留する。
2. 機種マスタ駆動の見積〜出荷フロー (Quote-to-Ship Flow)
クリエイト・エンジニアリングの基本フローは「機種マスタを起点に親 BOM・子 BOM が自動展開され、必要に応じてオプション・カスタム品を上乗せする」モデルである。タマリのような案件単位の自由設計とは異なり、機種コードを選んだ瞬間に約 400 部品の標準 BOM が確定する。
2.1 フロー全体像
[1] 見積 (Excel / 新システム)
└─ 機種コード選択 → 定価 × 0.42 で原価仮置き → 粗利計算
(修理見積は §7、据付見積は §6 で別途計算)
↓
[2] 受注 → 大野社長が業務指示書 (BDI ナンバー付) を起票 ← §3
↓
[3] キックオフ会 (設計主導、類似品の取扱い注意点を周知)
↓
[4] BOM 展開・引き当て (テックス内)
├─ 「部品受注入力」で空の製番を起票
├─ 機種選択 → 親品番 (ユニット) → 子部品約 400 点を一括展開
└─ 引き当て = 在庫減算 (使う認識)
↓
[5] 発注 (テックス、半自動)
├─ 永井さんがリードタイム / ロット / 単価変動を加味
└─ 部品分類 3 階層 (§4) によって発注ポリシーが分岐
↓
[6] 入荷 (紙ベース)
├─ 納品書とテックスデータを「アプリ屋アプリ」発行のバーコードで照合
└─ 受入登録
↓
[7] 棚入れ (例: 棚 16-3、テックスの棚マスタが正)
↓
[8] 製造 / 組立
├─ 業務指示書 + 製造日程表で順序決定
└─ ユニット単位の「バーコード付き紙の部品表」をピック → スキャン → 在庫減算
↓
[9] 試運転 / 検査 (ユニット別チェックリスト印刷物)
↓
[10] 出荷 (出荷費・客先・導入先・据付仕様を出荷記録 Excel に残す)
↓
[11] 納品書・請求書 (テックス外、Excel で作成 → 郵送 / メール) ← §8
↓
[12] 据付・試運転 (現地、車両・人工・交通費) ← §6
↓
[13] 修理 / 部品交換 (写真ベース) ← §7
2.2 主キーと識別子
- BDI ナンバー は受注時に確定し、製造番号としてフレームに刻印・銘板貼付される。1 筐体 = 1 BDI ナンバー。
- 機種コード (例: 130F) は機種マスタの識別子で、同じ機種は複数の BDI ナンバーで製造される。
- 製番 (テックス内の生産指示識別子) は BDI ナンバーと 1:1 で紐づく内部 ID。
- 修理・部品交換は元 BDI ナンバーに紐づけて履歴を残す (車両整備の VIN モデル相当)。
2.3 標準値・運用パラメータ
| 項目 | 値 | 出典 |
|---|---|---|
| 1 機種あたり子部品点数 | 約 400 部品 | 所見 §6 / 受注フロー §4.4 |
| 原価率 (新設) | 定価 × 0.42 (= 42%) | 所見 §4.1 |
| 原価更新ラグ | 単価が約半年前のまま反映されない (現状の課題) | 所見 §2 |
| BOM 機種間差分 | 約 5% | 所見 §5 |
| 標準品リードタイム実動 | 15 日 | 所見 §5 |
新システムでの要件: 見積→受注→ BOM 展開→発注→受入→製造→出荷の全段階で BDI ナンバー + 機種コード を主キーとして串刺しできること。原価率 42% は機種マスタのデフォルト値として保持し、機種別オーバーライドを許容する。
3. 業務指示書 (Work Instruction) の起票主体 = 大野社長
クリエイト・エンジニアリングでは 受注確定後、大野社長が業務指示書 (BDI ナンバー付) を起票する ことがフロー開始のトリガーである。これはタマリ工業の「営業発行の購買依頼書」と並ぶが、起票主体・記載項目・回付先が異なる。
3.1 業務指示書の責務
| 役割 | 大野社長 (代表) |
|---|---|
| 起票タイミング | 受注確定直後 |
| 採番 | BDI ナンバー を新規付番 (1 筐体 1 番) |
| 記載項目 | 納入先名、装置仕様 (オプション内訳)、客先要求、完成予定日、出荷予定日 |
| 一次回付先 | 山本さん (技術 = 設計兼 BOM オーナー) |
| 二次回付先 | 永井さん (調達)、製造リーダー、品証 |
| 改訂 | 仕様追加・延長ホッパー等のカスタム品確定タイミングで追記 (§4 都度発注品の連動) |
3.2 業務指示書のドメイン位置付け
- 業務指示書は受注 (SalesOrder) と製造指示 (ProductionInstruction) の橋渡しとなる アグリゲートのライフサイクル開始イベント として扱う。
- 起票者は社長権限であり、後続の BOM 展開・発注の前提条件となる。承認ワークフローはこの時点で「社長 = 起票者 = 承認者」として 1 段階に縮約される。
- 業務指示書 = WorkInstruction (Aggregate) は BDI ナンバーを集約 ID として保持し、関連する受注明細 / 機種コード / オプション仕様 / 製造指示 / 出荷記録を子エンティティとして束ねる。
新システムでの実装方針: 大野社長が業務指示書を起票するまで BOM 展開・発注は実行不可とする。業務指示書には機種コードとオプションコードを構造化フィールドとして持たせ、フリーテキストの仕様欄も残す。延長ホッパー等のカスタム品が後追いで確定した場合は 改訂 (Revision) として履歴を残し、製造工程に乗ったタイミングで都度発注品マスタへ昇格させる (§4 参照)。
4. 部品分類 3 階層 (標準 / 準標準 / 都度発注) と発注計画への影響
クリエイト・エンジニアリングは部品を 3 階層 で分類し、それぞれに異なる発注計画ポリシーを適用する。これは部品マスタの一級属性として保持し、発注画面の自動判定ロジックに直結させる。
4.1 分類定義
| 分類コード | 名称 | 定義 | 対象例 |
|---|---|---|---|
standard | 標準 | どの機種でも使う、または旗艦機 (130F) で使う部品 | 主要シャフト、共通フレーム部材、共通アクチュエータ |
semi-standard | 準標準 | コンベア系オプション等、年間 30〜40 台程度の流動量がある部品 | コンベア延長部材、特定オプション専用ユニット |
on-demand | 都度発注 | 客先別カスタム品、受注確定でマスタ登録 = 発注 | 延長ホッパー、客先仕様の特注治具 |
4.2 発注計画への影響
- 標準 (
standard): 安全在庫を持ち、リードタイム実動 15 日 をベースに棚卸点で自動補充。GW・需要シーズンを考慮した感覚調整は永井さんの裁量で実施。 - 準標準 (
semi-standard): 年間流動量を見ながらロット最適化 (例: 5 個発注を 15 個に増やすと単価が下がる) を人手で判定。発注ロット × 単価ステップ表をマスタに保持して半自動化したい。 - 都度発注 (
on-demand): 受注確定 (業務指示書発行) のタイミングでマスタ登録 = 発注となる。延長ホッパーなどは業務指示書回付 → 製造工程に乗ったタイミングで形式が確定 → そのタイミングで都度発注品としてシステム登録される。
4.3 安全在庫・ロット最適化の運用
- 標準品の安全在庫はテックスの棚マスタ + 引き当て数量で運用。新システムではこれを引き継ぎつつ、リードタイム 15 日と年間流動量から 再発注点 (ROP) を自動算出する要件あり。
- ロット縛り (例: 5 個 → 15 個で単価 × 0.85) を部品マスタに「ロット階段」として持たせ、発注画面で年間予測流動量と突き合わせて推奨ロットを表示する。
新システムでの実装方針:
Part.partsCategory: 'standard' | 'semi-standard' | 'on-demand'を共通ドメイン (Phase 2 でdocs/ddd/pms/03-aggregates/procurement.mdに追記予定) に持ち、テナント設定 (tenant-config.yamlのclassifications.partsCategory) で表示名・運用パラメータを上書き可能とする。
5. 連動部品 (セット交換) のマスタ要件
「これを替えるならこれとこれもセットで交換」という 連動部品 (Linked Parts Set) の関係は、現状すべて山本さんの暗黙知として保持されている。クリエイト・エンジニアリングの新システム要件として、これを部品マスタの構造化データに落とし込むことが必須である。
5.1 連動部品の関係種別
| 関係種別 | 説明 | 例 |
|---|---|---|
| 必須セット | 部品 A を交換するなら部品 B も必須交換 | シール部品とそのリテーナ |
| 推奨セット | 部品 A を交換する際に部品 B も同時交換が推奨される (摩耗連動) | 主軸ベアリングと当該シャフト |
| 世代依存 | 世代 X では部品 A、世代 Y では部品 A' に置換 | I シリーズと G シリーズで径が異なるシャフト |
5.2 マスタへの要求事項
- 部品マスタの関係エンティティ として
PartLink(仮称) を持たせ、fromPartId / toPartId / linkType ('mandatory' | 'recommended' | 'generation-dependent') / generationCode (任意)を保持する。 - 修理見積 (§7) 時に部品 A を選択した瞬間、関連部品 B/C が候補として自動提示されることを要件とする。
- 連動セットは 山本さんからのナレッジ移管 として段階的に登録する (登録ガバナンスは設計者ロールに付与)。
5.3 業務上の制約
- 連動部品の判定は世代差 (§9) と密に結合する。例えば I シリーズの部品 A を選ぶと連動部品 B は I シリーズ用が候補に出る、という二段制約。
- 新規受注時には連動部品判定は不要 (機種マスタの標準 BOM がすべて先に展開されるため)、修理・部品交換時のみ必要となる。
新システムでの実装方針:
LinkedPartsSetを部品マスタ (Part) の関連エンティティとして実装し、世代コード (generationCode) と組み合わせて修理見積画面の候補提示エンジンに渡す。Phase 2 で共通アグリゲートproduct-catalog.mdに「Linked Parts Set」節として正式定義する予定。
6. 据付・試運転原価 (Installation & Commissioning Costing)
据付・試運転は新設機の出荷後に発生する 独立工程 であり、現地での部品代 + 人件費 + 交通費を別管理する。クリエイト・エンジニアリング固有の単価体系を以下に明記する。
6.1 単価表
| 費目 | 原価単価 | 客先単価 | 単位 | 備考 |
|---|---|---|---|---|
| 車両費 | 30,000 円 / 日 | (距離・高速料金は別途実費) | 1 日 | 出張地ごと (横浜 / 福岡など) に粗かったため、2026 年 4 月から距離ベースで細分化 |
| 人工費 | 3,500 円 | 6,500 円 | 1 人工 | 原価 (社内コスト) と客先請求単価を分離 |
| 交通費 (高速・宿泊) | 実費 | 実費 | — | 事業所からの距離・宿泊有無で算出 |
6.2 原価計算ロジック
- 据付見積は 移動時間 + 現地作業時間 (人工) + 車両費 (日数 × 30,000 円) + 高速・宿泊実費 で組み立てる。
- 原価人工 3,500 円 / 客先単価 6,500 円の差額 (3,000 円 / 人工) が据付の粗利源となる。
- 2026 年 4 月以降は事業所所在地から納入先までの距離ベースで車両費・宿泊費を細分計算する方針。新システムでは 距離マスタ + 距離 × 単価 のテーブル駆動を要件とする。
6.3 売上根拠
- 据付・試運転の完了時には 終了書 に客先サインを取得し、写真を添付して売上計上の根拠とする。
- 新システムでは Installation アグリゲートに
signedCompletionDocument、evidencePhotosを持たせ、売上計上のゲートとする。
新システムでの実装方針: 据付・試運転は
Installation/Commissioningアグリゲートとして独立させ、車両単価 (vehicleDailyRate: 30000)・人工原価単価 (laborCostRate: 3500)・人工客先単価 (laborBillingRate: 6500) をテナント設定 (tenant-config.yaml) に持たせる。Phase 2 で共通ドメインdocs/ddd/pms/03-aggregates/production.mdおよびdocs/ddd/pms/03-aggregates/cost-analysis.mdに追記予定。
7. 修理フロー (写真 → 形式特定 → BOM 逆引き)
修理・部品交換はクリエイト・エンジニアリングの主要収益源の一つで、新設機とは独立した修理サービス境界 を持つ。現状は山本さん属人化が極端に強く、システム化の最重要要件の一つ。
7.1 フロー
[1] 客先からの依頼
└─ 「これちょうだい」と写真添付メールが届く
↓
[2] 形式・世代特定 (現状: 山本さんが目視判定)
└─ I/G シリーズ等の世代差を判別 (§9)
↓
[3] BOM 逆引き (現状: テックス + 山本さんの記憶)
└─ 該当世代の BOM から候補部品を特定
連動部品 (§5) も同時に提示
↓
[4] 時価で見積もり (現状: Excel)
└─ 半年前の単価のまま反映されない問題あり (§2 課題)
↓
[5] 受注 → 業務指示書起票 (修理用) ← §3 と同フロー
↓
[6] 部品発注 → 出荷 → 据付 (必要時) ← §2 / §6
7.2 システム化の要件
- 写真添付フォーム: 客先からの写真をそのまま受付 (将来要件: AI による形式判定の補助)。
- 世代特定支援: BDI ナンバー (現地の銘板) を入力すると過去製造履歴から該当世代・形式が自動特定される。
- BOM 逆引き検索: 世代コード + 部位 (例: ホッパー、シャフト) の組み合わせで候補部品リストを返す。
- 連動部品の自動提示: §5 の連動部品マスタに基づき、選択部品の関連部品を候補表示する。
- 時価反映: 部品マスタの単価更新を発注実績から半自動で取り込み、修理見積に最新単価を反映する。
7.3 制約
- メーカー直の購買は不可、必ず商社経由 (§8 /
vendorTier制約)。 - 世代違いの部品を取り違えると現地で組み付け不可となるため、世代特定の精度 が修理品質に直結する。
新システムでの実装方針:
RepairRequestをサービス境界として定義し、写真添付・BDI ナンバー紐付け・世代特定・BOM 逆引きの 4 機能を一連のワークフローとして実装する。Phase 2 では共通ドキュメント化の対象外 (将来要件)、Phase 3 以降で個別アグリゲート化を検討する。
8. テックス連携の切り出し範囲
現行基幹のテックス (TechS) は契約があと 1 年残っており、高い更新費を払って製品マスタ (BOM) を整備済みである。新システムへ全面置換するのではなく、機能を切り出して連携 する方針を採る。
8.1 残す機能 (テックス側)
| 機能 | 残置理由 |
|---|---|
| BOM 展開・引き当て | 製品マスタ (BOM) のデータが直近で大規模更新済み。再構築コストが大きい |
| 棚マスタ・棚位置管理 | 物理棚 (例: 16-3) と紐づき、現場運用がテックスを前提に組まれている |
| バーコード受入・在庫減算 | アプリ屋アプリのバーコードシール発行と統合運用されている |
8.2 新システムへ移す機能
| 機能 | 移行理由 |
|---|---|
| 見積 (Excel 完全脱却) | 製品マスタ未連携・原価単価ラグ・属人化 (栗田さん遺産) を解消 |
| 原価管理 (案件原価・物件別原価) | 現状ほぼ集計されておらず、台数按分の粗い計算しか出来ていない |
| 工数管理 | 携帯バーコード打刻が機能しておらず、ほぼ未実施 |
| 納品書・請求書発行 | 現状 Excel で外部作成・郵送/メール。テックスを使わずに行っているため移行容易 |
| 販売管理 (受注〜請求〜入金) | テックス外で運用されており、新システムが第一級の責務として持つ |
| 発注の自動化 | 現状はテックスで半自動 (画面操作必要)。新システムから発注リクエストを発行し、テックスは BOM 引き当て・在庫照会のみ実行する形に切り替え |
8.3 連携アーキテクチャ
- テックス → 新システム: BOM データ・部品マスタ・棚マスタ・在庫数量をマスタデータとして同期 (CSV / API)。
- 新システム → テックス: 受注確定時に製番起票要求、発注時に発注明細を渡し、入荷時に受入結果を取り込む。
- アプリ屋アプリ: バーコードラベル発行用ツール。テックスから CSV を出力して使用しており、当面は現状維持。
8.4 サブシステム連携 (関連)
| 連携先 | 内容 |
|---|---|
| CAD (図面サーバー) | 図面 PDF を BOM に紐づけたい (現状未連携。図面番号でフォルダ命名のみ) |
| Eight (名刺アプリ) | CSV ダウンロード → 1 時間ごとに営業ツールに投入 |
| 会計ソフト | 連結会計の数字を出して銀行融資に提出する要件あり |
| 営業ツール (アネブル名刺由来 CRM) | 年内導入予定 |
新システムでの実装方針: テックスを 境界づけられたコンテキスト (Bounded Context) として扱い、
docs/ddd/pms/02-context-map.md上で「BOM/在庫サブシステム」として明示する (Phase 2 で追記予定)。データ同期は当面 CSV ベース、将来的に API 化を検討。
9. 部品マスタリビジョン要件 (世代差 — I/G シリーズ等)
クリエイト・エンジニアリングは 4 世代 (I シリーズ 〜 G シリーズ) のバージョン履歴を保有しており、形式によって部材・シャフト径まで変わる。修理・部品交換の品質はこの世代特定の精度に直結するため、部品マスタは 時系列リビジョン を一級概念として保持する必要がある。
9.1 世代の定義
| 世代コード | シリーズ名 (例) | 特徴 |
|---|---|---|
I | I シリーズ | 最古世代 |
| (中間世代) | (要確認) | 部材・シャフト径が段階的に変化 |
| (中間世代) | (要確認) | 同上 |
G | G シリーズ | 最新世代 |
未確定項目 (要確認): 4 世代の正式名称・年代区分・代表機種。所見では「I 〜 G シリーズの 4 世代」とのみ記述されており、中間 2 世代の名称は本ファイルでは保留する。
9.2 リビジョン管理の要求事項
- 機種マスタ (EquipmentCatalog) に
generationCode属性を持たせ、世代ごとに 標準 BOM の差分 を保持する。 - 部品マスタ (Part) に
applicableGenerations: GenerationCode[]を持たせ、どの世代で使われる/使われないかを宣言的に表現する。 - 世代間で互換性のある同等品 (例: 形状違いだが機能等価) は 同等品マッピング (
equivalentParts関係) として保持する。 - 新規受注時の機種選択画面では、世代コードを必須選択項目とし、選択世代に対応する標準 BOM のみを展開する。
9.3 修理時の世代制約
- 修理見積 (§7) では BDI ナンバー → 製造履歴 → 製造時世代 を自動引き当てる。
- 世代違いの部品を提示しないよう、部品候補は当該 BDI の世代に限定 する (
Part.applicableGenerationsで絞り込み)。 - 連動部品 (§5) は世代依存型 (
generation-dependentlinkType) を持ち、世代をまたぐと別部品にマッピングされる。
9.4 マスタ運用ガバナンス
- 世代追加 (新シリーズリリース) は 山本さん主導 で機種マスタにリビジョンとして登録される (現状の運用を継承)。
- 部品マスタへの世代差反映は 山本さん → 永井さん の二段ハンドオフ (現状)。新システムでも同ハンドオフを承認フローとして明示する。
新システムでの実装方針:
Generationを値オブジェクト (Value Object) としてdocs/ddd/pms/06-value-objects.mdに追記予定 (Phase 2)。EquipmentCatalogは世代別にBomRevisionをネストして持ち、修理時の同等品マッピングはPart.equivalentPartsで表現する。
関連ドキュメント
- 生データ SSOT:
docs/ddd/pms/instances/create-engineering/interview-findings.md - 設定値ファイル (構造化):
docs/ddd/pms/instances/create-engineering/tenant-config.yaml(Phase 1.6 で作成予定) - 比較対象テナント:
docs/ddd/pms/instances/tamari/configuration.md - 共通 DDD ドキュメント (Phase 2 で拡張予定):
docs/ddd/pms/03-aggregates/procurement.md(部品分類 3 階層・ベンダー階層)docs/ddd/pms/03-aggregates/product-catalog.md(機種マスタ・世代・連動部品 — 新設予定)docs/ddd/pms/03-aggregates/production.md(据付・試運転)docs/ddd/pms/03-aggregates/cost-analysis.md(据付・試運転原価)docs/ddd/pms/02-context-map.md(テックス連携境界)docs/ddd/pms/06-value-objects.md(BdiNumber,GenerationCode)