TOP>企業情報>コラム>お客様の声>NO.05 ヴァル研究所

NO.05 ヴァル研究所

発売以来18年にわたって売れ続けているロングセラー・ソフト「駅すぱあと」の開発元であるヴァル研究所では、かつて業務システムは、各部署の自主判断、自主管理で構築していたが、この度、Oracle を基盤とした全社統一システムに変更した。その際、アシストがどう貢献したのか。また、ヴァル研究所が提供するソフトの共通点「ナビゲーション」と情報活用の関係について、詳しく聞いた。

Guest Speaker
株式会社ヴァル研究所
ソリューション開発部
部長 山本直樹氏(写真中央)


1. ヴァル研究所とは?


まず、ヴァル研究所の業務内容について、お聞かせください。

ヴァル研究所という社名自体は、一般の方にはあまり馴染みがないかもしれません。しかし「駅すぱあと」という路線・運賃探索ソフトは、ご存じの方も多いと思います。また「駅すぱあと」という商品名をご存じない方であっても、「Yahoo!路線情報」ならご存じなのではないでしょうか。実は、あのサイトには、「駅すぱあと」の経路・運賃探索エンジンがOEM搭載されています。

「Yahoo!路線検索」なら、私もいつも使っています。あの中身は「駅すぱあと」だったのですね。

「駅すぱあと」はMS-DOS版を初めて発売したのが1988年。そのときは、まさかこのソフトがインターネット経由で全国で使われるようになるとは夢にも思っていませんでした。実は、「駅すぱあと」は、大学教授の経路探索アルゴリズム研究がその原型で、その研究論文を読んだ初代社長が、これをビジネスに応用できそうだと思ったことが開発のきっかけでした。

発売当初の周囲の反応はいかがでしたか。

経路探索はビジネスにならないだろうという意見が大勢を占めていました。その予測の通り、対応範囲を首都圏に限定していた最初のバージョンはあまり売れませんでした。しかし、そこで諦めずに範囲を拡張して、全国対応版を発売したところ、出張が多いビジネスマンに大好評となりました。

初版の発売が1988年。つまり、実に18年にわたって売れ続けているロングセラー・ソフトになります。

ここまで永く幅広く愛用される製品が作れたことに、会社として誇りと感謝を感じています。常に、今よりもっと良い物を作ろうと努力し続けてきたのが認められたのだと思います。

2. アシストとヴァル研究所の、現在の関わり


さて、ヴァル研究所とアシストとは、現在どのような関わりなのでしょうか。

アシストからは、Oracle のほか、PowerBuilderなどの開発ツールやMercury QuickTest Professional といったテストツールを購入しています。Oracleは、現在、会社全体の基幹システム、つまり売上管理システムや顧客情報管理システムなどの基盤のデータベースとして活用しており、Oracleで多くの技術支援を提供していただきました。

Oracle以前は、どのような体制で社内システムを構築していたのでしょうか。

以前は、各部署がそれぞれシステムを構築していました。当時は、現場が、自主的にコンピュータを利用して、自分や自部門の業務に役立てるといったエンドユーザ・コンピューティング(EUC)の考えが流行した時代でした。弊社はソフトウェア開発会社なので、社員のコンピュータ・リテラシーは割合に高い方であり、やろうと思えば、ちょっとしたシステムぐらいは、各部門で簡単に組めてしまうということもあり、部門別のシステム構築は進みました。しかし、システムが個別に作られたことによる問題も生じてきました。

どういう問題が生じたのでしょうか。

データが分散してしまうことが最大の問題でした。例えば得意先マスターひとつとっても、営業部にも得意先マスターがあり、受託開発部にも得意先マスターがある。これでは、マスターといえません。やはり、ツギハギは良くないなということで、これは時間とお金をかけても、ちゃんとしたものを作ろう、部署ごとのシステム分立は止めて、会社全体の統一DBプラットフォームを構築しようということになりました。

EUCに見切りをつけたわけですね。

いえ、EUCの考え方そのものは、今でも正しいと思っています。やはり現場での利便性や使い勝手をよく知っているのは、現場で働いている人々ですからね。ただプログラムが分散するのは良いとしても、データが分散するのは良くなかった。せめてマスターぐらいは一箇所にまとめないと業務に支障をきたします。

