Recruit Tech Blog
社内のローカルツール廃止に向けた取り組み
はじめに
ICT統括室の上原と申します。この記事では、約30年間で蓄積した大量のローカルツール（Access、Excelで作成、以降ツールと表記）の廃止とクラウド化に向けた取り組みをまとめてみました。時間経過と共に増え続ける膨大なローカルツールに課題感を持つ企業は多いと思います。そんな社内IT共通の問題に対するヒントになれば幸いです。
取り組みの背景
リクルートではIT組織が提供する標準的な機能（例えばテーブルを指定して単純に検索する機能、等）を持つツールに加えて、業務内容に応じて事業部門が独自に開発・利用しているローカルツールが1,000個以上存在していました。
元々はこれほどの数ではなかったのですが、長い期間の中で複製や改良が繰り返され、類似機能を持つツールが増えていく状況となっていました。また、すでに開発者が退職・異動してしまい管理者が不在になってしまった結果、誰も仕様を把握してない「ブラックボックス化」や、そもそもツールを使用している業務が無くなっているにも関わらずシステム保守だけが続いている「ゾンビ化」などが進行している状態でした。これらに加えて、Access・Excelは定期的なOfficeやOSアップデートの度に全てのツールで影響確認を行い、必要に応じて改修を加える必要があるため、IT部門だけでなく事業部門にとっても大きな負担となっていました。
上記のような背景の中で、リクルートでは30年利用を続けてきたERPの刷新を進めることになりました。これは汎用機からSAPへの入れ替えになるのですが、当然のことながら新旧システムではアーキテクチャが大きく異なります。ERPをデータソースとして動作するツールを「そのまま使い続ける」という選択肢は取れなかったのです。
何をしたのか
上記を背景として大きく2つの施策を段階的に実施しました。それぞれについて説明していきます。
●ステップ１：不要なツールは廃止する
まずは大規模な棚卸を実施して、ツールの数をとことん減らすことにしました。単純に利用者へ広報しただけでは棚卸が進まず、ツールも減らないため、IT組織が垣根を超えて利用組織に踏み込み、愚直に、泥臭く進めました。
①整理の対象を決める
最初からあらゆるツールを整理の対象にするには量が多すぎたので、まずはERP刷新により影響が出そうな業務範囲に絞りました。ここでは関係あるなしの厳密な線引きはあえて行わずに、まずは関係がありそうな利用組織から声がけをして候補を募りました。結果、整理対象として約1,000ツールを決めることができました。
②ツールの利用状態を調査
データソースへのアクセス履歴などのシステム観点、オペレータの使用有無などの業務観点と二つの方向から攻めてみました。それにより、ツールごとに利用している業務や組織、頻度など様々な情報を得ることができました。
③要否の仕分け
結果を基に業務組織と協働で仕分けを行い、業務上の必要性を判断軸に要否判断を実施しました。難しかった点としては、この時点ではまだ新しいERPの業務内容が固まっていなかったので、断定的な判断が出来なかったことです。とは言え、新業務が決まるまで待っていたら終わりませんので「この時点の解像度でいったん決める」ことを重視しました。その時点より以降に業務内容との相違が生じたら随時変更していくことにしました。結果的にはいったんの決定をしてからも1年以上に渡り、ツールごとの要否判断や仕様が変わり続けましたが、僕らはこれを「手戻り」と呼ばずに前向きに「変化」と捉えています。
④類似ツールの統合
利用継続するツールについてCRUD図やDFD（データフローダイアグラム）を用いてデータとツール間の相関性を可視化しました。これにより、客観的に類似性や重複性などが判断可能な状態となり、業務組織が集約や廃止の判断を下しやすくなりました。これにより結果的にツール数を70個まで絞ることに成功しました。
●ステップ２：必要なツールをクラウド化する
そして、残った必要なツールを新しいERPの考えに合わせて、業務と仕様を見直して、Googleスプレットシート×BigQueryでクラウド化することにしました。
①ツール要件の見直し
新旧ERPではデータ構造が大きく異なります。そのため現在のツールを「そのまま使い続ける」ことができません。また、業務内容にも変更が生じていますので、業務組織と協働して改めて要件の見直しを行いました。
②GoogleスプレッドシートとBigQueryで新ツールを構築
プラットフォームはリクルートの中でも利用者が多く、開発のナレッジが多いGCPを選択しました。また、構造は出来るだけシンプルにしました。BigQueryをDWH、データレイクとしてSAPからのデータを蓄積し、これに業務に応じた70個のスプレッドシートが接続してデータの利活用を行います。
得られた効果
結果として、以下の効果を生み出すことができました。個人的には約30年分の棚卸をすることができた（１）と、現場の負荷を大きく下げることができた（２）は大きな成果だと感じています。（なお、この記事を執筆しているタイミングではツール構築中のため、一部の効果は見込みで記載してします）
（１）ツールの大幅な削減
約1,000個のツールを70個へ集約（約93%削減）することに成功しました。蓋を開けば、すでに廃止された業務用や利用組織が異なるだけで機能はほぼ同じツールなどが多く存在していました。整理に踏み込まずに新ツールを構築していたら多大な期間と投資が必要であったことを考えると、このプロセスを丁寧に進めたことは大きな成果だと思います。
（２）OSバージョンアップ対応からの脱却
クラウド化したことで、ローカルツールで定期的に発生していたOfficeやOSバージョンアップ時の影響確認や改修作業から解放されたことは、IT・業務の双方で大きな負担軽減を実現することができました。
（３）ツール運用のハイブリット化
セキュリティ対策や、バグ対応など全ツール共通で必要な運用はIT組織が担い、業務変更に伴うツール個別の機能見直しは業務組織に委ねることで、それぞれが得意な分野に注力することができるようになります。これにより、業務の見直しなど必要な変化に迅速に対応できる状態を実現します。
（４）開発ナレッジの共有知化
今回、開発した際に得られたナレッジを標準化して社内へ広く展開することで、会社全体のツール生産性を向上させる第一歩を踏み出すことができました。今後は全体のナレッジベースとして成長させていきたいと思います。
成功の秘訣
本当に多くの工夫を重ねましたが、特に大きなポイントとなった以下の4点をお伝えしたいと思います。
役割を超える
何をしたいのかは業務が考える。それをシステムとして形にするのがIT。といった従来の役割分担では、お互いの不得手を補えません。そのため、業務の検討にITも参加してシステムとしての実現性を補完したり、システムの設計に業務も入り、業務観点での妥当性を相互に補完する体制にしました。開始前は仕事が増えそうに見えましたが、結果的には急がば回れで短期間で双方が納得する良いモノを生み出すことができました。
アジャイル的な進め方
新業務の検討と並走してツール開発を進めるため、途中で業務要求内容が変わることを前提におきました。それにはウォーターフォール型の開発では対応できませんので、変化へ臨機応変に対応できるように、アジャイル的な進め方を随所に取り入れました。
成果物は最小限に
いろいろと決まっていないことが多かったので、とにかく業務とIT間のコミュニケーション密度を上げることを重視しました。議論の時間を捻出するために、不要不急のドキュメントなどの成果物はあえて作成しない、もしくは後で作成することを選びました。結果的に使用頻度の低い成果物を惰性で作成することが無くなり、コミュニケーション密度を上げながら、良質で最小限の成果物を作成できました。
標準化で開発生産性UP
複数のチームで分担してツールを開発していたのでナレッジの標準化に拘りました。これにより同じような課題に重複して対応することが無くなり、開発者の時間を有効に使うことで生産性の向上を実現しました。
最後に
いろいろな前提が不確定ななかでも、素早く前進することが求められる難易度の高いテーマでしたが、泥臭く、工夫を積み重ねることで成果に繋げることができました。また、自身のプロジェクトマネジメント手法のバージョンアップにも繋がる良い経験となりました。そして、同じゴールを志す多くの仲間にも恵まれたことも大きな要素だったと思います。
プロジェクトは道半ばですが、今後も固定観念に捕らわれず柔軟に変化を起こしながら、皆で前に進んで行きたいと思います。
最後まで読んで頂きありがとうございました。このナレッジが皆さまの一助になれば幸いです。
このブログを読んでピンと来た方は、ぜひ一度採用サイトもご覧いただけるとうれしいです。まずはカジュアル面談から、という方も大歓迎です。
また、他にも色々な記事を投稿していきます！
過去の記事もご興味あれば、ぜひ他の記事もあわせてご参照ください。
・Recruit Tech Blog
・リクルート ICT統括室 Advent Calendar 2024
・リクルート ICT統括室 Advent Calendar 2023