kintoneのプロセス管理は、業務をそのまま描かない

kintoneのプロセス管理は、業務を正確に表現しようとするほど、複雑になっていくことがある。

ある見積作成・申請アプリでは、複数の「作成種別」を扱っていた。

作成種別ごとに、確認する担当者が違う。
承認する責任者も違う。
必要な確認項目や、承認後の処理も少しずつ違う。

そのため、当初のプロセス管理では、作成種別ごとに独自の承認ルートとステータスが用意されていた。

たとえば、

• A種別の担当者確認中

• A種別の責任者承認中

• B種別の担当者確認中

• B種別の責任者承認中

• C種別の担当者確認中

• C種別の責任者承認中

といった具合である。

業務の内容が、そのままプロセス管理に表現されている。

一見すると、非常に丁寧で分かりやすい設計に見える。

しかし、この設計には大きな問題があった。

作成種別が増えるたびに、プロセスも増えていく

新しい作成種別を追加するたびに、専用のステータスとアクションが必要になる。

作成種別が一つ増えれば、確認用のステータスが増える。
承認用のステータスが増える。
差戻し用のアクションも増える。

プロセス管理の設定画面には、似たようなステータスと矢印が延々と並んでいく。

しかも、影響するのはプロセス管理だけではない。

ステータスを条件にしている処理があれば、それらも一緒に増えていく。

たとえば、

• ステータスごとの通知設定

• ステータスごとのアクセス権

• 一覧画面の絞り込み

• JavaScriptによる表示制御

• 帳票を出力できる条件

• ボタンを表示する条件

• 外部サービスへ連携する条件

などである。

新しい作成種別を一つ追加しただけなのに、修正しなければならない場所が何か所も発生する。

業務を忠実に表現したはずのプロセスが、次第に変更しにくい構造へと変わっていく。

業務の違いと、プロセスの違いは同じではない

ここで、一度立ち止まって考える必要がある。

作成種別が違うことと、プロセスの段階が違うことは、本当に同じなのだろうか。

作成種別によって承認者は違う。

しかし、そこで行われている処理を抽象化すると、多くの場合は次のような流れになる。

1. 担当者が内容を確認する

2. 責任者が内容を確認する

3. 承認が完了する

担当者の所属や役職は違っても、プロセス上の役割は同じである。

A種別では営業担当者が確認する。
B種別では給与担当者が確認する。
C種別では別の専門部署が確認する。

しかし、いずれもプロセス上は「最初の確認」である。

その次に行われる責任者の確認も、担当する部署は違っていても、プロセス上は「二段階目の確認」である。

そこで、作成種別ごとの業務名をステータスとして持つのではなく、プロセス上の段階を表す名前へ置き換えることにした。

導入したのが、

• 一次承認

• 二次承認

• 承認済み

という概念である。

「一次承認」は、単なる短い名前ではない

「A種別担当者確認中」を「一次承認」に変更する。

これだけを見ると、単にステータス名を短くしただけに見えるかもしれない。

しかし、重要なのは名前ではない。

複数の業務に共通する構造を見つけ、それを一つの概念として扱えるようにしたことに意味がある。

「一次承認」とは、特定の部署や作成種別を表す名前ではない。

そのレコードにおいて、最初の承認責任を持つ人が確認している段階を表している。

「二次承認」も同様である。

誰が承認するのかではなく、現在どの段階まで進んでいるのかを表す。

プロセス管理が持つ役割を、

「誰の業務なのか」

から、

「今どの段階なのか」

へ変更したのである。

作成種別ごとの差は、承認者に持たせる

もちろん、作成種別ごとの違いがなくなるわけではない。

A種別とB種別では、確認する人が違う。
必要な権限も違う。
場合によっては、二次承認が必要なものと不要なものもある。

これらの違いまで、無理に同じにする必要はない。

大切なのは、違いをどこに持たせるかである。

作成種別ごとの違いを、ステータス名やアクションの数で表現するのではなく、レコード内の設定値として持たせる。

