大和書房 × オモシク / kintone DXプロジェクト Phase 1

kintone 発注書アプリ
Phase 1 最終形ビジョン

編集部 → 総務(高橋)の業務委託発注 〜 支払依頼フローを kintone に集約し、4種フォーマット統合・PDF自動出力・取引先表記揺れ撲滅を実現する。

📅 2026-05-17 更新(5/19 高橋MTG 反映予定) 🎯 Phase 1: 5月着手 → 6月リリース → 7月安定運用 👥 推進: 西川(オモシク)/ 窪田(総務)/ 高橋(経理)
-70%
発注書1件作成時間
(10分 → 3分)
0件
表記揺れ差戻し件数
(月5-10件 → 0件)
-50%
高橋 月次支払処理時間
(案件あたり)
100%
PDF生成自動化
(手動 → ボタン1つ)
FINAL VISION

1. 最終形:何が実現されるか

編集部担当者が kintone 1画面で発注書を作成 → PDFが自動生成され取引先へ送付 → 同じレコードから支払依頼が派生 → 総務(高橋)が月次まとめて承認、という一気通貫の運用を実現する。

CORE 1

発注書 4種統合フォーム

デザイン等・撮影等・だいわlog連載・リーディング を1つの kintone フォームに集約。業務種別 × 支払起算日 のドロップダウン選択で 4 種の Excel フォーマットを完全に吸収。

CORE 2

PDF 自動生成

「PDF生成」ボタン1つで規定レイアウトの発注書PDFを自動生成。kintoneレコードに添付ファイルとして保管され、紛失リスクゼロ・どこからでも参照可能。

CORE 3

取引先マスタ統一

「鷗来堂」「株式会社鷗来堂」「Ouraidou」が全部同じ取引先と認識される、表記揺れ吸収マスタ。高橋さんの THINKs 登録コード照合作業を大幅短縮。

CORE 4

支払依頼へワンクリック派生

発注書から「支払依頼を作成」ボタンで支払依頼レコードを自動生成。金額変更がある場合は理由を必須入力させ「発注書を作り直さない」運用ミスを構造的に防止。

CORE 5

シンプル承認ワークフロー

編集部担当者 → 総務(高橋:支払日入力・最終確認)の 2ステップ を kintone プロセス管理で実装。河合さんは出版契約フロー(Phase 3)の担当で、本PJ(発注・支払)には関与しない。

CORE 6

月次集計・経理連携

支払予定月別の集計ビューで高橋さんの月次処理を効率化。CSV エクスポートで THINKs 印税入力・freee 会計取引登録へ連携(Phase 3で自動化)。

SYSTEM ARCHITECTURE

2. システム全体像

関係者・データの流れを1枚に集約。kintoneを中心に、THINKs・freee と疎結合で連携する。SharePoint は発注書PDF保管としては廃止(kintone添付ファイルで一元化)。

flowchart TB
    subgraph 編集部["👥 編集部担当者"]
        E1[発注書作成]
        E2[支払依頼へ派生]
    end

    subgraph kintone["☁️ kintone(中核)"]
        APP1[発注書アプリ
4種統合フォーム] APP2[支払依頼アプリ
ワークフロー付] M1[(取引先マスタ
表記揺れ吸収)] M2[(書誌マスタ
既存 1,226件)] end subgraph 総務["🏢 総務"] T2[高橋:支払日入力・最終確認] end subgraph 取引先["✉️ 取引先"] TS[著作権者:
デザイナー/著者/
イラストレーター等] end subgraph 外部["🔗 外部システム"] TH[(THINKs
著作権者マスタ 2,487件)] FR[freee会計] end E1 ==> APP1 APP1 --lookup自動--> M1 APP1 --lookup自動--> M2 APP1 ==PDF自動生成==> TS E2 ==> APP2 APP1 ==派生ボタン==> APP2 APP2 ==> T2 T2 -.月次CSV手動DL.-> FR T2 -.月次CSV手動DL.-> TH TH -.初期CSV手動取込
2026-05-15 受領済.-> M1 style APP1 fill:#dbeafe,stroke:#1a56db style APP2 fill:#cffafe,stroke:#0891b2 style M1 fill:#d1fae5,stroke:#16a34a style M2 fill:#d1fae5,stroke:#16a34a
━━▶太線(実線):自動処理(kintone 内蔵・JS・lookup・添付保管)
━▶細線:自動だが補助的(lookup 表示等)
┄┄▶点線:人が介在する手動操作(CSVダウンロード・取込)
INSIGHT
kintone は「業務の中核」、THINKs/freee/SharePoint は「外部の補助」という位置付け。すべての発注・支払データが kintone に集約されるため、過去履歴の検索・分析が一画面で完結する。
UI / UX MOCKUP

3. UI / UX イメージ

編集部担当者が日常使うフォームの叩き台。実際のkintone標準UIと比較しながらレビュー・改善する。

📝 発注書 新規作成画面(業務種別 4種をタブで切替)

現状の Excel 4 種フォーマット(デザイン等/撮影等/だいわlog/リーディング)を、kintone 1 フォームに統合。 「業務種別」を選ぶだけで、支払起算日・日付ラベル・特記文言・PDFテンプレが自動切替されます。

