導入事例

オンプレ製品からSaaSのベスト・オブ・ブリードモデルへの切替によって、稟議完了までのスピードが劇的に改善

抱えていた問題点	・運用期間が長くなるにつれ管理が難しくなってきた ・既存製品の運用コストが高まってきた
導入の理由	・クラウド製品にも関わらず機能やAPIが豊富 ・カスタマーサポートの手厚さ

日本のモバイルインターネットサービスを牽引

まずは貴社の事業について教えてください。

グリー株式会社はソーシャル・ネットワーキング・サービス（SNS）GREEを創業事業とし、世界初のモバイルソーシャルゲームを開発するなど日本のモバイルインターネットサービスを牽引してきました。

現在はゲーム事業、ライブエンターテインメント事業、メディア事業、広告事業、投資事業を展開しています。

続いて、井上さんのご所属と普段のお仕事について教えてください。

経営企画部のIT企画グループ IT企画チームに所属しています。

IT企画グループは、経営に寄与するような基幹系システム全般の企画立案やPJマネジメントを担う「IT企画チーム」と、システム開発/運用を担う「ITエンジニアリングチーム」の2チーム体制になっています。人員構成としては、社員と業務委託が半々です。

私の主な業務は、IT企画チームの中でもグリーグループ全体の業務改革（BPR)や、業務効率化の企画、立案、推進を行っています。稟議・ワークフローは情シス目線と経営管理目線の2軸で考えなければいけないことがあるかと思いますが、ちょうどその2つが統合されたような部署で日々業務にあたっています。

運用期間が長くなるにつれ、保守難易度が上がってしまった

リプレイス以前の課題を教えてください。

kickflow導入前は、オンプレミス製品でワークフローを運用していました。

この製品は2012年に導入したのですが、それ以前に分散していた、ほぼ全てのワークフローを統合していました。統合したことにより、システムや問合せ窓口が一本化する等のメリットももちろんあったのですが、、、ユーザの要望を多く取り入れすぎたことで過多になり、管理の難易度が上がってしまいました。

そのため、専任の運用要員が常に必要になるなど、運用コストが高くなるというデメリットもありました。

また、弊社では組織変更や人事異動が度々発生するのですが、その都度ワークフローの設定変更に多くの時間を要するといった、保守作業の非効率化も問題となっていました。

どのような方針でリプレイスを検討していましたか？

そういったデメリットが顕在化していたため、統合型のオンプレ製品ではなく適材適所でSaaSを組み合わせる「ベスト・オブ・ブリードモデル」でリプレイスを考えていました。しかし、周辺システムの製品選定はある程度進んでいたのですが、稟議・ワークフローの選定は難航していました。

なぜなら、内部統制の観点から要件が厳しく、リプレイス先の製品にも一定レベル以上の機能群が必要だったからです。

機能やREST APIの豊富さとサポートの手厚さで選定

そんな中、kickflowを選定した理由を教えてください。

クラウド製品にも関わらず、機能やAPIが豊富だったことが一番の理由です。

先ほどお伝えしたような一定レベル以上の機能があり、かつ出来るだけ自動化や業務の簡略化をしたかったので、Slackや他のシステムと適切に連携できるREST API/Webhookがあるのがよかったです。

もう一つあげるとすれば、契約前からサポートが手厚かった点もあるかと思います。設計が柔軟なオンプレ製品と比較すると、クラウド製品はカスタマイズ性が低い傾向があります。

そのため、オンプレミス製品からクラウド製品へ移行するためには、どうしてもオペレーションを変える必要が出てきます。

しかし、kickflowは導入検討時から単純な機能のある/なしだけではなく、「何故この機能があり、何故この機能がないのか」という根幹にある製品思想やそれを踏まえた将来的なアップデートの構想を聞かせてもらっていました。

そういった情報も考慮した上で、現状の自社のオペレーションをどのようにマッチさせるかを検討できたのが良かったですね。

前に「さらにもう一つ理由がある」と言っていたような…

これも言っちゃっていいんですかね…（笑）

kickflowさんにとっては嬉しい話ではないと思いますが、リプレイスのしやすさもポイントでした。

これは過去に失敗を重ねた中での気づきですが、システム導入時に考慮すべきバランスは「導入2割、運用6割、撤退2割」が適切なのではないかと思っています。

