2024.12.21

クラウドシフトによるDX推進：ユーザー、開発者、運用者の3つの「不」を解決した話

はじめに

こんにちは。ICT統括室の越智です。
私はもともと複合機のメーカーで上流工程のSEとして、さまざまなソリューションでお客様の課題解決を支援してきました。その過程で、複雑な業務課題を解決することに魅力を感じ、現在社内SEとしてリクルートのICT業務に携わっております。

リクルートでは、不満、不便といった社会の「不」を解消することを意識してサービスを作り上げており、私もその考え方に共感しました。今回は私もそれに倣い、社内ICTという枠組みの中で、社内のユーザー、開発者、運用者の「不」を解決することを目的に取り組んだプロジェクトの事例を紹介させていただきます。

Accessツールの課題とクラウドシフトの目指すところ

社内業務で長年使用されてきたAccessなどの多くのレガシーツールは、業務プロセスの属人化、ビジネスロジックのブラックボックス化、OS依存によるメンテナンス負担など、さまざまな課題を抱えるようになりました。
具体的には、業務プロセスがツールによって属人化することで、業務全体の可視化が困難になり、標準化を進めることが難しくなっていました。開発に関しても、ツールの中身がブラックボックス化してしまっていることで、軽微な開発でもコストがかかることや改修に対応できる技術者も年々減ってきていることが課題になっていました。さらに運用もWindowsのアップデートなどのクライアントOSの環境変化に伴う影響調査や軽微な改修作業が必要になっています。

そこで、Accessツールのクラウドシフトを実施することで、アーキテクチャを根本から変え、長年抱えていた課題の解決に取り組むことにしました。
具体的には、Googleの製品、スプレッドシート、Google Apps Script（GAS）、BigQueryを活用し、以下の3つの観点から課題解決を目指しました。

ユーザー視点での業務効率の向上
ツールを見直し、必要な機能の整理・可視化を行い、業務改善を可能にする
開発者視点での技術的負債の解消
クエリなどの内部ロジックの可視化により、迅速に改修が可能な状態にする
運用者視点での維持管理コストの削減
クラウド製品導入により、OS依存に伴うタスクを解消し運用負荷をさげる

ユーザーの「不」：業務プロセスの属人化による改善の停滞

Accessツールは長年にわたり特定の業務プロセスと密接に結びついていたため、ユーザーがそのプロセスを変えるということは非常に困難になっており、ツールの利便性が低くても改善の検討は進まない状況にありました。そのため、ユーザーの体験価値を毀損せずにツールの属人化を脱却し、プロセスの可視化が容易な状態を目指しました。

まずはAccessツール群を解析し、「機能の見える化」を行いました。具体的にはAccessの機能を汎用的なシステムフロー図に落とし込み、Accessの機能やデータの流れを可視化しました。その中で共通項としてまとめられる機能を業務単位で整理し、機能のインテグレーションを進めました。アーキテクチャが抜本的に変更になりましたが、結果としてユーザーのツールを用いて行う業務プロセスはほとんど変わることがなかったため、ユーザーには抵抗なく受け入れてもらうことができました。また、長年ブラックボックスになっていた機能も整理された状態でまとめることができたため、プロセスの改善の検討も容易な状態にすることができました。

開発者の「不」：ブラックボックス化したロジックの改修負担

Accessツールでは、当時の業務ロジックが数多く埋め込まれていたため、時代の流れと共にシステム保守の負担となっていました。具体的には数十から百以上の複雑なクエリが実装されており、それらの用途含めブラックボックス化されていました。その結果、機能の追加1つとっても調査に時間がかかり、簡単な改修にも時間がかかっていました。そのため、クエリを始めとした機能改修に大きく関わる要素を可視化し、容易に改修できる状態を目指しました。

対策として、ブラックボックス化していたクエリなどの機能は、スプレッドシートにパラメータ化させて実装しました。特に各機能で汎用的に使用する部分をGASを用いて部品化させ、可読性や拡張性を向上させました。結果として、機能改修に大きく関わる可変要素をパラメータ化できたことで、スプレッドシートを見ればどのような機能が実装されているか容易に把握できるようになりました。また、部品化された機能は、新規に流用はもちろん、個別にメンテナンスや改修が可能となり、改善のスピードが大幅に向上しました。

運用者の「不」：OS依存によるコスト増とメンテナンス負担

AccessはWindowsで動作するクライアントOSに依存するツールのため、定期的なOSのアップデートのたびに動作確認や修正作業が必要でした。この作業ではユーザー調整、パートナー管理、予期しない不具合の対応も含め、多大な時間とコストがかかっていました。そのため、Accessで必要な機能は全てクラウドの製品に置き換えることが重要な要素となっていましたので、クライアント側に機能を持たせない状態を目指しました。

AccessのU/Iやクエリといった機能に関しては、スプレッドシートとGASで充足することができました。しかし、Accessは内部で独自のテーブル（ローカルマスタのようなもの）を持っており、そのデータソースも併せてクラウドで管理できるようにする必要がありました。そこで、BigQueryでAccessのテーブルも管理できるように移すことで、全ての構成要素をクラウド製品で充足させることができました。
クライアントOSから脱却できたことで、クラウド環境での一元管理が可能となり、維持管理コストの削減も実現できました。また、OSアップデートに対するユーザー調整などの負荷がなくなり、運用者は本来の業務に注力できるようになりました。

まとめ

本プロジェクトでは、Accessツールからスプレッドシート、GAS、BigQueryへの移行を通して、業務プロセスの合理化と運用効率の向上を達成しました。また、ユーザー、開発者、運用者の3つの「不」を解決したことで、次のような効果を得られました。

業務効率の向上
ユーザーが業務プロセスの全体像を把握できるようになり、日常の業務改善を進める土台が整いました。見える化された業務フローにより、非効率な部分が明確となり、業務のスピードアップにもつながりました。

開発・改修の迅速化
クエリのブラックボックス状態が解消され、メンテナンスがしやすくなりました。開発者は必要なロジックを部品単位で扱えるため、開発サイクルが短縮され、機能追加や改修に迅速に対応できるようになりました。
運用コストの削減
OS依存から脱却したことで、アップデートに伴う予期せぬトラブルが減り、運用者の手間も軽減されました。また、コスト面でも、運用環境の維持費が減少しました。