確認事項
位置づけ: 意思決定待ちの登録簿
本ページは先行リリース第1弾（催事＋アイテム〈商品マスタ〉＋商社〈卸・発注〉）に関する意思決定待ち事項の登録簿である。すでに合意済みの運用ルールを「決定事項」、VE の回答を待つ論点を「確認事項」として区分する。確認事項は質問リスト全91問と1対1で対応し、質問No で追跡する。回答状況はすべて未確認である（実データで確定・回答受領のたびに更新）。
根拠は試作実装（crm_app）と定例会議事に基づく。件数・規模等の実データは「（実データで確定）」と記す。
先行リリース第1弾のスコープは催事・アイテム（商品マスタ）・商社（卸・発注）の3領域である。顧客・商談・見積・KPI予実等の後続フェーズ機能は本ページの対象外とする。フェーズ区分の詳細は redesign/scope-phasing を参照する。
| 論点 | 決定内容 | 根拠 |
|---|---|---|
| 価格保持の責務 | 価格は CRM 側で保持し、ValueOS 側には持たない | 7/17合意 |
| 論点確定の進め方 | 判断が割れる論点は開発を止めず、Ouver がおすすめ実装を提示し複数パターンから選定する | 既往の合意プロセス |
| 回答反映のフロー | 回答受領 → 区分更新 → 該当ページへ反映 → 本ページの該当行をクローズ、の順で運用する | 本ページ運用ルール |
| フェーズ表示の方法 | フェーズはサイドバーで分類せず、各ページ冒頭の「位置づけ」行と redesign/scope-phasing に集約する | ドキュメント体裁ルール |
| 議事の正本 | 定例会議事の正本は redesign/meeting-log とし、本ページと二重管理しない | 運用ルール |
| 確認チャネルの使い分け | チャット質問窓口（軽量な解釈確認）・定例会アジェンダ（◎論点）・都度連携（実データ受領）の3経路で運用する | 既往の運用 |
| 卸金額の販売店軸（No.56） | 卸価格は販売店ごとに異なり得るという前提で設計する（YES）。ValueOS sales_prices の dealer_id 軸に準拠し、WholesalePrice.dealer?（未設定＝標準価格）で表現する。試作実装（crm_app）済み | ValueOS準拠設計・試作実装 |
| 合格基準の定義 | 合格基準＝「業務が回ること」。10月中にできる「設計書」を正とし、そこに明記されている部分を責任範囲とする。11月末に現場投入して使える形かをチェックし、修正はバッファ内で消化可否を判断する（設計書にない要望は追加機能＝範囲外になり得る） | 2026-08-19定例 |
| 卸（商社）の扱い | 卸は現場で実運用しながら改善済みの現行運用を「正解」として踏襲する。データの流れ・業務フローは踏襲しつつ、フロント実装（肥大化した1ファイルの共通化等）は Ouver 側で改善してよい | 2026-08-19定例 |
| マスタのCSV一括登録 | 店舗・系列・代理店等、全マスタ種別に CSV 一括登録機能を用意する | 2026-08-19定例 |
質問リストは全91問。優先度は次の3段階で管理する。
| 記号 | 意味 |
|---|---|
| ◎ | 先行リリースのブロッカー（回答がないと実装・移行が止まる） |
| ○ | リリースまでに要確定（暫定実装のまま先行は可能） |
| △ | リリース後でも可（後続フェーズのバックログへ転記） |
全体方針（Q1〜Q6）
Section titled “全体方針（Q1〜Q6）”| No | 問い | 選択肢 | 優先度 | 確認先 |
|---|---|---|---|---|
| Q1 | 先行リリース範囲は「催事＋アイテム＋商社」で確定か。顧客・商談・見積・KPIは後続でよいか | （2026-08-19定例で確定）現行3領域（催事＋アイテム＋商社）で確定。問題なし | ◎→解決 | 田中氏 |
| Q2 | 現場での利用開始希望時期はいつか | （2026-08-19定例で確定）実装完了は9/30目標。早いほど望ましいとの補足あり | ◎→解決 | 田中氏 |
| Q3 | 対象ユーザーは誰か | （2026-08-19定例で確定）社内4ロール（本部管理者／社内営業／経理／発注担当）＋外部は代理店ロール（管理権限者）と催事スタッフロール（メンバー）の2階層 | ◎→解決 | 田中氏 |
| Q4 | 既存BT社CRMと並行稼働するか。二重入力の扱いは | 並行稼働／段階移行／即時切替 | ◎ | 田中氏 |
| Q5 | 先行運用は本番データか試験運用（ダミー／一部）か | （2026-08-19定例で確定）本番データで運用 | ○→解決 | 田中氏 |
| Q6 | 先行リリースの受入基準（何ができれば使い始めるか）は何か | （2026-08-19定例で確定）合格基準＝業務が回ること。10月中に作成する設計書を正とし、明記された部分を責任範囲とする。11月末に現場投入して使える形かをチェックし、修正はバッファ内で消化可否を判断（設計書にない要望は追加機能＝範囲外になり得る） | ◎→解決 | 田中氏 |
催事（Q7〜Q34）
Section titled “催事（Q7〜Q34）”| No | 問い | 選択肢 | 優先度 | 確認先 |
|---|---|---|---|---|
| Q7 | 「催事」の定義は店頭イベント販売か | （2026-08-19定例で確定）量販店等の店頭イベント販売で確定 | ◎→解決 | 田中氏 |
| Q8 | 催事の主役はVE社（元請として代理店へ販売機会提供）か | （2026-08-19定例で確定）VE＝元請（代理店・販売店へ販売機会を提供）で確定 | ◎→解決 | 田中氏 |
| Q9 | 催事1回の単位は「日×店舗×代理店」でよいか | （2026-08-19定例で確定）現行単位（日×店舗×代理店）で確定。自社が入る場合もあり得る | ◎→解決 | 田中氏 |
| Q10 | 同一店舗・同日に複数催事／複数代理店はあり得るか | （2026-08-19定例で確定）あり得ない（1店舗1店舗で取る） | ○→解決 | 田中氏 |
| Q11 | 「会期（複数日）」の概念は必要か | 必要（会期単位を新設）／不要（単日積み上げのまま） | ○ | 田中氏 |
| Q12 | 店舗マスタ必須項目は 店名・エリア・系列 で足りるか | （2026-08-19定例で確定）現行3項目に加え、電話番号・責任者・メモ（備考）を追加 | ◎→解決 | 田中氏 |
| Q13 | 店舗の「系列」はマスタ化するか | （2026-08-19定例で確定）マスタ化（選択式）で確定。店舗カテゴリーもマスタ化し、全マスタにCSV一括登録を用意 | ○→解決 | 田中氏 |
| Q14 | 店舗は全国で何件規模か | （実データで確定） | ○ | 田中氏 |
| Q15 | 代理店マスタ項目は 名称・連絡先・業態 で足りるか | （2026-08-19定例で確定）現行3項目では不足。加盟店契約スプレッドシート「会社情報」シートの項目群を全採用し大幅拡張（詳細フィールドは data-model 側に定義） | ◎→解決 | 田中氏 |
| Q16 | 代理店に取引条件・複数拠点情報は必要か | 必要／不要 | ○ | 田中氏 |
| Q17 | 代理店ロールの外部招待は先行に含めるか | （2026-08-19定例で確定）含める。約40社それぞれに個別アカウントを発行 | ◎→解決 | 田中氏 |
| Q18 | シフト割当対象は「代理店＋責任者名＋人数」でよいか。個人スタッフ単位が必要か | （2026-08-19定例で確定）現行粒度（代理店＋責任者名＋人数＋店舗）で確定。個人スタッフ単位マスタは不要。シフト登録はVE側が行い、代理店ごとの一括登録に対応（希望店舗ヒアリング〜自動マッチングの流れは本表直後の補足参照） | ◎→解決 | 田中氏 |
| Q19 | 責任者は名簿（マスタ）から選ぶか手入力か | （2026-08-19定例で確定）手入力のまま。責任者とユーザーの紐付けは行わない | ○→解決 | 田中氏 |
| Q20 | シフト時間は「日＋開始／終了」で足りるか。複数コマ・交代制は必要か | （2026-08-19定例で確定）現行構造（日＋開始／終了）で確定。一括登録可、個別修正も可（履歴管理は不要） | ○→解決 | 田中氏 |
| Q21 | ステータス5区分（予定／開始済／終了済／未開始／終了未報告）は妥当か | （2026-08-19定例で確定）現行5区分で妥当。遷移規則：登録時＝予定→開始報告で開始済（開始予定超過かつ未報告は未開始）→終了報告で終了済（終了予定超過かつ未報告は終了未報告） | ○→解決 | 田中氏 |
| Q22 | シフト作成は誰が行うか。承認は必要か | （2026-08-19定例で確定）VE側が作成。代理店は行わない。承認フローは不要 | ○→解決 | 田中氏 |
| Q23 | 開始報告の必須項目は 責任者・緊急連絡先 の2項目でよいか（チェック項目は未完了でも送信可） | （2026-08-19定例で確定）責任者・緊急連絡先に加え、当日入るメンバー名（文字列可・全員記載可）を必須項目に追加（カインズからの要請対応） | ○→解決 | 田中氏 |
| Q24 | 朝礼チェック項目（既定7つ）の内容を確定できるか。店舗・催事ごとの出し分けは必要か | （2026-08-19定例で確定）既定7項目に固定せず編集機能を用意（編集以降の申請に反映）。項目ごとの詳細閲覧に対応。店舗カテゴリーごとの出し分けに対応 | ◎→解決 | 田中氏 |
| Q25 | 終了報告のファネル（抽選→着座→アポ）は実ファネルと一致するか | （2026-08-19定例で確定）現行ファネル（抽選→着座→アポ）で確定。実際はさらに細かい段階がある | ◎→解決 | 田中氏 |
| Q26 | 両面提案／片面提案／計の3値管理は必要か | （2026-08-19定例で確定）3値管理のまま。合計は入力不要で自動計算（両面1・片面2なら合計3の加算方式） | ○→解決 | 田中氏 |
| Q27 | 「部門」はマスタ化するか | （2026-08-19定例で確定）マスタ化。ただしログイン部署から自動導出し入力不要（イレギュラー時は変更可）。社員の部署履歴を保持。代理店側も部門分けを行う | ○→解決 | 田中氏 |
| Q28 | 終了報告に売上・受注金額・契約件数を入れるか | （2026-08-19定例で確定）不要。アポ化後はアポ／商談側で金額・件数を管理 | ◎→解決 | 田中氏 |
| Q29 | 成果KPI（着座率・アポ率等）を先行で表示するか | （2026-08-19定例で確定）先行では不要。データが揃った最終段階でBIツール的に一括表示する方針（可視化したい数字のゴールは先にメモしておく） | ○→解決 | 田中氏 |
| Q30 | 催事で獲得したアポ・商談を先行でCRM（商談）に登録する運用を含めるか | （2026-08-19定例で確定）含めない（先行運用なし。現状どおりスプレッドシート管理。仮登録機能も不要） | ○→解決 | 田中氏 |
| Q31 | 含める場合、催事シフトと商談・案件の紐付けキーは何か | （2026-08-19定例で確定）Q30により先行では該当なし。ただし担当ロールのすり替え（催事アポ→訪問→クロージングの間に担当会社・部署が変わる）はデータ上追えるようにする必要があり、案件ごとに数フェーズの担当登録を後続で設計する（Mockで検討予定） | ○→解決（付随論点は後続設計） | 田中氏 |
| Q32 | 通知（前日リマインド・未提出アラート）は必要か。手段は何か | （2026-08-19定例で確定）必要。手段はメール／LINE／Slackを会社ごとに使い分け（メールは実装容易、LINE/Slackの連携方式は要確認）。前日リマインド・終了報告未提出アラートに加え、開始報告のアポ数と実登録数の乖離アラートも追加※LINE/Slack通知手段は要確認 | ◎→解決（一部要確認） | 田中氏 |
| Q33 | 現場入力はスマホ主体か。オフライン一時保存は必要か | （2026-08-19定例で確定）スマホ主体＋PCも対応（UIはPC基準でも用意）。オフライン一時保存は不要 | ◎→解決 | 田中氏 |
| Q34 | シフト表・成果レポートのPDF出力は必要か | （2026-08-19定例で確定）催事のシフト表・成果レポートは印刷不要（見積・発注書等、他領域ではPDF化する） | △→解決 | 田中氏 |
Q17/18 の補足（希望店舗ヒアリング〜自動マッチングのフロー）
Section titled “Q17/18 の補足（希望店舗ヒアリング〜自動マッチングのフロー）”2026-08-19定例での回答に基づき、シフト割当（Q17/18）の運用フローを補足する。
| 項目 | 内容 |
|---|---|
| 場所取り | VE がカインズ等と場所取りを取り決め、取れた店舗を代理店に割り振る |
| 希望収集のタイミング | 基本2ヶ月後の店舗しか決められないため、今月に「2ヶ月後（例：10月）」の希望を回収する |
| 希望収集の内容 | 日別の稼働可否＋希望店舗3店舗程度＋（漏れる場合の）希望エリア |
| 現状の運用 | LINE で吸い上げ→スプレッドシートで手作業マッチング→正本シフト表を作成し代理店に配布 |
| システム化後の想定フロー | 月曜に代理店へ通知→代理店が2ヶ月後の希望店舗・エリアをシステム内で提出→VE側が取れた枠を登録→自動マッチングで店舗割当の叩きを作成 |
| 未確定事項 | 取れた店舗の代理店への連絡方法（現状はLINEグループでのスクショ共有）は後続で整理する |
アイテム（商品マスタ）（Q35〜Q53）
Section titled “アイテム（商品マスタ）（Q35〜Q53）”| No | 問い | 選択肢 | 優先度 | 確認先 |
|---|---|---|---|---|
| Q35 | 「アイテム」は商品（型番）を指すか、パッケージも含むか | 商品＋パッケージ双方／商品のみ | ◎ | 田中氏 |
| Q36 | 商品の主キーは型番でよいか。自社コードを別途採番するか | 型番＝主キー／自社コード併用 | ◎ | 田中氏 |
| Q37 | 型番の重複・改番時の運用は何か | 手動突合継続／運用ルール新設 | ○ | 田中氏 |
| Q38 | 商品種別（PV／BT／EQ／IH／AC／付帯）はこの6区分で確定か | 現行6区分／区分見直し | ○ | 田中氏 |
| Q39 | メーカー→シリーズ→商品をID参照に正規化するか | ID正規化を先行実施／後続送り | ◎ | 田中氏 |
| Q40 | 商品マスタ必須項目は メーカー・型番・種別（kind） の3項目でよいか | 現行3項目／品名・シリーズ・容量も必須化 | ◎ | 田中氏 |
| Q41 | 一覧列（メーカー／シリーズ／商品名／型番／容量）は確定か。他に出す列はあるか | 現行列で確定／列追加 | ○ | 田中氏 |
| Q42 | 納期は商品ごとに持つか、メーカー単位でよいか | 商品優先＋メーカーfallback（現行）／メーカー単位のみ | △ | 田中氏 |
| Q43 | 画像・カタログ・仕様書の添付は先行で必要か | 必要／不要 | △ | 田中氏 |
| Q44 | 規格（容量等）は自由入力でよいか、構造化するか | 自由入力のまま／構造化 | △ | 田中氏 |
| Q45 | JAN等の外部コードを持つ必要はあるか | 必要／不要 | △ | 田中氏 |
| Q46 | メーカーマスタは名称のみで足りるか | 名称のみ／コード・取引区分を追加 | ○ | 田中氏 |
| Q47 | メーカーマスタと商品マスタを統合する設計にするか | 統合／またがり参照のまま | ○ | 田中氏 |
| Q48 | シリーズ編集の変更履歴未記録を先行で解消するか | 解消（履歴対象に追加）／後続送り | ○ | 田中氏 |
| Q49 | 仕入先マスタは 商社／メーカー直送 の2値区分で足りるか。コード・連絡先・支払サイトは必要か | 現行2値／項目追加 | ◎ | 田中氏／経理 |
| Q50 | 施工店（Vendor）マスタを先行に含めるか | 含める／後続送り | ○ | 田中氏 |
| Q51 | ローン会社マスタ（2社間／3社間の入金日数）を先行に含めるか | 含める（三社間決済フローで使用）／後続送り | ◎ | 田中氏 |
| Q52 | 商品状態「販売中／廃番」を追加すべきか | 追加／在庫enumで代替継続 | ◎ | 田中氏 |
| Q53 | 在庫表示（潤沢／少／欠品）は誰がどう更新するか | 手動更新継続／外部連携 | ○ | 田中氏 |
商社（卸・発注）（Q54〜Q73）
Section titled “商社（卸・発注）（Q54〜Q73）”| No | 問い | 選択肢 | 優先度 | 確認先 |
|---|---|---|---|---|
| Q54 | 商社（卸）の先行スコープは「案件・受注・請求・入金・タスク」の5本柱で確定か（タスクは5本柱の一部であり、別軸の任意機能ではない） | 現行5本柱で確定／範囲見直し | ◎ | 田中氏 |
| Q55 | 卸金額マスタの品名はフリーテキストのままか、商品（型番）とID連携するか | フリーテキスト継続／ID連携を先行実施 | ◎ | 田中氏 |
| Q56 | 卸価は「商品×仕入先」単位のみでよいか、販売店ごとの差を持つか | 設計として解決（YES＝販売店ごとに異なる）。試作実装（crm_app）済み | ◎→解決 | 田中氏 |
| Q57 | パッケージの卸金額は個別登録か、構成品の積み上げ方式か | 個別登録（現行）／積み上げ方式 | ○ | 田中氏 |
| Q58 | 仕入先はマスタ化して選択式にするか | マスタ化／文字列のまま | ○ | 田中氏 |
| Q59 | 決済区分は 前金・掛売・三社間・カード・その他 の5種・呼称で確定か | 現行5種で確定／区分・呼称見直し | ◎ | 田中氏／経理 |
| Q60 | 決済区分ごとのフロー理解（三社間・カードはinvoice工程省略等）は正しいか | 現行理解で確定／フロー見直し | ◎ | 経理 |
| Q61 | 各工程の担当（決済確定・請求・入金消込＝経理、発注＝発注担当）はこの体制でよいか | 現行体制／担当見直し | ○ | 田中氏 |
| Q62 | 与信枠（掛売）の代理店ごとの上限管理は必要か | システム管理／運用でみる | ○ | 田中氏 |
| Q63 | 販売店発注は「フォーム→案件化」でよいか。誰がどこから入力するか | 代理店入力／自社入力／両方 | ◎ | 田中氏 |
| Q64 | 発注フォームの項目（発注元・商品・数量・納品先・希望納期等）を確定できるか | （項目リストで確定） | ◎ | 田中氏／発注担当 |
| Q65 | 発注〜入金の状態区分（発注済／納品済・請求済／一部入金／入金済）はこの区分でよいか | 現行区分／区分見直し | ○ | 田中氏 |
| Q66 | 分割入金・残高消込は先行で必要か | 必要（実装済み）／不要 | ○ | 田中氏 |
| Q67 | 商社・メーカーへの発注依頼はシステムから送るところまで含めるか、記録のみか | 送信まで含める／記録のみ | ○ | 田中氏 |
| Q68 | 発注書・納品書・請求書のPDF様式（自社フォーマット）は提供可能か | 自社フォーマット提供／簡易出力継続 | ◎ | 経理 |
| Q69 | 商社（卸）案件は元請（販売店／deals）と別軸で持つ方針で確定か。将来分社化も視野に入れるか | 別軸方針で確定／統合方針 | ◎ | 田中氏 |
| Q70 | 商社別軸のパイプライン列（決済待ち／発注待ち／納品待ち／請求待ち／入金待ち／完了）でよいか | 現行6分類／分類見直し | ○ | 田中氏 |
| Q71 | タスク（5本柱の1つ）の運用ルール詳細（担当・期限管理の粒度）は現行のままでよいか | 現行運用で確定（実装済み）／運用ルール見直し | ○ | 田中氏 |
| Q72 | 卸の売上・粗利集計を先行でダッシュボード表示するか | 表示する／後続送り | ○ | 田中氏 |
| Q73 | 「商社明細スキャン→自動取込」は先行対象外でよいか | 対象外（後続DXコンサル枠）／先行に含める | △ | 田中氏 |
Q56 の解決（卸金額・販売店軸）
Section titled “Q56 の解決（卸金額・販売店軸）”Q56「卸価は販売店ごとの差を持つか」は、ValueOS の sales_prices（dealer_id 軸で販売店ごとに価格を持つ設計）を裏付けとして、設計として解決済み（YES）とする。回答待ちの確認事項から決定事項へ区分を更新する。
| 項目 | 内容 |
|---|---|
| 結論 | 卸価格は販売店ごとに異なり得る。販売店指定価格を優先し、なければ標準価格にフォールバックする |
| ValueOS 側の根拠 | dealers（販売店マスタ）／sales_prices（dealer_id 軸の価格）／suppliers（仕入先の支払条件） |
| CRM 側の実装（試作・crm_app） | WholesalePrice.dealer?（販売店名。未設定＝標準価格）／currentWholesalePriceForDealer(prices, { productModel?, itemName?, kind?, dealer? }, baseDate) で「販売店指定価格を優先→なければ標準価格にフォールバック」を解決 |
| 代理店（＝販売店・卸先）マスタの拡張 | EventCompany に paymentType?（既定支払区分）・defaultProfitAmount?（既定利益額）を追加（ValueOS dealers 相当） |
| 仕入先マスタの拡張 | Supplier に closingDay?（締日）・paymentSite?（支払サイト）・creditLimit?（与信枠）を追加（ValueOS suppliers 相当） |
反映先は features/wholesale および data-model/entities-phase1 とする。
共通・横断（Q74〜Q91）
Section titled “共通・横断（Q74〜Q91）”| No | 問い | 選択肢 | 優先度 | 確認先 |
|---|---|---|---|---|
| Q74 | マスタ編集は管理者のみか、現場も編集可か（マスタ種別ごと） | 管理者限定／種別ごとに現場編集可 | ◎ | 田中氏 |
| Q75 | 変更に承認フロー（申請→承認→反映）は必要か | 承認フロー導入／即時反映継続 | ○ | 田中氏 |
| Q76 | 変更履歴はフィールド単位before／afterで足りるか。保持期間は | 現行方式継続／対象拡大・保持期間設定 | ○ | 田中氏 |
| Q77 | 物理削除は許容するか | 許容／論理削除のみ | ○ | 田中氏 |
| Q78 | 商品・店舗・代理店・仕入先・卸金額の既存データはどこにあるか | （実データで確定） | ◎ | 田中氏 |
| Q79 | それぞれのデータ件数規模はどの程度か | （実データで確定） | ○ | 田中氏 |
| Q80 | 初期データは移行（取込）か手入力か併用か | 取込／手入力／併用 | ◎ | 田中氏 |
| Q81 | 既存コード（型番・店舗・仕入先）を引き継ぐか、新規採番か | 引き継ぎ／新規採番 | ○ | 田中氏 |
| Q82 | PII・機密（代理店・仕入先連絡先）の取扱いルールは何か | （運用ルールで確定） | ○ | 田中氏 |
| Q83 | 想定ユーザー数・同時アクセス数（社内＋代理店）はどの程度か | （実データで確定） | ○ | 田中氏 |
| Q84 | 主対象端末はスマホか。PC・タブレットとの使い分けは | スマホ主体（催事現場）／PC・タブレット併用 | ◎ | 田中氏 |
| Q85 | 認証方式はID／パスワードか、SSOか、代理店の外部招待か | ID／パスワード／SSO／外部招待 | ◎ | 田中氏 |
| Q86 | 外部連携（会計・EC・在庫・ANDPAD・チャット・ValueOS・ValueAuth）の要否はどうか | 連携範囲を個別確定 | ○ | 田中氏 |
| Q87 | 稼働環境・ホスティングの希望はあるか | 既存ConoHa継続／新規環境 | ○ | 田中氏 |
| Q88 | 受入テストは誰がどう行うか。テストデータは用意できるか | （運用計画で確定） | ○ | 田中氏 |
| Q89 | 保守・問い合わせ対応の体制と時間帯はどうするか | （運用計画で確定） | △ | 田中氏 |
| Q90 | マニュアル・教育（現場向け／管理者向け）は必要か | 必要／不要 | △ | 田中氏 |
| Q91 | 先行分の投資枠・予算はどう握るか | （予算合意で確定） | ○ | 田中氏 |
確認の進め方
Section titled “確認の進め方”回答期限は優先度で切り分ける。
| 優先度 | 期限の考え方 |
|---|---|
| ◎ | 次回定例まで |
| ○ | リリース判定会まで |
| △ | 期限なし（後続フェーズのバックログへ転記） |
確認先ロールは3経路で使い分ける。
- チャット質問窓口：軽量な解釈確認
- 定例会アジェンダ：構造に関わる ◎ 論点
- 都度連携：実データ受領
回答確定後の反映先は区分ごとに固定する。
| 論点区分 | 反映先 |
|---|---|
| 催事の確定事項 | features/events |
| アイテム・商社の確定事項 | data-model/entities-phase1 |
| 議事そのもの | redesign/meeting-log（正本） |