kintoneプロセス管理の設計方法｜ステータス・作業者・アクションの決め方

kintoneのプロセス管理は、便利な標準機能です。

レコードにステータスを持たせる。

作業者を指定する。

アクションボタンで次のステータスへ進める。

条件によってアクションを出し分ける。

作業者へ通知する。

これだけ見ると、申請承認のための機能に見えます。

もちろん、稟議、経費精算、休暇申請、見積承認などにも使えます。

ただし、プロセス管理は承認フロー専用ではありません。

問い合わせ対応、案件管理、制作進行、請求確認、在庫調整、日報確認のように、「レコードの状態」と「次に動く人」を管理したい業務にも使えます。

一方で、次のように設計すると運用で崩れます。

• ステータス名が「確認中」「処理中」「完了」だけで、誰待ちか分からない
• 作業者と責任者が混ざっている
• アクション名が「OK」「次へ」になっていて、何を判断したのか残らない
• 条件分岐を増やしすぎて、テストできない
• 通知を全員に出して、誰が次に動くのか分からない
• 差し戻し後に何を修正すべきか分からない
• 承認済みや完了後も重要項目を自由に編集できる
• 一覧や期限超過の確認を作らず、通知だけで運用している
• 申請業務以外にも使えるのに、承認用途だけで考えている

プロセス管理で最初に決めるべきなのは、ステータス名ではありません。

レコードがどの状態なら、誰が、何を見て、どのアクションを押せるのかです。

kintoneプロセス管理は、ステータスを表示する機能ではなく、「レコードの状態・作業者・次のアクション」を一体で管理する機能として設計します。

この記事では、kintoneのプロセス管理を、ステータス、作業者、アクション、条件分岐、通知、権限、コメント、履歴、申請以外の業務への応用まで含めて設計する方法を整理します。

kintoneワークフローの作り方はこちら
kintone承認フローの設計方法はこちら

先に結論：プロセス管理はレコードの状態管理

kintoneのプロセス管理は、レコードの状態を進めるための機能です。

kintone公式ヘルプでも、プロセス管理は業務プロセスに沿ってステータスや作業者を設定し、レコードの進捗を管理する機能として説明されています。

kintoneヘルプ：プロセス管理

基本要素は、ステータス、作業者、アクションです。

要素	意味	設計で決めること
ステータス	レコードの現在状態	未着手、対応中、確認待ち、完了など
作業者	その状態で次に動く人	担当者、確認者、承認者、次工程担当
アクション	状態を進める操作	対応開始、確認依頼、差し戻し、完了など
条件	アクションを出す条件	金額、種別、入力有無、担当部署など
通知	次の作業者に知らせる仕組み	自分宛通知、メール、リマインダー

kintoneヘルプ：ステータス、作業者、アクションとは

この3つを分けると、申請以外の業務にも使いやすくなります。

たとえば、問い合わせ対応なら次のように考えます。

ステータス	作業者	アクション
未対応	受付担当	担当者を決める
対応中	担当者	回答確認へ進める
確認待ち	上長、管理者	完了する、差し戻す
差し戻し	担当者	修正して再確認へ進める
完了	なし、または管理者	原則更新しない

重要なのは、ステータスが「状況のラベル」ではなく、次の行動を決める情報であることです。

ステータスを見た人が、誰がボールを持っているか分からないなら、プロセス管理としては弱いです。

ステータスを業務の節目で決める

ステータスは、業務の節目で決めます。

細かい作業をすべてステータスにすると、管理できません。

逆に、ステータスが粗すぎると、どこで止まっているか分かりません。

ステータスの粒度	よい例	悪い例
状態が明確	未着手、対応中、確認待ち、差し戻し、完了	確認中、処理中、保留
責任が分かる	担当者対応中、管理者確認待ち	作業中
次の行動が分かる	申請者修正待ち、経理確認中	要確認
一覧で使える	期限超過、承認済み未処理	完了っぽい

