小野氏

2000年に株式会社アプレッソで代表取締役として仕事をはじめ、半年ほどでDataSpiderを開発、2001年にバージョン1をリリースしました。ベンチャー企業の代表取締役ながら、2013年に旧セゾン情報システムズと一緒になるぐらいまでずっとコーディングしていました。組織上トップに位置する代表取締役が、リードプログラマーとして開発部長の部下として動いているという、ちょっと特殊なマネジメントでしたね。
今は株式会社クレディセゾンに在籍していますが、総合職のメンバーが市民開発者としてセルフサービスBIを利活用する際に、Microsoft Power PlatformとともにDataSpider Servistaをさまざまな連携場面で使っています。ノーコード・ローコードの強力なツールの1つとして、事業会社において今は使う側の立場です。

有馬

私自身は2009年に入社してSI開発を行っていましたが、DataSpiderとの接点は、技術統括や品質管理を行うCTO直轄組織として2016年4月に新設されたテクノベーションセンターに公募で入ったとき。DataSpider ServistaのアダプタSDKを使ってアダプタ開発したことが契機となっています。初めて触れたとき、プロダクトのソースコードの美しさや高速処理を実現するための工夫などに感銘を受けたのを覚えています。

石井

私はDataSpider Servistaを使ってSI開発を行っていた2019年ごろが原点です。もともとプログラム開発していた人間でしたが、膨大なコードを書いてテストを繰り返し行わないといけない処理が、アイコンのドラッグ＆ドロップで実現できてしまうことに感動したことを覚えています。非常に多機能で、運用機能も豊富にあるなど、ビジネス環境に適した素晴らしいソフトウェアだと強く実感しましたね。その後自分で開発をしたいという想いもあり、2020年に公募で開発部に異動し、今はDataSpider ServistaやHULFT Squareなどの開発を手掛ける部門の部長をしています。

佐々木

小野さん以外では、私が一番DataSpiderとの関わりが長く、DataSpiderとの出会いは、2003年までさかのぼります。JavaやXMLなどを独学するなかでソフトウェア開発に携わりたいという想いがあり、当時活動していたXMLコンソーシアムの会員企業として名を連ねていた株式会社アプレッソを知り、ソフトウェア開発エンジニアとして入社しました。すでにDataSpiderは市販されていましたが、当時はIT未経験の状況だったため、全く知りませんでした。入社後は一貫してDataSpiderの開発に携わってきましたが、現在はHULFT Squareの開発に携わっています。

小野氏

とても長い時間が経過したと思うのと同時に、2001年のころは怒涛のベンチャー時代で、あっという間でした。ただ、プロダクトが目指したことは、実は25年前も今も変わっていないのではないでしょうか。システムの世界は答えがシンプルではなく、ERPのような中央集権的なシステムであっても、絶対にサブシステムはゼロにはなりません。メールやExcelのような軽めの仕組みもあれば、ERPのような重めの仕組みもあり、離れていればいるほど連携しづらいといった状況は当時からありました。また生成AIといった新たな技術の登場は、当然ながら予測できないもので、予測できない以上、いつの時代であっても異なる複数のものが混在することを是とすることがITのあり方です。その間をつなげていくものが必要という考え方から、DataSpiderを作り始めました。DataSpiderが求められる役割や目指したものは、開発当初と変わっていませんし、当時目指したものは間違っていなかったと改めて実感しています。

そもそもDataSpiderを開発するに至ったきっかけは、どんなことがあったのでしょうか。

小野氏

大学生だった1997年ごろに野村総研でリサーチャー的なアルバイトをしていたのですが、アナリストは毎朝自分に関係するテーマや顧客の情報を新聞含めた各種メディアや白書などで調べて、今日のトピックを押さえてから仕事に入るといったスタイルでした。当時はインターネットが世に広がり始めたばかりで、今でいうクローリング的な処理を人力で行っていたのです。
そこでアナリストに関係するトピックをポータルサイトにまとめるといった、パーソナライズされたWebサイトを作って欲しいという依頼があって、設計から開発、実装、運用まで一人で担当していました。その経験が大きなきっかけですね。

そもそも学生アルバイトにそんな依頼があったのですね。

小野氏

私は小学4年生のころからプログラムを書き始めていたプログラマーです。実はリサーチャーとしてお給料をいただいている人力の仕事を、全部自動化していたんですよ。自動化できるものがあれば自動化するのがプログラマーの習性で、“そこに山があるから登る”登山家と同じ感覚でしょうか。自動化できる業務がそこにあったので（笑）。