実際には利用がないにも関わらず、データ保全のためだけに何年も契約更新している製品もあるので、新規導入の際にはロックインされないかどうかも重視していました。

その点kickflowはAPI経由で全データ（添付ファイル含む）を取得出来るので、万が一またリプレイスが必要になった際に切り替えやすい点も評価しています。

SAP等の基幹システムと連携し、業務を自動化

kickflowをどのように使っていますか？

利用ケースは捺印申請や稟議申請が多いですね。申請されたデータはAPIを介して社内DBやSAP Concurに連携されていて、別のサービス上でも活用しています。

今後は申込書や発注書がkickflow経由で作成されるような連携も進めていく予定です。

また、運用も出来るだけ自動化するように工夫をしています。 人事異動や入退社が多いことから、kickflow上の組織やユーザー設定はSAPや管理台帳が持つ人事データをAPI連携する形で実現しました。取引先マスタも別のDBからkickflowに配信されるようにしています。

元のデータフォーマットをkickflowのものに整形する部分はDataSpider Servistaを主に使っています。

リプレイス時に苦労した点を教えてください。

これまでのオンプレ製品のワークフローの機能を全てkickflowで実現するのは不可能だったので、kickflowではどの機能を実現するのかを精査するのに苦労しました。

これまでのオンプレ製品のワークフローには非常に多くの機能があったので、どの機能を捨てるか、残すかを定量的、定性的に調査しました。

定量的な側面では、過去の申請データから各機能の利用実績や利用頻度を調査し、定性的な側面ではユーザや管理部門に必要な機能のヒアリングを実施しました。

すると、多くの機能は利用頻度がまれであったり重要性がそもそも低いなど、必要な機能は実はそれほど多くない事が分かりました。

これら調査結果踏まえ、リプレイス後に実現すべき機能を厳選しましたが、幸いkickflowには多種多様な機能があったので、大半の機能を実現することができました。

kickflowを導入した効果はありましたか？

承認が完了するまでのスピードがめちゃくちゃ早まりました！

リプレイス前の数字が取れていないのですが、肌感覚では承認までの日数が半分以下になった印象です。直近の数字だと約5割の稟議申請が当日中に承認完了、翌営業日までだと8割弱が承認完了しています。

これはSlack上で承認/通知が出来る機能や、並列承認ステップ機能が効果的でした。VPNを張る必要がなくなったのもありそうですね。

また、今回の導入をきっかけにオペレーションを見直すことができ、運用コストが下がりました。 kickflowのカスタマーサクセスの方と議論をしながら承認フローや統制のかけかたを見直すことで、結果として事前統制から事後統制の方針に切り替えを行い、運用コストを下げることに成功しました。

パイロット導入を行い、ユーザの声を聞きながら推進

ワークフローの切り替えを検討中の方へ一言お願いします。

ワークフローシステムは企業の業務や文化が如実に表れるシステムだと思います。単純な業務のフローだけではなく、企業の独特な作法や手順、慣習をシステムで表現することを求められます。

また、各フロー毎に異なる関係部署や関係者が関わり、事前の合意形成だけでも大変だったりします。

弊社では全てのワークフローを一気にリプレイスするのではなく、数種類のワークフローを厳選し、kickflowのパイロット導入を行う手法をとりました。

これは、kickflowへリプレイスするとどういった効果があるのか、ユーザ(社員)が体験した方がより理解を得やすいと判断したからです。

結果、kickflowのワークフローを利用したユーザのほとんどがkickflowの見た目の分かりやすさ、直観的に操作できる点、承認速度が劇的に向上した点を評価し、kickflowへのリプレイスをポジティブに捉えてくれました。

また、更に他のワークフローもkickflowへリプレイスして欲しい等の要望へと発展し、ワークフローのリプレイスがスムーズに進行できました。

このパイロット導入において、担当者さんに相談にのってもらえた事が良かったと思っています。パイロット導入として効果的なワークフローの選定であったり、実現したい機能の実装方法、保守の仕方など、事細かく親身にアドバイスしてもらえました。

今後ワークフローの導入やリプレイスを検討されている方々も、現在直面している問題・課題をkickflow社に相談してみるのも手だと思います。

多種多彩な解決方法をアドバイスしてくれると思いますよ。

kickflowを宣伝いただきありがとうございます(笑)　貴重なお話をありがとうございました！

kickflowがわかる資料のダウンロードはこちらから