バイセル Tech Blog

バイセル Tech Blogは株式会社BuySell Technologiesのエンジニア達が知見・発見を共有する技術ブログです。

バイセル Tech Blog

ワークフローシステムをkickflowにリプレースした話

はじめに

はじめまして

株式会社BuySell Technologies 情報システム部所属の菊池と申します。

私は情報システム部(以下情シス)内で、社内全般のSaaS管理・運用、社員のヘルプデスク対応などを担当しております。

今回はワークフロー業務として全社的に利用していたシステムをkickflowというプロダクトにリプレースすることになった背景・プロセス・結果を皆様にお伝えできればと思います。

旧システムとkickflowについて

旧システムとkickflowは、どちらも素晴らしいシステムですが、それぞれ特徴が異なります。以下に、機能面の視点から両者の違いをまとめました。

旧システム

  • 特徴
    • 幅広い業務に対応: 顧客管理、案件管理、勤怠管理など、様々な業務に合わせたアプリをノーコードで作成できる。
    • 柔軟なカスタマイズ: アプリの項目やレイアウト、権限などを自由に設定できる。
    • コミュニケーション機能: アプリ上でコメントやファイルを共有でき、チームでの情報共有や進捗管理に役立つ

kickflow

  • 特徴
    • ワークフローに特化: 稟議申請、経費精算、契約書作成など、様々なワークフローをノーコードで構築できる。
    • 直感的な操作: ドラッグ&ドロップでワークフローを設計できるため、誰でも簡単に利用できる。
    • 高度な機能: アプリ上でコメントやファイルを共有でき、チームでの情報共有や進捗管理に役立つ
    • 外部連携: Zapierや他のクラウドサービスとの連携により、ワークフローの効率化やデータ連携が可能。

旧システムは全社的な業務改善に対応できる多機能なシステムであるのに対し、kickflow はワークフロー業務に特化したシステムであると言えます。

リプレースの背景

リプレースの背景には、主に以下の2つの理由がありました。

機能面

旧システムは全社的な業務改善に貢献する優れたプロダクトですが、ワークフロー機能をメインに利用するバイセルにとって、その高いカスタマイズ性を十分に活かせませんでした。申請者・承認者・管理者にとって最適な環境とは言えず、バイセルでは、よりシンプルな機能で、ワークフロー業務に特化したプロダクトが求められていました。

コスト面

旧システムのアカウント発行数は正社員全員分の約1,200アカウントでしたが、「発行済み未使用」のユーザーが多く存在し、月々のコストが無駄に発生していました。今回のリプレースを機に、アカウント発行ルールの整備も併せて行いました。

上記の背景を踏まえ

  • ワークフロー業務に特化している
  • SSO・Slack連携などバイセルに必要な機能を兼ね備えている
  • kickflowへのリプレースにより、1アカウントあたり約35%のコスト削減が見込まれる

という点はバイセルの環境とマッチすると判断し、導入に至りました。

特にSlackとの連携は、バイセルが待ち望んでいた機能の1つでした。 旧システムではSlack連携機能がなく、承認ステップの通知もメールのみであったため承認者が気付かず、早急な承認依頼のコミュニケーションが発生していました。 kickflowでは、Slack通知機能に加え、Slack上での承認やコメントも可能なため、不要なコミュニケーションが削減され、旧システムと比較して承認スピードの大幅な向上が見込まれました。

その他、旧システムは複雑な構造によりUI・UXに課題を抱えていましたが、kickflowのシンプルでモダンな機能により、申請者・承認者は視覚的・直感的に申請や承認を行え迷うことがなくなるほか、管理者にとってもメンテナンスが容易になることが期待されました。

kickflow導入プロセス

kickflowの導入は下記のプロセスを踏まえて進めていきました。

1.運用における原理・原則の取り決め