たとえば、レコードに次のようなフィールドを用意する。

• 一次承認者

• 一次承認グループ

• 二次承認者

• 二次承認グループ

作成種別が選択されたときに、その種別に対応する承認者や承認グループを設定する。

プロセス管理では、すべての作成種別が共通して「一次承認」へ進む。

しかし、実際に一次承認を行う人は、レコードごとに異なる。

A種別のレコードではA部門の担当者が承認する。
B種別のレコードではB部門の担当者が承認する。

ステータスは同じでも、承認者は違う。

これにより、プロセスの骨格と、業務ごとの担当者を分離できる。

プロセス管理に、すべてを背負わせない

プロセス管理が複雑になる原因の一つは、業務上の違いをすべてプロセス管理で表現しようとすることである。

作成種別が違う。
担当部署が違う。
承認者が違う。
帳票が違う。
入力項目が違う。

これらをすべてステータスやアクションの違いとして表現すると、プロセス管理は急速に肥大化する。

しかし、これらは本来、別々の仕組みで管理できる。

作成種別は、作成種別フィールドで管理する。
承認者は、承認者フィールドで管理する。
表示する項目は、フィールド制御で管理する。
出力する帳票は、帳票の条件設定で管理する。
プロセス管理では、現在の進行段階だけを管理する。

一つの機能に多くの意味を持たせすぎない。

これは、kintoneに限らず、システム設計全般で重要な考え方だと思う。

現実の業務は、完全には同じにならない

プロセスを共通化すると聞くと、すべての作成種別を完全に同じ流れへ押し込めるように感じるかもしれない。

しかし、実際にはそうではない。

二次承認が必要な作成種別もあれば、一次承認だけで完了する作成種別もある。

特定の条件に該当した場合だけ、追加の確認が必要になることもある。

その場合でも、作成種別ごとに専用のステータスを増やす必要があるとは限らない。

承認者が設定されている場合だけ二次承認へ進む。
設定されていなければ、そのまま承認済みに進む。

このように、共通のプロセスの中で、必要な部分だけ条件分岐させることもできる。

重要なのは、例外があるたびに新しいルートを一本追加するのではなく、共通部分を維持したまま、差分だけを表現することである。

複雑な業務には、複雑なプロセスが必要なのか

業務が複雑だから、プロセス管理も複雑になる。

これは、ある程度は仕方がない。

しかし、業務の複雑さと、設定画面の複雑さは必ずしも比例しない。

複雑な業務の中にも、共通する構造はある。

誰が処理するのか。
何を確認するのか。
どの帳票を使うのか。

細かな違いを取り除いていくと、多くの業務は、

• 作成

• 一次確認

• 二次確認

• 完了

という単純な構造へ整理できることがある。

業務ごとの違いを無視するのではない。

違いを適切な場所へ移動するのである。

プロセス管理には、プロセスの段階だけを持たせる。

担当者の違いは承認者フィールドへ持たせる。
作成種別の違いは作成種別フィールドへ持たせる。
画面の違いは表示制御へ持たせる。

そうすることで、作成種別が増えても、プロセス管理そのものを大きく変更せずに済む。

プロセス管理は、業務をそのまま描かない

現場の言葉をそのままシステムへ入れることは、必ずしも分かりやすい設計にはならない。

業務をそのまま描けば、最初は分かりやすい。

しかし、業務が増え、条件が増え、例外が増えたとき、その分かりやすさは急速に失われる。

必要なのは、業務を省略することではない。

業務の中から、共通する構造を見つけることである。

今回導入した「一次承認」「二次承認」という概念も、そのためのものだった。

プロセス管理が表すべきなのは、

「何の業務をしているのか」

ではなく、

「今、どの段階にいるのか」

なのかもしれない。

複雑な業務を扱うために、複雑なプロセス管理が必要とは限らない。

業務の違いを正しく分離できれば、プロセスそのものは、むしろ単純にできる。

次はこの記事を読みませんか？

要件定義の本質は、「概念に名前をつけること」