gusuku Customineでプロセス管理を作ってみよう - アールスリーインスティテュート

公開日：2025-12-12

注意

本記事は情報提供を目的としており、本記事の内容は無保証、サポートの対象外です。
サポート窓口、問合せ窓口にご質問をいただいても対応いたしかねますのでご了承ください。

こんにちは。システム開発グループのやまさです。

皆さん、kintoneのプロセス管理は使っておられますでしょうか？
簡単な設定でワークフローを実現することができてとても便利ですよね～

今回は、そんなプロセス管理と同じような機能を、gusuku Customineを使って作ってみよう、というお話です。

なんでわざわざそんなことを・・・と思われるかもしれませんが、
gusuku Customineで作った場合の良い点や、ノウハウもありますので、ぜひ参考にして頂けると嬉しいです。

実現するワークフロー

今回は、経費精算の業務を題材にしてみたいと思います。
大きくは以下のような流れです。

精算をしたい人が申請
申請者の上長が承認または差戻し
経理の方が精算

kintone基本機能のプロセス管理を使った場合の実現イメージ

まずは、gusuku Customineを使わずに、kintoneだけ使用した場合のイメージを作ってみました。

kintoneアプリ（経費精算アプリ）

プロセス管理の設定（経費精算アプリ）

今回はこれと同等の内容を、gusuku Customineを使って実現しようと思います。

gusuku Customineでの実現

まず始めに、プロセス管理を実現するにあたって必要な、以下の情報を定義していきます。

ステータス（未申請など）
ステータスごとの作業者
ステータスの遷移ルール（どのステータスからどのステータスへ移動できるか）
ステータスを遷移させるときのアクション名

今回は、これらの情報をkintone上にマスタアプリとして定義する形でやってみたいと思います。

具体的には、2つのマスタアプリを用意します。
１．ステータスマスタアプリ
　　ステータス名と、ステータスごとの作業者を定義します。

２．ステータス遷移マスタアプリ
　　ステータスの遷移ルールとアクション名を定義します。

次に、先ほどの経費精算アプリを修正します。

プロセス管理を使用しない代わりに、ステータスと作業者用のフィールドを追加します。
追加したフィールドに対して、ルックアップフィールドを使って、ステータスマスタの情報をコピーするようにします。

最後に、プロセス管理のようなUIをgusuku Customineを使って作っていきます。

このような見た目にしてみました。ドロップダウンでアクションを選択して、「実行」ボタンを押すとステータス名が変わる、という形です。

gusuku Customineでの実装は以下のようにしてみました。

補足すると、以下のようなことをやっています。

詳細画面表示時に、画面に表示しているレコードのステータスコードに応じて、実行可能なアクション名をドロップダウンで表示する
- ただし、ログインユーザーが、画面表示しているレコードの作業者に含まれる場合のみ
「実行」ボタンを押すと、画面表示しているレコードのステータスコードを、選択されたレコードのステータスコードで更新する

早速動かしてみたいと思います。

申請者が「申請」を選択して「実行」を押すと

ステータスが「承認待ち」に変わりました。また、作業者が上長へ変わっています。
さらに、申請者の画面には、ドロップダウンと実行ボタンが表示されなくなりました。

次に、承認者である、上長Aの画面を見てみましょう。

上長Aの画面には、ドロップダウンと実行ボタンが表示されています。
また、ドロップダウンでは2つのアクションが選択できるようになっています。

上長Aが「承認」を選択の上、「実行」を押すと

ステータスが「精算待ち」に変わりました。作業者も、経理へ変わっています。

また、一覧を用意すれば、自分が作業者になっているレコードだけを表示することもできます。

いかがでしょう。プロセス管理に近い雰囲気になってるのではないでしょうか。

gusuku Customineを使ってプロセス管理を作ることの良い点

無事、kintone基本機能のプロセス管理のようなものをgusuku Customineを使って作ることができました。
せっかくなので、この方法の良い点も紹介させて頂きますね。

