「世界一の変換率だ」

シアトルのマイクロソフト本社。SQL Serverチームのエンジニアたちは、日本からやって来た小さなソフトウエア会社の技術を前に、そう声を上げた。

マイクロソフト自身の移行ツールでも届かなかった変換精度。やがて両社は、ソースコードを共有し合いながら共同で開発を進める関係になっていく。

なぜ彼らはマイクロソフト本社に認められたのか。

答えは、最新技術を誰より早く追いかけたからではない。多くの企業やエンジニアが「古い技術」と見向きもしなかったMicrosoft Accessと向き合い続け、現場で積み重ねた知見を武器にしてきたからだ。

AI時代になった今も、その姿勢は変わらない。流行に飛び付くのではなく、一つの領域を30年以上徹底的に深掘りし、誰も行かない場所で価値をつくり出す――。インフォース代表取締役・濱松 毅さんに話を聞いていくと、「技術の選び方」以上に、「戦う場所の選び方」が、エンジニアのキャリアを大きく左右することが見えてきた。

インフォースグループ
代表取締役社長
濱松 毅さん

埼玉県出身。学生時代に起業し一度失敗を経験するも、小さな企業への就職を経て再起。インフォースを設立し、米国マイクロソフト社の開発チームに参加するなどAccess開発の第一人者としての地位を確立した。プライベートでは学生時代から続ける剣道に打ち込み、最近七段に合格。文武両道を地で行く経営者である

なぜMS本社は、日本の小さな会社を呼んだのか

──マイクロソフト本社から「シアトルへ来てほしい」と声が掛かったそうですね。

そうなんです。ただ、いきなり本社から呼ばれたわけではありません。

きっかけは、取引先の金融機関の方が、マイクロソフト本社のディレクターを紹介してくれたことでした。「せっかくだから」と、開発していたAccess→SQL Server移行ツールの話をしてみたら、そのディレクター自身が驚いた様子で、「ぜひ社内で聞かせてほしい」と食いついてきたんです。

──それで、シアトルまで行くことになったと。

はい。実は彼らも、技術の壁をなかなか崩せずに悩んでいて、ちょうど変換率の高いツールを探していたタイミングだったんです。それで実際にシアトルへ足を運んで、SQL ServerチームとAccessチーム、両方に会うことになりました。

──実際に会ってみて、何か発見はありましたか。

印象的だったのは、社内に二つのデータベースがあることを、マイクロソフト自身がずっと課題として捉えていたことです。AccessとSQL Serverは、もともとつながりを想定して作られたものではありませんでした。

Accessはビル・ゲイツが自分で作ったという話を、Accessチームの人から直接聞きました。一方のSQL Serverは、Sybase(サイベース)という会社を買収して手に入れたもの。だから、そもそもアーキテクチャが違うんです。SQLの言語一つとっても別物。「じゃあ、それをどう合体させるか」というのは、マイクロソフトほどの会社でも簡単には答えの出ない、根の深いテーマだったんですよね。

その解決策として社内にあったのが、SSMA（SQL Server Migration Assistant）とアップサイジング ウィザードでした。

どちらも「ボタン一つでAccessとSQL Serverを接続します」とうたっている機能でしたが、私たちが実際の案件で見てきた限りでは、完成度は感覚的に15〜20％程度。テーブルを変換できるくらいで、実際の業務システムをそのまま移行できるレベルではありませんでした。

だからこそ、移行しようとしてもうまくいかず、私たちのもとへ相談が集まってきたのです。

世界一の変換率は、「現場」が育てた

──マイクロソフトほどの会社でも解決できなかった課題を、なぜインフォースは解決できたんでしょう。

一言で言えば、私たちは製品を作っていたのではなく、現場を見ていたからです。

マイクロソフトは世界中の誰もが使える「製品を作る会社」であって、「個別の業務システムを作る会社」ではありません。社内でもアップサイジングの研究はされていましたが、実際の現場システムを大量に触っていたわけではなく、事例数が絶対的に足りていなかった。その差が、そのまま変換精度の差になったのだと思います。

──何がそんなに難しかったんですか。

