既存システムリプレイスにおけるユーザー中心設計のリアル

はじめに

こんにちは！RSSでデザイナーをしているS.A.です。
現在、私たちのチームは大規模な既存システムのリプレイスプロジェクトに取り組んでいます。このプロジェクトでは、ユーザー中心の設計（UCD）の考え方を取り入れました。開発手法にはLeanXPを採用しています。

私たちは日々、様々な壁にぶつかり、試行錯誤しながら、プロジェクトを進めています。今回は、そんな私たちのリアルな経験の中から、特に大変だった課題と、それに対する具体的な改善アプローチ、そしてそこから得られた学びや成果についてお話ししたいと思います。

私たちの奮闘記が、同じように複雑な課題に立ち向かっている開発チームの皆さんや、これからユーザー中心のアプローチを始めようと考えている方々にとって、少しでも何かのヒントになれば嬉しく思います。

背景

私たちのチームがリプレイスしているのは、大規模な既存システムです。
システムはお客様にご利用いただく部分と、社内の業務を支援する部分から構成されます。この現行システムは、長年ウォーターフォール型の開発プロセスで構築されてきました。しかし、その結果、業務フローの変化の速さに対応することができず、ユーザへの価値提供の遅れや、ユーザのシステム離れといった課題を招いていました。

目的

本プロジェクトの目的は、ユーザーの生産性を向上させることです。作って終わりではなく、業務の変化の速さにも対応し、ユーザに使い続けてもらえるシステムを開発します。また、チームとしてUCDとLeanXPの手法を実践し、成長していくことも重要な目的の一つです。

課題

しかし、プロジェクトはうまくいくことばかりではありませんでした。特に「既存システムのリプレイス」という状況が、特有の難しさをもたらしたように感じています。直面した主な課題は以下の通りです。

課題1：チームのアジャイル導入初期の壁

私たちの会社では、これまでウォーターフォール型の開発プロセスが主流でした。そのため、UCDを実践するために導入した多くのプラクティス（ユーザーインタビュー、ペルソナ作成、カスタマージャーニーマップ、ユーザーストーリーマッピング、レトロスペクティブ等）は、チームメンバーの多くにとって初めての経験でした。

• 新しいプラクティスへの順応： プロジェクト開始当初は、聞き慣れない用語や新しい会議体の連続でした。それぞれのプラクティスが持つ目的や効果的な進め方を理解し、チームとしてスムーズに実践できるようになるまでには、外部の専門トレーナーさんによる手厚いサポートを受けながらも、一定の学習期間と試行錯誤が必要でした。
• 進捗が目に見えにくいことへの戸惑い： 「ユーザーに早く価値を届けたい」という思いとは裏腹に、新しいプロセスへの適応や、前述のスコープ定義の難しさなどから、プロジェクト初期はなかなか目に見える進捗を実感しにくい時期がありました。「本当にこの進め方で大丈夫だろうか」と不安を感じる瞬間もありました。
• オープンなコミュニケーション文化の醸成： UCDを効果的に進める上で、チーム内の率直なコミュニケーションは欠かせません。しかし、「こんな初歩的なことを聞いてもいいのだろうか」「この懸念を伝えたら、チームの雰囲気を悪くするかもしれない」といった心理的なハードルが、当初は少なからず存在していたように感じます。心理的安全性をいかに確保し、誰もが気兼ねなく意見や疑問を口に出せるようにするかが課題でした。

課題2：スコープ定義の難しさ

リプレイスプロジェクトでは、まず既存システムの現状を把握し、新システムで何を実現するのか、あるいは実現しないのかを明確にする必要があります。これが、想像以上に一筋縄ではいきませんでした。