また最近は、個人情報保護の観点からセキュリティがクローズアップされてきたこともあり、やはりマスター・データは一元管理が必要です。

ですが、マスターの統一やセキュリティへの配慮などの課題がクリアできた上であれば、入出力などフロントエンドの部分については、部署ごとに自由度を持たせても良いかなとは思います。

3. なぜアシストからOracleを購入したのか


その統一プラットフォームのDBとして、Oracleを選択した理由は。

それ以前は別のデータベースを使用していましたが、Oracleについては、受託開発で使用するケースも多かったし、今後はこれを社内で使った方が、ノウハウも貯まって良いだろうということで、Oracleに決めました。

Oracleの購入にあたり、アシストに問い合わせをされたようですが、Oracleを販売する数あるソフトウェア商社の中で、特にアシストを選んだ理由をお聞かせください。

これまで受託開発の仕事を通して、Oracleのコンサルタントとも色々知り合いましたが、その多くがアシスト出身者だったのです。そういうわけで、アシストには「Oracleのコンサルタントを多く輩出するほどの、専門知識が豊富な会社」という良いイメージがあったので、Oracle検討の際は、一応は問い合わせておいた方がいいだろうと考えたのです。ちなみに、アシスト以外にも、大手ソフトウェア商社や、ハードウェア・ベンダー系の商社にも問い合わせました。

そして最終的にはアシストからOracleをご購入いただきました。これは、アシストに対する「最初の良いイメージ」が理由でしょうか。

いえ、最終的にアシストから買おうと決心したのは、具体的な提案内容を聞いてからのことです。逆に言うと、もし提案内容が大したことがなければ、おそらくアシストからは買っていなかったと思います。

アシストから買わなかった場合は、どのようにOracle構築を進めていたことになるでしょうか。

弊社はソフトウェア開発会社なので、Oracleの開発経験もありますから、ある程度のシステムであれば、社内の人材で構築することが可能です。ということは、アシストには、ヴァルの技術者のスキルや発想を上回る「提案」を期待したということです。正直言って、アシストより安い値段で見積もりを出してきた会社もあったので、もしアシストの提案が、弊社の技術者の発想と同等あるいはそれ以下であったとしたら、アシストから買う理由はありません。その場合は、どこかから安くモノを買って、後は自社で組み上げていたことでしょう。

4. ヴァルの技術者の視点から見たアシスト


アシストからはどのような提案があったのでしょうか。

当時、弊社は、「駅すぱあと」のサポートの24時間受付を始めたこともあり、24時間365日、落ちないシステムが必要でした。その要件に対し、アシストからはOracleを使ったRAC(Real Application Clusters)の提案がありました。RACの仕組みは大変魅力的でしたが、それは弊社ではまだ未経験の分野でもありました。これは検証経験や実績の多いアシストの協力を得ながら構築した方が合理的だと、弊社の技術者も納得し、アシストからのOracle購入が決定した次第です。

技術者の納得、というと具体的には。

弊社の技術者にもプライドがありますから、アシストのOracle技術者に対しても、最初はどうしても値踏みするような気持ちがあるわけです。いろいろな質問を投げかけてみて、それにどう対応してくるのか。もし自分と同等もしくはそれ以下の技術や発想しかないのだとしたら、わざわざ教えを請う必要はありません。しかしアシストの技術者の話は、ことOracleに関しては、やはりすごかったのです。これはもう、一緒にRAC構築に取り組んで、そのノウハウを自社にも吸収したいものだと、そういう気持ちになりました。あとは、RACという全く未知の分野、新しいことにチャレンジしたいという、そういう気持ちにも後押しされました。

「新しいことにチャレンジしたい」……と言いますと。

技術者は新し物好きです。OracleのRACは未経験の仕組みだった。ならばトライしてみたいという、単純な話です。最初、アシストからは、「今回は、枯れたバージョンであるOracle 9iRACの方でいきましょう。その方が安全です」と提案がありましたが、結局は、新バージョンの10gを使いました。新しいバージョンの場合、それなりに、「初物ならではのバグ」もありますが、それは時間とともに解決していくことだと楽観していました。途中、問題に直面するとしても、その時はその時。それを乗り越えれば、また一皮むけるさ、と考えていました。ちなみに、実際には、10gはさしたる障害もなくきちんと稼働してくれました。

