ケーススタディ

業務監査の道具とUXをヒト起点でリデザイン

監査室で長年使っていた道具を見直してユーザー体験を一新することにより作業時間を1/3に削減

クライアント

監査室は、 “経営者の代わりとなって、会社の経営上のリスクを発見する” という役割をもった、社長直轄の組織です。“経営上のリスク”とは、会社が “不利益になる” や “信用を落とす” 等の結果になりそうな “従業員の行動” のことで、監査室ではこのリスクを発見するために社内の様々なデータを調査しています。

背景

監査室では、リスクの多様化、従業員の行動の変化に伴い、監査室が調査する内容や基準もそれらの変化に適応させるよう取り組んでいます。業務効率の面では、調査する内容や基準が一律であることが望ましいのですが、一律チェックに抜け道があった場合にリスクを発見できません。そのため、監査室ではある程度の基準を設けながらも、“ヒトが判断する”ということも大切にしていました。

しかしながら、ヒトが判断する過程で “人手による作業” が発生してしまい、「余分だと思われる作業（手間）による物理的・心理的な負担（ストレス）」と「個々人のスキルや経験の差」が作業や判断のクオリティに影響を与えているという課題がありました。

テーマ

そこで、デジタルを適切に活用することで、監査業務における “人手による作業” の摩擦点（※2）をなくすことができないだろうか、というチャレンジが始まりました。

※2 摩擦点（Friction Point） … ユーザー体験上の抵抗や摩擦のことであり、ユーザーに混乱や迷い、余分な手間をかけさせストレスを与える体験

そして、監査室における監査テーマ（監査対象）は様々ありますが、すべての監査室メンバーが関与している “業務監査（受注／売上／原価を対象とした監査）” に焦点を絞って始めていくことにしました。

リサーチ

「監査室の人々が業務監査をどのように捉えているのか？、その目的や絶対に譲れない部分は何か？」を理解することが、新しいユーザー体験を作っていく上で核および指針となっていく部分です。また、「業務フローには現れないくらい細かいことだけれども、監査室メンバーが実際に行っている作業は何か？、どのような状況で作業しているのか？、その作業の意味や作業に対して感じていることは何か？」、これらを理解することが、摩擦点を特定するために必要となります。

プロジェクトチームは、監査室メンバーの中で、監査室での経験が長い人と短い人、監査室に来る前の職種が営業の人とエンジニアの人など、それぞれ特徴や価値観が異なる人とのインタビューを通して、 “業務監査をする人” のインサイトを発掘していきました。

インサイト

リサーチから見えてきたのは、業務監査の工程には不合理や矛盾等はなく、非常にシンプルかつ合理的に整理されていること。そして、拠点への指摘事項（経営上のリスクになりそうな事象）を発見するまでの行動は監査テーマごとに異なるが、拠点へ指摘事項を発見した後はどの監査テーマでも同じ工程となっている。

また、さらに作業レベルまで分解していくと、複数の無駄な作業が発生しており、その作業が業務上のリスクとユーザーのストレスの要因になっていることも見えてきました。そして、その原因は「今の道具を使うと、どうしても無駄な作業が発生する運用になってしまう」という点にあることがわかりました。

コンセプト

リサーチで得たインサイトを元に、プロジェクトチームでは業務の大きな流れは変えないが、道具を根本から変えることで、発生する作業を全く新しいものにするコンセプトを創りました。

業務監査の業務には「①案件の調査」「②指摘要否の判断」「③拠点へ質問」「④指摘の通達」という工程があります。監査室では、表計算ソフトを使用して、それぞれの工程で必要なデータを、工程ごとに異なるシートを作成して管理していました。

そのため、例えば “受注No. ” や “顧客名” などの複数工程で必要になるデータも、その都度、前工程のシートや元データが登録されているシステムから当該工程のシートに手入力する必要がありました。取り扱う件数が多く、データの項目数も多いため、作業する上での負担やストレスになるだけでなく、入力／転記ミスや既存データの誤った上書きというリスクになっていました。

そこで、それぞれの工程で管理しているシートを一元化することで、「前工程で入力したデータを参照でき、その工程で発生したデータのみを登録する」というユーザー体験とアプリケーションをデザインしました。

検証

デザインしたコンセプトは、あくまでプロジェクトチームによって創られたアイデア（仮説）であるため、本当に効果があるのか、ユーザーに受け入れられるのかを、早い段階のうちに適切なコストで検証する必要があります。

プロジェクトチームは、 “効果の実証” という観点から「作業時間は減るだろうか？（定量）」「誤入力件数は減るだろうか？（定量）」「作業中のストレスは減るだろうか？（定性）」を、 “ユーザーに受け入れられるか” という観点から「道具の変化への抵抗感はないか？（定性）」「業務は遂行できるのか？（定量）」を検証することにしました。

ユーザーに実際に作業してもらい計測する必要があるため、検証するために必要最低限のプロトタイプを作成しました。ユーザーには、旧来の表計算ソフトによる作業と、プロトタイプによる作業を行ってもらい、定量項目の測定と定性項目のインタビューを実施しました。

検証の結果、作業時間は約1/3（※3）になり、誤入力件数も0件、抵抗感やストレスも無く、業務も遂行できるということを実証することができました。

※3 ユーザーテストにおけるデータ3件の作業時間が 45min から 15min に削減した。2022年度の業務監査件数250件での作業時間を試算すると 87h が 30h に削減する。

さらには、ユーザーはプロジェクトの成果を受けて、「自分たちの業務を変えていける」ということに対し自信と期待をもつことができました。

Next Step 共創プロジェクト終了後の活動

コンセプトの検証により、プロジェクトチームにてデザインした道具とユーザー体験がユーザーに受け入れられ、業務における効果があることを実証できたため、プロジェクトはここまでで完了となりました。

プロジェクト終了後は、監査室と技術本部で協力しながら実運用に向けたアプリケーションを設計・開発するように進めていく予定となっています。

監査室長コメント（一部抜粋）

• プロジェクトの成果が、検証結果と検証のためのプロトタイプだということを理解した上でも、スピード感がよかった。もうちょっと時間かかるのかな？と思っていたが、当初のアライメントで約束した期間内でスピード感を持って成果をだせたのがよかった。
• 監査室と共に課題を見つけていくという、やり方自体は良かった。インタビュー結果を踏まえて課題を見つけてくれたので納得感があり、ズレも感じなかった。
• こっちから話したことを、次の機会でちゃんと反映していることはよかった。それがあると「確かに言ったな」と納得できた。それを提示した上で、提案されると提案内容に納得できる。その流れは非常によかった。
• Midphase（中間レビューおよび検証するコンセプトを決定するイベント）で「こういう検証結果が欲しい」「アウトプットとしてここまで欲しい」という意見を踏まえて、提案してくれたので納得できた。
• 今後に関しては、既に関係各所と見積もりの件や、使用したいAPI等の件で話を進めている。