Fab Forward Dev/

DDD ドキュメント

world-system

PMS Instance

ワールドシステム テナント設定 / World System — Tenant Configuration

目的: 汎用 DDD モデルをワールドシステムの業務に適用するためのテナント固有設定。 本ドキュメントは DDD モデル (docs/ddd/) の「インスタンス」であり、業務フローの特殊性・運用ルール・ 将来要件などワールドシステム固有の業務ロジックを定義する。

出典: docs/ddd/pms/instances/world-system/interview-findings.md (2026-04-28 インタビュー所見)

業種: 装置メーカー寄りのエンジニアリング受注生産 (案件主導の一品設計・製造) 規模 (体制): 営業 4 名 / 調達 1 名 / 総務 3 名 + 設計・製造 (組立・電装・ロボットティーチング) の少人数体制。ソフトウェア担当 1 名のキャパ制約あり。 主キー: 交番 (こうばん) 番号 (例: WYM-1019)。案件・見積・発注・原価・図面ファイル名・フォルダ名すべてに同一番号を用いる。見積番号 = 交番番号。 現行システム: Excel + 共有フォルダ が中核。過去にテクノワ系生産管理パッケージを導入したが定着せず。請求書発行ソフト「まちがな (?)」系および会計ソフト (弥生系ではない) と並走。 グループ: クリエイト・エンジニアリング、板倉、高橋、アイサン等。連結会計を銀行に約束済み。


1. 区分マスタ設定 (Classification Values)

ワールドシステムは現状コード体系 (区分マスタ) を持たない Excel 運用のため、新システム導入時に下記カテゴリで区分マスタを起票する必要がある。具体的なコード値・名称は本書のスコープ外であり、Phase 2 以降の設計で確定する。

1.1 単位区分 — UnitOfMeasure

1.2 入金方法 — PaymentMethod: Receipt

1.3 支払方法 — PaymentMethod: Supplier

1.4 費目区分 — ExpenseCategory

ワールドシステムは案件主導の一品受注生産であり、費目は概ね下記の業務カテゴリに対応するが、コード化されていない。

  • 鋼材・部品製作品 (材料)
  • 購入品 (商社経由のメーカー部品)
  • 外注費 (機械加工・電装)
  • 塗装・表面処理
  • 運搬・据付・現地作業
  • 赤伝交番経由の販管費 (サービス費) — 不具合対応で発生する費用は製造原価ではなく販管費に振替計上する (§9.3 参照)。

1.5 見積費目区分 — QuotationCostItem

1.6 社内工程区分 — InternalProcessCategory

製造工程は 組立 / 電気運転 / ロボットティーチング / 最終調整 に分かれ、最終調整できる人材が限られる (スキル制約)。営業・設計・総務は間接工数として別カテゴリ。

1.7 製作工程区分

1.8 手配品区分 — ProcurementItemType

購入品マスタには下記属性を Excel で持っている。

  • 品名
  • 品名・型式
  • メーカー (製造メーカー)
  • 数量
  • 発注先 (商社、メーカーとは別) — 商社経由が前提
  • 予備品フラグ
  • 客先支給フラグ

1.9 仕入先区分 — SupplierClassification

ベンダー階層として メーカー (製造) と 商社 (発注先) の分離 が必須。商社経由でないとメーカー直は買えない取引慣行あり。

1.10 注文書出力方法 — POOutputMethod

現状は 注文書を発行せず、図面 PDF を伝票代わりに同梱する運用が主流。発注メールは人手で PDF を添付。新システムではメール送付を標準化する想定。

1.11 売上先区分

1.12 請求書タイミング

1.13 納品書出力区分


2. ステータスマッピング (Status Mappings)

ワールドシステムは現状ステータス管理を Excel の色塗りで運用しているため、レガシーコードは存在しない。新システムで採用するステータス値をここで定義する。

2.1 見積ステータス — QuotationStatus

見積は同一交番番号配下で Excel シート 1 / 2 として改訂を保持。「初付け / 2付け」と並べる運用。

