承認経路のメンテが終わらない理由

人事異動の内示が出ると、情シスの手元には経路修正のリストが積み上がっていきます。

承認経路に入っている担当者の名前を一つずつ確かめて、抜ける人を外し、後任を入れる。この作業のために、発令日までの数日は他の仕事を止めて張り付くことになります。

期が変わるたびに、メンテ地獄がやってきます。ワークフローの運用と切り離せない業務として、半ば当たり前になっていないでしょうか。

経路の一覧を書き出して氏名で検索をかけ、ヒットしたものを1本ずつ開いて直していく。そこまでやっても1本だけ抜けていて、発令日の翌朝に「承認者が退職者のままです」と連絡をもらってしまう。そんな経験、ありませんか。

なぜその経路にその人が入っているのかを説明できる人が、もう社内に残っていない。だから、とりあえず後任に置き換えておく。これもよくある話だと思います。

しかもこの作業、ワークフローシステムを長く運用している会社ほど重くなっていきます。経路の本数が増えて、例外の分岐も増えていくからです。

相談の場でも、毎回この話になります

kickflowでフィールドセールスを担当している西尾です。承認経路の設計や見直しのご相談に立ち会っていると、経路修正の負荷は必ずと言っていいほど話題に上がります。

正直に言うと、私も一度ここでつまずいています。「異動のたびの経路修正を減らしたい」とご相談をいただいたときに、直し方の工夫や運用ルールの話ばかりを並べてしまって、肝心の「なぜ毎回直さなければならないのか」にはうまく答えられませんでした。

そのとき引っかかったまま残っていた論点を、あらためて整理したのがこの記事です。

経路修正の重さは、担当者の手際でも、ツールの性能でも決まりません。

決まるのは、もっと手前の設計です。承認ステップを「誰に」割り当てたか。人に割り当てた経路は人が動くたびに修正が要り、役割に割り当てた経路は人が動いても残ります。

そこで本稿では、承認ステップの割り当て方式を3つに整理します。

そのうえで、多くの会社がすでに使いこなしている役職参照でもなお個人名が残ってしまう領域を特定し、その領域を引き受けるチームの設計、チームに割り当てるときにあわせて決めておくこと、自社の経路を仕分ける判断フローまでをお話しします。

読み終わるころには、次の異動シーズンに向けて、どの経路から手を付け、どこまでを個人指定のまま残してよいのかが、順番のついた手順として見えているはずです。

経路修正が人事イベントに連動してしまう構造

そもそも、決裁権限規程やワークフローの業務設計書に、個人名は登場しません。

「所属長が承認する」「経理部長が決裁する」「安全管理責任者が確認する」。規程は、役割の言葉だけで書かれています。

ところが、システム上の経路には、いつのまにか個人名が入り込みます。導入時は役職ベースで組んだはずなのに、運用が始まると例外が生まれるからです。

「この申請だけは、課長ではなく実務に詳しいあの人に見てほしい」

こうした要望の一つひとつは、合理的な判断です。

審査の担当者は決まっているのに、その人の役職が係長で、役職名では特定できないというケースもあります。妥当な判断の積み重ねが、経路の中の個人名を増やしていくわけです。

経路に人を直接置いた瞬間から、その人に起きる変化はすべて設定変更になります。

異動、退職、休職、昇格、産育休。人事の出来事が、そのままシステムの作業に変換される構造です。

経路修正が終わらないのは、変換が起き続けているからにほかなりません。

承認ステップの割り当ては、3つの方式に整理できる

承認ステップに「誰がやるか」を持たせる方法は、突き詰めると3つです。3つ目の役割チームは、組織規程には載っていない、役割の単位で作るチームを指します（本稿では役割チームと呼びます）。

個人指定は、誰が処理するかが明確で、設定も直感的です。その代わり、人の変化がすべて設定変更になります。

役職・組織参照は、申請者の所属組織をたどって「その部の部長」を動的に解決する方法。人事マスタや組織図が正しく保たれていれば、異動には自動で追従します。

役割チームは、組織図上のチームに承認ステップを割り当て、そのチームに所属している人が処理する方法です。誰がやるかは、経路ではなくチームの所属で管理します。