旧システムでは、承認ステップにおけるメンバーの個別指定(バイネーム指定)が、管理コスト肥大化の一因となっていました。 組織の成長に伴い、組織変更や人事異動が発生するバイセルでは、承認者の手作業による変更が都度発生していました。その結果、業務量の増加、設定のミス、管理者と承認者間のコミュニケーションコスト増大を招いていました。 これらの課題を解決するため、承認者の個別指定を廃止し、部署・役職による一律指定に移行しました。これにより、承認メンバーが動的に適用され、人事異動や組織変更に伴う承認者の変更手続きが簡略化されました。

また、コスト削減の観点から、アカウント付与対象者の基準を見直しました。以前は正社員全員にアカウントを付与していましたが、一定以上の役職者と一部のバックオフィス担当者のみに限定する方針としました。

2.他部署とのコミュニケーション

今回のリプレースは、情シスのみならず他部署にも大きな影響を与えるため、綿密なコミュニケーションが不可欠でした。 まず、議題に挙がったのは、移行する申請アプリの選定についてです。当時の環境には、入社申請・退職申請・各種システム利用申請など、多数の申請アプリが存在していました。そのため、「この申請は誰が利用しているのだろうか?」「この申請、最終更新が3年前だが今も必要なのだろうか?」といった疑義が生じるものが多数ありました。 そこで、これらの申請アプリの一覧と利用実績を洗い出し、各事業部と協議の上、kickflowへの移行可否を判断しました。

その他、既存の申請アプリ、経路、閲覧・承認権限周りの見直しについて話し合うことができました。 管理者・承認者・申請者など様々な立場の社員がいますが、「この申請、こうだったら工数が減っていいのにな…」「この承認者って本当に必要なんだろうか?」など、曖昧に共有されていた認識について、改めて話し合う良い機会となりました。 申請アプリ内の項目・経路、承認に関する整理ができたことにより、旧システムと比較して、1件あたりの承認までのリードタイムを113時間、日数にして4. 6日ほど短縮することができました。

3.各種申請アプリ、経路の作成

各部署とコミュニケーションを取りながら、各種申請アプリと経路の作成を並行して行いました。 kickflowでのアプリ作成は初めてだったため、試行錯誤の連続でした。

例えば、"各種社員情報の入力を自動化する"という目的を達成するには

A・B・Cの条件を満たす必要がある →AとBを満たすと、仕様の問題でCを満たすことができない

といった問題も発生しましたがkickflowにはwebhookなど各主要Saasとの外部連携が豊富でしたのでAPIなどを利用しながら課題はクリアできました。

また、バイセルでは各社取引先様情報を集約するデータベースとしてkintoneを利用しているのですが

  1. 取引先様に関する各種申請がkickflowで承認される
  2. kintoneのマスタ情報も自動で都度新規追加・編集される
  3. Slackで連携通知が流れる

といった作業の自動化も実現することができました。

利用したプロダクトはZapierです。各種処理フローを簡単に紹介すると

  1. 取引先様に関する申請が完了した際にkickflowよりwebhookを受け取る
  2. チケットタイトルを取得
    • webhookのリクエストボディからチケットタイトルを取得
      • チケットタイトルの部分一致から、申請種別ごとに処理分岐
  3. 新規取引様作成・情報更新・取引停止など申請種別によってkintone側で分岐処理させる

上記のフローにて作業を自動化しました。

承認者・作業者にとって、kintoneと同じようなマスタをわざわざ新規構築することなくそのまま利用できたこと、kickflow・kintoneサイト間の往復をしないことはユーザビリティの観点から大きなメリットとなりました。

また、申請内の項目に関しても、旧システムの項目をなるべく踏襲するよう配慮しました。これは上記と同様にユーザビリティの観点から、項目まで大幅に変更してしまうと申請時に迷いが生じてしまう、という背景があったためです。

そういった紆余曲折がありながら、結果として50個を超えるアプリ、70個を超える経路を作成しました。

4.テストの実施

各種アプリや経路の設定、部内レビュー、アカウント付与予定者への説明会などを経て、2週間ほどの全社的なテスト期間を設けました。

テスト対象者は、アカウント付与予定者全員です。