「できることが多すぎるAccess」と、「堅牢性のため制約が多いSQL Server」では、そもそも世界観が違いすぎるんです。

Accessには、大きく四つの弱点があります。複数人が同時に使うと壊れやすい「排他制御」の弱さ。セキュリティーやバックアップが標準では備わっていないこと。2GBという容量制限。そして「Webができない」こと。

マイクロソフト自身も「データ アクセス ページ」という機能で解決しようとしましたが、中途半端なまま終わっています。だからこそSQL Serverへ移行したい、というニーズが生まれるわけですが、いざ変換しようとすると、今度は別の壁にぶつかります。

Accessは、半角カナのようなSQL Serverでは扱えないデータも、そのまま処理してしまうんです。堅牢さのために制約を持たせているSQL Serverに対して、Accessは「ユーザーを甘やかしてくれる」ソフトなんですよ。設計が多少中途半端でも、なんとなく動いてしまう。

しかも、多くのAccessシステムはExcelの延長線で使われています。「とりあえず動けばいいや」という感覚で現場が自作してきたものだから、設計ルールも統一されていない。それをボタン一発で完全変換するのは、正直ほぼ不可能でした。

実は、私たち自身も最初から今のやり方にたどり着いていたわけではありません。最初に試したのは、「Accessの中でアップサイジング ウィザードを作る」という方法でした。Accessが得意なAccessに、Access自身を変換させようとしたわけです。

でも、それは早々に「方向性として間違っている」と気付きました。そこで、C#でゼロから作り直すことにしたんです。そこからクオリティーは一気に変わりました。ただ、それでも「どうしても完璧にはできない」という壁が残ったんですよね。

──その壁はどうやって突破していったのですか。

地道な積み重ねで埋めていくしかありませんでした。

一件一件、実際の案件で発生した問題を潰しながら、「このテーブル構造ならこう変換する」「この種類のクエリはこう書き換える」というパターンを、辞書のように蓄積していったんです。単にツールで機械的に置き換えるのではなく、「これは何のための処理なのか」という根本まで立ち返る。ときには、顧客の要件レベルから作り直すこともありました。

そうやって少しずつ精度を上げていって仕上げたのが、世界初のAccessからSQL Serverへのアップサイジング専用ソフトです。冗談交じりに「現状打破激震」と名付けたりしましたが、海外では発音しづらかったようで、途中から名前を変えたのもいい思い出です(笑)。

案件をやればやるほどツールも育っていく。今でいうパソコンやスマートフォンの”変換辞書”みたいなものです。現場で得た知見が、一つずつ積み上がっていったんですね。そうやって仕上げたツールを引っさげて、いよいよシアトルへ向かうことになったんです。

「世界一の変換率だ」

──それを、そのままSQL Serverチームにぶつけたわけですね。

そうです。プレゼンをすると、当時Accessのアップサイズを担当していた人が出てきて、「これは世界一の変換率だ。見たことないし、うちもできなかった」と。

その場で「ちょっと中に入ってやってくれ」という話になって、次期製品を先行開発するTAP(Technology Adoption Program)というチームに加わることになったんです。

同時に、あのとき感じたのは「アメリカらしいな」ということでした。どこの馬の骨か分からないベンチャーでも、いいものを持ってくれば、正当に評価して採用する。こういう巡り合わせは、日本ではなかなか起きにくいことかもしれません。そういう意味で、「面白い国だな」と思いましたね。

私たちからすると、特別なことをしたつもりはありません。目の前のお客さまが困っている。だったら、次のお客さまは困らないようにしよう。その積み重ねでした。

──「中に入ってやる」というのは、具体的にはどういうことなんですか。

Accessの中身を、かなり踏み込んだレベルまで見せてもらえたんです。それってなかなかないことで。実際の作りを見ながら「ああ、ここにこう組み込むのか」というのを掴んでいきました。

当時の開発チームはかなりの大所帯で、半数以上がテスターという体制でした。個室が並んでいて、あちこちの部屋を行き来しながら情報交換する。英語もそんなに話せなかったので通訳を入れてもらいましたけど、コードを書いて見せると「ああ、なるほど」と伝わる。技術者はコードで話す、とはよく言ったものです。