そんなある日、会社の先輩から「君は時給労働のはずだけど、全然関係ないことやっているね」と指摘されて。プログラムにリサーチをやらせていることを説明して、実際に動いているプログラムを見た先輩から、そんなことができるならと、同じような仕組みをシステム化しようとしていたチームに紹介してくれました。開発チームのメンバーから「これひとりで作っちゃったの？」って驚かれて、そこから学生なのに契約社員に切り替わり、100％システム開発に従事することになったんです。

複数のシステムをつなぎ合わせて1つの情報にまとめるような仕組みは、当時はなかったのでしょうか。

小野氏

EAIのような類似ジャンルのものは確かにありましたが、金額はもちろん、複雑な仕組みで、正直Too Muchなものばかり。もっと手軽につないでいけるものが、ある意味で“空いているスペースだな”と当時思ったのです。複数のシステムをつなげる仕組みは、当時は高額なEAIを使うかスクラッチで作るしかなかったですし、どちらを選択しても数千万円規模の投資が必要でした。

そのあたりがDataSpiderを生み出す契機になったと。

小野氏

当時は数百万円で作れるようなプロダクトは1つもありませんでした。XML関係のベンダーはいくつかありましたが、XMLパーサーだけを提供していたり、アダプタだけ作っていたりなど、オーケストレーションするGUIを持ったものはありませんでした。作った人間が言うのもあれですが、ある意味でこの手のジャンル自体がDataSpiderから始まったといっても過言ではないと思っています。

アルバイトに対する依頼としてはかなり大ごとな気がしますが、かなり苦労されましたか。

小野氏

社内にあった各種白書DBを見に行くために端末エミュレーターを経由したり、それぞれ独自の文字コードやレイアウトをうまく吸収したりする必要がありました。Webブラウザでクローリングする際にも、今のように全部がUnicodeというわけでもなく、スクレイピングの技術もなかった。国が発表している白書も社内DBもそれぞれ作法が異なるため、それらを全て一カ所に集めて同じフォーマットに整えないといけないわけです。XMLがW3Cの標準仕様として採択される前から、XMLパーサーを作っていたのを覚えています。
つまり、フォーマットやレイアウト、文字コード、記事構成の違いなどを吸収して横断的に取り扱うのがものすごく大変でした。当時の野村総研もSIerに相談していましたが、うまくできないみたいな話があったことが、まさに異なるものをシンプルにつなぎ合わせるDataSpiderのような仕組みが、市場でも求められているのではと実感した原体験となったと考えています。

小野氏

プレスリリースを打ったところ、いろんな会社から問い合わせが来ました。そのうちの1社がNHKさまです。当時高校野球の速報をWebでお知らせするシステムがあり、現地の記者が手書きメモで速報を書き、FTPで送っている仕組みがありました。DataSpiderを使ってもっとタイムリーに情報更新できるようにしたいというお話でした。
起業間もないベンチャーとして試されているなか、最初の訪問時に業務説明を受け、そのミーティング中にメモを取りながら、並行してDataSpiderのスクリプトを作っていました[細見1.1]。DataSpiderならこのシステムをどのくらいで作れるのかを問われたタイミングで[細見2.1]、急ごしらえした大枠の仕組みをその場で披露したのです。今も昔も変わりませんが、ポジティブサプライズをプログラミングで与えていくということを大事にしています。

小野氏

生産性の高さは実感いただいたと思いますが、最初は半信半疑だったはず。それっぽい画面はできているけど、実務レベルのデータを入れたらちゃんと動くのかと。実際にはイレギュラー処理も含めて数ヶ月ほど検証したのちに、十分仕様に耐えられるとご判断いただき、ファーストユーザーになっていただきました。ベンチャー界隈で経営者がハードシングスを乗り越える、みたいな話はよくありますが、当時は会社も製品もまだ立ち上がったばかり。最初の案件でもあったため、かなり忙しく働いていましたが、皆で力を合わせて取り組みました。

小野氏

多くのお客さまの話から、かなりエンタープライズニーズがあることが分かってきました。大量のトランザクションをさばくといったエンタープライズの仕様に耐えうる機能を実装していく必要があると痛感しました。そこで、設計思想からエンタープライズでも使えるものに再設計すべく、データ連携の根幹は変えずに大きく変更を加えました。バージョン1は便利ツールのような位置付けだったものが、今度は定常的にプロセスを走らせるといった、プラットフォームとしてDataSpiderを進化させたのです。
大掛かりな変更に伴って製品名についても社員から公募で募ってアイデアを募集したところ、サッカーでいうファンタジスタのように、サービスを自在に魔法のようにつなげていくプレイヤーというイメージから、サービス＋ファンタジスタ＝Servistaという名前が生まれたのです。

