経費精算デジタル化 Try&Errorを高速で回して解像度をあげるアプローチ

はじめに

こんにちは、ICT統括室の山形です。
前職は公共系システム構築を中心に担うSEでした。超上流工程から携わりたい、ユーザの現状を間近で見てシステム仕様の意思決定をやってみたいと思い、リクルートに転職。現在は、従業員が使用する会計システム複数を保守しながら、以下のようなプロジェクトを推進しています。
・全社戦略に基づく対応
・法令対応
・利便性向上にかかわる対応

 

今回は、従業員約2万人が使用する経費精算システムをDX化した事例を紹介いたします。


従業員の経費精算はまだ紙を使用していた

リクルートは、どんどん新しいものを追い求めるイメージがあるかもしれませんが、実は経費精算にはまだ紙ベースのプロセスが残っていました。例えば、営業職の人々は毎月交通費精算を100件以上必死に入力、上長は印刷された申請書に捺印するため出社、経理は色鉛筆を駆使して1項目ずつチェック等、本来の業務ではないところで負荷があった状況です。
そこで、経費精算をDX化するためにConcur Expense導入プロジェクトが発足しました。


リクルートは挑戦する機会をくれる

少し本題からは逸れて個人的な話となりますが、当プロジェクトには自ら「やりたい」と手を挙げてアサインされました。私は過去に請求支払システムを黒い画面の汎用機からWEB(スクラッチ)に刷新するプロジェクトを推進し導入したのですが、そのすぐ後に決算早期化のため別プロジェクトでConcur Invoiceに刷新となりました。自分が開発を担当したシステムがわずか1年足らずでクローズになった悔しさと寂しさ。しかし一方で、更なる進化をさせたプロジェクトの人々に対して尊敬の念も抱き、次の進化を担う施策は自分でやりたいと思っていました。
※Concur Invoice:コンカー社が提供する請求支払(社外支払)システム、Concur Expense:コンカー社が提供する経費精算(従業員支払)システム


シンプルを志向する

Concur Expenseを導入することでペーパーレス化などのメリットも得られますが、スクラッチシステムからSaaS製品への置き換えになるため、現行と比較すると製品制約でできないことも多くなります。
だからといって、現行業務そのままをSaaS製品でどうにか実現しようとアドオンに時間をかけることは、短期導入がメリットのSaaS製品の良さが失われるため、関係者で以下の認識を合わせました。

◆目標

・いち早く、従業員の経費精算を楽にする
 └浮いた時間を本来の業務にあてられるようにし、全体の生産性向上を目指す
・シンプルを志向
 └製品を最大限活かせるようなBPRを実現し、
  過剰なカスタマイズや現行業務を満たすためだけのサードパーティー製品は基本的に入れない。
  SaaS製品のベストプラクティスにどう合わせられるかを考える。

◆アプローチ
1.SaaS製品の標準を知る

2.現行業務を詳細に理解する
3.標準に合わせるための課題を出し、打ち手を検討


攻めるところを攻めたら、結果それが最大の守りになった

進める上で、特に3つ工夫したことがあります。



攻めポイント①:論点・課題はTry&Errorを高速で繰り返し解像度を高める

SaaS製品の”すぐ設定して確認できる”という特性を生かし、要件定義~システム開発までに、実装と業務検証を5回繰り返しました。

 

主要機能や周辺システムに影響がある論点を優先とし、検証を繰り返す度に徐々に概要→詳細へと解像度を高めていきました。

個別論点の検証で抽出した課題に対して、カスタマイズが必要になる場合、基本方針に基づき、システム対応は必須か?を喧々諤々と議論し、どうしても必要と判断した場合にのみ、カスタマイズを入れています。
課題の打ち手検討に際し、重要なのは最初から100点を狙わず、否定されることを恐れないことです。「原案」「こういう想定」でどんどん意見をぶつけて、議論を活性化することでよりよい最適解を見つけることが可能になると考えています。

 

