[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-related-pool":3,"blog-detail-zdr5kdsdp":112},{"contents":4,"totalCount":108,"limit":109,"offset":110,"category":111},[5,16,24,32,40,48,57,65,73,84,92,100],{"id":6,"slug":6,"title":7,"categories":8,"image":10,"publishedAt":14,"order":15},"form_field_placement","申請フォームの項目が52個。どこまで画面に載せるか",[9],"ワークフロー情報",{"url":11,"width":12,"height":13},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F72cccde74ada405581943d99fbcfb389\u002Feyecatch-form-field-placement-20260821.svg",1472,832,"2026-08-31T03:00:08.597Z",32,{"id":17,"slug":17,"title":18,"categories":19,"image":20,"publishedAt":22,"order":23},"workflow_migration_forms","ワークフロー移行の様式一覧。その行数は業務の数ではない",[9],{"url":21,"width":12,"height":13},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F5453b8af60f34db3bae2a831165858d2\u002Feyecatch-migration-forms-20260822.svg","2026-08-28T03:00:08.796Z",31,{"id":25,"slug":25,"title":26,"categories":27,"image":28,"publishedAt":30,"order":31},"workflow_user_count","ワークフローシステムの利用人数は、4つの層に分けて数える",[9],{"url":29,"width":12,"height":13},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002Ffa59e9e9fb06403ab768aa71b98c4b1c\u002Feyecatch-workflow-user-count-20260817.svg","2026-08-25T03:00:07.825Z",30,{"id":33,"slug":33,"title":34,"categories":35,"image":36,"publishedAt":38,"order":39},"purchase_workflow_split","購買ワークフローをどこで区切るか。稟議・発注・検収・支払",[9],{"url":37,"width":12,"height":13},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F3c4bbdb6cdd24b17adf74aeb8b59d6fb\u002Feyecatch-purchase-workflow-split-20260819.svg","2026-08-24T08:33:41.719Z",29,{"id":41,"slug":41,"title":42,"categories":43,"image":44,"publishedAt":46,"order":47},"1zvg65piyg1o","ワークフローシステムを選ぶ前に押さえておきたいポイント。比較表の○が揃ってしまう4つの領域",[9],{"url":45,"width":12,"height":13},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F9d15c99ff977492cbb1d90924a827bf8\u002Feyecatch-erabu-mae-20260815.svg","2026-08-21T05:04:24.116Z",28,{"id":49,"slug":49,"title":50,"categories":51,"image":53,"publishedAt":55,"order":56},"0u3jqdwhrgu5","稟議の差し戻しが減らないのは、承認する側の判断基準が申請画面に載っていないから",[52],"業務効率化",{"url":54,"width":12,"height":13},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F8745469660744c84b74ceccedda1506e\u002F%E3%82%A2%E3%82%A4%E3%82%AD%E3%83%A3%E3%83%83%E3%83%81_%E7%A8%9F%E8%AD%B0%E3%81%AE%E5%B7%AE%E3%81%97%E6%88%BB%E3%81%97%E3%81%8C%E6%B8%9B%E3%82%89%E3%81%AA%E3%81%84%E3%81%AE%E3%81%AF_v3_20260813.svg","2026-08-20T05:52:42.029Z",27,{"id":58,"slug":58,"title":59,"categories":60,"image":61,"publishedAt":63,"order":64},"d9qydi-huy","申請者が承認者を毎回選ぶ運用を、いつまで続けられるか",[9],{"url":62,"width":12,"height":13},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F2187bb39420b4e1fbf28c32c75a6a706\u002Feyecatch-approver-selection-20260814.svg","2026-08-19T06:13:13.637Z",26,{"id":66,"slug":66,"title":67,"categories":68,"image":69,"publishedAt":71,"order":72},"3358728uqfu3","ワークフローのトライアルは、何を確かめる30日か。検証を3層に分けて設計する",[9],{"url":70,"width":12,"height":13},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F2b008dbc543f4e519b897fe9f68ebb89\u002Feyecatch-trial-30days-20260814.svg","2026-08-18T10:45:01.972Z",25,{"id":74,"slug":74,"title":75,"categories":76,"image":78,"publishedAt":82,"order":83},"u-_k2jynls92","【セミナーレポート】決算が締まらなかった会社は、ワークフローをどう建て直したか（出前館 志賀綾子氏・足立隆裕氏）",[77],"ガバナンス",{"url":79,"width":80,"height":81},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F3f07e07a9d734a6cae069a55a0c8fb4a\u002F%E6%B1%BA%E7%AE%97%E3%81%8B%E3%82%99%E7%B7%A0%E3%81%BE%E3%82%89%E3%81%AA%E3%81%8B%E3%81%A3%E3%81%9F%E4%BC%9A%E7%A4%BE%E3%81%AF%E3%80%81%E3%83%AF%E3%83%BC%E3%82%AF%E3%83%95%E3%83%AD%E3%83%BC%E3%82%92%E3%81%A8%E3%82%99%E3%81%86%E5%BB%BA%E3%81%A6%E7%9B%B4%E3%81%97%E3%81%9F%E3%81%8B.webp",1280,670,"2026-08-17T01:00:06.830Z",24,{"id":85,"slug":85,"title":86,"categories":87,"image":89,"publishedAt":90,"order":91},"f0jy89g2jlp","依頼系の申請は一覧を見ても誰の件か分からない。原因と一覧から逆算するフォーム設計",[88],"働き方・組織",null,"2026-08-14T01:00:07.094Z",23,{"id":93,"slug":93,"title":94,"categories":95,"image":96,"publishedAt":98,"order":99},"zdr5kdsdp","承認経路のメンテが終わらない理由",[88],{"url":97,"width":12,"height":13},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F941338f1bdb84c45b5f08dfe4f1ca593\u002F%E3%82%A2%E3%82%A4%E3%82%AD%E3%83%A3%E3%83%83%E3%83%81_%E6%89%BF%E8%AA%8D%E7%B5%8C%E8%B7%AF%E3%81%AE%E3%83%A1%E3%83%B3%E3%83%86%E3%81%8B%E3%82%99%E7%B5%82%E3%82%8F%E3%82%89%E3%81%AA%E3%81%84%E7%90%86%E7%94%B1.png","2026-08-13T01:00:07.386Z",22,{"id":101,"slug":101,"title":102,"categories":103,"image":104,"publishedAt":106,"order":107},"qbwzwoaayu","新システムへの切り替えは「一斉リリース」か「段階リリース」どちらが良いのか",[9],{"url":105,"width":12,"height":13},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002Faec08d0f80d14f0aa49635a5184bd2a6\u002F%E3%82%A2%E3%82%A4%E3%82%AD%E3%83%A3%E3%83%83%E3%83%81_%E6%96%B0%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%B8%E3%81%AE%E5%88%87%E3%82%8A%E6%9B%BF%E3%81%88%E3%81%AF%E3%80%8C%E4%B8%80%E6%96%89%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%80%8D%E3%81%8B%E3%80%8C%E6%AE%B5%E9%9A%8E%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%80%8D%E3%81%A8%E3%82%99%E3%81%A1%E3%82%89%E3%81%8B%E3%82%99%E8%89%AF%E3%81%84%E3%81%AE%E3%81%8B.png","2026-08-12T01:30:06.254Z",21,33,12,0,"",{"id":93,"slug":93,"title":94,"categories":113,"image":114,"publishedAt":98,"order":99,"body":115,"toc":116,"excerpt":145,"readingMinutes":146,"revisedAt":98},[88],{"url":97,"width":12,"height":13},"\u003Cp>人事異動の内示が出ると、情シスの手元には経路修正のリストが積み上がっていきます。\u003C\u002Fp>\u003Cp>承認経路に入っている担当者の名前を一つずつ確かめて、抜ける人を外し、後任を入れる。この作業のために、発令日までの数日は他の仕事を止めて張り付くことになります。\u003C\u002Fp>\u003Cp>期が変わるたびに、メンテ地獄がやってきます。ワークフローの運用と切り離せない業務として、半ば当たり前になっていないでしょうか。\u003C\u002Fp>\u003Cp>経路の一覧を書き出して氏名で検索をかけ、ヒットしたものを1本ずつ開いて直していく。そこまでやっても1本だけ抜けていて、発令日の翌朝に「承認者が退職者のままです」と連絡をもらってしまう。そんな経験、ありませんか。\u003C\u002Fp>\u003Cp>なぜその経路にその人が入っているのかを説明できる人が、もう社内に残っていない。だから、とりあえず後任に置き換えておく。これもよくある話だと思います。\u003C\u002Fp>\u003Cp>しかもこの作業、ワークフローシステムを長く運用している会社ほど重くなっていきます。経路の本数が増えて、例外の分岐も増えていくからです。\u003C\u002Fp>\u003Ch2 id=\"hc233a3ce06\">相談の場でも、毎回この話になります\u003C\u002Fh2>\u003Cp>kickflowでフィールドセールスを担当している西尾です。承認経路の設計や見直しのご相談に立ち会っていると、経路修正の負荷は必ずと言っていいほど話題に上がります。\u003C\u002Fp>\u003Cp>正直に言うと、私も一度ここでつまずいています。「異動のたびの経路修正を減らしたい」とご相談をいただいたときに、直し方の工夫や運用ルールの話ばかりを並べてしまって、肝心の「なぜ毎回直さなければならないのか」にはうまく答えられませんでした。\u003C\u002Fp>\u003Cp>そのとき引っかかったまま残っていた論点を、あらためて整理したのがこの記事です。\u003C\u002Fp>\u003Cp>経路修正の重さは、担当者の手際でも、ツールの性能でも決まりません。\u003C\u002Fp>\u003Cp>決まるのは、もっと手前の設計です。承認ステップを「誰に」割り当てたか。人に割り当てた経路は人が動くたびに修正が要り、役割に割り当てた経路は人が動いても残ります。\u003C\u002Fp>\u003Cp>そこで本稿では、承認ステップの割り当て方式を3つに整理します。\u003C\u002Fp>\u003Cp>そのうえで、多くの会社がすでに使いこなしている役職参照でもなお個人名が残ってしまう領域を特定し、その領域を引き受けるチームの設計、チームに割り当てるときにあわせて決めておくこと、自社の経路を仕分ける判断フローまでをお話しします。\u003C\u002Fp>\u003Cp>読み終わるころには、次の異動シーズンに向けて、どの経路から手を付け、どこまでを個人指定のまま残してよいのかが、順番のついた手順として見えているはずです。\u003C\u002Fp>\u003Ch2 id=\"h4c4fea64e3\">経路修正が人事イベントに連動してしまう構造\u003C\u002Fh2>\u003Cp>そもそも、決裁権限規程やワークフローの業務設計書に、個人名は登場しません。\u003C\u002Fp>\u003Cp>「所属長が承認する」「経理部長が決裁する」「安全管理責任者が確認する」。規程は、役割の言葉だけで書かれています。\u003C\u002Fp>\u003Cp>ところが、システム上の経路には、いつのまにか個人名が入り込みます。導入時は役職ベースで組んだはずなのに、運用が始まると例外が生まれるからです。\u003C\u002Fp>\u003Cp>「この申請だけは、課長ではなく実務に詳しいあの人に見てほしい」\u003C\u002Fp>\u003Cp>こうした要望の一つひとつは、合理的な判断です。\u003C\u002Fp>\u003Cp>審査の担当者は決まっているのに、その人の役職が係長で、役職名では特定できないというケースもあります。妥当な判断の積み重ねが、経路の中の個人名を増やしていくわけです。\u003C\u002Fp>\u003Cp>経路に人を直接置いた瞬間から、その人に起きる変化はすべて設定変更になります。\u003C\u002Fp>\u003Cp>異動、退職、休職、昇格、産育休。人事の出来事が、そのままシステムの作業に変換される構造です。\u003C\u002Fp>\u003Cp>経路修正が終わらないのは、変換が起き続けているからにほかなりません。\u003C\u002Fp>\u003Cfigure>\u003Cimg src=\"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F4797bcc94dd342118c74dbc90fc61a3a\u002F%E5%9B%B31_%E5%89%B2%E3%82%8A%E5%BD%93%E3%81%A6%E6%96%B9%E5%BC%8F%E3%81%AF3%E3%81%A4_20260813.png?w=1200&fm=webp&q=80\" alt=\"\" width=\"2400\" height=\"1204\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\u003Ch2 id=\"h68f1ea8faa\">承認ステップの割り当ては、3つの方式に整理できる\u003C\u002Fh2>\u003Cp>承認ステップに「誰がやるか」を持たせる方法は、突き詰めると3つです。3つ目の役割チームは、組織規程には載っていない、役割の単位で作るチームを指します（本稿では役割チームと呼びます）。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth>\u003Cp>方式\u003C\u002Fp>\u003C\u002Fth>\u003Cth>\u003Cp>誰が処理するかの決まり方\u003C\u002Fp>\u003C\u002Fth>\u003Cth>\u003Cp>向いている承認\u003C\u002Fp>\u003C\u002Fth>\u003Cth>\u003Cp>人が動いたときに触る場所\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>個人指定\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>経路に置いた本人\u003Cbr \u002F>例：契約審査は法務の担当者本人を経路に直接指定\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>個人に固有の根拠がある承認\u003Cbr \u002F>例：有資格者しか行えない安全確認\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>その人が入っているすべての経路\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>役職・組織参照\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>申請者の所属をたどって解決\u003Cbr \u002F>例：申請者が所属する課の課長\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>申請者の上長による承認\u003Cbr \u002F>例：所属長承認、部長決裁\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>人事マスタ・組織図（経路は無修正）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>役割チーム\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>チームに所属している人\u003Cbr \u002F>例：押印管理チームに所属する担当者\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>部門をまたいで特定の機能を担う承認\u003Cbr \u002F>例：押印管理、契約審査、安全審査\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>チームの所属メンバー（経路は無修正）\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>\u003Cstrong>個人指定\u003C\u002Fstrong>は、誰が処理するかが明確で、設定も直感的です。その代わり、人の変化がすべて設定変更になります。\u003C\u002Fp>\u003Cp>\u003Cstrong>役職・組織参照\u003C\u002Fstrong>は、申請者の所属組織をたどって「その部の部長」を動的に解決する方法。人事マスタや組織図が正しく保たれていれば、異動には自動で追従します。\u003C\u002Fp>\u003Cp>\u003Cstrong>役割チーム\u003C\u002Fstrong>は、組織図上のチームに承認ステップを割り当て、そのチームに所属している人が処理する方法です。誰がやるかは、経路ではなくチームの所属で管理します。\u003C\u002Fp>\u003Cp>多くの会社は、役職・組織参照までは使いこなしています。むしろ、導入時に真っ先に設計するのがこの部分。\u003C\u002Fp>\u003Cp>それでも経路修正がなくならないとすれば、残っているのは役職・組織参照でカバーできない領域のはずです。\u003C\u002Fp>\u003Ch2 id=\"hdf28f4d396\">役職参照だけでは、なぜ個人名が残るのか\u003C\u002Fh2>\u003Cp>役職・組織参照が解決するのは、申請者から見た縦の関係です。\u003C\u002Fp>\u003Cp>所属課の課長、所属部の部長、その上の本部長。組織図の階層を上にたどって行き着く承認は、この方式で自動化できます。\u003C\u002Fp>\u003Cp>でも、規程に書かれた役割の中には、組織図の階層をたどっても行き着けないものがあるんです。\u003C\u002Fp>\u003Cp>押印の管理担当。契約書の法務審査。内部統制上のチェック。安全審査。情報システムの利用承認。\u003C\u002Fp>\u003Cp>どれも申請者の上司ではありません。部門をまたいで特定の機能を担う人たちであり、申請者の所属をたどっても解決できない相手です。\u003C\u002Fp>\u003Cp>しかも、役割を担う人の役職はまちまち。係長のこともあれば、役職のない専任担当のこともあります。役職名を手がかりにしても、特定にはたどり着けません。\u003C\u002Fp>\u003Cp>行き先を失ったステップが、個人指定で実装されます。\u003C\u002Fp>\u003Cp>異動シーズンに最後まで残る修正対象は、たいていこの部分です。ツールの機能が足りないのではなく、縦のライン向けの仕組みで部門横断の役割を表現しようとしているところに、無理があるだけなんです。\u003C\u002Fp>\u003Cfigure>\u003Cimg src=\"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F040762dbe69d42c69bb9f64cd0877598\u002F%E5%9B%B32_%E3%81%9F%E3%81%A8%E3%82%99%E3%82%8C%E3%82%8B%E6%89%BF%E8%AA%8D%E3%83%BB%E3%81%9F%E3%81%A8%E3%82%99%E3%82%8C%E3%81%AA%E3%81%84%E6%89%BF%E8%AA%8D_20260813.png?w=1200&fm=webp&q=80\" alt=\"\" width=\"2400\" height=\"1224\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\u003Ch2 id=\"h364c69618a\">組織図に「役割チーム」を作る\u003C\u002Fh2>\u003Cp>部門横断の役割の割り当てには、役割チームを使います。公式の組織図には存在しないチームを、ワークフロー上の組織図にあえて作る方法です。\u003C\u002Fp>\u003Cp>押印管理チーム。契約審査チーム。安全審査チーム。\u003C\u002Fp>\u003Cp>会社の組織規程には載っていなくても、ワークフローの世界では正式な組織として定義してしまう。承認ステップはこのチームに割り当て、実際に処理する人はチームの所属メンバーとして登録します。\u003C\u002Fp>\u003Cp>設計をこの形に変えると、異動対応の中身が変わります。\u003C\u002Fp>\u003Cp>経路そのものは触らず、チームのメンバーを入れ替えるだけ。担当が3人から4人に増えても、経路は無修正です。\u003C\u002Fp>\u003Cp>設定変更の対象が、数十本の経路から、数個のチームの所属に絞られます。\u003C\u002Fp>\u003Cp>副次的な効果も小さくありません。\u003C\u002Fp>\u003Cp>チーム名を規程の役割名に合わせておけば、決裁権限規程とシステム設定の対応関係が、そのまま説明できるようになります。\u003C\u002Fp>\u003Cp>監査で「この承認は規程のどの役割か」と問われたとき、経路の中の個人名を規程と突き合わせて説明するのと、規程と同じ名前のチームを見せるのとでは、準備にかかる時間がまるで違います。\u003C\u002Fp>\u003Cp>担当の引き継ぎも変わります。システム設定の変更ではなく、チーム所属の変更という人事寄りの作業になるからです。\u003C\u002Fp>\u003Cp>設計するときの注意点は3つ。\u003C\u002Fp>\u003Cp>\u003Cstrong>粒度\u003C\u002Fstrong>：チームは役割の単位で作り、部門の写しにしないこと。部門をそのまま複製すると、組織改編のたびにチームの改編も必要になり、本末転倒です。\u003C\u002Fp>\u003Cp>\u003Cstrong>命名\u003C\u002Fstrong>：規程・業務設計書で使われている役割の言葉に合わせること。規程が「安全管理責任者」なら、チーム名もその言葉に寄せます。\u003C\u002Fp>\u003Cp>\u003Cstrong>所管\u003C\u002Fstrong>：チームのメンバーを最新に保つ責任者を決めておくこと。役割チームは自動では更新されないため、メンテナンスの主体が曖昧だと、今度はチームの中身が古くなっていきます。\u003C\u002Fp>\u003Cp>正直に言うと、役割チームにすれば何もかも割り切れる、とまでは言えません。\u003C\u002Fp>\u003Cp>担当者が1人しかいない役割は、チームを作っても中身は実質1人。個人指定と大差ないように見えます。\u003C\u002Fp>\u003Cp>以前は、そこまで無理にチームにしなくてもいいのでは、と考えていました。考えが変わったのは、担当者の退職にともなう引き継ぎで、その人の名前が入った経路を1本ずつ探して差し替えている場に居合わせてからです。1人でも規程の役割名でチームを立てておけば、探す作業そのものがなくなるんですよね。\u003C\u002Fp>\u003Cp>とはいえ、チームの数が増えれば所属の管理も増えます。どこまで徹底するかは会社の規模によって分かれるところで、私も相談の場ですぐに答えを出せないことがあります。\u003C\u002Fp>\u003Ch2 id=\"ha956d67caf\">役割チームに割り当てるとき、あわせて決めること\u003C\u002Fh2>\u003Cp>チームに割り当てると、経路の設定は「誰が」から解放されます。\u003C\u002Fp>\u003Cp>代わりに、チームの中でどう成立させるかという問いが出てきます。決めないまま運用を始めると、承認が止まった理由が誰にも分からない状態になりがちです。\u003C\u002Fp>\u003Cp>\u003Cstrong>1つ目は、承認の成立条件。\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>チームの誰か1人が承認すれば次へ進むのか、全員の承認が必要なのか。\u003C\u002Fp>\u003Cp>押印管理のように手の空いている人が処理すればよい役割は前者、複数部門の合議に近い役割は後者です。紙で回していたころは、回ってきた人が押せば進むという運用が自然に成立していました。システムでは、明示的に決めておく必要があります。\u003C\u002Fp>\u003Cp>\u003Cstrong>2つ目は、不在時の扱い。\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>チームの全員が休みの日に申請が来たら、どう進めるか。\u003C\u002Fp>\u003Cp>誰か1人の承認で進む設定なら、人数の確保が答えになります。全員承認の設定なら、代理承認を用意するか、一定日数で上位者へ引き上げる運用にするかを決めておくことになります。\u003C\u002Fp>\u003Cp>\u003Cstrong>3つ目は、チーム所属を変更する手続き。\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>経路を触らずに担当を替えられるということは、チームの所属を変えるだけで決裁の担い手が変わるということでもあります。\u003C\u002Fp>\u003Cp>だからこそ、所属変更そのものを申請・承認の対象にしておくと、統制の面で説明がしやすくなります。誰がいつチームに入り、いつ抜けたかの記録が、承認記録と同じ場所に残るからです。\u003C\u002Fp>\u003Cp>\u003Cstrong>4つ目は、監査で見せる単位。\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>監査対応で問われるのは、決裁の時点で誰がその役割を担っていたかです。\u003C\u002Fp>\u003Cp>現在の所属だけでなく、過去のある時点の所属を再現できるか。製品によって扱いが違う部分なので、設計の段階で確認しておくと後の対応が楽になります。\u003C\u002Fp>\u003Ch2 id=\"haafaecebf7\">それでも個人指定を残してよい場合\u003C\u002Fh2>\u003Cp>すべてを役割で表現できるわけではありません。個人指定のまま残してよい例外は、私が見てきた範囲では3つに整理できます。\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth>\u003Cp>例外の類型\u003C\u002Fp>\u003C\u002Fth>\u003Cth>\u003Cp>具体例\u003C\u002Fp>\u003C\u002Fth>\u003Cth>\u003Cp>台帳に書いておくこと\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>資格・免許が根拠\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>有資格者でなければ判断できない安全確認、特定の専門資格を要する審査\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>根拠となる資格名と、資格の有効期限\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>個人への委任が根拠\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>取締役会の決議で特定の個人に委任された決裁\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>委任の決議日と、委任された範囲\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>機密性が根拠\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>限られた個人だけが内容を見て決裁する必要がある申請\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>対象の申請と、閲覧を限る根拠となる規程\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>共通するのは、「その人だから」ではなく「その人に固有の根拠があるから」個人指定になっている点。\u003C\u002Fp>\u003Cp>根拠を書けない個人指定は、たいてい過去の例外対応がそのまま残っているだけです。異動シーズンの前に見直す対象として、台帳に載せておきます。\u003C\u002Fp>\u003Cfigure>\u003Cimg src=\"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F9dc58c184a2b43478291c33718e8de44\u002F%E5%9B%B33_%E4%BB%95%E5%88%86%E3%81%91%E3%81%AE%E5%88%A4%E6%96%AD%E3%83%95%E3%83%AD%E3%83%BC_20260813.png?w=1200&fm=webp&q=80\" alt=\"\" width=\"2400\" height=\"1242\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\u003Ch2 id=\"hddd354866b\">自社の経路を仕分ける判断フロー\u003C\u002Fh2>\u003Cp>既存の経路を棚卸しするときの手順です。承認ステップを1つずつ、次の順番で確かめていきます。\u003C\u002Fp>\u003Cp>\u003Cstrong>まず、根拠を確かめる\u003C\u002Fstrong>\u003C\u002Fp>\u003Col>\u003Cli>このステップは、決裁権限規程・業務規程のどの役割に対応しているか。対応する役割が見つからないなら、割り当て方式を考える前に、ステップ自体の要否を業務所管部門と確認する\u003C\u002Fli>\u003Cli>規程上の役割の言葉（所属長、契約審査担当など）を、そのステップの本来の担い手としてメモする\u003C\u002Fli>\u003C\u002Fol>\u003Cp>\u003Cstrong>次に、割り当て方式を決める\u003C\u002Fstrong>\u003C\u002Fp>\u003Col>\u003Cli>その役割は、申請者の所属ラインの上長か。Yesなら役職・組織参照に寄せる\u003C\u002Fli>\u003Cli>上長でないなら、部門をまたいで特定の機能を担う役割か。Yesなら役割チームを作り、チームに割り当てる。あわせて、承認の成立条件・不在時の扱い・所属変更の手続きを決める\u003C\u002Fli>\u003Cli>個人に固有の根拠（資格、委任、機密）があるか。あるときだけ個人指定を残し、根拠と本人の名前を台帳に記録する\u003C\u002Fli>\u003C\u002Fol>\u003Cp>\u003Cstrong>最後に、着手の順番を決める\u003C\u002Fstrong>\u003C\u002Fp>\u003Col>\u003Cli>個人名が入っている経路を、申請件数の多い順に並べる。件数の多い経路ほど、修正の漏れが業務の停滞に直結する\u003C\u002Fli>\u003Cli>上位から順に、3の役職参照・4の役割チームへ置き換える。1回の異動シーズンで全部を終わらせようとしない\u003C\u002Fli>\u003C\u002Fol>\u003Cp>この手順を通すと、経路の大半は役職参照か役割チームに収まり、個人指定は根拠を説明できる少数の例外だけになります。\u003C\u002Fp>\u003Cp>異動シーズンに触るのは、その例外と、役割チームの所属。触る対象の数が変わります。\u003C\u002Fp>\u003Ch2 id=\"h047f08edc0\">次の異動シーズンまでにやっておくこと\u003C\u002Fh2>\u003Cp>経路メンテナンスの重さは、運用の丁寧さではなく、設計時の割り当て単位で決まります。\u003C\u002Fp>\u003Cp>人に割り当てた経路は人と一緒に動きますが、役割に割り当てた経路は、人が入れ替わっても組織が変わっても残ります。規程が役割の言葉で書かれているのだから、システムの経路も役割の言葉で組んでおく。\u003C\u002Fp>\u003Cp>言葉にすればそれだけのことなのに、日々の例外対応の中では、なかなか立ち返れない原則でもあります。\u003C\u002Fp>\u003Cp>まずは、個人名が入っている経路の一覧を出すところから始めてみてください。\u003C\u002Fp>\u003Cp>その一覧を今回の判断フローにかけて、役職・組織参照に寄せるもの、役割チームに移すもの、根拠つきで個人指定のまま残すものに仕分けていきます。\u003C\u002Fp>\u003Cp>全部を一度に終わらせる必要はありません。申請件数の多い経路から順に手を付けるだけでも、来期の経路修正は今期よりずっと短い仕事になります。\u003C\u002Fp>",[117,121,124,127,130,133,136,139,142],{"id":118,"text":119,"level":120},"hc233a3ce06","相談の場でも、毎回この話になります",2,{"id":122,"text":123,"level":120},"h4c4fea64e3","経路修正が人事イベントに連動してしまう構造",{"id":125,"text":126,"level":120},"h68f1ea8faa","承認ステップの割り当ては、3つの方式に整理できる",{"id":128,"text":129,"level":120},"hdf28f4d396","役職参照だけでは、なぜ個人名が残るのか",{"id":131,"text":132,"level":120},"h364c69618a","組織図に「役割チーム」を作る",{"id":134,"text":135,"level":120},"ha956d67caf","役割チームに割り当てるとき、あわせて決めること",{"id":137,"text":138,"level":120},"haafaecebf7","それでも個人指定を残してよい場合",{"id":140,"text":141,"level":120},"hddd354866b","自社の経路を仕分ける判断フロー",{"id":143,"text":144,"level":120},"h047f08edc0","次の異動シーズンまでにやっておくこと","人事異動の内示が出ると、情シスの手元には経路修正のリストが積み上がっていきます。承認経路に入っている担当者の名前を一つずつ確かめて、抜ける人を外し、後任を入れる。この作業のために、発令日までの数日は他の仕事を止めて張り付くことになります。期…",14]