【セミナーレポート】決算が締まらなかった会社は、ワークフローをどう建て直したか（出前館 志賀綾子氏・足立隆裕氏）
クラウドワークフロー「kickflow」の顧客対談セミナーに、株式会社出前館から執行役員 兼 BPオペレーション本部本部長の志賀綾子さんと、情報システム部 IT戦略グループ ITヘルプデスクグループ グループマネージャーの足立隆裕さんをお迎えしました。
ワークフローシステムの導入やリプレイスを経験したことがある人は、そう多くはありません。 この領域は情報システム部門だけで完結せず、経理や内部監査、人事、そして経営層まで巻き込む一大プロジェクトです。
「変えたほうがいいのはわかっているが、どう進めればいいのかわからない」
「上申が通らない」
そうした声を数多くいただいてきたことが、このセミナーの出発点でした。
本記事では、当日の対談内容をレポートします。
第1部は当時管理本部長だった志賀さんに経営と統制の視点から、
第2部は導入プロジェクトを推進した足立さんに現場の視点から伺いました。
アーカイブ映像もご覧いただけます（記事末尾にリンクがあります）。
序章｜「回っているから、まだ大丈夫」の危うさ
ワークフローは、動いていることが当たり前だと思われるシステムです。
普通に回っていることが普通だというふうに捉えるのが、おそらく経営層の方々です。現場としては何を使っていいかわからない、何をしたら正しいんだろうというところで、少しギャップは感じていました。（志賀さん）
経営層は「回っているならそれでいい」と見る。 現場は毎日汗をかいている。 この非対称が続くかぎり、リプレイスの必要性は言葉にならないまま先送りされます。
出前館の場合、その先送りを止めたのは機能への不満ではありませんでした。
第1章｜急成長のあとに来た「成長痛」
決算が締まらなかった
出前館は創業から約25年、上場企業でありながら社内はベンチャー気質が残る会社です。 2020年のコロナ禍以降、売上は5倍、従業員数は4倍に伸びました。
急成長には成長痛が伴います。
決算が締められないような事象が発生したのが2021年の秋です。（志賀さん）
決算が締まらず、株主総会の日程にも影響が出ました。 社外取締役を含む経営層、そして株主まで、事態は周知の事実になりました。
本来は誤謬が出る前に補正されなければならない部分なので、どちらかというとお恥ずかしい話だなと思うところが大きいのですが、もうこれは短期に修正しなければならない、それも大元から修正しなければいけないことなんだ、というところが一番大きくて。（志賀さん）
志賀さんが入社したのは2022年です。 バックオフィスの管理体制強化をミッションとして着任し、そこにワークフローの再構築が含まれていました。
ここで注目したいのは、経営層の合意が先にあり、残っていたのは How だけだったという点です。
全社的に、特に経営層がこの強化をしなければいけないことはアグリーしている状態だったので、結果的に私が強く推し進めたというよりは、How の部分をどうしていこうかという状況でした。（志賀さん）
「ワークフローはただのツールに過ぎない」
では、当時のワークフローの何が問題だったのか。 志賀さんの整理は、ツールの機能比較から始まりません。
ワークフローってただのツールに過ぎなくて、大元は決裁権限規程だったりの規程をどう表現するかというところがとても大事です。一人一人の従業員やスタッフまで全ての決裁権限を万遍なく浸透させるというのは現実的に無理な中で、このワークフローを使えば統制上問題ない、エラーが出ない、正しく処理ができるんだ、というところまで持っていくのが必要なんです。（志賀さん）
当時使われていたのは、別システムに付随するオプション的なワークフローと、グループ会社が作ったスクラッチのワークフローの2本立てでした。 どちらも階段状に次のステップへ回すことはできても、金額基準や階層に応じた細かい条件設定、分岐、他の申請との関連付けができません。
できない部分は人が埋めることになります。 割り振りを人の判断で変え、追加で配布する。 その手作業が抜けたときに、そのままエラーになる。
社歴の長い従業員が頭の中で判定しているうちは回っていました。 しかし規模が5倍になると、一人では回しきれません。 そしてノウハウはその人にしかない。
そこがちょっと危ないな、怖いなと思ってやっていたという状況です。（志賀さん）
載せられない申請は、メールやチャット、Excelのコメントで処理されていきました。 承認を取らずに進めるわけにはいかないが、ワークフロー化を待ってもいられない。 そのギャップを埋める形で、システム外の運用が肥大化していったのです。
最初にやったのは、棚卸しと「聞いて回る」こと
着手の第一歩は、既存ワークフローの承認経路とロール設定の洗い出しでした。 ところが、棚卸しができないほど細かい設定が積み上がっていました。
ちょっとこれはスパゲッティ化が始まっているので、なんか直すよりゼロイチやった方がいいかね、なんて話にまさにつながってきました。（志賀さん）
決裁権限規程を読んでも、社内の業務に合わせて生まれたフローまではわかりません。 本来これは誰の権限で、誰が確認者で、誰が承認者なのか。 情報システム部門のメンバーと議論を重ねながら紐解いていきました。
設計の方針は、最も使うフローを最大公約数として先に作り、そこにオプションとして経路の追加やスキップを重ねていくというものです。
同時に志賀さんは、経営層に個別に確認して回りました。
当時のCFOに、これって承認したいですか、それまで全部見たいですか、って聞いて回るということは結構していました。（志賀さん）
経営層といっても「回ってくればいい」と考える人ばかりではありません。 正しいものを正しく見たいという人もいれば、全権限が上がってきたら承認が大量に届いて困る人もいます。 現行の権限規程と実態がフィットしているかを確かめる作業でもありました。
経理と内部監査へのヒアリングにも時間を割いています。 監査法人への説明が必要になる領域だからです。
現場の反応と、伝え方
変更にあたって、現場から声が上がらなかったわけではありません。
抵抗感というより、じゃあどうしたらいいの、私のこの業務はどうなるの、と。今までのものが変わることを不安に思うのは当然のことなので、その作業そのものにこだわる発言の方がどうしても多くなる。（志賀さん）
これに対して志賀さんは、規程を根拠に説明しました。 誰に承認を取るかは規程で決まっている。 ツールが変わってもやることは変わらず、むしろ入力が楽になる。
ツールの導入としてではなく、プロジェクトの理念と背景を伝えることで協力を得ていったかたちです。
副次的に得られたもの
ワークフローで重要なのは、お金の流れと契約の流れという2つのファクトだと志賀さんは言います。 その整理を先に済ませてから、細かい業務をどう載せるかを詰めていきました。
結果として起きた変化は、申請の電子化そのものより大きなものでした。
これは標準型に合わせるのか、標準とは違うプロセスを踏んでいるのか、それならその場合はなぜなのか、という会話ができる人が増えたのがすごく嬉しいです。（志賀さん）
会社の動脈が一度可視化されたことで、新しい申請が出てきたときにも位置づけを含めて判断できるようになりました。
追加コストをどう説明したか
既存の2システムは、いずれも利用料が安いものでした。 新しいワークフローを入れれば費用は上がります。
私以上の経営層のところも、アドオンで費用がかかるんだというところは、最初、そんなに即決でできたわけではないんですけれども。（志賀さん）
説明の柱は3つでした。
- 帳票を集める作業がなくなり、散らばっていた承認証跡が一元化される。これは人件費の裏返しである
- タイムスタンプが付くことで、メールの証跡よりも証跡としての確度が高くなる。単純にコストだけでは表現できない
- コストをかける以上は使い倒す
何かが下がるとか、単純にコストカットになるというよりも、これを活かしてもっとバリューを出していくよ、というような説明をした記憶があります。（志賀さん）
情報システム部門への支援
経営層からは、こう言われ続けていたそうです。
いいものを入れてもいいけれども、それが使いこなせなかったら意味がないから。特に高いものを入れるときに使いこなせないと一番もったいない。
※経営層の言葉（志賀さん）
そのため、社内にワークフローが何十本、何百本あって、それが全部取り込めるのかを説明できる状態を重視しました。 志賀さん自身も製品説明の場に何度か同席し、責任を持ってローンチまで並走すると表明しています。
第2章｜「普通のワークフローを入れてください」
ここからは第2部、プロジェクトを推進した足立さんのパートです。
出前館の情報システム部は独立した「IT本部」に属し、IT戦略、ファシリティ、ヘルプデスク、ウェブの4グループで構成されています。 ワークフロー導入を担当したのはIT戦略グループです。
プロジェクト体制は3名でした。 PjMが足立さん、技術面を見るプロパー社員が1名、スケジュール管理を担うPMOが業務委託で1名。 この体制は、契約前の選定フェーズから導入後の構築フェーズまで変わっていません。
「何でもいい」ほど困るものはない
志賀さんから足立さんへのオーダーは、シンプルなものでした。
笑っちゃうかもしれないんですけど、普通のワークフローを入れてくださいというお話はしました。（志賀さん）
受け取った側の反応です。
どういう機能要件が欲しいですかと聞いたら、いや、普通のワークフローだったら何でもいいよみたいなことを言われて。いや、逆にどうしたらいいんだろうと。何でもいいほどこちらが困ってしまうことはなかった。（足立さん）
そこで足立さんは、自分で3つの選定軸を立てました。
1つ目は、SaaSであること。 出前館の社内システムには「物を持たない」という考え方があります。 オンプレミスは維持費に加えて、基盤があってもそれを支える人件費が必ず発生します。
さらに足立さんは、グループウェアの一機能ではなく、ワークフロー単体で成立している専用製品を探していました。
ベストオブブリードという考え方で我々は社内システムを導入しているので、やっぱりSaaS一つ一つが機能として特化していた方が、機能要件としては素晴らしいですし、痒いところに手が届くという経験則もあるので。（足立さん）
2つ目は、柔軟性とカスタマイズ性。 他のSaaSとどれだけ連携できるか、APIとWebhookがあるかどうかを必須条件としました。 ワークフローからのアカウント改廃、将来的には社内のスクラッチシステムとの連携まで視野に入れていたためです。
3つ目は、運用負荷が軽いこと。 ワークフローシステムは専門要員による属人化が起きやすく、しかも出前館は組織変更が非常に多い会社です。 直感的に触れること、ノーコードとローコードで扱えることを求めました。
この条件には、足立さん自身の前職での経験が背景にあります。
その時に非常に苦労したのが、JavaScriptで特別な承認フローを組む設定が必要だったりというのが当時あったんですね。基本的にもうGUI上でオペレーションできるというところは、運用負荷という観点で最低限譲れない部分ではあった。（足立さん）
kickflowを選んだ理由
選定理由としては、正直、今まで言ってきたことが全て一通り網羅されていたという一言に尽きるなと思っています。（足立さん）
具体的に挙げていただいたのは、豊富なAPIとWebhook連携による自動化、GUIベースで担保されるメンテナンス性、そして組織変更時の事前予約機能でした。
他のワークフローですと、発令日の1日前の深夜に実行したり、場合によっては当日の朝に情シスの人が手動で設定変更をかけるというところは苦労しているという話も聞いていたので。（足立さん）
「紙っぽいUI」の議論は起きなかった
ワークフロー選定の最終盤で論点になりやすいのが、申請画面が紙の帳票に見えるかどうかです。 出前館ではこの議論が発生しませんでした。
既存の2システムがどちらも紙的なUIではなく、会社として思ったほど紙文化がなかったためです。
足立さん個人の見解も明快でした。
実際に紙っぽくないフォームが決まっているものを使い始めると結構慣れてきてしまって、紙のレイアウトに固執する理由というのは正直あまりなくなってしまったんですね。UIってのはあくまでも手段ですので、目的はあくまでも承認行為。（足立さん）
紙のレイアウトのほうが現場の心理的ハードルが下がることは理解しつつ、操作性、可視性、可用性の観点ではフォームが決まっているもので十分だという判断です。
なお、kickflowもプロダクトの立ち上げ時から紙を模したUIは作っていません。 ただし、申請と承認はWeb画面でよいが最後は印刷して保存する必要がある、というニーズがあることは把握しており、帳票出力機能として用意しています。
稟議は「人件費込みのコスト比較」で通した
費用対効果の整理は、足立さんにとって最大の難所でした。
両方とも正直そのメリットとしては、単純にシステムとしての利用料が安いという一言だったんですね。逆にこれが新しいワークフローを導入する上での、論理的に提案する部分ですごいネックになった。（足立さん）
安いという事実は動かせません。 そこで足立さんは、比較の土俵を変えました。
安いんだけども、運用していったり維持していく部分にものすごい人的リソースがかかるというところがあったので、そこを可視化したんですね。人材がいた場合、じゃあその人に対してどれぐらいの人件費がかかるか、業務委託だった場合はこれぐらいのコストがかかる、というところで人件費ベースのコスト算出をした上で、この2つはシステムとしては安いんだけども、これぐらい人をアサインしないと維持運用管理ができないよと。（足立さん）
システム利用料の比較ではなく、維持運用に必要な人件費を含めた総額の比較にする。 これが決裁者への説明として機能しました。
第3章｜半年で移行しきったプロジェクトの進め方
第3のワークフローとして、小さく始める
既存の2本に加えてkickflowを導入したため、当時は社内で「第3のワークフロー」と呼んでいたそうです。 旧2システムに解約期限がなかったことも、移行を進めやすくしました。
方針はスモールスタートでした。
全社的に展開するもののセオリーとして、一気にバスッと移行するというのは事故が起きるという観点もあるかなと思うので、石橋を叩いても渡らないぐらいな感じで、少しずつ少しずつ展開していった。（足立さん）
最初に作ったのは、ワークフローを作るためのワークフロー
着手の順番には理由があります。
最優先は人事系のワークフローでした。 従来のシステムでは機能要件を満たせず、「できません」としか答えられなかった領域であり、現場からの要望が最も強かったためです。
そしてもう一つ、同時に作ったものがあります。
今後いろんなワークフローを作ってくれというような話が出てくるので、kickflow上でワークフロー作成を依頼するためのワークフローを真っ先に作った。（足立さん）
実装が進むにつれて社内にノウハウが溜まり、実装スピードも上がっていきました。 一方で現場からの差し込み要望も入り、フェーズ1と2のあいだに1.5や1.7が生まれたそうです。
二重運用の混乱をどう防いだか
スモールスタートには、新旧のツールが並存して現場が混乱するという難点があります。 出前館の対処はシンプルでした。
移行した場合は今まで使ってたワークフローに対しては申請できなくなるようにする。アナウンスとかタイトル変更ができるのであれば、これは廃止だったり移行しましたというところで、システマチックに旧ワークフローは使えないようにする。（足立さん）
そうすれば自然と人が新しいほうに流れます。 問い合わせが来たときにも「こちらです」と誘導できます。
考え方としては、古いものはバサッと切るというような形で移行してきました。（足立さん）
既存ワークフローの移行は、半年以内で完了しました。 それ以降は、これまで存在しなかったワークフローを新規に作るフェーズへ移っています。
移行速度を決めたのは「即答でジャッジしてくれる人」
志賀さんは構築フェーズについて「情報システム部門を信頼して任せた」と語っていました。 しかし実際には、裏で密に連携していた領域があります。
内部決裁規程です。
全てのワークフローが内部決裁規程に当てはまるとは限らないと思っているんです。特に作業系のワークフロー。（足立さん）
例として挙がったのが入社申請でした。 採用プロセスに関する決裁規程は存在しますが、入社申請そのものは各部署のタスク管理としての意味合いが強く、規程には書かれていません。 どの時点でどういう情報が来るべきかは、情報システム部門だけでは判断できない領域です。
そこに対しては弊社の志賀と相談しながら、ここはどうしたらいいんですかと。志賀は本当にもう、ここはこれでいいというふうにビシッとちゃんと決めてくれたので、もうそこがあるかないかによって、この移行のスピードというのは全然違っていた。（足立さん）
足立さんは、この点をプロジェクト最大の成功要因として挙げています。
正直、情報システム部門だけでは絶対にできないので、やはりそういったバックオフィス系というか、経営に近い人でイニシアチブを取ってくれる方がいたというところが非常に大きかった。（足立さん）
第4章｜「じわじわ浸透していった」その後
プロジェクトの振り返りとして、足立さんは高めの自己採点をつけました。 社内が混乱するのではないかと身構えていたものの、実際にはほとんど起きなかったこと、そして段階的に進めたことでスケジュールに余裕があったことが理由です。
導入後には、これまでできなかったことも実現しています。
一つは、子会社の人の出入りに関わるワークフローです。 出前館の業務を子会社に委託する商流のため、子会社を管理する部署が申請できる状態を作ったことで、情報連携がスムーズになりました。
その前までは全てExcelとかで連携していたので、なんか気づいたら人は増えているし、気づいたら間違いだったところが誰かの手によってこそっと修正されているみたいなところで、データの信憑性みたいな部分がちょっと怪しい部分もあった。（足立さん）
もう一つは、出前館のサービス側にあるスクラッチシステムに対するアカウント改廃の実装です。
浸透の仕方についても、印象的な言葉がありました。
どっかのタイミングでもうやってやったみたいな、達成したというような感じではなく、じわじわじわじわ浸透していった。気づいたらこんな活躍するワークフローになると思ってなかったというところが率直な感想なんですね。（足立さん）
ある部署がkickflowで自動化をしている。 それを見た別の部署が、自分たちの業務でも使えるのではないかと考える。 そうして少しずつ広がっていきました。
1年以上経過してからの方が、あ、もうこんなになくてはならないようなシステムになっているんだなというように実感できた。（足立さん）
これは情報システム部門の仕事そのものにも似ています。 障害を起こさず現状を維持することが本来正しいのに、外からは何をしているのか見えにくい。 ワークフローも、承認が普通に回っていることこそが最良の状態です。 だからこそ、ガツンと変わるより徐々に浸透していくほうが、この種のシステムには合っているのかもしれません。
おわりに｜これから上申する方へ
最後に、お二人からのメッセージを紹介します。
志賀さんからは、事故が起きる前に見直してほしいという呼びかけがありました。
他の会社様でもきっと事故は起きていないけれども、事故になってしまいそうな手前の状況というのはたくさんあると思っていて。監査とかに対応するために証票を集めて提出しなければならないみたいなシーンって、日頃の事務担当の方々のリソースに埋没しがちなんですけれども、全てワークフローに乗っていくことで一元化されるので、証跡を集めるというのが圧倒的に楽になってくる。（志賀さん）
入力必須項目を限定したことで、日本語の長文を読み解く作業もかなり減ったそうです。 今のフローが回っているからで止めず、そのフロー自体が正しいのかを見直す機会にしてほしい、という言葉で第1部は締めくくられました。
足立さんからは、上申の組み立て方についてです。
承認証跡というのは内部統制強化に繋がるので、そこをおろそかにしてしまいますと、後から是正するためにコストがさらにかかったりする部分があると思いますので、承認証跡の大切さというのはやっぱり経営層に伝えるべきだと思います。（足立さん）
コスト視点が一番重要だと思うので、単純にシステムのコストだけではなく、入れることによってどういった業務がどれぐらい短縮されて、どれぐらいのコスト利益を生むかといったところをアプローチしていくと、非常に導入しやすいんじゃないかなと私は考えています。（足立さん）
システムのコストではなく、業務のコストで語る。 証跡は、あとから取り返そうとすると高くつく。 この2点が、決裁者に届く言葉だということでしょう。
志賀さん、足立さん、貴重なお話をありがとうございました。
アーカイブ映像のご視聴
本セミナーの本編（約60分）とダイジェスト版は、アーカイブでご覧いただけます。 記事では触れられなかった細かなやりとりも収録しています。
費用対効果を試算する
足立さんが実践した「人件費を含めた総額での比較」は、リプレイス提案の要になります。 現行システムの運用工数から乗り換え効果を試算できる診断をご用意しています。
kickflowについて
kickflowは、300社以上の情報システム部門と管理部門へのヒアリングから生まれた、AI搭載のクラウドワークフローです。 組織図の事前予約、承認経路のシミュレーション、100種類以上のREST API／Webhookを備え、組織変更の多い企業でも属人化しない運用を実現します。
