株式会社etika ｜ 要件定義書（図解版）
美濃焼産地で商品企画 → メーカーへの生産手配 → 梱包・物流（BtoB卸）を担うメイクス様。現在は販売・在庫管理に FLAM を利用し、受注はメール、メーカー発注はFAX、会計ソフトは未導入。アナログ・Excel依存と商品マスターの二重管理が中心課題です。
採用プラットフォームは Zoho CRM（カスタマイズ）。在庫管理は本フェーズでは専用モジュールを設けず、商品（Products）のカスタム項目＋Deluge関数で実現します。
受注を起点に、商流（モノ）と金流（カネ）が枝分かれします。詳細は次節②（入出金）・③（在庫）で個別に解説します。
登場者は 得意先・メイクス様（Zoho CRM）・仕入先メーカー の3者。誰が・何を・どのモジュールで行うかを時系列で示します。自動はDeluge等による自動処理、手動は人手の入力です。
在庫は専用モジュールを持たず、商品（Products）のカスタム項目で保持し、取引イベントに連動して Deluge関数で自動増減します。対象は「在庫管理対象」フラグを立てた定番商品のみ（OEM・都度手配品は対象外）。
受注 → 発注 → 入庫 → 出荷 が一直線に進む標準ケース。
| イベント | 実在庫 | 引当済 | 有効在庫 | 発注残 | 説明 |
|---|---|---|---|---|---|
| 期首 | 10 | 0 | 10 | 0 | 初期状態 |
| 受注 6個（引当） | 10 | 6 | 4 | 0 | 引当済＋6 → 有効在庫が10→4に |
| 発注 20個 | 10 | 6 | 4 | 20 | 発注残＋20（入荷予定の可視化・任意） |
| 入庫 20個 | 30 | 6 | 24 | 0 | 実在庫＋20／発注残−20 → 有効在庫24 |
| 出荷 6個（消込） | 24 | 0 | 24 | 0 | 実在庫−6／引当済−6 → 有効在庫は不変 |
引当が在庫を超える（品薄）→補充発注→分納（一部出荷）→数量変更→発注点アラートの発火・解除まで含む実務ケース。⚠️＝発注点を下回りアラート発火中。
| イベント | 実在庫 | 引当済 | 有効在庫 | 発注残 | 出荷残 | 状態・説明 |
|---|---|---|---|---|---|---|
| 期首 | 8 | 0 | 8 | 0 | 0 | 初期状態（発注点5） |
| 受注 10個（引当） | 8 | 10 | −2 ⚠️ | 0 | 10 | 引当が実在庫超＝品薄。有効在庫マイナスで補充要と判明 |
| 発注 20個 | 8 | 10 | −2 ⚠️ | 20 | 10 | 仕入先へ補充発注 → 発注残＋20 |
| 入庫 20個 | 28 | 10 | 18 | 0 | 10 | 実在庫＋20／発注残−20 → 有効在庫が回復 |
| 出荷 4個（分納①） | 24 | 6 | 18 | 0 | 6 | 一部出荷。実在庫−4／引当済−4。出荷残6が残り受注は「一部出荷」 |
| 出荷 6個（分納②・完了） | 18 | 0 | 18 | 0 | 0 | 残り出荷で受注「完了」。有効在庫は分納でも不変 |
| 別受注 14個（引当） | 18 | 14 | 4 ⚠️ | 0 | 14 | 有効在庫4 < 発注点5 → 発注点アラート発火 |
| 数量変更 14→10個 | 18 | 10 | 8 | 0 | 10 | 引当済を4戻す → 有効在庫8（≥5）でアラート解除 |
本フェーズで構築するタブ／モジュールは13。在庫は専用モジュールを持たず商品（Products）のカスタム項目で保持し、入庫・出庫・入金・出金予定・出金はそれぞれ独立カスタムモジュールとして親伝票の関連リストに置きます。支払は売り側（請求書→入金）と対称に、買い側を出金予定（買掛）→ 出金（支払実績）の2層で構成します。
| # | 業務概念 | Zohoモジュール | 区分 | 主な保持項目 |
|---|---|---|---|---|
| 1 | 見込み客 | Leads | 標準 | 名刺情報、流入元（将来のマーケ基盤） |
| 2 | 取引先 | Accounts | 標準 | 区分（得意先／仕入先）、締め区分／締め日、納品先（複数） |
| 3 | 連絡先 | Contacts | 標準 | 担当者情報 |
| 4 | 商品マスター | Products | 標準＋カスタム | 販売名／仕入名、仕入先、仕入単価、標準販売単価、品番、カテゴリ、在庫項目（実在庫・引当済・有効・発注残・発注点・在庫管理対象） |
| 5 | 価格バリエーション | Price Books | 標準 | 規格・色・サイズ別単価 |
| 6 | 受注 | Sales Orders | 標準 | 受注明細サブフォーム（受注数・出荷数累計・出荷残・行ステータス）、出荷ステータス、納品予定日 |
| 7 | 発注 | Purchase Orders | 標準 | 仕入先別の発注明細サブフォーム（発注数・入庫数累計・入荷残・行ステータス）、入庫ステータス、リードタイム |
| 8 | 請求 | Invoices | 標準 | 締め単位で自動集計 |
| 9 | 入庫 | 入庫（カスタム） | カスタム | 発注書の関連リスト。分納1回＝1レコード（入庫日・数量・商品）。発注明細の入庫数累計・入荷残をロールアップ更新し、実在庫加算・発注残減算のトリガー |
| 10 | 出庫 | 出庫（カスタム） | カスタム | 受注書の関連リスト。分納1回＝1レコード（出荷日・数量・商品）。受注明細の出荷数累計・出荷残をロールアップ更新し、実在庫減算・引当消込のトリガー |
| 11 | 入金 | 入金（カスタム） | カスタム | 請求書／取引先の関連リスト。入金1回＝1レコード（入金日・金額）。請求書を消し込み（分割入金対応） |
| 12 | 出金予定（買掛） | 出金予定（カスタム） | カスタム | 仕入先の関連リスト。締め支払で入庫実績（入荷分）を集計した支払予定。予定額・支払済額・残額・ステータス |
| 13 | 出金（支払実績） | 出金（カスタム） | カスタム | 出金予定の関連リスト。支払1回＝1レコード（支払日・金額）。出金予定を消し込み（分割払い対応） |
各モジュールのつながり（ルックアップ／関連リスト）を図示します。1 ──< 多 は「1件の親に複数の子がぶら下がる（1対多）」、多 >──< 多 は「多対多」を表します。色は ■標準 / ■標準＋カスタム項目 / ■カスタムモジュール。
― マスター層 ―
― 取引層（商流） ―
― 入出庫・入出金層（カスタムモジュール／関連リスト） ―
優先度：必須 中 低
| ID | 要件 | 優先度 |
|---|---|---|
| F-M1 | 商品マスター一元化。1商品に販売名／仕入名／仕入先／仕入単価／標準販売単価を保持 | 必須 |
| F-M2 | 色・サイズ・規格違いを価格表（バリエーション）または個別商品で管理 | 必須 |
| F-M3 | 商品の検索性向上（品番・商品名の一部・仕入先・カテゴリ等） | 必須 |
| F-M4 | 取引先マスター。得意先に締め区分、仕入先に締め日を保持 | 必須 |
| F-M5 | 得意先に紐づく納品先（倉庫・発送先）を複数保持 | 中 |
| F-M6 | 商品画像のアップロード | 低 |
| ID | 要件 | 優先度 |
|---|---|---|
| F-T1 | 受注伝票の起票（数量・単価・合計の自動計算） | 必須 |
| F-T2 | 受注からの発注書（仕入先別）下書き自動生成 | 必須 |
| F-T3 | 発注書の帳票出力（メーカー送付用PDF） | 必須 |
| F-T4 | 入庫処理と入荷残の可視化 | 必須 |
| F-T5 | 出荷処理・分納対応と出荷残の可視化 | 必須 |
| F-T6 | 入庫／出荷の完了に応じた発注・受注ステータス自動更新 | 必須 |
| F-T7 | 1取引先に複数の受注・発注・請求を紐付けて履歴管理 | 中 |
| ID | 要件 | 優先度 |
|---|---|---|
| F-S1 | 商品マスターに在庫カスタム項目（実在庫／引当済／有効／発注残／在庫管理対象／発注点） | 必須 |
| F-S2 | 在庫管理対象フラグONの商品のみ在庫計算対象 | 必須 |
| F-S3 | 受注確定時、引当済へ加算し有効在庫を再計算（引当） | 必須 |
| F-S4 | 入庫時、実在庫へ加算・発注残を減算・有効在庫を再計算 | 必須 |
| F-S5 | 出庫時、実在庫と引当済から減算（消込）。分納は当該分のみ | 必須 |
| F-S6 | キャンセル／数量変更時、引当済・発注残を戻し整合維持 | 中 |
| F-S7 | 発注時に発注残へ加算し入荷予定を可視化（任意） | 中 |
| F-S8 | 有効在庫が発注点を下回った商品を抽出・アラート | 低 |
| ID | 要件 | 優先度 |
|---|---|---|
| F-B1 | 得意先ごとの締め区分に基づく請求書の自動集計・生成 | 必須 |
| F-B2 | 仕入先ごとの締め日で入庫実績（入荷分）を集計し出金予定（買掛）を自動生成 | 必須 |
| F-B3 | 入金・出金の手動消し込み。売り側＝請求書←入金／買い側＝出金予定←出金の2層（分割入金・分割払い対応、各々別カスタムM） | 必須 |
| F-R1 | 伝票ベース＋明細ベースの集計（商品別・期間別・取引先別） | 必須 |
| F-R2 | ダッシュボード（売上・仕入・受注残・入荷残を一画面で） | 中 |
| F-R3 | レポートのCSVエクスポート | 中 |
| F-R4 | グリッド一覧からのインライン編集 | 中 |
| F-R5 | 発注 入庫状況レポート（明細レベル）：発注明細単位で発注数量／入庫済／入荷残／入庫ステータスを一覧化。仕入先別・商品別・期間別に集計 | 必須 |
| F-R6 | 受注 出荷状況レポート（明細レベル）：受注明細単位で受注数量／出荷済／出荷残／出荷ステータスを一覧化。得意先別・商品別・期間別に集計 | 必須 |
| F-A1 | 発注後リードタイム超過で未入荷をメールアラート | 中 |
| F-A2 | 納品・出荷予定日に基づく出荷忘れ防止アラート | 中 |
本提案は、いまメイクス様が抱える転記・在庫・集計・出荷漏れといった「日々の困りごと」をまず確実に解決します。さらにFLAM（販売管理“専用”ソフト）からZoho（業務に合わせて広げられるプラットフォーム）へ移すことで、AI・BI・OCRなどこれから必要になる仕組みを足していける土台が手に入ります。
| 現状の困りごと | Zoho CRM 構築後 |
|---|---|
| C1 仕入名と販売名が別管理で、発注書とメーカー注文書の名称が違い手作業で転記 | 商品マスターを一元化し、1レコードに販売名／仕入名／仕入先を保持。受注→発注の転記がゼロに |
| C2/C5 在庫・出荷残・入荷残が頭の中／アナログで、出荷漏れ・請求漏れのリスク | 定番商品の引当・実在庫を自動更新、出荷残・入荷残を明細レベルで可視化し漏れを防止 |
| C3 受注伝票がなく、メール受注にExcelで都度注文書を作成 | 受注を起点に仕入先別の発注書を自動下書き。受注→発注→入庫→出荷を1本の履歴で追跡 |
| C4 伝票単位でしか出ず、明細は1件ずつ開く。Excelで集計 | 明細レベルの横断集計・状況レポート（商品別・期間別・取引先別／入荷残・出荷残）をワンクリックで |
| C6 FLAMは画面遷移が多く売上と仕入の行き来が手間 | ダッシュボードで一画面に集約し、行き来の手間を削減 |
| C7 SKU約300で品番・商品名検索が引っかからない | 商品マスターに検索性を持たせ、経験の浅い担当でも素早く特定 |
FLAMは販売事務に最適化された専用ソフトで、業務フロー自体は固定です。ZohoはAPI・自動化（Deluge/Flow）で業務に合わせて作り込めるため、データが1か所に集まった先に、次のような発展が現実的になります。
実装方式：◎標準＝標準のまま ○設定＝カスタム項目・WF設定 △カスタム＝カスタムM＋Deluge ▲外部連携＝外部API/OCR/LLM
| 業務要件 | 標準で不足する理由 | 方式 |
|---|---|---|
| 受注→発注の自動下書き（仕入先別分割） | 標準は受注と発注が独立。明細の仕入先別振り分けがない | △ Deluge |
| 入庫・出荷の分納／入荷残・出荷残 | SO/POに部分入荷・部分出荷の数量管理が標準でない | △ カスタムM＋Deluge |
| 締め請求・締め支払の自動集計 | 締め日での期間集計＋帳票自動生成が標準にない | △ スケジュール関数 |
| 入金／出金の予定・消し込み | 売掛・買掛管理はCRM標準外（本来Books領域） | △ カスタムM |
| 在庫引当・更新（実在庫／引当済／有効） | 受注引当・入庫加算・出庫消込の自動増減が標準にない | △ Deluge |
| 未入荷／出荷忘れアラート | 日付ベースの定期監視通知が標準WF単体で不可 | △ スケジュール関数＋メール |
| AI注文書取り込み | OCR/LLM読取＋近似マッチはCRM外 | ▲ 外部連携（PoC） |
費用は単価 ¥65,000／人日（税抜）で試算。要件定義は1式 ¥200,000。プロジェクト管理は実装工数の10%。本フェーズは約2ヶ月での実装を想定。
| 区分／フェーズ | 工数(人日) | 費用(税抜) | 主な内容 |
|---|---|---|---|
| A. 要件定義（1式） | ― | ¥200,000 | 業務フロー整理・要件定義書／図解版の作成・合意形成 |
| B-0. 環境・初期設定 | 1 | ¥65,000 | テナント・組織・ユーザー／ロール・権限設計 |
| B-1. マスター設計・構築 | 2 | ¥130,000 | 取引先・商品一元化・価格バリエーション・連絡先 |
| B-2. データ移行 | 3 | ¥195,000 | マッピング・枝番加工・インポート検証 |
| B-3. 取引フロー | 5 | ¥325,000 | 受注→発注自動分割・帳票・入庫・出荷・ステータス自動更新 |
| B-4. 締め・請求・入出金 | 4 | ¥260,000 | 締め請求／締め支払・入金／出金予定／出金カスタムM・帳票 |
| B-5. 在庫管理 | 3 | ¥195,000 | 在庫項目設計・引当／消込・入庫加算 Deluge |
| B-6. レポート・可視化・アラート | 1.5 | ¥97,500 | 明細集計・ダッシュボード・アラート・グリッド |
| B-7. テスト | 2 | ¥130,000 | 単体・結合テスト・本番移行 |
| B-8. 運用手順書作成・ガイダンス実施 | 2 | ¥130,000 | 運用手順書の作成・操作ガイダンス（トレーニング） |
| B 小計（実装：人日分） | 23.5 | ¥1,527,500 | — |
| B PM・プロジェクト管理（実装の10%） | 2.35 | ¥152,750 | — |
| B 実装＋PM 小計 | 25.85 | ¥1,680,250 | 人日分の合計 |
| 合計（本フェーズ）＝ A ＋ B | 25.85人日＋1式 | ¥1,880,250 | 要件定義¥200,000 ＋ 実装・PM¥1,680,250（税抜・約2ヶ月で実装） |
補助対象経費（構築・導入役務 ＋ Zohoライセンス2年分）に対し補助率 1/2 で試算。申請枠上限 ¥2,456,000 の範囲内。ライセンスは現行価格 ¥4,800 × 2ID × 2年分で算入（値上げ後¥5,660ではなく現行価格ベース）。
| 項目 | 金額（税抜） |
|---|---|
| 構築・導入役務費（本見積：要件定義1式＋実装＋PM） | ¥1,880,250 |
| Zoho CRM Enterprise ライセンス費（現行 ¥4,800 × 2ID × 24ヶ月＝2年分） | ¥230,400 |
| 補助対象経費 合計 | ¥2,110,650 |
| 補助率 | 1/2 |
| 補助額 | ▲¥1,055,325 |
| 実質自己負担（補助後） | ¥1,055,325 |
| 区分 | 月額／ID | 年額／ID（年契約） |
|---|---|---|
| 現行価格（〜2026年6月／本試算の前提） | ¥4,800 | ¥57,600 |
| 値上げ後（2026年7月〜） | ¥5,660 | ¥67,920 |
| # | 論点 | 状態 |
|---|---|---|
| Q1 | 編集者ライセンスの選定（Professional / Enterprise） | 業務フロー確認後に確定 |
| Q2 | 色・規格違いを「価格表バリエーション」か「個別商品」か | 移行方針として決定要 |
| Q3 | 発注書・入金／出金のカスタムモジュール実装方式 | 設計フェーズで確定 |
| Q4 | AI注文書取り込みの実現可否・適用範囲 | 技術検証 |
| Q5 | 移行対象データの範囲とCSV項目マッピング | FLAM画面再確認で詳細化 |
| Q6 | 在庫管理の対象範囲（簡易在庫の粒度） | 設計フェーズで確定 |
| Q7 | 発注点（再発注点）アラートの要否・設計。基本は「受注に対して都度仕入れる」モデルと想定され、発注点による自動補充アラートが有効に機能するか、対象商品範囲・しきい値の設定基準・発火条件を要確認 | 要確認（運用方針） |
| Q8 | 入庫／出庫の分納頻度。設計はハイブリッド（明細サブフォームで残管理＋入庫／出庫モジュールを分納実績ログ）で確定。分納が月をまたぐ頻度・締めの実績日配分の必要性を確認し、ほぼ無ければモジュール統合での簡素化余地を検討 | 確定（ハイブリッド）／頻度は要確認 |