テストの結果、細やかなエラー報告・要望(申請内文言の変更・申請条件の設定ミス・一般社員へのアカウント発行依頼など)が多数寄せられましたが、そのほとんどはその都度対応可能なもので、運用上クリティカルな問題はありませんでした。

これは、事業部サイドとの密なコミュニケーションと入念なテストを実施したことによる結果だと思います。

導入・運用開始

テスト期間を経て、本格的な運用が開始されました。

運用開始後、情シスでは主に下記のような対応を行いました。

ユーザーからの申請項目の修正依頼および新規ワークフロー作成依頼への対応

テスト期間に引き続き、アプリ内の軽微な設定変更や経路の修正には都度対応しました。

また、複数の部署から新規申請アプリの作成依頼もありました。

これらは申請頻度や申請数を加味しながら優先順位を決め、新規作成もしくは関連性の高い既存アプリ内に組み込むことで対応しました。

組織図の変更

前述の通り、バイセルでは事業拡大にあわせて組織変更があり、都度kickflow内での組織図更新が必要となります。

その際、部署異動する社員の情報変更作業はもちろんですが、廃止される予定の部署が承認経路に入っていた場合、割当先の部署をコミュニケーションを図りながら設定する作業も発生しました。

以前まではユーザーの所属情報や組織図を都度変更していましたが、kickflowにはこれらの情報を予約更新できる機能があります。事前に部署・所属情報を設定し切替日を予約することが可能なので工数・時間ともに余裕ができるようになりました。

導入成果

今回のシステムリプレースにより、申請から承認までのリードタイムとコストの両面において、大幅な削減を実現することができました。

1件あたりのリードタイム短縮

旧システムと比較して、約38%短縮することができました。

これは、申請項目の整理、承認経路の最適化など、様々な改善施策が奏功した結果と言えます。リードタイム短縮は、業務効率化に大きく貢献し、従業員の生産性向上にもつながりました。

コスト削減

こちらはアカウント付与者の整理をした結果、年間約1,000万円のコスト削減を達成しました。

これは、申請項目の整理、承認経路の最適化など、様々な改善施策が奏功した結果と言えます。リードタイム短縮は、業務効率化に大きく貢献し、従業員の生産性向上にもつながりました。

将来の展望・ネクストアクション

バイセルはM&Aを積極的に行っており、今後もその流れは加速していくものと思われます。それに伴い、kickflowの導入のみならず、社内製アプリやシステムの導入・浸透も必須となってきます。

現状、kickflowを導入しているのはグループ会社を含めてバイセルのみですが、今後はグループ会社のタイムレス・フォーナインもバイセルと同じシステムを利用しているため順次kickflowにリプレースしていく予定です。

その際、コストや工数・承認までのリードタイム削減はもちろんですが、「バイセルには無いがグループ会社にはあるアプリ」や各社利用頻度の違いなど、今回のリプレースとは異なる状況も想定されるため、引き続き綿密なコミュニケーションを図りながら導入を進めていきたいと思います。

また、バイセルの申請アプリに関しても改善の余地は十分にあると考えています。今後は、

  • 入社申請時にアカウントが自動で作成される機能
  • グループ会社を複数含めた承認経路の設定・整備

などを実現していきたいと考えています。

おわりに

今回のシステムリプレースでは、事前準備やテストを十分に実施したことにより、大きな混乱もなくkickflowを導入することができました。また、承認までのリードタイムとコストを大幅に削減できたことも大きな成果でした。

今後は、グループ会社へのkickflow導入をはじめ、グループ会社を含む全社的なIT統制が大きなミッションとなります。グループ会社は今後も増加が見込まれており、取り組むべき課題・やりたいことはまだまだあります。

バイセルではこのような状況を楽しみながら、一緒に働いてくれる人を募集しています。

少しでも気になった方のご応募、お待ちしています。

https://herp.careers/v1/buyselltech/requisition-groups/29a2752f-e907-4a7b-8120-5a0902b44756