始まりはMS-DOSの黒い画面だった

1990年代初頭。まだWindowsという言葉が一般に広まる前、日本のオフィスにあるコンピュータの多くはMS-DOSというOSで動いていた。真っ暗な画面に白い文字が並び、コマンドを打ち込まなければ何も始まらない。そんな時代に、私は一人のプログラマー見習いとして、小さなソフト会社でのキャリアをスタートさせた。

当時、私が担当していたのは計測制御系のソフトウェア開発だ。工場や研究機関で使われる複雑なデータを処理し、グラフ化して表示する。今のようにインターネットで情報を拾うことも、AIにコードを聞くこともできない。分厚いマニュアルを片手に、C言語やアセンブラと格闘する日々。それが私の「技術」との最初の出会いだった。

想定外の転換：開発室から全国の営業現場へ

しかし、運命の歯車は思わぬ方向に回り始める。入社して間もなく、私は自社開発ソフトの企画と全国営業を任されることになったのだ。「プログラマーなのになぜ営業？」という戸惑いよりも、自分が関わったソフトがどう世の中で使われるのかを見たいという好奇心が勝った。

営業先は、名立たる大企業の研究開発、設計、生産、そして品質管理部門。相手にするのは、その道のプロフェッショナルである技術者や研究者たちだ。20代前半の若造が、日本の最先端を支える人々を相手にプレゼンを行う。プレッシャーは相当なものだったが、そこで私はある「壁」にぶつかる。

巨人と闘い、知ったこと

当時、私たちの最大のライバルは、アメリカの巨大企業、テキサス・インスツルメンツ（TI）社だった。資金力も知名度も圧倒的な多国籍企業に対し、私たちは知る人ぞ知る日本のベンチャー。機能比較表だけで勝負すれば、数人で作ったソフトが勝てるはずもなかった。

しかし、現場に足を運び、研究者たちの「困りごと」を深く聞いていくうちに、あることに気づいた。彼らが求めていたのは、究極の多機能ではなく、自分の目の前にある計測機器とスムーズに繋がり、思い通りのグラフが今すぐ出るという「実直な解」だったのだ。

私は開発責任者の部長と二人三脚で、現場の声を吸い上げてはソフトのUIに反映させ、また翌日には別の大企業へ向かう。MS-DOSベースの限られたリソースの中で、いかに直感的なグラフィックUIを実装するか。そこで培われた「技術を事業に翻訳する力」が、私のキャリアの根底に流れることになった。

「技術×営業」が教えてくれたもの

この4年間の激動期で私が得た最大の資産は、プログラミングスキルそのものではない。「技術がわかる人間が、現場の痛みを知り、それを売れる仕組みに翻訳する」ことの圧倒的な価値だ。

どんなに優れたソースコードも、それが誰かの課題を解決し、対価となって戻ってこなければ、事業としては継続できない。逆に、技術の中身を理解していれば、表面的なセールストークではない、本質的な提案ができる。

AI時代に立ち戻る原点

今、私はAIエージェントの会社「Sparx」を運営している。30年以上経ち、ツールはMS-DOSから最新のLLMへと変わった。しかし、本質は何も変わっていない。

「最新のAIを使えば何でもできる」という理想論ではなく、クライアント企業の現場で誰が何に苦しみ、どうすればその負担をAIが肩代わりできるのか。その「仕組み」を作ることこそが、私の役割だ。

第1章のプログラマー見習いから始まった旅は、紆余曲折を経て今、AI時代という新たなステージに立っている。技術と営業、その中間にある「仕組み化」の重要性を、私はこの20代の原体験から学び続けている。

Founder Principles 1: Build systems, not tasks. (タスクではなく、仕組みを作れ)
今のSparxが提供しているのは、単なる自動化ツールではなく、人がより人間らしい決断に集中できるための「働く仕組み」そのものだ。