2.2 手配ステータス — ProcurementStatus

承認 NG → 突き返し → 交渉 → 再承認のループが標準フロー (§9.1)。差戻し回数・コメントの保持要件あり。

2.3 工事ステータス — OrderStatus

売上計上後は 同交番への発注ロック (§9.2)。completed_billed 相当の状態で「ロック中」フラグが立つイメージ。

2.4 製作指示ステータス — ProductionStatus

2.5 注文書ステータス

2.6 社内外区分 — InternalExternal

少人数体制のため社内製作の比率は限定的。ロボットティーチング・電気運転は社内工程だが、加工・塗装は外注比率が高い想定。

2.7 手配品種別 — ProcurementRouting

2.8 単価区分 — PriceType

発注時点で原価が立つ運用 にしたい (現状は受入後)。新システムでは「発注原価」と「納品原価」を二段で管理する要件あり。

2.9 端数処理 — RoundingPolicy

2.10 請求計算区分 — BillingCalculationMethod

2.11 支払月区分 — PaymentTiming

2.12 締日区分

2.13 権限レベル — PermissionLevel


3. 採番ルール (Document Numbering)

ワールドシステムでは 交番番号 がほぼ全業務文書の主キーとなる。見積番号 = 交番番号 = フォルダ名 = 図面 PDF ファイル名。

番号種別形式例同一性 / 関連
交番番号WYM-1019案件・見積・発注・原価集計の主キー。引き合い段階で採番。
見積番号(交番と同一)同じ交番番号を使用。改訂は Excel シート 1 / 2 で表現。
ユニット番号10-001 台の機械内の組立単位。図面・部品表の親キー。
図面番号(発注リスト行番号と一致)交番フォルダ内の PDF。図面番号 = 発注リストの行番号。
枝番交番 (連番交番)(交番 + 連番)売上計上後の追加発注用 (§9.2)。
赤伝交番(新規交番として起票)不具合対応 (§9.3)。元交番との関連線を保持。販管費計上。

4. 権限・ロール構成 (Authorization)

4.1 ロール一覧

ワールドシステムの主要ペルソナは以下 (interview-findings §3 参照)。

ロール主な責務
営業案件取り、見積、購買依頼書発行、日程表作成、発注承認 (最終承認者)、請求承認
調達 / 購買3 社相見積もり、価格交渉、発注、入荷チェック、在庫の判定、余材→在庫交番の振替判断
設計受注後にユニット品番 + 名称 + ユニット番号を割り付け、製作リスト + 購入品リスト作成
製造 (組立)ユニット単位の組立。最終調整は属人スキル制約あり
製造 (電気運転 / ロボットティーチング)配線・PLC 制御・ティーチング作業
検査立ち会い検査担当 (客先立会い前提)
総務 (経理)工数集計、請求書発行、支払処理
社長一括請求書突合後の最終承認 (振込承認)

特記: 発注承認の最終権限は 営業担当 にある。これは購買責任者承認を前提とする一般的な PMS パターンと異なるワールドシステム固有のルール (§9.1)。

4.2 画面アクセスマトリクス


5. 帳票マッピング (Report Templates)

ワールドシステムの現行帳票は Excel シートが中心であり、フォーマット標準化が進んでいない。下記は新システム化対象の主要帳票候補。

帳票名現状Domain Entity (想定)
見積書Excel シート (シート 1 / 2 で改訂)Quotation
購買依頼書営業が発行、調達 + 設計に同報メールPurchaseRequest
製作リスト設計が機械図面フォルダに配置 (Excel)ProductionInstruction (BOM)
購入品リスト設計が機械図面フォルダに配置 (Excel)Procurement (BOM)
注文書現状発行せず (図面 PDF を伝票代わりに同梱)PurchaseOrder
個別交番日程表個別交番ごとの色付き Excel(Project Schedule)
立ち会い検査票客先ごとの定型なしInspectionRecord
調達決定 (交番台帳)全交番を連番管理する Excel。受注 / 未受注を色塗り(Project Ledger)
請求書「まちがな (?)」系の請求書発行ソフトInvoice

