[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-detail-d9qydi-huy":3,"blog-related-pool":54},{"id":4,"slug":4,"title":5,"categories":6,"image":8,"publishedAt":12,"order":13,"body":14,"toc":15,"excerpt":51,"readingMinutes":52,"revisedAt":53},"d9qydi-huy","申請者が承認者を毎回選ぶ運用を、いつまで続けられるか",[7],"ワークフロー情報",{"url":9,"width":10,"height":11},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F2187bb39420b4e1fbf28c32c75a6a706\u002Feyecatch-approver-selection-20260814.svg",1472,832,"2026-08-19T06:13:13.637Z",26,"\u003Cp>「承認者はどなたに回せばいいですか」\u003C\u002Fp>\u003Cp>申請を上げる直前に、こういう確認が飛んできます。\u003C\u002Fp>\u003Cp>聞かれた側もすぐには答えられません。似た申請が前にもあったはずだと履歴をたどって、そのときの承認者を探すことになります。\u003C\u002Fp>\u003Cp>組織図がシステムに入っていれば、この確認は要らないのに。。。\u003C\u002Fp>\u003Cp>グループウェアに付いている申請機能で全社の稟議を回している会社では、承認者の欄が空欄から始まることが少なくありません。誰に回すかを決めるのは、申請を上げる本人です。\u003C\u002Fp>\u003Cp>運用が緩いからこうなっているわけではありません。多くのグループウェアには、組織階層や役職から承認者を自動的に導く仕組み自体は用意されています。\u003C\u002Fp>\u003Cp>ただ、その仕組みが前提にしているのは、1人が1つの部署・1つの役職にきれいに収まる組織です。兼務が多い、指揮系統に例外がある、といった実際の組織はこの前提からはみ出しやすく、はみ出した分は結局、申請者が選ぶ形に戻ってきます。承認者を決める仕事が申請者の側に残るのは、組織情報が存在しないからではなく、整備し続けられていないからです。\u003C\u002Fp>\u003Cp>この形は、実際のところかなり長く持ちます。持ちこたえられる範囲を3つの問いに分けて整理します。自社がいまどのあたりにいるかを測る目安になれば十分です。\u003C\u002Fp>\u003Ch2 id=\"hffb30a1352\">承認者を選ぶ仕事は申請者に残っている\u003C\u002Fh2>\u003Cp>例えば、営業部から上がってきた展示会の出展費用の稟議。金額は180万円で、部長の決裁では収まらず営業本部長まで上がるものだとします。\u003C\u002Fp>\u003Cp>申請者は、まず部長の名前を選びます。次に本部長。ここまでは迷いません。\u003C\u002Fp>\u003Cp>迷うのはそのあとです。180万円の出展費用に、経理の事前確認は必要なのか。会場の設営で外部の制作会社が入るなら、法務も通しておくべきか。\u003C\u002Fp>\u003Cp>決裁権限基準表を開けば、金額と決裁者の対応は書いてあります。ただ、決裁に至る途中で誰を挟むかまで書いている会社は、そう多くありません。\u003C\u002Fp>\u003Cp>だから申請者は、隣の席の人に聞きます。あるいは、前に似た申請を出した人の履歴を探します。\u003C\u002Fp>\u003Cp>\u003Cstrong>この確認は、ワークフローの外側で行われます。\u003C\u002Fstrong>誰に聞いたのか、なぜその人を選んだのかは、申請の記録には残りません。残るのは、選ばれた結果だけです。\u003C\u002Fp>\u003Ch2 id=\"h0d804d8db5\">グループウェアの組織図は、整った組織までしか届かない\u003C\u002Fh2>\u003Cp>なぜ承認者を自動で決められないのか。組織の情報が入っていないからでも、組織の情報が経路計算に使えない性質だからでもありません。仕組みとしては使えるのに、自社の組織構造に合わせて整備し続ける手間のほうが先に切れてしまうからだと考えています。\u003C\u002Fp>\u003Cfigure>\u003Cimg src=\"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F8a753c9e5fb846af89297da0e488b4df\u002Ffig1-two-org-data-20260814.svg\" alt=\"表示のための組織情報と、経路を計算するための組織情報の違いを対比した図\" width=\"1200\" height=\"490\" \u002F>\u003C\u002Ffigure>\u003Cp>人が読むだけの組織図なら、1人が1つの部署に属していれば十分です。兼務は備考欄に書いておけば運用できますし、更新も人事の発令が出てから追いかければよく、数日の遅れは実務では問題になりません。\u003C\u002Fp>\u003Cp>経路を計算するための組織情報は、そうはいきません。部署の上下関係、役職の序列、兼務のどちらが主でどちらが従か、変更が効き始める日付。このどれかが空いていると、承認者が決まらないか、意図しない人が決まります。\u003C\u002Fp>\u003Cp>多くのグループウェアは、後者の水準にもある程度対応できるように作られています。役職をロールとして登録し、組織階層をたどって承認者を自動的に導く仕組みも珍しくありません。問題は、その仕組みが「1人1部署・1役職」に近い、比較的整った組織を前提にしていることです。兼務や例外的な指揮系統が増えるほど、ロールや階層をその実態に合わせて設定し続ける作業が追いつかなくなります。\u003C\u002Fp>\u003Cp>だから、複雑な組織ほど、承認者を人が選ぶ形に戻ってきます。整備が追いつかなくなった先に、いちばん柔軟に対応できる方法として、申請者の判断が残るという順番です。\u003C\u002Fp>\u003Ch2 id=\"h38060edc2e\">経路を作り込めば済むわけではない\u003C\u002Fh2>\u003Cp>この状態への対処として、まず思い浮かぶのは経路を固定してしまうことでしょう。申請書ごとに承認者をあらかじめ設定しておけば、申請者は選ばなくて済みます。\u003C\u002Fp>\u003Cp>ただ、固定する対象を氏名にすると、異動のたびに直す作業が生まれます。役職や部署で指定できるなら話は変わりますが、それは組織情報が経路計算に耐える形で入っていることが前提です。\u003C\u002Fp>\u003Cp>もうひとつの道は、組織情報を手で整え続けることです。こちらは動きます。動くのですが、更新の起点が人事の発令にあるかぎり、発令のタイミングと申請の発生タイミングは揃いません。\u003C\u002Fp>\u003Cp>そして、どちらの対処でも残るものがあります。\u003C\u002Fp>\u003Cp>\u003Cstrong>申請者が選んだ承認者が正しかったのかを、あとから確かめる手段がないという点です。\u003C\u002Fstrong>記録に残るのは「この人が承認した」までで、「この人が承認すべきだった」は残りません。\u003C\u002Fp>\u003Ch2 id=\"he642004c76\">3つの問いでいまの運用がどこまで持つかを見る\u003C\u002Fh2>\u003Cfigure>\u003Cimg src=\"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F41e1d7cb29a64cfd972734a7bc221018\u002Ffig2-three-questions-20260814.svg\" alt=\"3つの問いと、引っかかったときに引き受けることになるものを並べた表\" width=\"1200\" height=\"530\" \u002F>\u003C\u002Ffigure>\u003Ch3 id=\"hd28bcea82f\">問1 その承認者はどこかに書いてあるか\u003C\u002Fh3>\u003Cp>決裁者が基準表に書いてあるかを聞いているのではありません。決裁に至る途中で挟む承認者、たとえば経理の事前確認や法務の審査を、どの文書が定めているかという話です。\u003C\u002Fp>\u003Cp>文書に書いてあるなら、申請者がしている選択は文書の転記に近い作業です。手間はかかりますが、判断そのものは属人的ではありません。\u003C\u002Fp>\u003Cp>書いていない場合、選ぶ基準は誰かの記憶の中にあります。180万円の出展費用に経理を挟むかどうかを、社内の誰も文書で示せない状態です。\u003C\u002Fp>\u003Ch3 id=\"had0294c953\">問2 違う人が承認しても止まらない\u003C\u002Fh3>\u003Cp>承認者の選び方を間違えると、差し戻しになることがあります。この形で表に出るぶんは、まだ扱いやすい間違いです。\u003C\u002Fp>\u003Cp>扱いにくいのは、間違ったまま通ったときです。何も起きません。申請は決裁され、記録も残り、業務は進みます。\u003C\u002Fp>\u003Cp>気づくのは、監査や内部統制の対応で決裁の妥当性を確かめる場面になってからです。\u003Cstrong>そのとき記録を見ても、承認者の選択が正しかったかどうかは判断できません。\u003C\u002Fstrong>\u003C\u002Fp>\u003Ch3 id=\"h116036d833\">問3 選び方を知っている人が抜けたとき\u003C\u002Fh3>\u003Cp>承認者の選び方は、たいてい部門の中で口伝で受け継がれます。手順書があるというより、「この種の申請はこの人にも回しておく」という感覚として共有されています。\u003C\u002Fp>\u003Cp>異動と退職でこの継承が切れると、申請者は「前と同じ人」を選ぶようになります。前がなぜその人だったのかは分からないまま。\u003C\u002Fp>\u003Cp>このとき経路は形式的には動いています。止まらないので、切れたことに気づく機会がありません。\u003C\u002Fp>\u003Ch3 id=\"h3103eb3a9f\">3つを1人の申請者に戻す\u003C\u002Fh3>\u003Cp>例の出展費用の稟議を出す人の頭の中では、3つの問いが1続きになっています。\u003C\u002Fp>\u003Cp>基準表を開いても経理を挟むかは書いていない。隣の人に聞いたら「たしか去年は入れてたと思う」と返ってくる。去年の担当者はもういない。とりあえず入れておけば怒られはしないだろうから、入れて出す。\u003C\u002Fp>\u003Cp>この判断がおかしいわけではありません。むしろ、この状況で取りうる中でいちばん妥当な判断です。ただ、なぜ経理を入れたのかという理由は、誰の手元にも残りません。\u003C\u002Fp>\u003Ch2 id=\"hf245469f54\">以前は替えなくてもいいと考えていました\u003C\u002Fh2>\u003Cp>正直に言うと、いまの運用で回っているなら無理に組織連動へ寄せなくてもいいのでは、と以前は考えていました。承認者を選ぶ手間は数十秒ですし、間違えれば差し戻せば済むと思っていたからです。\u003C\u002Fp>\u003Cp>考えが変わったのは、監査の指摘を受けて過去の決裁を洗い直している場に居合わせてからです。\u003C\u002Fp>\u003Cp>そこで困っていたのは、承認の手間ではありませんでした。1件ずつ、そのとき誰が承認すべきだったのかを人の記憶で再構成していく作業に、担当の方が何日も費やしていた。\u003C\u002Fp>\u003Cp>手間は運用の話なので、あとからでも減らせます。記録は、あとから作り直せません。\u003C\u002Fp>\u003Ch2 id=\"hf75771ab5e\">社内に聞くこととベンダーに聞くこと\u003C\u002Fh2>\u003Cp>3つの問いのどれかに引っかかったとして、次に何を確かめるか。聞く相手で分けると整理しやすいと思っています。\u003C\u002Fp>\u003Cp>社内に聞くこと：\u003C\u002Fp>\u003Cul>\u003Cli>決裁に至る途中で挟む承認者の基準は、どの文書に書かれているか。書かれていないなら、誰の頭の中にあるか\u003C\u002Fli>\u003Cli>決裁権限基準表は、どの部署が改定を起案し、どの頻度で見直しているか\u003C\u002Fli>\u003Cli>兼務者が承認する場合、どちらの立場での承認かを区別する必要があるか\u003C\u002Fli>\u003Cli>監査で決裁の妥当性を問われたとき、いま何を証跡として出しているか\u003C\u002Fli>\u003Cli>異動や組織変更の情報を、社内でどのシステムが最初に受け取っているか\u003C\u002Fli>\u003C\u002Ful>\u003Cp>ベンダーに聞くこと：\u003C\u002Fp>\u003Cul>\u003Cli>組織情報をどの粒度で取り込めるか（部署の新設と統合、兼務、役職の序列）\u003C\u002Fli>\u003Cli>発令日を指定して、未来の組織変更を先に登録できるか\u003C\u002Fli>\u003Cli>経路を組織情報から決める場合、該当する役職者が不在のときはどう振る舞うか\u003C\u002Fli>\u003Cli>申請者が承認者を選ぶ形と、組織から自動で決める形を、申請の種類ごとに使い分けられるか\u003C\u002Fli>\u003Cli>承認の記録に、そのとき適用された経路の定義まで残るか\u003C\u002Fli>\u003C\u002Ful>\u003Cp>最後の1つは、聞かれることが少ない項目です。ただ、問2に引っかかっている会社にとっては、いちばん効く確認だと思っています。\u003C\u002Fp>\u003Ch2 id=\"h96641f34b3\">いつ替えるかは記録の側から決まる\u003C\u002Fh2>\u003Cp>承認者を申請者が選ぶ形は、うまく回っているうちは何も問題を起こしません。3つの問いに引っかかったからといって、すぐ替えるべきという話でもありません。\u003C\u002Fp>\u003Cp>ただ、問1は文書を整えれば解けます。問3も、選び方を書き出せば当面はしのげます。\u003C\u002Fp>\u003Cp>問2だけは、時間が経つほど戻せなくなります。記録が残っていない期間は、あとから埋められないからです。\u003C\u002Fp>\u003Cp>私は相談を受ける側で、組織情報を整え直す作業を自分の手でやり切った当事者ではありません。ここに書けるのは、相談の場で共通して出てきた論点の整理までです。この整理が、いまの運用をどこまで続けるかを考えるときのたたき台になれば幸いです。\u003C\u002Fp>",[16,20,23,26,29,33,36,39,42,45,48],{"id":17,"text":18,"level":19},"hffb30a1352","承認者を選ぶ仕事は申請者に残っている",2,{"id":21,"text":22,"level":19},"h0d804d8db5","グループウェアの組織図は、整った組織までしか届かない",{"id":24,"text":25,"level":19},"h38060edc2e","経路を作り込めば済むわけではない",{"id":27,"text":28,"level":19},"he642004c76","3つの問いでいまの運用がどこまで持つかを見る",{"id":30,"text":31,"level":32},"hd28bcea82f","問1 その承認者はどこかに書いてあるか",3,{"id":34,"text":35,"level":32},"had0294c953","問2 違う人が承認しても止まらない",{"id":37,"text":38,"level":32},"h116036d833","問3 選び方を知っている人が抜けたとき",{"id":40,"text":41,"level":32},"h3103eb3a9f","3つを1人の申請者に戻す",{"id":43,"text":44,"level":19},"hf245469f54","以前は替えなくてもいいと考えていました",{"id":46,"text":47,"level":19},"hf75771ab5e","社内に聞くこととベンダーに聞くこと",{"id":49,"text":50,"level":19},"h96641f34b3","いつ替えるかは記録の側から決まる","「承認者はどなたに回せばいいですか」申請を上げる直前に、こういう確認が飛んできます。聞かれた側もすぐには答えられません。似た申請が前にもあったはずだと履歴をたどって、そのときの承認者を探すことになります。組織図がシステムに入っていれば、この…",10,"2026-08-19T06:14:52.559Z",{"contents":55,"totalCount":151,"limit":152,"offset":153,"category":154},[56,64,72,80,88,96,105,108,116,127,135,143],{"id":57,"slug":57,"title":58,"categories":59,"image":60,"publishedAt":62,"order":63},"form_field_placement","申請フォームの項目が52個。どこまで画面に載せるか",[7],{"url":61,"width":10,"height":11},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F72cccde74ada405581943d99fbcfb389\u002Feyecatch-form-field-placement-20260821.svg","2026-08-31T03:00:08.597Z",32,{"id":65,"slug":65,"title":66,"categories":67,"image":68,"publishedAt":70,"order":71},"workflow_migration_forms","ワークフロー移行の様式一覧。その行数は業務の数ではない",[7],{"url":69,"width":10,"height":11},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F5453b8af60f34db3bae2a831165858d2\u002Feyecatch-migration-forms-20260822.svg","2026-08-28T03:00:08.796Z",31,{"id":73,"slug":73,"title":74,"categories":75,"image":76,"publishedAt":78,"order":79},"workflow_user_count","ワークフローシステムの利用人数は、4つの層に分けて数える",[7],{"url":77,"width":10,"height":11},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002Ffa59e9e9fb06403ab768aa71b98c4b1c\u002Feyecatch-workflow-user-count-20260817.svg","2026-08-25T03:00:07.825Z",30,{"id":81,"slug":81,"title":82,"categories":83,"image":84,"publishedAt":86,"order":87},"purchase_workflow_split","購買ワークフローをどこで区切るか。稟議・発注・検収・支払",[7],{"url":85,"width":10,"height":11},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F3c4bbdb6cdd24b17adf74aeb8b59d6fb\u002Feyecatch-purchase-workflow-split-20260819.svg","2026-08-24T08:33:41.719Z",29,{"id":89,"slug":89,"title":90,"categories":91,"image":92,"publishedAt":94,"order":95},"1zvg65piyg1o","ワークフローシステムを選ぶ前に押さえておきたいポイント。比較表の○が揃ってしまう4つの領域",[7],{"url":93,"width":10,"height":11},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F9d15c99ff977492cbb1d90924a827bf8\u002Feyecatch-erabu-mae-20260815.svg","2026-08-21T05:04:24.116Z",28,{"id":97,"slug":97,"title":98,"categories":99,"image":101,"publishedAt":103,"order":104},"0u3jqdwhrgu5","稟議の差し戻しが減らないのは、承認する側の判断基準が申請画面に載っていないから",[100],"業務効率化",{"url":102,"width":10,"height":11},"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":4,"slug":4,"title":5,"categories":106,"image":107,"publishedAt":12,"order":13},[7],{"url":9,"width":10,"height":11},{"id":109,"slug":109,"title":110,"categories":111,"image":112,"publishedAt":114,"order":115},"3358728uqfu3","ワークフローのトライアルは、何を確かめる30日か。検証を3層に分けて設計する",[7],{"url":113,"width":10,"height":11},"https:\u002F\u002Fimages.microcms-assets.io\u002Fassets\u002F5698d73b7745481892076525d4d1bcad\u002F2b008dbc543f4e519b897fe9f68ebb89\u002Feyecatch-trial-30days-20260814.svg","2026-08-18T10:45:01.972Z",25,{"id":117,"slug":117,"title":118,"categories":119,"image":121,"publishedAt":125,"order":126},"u-_k2jynls92","【セミナーレポート】決算が締まらなかった会社は、ワークフローをどう建て直したか（出前館 志賀綾子氏・足立隆裕氏）",[120],"ガバナンス",{"url":122,"width":123,"height":124},"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":128,"slug":128,"title":129,"categories":130,"image":132,"publishedAt":133,"order":134},"f0jy89g2jlp","依頼系の申請は一覧を見ても誰の件か分からない。原因と一覧から逆算するフォーム設計",[131],"働き方・組織",null,"2026-08-14T01:00:07.094Z",23,{"id":136,"slug":136,"title":137,"categories":138,"image":139,"publishedAt":141,"order":142},"zdr5kdsdp","承認経路のメンテが終わらない理由",[131],{"url":140,"width":10,"height":11},"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":144,"slug":144,"title":145,"categories":146,"image":147,"publishedAt":149,"order":150},"qbwzwoaayu","新システムへの切り替えは「一斉リリース」か「段階リリース」どちらが良いのか",[7],{"url":148,"width":10,"height":11},"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,""]