ただ、いい思い出ばかりではありません。Accessチームと1年半ほど一緒にやっていたところで、当時CEOだったスティーブ・バルマー氏が「SharePointを介してAccessとSQL Serverを接続する」という方針を打ち出したんです。それをきっかけに、「ブラウザ上でAccessのシステムを再現しよう」という大きな方向転換があり、それまで積み上げてきたものを一度作り直すことになりました。

結果として、そのプロジェクトは私たちの手を離れていくことになったんです。個人的には、あのとき目指していた形は、今もまだ完全には実現できていないんじゃないかと感じています。

西 和彦だけは、この未来を見ていた

──SharePointの方針転換で、いったんプロジェクトが止まってしまった、と。

そうなんです。ただ、私たち自身はまだニーズが解決していないと思っていたので、マイクロソフトとは別に、自分たちだけでも解決策を探るようになりました。そんな中で出会ったのが、米マイクロソフト元副社長の西 和彦さんです。

──アスキー創業者の、あの西 和彦さんですか。

はい。あるところで知り合って、「マイクロソフト本社でこういうことをやっているんです」という話をしたら、日本で話しても「遠い世界の物語」みたいな反応しかされなかったのに、西さんは一瞬で理解してくれました。孫 正義さんと並んで、時代を作ってきた人ですから。

当時、私たちが考えていたのは、AccessそのものをOpenOfficeやLibreOfficeの上に作り直し、弱点を改良したソフトを自分たちで世に出す、という構想でした。それを西さんに話したところ、「”Accessのためのサービスパック”という意味で、『Service Pack for Access』にしろ」と言われたんです。「そうすれば、いつの間にか、みんなのAccessがこっちに置き換わる」と（笑）

──かなり大胆な発想ですね。

そうなんですよ（笑）。実際にやったらマイクロソフトに睨まれていたと思いますけど、それくらいの発想力の持ち主でした。

西さんはその時、こうも言っていました。「Accessはまた注目されるよ」と。ずっとデータベースを持っていなかったマイクロソフトが開発者向けソフトとして生み出したAccess。後にOfficeに組み込まれてVBAという共通言語になっていった……そんな歴史まで含めて、西さんは誰よりもリアリティーを持って理解してくれていたんです。

──単なる「古い技術」ではなく、その技術が生まれた歴史や背景まで理解していたんですね。

そうです。西さんと話して痛感したのは、「技術の表面的なトレンドではなく、その技術が生まれた背景や、ユーザーに与えた本質的な価値を見抜くこと」の重要性でした。

流行り廃りではなく「技術の思想」を押さえているからこそ、10年後、20年後にその技術がどういう形で生き残るかの構造が見えるんです。

エンジニアが「戦う場所」を選ぶ時、その技術が持っている背景や思想まで掘り下げられているかどうかが、10年後の生存率を分けるのだと思います。

──SharePointへの方針転換のときも、西さんに相談したんですか。

はい。あの方針転換には納得がいっていなかったので、西さんに間に入ってもらって、ビル・ゲイツ氏に「この方向性は違うんじゃないか」と直接伝えてもらいました。ただ、そのころにはビル・ゲイツ氏自身がもう経営の第一線から退いていて、動かすのは簡単ではなかったですね。

──それでも、西さんとの関係はずっと続いていたんですね。

西さんは、私たちがマイクロソフト本社と組んでいたころからずっと応援してくれていました。その後、私たちが世界で初めてAzureへのアップサイジングを手掛けたときの協業セミナーにも、ご本人に登壇していただいたんです。

Accessがどんな歴史をたどってきたか、なぜこの領域に価値があるのか、西さんの言葉で語ってもらった内容で、 今も弊社のホームページで見ることができます。

競争相手がいない市場は、自分でつくれる

──シアトルとのやり取りが始まって、会社としても変わっていったんでしょうか。