6. メール通知設定

下記タイミングでメール通知が発生している。

  • 購買依頼書発行時 (営業 → 調達 + 設計に同報): 案件・客先・納期を通知。
  • 発注時 (購買 → 仕入先): 図面 PDF を人手で添付。
  • 請求書送付時 (経理 → 客先): 「まちがな (?)」系ソフト経由。

7. 主要仕入先 (Preferred Suppliers)

ワールドシステムは 商社経由 が前提。代表的な商社・メーカーは以下が言及された。

区分名称備考
商社 (工作機械)マザック大手ユーザー (例: サントリー) 向け案件の経由商社
商社 (オンライン購買)ミスミAPI 連携によるオンライン見積取得を要件化 (§9.9)

商社経由でないとメーカー直は買えない取引慣行があり、メーカー (製造) と発注先 (商社) は仕入先マスタ上で分離して保持する必要がある。


8. 定型コメント (Preset Comments)


9. ワールドシステム固有の業務パターン

ここから先がワールドシステムのインタビューから判明した 業務上の特殊性 であり、新システム設計上の中核要件となる。

9.1 発注承認権者 = 営業担当 (差戻しループ)

ワールドシステムでは 発注承認の最終権限が営業担当 にある。一般的な PMS では購買責任者または部長が承認するが、ワールドシステムは案件 (交番) を取った営業担当者が原価責任を持つ構造のため、発注書の最終 OK / NG を営業が判定する。

承認フロー:

  1. 調達が 3 社相見積もり → 価格交渉 → 発注申請。
  2. 営業担当が承認判定。
  3. NG の場合は購買を突き返し、調達が再交渉 → 再申請。
  4. OK で発注確定。

このループは状態だけでなく 差戻し回数・コメント を保持する必要がある (Approval Workflow with Send-back パターン、interview-findings §3.4)。

9.2 売上計上後の交番ロック + 枝番交番

売上を計上した瞬間にその交番への新規発注はロック される。追加コストが必要になった場合は、元交番に紐づけた 枝番 (連番) 交番 を新規起票する。これは原価集計を「完成品」と「アドオン」で明確に分離し、月次原価表を確定可能にするための運用ルール。

ドメイン的には:

  • 親交番: 売上計上 → ロック状態 → 以降の発注は受け付けない。
  • 枝番交番: 親交番との関連線を持つ独立アグリゲート (Sub-order)。原価集計は親と分離。

9.3 赤伝交番 → 販管費 (サービス費) 振替

不具合対応 (出荷後の故障対応・無償修理等) は 赤伝の交番 を新規発行し、締めた元交番には載せない。会計上は 製造原価ではなく販管費 (サービス費) に振替 計上する。

ドメイン的には:

  • 赤伝交番 = ServiceOrder アグリゲート。元交番との関連線を保持。
  • 発生する原価 (部品・工数・出張費) は通常通り集計するが、勘定科目は 販管費 (サービス費) に振替。
  • 会計連携の境界コンテキスト (Bookkeeping Bridge) で勘定切替を表現する (interview-findings §3.4)。

9.4 立ち会い検査必須

客先ごとの定型検査票は無いが、客先側の立ち会い検査が必須 で出荷の前提条件となる。立ち会い検査担当が検査記録を作成し、客先サインを得てから出荷工程に進む。

9.5 在庫の 3 パターン運用

ワールドシステムには 在庫管理システムが無い。物理的な棚はあるが、棚に置かれている物は下記 3 パターンに分かれており、いずれも「原価から在庫に振り替える」会計処理が現状未実施。

パターン内容由来振替判断
① 大量発注分ロット単価メリットを取るため必要数より多めに発注した残り発注時の単価交渉調達が「在庫交番」へ振替 (要件)
② 余材案件で使い切らなかった材料・部品設計余裕・歩留まり調達が「在庫交番」へ振替 (要件)
③ 客先支給客先から支給された部品・材料客先の指定品物理保管のみ。原価には乗せない

