導入事例

DXに取り組むコープさっぽろがワークフローをkickflowにした理由

抱えていた問題点	・APIが搭載されておらず、業務の自動化が進めにくかった ・別システムへの転記作業や申請情報の出力・加工に手間がかかっていた ・チャットツール（Slack）とワークフローシステムが分断していた
導入の理由	・豊富で使いやすい API / Webhook の存在 ・Slackと稟議のシームレスな連携が簡単に実現できる ・拡張性がありながら従業員が迷わず使いやすいインターフェースだった

道民500万人の暮らしを支える「コープさっぽろ」

コープさっぽろについて教えてください。

長谷川：「コープさっぽろ」は生活協同組合です。職員数全体では15,000人を超えており、本部で勤務する者だけでいうと600人前後です。

北海道内に100以上の店舗を構えて、安全安心なコープ商品を販売し、宅配事業や共済事業も行っています。普通の会社と少し違うのは出資をしてくれている組合員自身がお客様であること。ですので「組合員のためになること」をするための組織です。

例えば、コープさっぽろでは「畑でレストラン」という企画があります。生産者さんの畑や農場に人気シェフをお招きして1日限りのランチレストランをオープンする。その1日のためにキッチンカーやテーブル、椅子などを準備しています。

また、株式会社と違う点で一つ面白いのは「儲かることを目指していない」という点もあります。

「畑でレストラン」も収支を見れば赤字ですし、コロナ禍で配食やEC事業が大きく伸びましたが、その利益は理事長から直々に「組合員に還元していきましょう」と言われています。

そのあたりは普通の株式会社とは違う意思決定ですね。

お二人はどのような業務を担当しているのでしょうか？

長谷川：私はCIOとして「デジタル推進本部」を担当しています。

コープさっぽろ全体の情報システムを統括する立場です。コープさっぽろは多くの事業を手掛けていますが、グループ全体をデジタルという横串で通して見ています。2020年の春に入協して、現在4年目に入りました。

川口：私は2022年の5月に入協しました。事業部や関連会社向けのシステム導入を担当しています。

もともとメーカー系のSESやWEB系のエンジニアとして働いていましたが、「目の前のユーザーを喜ばせたり、直接フィードバックを貰えたりするような仕事がしたい」と思いコープさっぽろの組織内システム部門に転職をしました。

興味本位の質問になってしまうのですが、デジタル推進本部のメインミッションについてもお伺いさせていただけますか？

長谷川：デジタル推進本部と聞くと「全てをデジタルに統一していく」というイメージを持たれるかもしれません。しかし、道民のなかには高齢者の方も多いので何でもデジタル化するのが最適解ではありません。

お客様に関しては紙の方がご都合が良い方もいるので「何でもかんでもデジタルで」ではなく、「アナログが好きな人にはアナログを、デジタルが好きな人にはデジタルを」という形で、選択肢の幅を増やしていくという方針で進めています。

一方で、組織内に関しては明示的にデジタルによる合理化を進めています。

私の方で方針を立て、その方針に従ってチーム一同で取り組んでいます。一部をご紹介するとこんな感じです。

• コンシューマーテクノロジーシフト: 法人向け製品は高いことが多いので、良いものはコンシューマー向け製品であっても使っていく
• オープンテクノロジーシフト: 単独メーカーの技術に依存しない
• クラウドシフト: サーバーを自前で管理しない
• SaaSシフト: スクラッチ開発しない
• ノンプログラミングシフト: SaaSで適切なものがない場合はできるだけノンプログラミングでシステム導入する
• ITの民主化シフト: システム部門以外でも業務改善できるようにする
• オートマチックシフト: 業務をITで自動化して業務自体をなくす
• 常にアップデートシフト: 常に最新のOSやファームウェアを利用し、セキュリティーの向上とともに費用も削減する
• デジタル推進本部のスキルシフト: 業務が分かるエンジニアリング組織とアプリケーション構築のプロフェッショナル組織の組成

とはいえ、いきなり全てを実施することは不可能なので、各STEPを置きながら一歩ずつ進めています。

• STEP1: テクノロジーインフラを整備する（データセンター、ネットワーク、デバイス、セキュリティーなど）
• STEP2: コミュニケーションインフラを整備する（Slack、GoogleWorkspaceなど）
• STEP3: アプリケーションインフラを整備する（データが貯まる仕組みのこと　※承認や作業のログが貯まるkickflowもここに入る）
• STEP4: アプリケーションを整備する（データを活用する業務フローのこと）

「DXを進めるぞ」となるとSTEP4から取り組まれる企業もいらっしゃると思いますが、その前工程から整備していくことが「急がば回れ」的な発想で重要だと考えています。

例えば、コープさっぽろでは「からあげ事件」と呼ぶ事例がありました。

各店舗に送った冷凍からあげのロットに揚げると黒くなってしまうモノが混ざっており、それを販売しないように通達したときのこと。

これまでは各店舗のスーパーバイザーが一件一件店舗に電話して「このロットのからあげは販売しないで！」と伝えていました。

でも、Slackが導入されたので、各店舗とのチャネルにこの内容を投稿するだけ。店側もスタンプで「了解」や「済」と返せばOKです。

スーパーバイザーを介さずに情報が伝達される世界を作ること、これも一つのDXではないでしょうか。小さなことかもしれませんがデジタルで業務が楽になった事例です。

ワークフローと他システムをAPIで繋いでシームレスに

コープさっぽろは稟議やワークフローにどのような課題を抱えていたのでしょうか？

長谷川：先に上げた方針に従って見直しをかけようと思っていた一つに、利用頻度も高く承認や作業ログが貯まるワークフローがありました。

もともとはオンプレミスのワークフローシステムを導入していました。

