0.1 本ドキュメントの位置付け
大和書房 × オモシクの kintone 発注書PJ Phase 1 における実装レベルの詳細設計を全領域統合した設計書。
| 層 | ドキュメント | 対象読者 |
|---|---|---|
| 戦略・合意 | v3.4 ブループリント | クライアント(高橋さん・窪田部長)・経営層 |
| 詳細設計(本書) | app-design-detail.html(このページ) | 実装者(西川)・QA |
| 個別仕様 | docs/specs/*.md(参照リンク §12) | 個別領域の実装担当・保守担当 |
| 意思決定記録 | docs/plan/adr-*.md | 将来の参照、判断履歴 |
0.2 読み方のガイド
§3〜§8 を順番に
各アプリ仕様 → フロー設計 → kintone JS 実装の順で読み、必要に応じて §12 の個別仕様 .md にドリルダウン。
§10 から逆引き
テスト計画から各テスト項目の背景仕様を §3〜§8 で確認。残論点(§11)も合わせてチェック。
§2 + §9 + §11
方針決定(ADR-001)・リリース計画・残論点を中心に状況把握。
0.3 v3.4 設計の核心
2026-06-05 新刊フローキックオフで 「新刊レコード①が書籍lookup の真のハブ」 設計が確定したため、v3.3 までの「書籍マスタ App85 拡張案」を全廃止し、発注書の書籍 lookup 先を新刊レコード①へ変更。詳細は §2 参照。
1.1 システム全体構成
flowchart TB
subgraph EXT["👥 外部"]
EDITOR["編集者"]
SUPPLIER["取引先"]
TAKAHASHI["高橋さん"]
end
subgraph KIN["☁️ 大和書房 kintone"]
APP_PO["📋 発注書アプリ
5パターン統合・PDF生成"]
APP_SM["👤 取引先マスタアプリ
新規登録フロー受け皿"]
APP_PR["💰 支払依頼アプリ
発注書から派生"]
APP85["📚 書籍マスタ App85
THINK's同期 既存"]
APP_SH["🆕 新刊レコード①
新刊フロー連携先 v2"]
end
subgraph M365["☁️ 大和書房 Microsoft 365"]
PA["⚡ Power Automate
3フロー"]
MSF["📝 Microsoft Forms
取引先入力"]
OUTLOOK["📧 Outlook
自動メール"]
SP["💾 SharePoint
ログ"]
end
subgraph EXT_SYS["🔌 外部基幹"]
THINKS["THINK's
印税・支払処理"]
FREEE["freee会計"]
end
EDITOR -- 発注書作成 --> APP_PO
APP_PO -- lookup --> APP_SM
APP_PO -- lookup --> APP_SH
APP_SH -- lookup --> APP85
APP_SM -- webhook --> PA
PA -- メール --> OUTLOOK
OUTLOOK -- To+CC --> SUPPLIER
SUPPLIER -- 入力 --> MSF
MSF -- onSubmit --> PA
PA -- レコード更新 --> APP_SM
PA -- ログ --> SP
APP_PO -- 派生 --> APP_PR
APP_PR -- CSV月次 --> TAKAHASHI
TAKAHASHI -- 手動転記 --> THINKS
TAKAHASHI -- 手動転記 --> FREEE
style APP_PO fill:#dbeafe,stroke:#1e40af,stroke-width:2px
style APP_SM fill:#fef3c7,stroke:#d97706,stroke-width:2px
style APP_SH fill:#fce7f3,stroke:#db2777,stroke-width:2px
style PA fill:#ede9fe,stroke:#7c3aed,stroke-width:2px
1.2 主要アプリ構成(新規3アプリ + 書籍lookup連携)
📋 発注書アプリ
5パターン統合(書籍デザイン/撮影・校正・拡材/だいわlog/リーディング/その他例外)+ 複製機能 + PDF自動生成。書籍 lookup 先は新刊レコード①(v2)。
👤 取引先マスタアプリ
32フィールド・3区分入力(編集者/取引先/高橋)・新規取引先登録フローの受け皿。機密フィールドは権限分離。
💰 支払依頼アプリ
発注書から派生・金額確定・支払日入力・月次CSVエクスポート。THINK's・freee 手動転記の起点。
📚 書籍 lookup(連携)
v1:書籍マスタ App85 直接 / v2:新刊レコード① 経由(7-8月切替)。担当編集者・書名等を自動コピー。
1.3 連携の特徴
- すべて大和書房テナント内で完結:Microsoft 365 + kintone のデータが大和書房側で一元管理
- 新刊フロー PJ との連携:書籍 lookup を新刊レコード①経由に統一(v2)
- 外部基幹システム連携:THINK's / freee は手動転記(自動化は Phase 3 で検討)
- Power Automate Premium 月¥2,248 + 西川用 M365 月¥1,874 = 月¥4,122
2.1 コンテクスト
v3.3 までは「書籍マスタ App85 を拡張(ステータス・担当編集者・仮タイトル追加 + 検索マッチング画面)」する設計だったが、2026-06-05 新刊フローキックオフで 4アプリ確定スコープ + 新刊レコード①が書籍lookup の真のハブ 設計が確定したため、設計コンフリクトが発生。
2.2 決定(D1〜D6)
| # | 決定 | 影響 |
|---|---|---|
| D1 | 書籍マスタ App85 は触らない | 既存 THINK's 日次同期そのまま維持 |
| D2 | 発注書「書籍/企画」lookup 先を App85 → 新刊レコード①へ変更 | 新刊フロー連携の核心 |
| D3 | 「企画段階で新規登録」動線を新刊フロー側に委譲 | 新刊フロー①の登録UIへリンク誘導 |
| D4 | 担当編集者は新刊レコード①から lookup 自動コピー | CREATOR 自動セット廃止 |
| D5 | 検索マッチング画面(§14.6)廃止 | App85 ↔ 新刊レコード① は 1:1直結のため不要 |
| D6 | 仮タイトル運用責任者は新刊フロー側に吸収 | v3.3 §14.7 廃止 |
2.3 v3.3 → v3.4 変更サマリ
| 観点 | v3.3 設計(旧) | v3.4 設計(新・確定) |
|---|---|---|
| 書籍マスタ App85 | ステータス・担当編集者・仮タイトル追加 | ✅ 何も変更しない |
| 書籍lookup先 | App85 直接 | 新刊レコード①(v1暫定App85、v2切替) |
| 担当編集者 | App85追加 + CREATOR自動セット | 新刊レコード①から lookup 自動コピー |
| 検索マッチング | kintone JS スコアリング | ❌ 不要(1:1直結) |
| Phase 1 工数 | 純3-5日 | 純0日 |
2.4 段階移行スケジュール
App85 直接 lookup
新刊フロー①未稼働期間の暫定運用。発注書アプリで App85 を直接 lookup。書籍/企画が見つからない場合はフリーテキスト入力。
新刊レコード① 連携
新刊フロー① 完成後、lookup 先を切替。kintone JS リファクタ + 過去発注書はそのまま維持。
編集部浸透
新刊フロー① が編集部に浸透。Phase 2 で業務委託契約との連携を追加。
3.1 フィールド設計(全32項目・3区分)
編集者最小入力(4項目)→ 取引先本人入力(19項目)→ 高橋さん確定(9項目)の3段階で完成。
3.1.1 Phase A-B:編集者入力(最小限・30秒)
| # | フィールド | コード | 型 | 必須 |
|---|---|---|---|---|
| 1 | ペンネーム / 会社名 | henmei_kaishamei | 文字列1行 | ✅ |
| 2 | 取引先メールアドレス | supplier_email | リンク(Email) | ✅ |
| 3 | 業務種別(想定) | gyomu_shubetsu | 複数選択 | — |
| 4 | 書類送付先(あれば) | shorui_soufu | 文字列複数行 | — |
3.1.2 Phase D:取引先本人入力(Microsoft Forms 経由)
19フィールド:基本情報(5-11)/ 連絡先(12-17)/ インボイス・税務(18)/ 銀行口座 🔒(19-24)。詳細は app-supplier-master.md §2.2 参照。
3.1.3 Phase F:高橋さん入力(最終確定)
9フィールド:著作権者コード(PK・THINK's 採番)/ 源泉徴収税率 / 支払方法 / ステータス / 取引先タイプ / 表記揺れ別名サブテーブル / 備考。
3.2 ステータス遷移
stateDiagram-v2
[*] --> input_requesting: 編集者が新規登録
[*] --> paper_operation: メアド空で登録
input_requesting --> input_done: 取引先がフォーム送信
input_requesting --> expired: 14日経過
expired --> input_done: フォーム送信
expired --> archived: 30日経過
paper_operation --> confirmed: 高橋さん紙回収+手動入力
input_done --> confirmed: 高橋さんTHINK's転記+コード反映
confirmed --> suspended: 取引停止
suspended --> archived
archived --> [*]
confirmed --> [*]: 発注書 lookup 可能
3.3 権限設計(二層防御)
| フィールドカテゴリ | 編集者 | 高橋さん | 経理 | 窪田部長 |
|---|---|---|---|---|
| 基本情報 | 閲覧 ✅ | 編集 ✅ | 閲覧 ✅ | 閲覧 ✅ |
| 🔒 機密(口座等) | ❌ | 編集 ✅ | 編集 ✅ | ❌ |
| ステータス・THINK'sコード | 閲覧 ✅ | 編集 ✅ | 閲覧 ✅ | 閲覧 ✅ |
JS の
setFieldShown は UX 最適化のみ。本物の制御は必ず kintone 権限で別途設定。
3.4 ビュー設計(9ビュー)
「自分の登録」「取引先入力依頼中」「取引先入力済(高橋確認待ち)」「期限切れ警告」「正式登録完了」「紙運用」「アーカイブ」「取引先タイプ別」「機密情報ビュー」の9ビューを用意。詳細は app-supplier-master.md §6。
4.1 業務種別5パターン(5/19高橋MTG確定)
| # | 業務種別 | 支払起算日 | 日付ラベル | 使用想定 |
|---|---|---|---|---|
| ① | 書籍デザイン等 | 校了日基準 | 受領(校了)予定日 | 高(最頻) |
| ② | 撮影・校正・拡材等 | 納品日基準 | 納品予定日 | 高(営業の販促物も含む) |
| ③ | だいわlog 連載 | 納品日基準 | 受領予定日(毎月) | 中(複製機能で対応) |
| ④ | リーディング | 納品日基準 | 納品予定日 | 低(ほぼ未使用) |
| ⑤ | その他(例外) | 選択 | 任意 | 🚫 原則使用禁止・経理 高橋さん事前相談必須 |
4.2 新刊レコード①連携(ADR-001 反映)
v1(6月リリース)は App85 直接 lookup、v2(7-8月)で新刊レコード①連携に切替。
sequenceDiagram
autonumber
actor E as 編集者
participant PO as 発注書アプリ
participant SH as 新刊レコード①
participant SF as 新刊フロー① UI
E->>PO: 「書籍/企画」検索
PO->>SH: lookup(新刊番号)
alt 該当書籍あり
SH-->>PO: 書名/著者/ISBN/担当編集者を返す
PO->>PO: 発注書に自動コピー
else 該当書籍なし
SH-->>PO: ヒットなし
PO->>E: 「📚 新刊フローで新規登録する」リンク表示
E->>SF: 新刊フロー① で最小入力
SF-->>E: 新刊番号取得
E->>PO: 戻って lookup 選択
end
4.3 複製機能(CORE 7)
自分の過去発注書を複製して新規作成。だいわlog連載月次発注 / 定期取引先(チコルズ等)/ 同一書籍の追加発注で入力負荷-70〜80%削減。
4.4 PDF生成・「支払依頼を作成」ボタン
確定ステータスで PDF 自動生成(C案 Cloud Run + Puppeteer or jsPDF)。「支払依頼を作成」ボタンで支払依頼アプリへ自動派生、取引先・書籍・金額を引き継ぎ。
5.1 主要フィールド
| カテゴリ | フィールド | 備考 |
|---|---|---|
| 基本 | 支払依頼番号 / 申請日 / ステータス / 申請者 | 派生時自動セット |
| 派生情報 | 発注書(lookup)/ 取引先(コピー)/ 書籍(コピー) | 発注書から引き継ぎ |
| 金額 | 金額確定値 / 修正理由 / 支払日(高橋入力) | 金額変更時は修正理由必須 |
| 経理連携 | THINK'sコード / freee取引ID / 月次CSV出力フラグ | 月次エクスポートで使用 |
5.2 ワークフロー(2ステップ)
編集者申請 → 高橋さん最終確認・支払日入力。河合さんは Phase 1 では関与なし(5/19 高橋MTG訂正)。
5.3 月次CSVエクスポート
毎月末に「支払予定月」フィルタでCSV出力。THINK's印税入力・freee会計取引登録への手動連携。Phase 3で自動化検討。
6.1 データモデル
erDiagram
BISHO_MASTER ||--o| SHINKAN : "lookup 書誌コード/ISBN"
SHINKAN ||--o{ PURCHASE_ORDER : "lookup 新刊番号"
BISHO_MASTER {
string shosi_code PK "書誌コード App85 既存"
string isbn_code "ISBN"
string title "書名"
}
SHINKAN {
string shinkan_no PK "新刊番号"
lookup bisho "書誌マスタ参照"
user editor "担当編集者 lookup元"
date deliver_fix "搬入確定日"
}
PURCHASE_ORDER {
string order_no PK "発注番号"
lookup shinkan "新刊レコード参照 lookup先変更"
lookup supplier "取引先参照"
}
6.2 lookup 自動コピー項目
| 発注書側フィールド | コピー元(新刊レコード①) | 元データ(App85) |
|---|---|---|
| 書名(コピー) | title | App85 title |
| 著者(コピー) | author1 | App85 著者1 |
| ISBN(コピー) | isbn_code | App85 isbn_code |
| 本体価格 | price | App85 price |
| 判型 | hankei | App85 判型1+判型2 |
| 担当編集者 ⭐ | editor(USER_SELECT) | —(新刊レコード①固有) |
6.3 T1書名追従
新刊レコード①の書名が変更されると、関連発注書の書名(コピー)を一括更新。kintone JS の app.record.edit.submit.success イベントで実装。詳細は §8 §7 title-sync.js。
6.4 段階移行(再掲)
v1(6月、App85直接) → v2(7-8月、新刊レコード①切替)→ v3(9月〜、編集部浸透)。詳細は §2.4 + integration-with-shinkan-flow.md §7。
7.1 Power Automate 3フロー構成
Flow_SupplierInvite(取引先招待メール送信)
| 項目 | 内容 |
|---|---|
| トリガー | kintone「レコード作成時」(status=input_requesting) |
| 主要アクション | レコード詳細取得 → HMAC token 生成(Office Script)→ ユニークURL構築 → Outlook メール送信(To: 取引先 / CC: 編集者+高橋) |
| エラー対応 | 3回リトライ → 失敗継続なら高橋さん通知 + kintone レコードにフラグ |
Flow_FormResponse(フォーム回答→kintone反映)
| 項目 | 内容 |
|---|---|
| トリガー | Microsoft Forms「新しい応答が送信されるとき」 |
| 主要アクション | 応答詳細取得 → HMAC検証 + 有効期限チェック → 冪等性確認 → kintone レコード更新(status=input_done、機密フィールドはセキュア入出力)→ 高橋さん通知 |
| エラー対応 | トークン無効時は取引先に再送メール、kintone通信失敗時は標準リトライ |
Flow_ScheduledReminder(督促・期限切れ・アーカイブ)
| 項目 | 内容 |
|---|---|
| トリガー | 毎日 09:00 JST スケジュール |
| 主要アクション | kintone レコード走査(status=input_requesting/expired)→ 経過日数判定 → 7日経過督促 / 14日 expired / 30日 archived |
7.2 Microsoft Forms 設計(7セクション・24質問)
イントロ + 隠し質問
kintone_id / token / exp の3つを隠し質問として保持(URL事前入力)
本人確認(二要素化)
「{henmei}様で合っていますか?」確認チェック必須。「いいえ」選択時はエラー画面へ分岐
基本情報・連絡先・インボイス
13フィールド(氏名カナ・住所・電話・個人/法人・マイナンバー有無・居住区分・インボイス登録状況)
銀行口座(機密)
6フィールド。SSL暗号化 + 機密情報セキュア入出力 + kintone権限分離の三重防御
7.3 HMAC セキュリティ設計
https://forms.office.com/r/{form_id}?
kintone_id=12345&token=Hk8Bc3aF2pQv9ZdYxNmL4Rk6Wj7T0sUe&exp=1748908800
// Office Script で HMAC-SHA256 生成
function main(workbook, kintone_id, exp): string {
const secret = getNamedItem("HMAC_SECRET");
const message = `${kintone_id}|${exp}`;
return computeHmacSha256(secret, message).slice(0, 32);
}
// Power Automate 検証(Flow_FormResponse)
@if(and(greater(int(exp), div(ticks(utcNow()), 10000000)),
equals(token, outputs('Office_Script_HMAC')?['body/result'])), 'valid', 'invalid')
| セキュリティ要素 | 対策 | 効果 |
|---|---|---|
| URL推測攻撃 | HMAC-SHA256 + 32文字署名(2^256通り) | 総当り実質不可能 |
| URL漏洩 | 有効期限 7日 を URL に埋込 | 古いURL無効化 |
| シークレット管理 | SharePoint List(権限制御) | フロー所有者のみアクセス |
| 第三者不正回答 | token + 取引先メアド + 本人確認チェックの三重検証 | URL知らないと回答不可 |
8.1 ファイル構成
scripts/kintone-js/
├── common/ # 共通 config + utils + API ラッパー
├── purchase-order/ # 発注書アプリ JS
├── supplier-master/# 取引先マスタ JS
├── payment-request/# 支払依頼 JS
└── book-master-link/ # 書籍マスタ × 新刊レコード連携 JS
8.2 主要 JS 機能(9種)
| # | 機能 | 対象アプリ | イベント |
|---|---|---|---|
| 1 | 新刊レコード① lookup → 自動コピー | 発注書 | change.shinkan_lookup |
| 2 | 業務種別5パターン動的切替 | 発注書 | change.gyomu_shubetsu |
| 3 | 複製機能(自分の発注のみ) | 発注書 | detail.show |
| 4 | 機密フィールド表示制御 | 取引先マスタ | detail.show / edit.show |
| 5 | ペンネーム + 別名 検索拡張 | 取引先マスタ | change.supplier_lookup |
| 6 | 「情報更新を依頼」ボタン | 取引先マスタ | detail.show |
| 7 | T1書名追従 | 新刊レコード① | edit.submit.success |
| 8 | 「支払依頼を作成」ボタン | 発注書 | detail.show |
| 9 | PDF生成ボタン | 発注書 | detail.show |
8.3 実装スケジュール
| Step | 対象 | 工数 | 期間 |
|---|---|---|---|
| 1 | 取引先マスタ JS(confidential / search-expand / update-button) | 2日 | Step 1 後半 |
| 2 | 発注書 JS(lookup-shinkan v1暫定 / 業務種別 / 複製 / PDF生成) | 4日 | Step 2 |
| 3 | 支払依頼 JS | 2日 | Step 3 |
| 4 | T1書名追従 JS(v2 切替時) | 1日 | 7-8月 |
| 合計 | 9日 | — | |
9.1 全体スケジュール
gantt
title Phase 1 リリーススケジュール
dateFormat YYYY-MM-DD
section Step 1-3
マスタ整備 :a1, 2026-05-20, 9d
発注書アプリ実装 v1 :a2, after a1, 13d
支払依頼アプリ実装 :a3, after a2, 10d
section パイロット
Stage 1 総務UAT :b1, 2026-07-01, 7d
Stage 2 編集部 :b2, 2026-08-01, 14d
section v2 切替
新刊フロー①完成待ち :c1, 2026-07-01, 30d
発注書アプリ v2 切替 :c2, after c1, 7d
section 全展開
編集部全展開 :d1, 2026-09-01, 14d
9.2 取引先マスタ初期投入
| 項目 | 内容 |
|---|---|
| ソース | THINK's 著作権者マスタ CSV(2,487件・38列・cp932、5/15受領済) |
| クレンジング | NFKC正規化、異常値処理、ペンネーム運用フラグ正規化(284件)、重複候補マージ(8グループ19件) |
| 投入工数 | 4日(テスト100件 + 検証 + 全件 + 検証) |
9.3 段階パイロット
総務UAT(7月)
高橋さん + 窪田部長で機能検証。期間1週間、日次レビュー。
編集部パイロット(8月)
編集部 2-3名で実業務利用。期間2週間、週次レビュー。
編集部全展開(9月)
編集部全員(ライセンス追加後)。旧Excel廃止アナウンス + ヘルプデスク窓口設置。
9.4 Phase 1 完了判定KPI
| # | 指標 | 目標 |
|---|---|---|
| 1 | 編集部 kintone 発注書使用率 | 8割以上 |
| 2 | 表記揺れ差戻し件数 | 0件 |
| 3 | 高橋さん月次支払処理時間 | -30%以上 |
| 4 | 取引先マスタ正式登録完了率 | 8割以上 |
10.1 テスト階層・カバレッジ
| 階層 | 領域 | 件数 | 担当 |
|---|---|---|---|
| 単体 | kintone JS(9機能) | 9件 | 西川 |
| 単体 | Power Automate(3フロー) | 9件 | 西川 |
| 単体 | Microsoft Forms | 5件 | 西川 |
| 統合 | kintone × Power Automate | 6件 | 西川 |
| E2E | 取引先マスタ E2E | 3件 | 西川 + 高橋さん |
| UAT | Stage 1 総務UAT | 10ケース | 高橋さん |
| UAT | Stage 2 編集部パイロット | 15ケース | 編集部2-3名 |
10.2 重要 E2E シナリオ
- E2E-001:編集者新規取引先登録 → メール送信 → 取引先フォーム入力 → kintone反映 → 高橋さんTHINK's転記 → 発注書 lookup(成功パス)
- E2E-002:メアド無し → 紙運用 → 高橋さん郵送回収 → kintone手動入力(例外パス)
- E2E-003:既存取引先の情報更新(口座変更等)(更新パス)
- E2E-004:HMAC改竄検知 → 再送メール(セキュリティ)
- E2E-005:7日経過督促 → 14日 expired → 30日 archived(タイマー)
- E2E-006:発注書作成 → 派生 → 支払依頼 → 月次CSV エクスポート(業務フロー)
10.3 セキュリティ検証
- kintone 権限制御:編集者が機密フィールドにアクセスできないこと(JSなしでも)
- HMAC 検証:改竄URL、期限切れURL の拒否
- 個人情報マスキング:Power Automate 実行履歴・SharePoint ログに口座情報が平文で記録されていないこと
11.1 西川判断で決められること
| # | 論点 | 判断目処 |
|---|---|---|
| a1 | PDF生成方式(C案 Cloud Run+Puppeteer vs jsPDF 内製) | Step 2 着手前 |
| a2 | HMAC 実装手段(Office Script vs Azure Functions) | Step 2 着手時PoC |
| a3 | SharePoint List vs Azure Key Vault(シークレット保管) | Step 2 着手時 |
| a4 | kintone JS のコード管理(GitHub オンリーで足りるか) | Step 1 着手前 |
11.2 先方(大和書房)に確認が必要
| # | 論点 | 確認先 |
|---|---|---|
| b1 | 🔴 Power Automate Premium 契約 + 西川用 M365 アカウント発行 ステータス | 窪田部長(依頼済) |
| b2 | 🔴 著作権者マスタ項目「必須/任意・入力者」区分シート | 高橋さん(返送待ち) |
| b3 | 🔴 編集部 kintone ライセンス追加状況 | 窪田部長 |
| b4 | 機密フィールド経理ロールの正式メンバー(小山さん他) | 高橋さん |
| b5 | Outlook 送信元アドレス(no-reply@daiwashobo.co.jp 発行可否) | 情シス |
| b6 | 大和書房ロゴ画像・配色指定(Microsoft Forms用) | 窪田部長 |
| b7 | テスト環境 kintone の用意可否 | 窪田部長 |
11.3 新刊フロー側と連携が必要
| # | 論点 | 影響 |
|---|---|---|
| c1 | 新刊フロー① の APP_ID 確定 | kintone JS の lookup 先設定(v2切替時) |
| c2 | 新刊フロー側 §8 b4「担当編集者の管理元」 | 発注書 lookup 設計に影響 |
| c3 | 新刊フロー側 §8 c1「制作部の新刊リスト 実物」 | lookup コピー項目の網羅性 |
| c4 | 新刊フロー側 §8 c9「App85 書誌マスタ全67列ヘッダー」 | lookup マッピング最終確定 |
| c5 | 新刊フロー①のリリースタイミング | v2 切替スケジュール |
12.1 purchase-order PJ ドキュメント
| カテゴリ | ドキュメント | 説明 |
|---|---|---|
| 戦略 | v3.4 ブループリント | クライアント向け Phase 1 戦略・スコープ |
| 方針決定 | ADR-001 | 書籍マスタ → 新刊フロー連携 方針転換 |
| 仕様 | 取引先マスタアプリ | 32フィールド・ステータス遷移・権限・JS実装 |
| 仕様 | 発注書アプリ v2 | 5パターン統合・新刊レコード①連携・複製機能 |
| 仕様 | 支払依頼アプリ | 発注書からの派生・月次CSVエクスポート |
| 仕様 | 新刊フロー連携要件 | 段階移行・lookup自動コピー・T1書名追従 |
| 仕様 | 書籍マスタ縮減版 | v3.3 §14 廃止記録・新刊フロー責務委譲 |
| 仕様 | Power Automate 3フロー | SupplierInvite / FormResponse / ScheduledReminder |
| 仕様 | Microsoft Forms 設計 | 取引先入力フォーム 7セクション・24質問 |
| 仕様 | kintone JS 実装 | 9主要機能の実装スケッチ |
| 計画 | 移行・リリース計画 | 段階パイロット・KPI・ロールバック |
| 計画 | アダプション戦略 | 編集部浸透施策 |
12.2 新刊フロー PJ ドキュメント
| ドキュメント | 説明 |
|---|---|
| 新刊フロー 4アプリ詳細設計書 | 2026-06-05 キックオフ確定スコープ |
| 新刊フロー キックオフ議事録 | 4アプリ合意・ロードマップ |
| 新刊フロー ビジョン | 戦略全体像 |
12.3 議事録
- 5/19 高橋さん60分MTG — 業務種別5パターン確定 + 新規取引先登録フロー合意
- 4/28 窪田部長MTG — kintone第1弾選定・並行モデル合意