お打ち合わせ議事録
日時: 2026年7月17日
議題: ERPリプレイス検討 — 周辺システム連携の実現可否・開発範囲・スケジュール（CFCL × システム会社）
出席: CFCL（Ono様・Nakahara様・Nakayama様・Uchiyama）／システム会社（Hotta様・Nishiura様）
本議事録は音声の自動文字起こしを基に作成。社名・人名・システム名の一部は文字起こしの誤変換の可能性があるため、原文の表記に推定を併記している（例:「ジョア」=JOOR、「食材」=Shopify と推定）。
1. 決定事項
① 大目的の共通認識
システム未連携が原因で発生している手作業（本来存在しないはずの業務）の排除を最優先とする。あわせて、仕入・売上・在庫データのERPでの一元管理を実現する。現状は売上がJOOR（卸）・スマレジ（直営）・Shopify（EC）に分散し、アラジンオフィス上で集約できていない。
② API連携の実現可否の見立て
公開APIが充実しているスマレジ・Shopifyは連携実現可能の見込み（Shopifyは先方に海外出荷アプリの実績あり）。ロジザード（倉庫WMS）はAPI仕様書が申請制のため、CFCL側で利用申請すれば仕様把握のうえ連携可能な見込み。その他の連携先は仕様確認のうえ判断。
③ 連携方式の切り分け
売上・商品マスタなど更新頻度の高いものは常時API連携、日次で足りるデータはバッチ処理でも可、という方針で整理する。CFCL側作成の連携インターフェース一覧をベースに詰める。
④ フェーズ1の開発範囲（3本柱）
(1) 周辺システムとのAPI自動連携 (2) 連携データの管理画面（売上管理・在庫移動実績等の確認画面）(3) 現行システムで業務利用中の機能の最低限の担保 — の3点をフェーズ1として工数・スケジュールを検討する。
⑤ 連携開発コストの持ち方
ロジザード・スマレジ等メジャーな連携先との繋ぎ込み開発は、先方としても狙っていた領域のため一部持ち出しで対応する意向。正式な工数は開発チームから改めて提示。
⑥ スケジュールの前提
先方は現在バージョン5のテストリリース直後（自社ブランドで運用開始）で、ブラッシュアップが最優先。本格的な開発着手は最短1〜2ヶ月後。ただし工数見積・機能ギャップの洗い出し・API仕様確認は並行して進める。正式契約・要件定義の本格開始も最短2ヶ月後ごろのイメージ。
⑦ カスタマイズの扱い
汎用性のある開発は製品全体のアップデートに取り込み、CFCL固有の要件（ニット特有の糸の在庫管理・計算、帳票レイアウト等）はブランド個別のカスタマイズとして対応可能。前回ヒアリング内容はほぼカスタマイズで実現できる見込みで、次バージョンを待つ必要はない。
⑧ 補助金の活用
補助金は発注前の申請が必要。公募は2〜3ヶ月ごとにあるため、タイミングを合わせて申請し、カスタマイズ費用への充当を狙う。そのため見積取得と社内の発注判断は早めに進める必要がある。
⑨ 汎用性の高い開発の費用負担方針
汎用性が高い開発の工数を全額CFCLに請求するのはフェアではない、という先方の考え。汎用性が高いと判断できるものは「一部のみCFCL負担」または「先方負担での全体アップデート」のいずれかを内容に応じて判断し、先方から提案する。CFCLの要望は他ブランドにもプラスになるものがほとんどで、自社システムの向上と捉えて対応する意向（要望はまず遠慮なく出してよい）。
⑩ 目標スケジュールの共通認識（デッドライン）
来年6月のパリ展示会の時点で新システムが使える状態（テスト完了・少なくとも現行アラジンオフィス搭載機能相当が使え、データ連携が整流化された状態）を目標とする。先方は「要件が定義されれば現実的」と回答し、これをデッドラインとして開発スケジュール案を組む。直近2ヶ月で補助金申請と要件定義を並行 → その後約1年で要件定義〜内部結合・外部結合〜テストを完了させる想定。
⑪ 補助金の種別確定
省力化補助金・一般型を申請する（CFCLは従業員約80名のためカタログ型ではなく一般型が適用。上限約6,500万円）。
⑫ 導入後サポート体制
先方はリリース後に専任のテック担当を配置する。約80名規模の利用を想定したサポート体制を組む。直感的なUIでサポート工数を減らし、月額保守費はなるべく抑える方針。
2. ネクストアクション
【CFCL】ロジザードAPI仕様書の利用申請
申請制のため、CFCLから利用申請を行い、先方が仕様を確認できる状態にする。
【CFCL】連携インターフェース一覧へのデータ量追記・共有
日次・月次の件数に加え、繁忙期（ファーストデリバリーの6月・12月）のピーク時件数を概算で追記して先方へ共有する。
【CFCL】アラジンオフィスの機能一覧の提供
提供可能であれば先方へ共有。先方が自社機能とのギャップを特定し、フェーズ1/フェーズ2の切り分け案を提示する。
【CFCL】省力化補助金（一般型）の申請準備の前倒し
発注前の申請が必要なため、見積を前提に「本当に必要か・この金額で進めるべきか」の社内判断を早めに行い、直近2ヶ月での申請を目指す。
【CFCL】連携先（JOOR・ロジザード等）の仕様情報の連絡
先方が把握していない連携先側のコスト有無を精査できるよう、仕様情報・窓口を先方へ連絡する。
【先方】公開API連携の工数見積の提示
スマレジ・Shopify等、公開APIがあるものから工数感を算出。開発体制・スケジュール感もあわせて提示する。
【先方】機能ギャップの洗い出し
CFCLから受領する情報を基に、現行業務機能のカバー状況（あるもの・ないもの）を急ぎ洗い出す。バージョン5の設計書・機能一覧の確認と並行して進める。
【先方】想定マイルストーン（概算）の提示
本日共有した要件・体制の前提で、来年6月パリ展示会をデッドラインとした概算マイルストーンを提示する。
【先方】為替レート取得元の確認・シーズン別レート設定の整理
為替の自動取得元を確認のうえ、シーズンごとにレート設定を変更する運用（過去データとの整合含む）の実現方法を整理する。
3. 議事メモおよび補足事項
現状の課題（CFCL側の説明）
- システム間の自動連携がほぼなく、手動ボタン操作やCSVのエクスポート／インポートで運用。フォーマット不整合で連携失敗も発生
- 売上データが JOOR（卸受注）・スマレジ（直営店舗）・Shopify（EC）に分散し、アラジンオフィスで一元管理できていない
- 倉庫（ロジザード）との在庫連携も現場の手作業に依存し、正確な在庫管理ができていない
- 企画管理（サンプル工程までの企画情報）にも別ツールを利用（文字起こし上「作ろう」— ツール名は要確認）
API連携の工数に関する質疑
- 「ボタン一つで繋がるのか、数ヶ月かかるのか」との質問に対し: → 連携箇所と公開APIの洗練度による。整備されていない相手だと作り込みが発生する。まず仕様を見てから工数を出す、が先方回答
- 公開APIがあるものは即座に工数算出が可能。非公開の連携先はCFCLの協力（仕様入手）が前提
- 5社のシステム構成に合わせた共通基盤を設計できれば比較的スムーズに開発できる可能性、との先方エンジニア見解（ただし「蓋を開けてみないと分からない」面あり）
- API連携のランニングコスト: 開発時の一時費用のみの想定で、トランザクション課金等の継続コストは基本発生しない見込み。ただし連携先（JOOR・ロジザード等）側の仕様・課金は先方未把握のため、CFCL経由で情報連絡のうえ先方が精査する
開発の進め方・体制（質疑）
- 個社開発とエンハンス（全体アップデート）開発の並行可否: → チームはフロントエンド／バックエンドに大別。ブランドカスタマイズはフロントエンド作業が多い傾向で、フロント完結なら早い。バックエンドの仕組みまで深く関わる変更が最も時間を要する、が先方回答
- 先方の体制: 全社約10名、うち本システム担当は約半分（残りは物流ほか）。繁忙時は業務委託等での増員も可能
- 先方はCFCL案件の優先度を「非常に高い」と明言。CFCLにどれだけ満足してもらえるかは先方の今後にとっても重要、との位置付け
確認事項への回答（画面デモを交えた質疑）
- 事前送付した確認事項への回答は基本的にすべてYES。以下は個別に確認した項目
- 画像表示（在庫管理・売上画面）: 商品マスタには画像登録・表示済み。品番だけでは現場がイメージできないため在庫・売上画面でも画像表示したい、とのCFCL要望に対し → データは既に保有しているためUI調整で概ね対応可能、が先方回答
- 生産進捗（8番）: スケジュールに入力した日付ベースでサンプル/量産の工場ごとの進捗を一覧表示可能（デモ確認済み）。現状は生産管理側が工場から聞いた内容を入力する運用。工場側にログインしてもらい入荷・予定等を直接入力してもらう構想はあるが未実装
- 受注→後工程の反映（7番）: 受注データを基に「生産数確定」画面へ注文数が反映され、調整のうえ確定した生産数が量産仕様書へ自動反映される（デモ確認済み）
- 分納・同梱（9番）: 顧客別・製品別の2軸で分納可能。別々の注文データを紐付けて同梱（伝票統合）も可能。受注後に出荷伝票が作成されたタイミングで対応する
- 引き当て: 製品の入荷前でも優先度を付けて引き当てが可能。「直営側が在庫を先に取ってしまい卸先の分が不足する」という課題（先方自社ブランドでも同一課題）への対応として実装済み
- WMS連携: 出荷の分納処理をしたデータがロジザード側の入荷予定として流れると管理がスムーズ、とのCFCL要望。配分・引き当ての仕組みと関連させて検討する
- 返品: 実装済み（返品に伴う請求のマイナス反映を含む）
- 店舗間移動: 在庫移動機能でロケーションを選択して移動可能（デモ確認済み）
- スマレジ連携: 将来的に連携予定。現状店舗スタッフはアラジンオフィスとスマレジの両方を見る運用になっており、一元化があるべき姿とのCFCL指摘
- 売上分析: 収支シミュレーション機能で各タイミングの数値を閲覧可能。アイテム別・ジェンダー別・ランキング等、システム内にデータがあれば出力形式は柔軟に対応可能。Shopify・店舗の実売データを取り込めば実売（Sell-through）ベースのアウトプットも低コストで追加できる、が先方回答
通貨・価格設定（質疑）
- 外貨対応: 対応済み。為替レートは自動取得（取得元は先方が確認。CFCLはメイン=みずほ円、外貨=三井住友を参照する運用）
- シーズンごとのレート設定変更: 先方に運用経験がなく、現状は決めたレートを設定する仕組み。過去データとの整合含め整理・確認が必要
- 掛け率とディスカウント: 国内卸=掛け率設定（上代ベース）、海外卸=下代ベースのディスカウント設定として最初から別建てで設計済み。アラジンで発生している煩雑な入れ込み作業は発生しない、が先方回答
- 卸価格の個別設定: 1社に対して複数のディスカウント率設定（例: ポップアップ期間のみ別率）が実装済み
- EC多通貨の取り込み: ドル建て売上等が正しい通貨として取り込まれる（アラジンの「100ドルが100円と認識される」問題は発生しない）
スケジュール・補助金（CFCL側事情の共有）
- CFCL側の背景: 業務負荷過多により残業増・体調不良が全社的に発生しており、至急元の状態に戻したい。業務改善プロジェクトはQCDのうちデリバリーを最重視
- 日々の業務改善はAIでも進めているが、中期的にはアラジンのデータ連携課題の解消が最も効く、との認識
- 目標: 来年6月パリ展示会時点で新システムが使える状態（テスト完了・少なくとも現行アラジン機能相当・データ連携の整流化。売上の綺麗な可視化などは後続でよい）
- 先方回答: → 要件が定義されれば現実的なスケジュール。デッドラインとして開発スケジュール案を組む
- 進め方: 直近2ヶ月で補助金申請＋要件定義を並行 → その後約1年で要件定義〜内部結合・外部結合〜テスト
- 補助金: 省力化補助金・一般型（CFCLは従業員約80名のためカタログ型ではなく一般型。上限約6,500万円）
導入後サポート（質疑）
- 運用中の問い合わせ対応（現状アイル社に都度問い合わせしている運用の代替）: → 専任のテック担当を配置する、が先方回答
- 利用規模: 当初想定より大きい約80名規模となるため、先方がサポート体制を検討する
- 先方方針: 直感的なUIでサポート工数を減らし、月額保守費はなるべく抑えたい
本議事録は自動文字起こしからの要約のため、固有名詞・数値は原資料での確認を推奨。