5. RACの実装を振り返って


実装はいつ頃から始めたのでしょうか。

2004年の10月ぐらいからですね。実装は、基本的には自分たちで行いました。アシストには、要所要所で、ノウハウ面の支援をいただきました。特に障害テストの際のノウハウ支援は貴重でした。RACは弊社にとって初めての試みだったので、どういうテストをしたらいいのかというノウハウがなかったのです。とにかく自分たちで色々組んで、行き詰まったら、アシストに問い合わせる。その繰り返しでした。

その後のRACに対する評価はいかがですか。

試行錯誤しましたが、期待通りの安定度です。しかし、購買ルートについては、もっと上手くやれていたかもしれないと反省する部分があります。

「購買ルートについては、もっと上手くやれていたかもしれない」というと具体的には。

システム構築に必要な要素を購買する際に、Oracleはアシストから、ハードウェアは別の会社からというように発注先を切り分けてしまったことで、トラブルが発生した時に、これはOracleが原因なのか、それともハードウェアが原因なのかといった、いわゆる「障害の一次切り分け」をするのが大変でした。この点は、今後アシストにもう一歩踏み込んで助言いただきたい部分でもあります。

6. ヴァル研究所が考える情報活用 − 「駅すぱあと」


ここから先は、「ヴァル研究所が考える情報活用」というテーマで、様々なお話を伺いたいと思います。ヴァル研究所での「情報活用」というと、まず何が思い浮かびますか。

まずは弊社の主力商品である「駅すぱあと」。これは鉄道の運行表であるダイヤ情報を正確に提供することで、リーズナブルかつ最適な路線・運賃を調べるお手伝いをすることを目指した製品ですから、これは一種の「情報活用製品」と言えるかもしれません。

情報活用には、情報の鮮度が求められます。「駅すぱあと」の場合も常に最新のダイヤを反映しなければならないと思いますが。

そのため、「駅すぱあと」は毎月バージョンアップをしています。

ちなみに、最新のダイヤ情報はどこから仕入れるのでしょうか。どこかからマスター・データを購入しているのでしょうか。

いえ、一次情報をもとに、ひたすら自力で調べています。ダイヤの調査も、昔は首都圏だけだったのでまだ楽でしたが、最近は全国のダイヤ改正に目を光らせていなければならず、なかなか大変です。路線や駅の統廃合もありますし。

また、「駅すぱあと」の主要ユーザは出張の多いビジネスマンですから、新幹線のダイヤや飛行機のダイヤにも気を配らなければなりません。特に飛行機のダイヤは季節変動が大きいので、神経を遣います。「駅すぱあと」の飛行機ダイヤが間違っていたために、出張に行けなく行けなくなるようなことがあってはなりませんから。

私が以前勤務していた会社では、出張などの交通費の精算基準は「駅すぱあと」でした。飛行機や新幹線を総務に頼んで手配するときも、「駅すぱあと」の探索結果をプリントアウトして手渡していました。

おっしゃるように、「駅すぱあと」が、交通費精算の「基準」として扱われている運用例も多いようで、なかなか責任重大です。

7. ヴァル研究所が考える情報活用 − 顧客からのフィードバック


ソフトウェア企業においても顧客の声は重要な情報源だと思います。「駅すぱあと」に対しては、例えばどんな要望が寄せられますか。

ダイヤ周りの話ですと、乗り換え・乗り継ぎの情報の部分でお声を頂戴することがありますね。 例えば、「**駅での電車の乗り換え情報、あれ実際は、一本前の電車でもOKなんじゃないの」といったものです。しかしこのような類のご指摘は、なかなか対応に苦慮します。

どのあたりに苦慮するのでしょうか。

電車の乗り換えにおいては、足が遅い速いで個人差があります。足が速い若者にとっては楽に間に合う電車も、ご年配の方にはそうはいかないかもしれません。どの程度の歩行スピードを標準採用するかは、なかなか判断しづらいところです。ただ基本的には、あまり足が速くない人の歩行スピードを基準にするのが、あるべき姿だろうと思います。