攻めポイント②:「検証できない」で終わるのではなく、やれる方法を探して実施

「シンプルにする。そのためサードパーティー製品を入れない」の例外としたのが、Suica連携とタクシー連携でした。取り入れたほうがユーザ利便性の面でメリットが大きく、サードパーティー製品ではあるものの導入を決定しています。

しかし、これらはアプリ仕様で開発環境では動かず、前述の業務検証ができないことが分かりました。ぶっつけ本番でユーザー利用に臨むのは、システム品質、業務品質どちらの観点でもリスクです。
そこで「できない」で終わりにするのではなく、どうすれば本番環境に影響を与えずに検証できるかを模索し、最終的に本番環境でも業務検証を実施することにしました。

実際に電車や新幹線、タクシーに乗って検証をしています。たとえ本番環境でも、他の論点と同様に検証→課題抽出→打ち手検討のサイクルを回すことをしたのです。

 

攻めポイント③:本番切替は事前移行フェーズを入れることでリスク低減

本番環境でも既存業務への影響を出さずに解像度をあげる、リスクを低減する打ち手を模索するという考え方は、本番切替にも展開できました。周辺システムとの連携含めて、既存業務影響有無の観点で「事前移行」と「本番移行」に移行タスクを切り分け、本番移行のタスクを極力減らし、事前移行で想定外事象を潰しこむことでリスクを低減させることができました。

 

このような「シンプルにする」ことを前提に「検証→課題抽出→打ち手検討」を何度も繰り返したことは、見方を変えれば石橋を何度も叩くような最大の守りにもなったと考えています。


導入したら終わりではなく改善を繰り返す

これで終わりと思いきやそうではなく、導入後の懸念が一つありました。
ユーザの利用展開は部署ごとに段階的に行い、順に使用後の感想をアンケートで取得していました。アンケートでは、慣れの問題もあってか、操作の分かりにくさに関する意見を受ける状況でした。利用展開に伴い、課題を感じる人が広がることを思うと、早急に打ち手を考える必要がありました。本来の業務ではない部分に負荷がかかり、全体の生産性に影響すると考えたからです。


ここで困っていたら助けてくれるのがICT統括室の人々の良さです。製品仕様は変えられないためUX観点で改善を図るのですが、ICT統括室広報G、WEBデザインGと協同しながら取り組むことができました。

スムーズな経費精算に向けて、どこに負があるのか仮説を立て、既に作成済みのユーザマニュアルやポータルサイト、よくあるQAなど、全面的にリニューアルをかけました。
そのかいあって、Concur Expense導入後、大きな混乱なく稼働しています。中には「交通費精算が楽になった!」という声をいただくこともありました。


最後に

リクルートにはWill(やりたいこと)をオープンにすれば何かの機会に挑戦させてくれる環境があります。
挑戦するときに、不安なのも正解が分からないのもみんな一緒です。
今回は、間違うことを恐れず、周囲を巻き込みながらTry&Errorを高速で回し、論点の解像度を上げることで、早期に不確実性を解消することができました。
また、システム仕様もUX改善も、仮説と検証を繰り返して決めましたが、なんとも悩ましい案を採用したものもたくさんあります。本番稼働後の実績データ、従業員の声が、私たちにとって一番のフィードバックになるため、継続して改善していきたいです。そしてそれが、結果的に従業員の生産性向上につながり、リクルート全体の貢献につながると信じています。


 

このブログを読んでピンと来た方は、ぜひ一度採用サイトもご覧いただけるとうれしいです。まずはカジュアル面談から、という方も大歓迎です。

キャリア採用サイト 募集職種一覧

カジュアル面談フォーム

 

また、他にも色々な記事を投稿していきます!

過去の記事もご興味あれば、ぜひ他の記事もあわせてご参照ください。(リクルート ICT統括室 Advent Calendar 2023