はじめに
2023年8月に、ヘルプセンターシステムのリプレイスプロジェクトが一段落しました。2021年7月からリプレイスプロジェクトが発足してから約2年。数々の失敗を繰り返しながらヘルプセンターシステムを刷新できました。
またこれを機に、「CSS（Customer Service Support）グループ」から「CSプラットフォームグループ」へ改名しました。
本記事では、以前に開催したイベント『DMM meetup #35 〜24時間365日ユーザーの声を第一に。CSプラットフォームの裏側〜』の中でもお伝えした、プロジェクト概要のおさらいと振り返りについて具体的な開発エピソードを各エンジニア視点で連載 していきます。
今後の連載予定
| 記事概要 | 役割：担当 |
|---|---|
| （本記事）リプレイスプロジェクトの概要と結果 | プロジェクトマネージャー：堀本史朗 |
| 24/365で稼働するオンプレシステムのクラウド移行で取り組んだこと | インフラエンジニア ：吉田孝紀 |
| 社内マイクロサービスを使った結果開発効率が上がった話 | バックエンドエンジニア：.佐々木総 |
| API開発初期段階での技術選択の振り返りと今後の展望 | バックエンドエンジニア：.坂本穂高 |
| リプレイスにおけるUI/UX改善 | UI/UX設計者：小杉鞠奈 |
| 異動を機にTypeScript始めました | フロントエンドエンジニア：金粕真弥 |
| リプレイスにおける主な失敗と反省 | フロントエンドエンジニア：松田悠平 |
| 新卒エンジニアが戦力になるまでとこれからのヘルプセンターシステム | 新卒エンジニア：渡部大基 |
プロジェクト背景
なぜリプレイスを行ったか
私たちが提供するCSプラットフォームでは、カスタマーサポートに関わるシステムが集まり、それぞれのシステムが互いに関連しながら機能することで、カスタマーサポート業務を効率化しています。またその先のDMMユーザーのカスタマーエクスペリエンス（CX）の向上も目指しています。
しかし、CSプラットフォームの中核を担う「ヘルプシステム」と「問い合せシステム」については、拡張性・保守性といった観点で大きな課題がありました。それだけでなく、管理システムを使うオペレーターや、ユーザー向けサイトを使うDMMユーザーのUXにも大きく影響していました。これらの解決が急務となり、単にリファクタリングだけでなく、作り替えが必要だと判断しました。
ヘルプセンターシステム として、次の二つのシステムをリプレイスし統合しました。
ヘルプシステム
顧客が自己解決できるように『よくある質問』を提供するシステム。よくある質問は、管理システムのエディターで作成。システム自体が古く（使われている言語・フレームワーク・DBなど）、そのため「古い技術」の学習が必要。問い合せシステム
顧客からの『フォームでの問い合わせ』や『メールでの問い合わせ』を受けてチケットを一元管理するシステム。問い合わせに対しての返信・履歴の管理などを行う。
上記、両システムにおいて開発に携わったチームメンバーがいない状態でプロダクトが引き継がれていた結果、オンプレミスシステムの『ブラックボックス化』といった問題が生じていました。
リプレイスで解決したい課題
新システムでは次に述べる課題解消のほか、ユーザーにとって使いやすく、またビジネス要件にすばやく対応できるプロダクトにしていく必要がありました。また単にシステム開発だけでなく、参画する開発者のスキルアップとチーム全体の開発力強化 も目的としていました。
- アプリケーションの断片化
URL遷移でのみ繋がっている断片化されたアプリケーションでは、UI/UXの統合性が欠落します。これによりDMMユーザーやカスタマーサポート担当者が使いづらい状況が生じていました。全ユーザーにとって「使い易さ」を向上させていくことを目指し、併せて今回のリプレイスで解決したいと考えていました。
- 技術スタックや設計思想の不一致
対象のアプリケーションは、各開発チーム・各時期に作成されたものの、異なる技術スタックや設計思想により、理解に2倍のコストがかかる状況でした。しかし、統一した技術スタックと設計思想でアプリケーションを統合することで、この課題を解決したいと考えました。
- ブラックボックス化
設計や開発過程に関与したメンバーが現在のチームにはおらず、一部の機能追加・修正しか行えていない状況でした。そのため、全体像や細部への理解が不十分であり、潜在的な問題が存在していても気付けず、広範囲での効率的な改善が行えていませんでした。ブラックボックスを解消しながらリプレイスを行いたいと考えていました。
プロジェクト計画
開発方針
大まかな開発方針は、次のようになります。
- オンプレミス上で稼働している「ヘルプシステム」と「問い合わせシステム」をヘルプセンターシステムとしてパブリッククラウド上で統合する。
- フェーズを細分化しフェーズごとに、設計⇒実装⇒テスト⇒リリースを行い、ビックバンリリースは行わない。
- 最低限、既存システムの必要な機能は実現するが、追加機能開発は極力リプレイス後に行う。スピードを重視して機能実施のスコープは絞る。
- バックエンドの技術スタックの統一（APIはGOで実装）。マイクロサービスアーキテクトグループが提供するエコシステムを利用する。
- フロントエンドの技術スタックの統一（React Next.js）。フロントエンドグループが提供するエコシステムを利用する。
開発スケジュール
当初のプロジェクトでは、目標トータル期間を1年～1.5年とし、期間内でやりきれるように人員計画とリプレイスプランを考えていました。
リプレイスの難易度を考慮すると、「ヘルプシステム」は「問い合わせシステム」よりもリプレイスが容易なため、まず先にヘルプシステムをクラウド化し、リプレイスする方針を取りました。その後、問い合わせシステムもリプレイスし、二つのシステムを統合することで「単一のヘルプセンターシステムを実現する」という進行方針を採用しました。
開発体制
私たちの開発チームでは、扱う技術スタックの経験が浅かったため、それらを補うために各所で支援を受けながら開発を進めていきました。
具体的には自チームメンバーのほか、プラットフォーム事業本部の横断組織によるバックエンド・フロントエンドの開発の支援、インフラ部のインフラ構築の支援、QA部のテストの支援を受けることによって開発速度を上げながら品質の担保につなげました。
また成果物に関しては、システム利用者であるカスタマーサポート部に適宜レビューや利用してもらい、フィードバックを得ながら進めることで、手戻りのリスクが少なくなるように進めていきました。
| 役割 | 自チームの要員 | 支援体制 |
|---|---|---|
| デザイン作成 | UI/IX 担当1名 | デザイン部のデザイナーによるデザイン作成とUIレビュー支援 |
| インフラ構築 | インフラ担当1名 | インフラ部による構築支援 |
| バックエンド開発 | バックエンド開発チーム（4～8人） | マイクロサービスアーキテクトグループよるレビュー支援 |
| フロントエンド開発 | フロントエンド開発チーム（4～8人） | フロントエンドグループによるレビュー支援 |
| 成果物テスト | テスト担当1名 | QAグループによるテスト実施 |
| 成果物レビュー | UI/IX 担当1名 | カスタマーサポート部によるレビュー |
ヘルプシステムのリプレイス
ヘルプシステムのリプレイスは、次の3つのフェーズに分けて行いました。対応概要と結果を記載します。
- ユーザー向けサイトの開発
実際にサービスを利用するDMMユーザー視点でどういう情報を提供すべきかを、旧システムの課題やアクセス解析の結果を参考にしながらデザインし、実装しました。 - 管理者向けサイトの開発
管理サイトで、ユーザー向けサイトに出すデータをどのように作成していくかを決めてから管理画面を構築。具体的にはヘルプ記事の作成や、WYSIWYGエディターの選定と組み込みなどを行いました。 - ヘルプデータ修正と移行・システムの切り替え
ヘルプシムステムに集約された約3,000件以上のヘルプデータを新環境に合わせて改修しました。旧ヘルプ記事では、HTML・CSS・JSを自由に活用しながら「スマホ用」と「PC用」とで分けて作成されていましたが、新ヘルプ記事では、システムで定義されたHTMLとCSSに絞り、スマホ用とPC用を統一した一つのヘルプ記事として提供しました。そして無事に新環境へ切り替えるためにデータ移行期間（ヘルプ記事の凍結期間）を設けました。
結果
2022年5月19日に、旧システムから新システムへの切り替えを行い、オンプレミス環境から脱却してクラウド化できました。マルチデバイス対応ができるように、レスポンシブデザインへ変更、またヘルプ記事は一つの記事に統一しています。また誰が作っても、統一化されたヘルプ記事が簡単に書けるように、エディターを刷新し、利用ルールを統一しました。
問い合わせシステムのリプレイス
問い合わせシステムのリプレイスも、次の3つフェーズに分けて行いました。対応概要と結果を記載します。
- クラウドへのリフト＆シフト
- ユーザー向けサイトの統合
- 管理サイトの統合
クラウドへのリフト＆シフト
初期フェーズでは既存の問い合わせシステムをそのままクラウドへ移行することにし、また次の段階を経ながら進めるようにしました。
(詳細は、次回以降の連載記事で具体的な開発エピソードを紹介していきますので、そちらをご参照ください)
- 問い合わせDB / NFSのクラウド移行移
- 問い合わせシステムのメール受信、JOBのクラウド移行
- 問い合わせアプリ全体のクラウド移行
結果
2022年7月1日に、問い合せシステムのクラウドへリフト・シフトを実施できました。これにより、その後の改修やデータ移行の際にはクラウドの機能を享受しながら行うことが可能になりました。またクラウド化の過程で、ブラックボックスの一部分（主にインフラ・メール送受信の部分）が解消できました。
ユーザー向けサイトの統合
DMMユーザーが利用するユーザー向けサイトを統合しました。DBや管理サイトはそのままにして、ユーザー向けサイトを既存システムへシームレスに連携させることで既存データや管理サイトの利用には影響を与えることなく、ユーザー向けサイトをヘルプセンターシステムに統合しました。
結果
2022年10月17日に、ヘルプセンターシステムへの統合を終えました。これにより、DMMユーザーが利用するユーザー向けサイトは、当初から設計していたUIに変更され、問い合わせへの導線が明確化し、DMMユーザーのUXが大幅に改善されました。同年12月の『DMMプレミアム』リリースなどの案件に間に合うようにユーザーの導線が作れました。
管理サイトの統合
最後に、問い合せの管理サイトの統合を行いました。管理サイトは、主に管理者が利用する機能「管理者機能」とオペレーターが利用する機能「オペレーター機能」の２つがあり、データを同期した上でこれらの機能の移行を進めていきました。
- データ同期状態の作成 ：データ同期スクリプト及び、ダブルライトによる移行前後のDBの同期状態を作りました。
- 管理者機能の移行 ：管理者のみが使える管理機能を移行しました。
- オペレーター機能の移行 ：問い合わせの対応など、利用者数、利用頻度が共に多く、複雑なUIを持つオペレーター機能の移行を行いました。
結果
2023年3月15日に、一部機能を残し、管理者が利用する「管理者機能」を移行できました。特に、利用頻度が高い『問い合せフォーム』の作成機能に関しては、利用者側の要望も取り入れられ、柔軟に統一感を持たせながら作成できるようになりました。
2023年8月1日には、最後に対応した「オペレーター機能」を移行できました。これによりオペレーターが使う、問い合わせのチケット対応機能についてはUIの刷新が行われ、業務効率の改善につなげられました。移行過程では、新旧システムを並行稼働させながら、過去データを含んだ約600万件の問い合わせデータを安全に移行できました。
PJ全体を通して
プロジェクトを終えて関係者全体で振り返りを実施しました。失敗や反省点をまとめると、次のようになります。
技術習得の難しさとスケジュールの考慮
技術スタックの統一に関しては、当初は新しい技術の適応に思った以上に時間がかかってしまい、予定より遅延してしまいました。一方で他部門からの支援で時短できた部分もあり、スケジュールを立てる上で考慮すべき点だと思います。
データ管理の重要性と再利用への考慮
自由度が高く無秩序な旧ヘルプ記事のデータ修正が大変でした。専用メンバーを雇い、1.5カ月かけてデータを新環境に合わせました。無秩序なデータは、その後のデータ抽出・解析・再利用が難しくなることを痛感しました。今後のAI活用においても、データの整理は重要です。今回のリプレイスによってエディターにはテンプレートを用意し、ルールに沿って作成するようになっています。
リプレイス対象となるシステムを徹底理解すること
リプレイス対象がほぼ引き継ぎプロダクトであったため、理解が浅く、仕様の実装漏れが多発し、先々で遅延の原因にも繋がりました。必要な機能の抜けや考慮の漏れの判明が後になればなるほど開発スケジュールに響くため、早い段階で既存システムを徹底的に理解することが重要だと感じました。
先に動作するものを作ること
バックエンドとフロントエンドの各開発チームが開発効率とリソースの有効活用に焦点を絞りすぎたため、フロントエンド開発はバックエンドのAPIの完成を待つことなく、モックを使用する状態が長く続きました。実際の結合作業がスムーズに運ばなかったため、QAテスト段階までに多くの時間を費やし、結果的に機能の完成までの時間が長くなりました。バックエンドとフロントエンドの開発スケジュールを適切に調整し、各機能を逐次完成させた上でテストとユーザーレビューへと移行すべきでした。
各フェーズでの計画は綿密にすること
フェーズごとに計画を立て、優先順位を決定して開発を進めました。しかし、特に管理機能の統合に関しては、開発中にさらなる細分化が必要となりました。途中、細分化によって開発の優先順位が変動し、開発スケジュールに影響を与えてしまいました。このような問題を未然に防ぐためには、フェーズごとの計画立案に時間をかけてより緻密に行うべきでした。
リソースマネージメントの重要性
開発の遅延の遅れを、開発メンバーの増員によって取り戻そうとした際にはレビュアーが足りず、かえって混乱を招きました。また一部のメンバーの離脱による影響を軽視し、手当が遅れました。プロジェクトマネージメントの観点から、進行状況をモニタリングしながら開発の遅延箇所を特定し、すぐに行動することが必要でした。単にメンバーの数を増やすだけではコミュニケーションコストが増えるだけで、遅延箇所の手当になるようには役割変更なども考慮すべきでした。
おわりに
DMM全体の大型案件の影響やさまざまな要因に伴い、当初の予定よりも遅延してしまいましたが、失敗から多くの学びを得ながらリプレイスをやりきれました。
リプレイス後のプロダクトについては、現在も問題なく稼働しています。ブラックボックスが解消され、技術スタックの統一を基にリプレイスされた「ヘルプセンターシステム」においては以前よりも大幅に改善速度が上がっています。現在もAI活用を絡めた業務効率化を進めており、さらに発展させていきたいと思っています。