• 顧客向け画面における要求の複雑性： 例えば、外部のお客様にご利用いただく入力画面。新しいシステムでは、よりシンプルで使いやすいUI/UXを目指したかったのですが、ビジネスサイドからは「この項目はどうしても業務上必要で…」といった要望も多くありました。結果として、既存システムから項目数を約2割削減するに留まり、それでも8画面に渡る入力フォーム群となりました。ユーザビリティ向上と、業務上の必須要件とのバランスを見つけるのに非常に苦労しました。
• 社内向け画面における制御の複雑化： 一方、社内ユーザーが利用する画面では、業務ステータスが12種類も存在するという状況がありました。それぞれのステータスに応じて、入力項目の必須/非必須を切り替えたり、特定の操作ボタンを有効化/無効化したりといった画面制御が非常に複雑になり、これが開発工数だけでなく、ユーザーストーリーやテストケースの洗い出しの工数の増大にも繋がりました。
• 初期データ制約のバランス： 特に社内ユーザーが扱うデータについては、「最初から入力制約を緩く設定してしまうと、予期せぬデータが登録され、後々のデータ整合性に問題が生じるのではないか」という懸念がありました。そのため、「まずは厳しめに制約をかけておき、ユーザーから具体的な利用シーンに基づいて『ここが使いにくい』という要望が強くなったタイミングで緩和する」というアプローチを取りました。しかし、この「適切な厳しさ」の塩梅や、「いつ、どの程度緩和するか」の判断には、継続的な議論が必要でした。
• MVP（Minimum Viable Product）設定における本質の見極め： LeanXPの重要なプラクティスの一つが、MVPを設定し「小さく作って、早く価値を届ける」ことです。一般的にリプレイス案件では、「既存システムで提供されていた機能は、新しいシステムでも当然使えるべき」という暗黙の期待が存在しがちです。しかし、今回の私たちのプロジェクトでは、幸いなことに社内のユーザーやビジネスサイドから「今の業務に本当に必要なものだけに絞り込もう！既存の余計な機能は、この際ばっさり整理して問題ない」という、非常に協力的で前向きな後押しがありました。このおかげで、大胆な機能削減の可能性が広がった一方で、「では、本当に必要な最小限の機能とは何か？」を特定する作業は、また別の難しさを伴いました。「この機能がなくなったら、本当に業務は停止してしまうのか？ユーザーは具体的に何に困るのか？」といった問いを一つ一つ突き詰めていく必要があり、大幅な取捨選択の自由があったからこそ、その判断の責任と本質を見極めることの重要性を痛感しました。

課題3：情報共有の課題

アジャイル開発はドキュメントを全く作らないわけではありませんが、その種類や管理方法はウォーターフォール開発とは異なります。私たちのチームでも、効果的な情報共有のあり方については、多くの試行錯誤がありました。

• ツール間の情報分散： ユーザーインタビューの議事録や考察はスプレッドシート、ブレインストーミングや議論の過程はオンラインホワイトボード（FigJam）、UIデザインのプロトタイプはFigma、といった形で、目的に応じて複数のツールを使い分けていました。これは各ツールの得意分野を活かせる反面、情報が分散し、「あの時の議論の結論って、どこを見れば分かるんだっけ？」「このUIデザインの背景にあるユーザー調査の結果は？」といったように、必要な情報へのアクセス性が低下する場面がありました。
• 「最新版はどれ？」問題と認識のズレ： 特にUIデザインのように頻繁に更新が繰り返される成果物の場合、チームメンバー間で「現在参照すべき最新版がどれなのか」という認識が揃わないことがありました。また、口頭での情報伝達や記憶に頼った作業が、後になって認識のズレや手戻りを引き起こす原因となることも経験しました。

解決策

上記のような一つ一つの課題と向き合い、チームで知恵を出し合いながら、少しずつですが改善を進めてきました。ここでは、実際の取り組み内容をいくつかご紹介します。

改善1：スコープコントロール

前述の通り、特にスコープ定義は大きな課題でした。これに対して、私たちは以下のようなアプローチで少しでもコントロールしようと試みました。

• 「これがなくなったら、本当に困る？」を合言葉に： MVP（Minimum Viable Product）を定義する際には、関係者一同で「この機能がなかったら、本当に日々の業務は回らなくなるのか？優先度を下げられないか？」という観点で検討しました。最初は、前向きに協力してくださるユーザさんが望むものを全部作ってあげたい！という気持ちでしたが、全部詰め込むと仕様が複雑になったり、開発工数が増えたりして、リリース日が遅くなってしまいます。本当に必要なものを早く届けるために、MVPを定義しました。
• 初期の入力制約は「厳」から「緩」へ： 社内ユーザー向けデータの整合性を保つために、初期の入力項目に対する制約はあえて厳しめに設定しました。その上で、実際の運用が始まり、ユーザーから「ここが使いにくい」「この制約は業務実態に合わない」といった具体的なフィードバックが出てきた段階で、必要な箇所から段階的に制約を緩和していく、というアプローチを取りました。これにより、無用なデータ不整合リスクを抑えつつ、実態に合わせた柔軟な対応を目指しました。また、この厳格な初期制約がユーザーの負担にならないよう、あらゆる入力パターンを想定して、バリデーションを多数用意しました。さらに、エラーメッセージの内容やアラートの色にも複数のパターンを持たせ、ユーザーが次に何をすべきか直感的に理解し、操作に迷わないような設計を心がけました。