最初は、次のような基本形から始めると設計しやすいです。

ステータス	意味	次に動く人
未着手	まだ担当が動いていない	担当者、受付担当
対応中	担当者が作業している	担当者
確認待ち	作業結果を確認する	確認者、上長、管理者
差し戻し	修正が必要	担当者、申請者
完了	業務上の処理が終わった	原則なし、参照中心
保留	外部待ち、判断待ち	担当者、管理者

ステータスを増やす前に、一覧で何を見たいかを確認します。

承認待ち一覧。

差し戻し中一覧。

期限超過一覧。

完了前の後続処理待ち一覧。

一覧で使わないステータスは、増やしても運用されにくいです。

ステータスは、画面上の分類ではなく、一覧・通知・作業者・権限に影響する業務上の節目です。増やす前に「この状態で誰が何をするか」を確認します。

作業者と責任者を分ける

プロセス管理でよく混ざるのが、作業者と責任者です。

作業者は、現在のステータスでアクションを実行できる人です。

責任者は、そのレコードや業務の責任を持つ人です。

この2つは同じこともありますが、常に同じではありません。

役割	意味	例
作業者	次にボタンを押す人	担当者、確認者、経理担当
責任者	業務全体に責任を持つ人	案件責任者、部門長
申請者	レコードを起票した人	社員、営業担当
閲覧者	状況を確認する人	管理者、関係部署
次工程担当者	完了後に処理する人	発注、請求、契約、出荷担当

kintoneでは、作業者に設定された人が、該当ステータスでアクションを実行できます。

作業者は、固定ユーザー、組織、グループ、ユーザー選択フィールドなどから指定できます。

kintoneヘルプ：作業者の設定

実務では、人名固定よりも、レコード内のユーザー選択フィールドを使う方が保守しやすいです。

たとえば、問い合わせアプリなら「対応担当者」、確認が必要な業務なら「確認者」、請求確認なら「経理担当者」というフィールドを持たせます。

指定方法	向いているケース	注意点
固定ユーザー	管理者だけが処理する小さな業務	異動や退職に弱い
組織	部署内の誰かが対応する	誰が責任者か曖昧になりやすい
グループ	役割で管理する	グループ運用が必要
ユーザー選択フィールド	レコードごとに担当が違う	入力漏れ、誤指定を防ぐ
マスタ参照	部門や種別から自動設定したい	マスタ保守が必要

作業者を設定すると、自分宛通知や未処理一覧にも影響します。

そのため、作業者は「参考までに見てほしい人」ではなく、「次に動く人」に絞ります。

アクション名は現場の言葉にする

アクションは、ユーザーが押すボタンです。

ボタン名が曖昧だと、何を判断したのか後から分かりません。

曖昧なアクション名	改善例
OK	承認する、確認済みにする
次へ	確認依頼へ進める、経理確認へ回す
処理	対応開始、完了にする
戻す	差し戻す、申請者修正へ戻す
終了	完了にする、却下する、取消にする

アクション名は、現場で使う言葉にします。

問い合わせ対応なら「対応開始」「回答確認へ回す」「完了にする」。

経費精算なら「申請する」「上長承認する」「経理確認へ回す」「差し戻す」。

見積承認なら「提出前確認へ回す」「承認する」「再見積へ戻す」。

業務	アクション名の例
問い合わせ	担当者を決める、回答確認へ回す、完了にする
案件管理	商談化する、見積作成へ進める、受注にする、失注にする
制作進行	着手する、初稿確認へ回す、修正へ戻す、納品完了にする
請求確認	請求確認へ回す、差し戻す、請求済みにする
申請承認	申請する、承認する、差し戻す、却下する

アクション名を決めるときは、実行前ステータス、作業者、実行後ステータス、条件を表にします。