ただ、以前使っていたシステムは拡張性があまりなく、API経由でデータ抽出ができなかったことから、CSVファイルをダウンロードして加工して…といった人手が必要となる作業が発生していました。

他にも監査で「いくら以上の稟議だけ抽出したい」となった際に、簡単にデータを出せるのが理想です。今まで人間がやっていたことをなるべく自動化し、工数はもちろんのこと、マインドシェアも減らしていきたいと考えていました。

逆にkickflowに期待してくださっていたことは、どういった点でしたか？

川口：拡張性の高い機能がラインナップされている点、またAPIが豊富な点が決め手でした。特にkickflowはSlack連携が標準機能として備わっているのが魅力的でした。

社内コミュニケーションがメールからチャット（Slack）に移行していたので、Slack上で通知を受け取り承認まで完了する体験作りは重要視していましたね。

また、他にも重要視していたユーザー体験としては契約締結のフローです。これまでは稟議や押印申請というワークフローを回し、最終的には紙で契約締結していました。

現在はkickflowとクラウドサインをAPIでつなぎ、稟議書が通ればクラウドサイン発注書を自動送信する仕組みにしたので、契約締結が圧倒的に楽になりました。

ちなみにkickflowはじめクラウドサイン連携を標準機能として持っている製品はあるのですが、コープさっぽろの業務フローに合わせる形とするために、ここは標準機能ではなくAPIを使って開発を行った点です。

導入時には各部門とのコミュニケーションが重要

kickflow導入に際して、苦労した点などはありましたか？

川口：3点あります。1つ目は「コミュニケーション」でしょうか。お恥ずかしい話ではありますが、部署間のコミュニケーション不足が要因で導入プロジェクトが少し止まっていた時期がありました。

ワークフローはシステム部署だけではなく多くの部署が関わる領域ですので、各部署の責任者に大方針やこのプロジェクトの意義、メリットやデメリット、各部門に協力して欲しいことを説明するなど泥臭くコミュニケーションを取ることで一歩ずつ解消していきました。

2つ目は私が「大きな組織に慣れていなかった」ことがあります。

以前の会社は経理も総務も1人が担当していたので「この人に聞けばいい」と理解していたのですが、コープさっぽろは分業が進んでいるので「誰に何を確認すればいいのか」が手探りでしたね。

こちらも1つ目とあわせて解消していきました。

3つ目は「役職や承認フローの設計」です。

規模が大きいことから部署によって「この承認はセンター長？　店長？」となったり、「店長」の肩書が本部ではどの階層に相当するのかなど組織と承認経路の標準化が難しかったことを覚えています。リプレースのタイミングで改めて整理することが出来たので良かったです。

全社的なリプレースに向けて工夫した点を教えてください。

川口: 全組織導入する前に、先行してシステム部と広報部でスモールスタートという形で実業務での利用を始めました。

設計や運用方針を決めることが主目的ではありましたが、実業務として回している実績やイメージを伝える材料となったので、結果として関連部署に説明する際にも活用することが出来ました。

関連部署含めて管理部門全体でのフローが固まった後は、全組織に向けてシステム変更の説明会を行いました。30分の説明会を8回ぐらい実施しましたね。

ここでは「リプレースの経緯」「いつまでは前のシステムで申請、いつからはkickflowで申請」といった点をシンプルに共有しました。

コープさっぽろの場合は紙からシステムの移行ではなく、システムからシステムへの移行となるので、「前のシステムとの差分（新規に出来ること、逆に出来なくなること）」については丁寧に伝えることを心がけましたね。

今後はワークフローの改善に着手

実際にkickflowを導入して組織内の評判はいかがでしたか？

川口：「Slackで『承認してください』と通知が飛ぶのは楽だね～」と評判がいいですね。

リリース直後は月30～40件ほど問い合わせがきていましたが、それも「ログイン招待切れの再発行依頼」や「経路ミスの指摘」「閲覧権限の修正」など軽微かつ導入初期に発生するものが主でした。

長谷川：いちいちメールを見て、システムに飛び「承認されたかどうか？」を見に行かなくていいのは楽になりましたね。

また、kickflowはGoogleアカウント認証が可能なので個別にID/パスワード運用をしなくていいのも良い点です。

オンプレミスに付随する課題は解消されましたし、APIを活用するなどの大本の課題はほぼ解消できたと思っています。

今後はどのような取り組みを行う予定でしょうか？

川口：元々、一度に全てをやり切ろうとするとリリースまでに時間がかかってしまうので、アジャイル的に進めようと考えていました。

今回のリプレースに際してはやりたいことの半分程度まで進められたという印象です。基盤を整えることが出来たので、今後は残り半分にあたる業務フロー自体の改善を行っていく予定です。

長谷川：ユーザーにとって使いやすいシステムになるといいですね。

ここで言うユーザーとは申請や承認を行う方々だけでなく「申請や承認の後工程も含めたコープさっぽろ全体にとって」という意味です。システム連携やデータ活用も含めて取り組んでいこうと考えています。

不退転の気持ちで泥臭く、一歩ずつ良くしていくこと

これからワークフローを改善する方に向けてメッセージをお願い致します。

川口：システムをリプレースする際には関係する部署間のコミュニケーションが重要だと思います。

Slackによる文字ベースでのコミュニケーションだけでなく、口頭で心配事を確認するといった感情面のやり取りも大事です。

大きな組織だからこそ「誰が何の情報を持っていて、どのように感じるか」といった人間的な部分にも配慮すると進めやすくなると思います。

長谷川：やはり、今日よりも明日のほうが良い世界を作りたいですよね。

少しでも企業や社会を良くしていきたいと思う気持ちを大事にしながら、不退転の心で皆で取り組んでいきましょう！