多くの会社は、役職・組織参照までは使いこなしています。むしろ、導入時に真っ先に設計するのがこの部分。

それでも経路修正がなくならないとすれば、残っているのは役職・組織参照でカバーできない領域のはずです。

役職参照だけでは、なぜ個人名が残るのか

役職・組織参照が解決するのは、申請者から見た縦の関係です。

所属課の課長、所属部の部長、その上の本部長。組織図の階層を上にたどって行き着く承認は、この方式で自動化できます。

でも、規程に書かれた役割の中には、組織図の階層をたどっても行き着けないものがあるんです。

押印の管理担当。契約書の法務審査。内部統制上のチェック。安全審査。情報システムの利用承認。

どれも申請者の上司ではありません。部門をまたいで特定の機能を担う人たちであり、申請者の所属をたどっても解決できない相手です。

しかも、役割を担う人の役職はまちまち。係長のこともあれば、役職のない専任担当のこともあります。役職名を手がかりにしても、特定にはたどり着けません。

行き先を失ったステップが、個人指定で実装されます。

異動シーズンに最後まで残る修正対象は、たいていこの部分です。ツールの機能が足りないのではなく、縦のライン向けの仕組みで部門横断の役割を表現しようとしているところに、無理があるだけなんです。

組織図に「役割チーム」を作る

部門横断の役割の割り当てには、役割チームを使います。公式の組織図には存在しないチームを、ワークフロー上の組織図にあえて作る方法です。

押印管理チーム。契約審査チーム。安全審査チーム。

会社の組織規程には載っていなくても、ワークフローの世界では正式な組織として定義してしまう。承認ステップはこのチームに割り当て、実際に処理する人はチームの所属メンバーとして登録します。

設計をこの形に変えると、異動対応の中身が変わります。

経路そのものは触らず、チームのメンバーを入れ替えるだけ。担当が3人から4人に増えても、経路は無修正です。

設定変更の対象が、数十本の経路から、数個のチームの所属に絞られます。

副次的な効果も小さくありません。

チーム名を規程の役割名に合わせておけば、決裁権限規程とシステム設定の対応関係が、そのまま説明できるようになります。

監査で「この承認は規程のどの役割か」と問われたとき、経路の中の個人名を規程と突き合わせて説明するのと、規程と同じ名前のチームを見せるのとでは、準備にかかる時間がまるで違います。

担当の引き継ぎも変わります。システム設定の変更ではなく、チーム所属の変更という人事寄りの作業になるからです。

設計するときの注意点は3つ。

粒度：チームは役割の単位で作り、部門の写しにしないこと。部門をそのまま複製すると、組織改編のたびにチームの改編も必要になり、本末転倒です。

命名：規程・業務設計書で使われている役割の言葉に合わせること。規程が「安全管理責任者」なら、チーム名もその言葉に寄せます。

所管：チームのメンバーを最新に保つ責任者を決めておくこと。役割チームは自動では更新されないため、メンテナンスの主体が曖昧だと、今度はチームの中身が古くなっていきます。

正直に言うと、役割チームにすれば何もかも割り切れる、とまでは言えません。

担当者が1人しかいない役割は、チームを作っても中身は実質1人。個人指定と大差ないように見えます。

以前は、そこまで無理にチームにしなくてもいいのでは、と考えていました。考えが変わったのは、担当者の退職にともなう引き継ぎで、その人の名前が入った経路を1本ずつ探して差し替えている場に居合わせてからです。1人でも規程の役割名でチームを立てておけば、探す作業そのものがなくなるんですよね。

とはいえ、チームの数が増えれば所属の管理も増えます。どこまで徹底するかは会社の規模によって分かれるところで、私も相談の場ですぐに答えを出せないことがあります。

役割チームに割り当てるとき、あわせて決めること

チームに割り当てると、経路の設定は「誰が」から解放されます。

代わりに、チームの中でどう成立させるかという問いが出てきます。決めないまま運用を始めると、承認が止まった理由が誰にも分からない状態になりがちです。

1つ目は、承認の成立条件。