改善2：チームの心理的安全性を育み、学習を加速させる

UCDを効果的に進める上で、チームメンバーが安心して意見を言え、失敗を恐れずに挑戦できる「心理的安全性」の確保は、まさに土台中の土台です。私たちは、以下のような取り組みを通じて、少しでも風通しの良い、学習しやすいチームを目指しました。

• 外部の専門トレーナーによる強力な伴走支援： これは本当に大きかったです！
  • 丁寧なウォークスルーと「なぜ？」の問いかけ： 私たちが作成した成果物（例えばUIデザイン案やユーザーストーリー）に対して、トレーナーさんは一つ一つ丁寧に目を通し、「ここはなぜこういう表現にしたの？」「この機能の背景にあるユーザーの課題って何だっけ？」といった的確な質問を投げかけてくれました。これにより、私たち自身も気づいていなかった暗黙知が掘り起こされたり、メンバー間の認識のズレが早期に解消されたりしました。記憶頼りで進めてしまいがちな部分を、客観的な視点で補強してもらえたのは非常に助かりました。
  • 実践的な「整理の枠組み」の提供： 例えば、ユーザーインタビューの結果をどのように整理し、そこから「ニーズ」と「事実」を抽出して次のアクションに繋げるか、といった部分で、トレーナーさんが分かりやすい「枠組み（フレームワーク）」を提示してくれました。これがあったおかげで、情報を整理でき、効率的にソリューション検討を進めることができました。
  • 場を和ませるスタンプ活用術！： オンラインでのレトロスペクティブ（ふりかえり）やミーティングの際、トレーナーさんが私たちの発言内容に合わせて、スタンプを貼り付けてくれました！そのおかげで場が和んで、みんながよりリラックスして発言しやすくなりました。ちょっとした工夫ですが、コミュニケーションの潤滑油として素晴らしい効果があったと感じています。
• チーム内での意識的なコミュニケーション促進：
  • 雑談タイムの確保と懇親会： ちょっとしたことですが、意識的に業務以外の雑談をする時間を作ったり、時には飲み会を開いたりして、メンバー同士がお互いの人となりを知り、気軽に話せる関係性を築くことを大切にしました。
  • 「不安・分からない」はすぐに共有： 「こんなこと聞いてもいいのかな…」と一人で抱え込まずに、不安なことや分からないことはすぐにチームに共有し、相談し合える雰囲気を作ることを心がけました。実際に私が「本当にこの進め方で大丈夫だろうか」と不安を伝えたときには、リーダーやトレーナーさんが私の不安が解消するまで相談にのってくださいました。さらにそのときの私の疑問がきっかけでチーム全体への追加資料が作られ、結果としてチーム全体の認識をあわせることができ、同じ方向に走り出すことができました。不安を共有することが、チーム全体を前進させるきっかけになることを実感しました。誰かが困っていたら、自然と助け舟が出るようなチームを目指しています。
  • レトロスペクティブの継続的な改善： 当初は個人の反省が中心になりがちだったレトロスペクティブも、チームのフェーズや課題感に合わせて、「個人宛・ロール宛・チーム宛の良かったこと・改善点・お願いしたいこと」といった形にフォーマットを進化させました。これにより、より建設的で具体的なアクションに繋がりやすくなったと感じています。

改善3：情報共有ルールの整備とツールの最適活用

情報が散逸し、「あの情報どこだっけ？」という問題も頻発していました。少しでも改善するために、まずはできるところからルール整備を試みました。

• FigJam運用ルールの策定： 特にフロー図やワイヤーフレームなどの変遷が激しい情報は、オンラインホワイトボードのFigJam上で管理することが多かったのですが、無法地帯になりがちでした。そこで、「情報は基本的に左から右へ、時系列に沿って最新版を配置する」「各セクションのタイトルには必ず更新日付を明記する」というシンプルなルールを設けました。

学び・成果

これまでの取り組みから得られた学びと、現時点での手応えは以下の通りです。

学び