📊 4 種フォーマットの差分マトリクス(共通部分は省略)
項目 ① デザイン等 ② 撮影・校正等 ③ だいわlog 連載 ④ リーディング
支払起算日 校了日基準 納品日基準 納品日基準 納品日基準
日付ラベル 受領(校了)予定日 納品予定日 受領予定日(毎月) 納品予定日
書籍/企画 通常書籍 通常書籍 連載企画(だいわlog フィルタ) 翻訳企画(権利獲得前)
取引先例 デザイナー フォトグラファー / 校正者 コラムニスト リーダー / 翻訳家
特記事項 インボイス相当の支払通知書を弊社送付 翻訳契約発生時に印税に含む
共通項目 基本情報(発注番号・発注日・担当編集者)/ 取引先選択 / 報酬明細 / 締日(毎月25日)/ 支払日(翌月20日)/ ハラスメント窓口記載
cy6vg2ycifc8.cybozu.com / 発注書 / 新規作成 下書き
📌 業務内容(タブにより変化)
業務種別 *
デザイン等
支払起算日
校了日基準(業務種別から自動)
取引先 *
🔍 合同会社チコルズ(山田 知子)
書籍/企画 *
🔍 ロン毛メガネ『ずぼら薬膳』
報酬明細
表1デザイン / ¥120,000
本文DTP / ¥55,000
本文図版代 / ¥15,000(3,000×5点)
📌 納品・支払条件(タブにより変化)
受領(校了)予定日
2025-09-10
支払期日
校了日を基準に、毎月25日締め/翌月20日支払い(自動表示)
cy6vg2ycifc8.cybozu.com / 発注書 / 新規作成 下書き
📌 業務内容(タブにより変化)
業務種別 *
撮影・校正等
支払起算日
納品日基準(業務種別から自動)
取引先 *
🔍 株式会社鷗来堂(校正者)
書籍/企画 *
🔍 ロン毛メガネ『ずぼら薬膳』
報酬明細
本文校正(素読み・文字統一・事実確認) / 文字単価 ¥0.45
概算 215,000 文字 → ¥96,750
📌 納品・支払条件(タブにより変化)
納品予定日
2025-09-10
支払期日
納品日を基準に、毎月25日締め/翌月20日支払い(自動表示)
cy6vg2ycifc8.cybozu.com / 発注書 / 新規作成 下書き
📌 業務内容(タブにより変化)
業務種別 *
だいわlog 連載
支払起算日
▼ 納品日基準
取引先 *
🔍 ●●(コラムニスト)
著者名/連載企画名 *
🔍 ●●『test(仮)』連載 ※書誌マスタの「だいわlog」フィルタで絞込
報酬明細
だいわlog 連載原稿料 / 掲載1回分につき ¥●●●
📌 納品・支払条件(タブにより変化)
受領予定日
●●年●●月●●日 より毎月●●日
⚠️ 特記事項
適格請求書(インボイス)に該当する支払通知書を弊社より送付いたします。
※ PDF にも自動印字
cy6vg2ycifc8.cybozu.com / 発注書 / 新規作成 下書き
📌 業務内容(タブにより変化)
業務種別 *
リーディング
支払起算日
▼ 納品日基準
取引先 *
🔍 ●●(リーダー)
企画(権利獲得前)*
🔍 ●●『test(仮)』※翻訳企画モード
報酬明細
翻訳企画・権利獲得前下読み / ¥●●●
📌 納品・支払条件(タブにより変化)
納品予定日
●●年●●月●●日
⚠️ 特記事項
企画獲得時は翻訳業務についての業務委託契約書を結び、下読みの報酬は翻訳業務の印税に含むものとします。
※ Phase 2 で業務委託契約レコードと自動紐付け可能

📄 確定後:PDF自動生成 + 派生ボタン(4種共通)

発注書 #2026-0042 / 詳細 ✓ PDF生成済
📄 発注書_2026-0042_合同会社チコルズ.pdf
クリックでプレビュー / ダウンロード
支払依頼を作成 → PDFをダウンロード 複製して新規作成
関連レコード: 同じ書籍の発注書 3件 / 派生済み支払依頼 1件
UX POINT
Excel と比較した時短ポイント:① 書籍・取引先選択で「著者名・適格番号・住所」が自動入力 → 転記ゼロ。② 業務種別選択で支払条件が自動表示 → 暗記不要。③ 合計金額が自動計算。
⚙️ 参考:このタブ切替・自動入力・PDF生成ボタンの裏で動く「JS カスタマイズ」の中身(クリックで展開)

kintone は標準でも入力フォームとして機能するが、業務で実用するには JavaScript で「賢い動き」を仕込む 必要がある。これがないとアプリが「ただの Excel もどき」になって誰も使わない。

やらせたい動き 標準機能で可能? JS必要 実装イメージ
業務種別「デザイン」→「校了予定日」、「撮影」→「納品予定日」のラベル自動切替 ❌ できない app.record.edit.change.業務種別 イベントで .label を書換
著作権者を選んだら、源泉徴収税率(10.21%/0%)が自動取得→計算反映 △ lookup 可、計算は不可 lookup で取得した源泉率を「金額×税率」で自動セット
報酬明細テーブルの単価×数量=金額の自動計算+税抜・税込切替 △ 計算フィールド可、切替はJS change.報酬明細 でテーブル合計を再計算
著作権者名で検索したとき「ペンネーム」「表記揺れ別名」もヒット ❌ できない lookup ピッカーをカスタマイズ、複数フィールドで一括検索
「支払依頼を作成」ボタンで支払依頼アプリに自動でレコード作成、取引先・書籍・金額を引き継ぎ ❌ できない ✅ 必須 kintone REST API でPOST、URLパラメータで発注書ID渡し
「PDF生成」ボタンを押したらPDFを作って添付ファイル欄に格納 ❌ できない ✅ 必須 Cloud Run へHTTPS呼出→PDFバイナリ受領→kintone APIで添付
取引先が マスタにない場合の警告「高橋さんへ追加依頼」 ❌ できない lookup 結果が空の場合、警告メッセージ表示 + マスタ追加リンク
支払依頼で 金額が発注書と異なる場合「修正理由」を必須化 △ 条件分岐は標準で可能だが弱い submit 前にバリデーション、未入力ならblock
JS COST
JSカスタマイズの実装工数は 純3日(リードタイム4日)。これは Phase 1 のコア体験を作り込む最重要工程。コードは scripts/kintone-js/ に Git 管理し、kintone へは「JSカスタマイズ機能」経由でアップロード。
USER FLOW BY PERSONA

4. ユーザー別 E2E フロー

関係者ごとに、いつ・何を・どう操作するかを整理。各ペルソナのストーリーが完結することを確認する。

編集部担当者
発注書作成 → PDF送付 → 支払依頼起票
1取引先と業務・報酬を決定(口頭・メール)
2kintone「発注書」アプリで新規作成
3書籍・著作権者を選択(lookupで自動入力)
4業務種別・報酬明細・予定日を入力
5保存 → 発注番号 2026-NNNN 採番
6「PDF生成」ボタンでPDFを自動添付
7PDFをメールで取引先へ送付
━ 納品確認後 ━
8発注書詳細画面で「支払依頼を作成」
9金額変更があれば修正値+理由を入力
10「申請」ボタン → 高橋へ通知
高橋さん(総務・経理)
支払日入力・最終承認・月次CSV連携
1「支払日未入力」ビューを開く(日次)
2各レコードの振込先・金額を最終確認
3支払日(振込予定日)を入力
4「最終承認」 → ステータス=完了
━ 月次処理 ━
5「月次CSV出力用」ビューを開く
6CSV エクスポート(ボタン1つ)
7THINKs 印税入力に投入(手動転記)
8freee に取引登録(手動転記、Phase 3でAPI化検討)
※ 河合さんはPhase 1では本フローに関与せず(出版契約フローのみ Phase 3 で担当)
END-TO-END DATA FLOW

