ワークフローのプロジェクトで日本のユーザから100%聞かれる「差し戻しはないの？」に対して答えます。なお、この記事は標準の申請ワークフロー機能（Flow designerと標準のRequest, Requested Item, Approval ,Catalog Taskテーブル）について書いています。
「差し戻し」とは？
差し戻しの定義
まず、ワークフローにおける「差し戻し」を定義しておきます。特に日系企業においては、似たような言葉がいくつかあり、人によって違うものを意味している場合がありますが、ここでは最も一般的だと思われる定義を記載します。
差し戻し … 申請内容に不備や誤りがあった場合に、決裁者（承認者）が申請者や自分より前の承認者に対し、申請内容の修正を求めて申請書を戻すこと
却下 … 申請内容に不備や誤りがあった場合に、決裁者（承認者）が申請書を否認し申請プロセスを終了させること
引き戻し … 申請内容に不備や誤りがあった場合や何らかの原因で申請が不要になった場合に、申請者自身が申請内容を取り下げること
一般的な差し戻しの実装（UI）
日系のソフトウェアベンダのワークフローシステムには差し戻しが実装されていることが多く、その場合の一般的な実装としては、決裁（承認）画面において、承認するか、却下するか、差し戻すかを選択でき、差し戻す場合には、申請者か、自分より前の承認者を選べる、というものです。
さらに、差し戻しを前提とする場合、申請時のUIとして、申請情報を入力後、直ちに最初の承認者に承認要求が行かず、一度”ドラフト状態”もしくは”下書き状態”になることが多いです。これは、この”ドラフト状態”が存在しない場合、申請者に差し戻すことができない（”ドラフト状態”がなければ、差し戻したとしても、ただちに最初の承認者に承認がいってしまう）ためだと思われます。
Flowに「差し戻し」はなく「却下」しかないし、ServiceNow社は「差し戻しを」実装する気もない
申請ワークフローツールなのに「差し戻し」ができないなんてありえない！実は機能があるんじゃ？と聞かれることがよくあるので、ServiceNowが「差し戻し」を実装する気がない証拠を上げておきます。
そもそもServiceNowのワークフローは「決裁（承認）」のための機能ではない
まず、「差し戻し」は一般的に稟議・承認システムに対して求められる機能です。しかし、ServiceNowのFlowは稟議・承認のための機能ではありません。下記はFlowに関するドキュメントです。
Flow Designer is a Now Platform® feature that enables process owners to automate work. Build multi-step flows from reusable components without having to code.
https://docs.servicenow.com/bundle/sandiego-servicenow-platform/page/administer/flow-designer/concept/flow-designer.html
Flowの説明にApprovalなどという単語は一度も出てきません。つまり、Flowは自動化のための機能であり、稟議・承認のためのシステムではないのです。Flowにおいて承認は多くの機能のうちの一つであり、むしろ目玉はノーコードでのワークフロー開発体験や、クラウド/オンプレ問わず多くのシステムと連携するためのコネクタを含むIntegrationHubです。
ServiceNowの申請管理テーブルには”ドラフト状態”が存在しない
差し戻しとセットで必要になると上述した”ドラフト状態”ですが、標準の申請ワークフロー機能を用いた場合にFlowの紐づき先となるRequested Itemテーブルには、”ドラフト状態”が存在しません。つまり、申請した瞬間にFlowが起動し、（承認があれば）第一承認者に承認要求がされます。
仮に、ここに無理やり申請時点に戻す機能を付けたとしても、そのまま第一承認者に流れてしまい、内容の修正ができないのです。
なお、申請前に内容を一時保存する機能としてWishlistが存在しますが、WishlistはRequested Itemが作成される前の状態になるため、この状態に戻すことはできません。
そもそも申請後に申請内容を変更することを想定していない
ServiceNow社のドキュメントや製品紹介を見ると、申請機能はService Portalを経由して使うことが前提とされています。（なお、RomeよりService Portalを大体するEmployee Centerという機能が追加されました）そして、Service Portalの標準の自身の申請を確認するticketページでは、申請時に入力した項目は申請後は読み取り専用となり、変更することができません。このことからも、そもそも申請後に内容を変更することを想定していないことがわかります。
なお、ACLとしては編集が可能になっています。
Workflow editorには「差し戻し」のようなが存在したが、廃止された
現在の標準のワークフロー機能であるFlow designerには、その前身であるWorkflow editorが存在します。Workflow Editorは現在でも利用できますが、現在はServiceNow社の公式トレーニングでも扱われていない、枯れた技術です。
Workflowは下図のように、キャンバス上にパーツ(Activity)を配置し、それらを線(Transition)で結ぶことでワークフローを表現します。そして、このWorkflowにはワークフローの状態を巻きもどすRollbackというパーツを配置したり、単純に線をそれより前のパーツに繋げることで「差し戻し」を実現することができました。
その後、Workflow designerは、よりシンプルな、上から下に流れる処理に特化しより簡単に開発できるようにしたFlow designerに置き換えられました。そして、Flow designerにはRollbackは実装されませんでした。Flow designerのRollback機能については、NowSupport（公式のサポートサイト）で言及されています。
Rollback in legacy Workflow is prone to error and must be reimagined. While we have rollback on the radar, it is not on our immediate roadmap for consideration.
KB0820128 Is Rollback Action available in the Flow Designer
考えはしてるけどしばらくは実装する気がないよ、ということですね。このナレッジ記事にあるコミュニティのリンクを見ると、2020年にこの旨の投稿がされており、未だに実装されていないことから、今後も実装される見込みは低いと言えるでしょう。
「差し戻し」が本当に必要かを考えよう
この事実を踏まえ、「差し戻し」が本当に必要かどうか、考えてみるべきです。
差し戻しは発生しないのが理想
本来差し戻しは発生しないほうがよいものです。差し戻しが発生した場合、申請者は内容を修正し再び申請し、決裁者（承認者）はもう一度承認を行う必要があり、双方にとって時間の無駄です。
差し戻し機能を無くすとどうなるでしょう。もし申請内容に不備や誤りがあった場合、再度申請しなければならなくなりますから、必然的に差し戻しされるような適当な申請・承認は減っていくのではないでしょうか。差し戻し機能を廃止することは、仕組みとして差し戻し率を下げ、業務を効率化することに繋がるのではないでしょうか。「現行踏襲」で差し戻しを求めるのではなく、「変革のいい機会」だと捉えるべきだと考えます。
差し戻しの代替案を考える
差し戻しがなぜ発生するかを分析すれば、その多くは代替案が存在するはずです。
例えば必要な情報が入力されていないことによる差し戻しが発生しているのであれば、申請フォーム上で必要な項目を作成し、必須化すればよいですし、申請内容のフォーマットがおかしいことによる差し戻しはフォーマットチェックをかければ済みます。
第一承認者がきちんと内容を見ていない、もしくは承認判断ができていないことが原因であれば、それは業務設計の問題ですので、承認者を変更する、無意味な承認は業務フローから削除する、承認の際に確認すべき観点を明確にする（これができている場合、ほとんどの観点は自動化できることに気が付くと思います）ことで解決できる場合がほとんどではないでしょうか。
それでも必要なら別モジュールの利用か、個別のアプリケーションとして開発を行うことを検討する
ここまで考えても、どうしても「差し戻し」が必要となった場合、別モジュールの利用を検討してみるとよいです。例えばServiceNowの代表的なモジュールである「インシデント管理」では、インシデント（問い合わせや障害）に対し、解決策を提示した後、解決策が不十分だった場合はインシデント再オープンし、業務フローを戻す機能を持っています。このように、業務として巻き戻しが発生することが避けられない場合、その機能を含むモジュールが既に存在している場合があるので、より適切なモジュールがないかを検討しましょう。
その上で、存在しない場合は、標準の申請管理機能をカスタマイズするのではなく、個別のアプリケーションとしてServiceNowプラットフォーム上で開発を行うべきでしょう。無理やり申請管理機能をカスタマイズし「差し戻し」を入れようとする場合、標準機能の思想とあまりに乖離しており、多くの工数がかかる上に将来のUpgradeに悪影響を与える可能性が高いため、避けるべきです。
以上です。
コメント