ステータス削除で失敗しない!kintoneアプリの設定変更テクニック

公開日:

こんにちは!システム開発グループの鈴木です!

kintoneは後から変更を加えて、業務の変化に対応できる柔軟さが魅力の一つですが、やはり本番運用中のアプリの設定を変更することは、既存レコードへの影響を考えないといけないので、慎重さが求められるものですよね。

設定変更の中でも難しい物の一つがプロセス管理の設定の変更です。特に「既存ステータスの削除」はそのステータスのレコードが存在する場合は削除できないようになっています。(kintoneヘルプのプロセス管理の設定変更に関するページはこちら

ステータスの削除は大掛かりになるので、可能であれば避けたい作業です。ですが、最初は必要だと思っていたステータスでも、例えば業務が変わって、分担していた業務を統合してステップを分けなくてよくなったり、レコードの種類によって承認ルートを分けていたが、承認ルートを統一することになったりと、ステータスを削除したくなることはあるものです。

そこで、ステータスの削除する際に、本番運用中のアプリにできるだけ影響を与えないようにするためにできることをご紹介します。

(ただし、ここでご紹介するのは一般的なパターンを想定したものです。実際にはアプリの性質やプロセス管理の設定によって対応方法は異なります)

ステップ1:本当にステータスの削除が必要なのか考える

「ステータスを削除したい」ことはたしかにあるのですが、少し立ち止まって考えてみてください。そのステータスは今後不要でも、新規にそのステータスのレコードが増えなければOK、という場合もあります。

たとえば、2ルートあってそれぞれの終点となるステータスが違っていたけど、そのルートを統合することになった場合、片方の終点は不要になりますが、不要になった終点にたどりついてしまっているレコードを別の終点に無理やり変える手間をかけてまで、削除しないといけないものではないと思います。

そういう場合は不要になったステータスに進むルートを遮断するだけで、ステータス自体はそのまま残しておいて問題ないと思います。

ステップ2:不要ステータスに進むルートを遮断する

プロセス管理の設定を変更するのですが、いきなりステータスの削除はできないので、まずこれ以上このステータスのレコードが増えないように、このステータスへのルートを遮断、つまりプロセス管理のアクションを削除します。遮断したルートの代わりに別のルートの作成が必要な場合は併せて実施します。

ステータスの削除が不要な場合はここで作業は終わりです。ステータスの削除が必要な場合は次に進みます。

ステップ3:レコードのステータスを変更する

ステータスの削除が必要な場合は、削除するステータスに現在なっているレコードを、別のステータスに変更しないといけません。変更する方法は「手動で変更していく」「カスタマイズで一括で変更する」以外に、「待つ」という手もあります。

「待つ」というのがどういうことかと言うと、一旦そのまま運用して、自然に減っていくのを待つということです。先にそのステータスになるルートを遮断しているので、後は減る一方でいずれは無くなるはず、というわけです。

これは削除するステータスがワークフローの途中のステータスの場合に使える方法なのですが、既存レコードがこれまで通りの進み方をするので、比較的安全な方法と言えます。逆に言うと、ステータスを無理やり変えるというのは、イレギュラーなことなので、既存の機能や運用と矛盾してしまうリスクがある、ということですね。

ただ、ワークフローの進みが遅かったり、勝手には進まない状態だったりする場合は、「手動で変更していく」もしくは「カスタマイズで一括で変更する」で強制的に別のステータスに変更する必要が出てきます。変更先としたいステータスへのルートが無い場合は、事前に臨時ルートを作成しておく必要があります。

また、ステータスの変更作業が必要な場合は、事前に関係ユーザーに伝えて、その時間帯は運用をストップしてもらいましょう。もし作業中に他の人にレコードを編集されたり、ステータスを変更されたりしてしまうとエラーになる可能性があります。

実際にステータスを無理やり変更する場合は、基本的に「作業者を自分に変更する」→「ステータスを変更する」の2ステップが必要になります。

「手動で変更していく」の場合はこれを各レコードに手動で実施していくので、レコードが多いと骨が折れます。よほどレコードが少なくない限りは、「カスタマイズで一括で変更する」方法をとった方がいいでしょう。弊社のgusuku Customine(kintoneアプリをノーコードでカスタマイズできるツール)を使えば簡単に、「対象のレコードすべてに一括で作業者変更とステータス変更を実行する」機能を作成できます!

こちらの記事に詳しく記載しておりますので是非ご覧ください!)

ただし、レコードの一括更新は、更新対象のレコードや更新内容を誤った場合、元に戻すのが困難というリスクを伴います。別環境のアプリで十分テストした上での使用をお勧めします。また、ステータスが変更されたレコードがその後問題なくワークフローを進められるということも、事前に確認しておきましょう。

ステップ4:ステータスを削除する

削除するステータスのレコードが存在しなくなれば、ステータスを削除することができます。臨時ルートを作っていた場合は同時に削除しましょう。なお、ステータスを削除しても、既存レコードの「ステータスの履歴」には、そのステータスであった履歴は消えないので安心してください。

まとめ

まとめると、今回のポイントは以下の3つです。

  • ステータスの削除が本当に必要なのかを考えよう。
  • 削除が必要な場合、既存レコードのステータスを変更しないといけないが、待てば解決する場合もある。
  • ステータスの一括更新は十分テストした上で、実施も慎重に。

ステータスの削除が既存レコードに影響を与えないようにできることを書いたのですが、そもそもプロセス管理の設定の変更自体が、運用や機能に与える影響が大きいです。変更によって今まで動いていた機能が動かなくなったり、権限設定の変更が必要になったりすることもあります。

変更する際は、事前に別の環境でも同様の設定をしてみて、本番と同じ権限のテストユーザーを使って、ワークフローを一通り回せることを確認した上で、本番運用中のアプリに反映しましょう。

投稿者プロフィール

アバター画像
すずき
kintoneがメインのエンジニアです。空き時間の半分を合気道に使います。