5. E2E データフロー(ユーザー × システム × データ)

1件の発注 〜 支払完了までの全イベントを、3レイヤーで可視化。

sequenceDiagram
    autonumber
    participant U as 編集部担当者
    participant K as kintone
(発注書/支払依頼) participant DB as マスタ
(著作権者/書籍) participant PDF as PDF生成
(Cloud Run/Puppeteer) participant T as 高橋 participant X as freee/THINKs Note over U,X: ── 1. 発注フェーズ ── U->>K: 新規発注書を作成 K->>DB: lookup(著作権者・書籍) DB-->>K: 取引先情報・書籍情報を返却
(源泉徴収税率・インボイス状況含む) U->>K: 業務種別・明細を入力 K->>K: 合計金額・税額・源泉自動計算 U->>K: 保存(ステータス=確定) K->>PDF: 「PDF生成」ボタン押下 PDF-->>K: PDF を添付ファイルに保管 U->>U: PDFをメールで取引先送付 Note over U,X: ── 2. 納品〜支払依頼フェーズ ── Note over U: 取引先から成果物受領 U->>K: 発注書から「支払依頼を作成」ボタン K->>K: 発注書情報を引き継いで新規
支払依頼レコード作成 U->>K: 金額確定値・修正理由を入力 U->>K: 「申請」ボタン → ステータス=高橋確認中 Note over U,X: ── 3. 支払処理フェーズ ── T->>K: 「支払日未入力」ビューを確認 T->>K: 振込先口座・金額の最終確認 T->>K: 支払日(振込予定日)を入力 T->>K: 「最終承認」 → ステータス=完了 Note over T,X: ── 月次バッチ ── T->>K: 「月次CSV出力用」ビューを開く K-->>T: CSV エクスポート T->>X: THINKs 印税入力 / freee 取引登録(手動転記)
DATA SCHEMA

6. データテーブル蓄積イメージ(スキーマ)

kintone は 1アプリ = 1テーブル。フォームに入力された内容がレコードとして蓄積され、検索・集計・CSV出力できる。Phase 1 で動く4テーブルの中身を可視化。

