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
承認ワークフロー
編集部担当者 → 総務(河合:初動チェック)→ 総務(高橋:支払日入力・最終確認)の流れを kintoneプロセス管理で実装。現状の往復・確認手間を解消。
CORE 6
月次集計・経理連携
支払予定月別の集計ビューで高橋さんの月次処理を効率化。CSV エクスポートで THINKs 印税入力・freee 会計取引登録へ連携(Phase 3で自動化)。
SYSTEM ARCHITECTURE
2. システム全体像
関係者・データの流れを1枚に集約。kintoneを中心に、THINKs・freee・SharePoint と疎結合で連携する。
flowchart TB
subgraph 編集部["👥 編集部担当者"]
E1[発注書作成]
E2[支払依頼へ派生]
end
subgraph kintone["☁️ kintone(中核)"]
APP1[発注書アプリ
4種統合フォーム]
APP2[支払依頼アプリ
ワークフロー付]
M1[(取引先マスタ
表記揺れ吸収)]
M2[(書誌マスタ
既存 1,226件)]
end
subgraph 総務["🏢 総務"]
T1[河合:初動チェック]
T2[高橋:支払日入力・最終確認]
end
subgraph 取引先["✉️ 取引先"]
TS[デザイナー・
イラストレーター等]
end
subgraph 外部["🔗 外部システム"]
TH[(THINKs)]
FR[freee会計]
SP[SharePoint
アーカイブ]
end
E1 ==> APP1
APP1 --lookup自動--> M1
APP1 --lookup自動--> M2
APP1 ==PDF自動生成==> TS
E2 ==> APP2
APP1 ==派生ボタン==> APP2
APP2 ==> T1
T1 ==> T2
T2 -.月次CSV手動DL.-> FR
T2 -.月次CSV手動DL.-> TH
TH -.初期CSV手動取込.-> M1
TH -.初期CSV手動取込.-> M2
APP1 --添付ファイル自動--> SP
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日)/ ハラスメント窓口記載 |
📌 業務内容(タブにより変化)
報酬明細
表1デザイン / ¥120,000
本文DTP / ¥55,000
本文図版代 / ¥15,000(3,000×5点)
📌 納品・支払条件(タブにより変化)
支払期日
校了日を基準に、毎月25日締め/翌月20日支払い(自動表示)
📌 業務内容(タブにより変化)
報酬明細
本文校正(素読み・文字統一・事実確認) / 文字単価 ¥0.45
概算 215,000 文字 → ¥96,750
📌 納品・支払条件(タブにより変化)
支払期日
納品日を基準に、毎月25日締め/翌月20日支払い(自動表示)
📌 業務内容(タブにより変化)
著者名/連載企画名 *
🔍 ●●『test(仮)』連載 ※書誌マスタの「だいわlog」フィルタで絞込
報酬明細
だいわlog 連載原稿料 / 掲載1回分につき ¥●●●
📌 納品・支払条件(タブにより変化)
⚠️ 特記事項
適格請求書(インボイス)に該当する支払通知書を弊社より送付いたします。
※ PDF にも自動印字
📌 業務内容(タブにより変化)
企画(権利獲得前)*
🔍 ●●『test(仮)』※翻訳企画モード
報酬明細
翻訳企画・権利獲得前下読み / ¥●●●
📌 納品・支払条件(タブにより変化)
⚠️ 特記事項
企画獲得時は翻訳業務についての業務委託契約書を結び、下読みの報酬は翻訳業務の印税に含むものとします。
※ Phase 2 で業務委託契約レコードと自動紐付け可能
📄 確定後:PDF自動生成 + 派生ボタン(4種共通)
📄 発注書_2026-0042_合同会社チコルズ.pdf
クリックでプレビュー / ダウンロード
支払依頼を作成 →
PDFをダウンロード
複製して新規作成
関連レコード: 同じ書籍の発注書 3件 / 派生済み支払依頼 1件
UX POINT
Excel と比較した時短ポイント:① 書籍・取引先選択で「著者名・適格番号・住所」が自動入力 → 転記ゼロ。② 業務種別選択で支払条件が自動表示 → 暗記不要。③ 合計金額が自動計算。
USER FLOW BY PERSONA
4. ユーザー別 E2E フロー
関係者ごとに、いつ・何を・どう操作するかを整理。各ペルソナのストーリーが完結することを確認する。
編
編集部担当者
日々の発注業務を担当
1取引先と業務・報酬を決定
2kintone 発注書アプリで新規作成
3書籍・取引先を選択(自動入力)
4業務種別・報酬明細を入力
5確定 → PDF自動生成
6PDFをメールで取引先へ送付
7納品後「支払依頼を作成」ボタン
8金額変更あれば理由を入力
契
河合さん(総務・契約)
支払依頼の最初の受領・初動チェック
1編集部からの支払依頼を受領
2「河合確認待ち」ビューを確認
3取引先・書籍・金額の妥当性チェック
4入力漏れ・誤りの差戻し判断
5承認 → 高橋へ
P2業務委託契約書アプリ運用(Phase 2)
P2DocuSign 連携(Phase 2)
P3出版契約書類運用(Phase 3)
経
高橋さん(総務・経理)
支払日入力・最終確認・月次処理
1「河合承認後」ビューを確認
2振込先口座・金額を最終確認
3支払日(振込予定日)を入力
4最終承認 → 完了
5月次集計ビューで全件確認
6CSV エクスポート
7THINKs 印税入力 / freee 取引登録
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生成
(kViewer等)
participant R as 河合
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: 金額確定値・修正理由を入力
K->>R: ワークフロー「河合確認中」へ
Note over U,X: ── 3. 支払処理フェーズ ──
R->>K: 入力内容・取引先妥当性を確認
R->>K: 承認 → 高橋へ
K->>T: ワークフロー「高橋確認中」へ
T->>K: 振込先口座・金額の最終確認
T->>K: 支払日(振込予定日)を入力
T->>K: 最終承認 → 完了
K->>X: 月次CSVエクスポート
X-->>X: 印税入力 / 取引登録
EXTERNAL INTEGRATION FEASIBILITY
6. 外部システム連携マトリクス(フィジビリ・自動度)
どの連携が Phase 1 スコープ内か、どこまで自動化されるか、何が手動で残るかを明示。技術的な実現性(フィジビリ)と現状の不確実性も整理。
| 連携先 |
方式 |
データ/用途 |
頻度 |
Phase |
自動化レベル |
フィジビリ |
| THINKs(取引先) |
CSV 手動 DL → Python取込 |
取引先マスタ初期投入 ※業務委託先データの所在は要確認 |
初期 1 回 |
Phase 1 |
半自動 |
⚠️ 業務委託先マスタの所在未確定(窪田部長確認待ち) |
| 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 既存実績あり |
kViewer (or プリントクリエイター) |
kintone プラグイン |
発注書 PDF 自動生成 |
イベント駆動 (発注書確定時) |
Phase 1 |
完全自動 |
✅ プラグイン導入のみ、技術リスク低い |
取引先送付 (メール) |
編集部担当者が手動送付 |
kintone から PDF DL → メール添付 |
都度 |
Phase 1 |
手動 |
✅ 既存運用継続、メール文面の自動化は Phase 2 検討 |
完全自動人間操作不要、システムが完結
半自動人間が起動、処理は自動
手動人間が操作・確認しながら実行
PHASE 1 のスコープ整理
Phase 1 で実装する連携:取引先マスタ初期投入(CSV手動)/書誌マスタ活用(既存)/PDF生成(kViewer等)/SharePoint代替(kintone内)/取引先送付(メール手動)
Phase 1 で「手動継続」する部分:取引先送付メール/月次CSV出力 → THINKs/freee 取込(月次バッチ)/取引先マスタの追加更新
Phase 2/3 で自動化する部分:THINKs RPA 同期(Pywinauto)/DocuSign API/印税入力/freee 取引登録
⚠️ フィジビリ未確定の論点
① 業務委託先マスタの所在:THINKs に業務委託先(デザイナー・ライター等)の正規マスタが存在しない可能性大。窪田部長経由で印税管理メニュー・支払管理メニューの中身確認が必要。
② THINKs CSV インポート機能:Phase 3 の印税自動入力には THINKs 側 CSV 取込機能が前提。なければ手動入力が継続。
③ THINKs UI 自動化(Pywinauto):ビズロボ廃止判断の前提だが、PoC が必要。
USE CASE BRANCHING
7. ユースケース別の判断分岐
業務種別・金額変更・取引先タイプによって、kintoneアプリが分岐する処理を整理。
🎨 ケース A:デザイン発注(責了日基準)
業務種別=「デザイン等」を選択
→ 支払起算日=「校了日基準」を自動選択
→ 受領(校了)予定日 を入力
→ 検収予定日 = 受領予定日 + 7日 で自動計算
→ PDF 出力時「受領(校了)予定日」表記を使用
📷 ケース B:撮影・校正発注(納品日基準)
業務種別=「撮影・校正等」を選択
→ 支払起算日=「納品日基準」を自動選択
→ 納品予定日 を入力
→ PDF 出力時「納品予定日」表記を使用
💻 ケース C:だいわlog 連載原稿
業務種別=「だいわlog連載」を選択
→ 書籍マスタ参照を「連載企画」フィルタに切替
→ PDF テンプレートが連載専用に変わる
→ 「掲載1回分」表記でPDF生成
📖 ケース D:翻訳前下読み(リーディング)
業務種別=「リーディング」を選択
→ 後注釈「翻訳業務委託契約時に印税に含む」を自動付記
→ 翻訳契約発生時に Phase 2 業務委託契約と紐付け可能
💰 ケース E:金額変更(発注後の追加作業)
発注書から「支払依頼を作成」ボタン
→ 金額確定値が発注書金額と異なる場合
→ 「金額修正理由」フィールドが必須化
→ 旧発注書を更新せず、修正履歴を残す
🚫 ケース F:取引先がマスタにない
取引先lookup で検索ヒットなし
→ 警告メッセージ「マスタにない場合は高橋さんへ依頼」
→ 高橋承認 + マスタ追加後に発注書作成再開
→ Phase 1 後半は編集部から直接マスタ追加申請可
IMPLEMENTATION ROADMAP
8. 実装ステップと現在地
Phase 1 を5つのStepに分解。現在はStep 0(設計準備)の中盤。
5/13-21
Step 0: 設計準備 進行中(70%)
マスタ設計・PDFサンプル試作・ヒアリング・THINKs連携PoC。
✅ 設計ドキュメント一式作成完了 / 🟡 業務委託先マスタの所在確認中 / ⬜ 過去支払.xlsx 入手待ち
5/22-28
Step 1: マスタ整備 未着手
取引先マスタ新規作成、書籍マスタ拡張、初期データ投入(過去支払.xlsx → Python抽出 → kintone API)
5/29-6/10
Step 2: 発注書アプリ実装 未着手
4種統合フォーム、PDF生成JS、業務種別分岐ロジック、kViewer/プリントクリエイター方式選定
6/11-20
Step 3: 支払依頼アプリ実装 未着手
発注書からの派生、ワークフロー、月次集計ビュー、CSV エクスポート
6/21〜7月
Step 4: UAT・段階展開 未着手
Stage 1(前半):総務メンバーUAT、機能検証
Stage 2(後半):編集部パイロット 2-3名、実利用検証 → 全員ロンチ
📊 Step別 着手可能率(情報・条件が揃っている割合)
CURRENT BLOCKER
Step 1 の着手可能率が低いのは「
取引先マスタの初期データソースが未確定」のため。THINKs 内に業務委託先のマスタが事実上存在しないことが判明(得意先マスタ=取次のみ45件、著者マスタ=未運用1件)。
→ これを大和書房さまに確認する必要があります。
GAPS & REQUESTS
9. 不足情報 と 大和書房さまへの確認・依頼
実装に必要な情報のうち、現状不足しているもの・大和書房さま側にしかない情報を構造的に整理。
⚠️ ギャップ一覧
🔴 CRITICAL
業務委託先マスタの所在
THINKs の「得意先一覧」(45件) は取次・書店マスタ、「著者マスタ」(1件) は未運用。業務委託先(デザイナー・ライター等)のマスタが事実上存在しない可能性が高い。
確認したい:業務委託先データはどこに集約されているか?(印税管理メニュー内?freee?個人管理?)
🔴 CRITICAL
過去 1 年分の支払依頼.xlsx
取引先マスタ初期データの唯一の代替ソース。表記揺れの実態把握、業務量実数把握、THINKs登録コード対応関係の抽出に必須。
依頼したい:高橋さんから過去1年分(2025/5〜2026/4)の月次支払依頼.xlsx を共有していただきたい。
🟡 HIGH
印税管理メニューの中身
「権利者マスタ」のような業務委託先データが隠れている可能性。著者・翻訳家系の取引先情報が取れるかもしれない。
確認したい:THINKs 印税管理メニューのサブメニュー一覧、「権利者一覧」「印税対象者」等のデータがあるか。
🟡 HIGH
支払一覧・支払調書のエクスポート
過去の全支払履歴データ(取引先名・金額・日付)が取れれば、マスタの代替として使える。年間支払調書は税務上の正規データ。
確認したい:THINKs 支払管理メニューから過去支払履歴・支払調書一覧の CSV エクスポート可否、エクスポート手順。
🟡 HIGH
PDF レイアウト最終仕様
既存 Excel 発注書のレイアウトを kintone PDF 生成で踏襲する。社印・「様/御中」使い分け・フリーランス区分判定など、細部の確認が必要。
確認したい:社印の電子化はあるか?「様/御中」の判別ルールは?取引先別の特殊レイアウト要望はあるか?
🟡 HIGH
編集部 kintoneライセンス追加判断
Stage 1(総務UAT)の完了後、編集部パイロット 2-3名へのアクセス権発行が必要。月額 ¥1,800/人 × 人数の予算判断。
判断依頼:編集部パイロット時期(7月想定)に向けて、ライセンス追加可否・タイミングをご検討いただきたい。
🟢 MINOR
月間発注件数・4種比率の実数
ROI 試算・KPI設定の精度向上に使う。Phase 1 着手後でも対応可能。
確認したい:月間発注書件数(部署別)、4種フォーマットの利用比率の感覚値
🟢 MINOR
パイロット利用者の候補
Stage 2 編集部パイロットに参加してもらう 2-3名を選定する。早期適応者を優先。
相談したい:編集部内で kintone を試してくれそうな前向きな方を推薦してほしい(Phase 1 後半までに)。
📝 大和書房さまへの依頼事項サマリー(窪田部長 1on1 用)
-
1
業務委託先データの所在確認:THINKs 印税管理メニュー、支払一覧、支払調書一覧の中身確認。CSV エクスポート可否。→ 高橋さん・経理に確認していただきたい
-
2
過去 1 年分の月次支払依頼.xlsx 共有:取引先マスタの初期データ抽出に必須。→ 高橋さんから 2025/5 〜 2026/4 分を受領したい(機密扱い)
-
3
編集部 kintone ライセンス追加判断のタイミング合意:Stage 1(6月末)完了後の判断。→ 編集部 2-3名 → 全員(最終形)へのステップ確認
-
4
2段階パイロット案への合意:Stage 1(総務)→ Stage 2(編集部)の進め方。→ 井坂部長と連名でのトップダウンアナウンス文面検討
-
5
PDF 細部仕様の確認:社印・様/御中・フリーランス判定。→ 高橋さん・松本さんに既存運用を確認していただきたい
-
6
パイロット候補者の推薦:編集部で kintone 移行に前向きな方 2-3名。→ Phase 1 後半に向けた早期相談
NEXT ACTIONS
10. 次のアクション
この資料を元に、次の1on1で合意・確認していきたい項目。
直近1週間
窪田部長 1on1 でヒアリング
業務委託先マスタの所在確認、過去支払.xlsx 入手依頼、ライセンス追加判断のタイミング、PDF 細部仕様、パイロット候補相談。
→ Step 0 完了の前提条件
並行
西川による先行実装
PDF サンプル試作(既存 Excel ベース)、kintone 取引先マスタアプリ仮作成、初期投入スクリプトの骨格実装。
→ ヒアリング待たずに進められるタスク
5月末まで
Step 1 着手判断
窪田回答後、取引先マスタの初期データソースを確定し、Step 1 マスタ整備に進む。Phase 1 全体スケジュールの精度確定。
→ Phase 1 リリース 6月末の維持判断
SO WHAT
本PJの成功確率は
「業務委託先マスタの所在確認」と「過去支払.xlsx の入手」の2点にかかっている。技術的なブロッカーはほぼ解消済(cybozu.com 権限あり、THINKs API 無し前提も確定)。残るは情報・データの入手とその後の名寄せ作業の覚悟。
Step 0 のヒアリングが完了次第、Step 1 着手 → 6月末 Phase 1 リリースの現実性が確定する。