フュートレックでは、約15年間に渡り提供してきた統合CRMシステム「Visionary」のリニューアルプロジェクトが進行している。従来の良さを残しつつより柔軟で拡張性を持った製品にするため、マイクロサービスアーキテクチャへと刷新。それに伴い、Kubernetes、TypeScript、React.jsという技術を採用したが、なぜそれらの技術を選定したのか。また、新型コロナウイルス感染症の拡大により働き方が変わることでとまどいはなかったのか。Visionaryリニューアルの目的とともに、技術選定の背景や働き方の変化によるプロジェクトの生産性などについて、同プロジェクトに携わっている大塚勉氏(CRM事業部 副事業部長 プロダクト開発部 部長)、竹村憲二氏(CRM事業部 プロダクト開発部 副部長)、杉能康明氏(CRM事業部 プロダクト開発部 担当マネージャー)に話を聞いた。
コロナ禍でも経済的な影響を最小限にできた「Visionary」
フュートレックが提供している「Visionary」は、約15年に渡り、BtoBからBtoCまで200社以上の企業に導入してきた実績を持つ統合CRMシステムである。同システムの特徴は、顧客情報を一元管理しマーケティング施策の実施から効果検証までをワンストップで実現すること。
「例えば、いつ会員登録して、いつ来店してどんなものを購入したかなど、お客さまのいろいろなアクションを一元的に管理し、そのアクションに応じてメールを送信したり、ポイントやクーポンを発行したりと、さまざまなマーケティング施策をワンストップで実現します。施策の実行から結果分析、その結果の反映までを一元管理することで、マーケティングのPDCAを回していけるプラットフォームなのです」
こう説明するのは、Visionaryリニューアルプロジェクトのマネージャーを務める大塚氏である。元々、Visionaryはメルマガやアンケート配信などオンライン顧客向けのマーケティング機能の提供を主軸としていた。だが近年はO2O(オーツ―オー)やオムニチャネルなど、オンラインとオフラインの顧客情報を一元管理する考え方が不可欠となり、「そこに注目してVisionaryを強化していきました」と大塚氏は明かす。そのため、これまでは自社の顧客に対しメルマガ配信やアンケート配信等、機能の利用を目的とした企業が多かったが、現在は、ECやリアル店舗、さまざまな自社サービスの顧客情報を統合し、オンライン/オフライン問わず顧客体験の向上を目指すいろいろな業種業態の企業で使われている。特にここ数年は問い合わせも多く、売り上げは倍増。導入実績は200社以上と、認知度も上がっているプロダクトである。
Visionaryは、ホテルやアパレルなどを中心に多くの企業に導入されているが、これらの企業において、新型コロナウイルス感染症の影響は大きかったものと想像する。しかしVisionaryを導入したことによって、顧客の損害を最小限にすることもできたのだという。
大規模リニューアルを決めた理由
そんなVisionaryがなぜ、このタイミングでリニューアルするのか。実は現行のVisionaryは、「個社カスタマイズを売りにしてきた」と大塚氏は話す。つまりプロダクトを拡張してカスタマイズし、そのお客さま専用のCRMを開発してきたのである。
「各社向けのカスタマイズの工数が非常に大きくなっていました。そこで各社に対してそれぞれカスタマイズして提供していくのではなく、共通した製品をいろいろな会社に使っていただけるようなマルチテナントのCRMにしたいと考えました。そのためにリニューアルが必要だったのです」(大塚氏)
今後はこれまでの強みであるカスタマイズのしやすさを残しつつ、拡張性を考えてアーキテクチャをマイクロサービス化し、UI/UXの向上を図っていくという。
「業種業態が異なっても、マーケティングの視点からみると、求められる機能はある程度決まっています。そういった機能を標準化し、それ以外は個社に対応する。PaaSのような形でVisionaryを拡張していきたい。これがリニューアルで実現したいことです」(大塚氏)
マイクロサービス化にあたり、Kubernetes × TypeScript × React.jsを選定
リニューアルに伴い、採用する技術も一から見直すこととなった。
「現行のVisionaryはPHPを採用していました。PHPは記述もしやすく習得も簡単で、開発者の確保もしやすい。ですが、課題もありました」と、現行のVisionaryの立ち上げからチーフアーキテクトとして参画し、リニューアルプロジェクトでも開発チームを率いている杉能氏は語る。
PHPが持つ課題として杉能氏は、NginxなどのWebサーバーとの併用が必ず必要であること、prefork型のアーキテクチャを採用していること、言語レベルの非同期のI/Oに対応していないこと、サーバーリソースの利用効率が悪いこと、C10K問題が起こりやすいなどバーストトラフィック対応に適さないことなどを挙げる。
新Visionaryの要件では、管理する顧客の数が数100万件におよび、SNSの連携に伴うバーストトラフィックが予測されていた。サービスを止めないで機能をリリースするため、マイクロサービス化を採用。その実行環境として主要なクラウドで利用でき、特定のベンダーに依存しない環境が良いと杉能氏は考えた。
そこで、Kubernetesの採用を決めたという。Kubernetesは、Podという単位でコンテナをデプロイできるため、システムの障害時や高負荷時でも負荷分散できる仕組みを持っているからである。
「次に言語はTypeScriptを採用しました。TypeScriptなら非同期のI/Oを使うことで、限られたリソースだけでバーストトラフィックにも対応できます。また、他の言語に比べて圧倒的にサードパーティー製のライブラリが多いです。さらに、TypeScriptはUIにもバックエンドの実装にも使えることも採用の決め手となりました」(杉能氏)
そのほか、TypeScriptはJavaScriptの上位互換言語のため、既存のJavaScriptエンジニアはもちろん、型を作るコーディングになれているJava開発者も、少し学習するだけで案件に参画できることも採用された理由の1つである。
そして、新Visionaryに採用されたもう1つの技術がReact.jsである。これは総合的に比較した結果採用されたという。これらの理由により新Visionaryは、KubernetesとTypeScript、React.jsで開発されることとなった。
この記事は参考になりましたか?
- この記事の著者
-
中村 仁美(ナカムラ ヒトミ)
大阪府出身。教育大学卒。大学時代は臨床心理学を専攻。大手化学メーカー、日経BP社、ITに特化したコンテンツサービス&プロモーション会社を経て、2002年、フリーランス編集&ライターとして独立。現在はIT、キャリアというテーマを中心に活動中。IT記者会所属。趣味は読書、ドライブ、城探訪(日本の城)。...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社
この記事は参考になりましたか?
この記事をシェア