実行前ステータス	作業者	アクション名	実行後ステータス	条件
未着手	受付担当	対応開始	対応中	担当者が入力済み
対応中	担当者	確認へ回す	確認待ち	回答内容が入力済み
確認待ち	確認者	完了にする	完了	問題なし
確認待ち	確認者	差し戻す	差し戻し	差し戻し理由あり
差し戻し	担当者	再確認へ回す	確認待ち	修正済み

この表があれば、プロセス管理の設定画面で迷いにくくなります。

条件分岐と通知を最小限にする

プロセス管理では、条件によってアクションを出し分けられます。

公式ヘルプでも、フィールドの値を条件にして、特定のアクションを実行できるかどうかを設定できることが説明されています。

kintoneヘルプ：アクションが実行できる条件の設定

条件分岐は便利ですが、増やしすぎると管理できません。

最初は、次のような分岐に絞ります。

条件	使いどころ	注意点
申請種別	承認ルートや必要確認者を変える	種別を増やしすぎない
金額	高額時だけ上位承認へ回す	税込、税抜、合計の定義を固定する
担当部署	部署ごとに作業者を変える	組織変更への対応が必要
入力有無	添付や理由がないと進めない	入力必須設定と重複しないようにする
重要度	緊急、重要顧客、期限超過	主観になりすぎないよう分類する

通知も最小限にします。

通知は、関係者全員に知らせるためではありません。

次に動く人へ知らせるためです。

タイミング	通知先	目的
未着手になった	受付担当、担当者	初動を促す
確認待ちになった	確認者	判断を依頼する
差し戻しになった	担当者、申請者	修正を依頼する
完了した	必要な関係者	結果を共有する
期限を超過した	作業者、責任者	滞留を解消する

kintoneメール通知の設計方法でも整理したように、通知は多いほど良いものではありません。

承認待ち一覧、対応中一覧、期限超過一覧を作り、通知と一覧を組み合わせます。

編集権限・コメント・履歴の使い方

プロセス管理は、ステータスを進めるだけでは足りません。

どの状態で誰が編集できるかも決めます。

状態	編集方針
未着手	受付担当や申請者が必要項目を編集できる
対応中	担当者が対応内容を編集できる
確認待ち	担当者の重要項目は原則編集しない
差し戻し	指定された項目だけ修正できる
完了	原則編集不可。管理項目だけ更新できる

公式ヘルプでは、プロセス管理と一覧、通知、アクセス権を組み合わせると便利な設定として整理されています。

kintoneヘルプ：プロセス管理と組み合わせると便利な設定

実務では、次のように組み合わせます。

設計要素	使いどころ
一覧	承認待ち、対応中、差し戻し、期限超過を見つける
通知	次に動く人へ知らせる
レコードアクセス権	関係者だけが見られるようにする
フィールドアクセス権	金額、個人情報、管理項目を制御する
コメント	判断理由や確認事項を残す
変更履歴	重要項目がいつ変わったか追う

コメントは便利ですが、すべてをコメントに書くと集計しづらくなります。

差し戻し理由、期限超過理由、完了理由のように、後から分析したいものは項目として持ちます。

コメントは補足や会話に使います。

プロセス管理で後から改善したい情報は、コメントだけに残さず、差し戻し理由や期限超過理由のような項目として持つ方が運用改善に使えます。

申請以外の業務への応用

プロセス管理は、申請承認だけに使うものではありません。

「状態」と「次に動く人」がある業務なら使えます。

業務	プロセス管理の使いどころ
問い合わせ管理	未対応、対応中、確認待ち、完了
案件管理	リード、商談中、見積提出、受注、失注
制作進行	未着手、制作中、初稿確認、修正中、納品
請求管理	請求準備、確認待ち、請求済み、入金確認
在庫調整	申請中、確認待ち、調整済み、取消
日報確認	提出、確認待ち、差し戻し、確認済み

