Uncategorized

開発の裏側大公開! 生まれ変わったVisionaryができるまでの軌跡を開発者目線でご紹介

Visionary Visionary Visionary Visionary
Visionary Visionary Visionary Visionary

こんにちは。広報担当です。今回は、Visionary開発者のFさんとSさんに、Visionaryの歴史を振り返りながら、どんな技術を使っているのか、どんな想いで開発してきたのか話を聞きました。ぜひ最後までご覧ください。

【開発者F】
・マネージャーとしてチームの管理をメインに行い、手を動かすことも

【開発者S】
・技術統括チームに所属し、インフラやアプリ開発など幅広く対応

〈目次〉
・新しいVisionaryが生まれるまで
・開発を進める上で苦労したこと
・開発でこだわっているポイント
・お客様とともに進化するVisionary

■新しいVisionaryが生まれるまで

◇Visionaryのこれまでの歩みについて簡単に教えてください

S:
Visionaryが市場に出始めたのは20年ほど前です。当時はApache・PHP・PostgreSQLなどを使っていて、モノリシックなアプリケーションでした。開発統括のOさんも言っていたように、10年ほど前から今のノンカスタマイズモデルのVisionary構想はあって、実際に形になり始めたのは約6年前(2020年ごろ)からですね。

◇当時のVisionaryについて教えてください

S:
当時のVisionaryはモノリシックな構成でした。そうした中、新規のお客様から利用中の別ベンダー製CRMパッケージをVisionaryへリプレイスしたいというご相談をいただきました。お客様が利用していたCRMパッケージもモノリシックな構成で、高い負荷がかかるとサービスが停止してしまい、安定した運用に課題を抱えていました。そこでお客様から、「この機会にVisionaryもマイクロサービス化できませんか」というご要望をいただき、新しいVisionaryの開発に踏み切りました。

◇新しいVisionaryの開発はお客様きっかけだったのでしょうか?

S:
おっしゃる通りです。本腰を入れてやるぞと思ったのは当時のお客様の要望に応えたいと思ったのがきっかけですね。新しいVisionaryの構想自体は10年前からありましたが、その要望を受けて本格的な開発へ踏み切りました。

◇新しいVisionaryの開発では具体的にどのようなことをしたのでしょうか?

S:
アーキテクチャを一新し、Kubernetes上で動くマイクロサービスとして技術を刷新しました。以前のモノリシックな構成では、キャンペーンなどでアクセスが集中すると負荷への対応が課題でしたが、現在はKubernetesによってインフラ管理の負担が軽減され、機能開発に注力できるようになりました。
※Kubernetes:Googleがクラウドサービス向けに作ったシステム。複数のコンテナ化されたアプリケーションの配置、スケーリング、および管理を自動化する。

◇高負荷に耐えるという点はVisionaryにとっては大命題なのでしょうか?

S:
はい、高負荷に耐えることはVisionaryにとって非常に重要です。
数百万規模の会員データを持ったお客様の場合、キャンペーン時にはECサイトにアクセスが集中するので、大量のリクエストを処理する必要があります。もちろんECサイトは止められないため、高負荷に耐えられることはとても重要でした。TypeScriptやKubernetesを使ったことで、その心配が大きく減ったのでよかったです。

◇どのような流れでパッケージとしてのVisionaryになっていったのでしょうか?

S:
最初はお客様の要望に特化したシステムとして開発しました。その後、運用が軌道に乗ってきたタイミングで機能を追加したり、アーキテクチャを調整したりしながら改善を重ね、パッケージとしてのVisionaryへとブラッシュアップしていきました。

◇新しいVisionaryの開発で見えてきた課題はありますか?

F:
今回は開発スピードを優先し、複数のチームが同時並行で開発を進めたことで、機能ごとに操作感や使い勝手に若干のばらつきが生じました。本来は一つの機能の使い方を覚えれば、ほかの機能も直感的に操作できるような一貫性のあるUI/UXが理想ですが、改善の余地を残す形となっています。一方この経験から、使いやすさの感じ方は人それぞれ異なるという大きな気づきを得ることができました。現在はその学びを活かし、操作性の統一感を高める改善を進めています。誰もが直感的に使える製品を目指し、今後も利用者目線を大切にしながらブラッシュアップを重ねていきたいと考えています。

S:
インフラやアーキテクチャの視点では、マイクロサービス化によって開発の手番やコミュニケーションが増えたことですね。モノリシックな構成では一人で完結できていた開発も、マイクロサービスでは複数人で役割を分担しながら進めるため、コミュニケーションがより重要になりました。

■開発を進める上で苦労したこと

◇開発を進める上で苦労したことや難しかったことを教えてください

S:
新しい技術をゼロから習得しながら開発を進めなければならなかったことです。約6年前、社内にはマイクロサービス、Kubernetes、TypeScript、クラウドサービスなどの知見がほとんどなかったため、外部の有識者と一緒にゼロから検証を進めました。これまで培ってきたPHPやApacheの知識がほとんど使えず、すべて手探りの状態で製品を作り上げていきました。

F:
Sさんも話されていますが、私が参画した約6年前は知識や経験が十分にない状態からスタートして開発を進めなければならなかったことが一番大変なポイントでした。まさに「習うより慣れろ」という状況で、最初は手探りで何度もトライ&エラーを繰り返しながらのスタートでしたが、そうやって必死に現場で揉まれたおかげで、今では知識やノウハウもだいぶ蓄積されました。ノウハウを活かして改善を重ねてきた結果、今ではシステムも非常に安定して動作するようになり、あのとき諦めずに一歩ずつ進めてきて本当に良かったなと思っています。

■開発でこだわっているポイント

◇開発でこだわっているポイントや重視している点などを教えてください

F:
振り返ってみると、私は開発において「分かりやすさや、使いやすさ」を一番大切にしているなと感じます。 どんなに高機能なシステムでも、使いづらいと結局は使ってもらえなくなってしまいますし、それでは作る意味が薄れてしまうと思うからです。 だからこそ、マニュアルを読まなくても、画面を見ればなんとなく使い方がわかるような「直感的な使いやすさ」にこだわりたいです。使ってくれる人がストレスなく自然に操作できるような、そんな優しいシステムをこれからも目指していきたいと思っています。

S:
高負荷な環境でも安定して動作する技術を選定することを重視しました。言語選定ではさまざまな言語を検証し、コンパイルに時間がかかりすぎるものは除外しました。その上で、大量のリクエストが発生する環境でも、できるだけシンプルに実装でき、要件を満たせるという観点からTypeScriptを採用しました。昔のPHPでは絶対に実現できないという強い思いがありましたね。構想自体は10年以上前からありましたが、お客様からのご要望をきっかけに新しいアーキテクチャへ移行でき、結果としてTypeScriptやKubernetesを導入することで、業界でもレベルの高い技術基盤を手に入れることができました。技術者から見ても、Kubernetesの運用に携われることは非常に魅力的だと思います。

■お客様とともに進化するVisionary

広報:
技術をゼロから見直し、お客様とともに開発を進めた新「Visionary」は、2026年4月にリニューアルを果たしました。もちろん、これで完成だとは考えていません。これからもお客様の声に耳を傾けながら、より使いやすく、より価値のあるシステムを目指して進化を続けていきます。