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

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

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

📅 2026-05-14 時点 🎯 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

承認ワークフロー

編集部担当者 → 総務(河合:初動チェック)→ 総務(高橋:支払日入力・最終確認)の流れを 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日)/ ハラスメント窓口記載
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 と比較した時短ポイント:① 書籍・取引先選択で「著者名・適格番号・住所」が自動入力 → 転記ゼロ。② 業務種別選択で支払条件が自動表示 → 暗記不要。③ 合計金額が自動計算。
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別 着手可能率(情報・条件が揃っている割合)

Step 0: 設計準備95%
Step 1: マスタ整備60%
Step 2: 発注書アプリ実装95%
Step 3: 支払依頼アプリ実装85%
Step 4: UAT・段階展開70%
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. 1
    業務委託先データの所在確認:THINKs 印税管理メニュー、支払一覧、支払調書一覧の中身確認。CSV エクスポート可否。→ 高橋さん・経理に確認していただきたい
  2. 2
    過去 1 年分の月次支払依頼.xlsx 共有:取引先マスタの初期データ抽出に必須。→ 高橋さんから 2025/5 〜 2026/4 分を受領したい(機密扱い)
  3. 3
    編集部 kintone ライセンス追加判断のタイミング合意:Stage 1(6月末)完了後の判断。→ 編集部 2-3名 → 全員(最終形)へのステップ確認
  4. 4
    2段階パイロット案への合意:Stage 1(総務)→ Stage 2(編集部)の進め方。→ 井坂部長と連名でのトップダウンアナウンス文面検討
  5. 5
    PDF 細部仕様の確認:社印・様/御中・フリーランス判定。→ 高橋さん・松本さんに既存運用を確認していただきたい
  6. 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 リリースの現実性が確定する。