新システムでは 「在庫交番」(交番付き在庫アグリゲート) への振替 をドメインイベント化し、原価から在庫への仕訳を自動生成する要件 (Inventory Reservation パターン、interview-findings §3.4)。

9.6 図面・ファイルシステム連携 (設備フォルダ階層)

ワールドシステムは全資料を共有フォルダ上で 設備フォルダ階層 に従って整理する。

設備関係 / 機械図面 / <客先> / <案件 (交番)> / ...
  • 引き合い段階で設備フォルダ配下に商社 / 客先 / 案件のフォルダを作成。
  • 引き合いのみで終わったものは「相談のみ」フォルダに移動。
  • 図面 PDF は交番フォルダ内に格納。図面番号 = 発注リストの行番号 と一致する命名。
  • 発注メール送付時には人手で PDF を添付している。

新システムでは このフォルダ階層を一級市民として持つ 要件があり、ファイルシステム連携 (または OCR / メタデータ抽出による DB 取り込み) が必要 (Engineering Document Library パターン、interview-findings §3.4)。

9.7 工数 30 分単位の案分ルール

工数管理は作業者の 手書き日報 を総務が Excel に手入力して交番ごとの原価表に展開している。重要な運用ルール:

  • 入力単位は 30 分
  • 複数交番を同時並行で作業した場合は時間を案分 し、片方に寄せず両方の交番に時間を入力する。

新システムではスマホ勤怠アプリ、またはタイムカード位置に QR コード読取端末を置く案が要件として挙がっている (§9.9)。

9.8 発注時点での原価二段管理

現状は仕入先からの請求書到着 (受入後 1 ヶ月遅れ) で初めて原価が判明し、予算超過に気付けない。新システムでは 発注した時点で原価が立つ 運用に変更し、以下の二段で原価を管理する。

段階原価タイミング
発注原価発注確定時の単価 × 数量PO 発行時 (即時に予算消化)
納品原価納品時の確定単価 (請求書ベース)入荷検収後

差額は別途「価格差異」として把握する想定。

9.9 将来要件 (新システム化スコープ)

下記はインタビューで言及された将来要件。Phase 2 以降の DDD 共通ドキュメントへの昇格・実装スコープ判定の対象。

9.9.1 大日程表 (Capacity Calendar)

全交番横断のリソース負荷ビュー。突発挿入時に自動再描画。現状は交番ごとの個別 Excel しかなく、全体の負荷が見えない。

9.9.2 スキルマップ (Skill Matrix)

ロボットティーチング・電気運転・PLC・最終調整など、作業者×スキルのマトリクス。同時進行可能本数の制約計算に使う。最終調整できる人材が限られるという属人性をシステム化する。

9.9.3 オンライン購買サイト連携 (ミスミ等)

API 連携で 自動見積取得 を行う。ただし価格交渉余地があるため 自動発注は不可、必ず人手の介在が要る

9.9.4 AI 図面検索 (キャディ風)

過去 PDF を全部 OCR → キーワード化し、「ストッパーユニット」等のキーワードで類似図面を呼び出せる検索。過去案件流用の属人化を解消する目的。

9.9.5 メール解析 AI

全社メールを解析してタスク・スケジュールに自動振分し、ナレッジを Wiki 化。

9.9.6 スマホ / QR による工数入力

タイムカード位置に QR コード読取端末を置く案、またはスマホ勤怠 / 工数アプリ。30 分単位案分ルール (§9.7) を維持しつつ手書き日報を廃止する。

9.9.7 銀行への支払リスト送信自動化

経理 → 社長承認 → 振込フローの最終出力 (銀行向け振込データ) を自動化したい。

9.9.8 AI サービス併用方針

Anthropic を基本に、コスト 1/10 の中国製を併用。機密度で振り分ける ポリシーが既に運用方針として存在。