• スコープコントロールからの学び： 既存システムのリプレイスにおけるMVPは、単純な機能削減だけでは不十分だと痛感しました。「捨てる勇気」と同時に、「なぜそれを残すのか」という明確な判断基準をチーム全体で共有することが何よりも重要です。また、全ての要求を最初から完璧に満たそうとするのではなく、段階的にリリースし、ユーザーからのフィードバックを元に改善を重ねていくというUCDのアプローチが、結果的に本質的な価値提供に繋がるのだと実感しています。
• チームの心理的安全性と学習からの学び： UCDやLeanXPは、単にプラクティスを導入すればうまくいくというものではなく、それを支える「文化」や「マインドセット」が何よりも重要だと再認識しました。特に心理的安全性は、チームの学習能力や変化への対応力を大きく左右します。少し時間がかかったかもしれないですが、そのようなチームづくりができてよかったと思っています。
• 情報共有からの学び： 完璧な情報共有の仕組みを最初から作ろうとするのは難しいですが、まずはチームで「何に困っているのか」を明確にし、小さなルールでも良いので合意形成して実践してみることが大切だと感じました。まだうまくいっていない部分もありますが、継続的にチームで議論し、自分たちにとって最適な形にアップデートしていきます！

成果

数々の課題に直面し、試行錯誤を繰り返してきた私たちですが、少しずつですが確かな手応えも感じ始めています。

• チームに生まれたポジティブな変化：  UCDとLeanXPのプラクティスを実践していく中で、チーム内のコミュニケーションは格段に活発になったと感じています。以前よりもメンバー同士が気軽に意見を言い合えるようになり、課題に対しても「どうすれば解決できるか？」「よりスピードをあげるにはどうしたらいいか？」と前向きに取り組む姿勢が強くなりました。ユーザーからのフィードバックを早期に得られるようになったことで、手戻りが減り、開発の方向性に対する納得感も高まっています。まだまだ道半ばですが、チームとしての一体感や成長を実感できる瞬間が増えてきました。
• 最初のマイルストーン「10月リリース」に向けて：「大変だけど、楽しい！」が今の本音： 正直にお伝えすると、10月のサービスインに向けて、まだまだ課題は山積みです。「本当に間に合うのだろうか…」と、不安が頭をよぎることもあります。でも、それ以上に「この大きな挑戦を絶対に成功させたい！」という強い想いと、日々の発見やチームでの協働から得られる「楽しさ」、そして「充実感」があるのも事実です。まさに「大変だけど、とても充実していて、すごく楽しい！」これが、今の私の心境です。

おわりに

ここまで、私たちのチームが「既存システムのリプレイス」という大きな壁に、UCDとLeanXPという手法でいかに挑み、どんな課題に直面し、そしてどのように乗り越えようと奮闘しているか、そのリアルな道のりの一部をお伝えしてきました。

10月のサービスインまで、あと2ヶ月。私たちの試行錯誤の日々はまだまだ続きますが、一つ一つ乗り越えていきます！このプロジェクトの成果や、そこから得られた知見については、また改めて記事にしたいと考えていますので、ご期待ください。

このプロジェクトでの経験は、私個人にとってはもちろん、会社全体にとっても貴重な財産になると信じています。私自身、エンジニアからデザイナーへとポジションチェンジをさせていただき、このプロジェクトに参加する中で多くのことを学ばせてもらいました。その経験を活かして、『RSSにとってのUCDやLeanXPとは何か』『RSSにおけるデザイナーの役割とは何か』を、このプロジェクトを通してしっかりと形にし、社内に新しい文化として根付かせていくことが、私自身の大きな目標の一つです。そして将来的には、UI/UXデザインを専門とするチームを作り、ユーザーにとって本当に価値のあるプロダクトを継続的に生み出せる組織へと、仲間を増やしながら育てていきたいと考えています。チーム一丸となって「やりきる！」という覚悟で、日々のタスクに取り組んでいます。

最後に、私たちが働くRSSという会社は、「やってみたい！」という社員の挑戦を応援してくれる文化があります。そして、その挑戦を一緒に楽しみ、支えてくれる仲間がいます。さらに、私たちが作るシステムに期待して、応援してくれるユーザーがすぐ近くにいてくださいます。 私たちは、そんな恵まれた環境で、日々直面する変化や困難さえも楽しみながら、チームとしても個人としても成長を実感できる、そんな働き方を目指しています。

長くなりましたが、最後までお読みいただき、本当にありがとうございました！

エンジニア募集中！

レイスシステムソリューションズ（コーポレートサイト）