プロセス管理の設定をマスタで定義できる
ステータスの追加/変更/削除が簡単です。kintoneアプリやgusuku Customineの設定変更は一切不要です。
ステータス名とは別にステータスコードを持つことができる
これは、ステータスを参照したkintoneカスタマイズを行う際にメリットとなります。
プロセス管理を使ったカスタマイズを実装する場合、ステータス名を参照して実装する形になりますが、
この形の場合は、ステータスコードを参照して実装することができます。
例えば、ステータス名を変える、という変更が発生した場合を考えましょう。
もし、プロセス管理を使っている場合はステータス名を参照しているカスタマイズを全て修正する必要がありますが、
この形のようにステータスコードを持たせて、それをカスタマイズでは参照する形で実装すれば、修正する必要がありません。
CSVでステータスを更新することができる
何らかの理由で、CSV読み込みを使ってレコードを一括で新規登録/更新したいケースがあると思います。
プロセス管理の場合は、CSV読み込みでステータスを変更することはできません。
一方でこの形の場合は、ステータスコードがルックアップフィールドになっているので、CSVでステータスを変更することができます。

めでたしめでたし？

プロセス管理と同等の機能を実現した上、メリットもあって、めでたしめでたし・・・
とはいきません。
実は、今の実装には問題があります。

同時更新に対応できていません

皆さんよくご存知の通り、kintoneにはレコードの同時更新をブロックする仕組みがあります。
kintone ヘルプの「レコードを編集する」によりますと、

複数のユーザーが同じレコードを同時に編集しようとした場合、最初に編集内容を保存したユーザーの操作が優先されます。
あとから編集内容を保存しようとしたユーザーは、次のエラーメッセージが表示され、編集内容を保存できません。

とあります。

レコード編集画面でレコードを保存しようとすると、以下のようなメッセージが画面上部に表示されることがありますよね。

これは、プロセス管理でアクションを実行した際も同様の動きとなります。
アクションを実行するためのボタンを押した際に、レコードの内容に変更が入っている場合は同様のエラーメッセージが表示されて、アクションの実行がキャンセルされます。

これによって、画面表示されている状態から実はステータスが変わっているのに、アクションを実行してステータスが変更される、ということが起こらないようになっています。

しかし実は、先ほどお見せしたgusuku Customineの実装では同時更新を防ぐことができていません。

実際にやってみます。

ステータスが「承認待ち」のレコードが1つあるとします。
このレコードを、上長Aと上長Bがそれぞれのパソコンの画面上で表示しているとします。

ここで、上長Aは承認を後回しにして、お昼休憩のために離席しました。
一方で、上長Bが承認しました。

その後、経理の人が精算まで完了させて、ステータスを「完了」へ進めました。

問題はここからです。
しばらくして、お昼休憩から上長Aが戻りました。
先ほど自分が開いていたレコードの画面を見ると、上長Aの画面では、ステータスがまだ「承認待ち」のままです。

上長Aは、承認がまだ終わっていないと思い、「承認」アクションを実行しました。

するとどうでしょう。本来なら、ステータスが「完了」のままとなるべきところが、「精算待ち」になってしまいました。
その後、経理の方が再度精算をしてしまい、申請者の方は経費の二重取りをすることができました。
めでたしめでたし。

・・・ではありませんね。これは困りました。

gusuku Customineの「レコードを書き出す」系のやることの出番です

安心してください。解決方法がちゃんとあります。

少し技術的な話になりますが、kintoneには、kintoneカスタマイズを行う際に使用することができる、「kintone REST API」があります。
kintone REST APIの中の、レコードを更新するAPI（1件のレコードを更新する/複数のレコードを更新する）のリクエストパラメーターの1つに、「revision」というものがあります。
これを使うと、レコードを更新するAPIを使ってkintoneのレコードを更新する際に、先のような同時更新が起こることを防ぐことができます。（「revision」についての詳細はこちらもご参照ください）

gusuku Customineのレコード更新系のやること（こちらにまとまっています）も、先のリクエストパラメーター「revision」の操作に対応しているのですが、
中でも、「レコードを書き出す」系の以下2つのやることは、レコード更新の目的で使う際に、ある時点のレコードのリビジョンを「revision」パラメータの値として指定できる点が特徴です。

「レコードを書き出す」
「レコードを1つずつ書き出す」

今回の問題を解決するためには、

画面表示している状態のレコードの内容から変更が入っている場合は、レコードの更新（今回でいうと、ステータスコードの変更）をキャンセルする

という動作が必要になるのですが、gusuku Customineの「レコードを書き出す」系のやることを使うと、この動作を実現することができます。

同時更新に対応したgusuku Customineの実装

具体的な実装のお話に戻ります。

先に概要を説明すると、冒頭で実装したカスタマイズに対して、以下の修正を加えます。

１．レコード詳細画面表示時に、画面表示しているレコードを取得する

２．「実行」ボタンを押したら

　　　２－１．レコード更新の前に、画面表示時からレコードの内容が変わっていないかチェックする