足の速さ以外にも、駅の構造に対する慣れ不慣れも重要な要素になると思います。例えば地方から東京に出張された方が新宿駅で乗り換えを行う場合、結構、迷うと思うのです。我々にしても、不慣れな大阪・梅田駅などでは乗り換えに戸惑うでしょう。それを考えても、やはり、不慣れな人を基準にして、余裕ある乗り換え時間を設定しなければいけないと考えています。万人に使われることを想定している「駅すぱあと」は、人にやさしいソフトでないといけませんから。

8. ヴァル研究所が考える情報活用 − 品質テスト


そのような人にやさしいソフトを作る上では、テスト工程も重要なのではないかと推測しますが、いかがでしょうか。

テストは非常に重要ですね。品質テストというと、例外テスト、所謂、意地悪テストがすぐ思い浮かびますが、それにも増して重要なのが、普通の使い方、普通の入力をしたときに、常識的に考えて妥当な反応が返るかどうかという、正常処理に関するテストです。想定範囲内の操作を行い、常識的な入力をしたはずなのに、反応が返ってこなかったとしたらユーザのフラストレーションも一気に高まるでしょう。

常識的な入力に対し、非常識な出力が出る…どういう場合にそのようなことが起こりえるのでしょうか。

機能追加を行ったときが危ないですね。その機能を追加したことで、以前は動いていた別の機能に悪影響が及ぶことがあります。以前は正常に動いていた機能なので、盲点となってテストの際に見落とされることがありえます。その製品がそのまま市場に出ると、常識的な入力に対し、非常識な出力が返ることになり、ユーザの不興を買うことになります。 そういう意味で、繰り返し、機能テストを行うことが重要なのです。

現在はどのような体制でテストを行っているのでしょうか。

「駅すぱあと」については、10数年の歴史の中で、様々なテスト・ノウハウが蓄積されており、それを元にした独自のテストロジックでテストしています。一方、「駅すぱあと通勤費管理システム」パッケージの方では、アシストから購入したQuickTest Professionalを使っています。頻繁な繰り返しテストや、先に述べたような回帰テスト(リグレッション・テスト)でプログラム変更時に変更によって予想外の影響が出ないかどうかを調べるときには、大変便利ですね。

9. ヴァル研究所にとっての情報活用 − まとめ


最後に総論としてお聞きしたいのですが、ヴァル研究所にとっての情報活用とは。

なかなか一言でまとめるのが難しい質問ですが、ヴァル研究所の会社価値ということで置き換えてお答えすると「ナビゲーションという価値を主軸にして、仕事や生活の役に立つソフトを作る」ということになるかもしれませんね。「駅すぱあと」は、まさにナビゲーションソフトですし、他の製品、例えば「健康生活ナビ」もやはりナビゲーションのソフトです。ナビゲーションとは、情報を元にして利用者を適切な方向に導く(ナビゲートする)ことですから、これはこれで情報活用の一種ではないでしょうか。

今後もヴァル研究所は、「ナビゲーション」という自社の強みを活かしていきたいですね。何でもやれます、やりますという姿勢では、いたずらにコスト戦争に巻き込まれるだけですから。

その他、今後のアシストへの期待などがあればお知らせください。

今述べたとおり、弊社は今後もナビゲーションを主軸として様々な製品を開発していく所存ですので、その取り組みをOracleなどのソフトウェア活用ノウハウを通じて、下支えしていただければ幸いです。また弊社の受託開発事業においても、今後、Oracleが絡む案件が出てきた時には、ぜひアシストから吸収したRACのノウハウを活用したいですね。アシストには、今後も、常に我々の一歩先を進むよう、パッケージソフト活用の技術と専門知識を深めていってほしいと思います。




※現在、ご利用いただいている製品、サービス
  ・リレーショナルDB(可用性、バックアップ・リカバリ~実装支援):Oracle
  ・テストツール:Mercury QuickTest Professional
  ・開発ツール:PowerBuilder
  ・各種保守サポート

※ (株)ヴァル研究所のWebサイト
※ 取材日時 2006年1月【取材協力:(株)カスタマワイズ】

「お客様の声」の新着コンテンツ


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る