小野氏

産みの苦しみは当然ありましたが、バージョンによって大きく仕様変更したことで、完全な互換性を維持できなかったことは大きな反省としてあり、2度と同じ規模のことがないようにという大きな教訓になりました。当時はお客さまやパートナーにご負担をかけてしまったのが正直なところです。

佐々木

前提としてDataSpiderはミドルウェアですので、爆発的に売れていくようなものではありません。それでも、2008年に某証券会社さまのシステムに導入いただいたことは大きな契機の1つと言えるでしょう。エンタープライズ領域へ展開していく流れはあったものの、金融業界においては性能や品質、運用などあらゆる面で高い要求があり、慎重な空気が社内にもありました。ただ、このプロジェクトを契機に、その高い要件に総力を結集してチャレンジしてみようという空気が醸成され、営業や開発など専任体制を組み、要件にミートできるようお客さまに鍛えていただきながら、そこを乗り越えて安定してご利用いただけるという実績を獲得したのです。社内的にも金融業界でも安定的なデータ連携基盤としてサービス提供できるという自信になり、その後の堅調な売上拡大につながったと考えています。

有馬

2026年の2月に最新バージョン DataSpider Servista 5 のリリースイベントとしてユーザーの皆さまにお集まりいただく機会がありました。登壇した際に、DataSpiderを使っている方に挙手をいただくと、バージョン2からお使いいただいている方が結構いらっしゃったことは意外でした。エンタープライズでの実装が可能な初期段階のバージョン2からお使いいただいている方が、今もイベントに来ていただいて、製品を愛していただけている。ある意味で虜になっていただいていることを知ると、やはりバージョン2のエンタープライズに必要な機能実装が2000年代の拡販に大きく貢献した出来事と言えるかもしれません。

小野氏

バージョン2でエンタープライズ向けの機能を実装できたことで、佐々木さんが話してくれた証券会社様への導入も実現できました。有馬さんが触れていた「バージョン2からお使いいただいているお客さまが多い」という点も、当時必要とされていた機能がバージョン2でひと通り揃ったことが大きかったのだと思います。
こうした機能拡充の背景には、パートナーの皆さまから寄せられた機能要望や、ユーザー会で寄せられたユーザーの皆さまの声がありました。そうした現場の声を受け止めながら機能を磨いてきたことが、DataSpider Servistaの成長につながったことは間違いありません。

小野氏

SAP連携において大規模なERP EAIを入れるではなく、ちょっとした周辺とのつなぎであればDataSpiderだ、といった認知が広がったことは大きなものの1つです。また、特定領域のインテグレーションに強みを持つパートナーさんが、そのサービス向けのアダプタを開発してくださったことも大きかったですね。SaaSやPaaSに詳しい人たちが我々にアドバイスいただくことから始まり、その後はサードパーティアダプタを作って販売いただくことで、我々だけでなくパートナーさんのビジネスにつながる。そんなパートナーエコシステムのなかでゴールデンユースケースのようなものが見つかり始め、さらなる拡販につながっていったという面は間違いなくあります。

小野氏

いろいろありますが、とあるプロダクトベンダーの技術トップとお話しした折に、どんなアダプタが用意できるのかという話になりました。遠方からお越しいただいたので、ミーティング後に帰宅する新幹線の時間をお聞きして、帰社するまでの3時間ほどの間に私のほうでアダプタを作成するというポジティブサプライズを実行しました。とても気に入っていただき、そこからパートナーシップが始まったという出来事もありましたね。

佐々木

やはり小野さんのソフトウェア開発における設計・実装の手際の良さはなかなか真似できないですね。私はもう少し落ち着いてプロダクトとしっかり向き合って、押さえるべきところをきっちり押さえるというのが自身の強みだと考えています。小野さんとは補完関係が築けるといいなと自分のなかですみわけをしていました。

小野氏

そもそもDataSpiderは異種混在というシステム世界のダイバシティーを実現させるものとも言えます。そんなシステム的な意味でダイバシティーが求められる領域を作っている我々だけに、組織にもダイバシティーが必要です。その意味では、私のようにプログラマーとしてガッと作る人もいれば、しっかり着実なプロセスでものづくりをする佐々木のようなタイプもいるなど、いろんな人が集まってそれぞれの強みを事業に生かしていくということが必要です。我々自身もダイバシティーを保ち続けることが重要です。