2025.08.25

「やらない理由」を覆せ！「手触り感」を原動力に、積年の課題を解決できた秘訣

安藤洵

はじめに

はじめまして！ICT統括室の安藤と申します。

　「もっとユーザーに近い場所で、価値を提供したい」

　「自身の仕事の成果を、よりダイレクトに感じたい」

こんな考えを巡らせたことはありませんか？

今回は、「社内ICTの仕事を通じて得られるやりがい」について、お伝えします。

自己紹介

私は、2010年にSIerへ新卒入社しました。

アプリ開発からインフラ基盤までを幅広く担当し、後半はプロジェクトマネジメントにも携わりました。

SIerのビジネスモデルは、顧客の意向がプロジェクトの意思決定に大きく影響します。

顧客のニーズを深く理解し、実現することは、前職でのたいへん貴重な学びでした。

一方で、ニーズの探索や課題設定、フィードバックの獲得など、ユーザーとの直接的な接点が多い環境で働きたいという想いが強くなってきました。

そこで、2022年にリクルートの社内ICTへ転職し、現在に至ります。

リクルートでは、複数の社内向けシステムの運用保守を担当しています。

ここからは、そのうちのひとつである、会議室予約システムでの経験をお話しします。

ユーザーの不満

ICT統括室では、半年に一度、リクルートグループの社内各部門および関連会社を対象に、社内向けシステムの満足度調査を実施しています。

その中で、会議室予約システムの満足度は60パーセントほどと、決して高くはない状況でした。

主に挙げられていた不満は、以下の2つです。

Outlookに遷移するのが煩雑
予約完了までの反映が遅い

調査当時は、空き会議室をシステム上で探した後に、Outlookカレンダーを経由して予約しなければなりませんでした。

私自身もユーザーであったため、こうした不満は非常に腹落ちでき、「これは絶対に解決すべき！」という確信を持っていました。

課題を紐解くと・・・

「Outlook遷移」や「予約反映」は一見すると、画面操作を改善すれば解決できる、UI/UX課題です。

しかし、詳細を紐解いていくと、それぞれの課題に表面的な対応をしても頭打ちになりそうだということがわかりました。

例えば、ユーザーに「Outlook遷移」をさせていたのは、「予約者が誰か？」を特定したかったから。

会議室予約システムにログイン認証機能が無いことが要因でした。

一足飛びには解決できず、抜本的な対応が求められました。

そこで、根本的にシステム方式から見直して、以下の3つに1年がかりで取り組むことを決断しました！

EntraID認証の実装
ログイン認証基盤の導入により、Outlook遷移不要の世界へ
DB処理のアーキテクチャの刷新
「Outlookカレンダー登録→システムDBに同期」という処理順番を、「システムDB登録→Outlookカレンダー登録」へ大転換
OutlookのAPIを利用した画面開発
予約画面からOutlook APIを実行するよう改修
同時にデザインも刷新し、スマホUIにも対応

「やらない理由」との闘い

取り組みを推進していく中で、次々と障壁が現れました。

そもそも、なぜやるのか

ユーザーの不満は理解できるものの、予約機能自体に問題はありません。そのため、まずはチームメンバーに「なぜやるのか？」を説明する必要がありました。

そこで私は、顕在課題の解消だけではなく、その先に広がる構想も語りました。例えば、ログイン認証により、ユーザーごとに検索条件の保持や表示制御ができるようになります。「忙しい営業さんが、よく使う会議室をワンクリックで予約できるようになる！」といった未来を語り、チーム内での機運醸成に努めました。
投資承認
業務上の緊急性は高くない開発に対し、どうやって承認を得るか？という壁にもぶちあたりました。

決裁ボードメンバーに対しては、取り組みを遂行することで、不満の大半が解消できることを投資対効果として説明しました。一足飛びには解決できない問題であるため、課題と打ち手の構造を整理し、ステップを踏んで対応していくことの説明に注力しました。また、チームメンバーへ語ったことと同様で、将来的なエンハンス例もアピールすることで、未来に対する基盤整備であることも認識してもらえたと考えています。
ユーザー影響
影響調査をしたところ、追随できない関連会社が一定数、存在することが明らかになりました。既存環境を縮小して並行稼働せざるを得ません。

開発チームと何度も議論し、切り替え時のリダイレクトなど、ユーザー影響を極小化できる環境遷移計画を立てました。その上で、関連会社担当や社内広報と密に連携し、「いつ」「誰に」「なぜ」「何を」してもらわなければならないのか、利用者に応じた周知を実施しました。

綿密な環境遷移計画と事前周知のおかげで、大きなハレーションもなく安定稼働に移ることができました。
自身の知識/経験不足
抜本的な方式変更をリードするためには、高度な技術的知識や経験が必要でした。私は、自身の不足を補うために、社内アーキテクト組織に壁打ちをさせてもらいました。

環境遷移やシステム方式のあるべき姿について、わからないなりに図に起こしたり、言語化したり。壁打ちを経て、徐々に解像度を上げることができました。複雑な概念も、自分の言葉や図で表現することで、理解が深まりました。また、こうしたプロセスがあったからこそ、投資決議やセキュリティレビューなどの場において、自信を持って説明/交渉し、承認に繋げることができました。

「手触り感」が原動力に！

今回の取り組みは、「できたら良いが、対応しなくても問題は発生しない案件」でした。
その対応の重さから、積年の課題となっていたことにチャレンジした、とも言えます。

そんな中、粘り強く課題解決を推進できたのは、私自身がユーザー満足にコミットできたからだと自負しています。

身近な同僚のみならず、自分自身もシステムユーザーであり、「これは嫌だ」、「こうなったら嬉しい」というユーザーの生の声や、手触り感のあるニーズ把握が自分のモチベーションになりました。

手触り感に関して、私が心に残っているエピソードをひとつ挙げます。

今回の機能をリリースする直前に、普段から会議室予約システムを使い倒してくださっている庶務の方々に、お試しをお願いしました。
庶務のみなさんから率直なフィードバックや後押し/応援の声をたくさんいただけたことで、リリース前に機能をブラッシュアップし、「これならイケる！」という手応えを得ることができました。
声をかけやすいところにユーザーがいる、という社内ICTの良さが出た場面だと思います。