ないなら組み合わせてみる!ユーザ利便性追求のためのSaaS API活用
はじめに
こんにちは、ICT統括室の佐田です。
リクルート従業員が使用する申請システムの運用やエンハンス業務を担当しています。
本記事では、申請システムの運用・エンハンスを行なっていく上で直面した課題の解決方法について紹介させていただきます。
申請システムって?
会社で働いていると様々なものが必要になると思います。
例えば、社用PCやプリンタ、スマートフォン、会社用のIDやメールアドレスなどです。
上記のような社内のICTサービスを利用するための申請、上司による承認、ICTサービスの手配などを一連のワークフローで構築したものを申請システムと呼んでいます。
SaaS利用時に直面する壁
SaaSを利用してシステム構築をしていると、ユーザからもっとこうしてほしいという声をいただくのにSaaSの標準機能にないため実装を見送る事があると思います。
SaaSベンダーに機能追加をリクエストしても、他機能との兼ね合いなどで追加が難しいと返答いただくこともありますよね。
私が運用していたシステムでも、SaaSへ移行した際に上記の問題に直面しました。
今回は諦めずにSaaS APIの組み合わせを模索した結果、ユーザ利便性を落とさず提供したい機能を実現した 申請の自動作成機能 の取り組みについて深堀って行きたいと思います!
こんなかたにおすすめかも!
SaaSを利用したシステム構築をされている方
申請を自動作成したい…!
そもそも申請を自動作成する、とは?
以下の図のようにユーザが申請する手間を省き、システムがユーザに代わって申請を作成/項目を埋めて後続処理を実施することを「申請を自動作成する」と表現しています。
ユーザからすると申請が自動作成されると何が嬉しいの?
例えば社内の様々なサービスを利用していたユーザが退職する際に、すべてのサービスの削除申請を上げることはユーザにとって大きな負担になってしまいます。
各部署でユーザごとに利用しているサービスを細かに管理してもらい、退職が発生した際には削除申請を出してもらったり、各サービスの運用担当者が利用権限をこまめに棚卸しすることもできますが、煩わしさが生まれてしまいます。
社内システムは縁の下の力持ちです。システムでできることは自動で実施し、ユーザには本来の業務に注力できる環境を提供する必要があります。
そこで私が担当しているシステムでは、毎日UPDATEされる人事情報を元に退職者を抽出し、該当ユーザの利用サービスの削除申請を自動で作成するという機能を作成したいと考えていました。
そのためには思考と手を止めるべきではないと考え、打開策がないかSaaSのAPI仕様書を読みこむ旅が始まりました。
実装してみた
システム保守の観点からシステムを作り込んで実装することは避けたい、システム構成はシンプルにしたいという強い思いもあります。
SaaSのAPI仕様書を読み込んで、この機能とこの機能を組み合わせれば…!のtry&errorを繰り返し最終的に2種類の申請の自動作成機能を実装しました。
① 日次バッチでの申請自動作成
-
人事情報から退職ユーザを検知
-
退職ユーザに利用サービスがあるか確認
-
存在する場合、削除申請を自動作成
② 申請起因での自動作成(サービスAの削除申請をキックにサービスBの削除申請を作成する)
- サービスAの削除申請をユーザが申請
- Aに紐づくサービスBを保持している場合、サービスBの削除申請を自システムにて自動作成
- サービスA、サービスBの申請情報をあわせて他システムへ連携
実際にSaaS REST APIのどんな機能を組み合わせたのか
担当システムでは申請画面やワークフローにSmartDBを利用しているため、ここから先は具体的にSmartDBのREST APIを利用してどのように申請の自動作成を実装したかお話しようと思います。
① 文書新規登録API を利用し、申請書を作成
このタイミングでは申請書の中身は空で、申請書の外側だけを作成します
② ビューの文書一覧取得API を利用し、申請書の中身を作成
どの利用者の何のサービスを削除するのか、①で作成した申請書の中身を作るために必要なID情報などを取得します
③ リスト型部品の行新規登録API を利用し、申請書の中身をUPDATE
②の情報をもとに申請書の中身の更新を行います
④ 業務プロセス開始API を利用し、申請ワークフローを開始
作成した申請書の申請ワークフローを開始します
申請の自動作成時に①〜④の処理を組み合わせることで、ユーザが申請したとき同様の申請ワークフローを流すことができます。
SaaSでのシステム構築を通しての学び
SaaSはシステム運用・管理の負担が比較的軽く、導入期間が短いことがメリットです。
一方で、カスタマイズの自由度が低く機能がないと言われたら諦めるしかない、申請システムでSaaSを利用し始めるまで私はそう思っていました。
ただ今回の件を通じてSaaSが提供している機能を正しく把握し、使い道を探ることで標準機能になかったとしても、工夫次第で機能提供を行えることを学びました。
手を止めずにユーザ利便性を追求したからこそ、打開策を見つける事ができたと思っています。
これからもリクルート従業員の縁の下の力持ちとして、ユーザ利便性 × シンプルを両立したシステムの構築を目指していきます。
最後に
ここまでお読みいただきありがとうございました!
社内システムは普段あまり脚光が当たらない部分ではありますが、ひとたび稼働が止まると全従業員の業務に影響が出てしまう、なくてはならないシステムだと思っています。
私の所属するグループでは、リクルートの全従業員が利用する申請システムをより利用しやすくするためのエンハンス開発や、安定稼働を行うための運用改善などを今後も積極的に実施していきたいと思っています。
このブログを読んでピンと来た方は、ぜひ一度採用サイトもご覧いただけるとうれしいです。まずはカジュアル面談から、という方も大歓迎です。
また、他にも色々な記事を投稿していきます!
過去の記事もご興味あれば、ぜひ他の記事もあわせてご参照ください。
・Recruit Tech Blog
・リクルート ICT統括室 Advent Calendar 2024
・リクルート ICT統括室 Advent Calendar 2023