　　　２－２．画面表示時のレコードのリビジョンを指定してレコードを更新する

では、gusuku Customineの実装と、実装の補足説明を記載しますね。　

gusuku Customineの実装

実装についての補足

1. レコード詳細画面表示時に、画面表示したレコードを取得

これは、「編集中のレコードデータを退避する」を使って実現します。
やることの名前に「編集中」とついているのですが、実は詳細画面でも使用できます。
詳細画面表示時のレコードを取得しておいて、この後の処理で、このレコードのリビジョンを参照します。

２－１．レコード更新の前に、画面表示時からレコードの内容が変わっていないかチェック

レコードの更新を実行する前に、「画面表示時の状態から変更が入っていないか？」をチェックします。
レコードの更新をする前に、既に変更が入っているのであれば、それを利用者へ通知してあげる、という形です（親切ですね）

２つの値を比較して条件を満たすならばを使って、画面表示時のレコードのリビジョンと、ボタンを押した後に改めて取得したレコードのリビジョンを比較し、不一致の場合はエラーダイアログを表示しています。

先ほどのお昼休憩から帰った上長Aのケースでは、「実行」ボタンを押した際にこのチェックに引っかかり、以下のようなエラーダイアログが表示されます。

「OK」を押すと画面がリロードされて最新のレコードの内容が表示されます。
レコードの更新は行っていないので、ステータスは正しく「完了」のままです。

２－２．画面表示時のレコードのリビジョンを指定してレコードを更新する

２－１の修正を加えるだけで、先ほど起きていた問題は防ぐことができるように見えるのですが、実はまだ完璧ではありません。
どういうことでしょうか。

次は、上長Aがもう少し早くお昼休憩から戻った結果、経理の方の「精算」と上長Aの「承認」がほぼ同時に行われたケースを考えてみましょう。
そうです。２－１のチェックをクリアした直後（ほぼ同時）に他の人によってレコードが更新されたケースに対応できていないんです。

具体的な例をあげると、上長Aの「承認」と経理の方の「精算」がほぼ同時に実行されたとします。
このとき、以下のような順番で処理がされると、先ほどの問題と同様に、ステータスが「精算待ち」となってしまいます。

上長A：２－１のチェックをクリア
↓
経理：２－１のチェックをクリア
↓
経理：レコードの更新（ステータスを「完了」へ変更）
↓
上長A：レコードの更新（ステータスを「精算待ち」へ変更）

パソコンやネットワークの状況次第ではこういったことが起こることがあるのですが、
２－１の修正だけではこのケースに対応することができていません。

このケースに対応するために、gusuku Customineのレコード更新の際の「やること」として、「レコードを書き出す」を使います。
（今回のケースでは「レコードを1つずつ書き出す」を使う形でも問題ございません）

ポイントは、「レコード」パラメータに、「実行」ボタンを押した後に改めて取得したレコードを指定する点です。（※）
こうすることで、万が一、２－１のチェックをクリアした後に他の人によってレコードが更新された、というようなケースにも対応することができます。
動作としては、レコード更新（ステータスを変更）する際に、画面表示している内容からレコードの内容が変更されている場合は更新をキャンセルする、という動きになります。

（※）画面表示時のレコードじゃないの？と思われたかもしれませんが、このレコードのリビジョンは、画面表示時のレコードのリビジョンと一致していることを２－１のチェックで確認済なので、問題ありません。

この修正の結果、以下のようなエラーダイアログを表示の上、レコードの更新がキャンセルされるようになります。

画面をリロードすると、本来あるべき「完了」ステータスのままになっています。

これで本当にめでたしめでたし。

まとめ

いかがでしょうか？
「レコードを書き出す」の素晴らしさについて知って頂けたのではないでしょうか？
gusuku Customineを使ってプロセス管理を作る、というケースそのものはないかもしれませんが、ご紹介したノウハウは他の場面でも役立つことがあるかと思います。
本記事の内容が、皆様のお役に立てれば幸いです。

キミノマホロ for kintone

アールスリーでは業務改善・システム開発を行うサービスを「キミノマホロ for kintone」として提供しています。
「キミノマホロ for kintone」は業務改善のプロセスをイロハで3つのフェーズに分け、フェーズごとに作業をメニュー化しています。
　　【イ】業務改善の始まり：業務改善の方向性を決める
　　【ロ】業務改善に必要なkintoneアプリ作成：業務改善を実現するための仕組み（kintoneアプリ）を作る
　　【ハ】業務改善の実行サポート：業務改善を進める