そうですね。今、私たちは約2,000社のお客さまと受託開発でお取引していますが、その全てが直接取引なんです。大企業だけでも100社ほどありますが、そこも例外なく直接。中小のソフトウエア会社としては、なかなかない話だと思います。

──それは、なぜ実現できたんですか。

Accessは、あらゆる現場に浸透しています。でも、そこで起きている問題を解決できる会社は、ほとんどない。だから、困った企業は結局うちに直接来るんです。マイクロソフトからも、直接仕事が来ます。

象徴的な例が、あるメガバンク系の生命保険会社の案件です。全国1,500の拠点で4,000人が使うAccessシステムをクラウド化したいという話が、マイクロソフトとAWSの両方から、ほぼ同時に持ち込まれたことがありました。

なぜ同じ話が両方から来たのか。理由は単純で、マイクロソフトとAWSはその案件でコンペをしていたんですが、どちらが受注しても、実際の開発を任せられる先はうちしかなかったんです。

──マイクロソフトからすると、なぜ自社で完結させずにインフォースを頼るのでしょう。

マイクロソフトのビジネスモデルは、ライセンスを売ることです。でも「SQL Serverを買ってください」「Power Platformを買ってください」と言うだけでは、誰も買いません。「これを使ってこういうシステムを作るから、ライセンスを買いましょう」というところまで提案できて、なおかつ実際に作れる会社が必要なんです。それができるのが、うちしかなかった。

言ってしまえば、マイクロソフトのブランド力と信用力とネットワークを、タダで使わせてもらっているようなものですよね。こんなに強力な営業マンはいません(笑)。その代わり、こちらはお客さまと直接つながることができて、Accessの次のステップになる、AI活用やBI、クラウド化まで、継続して提案できる関係になります。

Accessという、他社が「もう古い」と見向きもしない場所を入り口にしているからこそ、競合がほとんどいない。オセロでいう「角」を一つ取ってしまえば、そう簡単には動かされないポジションになる。それが、私たちの一番の強みだと思っています。

“終わった技術”は、本当に終わっているのか

──ここまでの話を聞いても、「でもAccessって、もう終わった技術ですよね」と思う読者は少なくないと思います。

確かに、新しくAccessでシステムを作るケースは昔より減っています。でも、「新しく作られなくなった」ことと、「現場からなくなった」ことは別なんです。

──どういうことでしょう。

企業には、10年、20年、中には30年以上前に作られたAccessの業務システムが、今も現役で動いています。実際、先ほどお話しした生命保険会社の案件も、長年使われてきたAccessシステムをどう次につなぐか、という相談でした。

販売管理や在庫管理、顧客管理など、日々の業務に深く組み込まれているので、「古いから」という理由だけで簡単に置き換えられるものではありません。

それを裏付けるように、Microsoftは現在もAccessのサポートを継続しています。2024年版Officeに含まれるAccessのサポートは2029年までと発表されていますが、これは現行バージョンのサポート期限を示したものであり、Accessそのものの終了を意味するわけではありません。

むしろ現場では、「今あるAccess資産を、どう次の環境へつないでいくか」という相談が今も増え続けています。クラウド化やモダナイズのニーズは依然として高く、私たちもこの仕事はまだまだ続いていくと考えています。

──簡単に切り替えられるものでもなさそうですね。

そうなんです。企業が困っているのは、「新しい技術を導入すること」だけではありません。今ある業務を止めずに、どう次の環境へつないでいくか。そこに一番大きな難しさがあります。

一度ブラウザベースのシステムへ移行しても、「この業務はAccessの方が使いやすい」と結局残るケースもあります。現場には、理屈だけでは割り切れない事情があるんです。

──だから、今でもAccessに関する相談が続いている。

はい。最近では「クラウドへ移行したい」「Azureと連携したい」といったご相談も増えています。昔と同じことを続けているわけではありません。お客さまが次の環境へ進めるように、その時代に合わせて支援の形も変わっています。

流行は消える、でも課題は残る

──お話を聞いていると、Accessを見ているというより、お客さまの業務を見ている印象を受けます。

まさにそうです。私たちにとって、Accessは目的ではありません。目的は、お客さまの業務を止めないことです。