TOKYO DIGITALの記事でも、kintoneのプロセス管理は一般的なワークフロー専用ツールとは異なり、レコードの状態と担当者を管理する機能として説明されています。

TOKYO DIGITAL：kintoneの「プロセス管理」完全ガイド

この考え方は重要です。

たとえば問い合わせ管理では、承認はありません。

それでも、未対応、対応中、確認待ち、完了という状態があります。

案件管理でも、承認ボタンは不要でも、誰が次に動くかを明確にしたい場面があります。

kintone案件管理の設計方法やkintone問い合わせ管理の設計方法でも、状態と担当者の整理は重要です。

プロセス管理は、承認のためだけでなく、業務のボールがどこにあるかを見えるようにするために使えます。

よくある失敗

kintoneプロセス管理でよくある失敗を整理します。

ステータスを増やしすぎる

細かい作業をすべてステータスにすると、アクションも通知も増えます。

ステータスは、一覧で見たい節目、作業者が変わる節目、権限が変わる節目に絞ります。

作業者を関係者全員にする

関係者を全員作業者にすると、誰がボタンを押すべきか分からなくなります。

参考に見てほしい人は閲覧者や通知先で扱い、作業者は次に動く人に絞ります。

アクション名が曖昧

「OK」「次へ」「処理済み」は、何を判断したのか分かりません。

承認する、差し戻す、確認へ回す、完了にする、のように行動が分かる名前にします。

通知だけで運用する

通知を見逃すと業務が止まります。

承認待ち、対応中、差し戻し、期限超過の一覧を作り、定期的に確認します。

完了後に重要項目を編集できる

完了後に金額、取引先、添付資料、対応結果が変わると、履歴の意味が弱くなります。

完了後に変更する場合は、管理者修正、再オープン、変更申請のどれで扱うか決めます。

プロセス管理の設計手順

実際に設計するときは、次の順番で進めます。

順番	決めること	成果物
1	対象業務	申請、問い合わせ、案件、請求など
2	レコード単位	何を1件の状態管理対象にするか
3	ステータス	未着手、対応中、確認待ち、差し戻し、完了
4	作業者	各状態で次に動く人
5	アクション	どのボタンで次の状態へ進むか
6	条件分岐	金額、種別、担当部署、入力有無
7	通知と一覧	誰に知らせ、どの一覧で見るか
8	権限	誰が見られるか、編集できるか
9	コメント・履歴	理由や判断をどう残すか
10	運用後の棚卸し	滞留、差し戻し、不要通知を見直す

この順番で設計すると、プロセス管理を設定画面の機能としてではなく、業務状態を動かす仕組みとして扱えます。

kintoneワークフローの作り方でも整理したように、先に表を作り、テストレコードで通常・差し戻し・例外を確認することが重要です。

まとめ：プロセス管理は、誰が次に動くかを決める設計

kintoneのプロセス管理は、単なるステータス表示ではありません。

ステータス、作業者、アクション、条件、通知、権限を組み合わせて、レコードを次の状態へ進めるための機能です。

申請承認だけでなく、問い合わせ、案件、制作、請求、在庫調整、日報確認のような業務にも使えます。

ただし、ステータスを増やしすぎたり、作業者を関係者全員にしたり、通知だけに頼ったりすると、運用で崩れます。

プロセス管理を設計するときは、まず対象業務のレコード単位を決めます。

次に、状態、作業者、アクション、条件、通知、権限を表にします。

最後に、一覧とテストレコードで運用できるか確認します。

Bitlightでは、kintoneプロセス管理について、申請、問い合わせ、案件、請求、制作進行などの業務に合わせて、ステータス、作業者、アクション、通知、権限、一覧、運用後の棚卸しまで一緒に設計できます。

「プロセス管理を入れたが誰が次に動くか分からない」「ステータスや通知が増えすぎた」「申請以外の業務にも使いたい」という場合は、設定画面ではなく業務の状態遷移から見直すのが近道です。