「VALUENEX Radar Fusion」β版開発の裏話≪後編≫
この記事は、現在テスターを募集している新サービスVALUENEX Radar Fusionの開発者インタビュー記事の後編です。アルゴリズム開発の話がメインの前編は、こちらからご覧ください。
後編では、Webアプリケーション開発編をお届けします。
中山さん 社内検証やお客様のニーズも把握できたところで営業部でもトピックモデルのASPを進めようということになり、営業部の新井さんと共に開発部に相談することになりました。
では実際にエンジニアとして実装を担当した麻生さんにお話を伺いたいと思います。
FusionをASPとして実装していく中でどのように進めていたのか教えてもらえますか。
麻生さん 開発と営業の合同のミーティングでトピックモデルをもっと広げていくために Webアプリケーションでトピックモデルを使えるようにしたい、では誰がやるかという話が出たので、じゃあ僕やりますみたいな話になったかなと。
お題としてはWebアプリケーションでトピックモデルをいろんなユーザーが利用できるようにすることで、Webアプリケーションの仕様も画面デザインもない状況からスタートしました。
最初にリリース時期を確認して、そこから逆算して、Webアプリケーションとしてユーザーに提供するために必要な機能や非機能要件を整理しました。
機能面だけでも認証機能や検索機能、可用性、性能、セキュリティや保守性等々、いろいろ考えないといけない中で、どういったアーキテクチャにすればいいのかとか、 どういった設定にすればいいのかというのを考慮しながら 実装していきました。
それと同時並行で画面の簡易デザインも書いて、 メンバーとデザインを共有しました。ある程度それらがまとまった段階で、実際に認証やセキュリティ、トピックモデルの非同期処理などの実装を行い、ようやくトピックモデルの分析結果がWebアプリケーション上で出るようになりました。
社内のサーバーにデプロイして、 メンバーの人たちに確認いただいて、 細かい修正をしていって、あとはインフラを構築するのみという段階になったタイミングでまさかのビジネス要件等の追加要望が発生して(苦笑)急いで修正案を出して、結果的にリリースが1ヶ月ぐらい 遅れてしまったのですが、その間、インフラコードの自動化対応とか、 細かい修正とかも並行してできたので、2023年5月に一部のお客様に対してα版としてお渡しすることができました。
中山さん アーキテクチャの設計から実装からインフラからデザインに至るまですべてお願いする形になってしまい、麻生さんには多大なご迷惑をおかけしました・・・。さらには営業や利用規約の観点のご相談も後出しになってしまい未熟で申し訳なかったです。そんな無茶振りにもご対応いただいて本当に感謝でした。
開発を進めるうえで、重視したことや、優先したことは何ですか？
麻生さん 今回のFusionで使うことにとどまらず、他のプロジェクトにも使えるものを1つでも多く残すことと急な修正にも対応できるように常に心に余裕を持つことを重視していました。
まず、インフラ構築の自動化は最低限行うことにしました。
今後、いろんなPoCをしていかないといけないと予測していたため、そのPoCのインフラ環境のテンプレートをこの際作っておこうと思っていました。
インフラ構築の自動化（Terraform）も会社として初めて、私としても初めて扱うということで、一からTerraformのドキュメントを調査して、実装していきました。
結果的に今行おうとしているPoCのインフラ環境はFusionで実装したものをテンプレートして使う流れができています。
あと、プロジェクト管理もNotionというツールを使って、開発の進捗のまとめ方をメンバーに共有して、ユーザー情報やフィードバックもそれなりにまとめていけるようになりました。
Notionでのプロジェクト管理、プロダクト管理もこれを機に社内に広がっていったと思います。
あと、最低限の機能で我々が行いたいことがWebアプリケーションとしてきちんと動作できるようになることを最優先にしました。
早い段階で私の開発環境できちんと動作できるようになっていたので、あとは細かい修正をしていくだけになって、精神的にも楽でした。おかげで、急な大幅な修正にも対応できたかなと思います。
そのように開発されていったFusionをユーザー様にも試してもらったとのことですが、フィードバックはどのように開発に生かしていましたか？
中山さん まず特許と論文を混ぜた分析ができないか？と問い合わせをいただいていたユーザー様に優先的にご案内して、2種類のテストで試していただきました。一つがFusionのアウトプットの有用性を判断いただくもので、お客様からデータを提供いただいて、当社でトピックモデルを使用して分析したアウトプットをお客様に見ていただくもの、もう一つが麻生さんが実装したWebアプリケーション版をお客様ご自身でデータのインプットから解析、アウトプットの確認までをトライアルいただくものでした。
ASPサービスの方でトライアルしていただいた方については、 まだまだ大﨑さんのプログラム自体が、 インプットするデータがコンサルで使うようにきれいな状態で加工・整形されていることを前提としていたので、お客様の方でそういった状態のデータを用意いただくことにハードルがあったり、アップロードできるデータ形式に制限があったりといろいろな改善点や要望をいただきました。
いただいたフィードバックを元に、修正が必要な箇所を洗い出し、どういった開発が必要なのか、優先順位をつけながら開発していくような方式で進めていました。お客様からいただいた要望を麻生さんにお伝えして、検討を重ねたうえで、実装いただくというような流れで現在も改良を進めています。
今後Fusionをどのようなサービスとして広げていきたいですか？
大﨑さん 絶対やらなければいけないこととして考えているのは多言語化ですね。今は英語が主ですが、お客様とディスカッションしているとまだまだ日本語にニーズは高いと感じています。
データソースとして入手しやすいことと、お客様の使用実績が大きいことから、 論文・特許を解析するということを前面出していますが、扱うデータはスタートアップ情報や社内文書など他のデータでもいいと思っています。個人的には、ユーザーも法人のお客様に限らず、個人の方にも使ってもらえるようになればいいなと。
僕の頭の中では、Fusionをどれだけ磨くかということも大事ですが、それよりももっと違うものを一気にドカンと出したいという思いの方が強いです(笑)まだまだいろいろとアイデアややってみたいことがあるので、それを形にしていければと考えています。
巨大GAFAやマグニフィセント・セブンと呼ばれるようなところの技術には敵わないかもしれないけれど、VALUENEXの強みはやはり俯瞰図化、二次元化するというところなので、そういう長所を伸ばしながら発展し続けられたらいいかなと思っています。
僕は社内では古株になってきたので、そろそろ次の人に頑張ってもらえるように、エンカレッジするのが僕の役割かなとも、ちょっと思ってるんで、新しいものを作るのは僕かもしれないし、 違う人に作ってもらった方がいいかもしれないなとも。そこら辺はオープンに考えてますね。
Fusionを作るまでたくさん失敗したし、Fusion以外でも全然使い物にならないゴミみたいなプログラムをたくさん作りました。まずは自分の手元でやって、 ダメなものいくつ作っても自分の中で作るのは問題ないんで、 そのうちいいのができたら、 あたかも「これしか作ってません」みたいな感じでしれっと出してみんなを驚かせる。そういうことを楽しめるのがVALUENEXかなと感じています。
Fusionに関わった中での振り返りをお願いします。
大﨑さん 僕は大変だったというより、勉強になったなと思います。僕としては一人ではできなかったものを後から入ってきた中山さんや麻生さんのご協力を得て形にすることができてとてもうれしかった。前の会社で、一人で特許評価システムを作ろうとして失敗した記憶があったので、 新規開発をするのは大変だし、また失敗したらいやだなと半分諦めていた部分がありました。
そんな中、こういう色んな助けをしてくれる人がいて、 自分ひとりじゃ決してできなかったであろうことがここでリベンジできたというのは、 とても感慨深いんですよね。VALUENEXはそういうチャレンジをさせてくれる場所で、 いい会社に来れたなと思っています。
苦手なことは自分がやっちゃいけない、 上手な人がちゃんと周りにいるから、 その人たちをお願いするのが一番いい。
麻生さん このプロジェクトでチャレンジだったのが、ビジネスサイドとのやり取り、モデル開発者とのやり取りといった仕様策定からインフラ、フロントエンド、バックエンド、テスト、リリースと一人で一気通貫で行わなければならない、しかも、それを半年という短期間で行わなければならなかったこと。
あと、技術面では、趣味でPythonはよくコーディングしていましたが、業務では使ったことがなかったため、セキュリティや非同期処理の方法は手探り状態で進めていたのでなかなかチャレンジングだったかなと思います。苦労といえば苦労なのかもしれないですけど、 大枠は本当にすぐできて、細かい修正は多々ありましたが、気持ちに余裕をもって対応することを心がけていたので、何とかなってよかったです。
モデル以外すべての実装に携われたのが、非常に刺激的で、大きく成長できたのかなと思います。
今後の目標は、開発リソースや時間の制約上開発できなかった技術的チャレンジをしていきたいです。具体的には、認証基盤、決済基盤、計算基盤の土台の構築と計算の非同期処理の深い理解と実装、インフラもKubernetesを導入して、開発サイクルを速くしていきたいです。
中山さん 大﨑さんと雑談で話していた時は、今までも提供していたようなコンサルの皆さんが独自に作成したプログラムをコンパイルしたモジュールにする簡単な提供方法くらいのレベルかと思ってたら、意外と大規模なプロジェクトになってしまっていて、「あれ、これ一介の営業員にしか過ぎない私には 重荷だったな」というところは、 正直ありました。ですが初めから営業が入ることでお客様のフィードバックを反映できたり販売戦略を想定しながら開発の相談が出来たり、プロジェクト推進を経験できたのはとてもよかったと感じています。体制が整っていない中で、先駆者もこの会社の中にいない中でやるっていうところは、 全体的に大変なことは多かったなと思いますが、その分、営業の枠を超えて製品開発～マーケティング～販売に携わり経験できることがとても多くて、ビジネスパーソンとして大きな経験値になりました。
〈Fusionの名称の由来について〉
Fusionは、融合の意味で、原子力研究のバックグラウンドがある大﨑さんが以下のような想いから命名したものでした。
VALUENEXの構想「Data Fusion & Chemistry」のまさしくFusionのパートを担っていければと思います。
論文と特許の融合分析の他、様々なデータの融合に活用できるようになればと思います。
従来のエネルギー発生機構がFission(核分裂)で、なんか世の中までバラバラに分裂しそうなイメージですが、
将来のエネルギー発生機構がFusion(核融合)で、将来は世の中も繋がって(融合)、明るい世の中になるイメージで、
Fusionには明るい未来を込めたつもりです。
ドラゴンボールの技にもFusionがあるそうですが、
論文と特許がFusion(融合)して、より強力な知見が得られると思えたらいいなと思います。
以上、Fusionの開発裏話をお届けしました。
Fusionを使ってみたいという方は現在テスターを募集しておりますので、ぜひお試しください。
カジュアル面談も随時受け付けてます！
この記事が気に入ったらサポートをしてみませんか？