チームの誰か1人が承認すれば次へ進むのか、全員の承認が必要なのか。

押印管理のように手の空いている人が処理すればよい役割は前者、複数部門の合議に近い役割は後者です。紙で回していたころは、回ってきた人が押せば進むという運用が自然に成立していました。システムでは、明示的に決めておく必要があります。

2つ目は、不在時の扱い。

チームの全員が休みの日に申請が来たら、どう進めるか。

誰か1人の承認で進む設定なら、人数の確保が答えになります。全員承認の設定なら、代理承認を用意するか、一定日数で上位者へ引き上げる運用にするかを決めておくことになります。

3つ目は、チーム所属を変更する手続き。

経路を触らずに担当を替えられるということは、チームの所属を変えるだけで決裁の担い手が変わるということでもあります。

だからこそ、所属変更そのものを申請・承認の対象にしておくと、統制の面で説明がしやすくなります。誰がいつチームに入り、いつ抜けたかの記録が、承認記録と同じ場所に残るからです。

4つ目は、監査で見せる単位。

監査対応で問われるのは、決裁の時点で誰がその役割を担っていたかです。

現在の所属だけでなく、過去のある時点の所属を再現できるか。製品によって扱いが違う部分なので、設計の段階で確認しておくと後の対応が楽になります。

それでも個人指定を残してよい場合

すべてを役割で表現できるわけではありません。個人指定のまま残してよい例外は、私が見てきた範囲では3つに整理できます。

共通するのは、「その人だから」ではなく「その人に固有の根拠があるから」個人指定になっている点。

根拠を書けない個人指定は、たいてい過去の例外対応がそのまま残っているだけです。異動シーズンの前に見直す対象として、台帳に載せておきます。

自社の経路を仕分ける判断フロー

既存の経路を棚卸しするときの手順です。承認ステップを1つずつ、次の順番で確かめていきます。

まず、根拠を確かめる

1. このステップは、決裁権限規程・業務規程のどの役割に対応しているか。対応する役割が見つからないなら、割り当て方式を考える前に、ステップ自体の要否を業務所管部門と確認する
2. 規程上の役割の言葉（所属長、契約審査担当など）を、そのステップの本来の担い手としてメモする

次に、割り当て方式を決める

1. その役割は、申請者の所属ラインの上長か。Yesなら役職・組織参照に寄せる
2. 上長でないなら、部門をまたいで特定の機能を担う役割か。Yesなら役割チームを作り、チームに割り当てる。あわせて、承認の成立条件・不在時の扱い・所属変更の手続きを決める
3. 個人に固有の根拠（資格、委任、機密）があるか。あるときだけ個人指定を残し、根拠と本人の名前を台帳に記録する

最後に、着手の順番を決める

1. 個人名が入っている経路を、申請件数の多い順に並べる。件数の多い経路ほど、修正の漏れが業務の停滞に直結する
2. 上位から順に、3の役職参照・4の役割チームへ置き換える。1回の異動シーズンで全部を終わらせようとしない

この手順を通すと、経路の大半は役職参照か役割チームに収まり、個人指定は根拠を説明できる少数の例外だけになります。

異動シーズンに触るのは、その例外と、役割チームの所属。触る対象の数が変わります。

次の異動シーズンまでにやっておくこと

経路メンテナンスの重さは、運用の丁寧さではなく、設計時の割り当て単位で決まります。

人に割り当てた経路は人と一緒に動きますが、役割に割り当てた経路は、人が入れ替わっても組織が変わっても残ります。規程が役割の言葉で書かれているのだから、システムの経路も役割の言葉で組んでおく。

言葉にすればそれだけのことなのに、日々の例外対応の中では、なかなか立ち返れない原則でもあります。

まずは、個人名が入っている経路の一覧を出すところから始めてみてください。

その一覧を今回の判断フローにかけて、役職・組織参照に寄せるもの、役割チームに移すもの、根拠つきで個人指定のまま残すものに仕分けていきます。

全部を一度に終わらせる必要はありません。申請件数の多い経路から順に手を付けるだけでも、来期の経路修正は今期よりずっと短い仕事になります。