flowchart LR
    subgraph master["📁 マスタテーブル"]
        M1[("著作権者マスタ
2,487件
38列")] M2[("書籍マスタ
1,226件
既存ID 85拡張")] end subgraph trx["📁 トランザクションテーブル"] T1["発注書
月50-150件
編集部が起票"] T2["支払依頼
月50-150件
発注書から派生"] end M1 -->|lookup
著作権者コード| T1 M2 -->|lookup
ISBN| T1 T1 -->|派生ボタン| T2 M1 -->|lookup
支払先| T2 M2 -->|lookup
関連書籍| T2 style M1 fill:#d1fae5,stroke:#16a34a style M2 fill:#d1fae5,stroke:#16a34a style T1 fill:#dbeafe,stroke:#1a56db style T2 fill:#cffafe,stroke:#0891b2

📊 4テーブルの想定蓄積件数

テーブル 種別 初期件数 増分 キー 主な用途
著作権者マスタ マスタ 2,487件(受領済) 年+50-100件 著作権者コード 発注書・支払依頼から lookup 参照
書籍マスタ マスタ(既存ID 85拡張) 1,226件 年+200件 ISBN 同上、書籍別の集計軸
発注書 トランザクション 0件(運用開始時) 月50-150件 = 年600-1,800件 発注番号(自動採番) 編集部が日常的に作成、PDF出力、支払依頼の起点
支払依頼 トランザクション 0件(運用開始時) 月50-150件 = 年600-1,800件 支払依頼番号(自動採番) 発注書から派生、高橋承認、月次CSV出力

📁 発注書テーブル 主要フィールド詳細

カテゴリ フィールド名 備考
基本情報発注番号文字列(自動採番)2026-0042 など
発注日日付デフォルト: 今日
担当編集者ユーザー選択デフォルト: ログインユーザー
ステータスドロップダウン下書き / 確定 / PDF生成済 / 取消
取引先・書籍著作権者lookupペンネーム・別名でも検索可
書籍/企画lookupISBN or 企画名で検索
業務内容業務種別ドロップダウンデザイン等 / 撮影・校正等 / だいわlog / リーディング
業務内容詳細テキストエリア例: 表1デザイン、本文DTP
報酬明細サブテーブル内容/単価/数量/金額(複数行)
合計金額(税抜/税込)計算フィールド自動計算
納品・支払受領/納品予定日日付業務種別によりラベル切替(JS)
支払起算日タイプドロップダウン校了日 / 納品日(業務種別から自動)
支払日(計算)計算フィールド翌月20日
出力PDF添付添付ファイル「PDF生成」ボタンで自動格納

📁 支払依頼テーブル 主要フィールド詳細

カテゴリ フィールド名 備考
基本情報支払依頼番号文字列(自動採番)PR-2026-0042
申請日日付デフォルト: 今日
ステータスプロセス管理申請中 / 高橋確認中 / 完了 / 差戻
発注書参照発注書lookup派生時に自動入力
書籍/企画lookup発注書からコピー
支払内容支払先表記文字列取引先名 or ペンネーム(編集可)
金額確定値(税抜)数値発注書からコピー、変更可
金額修正理由テキストエリア発注書と異なる場合のみ必須(JSで強制)
金額(税込)計算フィールド源泉徴収反映可
支払情報支払予定日計算フィールド支払起算日 + 締日 + 支払日から自動算出
支払日(振込)日付高橋が入力、最終承認時
振込先確認チェックボックス高橋が確認後ON
その他高橋メモテキストエリア編集部からは非表示
SHCEMA POINT
「データは消えずに永続保管される」のがkintone の最大の強み。月50-150件の発注書が積み上がれば、半年後には「あの著作権者には今年いくら払った?」「この書籍の原価はいくら?」がボタン1つで集計できる。Excel 個別管理では絶対にできない検索性が手に入る。
PDF GENERATION

7. PDF生成方式(C案採用、内製で月¥0〜数百円)

発注書を kintone から PDF として出力する仕組み。複数方式を検討した結果、Cloud Run + Puppeteer による内製(C案) を採用方針とする。

方式 月額 実装工数 保守 品質 採否
A. kViewer プラグイン ¥9,800 1日 低(GUI) ★★★ 候補(コスト発生)
B. プリントクリエイター ¥9,000 1日 低(GUI) ★★★ 候補(コスト発生)
C. Cloud Run + Puppeteer ← 採用 ¥0〜数百 4-5日 中(年0.5-1日) ★★★ ✅ 採用
D'. kintone JS + jsPDF + html2canvas
(注文書ジェネレーターと同方式)
¥0 3-4日 ★★(画像PDF) 予備案(品質要件次第で切替)

🏗️ C案 構成イメージ

flowchart LR
    A[編集部担当者] -->|PDF生成ボタン押下| B[kintone JS]
    B -->|HTTPS POST
レコードJSON| C[Cloud Run
Puppeteer] C -->|HTML雛形にデータ流し込み| D[HTML+CSS
レンダリング] D -->|PDF変換| E[PDFバイナリ] E -->|レスポンス| B B -->|kintone REST API| F[レコードの
添付ファイル欄に格納] F --> G[編集部担当者が
ダウンロード→メール送付] style C fill:#dbeafe,stroke:#1a56db style D fill:#cffafe,stroke:#0891b2

🛠️ 内製の保守ケース(年合計0.5〜1日程度)

発生タイミング 内容 工数
年1回GCP Node.js ランタイム deprecation 対応半日
年2-3回Puppeteer/Chrome のセキュリティパッチ反映1-2時間
必要時PDFレイアウト変更要望(社印位置等)半日〜1日
初期設計に含めればOKエラー時 Slack 通知設計込み
原則不要kintone API トークン期限切れ(無期限)
5/19 MTG で確認
PDF 品質要件次第で D'案(無料・ブラウザ内)にも切り替え可能。 確認したいこと:① 発注書PDFは印刷物として配るか?(画像PDFでは荒れる)② 社印は電子印影を貼るか? ③ レイアウト改修頻度はどの程度想定?
MONTHLY CSV EXPORT

8. 月次CSVエクスポート & ビュー設計

高橋さんの月次集計作業(現状2-3時間)を 30分以下 に短縮するための仕組み。kintone標準機能でほぼ実現可能。

🖥️ kintone ホーム画面からビューに到達する流れ

高橋さんが日次・月次にどう操作するかを実画面イメージで。

cy6vg2ycifc8.cybozu.com / ポータル(ホーム画面)
📌 ステップ① 高橋さんがkintoneにログイン → ホーム画面で「支払依頼」アプリのアイコンをクリック
📋
取引先マスタ
📚
書籍マスタ
📝
発注書
💰
支払依頼
← クリック
cy6vg2ycifc8.cybozu.com / 支払依頼 / レコード一覧
📌 ステップ② アプリ画面でビュー切替プルダウンを開く → 目的のビューを選択
▼ ビュー
デフォルト一覧
⚠️ 支払日未入力 (12件)
当月支払予定
月次CSV出力用
書籍別集計
→ 「支払日未入力」を選ぶと、
高橋さんが今日処理すべきレコードだけが一覧表示される
cy6vg2ycifc8.cybozu.com / 支払依頼 / 支払日未入力ビュー
📌 ステップ③ ビュー表示 → 各レコードをクリックして支払日入力・最終承認
支払依頼番号 申請者 著作権者 金額 支払予定日
PR-2026-0042荻田株式会社鷗来堂¥96,7502026-06-20
PR-2026-0043荻田合同会社チコルズ¥190,0002026-06-20
PR-2026-0044田中キャメレオン竹田¥120,0002026-06-20
... 残り9件
右上「エクスポート」ボタンで全件CSV出力可能(月次CSV出力用ビューと同じ動線)

📊 ビュー一覧(標準機能で事前設定)

事前にビューを設定しておけば、毎回検索せずに目的の画面に1クリックで飛べる。

対象者 ビュー名 抽出条件 用途
編集部「自分の発注書」担当編集者 = ログインユーザー自分の進行中案件チェック
「自分の支払依頼」申請者 = 自分支払処理状況確認
高橋「支払日未入力」ステータス=高橋確認中 AND 支払日=空日次の todo リスト
「当月支払予定」支払予定日 ∈ 今月月次の支払総額把握
「月次CSV出力用」ステータス=完了 AND 支払日 ∈ 指定月エクスポート対象抽出
全員「書籍別集計」書籍でグルーピング、金額合計1冊あたり総原価把握

📤 CSV エクスポートのフロー

高橋さん(毎月月末)
   │
   │【1】「月次CSV出力用」ビューを開く
   ▼
[kintone] 完了レコードを抽出表示
   │
   │【2】右上「エクスポート」→ CSV ダウンロード
   ▼
[ダウンロードフォルダ] payment_2026-05.csv
   │
   │【3-A】 THINKs 印税入力に手動投入(Phase 3で半自動化)
   │【3-B】 freee 取引登録に手動投入(Phase 3で API化検討)
   ▼
[完了] 月次経理処理完了

⏱️ Before / After

処理 Before(現状) After(Phase 1) 短縮
個別 .xlsx の収集・統合1-1.5時間0分(kintone集約済)-100%
取引先表記揺れ照合30分0分(マスタ統一済)-100%
月次集計表作成30分5分(ビュー切替)-83%
THINKs/freee 転記30分30分(手動継続、Phase 3でAPI化検討)
合計2.5-3時間35分-80%
5/19 MTG で確認(画面共有依頼)
高橋さんに 実際の THINKs/freee への転記作業を画面共有してもらう。kintone CSVのフォーマットを「後工程が一番楽になる形」に設計するため。
特に:① THINKs印税入力画面の入力項目・順序、② freee取引登録時の必須列、③ 区分・摘要等の自動入力に使える情報。
RECEIVED CSV ANALYSIS

9. いただいた CSV データから見えた、kintone 活用ポイント

高橋さんから 2026-05-15 にご共有いただいた「著作権者マスタ一覧.csv」を確認させていただきました。データの構造に合わせて kintone を設計することで、高橋さんの日々の業務がどう楽になるか を整理しました。

2,487
著作権者レコード
kintone に取り込み
38
項目数
振込先・税率まで完備
cp932
文字コード
(Shift_JIS、取り込み可)
3種
源泉徴収税率パターン
自動計算に活用

💡 kintone でこう活かせます(高橋さんの業務観点)

POINT 1

振込先の手入力がゼロになります

銀行コード、支店、口座番号、口座名義まで揃っているので、編集部が支払依頼を起票するときに 著作権者を選ぶだけで振込先情報が自動表示。転記ミスのご確認作業が不要になります。

POINT 2

「鷗来堂」「株式会社鷗来堂」が同じと認識できます

「著作権者名」と「ペンネーム」が別の項目で記録されているおかげで、表記揺れの照合作業(THINKs登録コード全件確認)が解消。編集部が誰の名前で書いても、高橋さんの目に届く時には正規名で揃います。

POINT 3

源泉徴収税率を自動判定できます

個人著者(10.21%)1,576件、法人(0%)871件、非居住者(20.42%)22件 のパターンが整っているので、支払依頼起票時に 源泉税額を自動計算。電卓いらず。

POINT 4

インボイス登録状況がフォームから見えます

登録済1,089件、未登録623件、登録予定なし226件、未確認548件 が整理可能。支払処理時に登録状況がひと目で分かる ようになります(インボイス番号自体は別管理かどうか5/19で確認させてください)。

QUESTION

👉 業務委託先と著者の判別方法を教えてください

「備考」欄に「著者」「イラストレーター」等の記載が散見されますが、明確なカテゴリ項目が見当たりませんでした。高橋さんは普段どうやって判別されていますか? 5/19で教えてください。

QUESTION

👉 軽微な気になり点もご確認させてください

「編集担当者」項目が2つあるのは「コード」と「氏名」の組合せでしょうか?/「個人法人」に「ユウチヨ」が1件あるのは入力誤り?/「論理削除」項目が全件空のため、停止された取引先のエクスポート方法も合わせて伺いたいです。

5/19 MTG ですり合わせさせてください
いただいたデータの構造に合わせて kintone マスタを設計します。上記の「👉 QUESTION」2点をクリアにできれば、Phase 1 のマスタ整備(Step 1)に即着手できる状態です。
EXTERNAL INTEGRATION FEASIBILITY

10. 外部システム連携マトリクス(フィジビリ・自動度)

どの連携が Phase 1 スコープ内か、どこまで自動化されるか、何が手動で残るかを明示。技術的な実現性(フィジビリ)と現状の不確実性も整理。

連携先 方式 データ/用途 頻度 Phase 自動化レベル フィジビリ
THINKs(著作権者マスタ) CSV 手動 DL → Python取込 著作権者マスタ初期投入
2,487件・38列(口座/源泉/インボイス完備)
初期 1 回 Phase 1 半自動 ✅ CSV受領済(2026-05-15)、想定以上にリッチ
THINKs(書誌) 既存 kintone アプリ ID 85 を活用 1,226 件の書誌マスタ
担当編集者・責了日を追加
必要時 Phase 1 完全自動
(既存活用)
✅ 既存運用あり、技術的問題なし
THINKs(取引先 RPA) 大和PC上 RPA
(Pywinauto)
取引先マスタ継続同期
(Phase 1 後)
週次/月次 Phase 2 後 半自動 🟡 PoC 必要、ビズロボ廃止判断と連動
THINKs(印税入力) kintone CSV 出力 → THINKs CSV 取込 月次印税支払対象データ 月次 Phase 3 手動 🟡 THINKs 側 CSV 取込機能の有無を窪田経由で要確認
freee 会計 kintone CSV 出力 → freee CSV 取込 月次取引登録(業務委託料・印税以外) 月次 Phase 3 手動 ✅ freee は CSV 取込標準対応、API もあり拡張可
SharePoint 非連携(kintone 内完結) 発注 PDF 保管
※既存 SharePoint 個人保管は廃止
Phase 1 完全自動
(kintone 添付)
✅ kintone 添付ファイルで代替、SharePoint 連携不要
DocuSign API 連携 業務委託契約・出版契約の電子署名発行 イベント駆動 Phase 2 完全自動 🟡 Phase 2 で技術検証、API 既存実績あり
Cloud Run + Puppeteer
(内製、C案採用)
kintone JS → HTTPS → Cloud Run 発注書 PDF 自動生成
HTML/CSS雛形でレイアウト管理
イベント駆動
(PDF生成ボタン押下時)
Phase 1 完全自動 ✅ GCP無料枠で運用可、月¥0〜数百
取引先送付
(メール)
編集部担当者が手動送付 kintone から PDF DL → メール添付 都度 Phase 1 手動 ✅ 既存運用継続、メール文面の自動化は Phase 2 検討
完全自動人間操作不要、システムが完結
半自動人間が起動、処理は自動
手動人間が操作・確認しながら実行
PHASE 1 のスコープ整理
Phase 1 で実装する連携:著作権者マスタ初期投入(CSV手動)/書誌マスタ活用(既存)/PDF生成(Cloud Run+Puppeteer 内製)/SharePoint代替(kintone内)/取引先送付(メール手動)

Phase 1 で「手動継続」する部分:取引先送付メール/月次CSV出力 → THINKs/freee 取込(月次バッチ)/著作権者マスタの追加更新

Phase 2/3 で自動化する部分:THINKs RPA 同期(Pywinauto)/DocuSign API/印税入力/freee 取引登録(API化検討)
⚠️ 5/19 高橋MTG で確認する論点
① 業務委託先と著者の判別方法:CSV「備考」列に「著者」「イラストレーター」等が散見されるが、明確なカテゴリ列なし。判別方法を確認。
② THINKs CSV エクスポート手順:誰がいつどう実施するか、自動化可否(Phase 1後 RPA 検討材料)。
③ THINKs/freee への CSV 転記実態:画面共有で実際の運用フローを確認、kintone CSV のフォーマット最適化に反映。
④ 論理削除の扱い:CSV内「論理削除」列が全件空のため、削除済みレコードの所在を確認。

🆕 新規著作権者が発生したらどう更新する?

著作権者マスタは「初期投入で終わり」ではなく、新規契約・情報変更が継続的に発生する生きたマスタ。発生源と更新パスを整理。

flowchart TB
    subgraph trigger["🎯 新規発生・更新が起きるシーン"]
        S1["新規契約締結
(業務委託 or 出版契約)"] S2["既存著作権者の
情報変更
(口座/住所/インボイス)"] S3["編集部が
マスタ未登録の
取引先と契約"] end subgraph thinks["📚 THINKs(基幹)"] TH[("著作権者マスタ
(正本)")] end subgraph kintone["☁️ kintone(運用)"] KM[("著作権者マスタ
(運用)")] KP["発注書/支払依頼
からlookup"] end S1 -->|高橋/河合が登録| TH S2 -->|高橋が更新| TH S3 -->|"⚠️ 高橋に追加依頼
(暫定運用)"| TH TH -.->|"Phase 1:
月次 手動CSV
取り込み"| KM TH ==>|"Phase 2:
RPA 週次/月次
半自動同期"| KM KM --> KP style TH fill:#fed7aa,stroke:#d97706 style KM fill:#d1fae5,stroke:#16a34a style S3 fill:#fee2e2,stroke:#dc2626
フェーズ 更新トリガー 更新パス 更新頻度・実現性
Phase 1(5-7月) 月次の経理締めタイミング 高橋さんが THINKs から CSV エクスポート → 西川提供スクリプトで差分抽出 → kintone API でアップサート ✅ 月次・半自動
(CSV出力は手動、取り込みは自動)
Phase 1(緊急対応) 編集部がマスタ未登録の取引先と契約 編集部 → 高橋さんへ追加依頼 → 高橋さんが THINKs に登録 → kintone マスタにも手動追加(or 次回CSV取込待ち) 🟡 都度・暫定手動運用
(運用負荷あり、Phase 2 で解消)
Phase 2 以降 同上+日次の情報変更 大和PC (NucBox4) 上で RPA(Pywinauto)が THINKs UI を自動操作してCSV出力 → 差分検出 → kintone 同期 🟡 週次/月次・半自動
(PoC必要、ビズロボ廃止連動)
Phase 3 以降(理想形) 新規契約締結のkintoneイベント kintone 契約アプリで新規登録 → Webhook で THINKs RPA 起動 → kintone マスタも同時更新 🔴 イベント駆動・半自動
(THINKs UI 自動化の安定運用が前提、長期構想)
⚠️ 期待値調整
「完全自動」は THINKs に API が無い限り技術的にハードルが高い。RPA(UI 自動操作)は実現可能だが、THINKs 画面構造の変更時にメンテが必要・実行中の例外ハンドリングが必要・大和PCの常時稼働前提など、「半自動」が現実的な落としどころ

Phase 1 では「月次手動 + 緊急時の都度手動追加」で運用開始し、運用負荷を実測してから Phase 2 の自動化スコープを決めるのが安全。
USE CASE BRANCHING

11. ユースケース別の判断分岐

業務種別・金額変更・取引先タイプによって、kintoneアプリが分岐する処理を整理。

🎨 ケース A:デザイン発注(責了日基準)
業務種別=「デザイン等」を選択
→ 支払起算日=「校了日基準」を自動選択
→ 受領(校了)予定日 を入力
→ 検収予定日 = 受領予定日 + 7日 で自動計算
→ PDF 出力時「受領(校了)予定日」表記を使用
📷 ケース B:撮影・校正発注(納品日基準)
業務種別=「撮影・校正等」を選択
→ 支払起算日=「納品日基準」を自動選択
→ 納品予定日 を入力
→ PDF 出力時「納品予定日」表記を使用
💻 ケース C:だいわlog 連載原稿
業務種別=「だいわlog連載」を選択
→ 書籍マスタ参照を「連載企画」フィルタに切替
→ PDF テンプレートが連載専用に変わる
→ 「掲載1回分」表記でPDF生成
📖 ケース D:翻訳前下読み(リーディング)
業務種別=「リーディング」を選択
→ 後注釈「翻訳業務委託契約時に印税に含む」を自動付記
→ 翻訳契約発生時に Phase 2 業務委託契約と紐付け可能
💰 ケース E:金額変更(発注後の追加作業)— 3案あり、5/19で運用合意
推奨 B案(支払依頼で吸収)
発注書はそのまま → 支払依頼の「金額確定値」を変更 → 「金額修正理由」を必須入力(JSで強制)
長所: 取引先への再送付不要、社内完結 / 短所: 発注書↔支払依頼で金額差が残る(修正理由で追跡)

A案(発注書改定): ステータス「改定中」→ バージョン2 → PDF再送付
C案(追加発注書): 差分のみ別発注書として起票、関連付けで紐付け
→ どのケースをどう運用するか、5/19高橋さんに確認
🚫 ケース F:取引先がマスタにない
取引先lookup で検索ヒットなし
→ 警告メッセージ「マスタにない場合は高橋さんへ依頼」
→ 高橋承認 + マスタ追加後に発注書作成再開
→ Phase 1 後半は編集部から直接マスタ追加申請可
IMPLEMENTATION ROADMAP

12. 実装ステップと現在地

Phase 1 を5つのStepに分解。現在はStep 0(設計準備)の中盤。

5/13-19
Step 0: 設計準備 進行中(90%)
マスタ設計・PDFサンプル試作・ヒアリング・THINKs連携PoC。
✅ 設計ドキュメント一式 / ✅ 著作権者マスタCSV受領(2,487件) / ✅ 河合さん除外を高橋確認済 / 🟡 5/19高橋MTGで詳細確定
5/20-28
Step 1: マスタ整備 未着手
著作権者マスタ kintone アプリ作成、書籍マスタ拡張、CSV初期投入(38列 → kintone REST API、rapidfuzz名寄せ)
5/29-6/10
Step 2: 発注書アプリ実装 未着手
4種統合フォーム、JS カスタマイズ(賢い動き)、Cloud Run + Puppeteer による PDF生成基盤
6/11-20
Step 3: 支払依頼アプリ実装 未着手
発注書からの派生、ワークフロー、月次集計ビュー、CSV エクスポート
6/21〜7月
Step 4: UAT・段階展開 未着手
Stage 1(前半):総務メンバーUAT、機能検証
Stage 2(後半):編集部パイロット 2-3名、実利用検証 → 全員ロンチ

📊 Step別 着手可能率(情報・条件が揃っている割合)

Step 0: 設計準備90%
Step 1: マスタ整備90%
Step 2: 発注書アプリ実装95%
Step 3: 支払依頼アプリ実装95%
Step 4: UAT・段階展開70%
BLOCKER UPDATE(2026-05-17)
🎉 Step 1 のブロッカーがほぼ解消:THINKs「著作権者マスタ」CSV(2,487件・38列)を 2026-05-15 に高橋さんから受領済。想定以上にリッチなデータ(口座/源泉徴収税率/インボイス状況フル装備)で、Step 1 着手可能。
→ 残るは 5/19 高橋MTG で運用詳細を確認 すれば即着手可能。

🔍 Step 4(UAT・パイロット)の事前確認・依頼事項

実装を進めながらのテスト・パイロット展開で、事前に高橋さん・窪田部長に依頼しておきたいこと。

タイミング 確認・依頼事項 依頼先 なぜ事前準備が必要か
5/20-28(Step 1中) kintone 管理者権限の最終確認、APIトークン発行 窪田部長 マスタアプリ作成にcybozu.com共通管理者権限が必須(付与済だが念のため)
5/29-6/10(Step 2中) 発注書PDFサンプル1枚のレビュー 高橋・松本 既存Excel発注書とのレイアウト差分を実物で確認、社印・宛名ルールの最終合意
6/11-20(Step 3中) Stage 1(総務UAT)参加者の確保 高橋・窪田部長 高橋さん本人+総務メンバー1-2名で実データ投入テスト、最低5営業日確保
6月中 編集部 kintoneライセンス追加判断 窪田部長・井坂部長 Stage 2 編集部パイロット(2-3名)に必要、月¥1,800/人の予算稟議
6月中 編集部パイロット候補者の推薦 井坂部長・松本 「触ってみてくれる前向きな2-3名」を事前リストアップ
6/21-28(Stage 1中) 過去1ヶ月分の発注実データで動作確認 高橋 仮想データではなく実データで「業務種別の境界」「金額変更ケース」をテスト
7月(Stage 2中) 編集部全員への展開タイミングの合意 窪田・井坂部長 2-3名パイロットで問題出尽くしを確認した後、全展開判断
7月以降(運用安定後) 旧Excel運用の正式廃止アナウンス 窪田部長 経由 全社 新旧併用は混乱の元、kintone一本化を社内通知
PHASE 2 / 3 OUTLOOK

13. Phase 2 / 3 の残論点・期待値・工数感

Phase 1(発注書・支払依頼)が安定運用したあとの拡張スコープを正直ベースで整理。「完全自動」と書きたいところを「半自動」に補正し、実現性のグラデーションを明示する。

📋 Phase 2: 業務委託契約書(想定 8-10月)

コンポーネント 残論点(5/19以降に確認) 期待値(実現確度) 工数感
業務委託契約アプリ(2フォーマット統合) 「ライティング等」「翻訳業務」の業務種別分岐、印税率/金額の入力UI 高(kintone標準で実現可) 純1日 / LT2日
JS カスタマイズ(マスタ参照・印税率計算) Phase 1 のJS資産が流用可能か 純2日 / LT3日
Word .docx 出力機能 既存Word雛形のCSS化、または pandoc / docx生成ライブラリで対応? 中(PoC必要) 純3日 / LT5日
DocuSign API 連携 大和書房のDocuSignアカウント権限、既存契約との整合(河合さんとすり合わせ) 中(API実績あり、社内権限次第) 純4日 / LT2週間
編集部→高橋ワークフロー(プロセス管理) Phase 1 と同じパターンで吸収可 純1日 / LT1日
Phase 2 合計 中〜高(DocuSign権限が鍵) 純11日 / LT 約1ヶ月

📋 Phase 3: 出版契約書類(想定 11月-)

コンポーネント 残論点 期待値(実現確度) 工数感
出版契約アプリ(5フォーマット統合) 「契約書/覚書」「紙電子一体型/紙のみ/文庫同意書」の組合せ判定 純2日 / LT3日
JS カスタマイズ(媒体別印税計算) 再版印税率・電子印税率・ページ割(按分)の自動計算 純3日 / LT4日
編集部→河合→高橋→河合 ワークフロー 河合さんとの詳細設計、現状の「往復」をどう解消 中(運用合意が前提) 純1日 / LT 河合さんMTG含めLT2週間
DocuSign 連携(Phase 2流用) Phase 2 が動いていれば流用 高(Phase 2成功条件付き) 純1日
THINKs 印税自動入力(RPA) THINKs UI の自動操作(Pywinauto)— UI変更時にメンテ必要・大和PC常時稼働前提 低〜中(PoC 5-7日必要、長期保守リスクあり) 純7日 + 運用保守 年5-10日
著者マスタ(書籍マスタから派生) 著作権者マスタとの統合 or 別アプリ化の判断 高(既設計の延長) 純1日
Phase 3 合計 低〜中(THINKs RPA が鍵) 純15日 / LT 約1.5ヶ月

🚦 期待値の補正(前回からの差分)

項目 前回表記 今回補正 理由
THINKs RPA 同期 完全自動 半自動(週次/月次) UI自動化は構造変更時にメンテ必要、例外処理が必要
DocuSign API 完全自動 半自動(イベント駆動) 社内DocuSign権限取得・既存契約との整合確認が前提
THINKs 印税入力(Phase 3) 手動 → API化検討 RPA(UI自動化)、長期保守要 THINKs に API が無いことが確定、RPA以外の選択肢なし
freee 取引登録 手動継続 手動継続(Phase 3+でAPI化検討) freee API実績あり、優先度次第で実装可能

⚠️ Phase 2/3 に進む前の前提条件

前提 A

Phase 1 の運用安定

編集部 8割が kintone 発注書を日常使用、月次支払処理が30%以上時短、ビズロボ廃止判断のデータ揃いの3つが揃ってから Phase 2 に進む。

前提 B

DocuSign 権限と運用合意

河合さん経由でDocuSignアカウントの API 利用権限を取得、既存契約との整合方針を合意。Phase 2 着手前に1on1必須。

前提 C

THINKs RPA PoC 成功

5-7日のPoCで「THINKs UIをPywinautoで安定操作できるか」を実証。失敗時はマスタ更新を手動継続 + ビズロボ廃止見送り判断。

SO WHAT
Phase 2/3 は「やれば動く」が「自動度の期待値は高くしすぎない」のが正直なところ。 特に THINKs RPA は「動かしたら安定運用は別問題」なので、Phase 1 の手動運用を覚悟しながら徐々に自動度を上げる姿勢が安全。 Phase 1 完了時点で改めて「Phase 2/3 のROI vs 工数」を再評価することを推奨。
GAPS & REQUESTS

14. 不足情報 と 大和書房さまへの確認・依頼

実装に必要な情報のうち、現状不足しているもの・大和書房さま側にしかない情報を構造的に整理。

✅ 解決済み(前回からの進展)

✅ RESOLVED
業務委託先マスタの所在
前回「所在不明」とした業務委託先マスタは、THINKs「著作権者マスタ」がそれに該当することが判明(高橋さん 5/15メール)。著者を含むが、報酬に関する業務委託をすべて包括。
受領済み:2,487件・38列の CSV を 2026-05-15 に取得。データ品質は想定以上。
✅ RESOLVED
河合さんのワークフロー関与
前回設計「編集部→河合→高橋」と記述したが、高橋さんから「河合は出版契約フロー(Phase 3)担当でこのフローには関与しない」と訂正。
反映済み:本資料の全フロー図を「編集部→高橋」の2ステップに修正。

🔴 5/19 高橋MTG で確認したいこと(P0)

🔴 CRITICAL
業務委託先と著者の判別方法
CSVの「備考」列に「著者」(195件)、「イラストレーター」(158件)、「再版2冊」(162件) などが散見されるが、明確なカテゴリ列なし。発注書アプリの業務種別との紐付けに必要。
確認したい:備考列以外で職種を判別する方法はあるか? それとも手動分類で運用しているか?
🔴 CRITICAL
過去 1 年分の支払依頼.xlsx
表記揺れ実態の確認・著作権者コードとの突合・支払フローの実測値把握のため。CSVが手に入った今でも、実際の運用イメージを掴むために必要。
依頼したい:高橋さんから過去1年分(2025/5〜2026/4)の月次支払依頼.xlsx を共有していただきたい(機密扱い)。
🔴 CRITICAL
THINKs/freee への CSV転記実態(画面共有)
kintone CSV のフォーマットを「後工程が楽になる形」にしたい。THINKs はAPI無しなのでCSV取込専用、freee はAPI連携も将来検討。
確認したい:実際に THINKs/freee へ転記している様子を画面共有してもらい、必要なCSV項目・順序・形式を把握。
🔴 CRITICAL
論理削除フラグの扱い
受領CSV「論理削除」列が2,487件すべて空。論理削除済みレコードがエクスポートから除外されているのか、運用上削除を使っていないのか不明。
確認したい:取引停止時の運用は? 論理削除 or ペンネーム列に「※使用停止」記入 or 別フィールド?

🟡 実装中に必要(P1)

🟡 HIGH
PDF 品質要件・社印・宛名ルール
PDF生成方式(C案 Cloud Run+Puppeteer vs D'案 ブラウザ内 jsPDF)の最終選定に影響。対外正式文書としての印刷要件・社印の扱いを確認。
確認したい:社印の電子化はあるか?「様/御中」判定ルール?印刷物 vs PDFのみの比率?取引先別の特殊レイアウト要望はあるか?
🟡 HIGH
THINKs CSV エクスポート手順
Phase 1 後の継続同期 RPA 設計のため。誰がいつどう実施しているかを把握。
確認したい:著作権者マスタCSVの出力手順、頻度、画面遷移、自動化の余地。
🟡 HIGH
編集担当者列が2つある理由
受領CSV内に「編集担当者」というカラム名が2列あり、片方が数値コード、片方が氏名と推測される。kintone マスタへの取り込み時にリネームが必要。
確認したい:2列は「コード」と「氏名」の組合せで合っているか? どちらが正?
🟡 HIGH
編集部 kintone ライセンス追加判断
Stage 1(総務UAT)完了後、編集部パイロット 2-3名へのアクセス権発行が必要。月額 ¥1,800/人 × 人数の予算判断。
判断依頼:編集部パイロット時期(7月想定)に向けて、ライセンス追加可否・タイミングを窪田部長とご相談いただきたい。

🟢 後でいい(P2、Phase 1 後半 or Phase 2 移行時)

🟢 MINOR
インボイス番号(T+13桁)の管理
受領CSVには「インボイス登録状況」(登録済/未登録等)はあるが番号(T+13桁)は無い。適格請求書発行時の表示に必要だが、Phase 1 では未表示でも実用可。
確認したい:インボイス番号は別管理か? 必要時は別CSV取得可能か?
🟢 MINOR
月間発注件数・4種比率の実数
ROI 試算・KPI設定の精度向上に使う。受領済み支払依頼.xlsxから算出可能。
確認したい:月間発注書件数(部署別)、4種フォーマットの利用比率の感覚値
🟢 MINOR
パイロット利用者の候補
Stage 2 編集部パイロットに参加してもらう 2-3名を選定する。早期適応者を優先。
相談したい:編集部内で kintone を試してくれそうな前向きな方を推薦してほしい(Phase 1 後半までに)。

📝 5/19(火)14:00 高橋さんMTG アジェンダ(60分

  1. 1
    本ビジョン資料のレビュー:河合さん除外を反映した最新版(このページ)の構造を一緒に確認、抜粋ポイント中心。→ 10分
  2. 2
    発注書4パターンの妥当性確認:4種で網羅できるか/業務種別の境界・切り分け方/同一発注で複数業務種別が混ざるケース/内容変更時のフロー(A.改定 / B.支払依頼で吸収 / C.追加発注)。→ 15分
  3. 3
    著作権者マスタ CSV の中身突合せ:業務委託先 vs 著者の判別方法、編集担当者2列の意味、論理削除の扱い、入力ミス疑い箇所。→ 15分
  4. 4
    THINKs/freee 転記の画面共有デモ:高橋さんの実際の月次処理を見せてもらい、kintone CSV のフォーマットを後工程最適化。→ 15分(最重要)
  5. 5
    クロージング:過去支払.xlsx共有依頼 + PDF品質要件(社印・印刷物有無)+ 5/20 Step 1 着手の合意。→ 5分
⚠️ 削った項目(持ち越し or 後日メール):編集部ライセンス追加判断(窪田部長別途)、パイロット候補者の推薦(井坂部長 / 松本さんへ別途)、月間発注件数の感覚値(受領済xlsxから算出可)
NEXT ACTIONS

15. 次のアクション

この資料を元に、次の1on1で合意・確認していきたい項目。

5/19(火)14:00

高橋さん 60分MTG

本資料レビュー → 発注書4パターン妥当性 + 内容変更フロー → 著作権者マスタCSV突合せ → THINKs/freee転記の画面共有 → クロージング。

→ Step 0 完了 + Step 1 着手の意思決定

5/17-19(事前準備)

西川による先行作業

著作権者マスタCSV分析詳細化(38列マッピング草案)、master-design.md 修正、PDF生成PoC(Cloud Run)の骨格実装、5/19MTG資料化。

→ MTG までに完了させる

5/20-7/上旬

Phase 1 本実装

Step 1(マスタ)→ Step 2(発注書)→ Step 3(支払依頼)→ Step 4(パイロット)。7月上旬 編集部全展開。

→ 純工数 12.5日 / リードタイム 35日

SO WHAT
🎉 前回の最大ブロッカー(業務委託先マスタの所在)は解消。THINKs「著作権者マスタ」CSV(2,487件、口座/源泉/インボイス完備)を取得済。

5/19 高橋MTG で運用詳細を確認できれば、即 Step 1 着手 → 6月末 Stage 1 パイロット / 7月上旬 編集部展開 が現実的スケジュール。技術ブロッカーはほぼゼロ。