編集部 → 総務(高橋)の業務委託発注 〜 支払依頼フローを kintone に集約し、4種フォーマット統合・PDF自動出力・取引先表記揺れ撲滅を実現する。
編集部担当者が kintone 1画面で発注書を作成 → PDFが自動生成され取引先へ送付 → 同じレコードから支払依頼が派生 → 総務(高橋)が月次まとめて承認、という一気通貫の運用を実現する。
デザイン等・撮影等・だいわlog連載・リーディング を1つの kintone フォームに集約。業務種別 × 支払起算日 のドロップダウン選択で 4 種の Excel フォーマットを完全に吸収。
「PDF生成」ボタン1つで規定レイアウトの発注書PDFを自動生成。kintoneレコードに添付ファイルとして保管され、紛失リスクゼロ・どこからでも参照可能。
「鷗来堂」「株式会社鷗来堂」「Ouraidou」が全部同じ取引先と認識される、表記揺れ吸収マスタ。高橋さんの THINKs 登録コード照合作業を大幅短縮。
発注書から「支払依頼を作成」ボタンで支払依頼レコードを自動生成。金額変更がある場合は理由を必須入力させ「発注書を作り直さない」運用ミスを構造的に防止。
編集部担当者 → 総務(高橋:支払日入力・最終確認)の 2ステップ を kintone プロセス管理で実装。河合さんは出版契約フロー(Phase 3)の担当で、本PJ(発注・支払)には関与しない。
支払予定月別の集計ビューで高橋さんの月次処理を効率化。CSV エクスポートで THINKs 印税入力・freee 会計取引登録へ連携(Phase 3で自動化)。
関係者・データの流れを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標準UIと比較しながらレビュー・改善する。
現状の Excel 4 種フォーマット(デザイン等/撮影等/だいわlog/リーディング)を、kintone 1 フォームに統合。 「業務種別」を選ぶだけで、支払起算日・日付ラベル・特記文言・PDFテンプレが自動切替されます。
| 項目 | ① デザイン等 | ② 撮影・校正等 | ③ だいわlog 連載 | ④ リーディング |
|---|---|---|---|---|
| 支払起算日 | 校了日基準 | 納品日基準 | 納品日基準 | 納品日基準 |
| 日付ラベル | 受領(校了)予定日 | 納品予定日 | 受領予定日(毎月) | 納品予定日 |
| 書籍/企画 | 通常書籍 | 通常書籍 | 連載企画(だいわlog フィルタ) | 翻訳企画(権利獲得前) |
| 取引先例 | デザイナー | フォトグラファー / 校正者 | コラムニスト | リーダー / 翻訳家 |
| 特記事項 | — | — | インボイス相当の支払通知書を弊社送付 | 翻訳契約発生時に印税に含む |
| 共通項目 | 基本情報(発注番号・発注日・担当編集者)/ 取引先選択 / 報酬明細 / 締日(毎月25日)/ 支払日(翌月20日)/ ハラスメント窓口記載 | |||
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 |
scripts/kintone-js/ に Git 管理し、kintone へは「JSカスタマイズ機能」経由でアップロード。
関係者ごとに、いつ・何を・どう操作するかを整理。各ペルソナのストーリーが完結することを確認する。
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 取引登録(手動転記)
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
| テーブル | 種別 | 初期件数 | 増分 | キー | 主な用途 |
|---|---|---|---|---|---|
| 著作権者マスタ | マスタ | 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 | ペンネーム・別名でも検索可 |
| 書籍/企画 | lookup | ISBN or 企画名で検索 | |
| 業務内容 | 業務種別 | ドロップダウン | デザイン等 / 撮影・校正等 / だいわlog / リーディング |
| 業務内容詳細 | テキストエリア | 例: 表1デザイン、本文DTP | |
| 報酬明細 | サブテーブル | 内容/単価/数量/金額(複数行) | |
| 合計金額(税抜/税込) | 計算フィールド | 自動計算 | |
| 納品・支払 | 受領/納品予定日 | 日付 | 業務種別によりラベル切替(JS) |
| 支払起算日タイプ | ドロップダウン | 校了日 / 納品日(業務種別から自動) | |
| 支払日(計算) | 計算フィールド | 翌月20日 | |
| 出力 | PDF添付 | 添付ファイル | 「PDF生成」ボタンで自動格納 |
| カテゴリ | フィールド名 | 型 | 備考 |
|---|---|---|---|
| 基本情報 | 支払依頼番号 | 文字列(自動採番) | PR-2026-0042 |
| 申請日 | 日付 | デフォルト: 今日 | |
| ステータス | プロセス管理 | 申請中 / 高橋確認中 / 完了 / 差戻 | |
| 発注書参照 | 発注書 | lookup | 派生時に自動入力 |
| 書籍/企画 | lookup | 発注書からコピー | |
| 支払内容 | 支払先表記 | 文字列 | 取引先名 or ペンネーム(編集可) |
| 金額確定値(税抜) | 数値 | 発注書からコピー、変更可 | |
| 金額修正理由 | テキストエリア | 発注書と異なる場合のみ必須(JSで強制) | |
| 金額(税込) | 計算フィールド | 源泉徴収反映可 | |
| 支払情報 | 支払予定日 | 計算フィールド | 支払起算日 + 締日 + 支払日から自動算出 |
| 支払日(振込) | 日付 | 高橋が入力、最終承認時 | |
| 振込先確認 | チェックボックス | 高橋が確認後ON | |
| その他 | 高橋メモ | テキストエリア | 編集部からは非表示 |
発注書を 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) | 予備案(品質要件次第で切替) |
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
| 発生タイミング | 内容 | 工数 |
|---|---|---|
| 年1回 | GCP Node.js ランタイム deprecation 対応 | 半日 |
| 年2-3回 | Puppeteer/Chrome のセキュリティパッチ反映 | 1-2時間 |
| 必要時 | PDFレイアウト変更要望(社印位置等) | 半日〜1日 |
| 初期設計に含めればOK | エラー時 Slack 通知 | 設計込み |
| 原則不要 | kintone API トークン期限切れ(無期限) | ― |
高橋さんの月次集計作業(現状2-3時間)を 30分以下 に短縮するための仕組み。kintone標準機能でほぼ実現可能。
高橋さんが日次・月次にどう操作するかを実画面イメージで。
| 支払依頼番号 | 申請者 | 著作権者 | 金額 | 支払予定日 |
|---|---|---|---|---|
| PR-2026-0042 | 荻田 | 株式会社鷗来堂 | ¥96,750 | 2026-06-20 |
| PR-2026-0043 | 荻田 | 合同会社チコルズ | ¥190,000 | 2026-06-20 |
| PR-2026-0044 | 田中 | キャメレオン竹田 | ¥120,000 | 2026-06-20 |
| ... 残り9件 | ||||
事前にビューを設定しておけば、毎回検索せずに目的の画面に1クリックで飛べる。
| 対象者 | ビュー名 | 抽出条件 | 用途 |
|---|---|---|---|
| 編集部 | 「自分の発注書」 | 担当編集者 = ログインユーザー | 自分の進行中案件チェック |
| 「自分の支払依頼」 | 申請者 = 自分 | 支払処理状況確認 | |
| 高橋 | 「支払日未入力」 | ステータス=高橋確認中 AND 支払日=空 | 日次の todo リスト |
| 「当月支払予定」 | 支払予定日 ∈ 今月 | 月次の支払総額把握 | |
| 「月次CSV出力用」 | ステータス=完了 AND 支払日 ∈ 指定月 | エクスポート対象抽出 | |
| 全員 | 「書籍別集計」 | 書籍でグルーピング、金額合計 | 1冊あたり総原価把握 |
高橋さん(毎月月末) │ │【1】「月次CSV出力用」ビューを開く ▼ [kintone] 完了レコードを抽出表示 │ │【2】右上「エクスポート」→ CSV ダウンロード ▼ [ダウンロードフォルダ] payment_2026-05.csv │ │【3-A】 THINKs 印税入力に手動投入(Phase 3で半自動化) │【3-B】 freee 取引登録に手動投入(Phase 3で API化検討) ▼ [完了] 月次経理処理完了
| 処理 | 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% |
高橋さんから 2026-05-15 にご共有いただいた「著作権者マスタ一覧.csv」を確認させていただきました。データの構造に合わせて kintone を設計することで、高橋さんの日々の業務がどう楽になるか を整理しました。
銀行コード、支店、口座番号、口座名義まで揃っているので、編集部が支払依頼を起票するときに 著作権者を選ぶだけで振込先情報が自動表示。転記ミスのご確認作業が不要になります。
「著作権者名」と「ペンネーム」が別の項目で記録されているおかげで、表記揺れの照合作業(THINKs登録コード全件確認)が解消。編集部が誰の名前で書いても、高橋さんの目に届く時には正規名で揃います。
個人著者(10.21%)1,576件、法人(0%)871件、非居住者(20.42%)22件 のパターンが整っているので、支払依頼起票時に 源泉税額を自動計算。電卓いらず。
登録済1,089件、未登録623件、登録予定なし226件、未確認548件 が整理可能。支払処理時に登録状況がひと目で分かる ようになります(インボイス番号自体は別管理かどうか5/19で確認させてください)。
「備考」欄に「著者」「イラストレーター」等の記載が散見されますが、明確なカテゴリ項目が見当たりませんでした。高橋さんは普段どうやって判別されていますか? 5/19で教えてください。
「編集担当者」項目が2つあるのは「コード」と「氏名」の組合せでしょうか?/「個人法人」に「ユウチヨ」が1件あるのは入力誤り?/「論理削除」項目が全件空のため、停止された取引先のエクスポート方法も合わせて伺いたいです。
どの連携が 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 検討 |
著作権者マスタは「初期投入で終わり」ではなく、新規契約・情報変更が継続的に発生する生きたマスタ。発生源と更新パスを整理。
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 自動化の安定運用が前提、長期構想) |
業務種別・金額変更・取引先タイプによって、kintoneアプリが分岐する処理を整理。
Phase 1 を5つのStepに分解。現在はStep 0(設計準備)の中盤。
実装を進めながらのテスト・パイロット展開で、事前に高橋さん・窪田部長に依頼しておきたいこと。
| タイミング | 確認・依頼事項 | 依頼先 | なぜ事前準備が必要か |
|---|---|---|---|
| 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 1(発注書・支払依頼)が安定運用したあとの拡張スコープを正直ベースで整理。「完全自動」と書きたいところを「半自動」に補正し、実現性のグラデーションを明示する。
| コンポーネント | 残論点(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ヶ月 | |
| コンポーネント | 残論点 | 期待値(実現確度) | 工数感 |
|---|---|---|---|
| 出版契約アプリ(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実績あり、優先度次第で実装可能 |
編集部 8割が kintone 発注書を日常使用、月次支払処理が30%以上時短、ビズロボ廃止判断のデータ揃いの3つが揃ってから Phase 2 に進む。
河合さん経由でDocuSignアカウントの API 利用権限を取得、既存契約との整合方針を合意。Phase 2 着手前に1on1必須。
5-7日のPoCで「THINKs UIをPywinautoで安定操作できるか」を実証。失敗時はマスタ更新を手動継続 + ビズロボ廃止見送り判断。
実装に必要な情報のうち、現状不足しているもの・大和書房さま側にしかない情報を構造的に整理。
この資料を元に、次の1on1で合意・確認していきたい項目。
本資料レビュー → 発注書4パターン妥当性 + 内容変更フロー → 著作権者マスタCSV突合せ → THINKs/freee転記の画面共有 → クロージング。
→ Step 0 完了 + Step 1 着手の意思決定
著作権者マスタCSV分析詳細化(38列マッピング草案)、master-design.md 修正、PDF生成PoC(Cloud Run)の骨格実装、5/19MTG資料化。
→ MTG までに完了させる
Step 1(マスタ)→ Step 2(発注書)→ Step 3(支払依頼)→ Step 4(パイロット)。7月上旬 編集部全展開。
→ 純工数 12.5日 / リードタイム 35日