さっきの生命保険会社の案件も、それが伝わったから選ばれたんだと思います。製品を売ることではなく、「この業務を理解している会社なら任せられる」と評価していただけたから、マイクロソフトもAWSも、うちに話を持ってきてくれたんだと思っています。

私自身、「この技術だからやりたい」という発想は、あまりないんです。お客さまが困っている。その課題を解決し続けてきたら、結果として30年以上、この分野に携わっていました。私にとっては、その順番なんです。技術そのものを追い掛けていたら、今頃は違う仕事をしていたかもしれません。

──濱松さんは30年以上一つの分野を掘り続けてこられましたが、最初からそういうキャリアを描いていたわけではないんですね。

ええ、全然そんなことはありません。ただ、長年この業界を見てきて、「流行に賭ける怖さ」もたくさん見てきました。

例えば、私が会社を立ち上げた頃は、「これからはiモードの時代だ」と言われていました。優秀なエンジニアも資本も、みんなそこへ集まっていたんです。でも、今はどうでしょう。iモードもガラケーも、もうありません。

一方で、「もう終わった技術だ」と30年前から言われ続けているAccessは、今も企業の現場で使われ続けています。

──多くのエンジニアは「次に何を学ぶべきか」「流行の技術を追わなければ取り残される」と考えがちですが、流行そのものではなく「何を解決するか」が大事だと。

そうですね。もちろん、お客さまの課題は時代によって変わります。AccessからSQL Serverへの移行もありましたし、クラウド化もありました。最近ではAIの活用もあります。私たちが扱う技術も、その時々で変わってきました。でも、「お客さまの課題を解決する」という軸だけは、一度も変わっていません。

流行を追うことが悪いとは思いませんし、新しい技術を学ぶことも大切です。でも、それだけでは、いつかまた次の流行が来て、そのたびに振り回されてしまいますから。

AI時代に問われるのは、「AIを使える人」ではない

──「流行にとらわれない」という考え方は、生成AIが当たり前になった今でも変わりませんか。

変わらないですね。もちろん、AIは素晴らしい技術ですし、私たちも積極的に活用しています。でも、正直に言うと、「AIをやっています」と口にするのは、少し恥ずかしいとさえ思っているんです。

──それは、どういう意味でしょう。

パソコン1台あれば、誰でも同じことができてしまう。優秀な人も、お金を持っている会社も、世界中にいくらでもいます。そんな相手と真っ向勝負して、たとえ一瞬勝てたとしても、面白いと思ったらすぐひっくり返される世界なんです。

だから大事なのは、「どんな課題を解決したいのか」という自分たちの軸の方です。私たちは「AI会社になろう」とは考えていません。今取り組んでいるのは、「Accessの課題をAIで解決できないか」ということ。例えば、長年難しいとされてきた変換作業を、AIでもっと自動化できないか。そこには大きな可能性があると思っています。誰もやっていないことですから。

──30年以上この領域を続けてきた今、ご自身の強みはどこにあると考えていますか。

一つは、向こうから仕事の依頼が来ることです。ただ、それは技術力だけで選ばれているからではないと思うんです。

そもそも、私自身はガチガチのエンジニアではありません。だからこそ、技術そのものに盲目にならず、常に「素人であるユーザーの代弁者」でいられたのかなと思っています。

技術を極めることは素晴らしいですし、最新のAIツールを使いこなす知識も当然必要です。ただ、それは半年も経てば誰もが使える「前提条件」になってしまう。その時、差がつくのは「誰の、どの泥臭い現場課題と最新技術を接続できるか」です。

私たちがAccess×AIに取り組んでいるように、一見誰も行きたがらない「レガシーな現場」や「負の遺産」にこそ、最新兵器を掛け合わせた時の巨大なブルーオーシャンが眠っている。流行の技術を追うエンジニアほど、あえて「誰も見向きもしない泥臭い場所」に足を運んでほしいですね。そこが、自分だけの無敵の陣地になりますから。

取材・文／福永太郎、玉城智子、撮影／桑原美樹　編集／玉城智子（編集部）