株式会社ギガスリートCEO大垣様インタビュー

1. なぜ貴社の製品・サービスを創ることになったのでしょうか？

最初にリリースしたサービスは野球スコア管理システム「G-SCORE」です。スコアブックを持ち運ばなくても、携帯からスコアをリアルタイムに入力することができ、当時はガラケーからの入力を主に考えたUIでした。

その後、写真やコメント機能、ランキング機能、試合マッチング機能などを備えた「G-LEAGUE」「G-LOCKER ROOM」「G-DOGOUT」等をリリース。そして、これらのサービスをより多くの人に知っていただくためのコンテンツ発信プラットフォームとして「G-TIMES」「G-MOMENT」を作りました。

日本のスポーツは、アメリカ・ヨーロッパに比べて、システム志向（ITシステムに限ったシステムという意味ではなく仕組みという意味において）が弱く、そのため実務でもテクノロジーの力を活用することに大きく遅れを取っています。

そして日本ではビジネスとしてのプロスポーツも収益は頭打ちでただ漠然とした危機感だけがあり、大きな変化をもたらすようなアクションは常に先送りになってきました。

ならば事例としてテクノロジーをフル活用した場合の”ビフォーアフター”を見せることで、意識の牽引ができるかもしれない、と考えました。先鞭して自ら最も組織化が弱く土台が脆弱な領域（=アマチュア草野球）で大きな変化をもたらすことを実証できれば、「それを転用すればいい」と皆が考えてれるようになるはずで、そうなれば成功だと思ったわけです。

2. どのような経緯でCEOになられたのでしょうか？

創業からずっと、システム開発も経営も私が行っています。ただ、開発・経営を分けるべき、もしくは、統一すべきという考えは特にありません。

自分よりもこの人に一任したほうが生産性も上がる、優れたサービスを生みだすことができるという方に出会うことができれば、もちろんお任せするでしょうし、今の体制に関しては今後変わることはあると考えています。

プログラミングを始めたきっかけは？

プログラミングを始めたのは高校生の頃です。情報科学科で情報処理を専門に学んでいました。ITという言葉もまだなく、インターネットもまだ普及していない時代でした。言語的には、当時はC言語全盛期でした。

高校2年生でプロを目指して野球渡米し、その間はひたすら野球をしていました。大学には入学しましたが、渡米費用を奨学金の一部で賄うことが主な目的でした。

6年間、アメリカで野球選手生活を続けましたが、2004年に帰国しました。帰国後、創業するまでには、父親が教師だった影響もあり、情報システム関連の専門学校で教師をしていました。その後、株式会社ワークスアプリケーションズに製品企画開発エンジニアとして入社しました。

株式会社ワークスアプリケーションズへの入社

いくつかの会社をあたりましたが、「何をするのか」「（入社してくる人に）何を求めているのか」が、他のソフトウェア会社と比較するとかなり明確でした。「既存のソフトウェア業界を変える」という挑発的な想いを聞き、入社を決断しました。

人事・給与システムの開発を行いその後、人事採用に関わることになりました。社内で誰もやったことがない領域だったこと、予算も大きくつけられやりがいがありそうだと思いましたので自ら手を挙げました。

どうしたら学生に広く知ってもらえるか、優秀な学生を集めることができるかという施策を出し、退職の前には、インド・中国・北米での海外採用を始め、上海・シンガポールオフィスを立ち上げ、学生の受け入れ体制を作りました。

採用に関わるようになると、仕事ではコードを書くことがなくなりました。ただ、元々好きなプログラミングへの興味は潰えないですし、個人的にコーディングをしつつ、システムを作って形になり、今の事業につながるアイデアも浮かんでいました。

いよいよ、本格的にサービスとして大きくしたいという気持ちが生まれ、そのタイミングで退職、創業を考えるようになりました。

3.大垣様が会社を立ち上げられてから、どのような開発体制の変遷がありましたか？それに伴うご自身の役割の変化はございましたか？

創業前から私個人でサービスを開発していました。サーバサイドもフロントエンドもすべて行います。チームになってからもその方針は同じで、それぞれ各人がサーバサイドからフロントエンド、DB設計まですべて行います。

技術面では様々なものを試しています。プログラミング言語だけでもPHP → Python → Julia → Scala → Common Lisp → OCaml → Haskell、TypeScript → Dart → Elm と変遷し、それぞれの言語のコンセプトを理解する度に更に理想に対する欲求は高まり「何か違う」と感じ、最終的に現在はHaskell + Elmとなっています。

技術の意思決定をする際には、技術トレンドも参考にはしますが、あまりそこに拘らず、もっと大局で捉えるようにしています。言語コンセプトの優位性・高い抽象の実現、の方が重要ではないかなと考えています。それら技術を扱っている（経験している）エンジニアの総数は、昔ほど重要ではないかなと考えるようになりました。これからはよりその傾向が強くなると考えています。

すでに普及しているプログラミング言語の方がサンプルは多いですし、他者との情報交換もしやすく、現時点で十分なマーケットシェアがありニーズも高ければ職を得やすくなるので、技術者の直接のインセンティブになりやすくモチベーションも上がるかもしれません。

しかし、それらの言語が多くの人に使われ普及してるのは、決して言語として優秀で生産性が高いからなのではなく、初学者〜中級者にとって理解しやすいものであるから、という面の影響が大きいのです。

『何ができるようになるのか』よりも『何を簡単にしてくれるのか』の方が重要だと考えています。

これは、最終成果が全く同じであるという前提の上で、そのプログラミング言語を選択することによって『何ができるようになるか』という議論よりも、『何をもっと簡単にしてくるのか』の議論の方が、ずっと重要だということです。

そして巷に蔓延している「『どのプログラミング言語を使うか』は所詮道具なんだからなんでもいいじゃないか」という意見には同意しません。その意見は、人間の思考は使う道具から多大に影響を受けることを軽視し過ぎています。

人はドリルを持つと、見るもの全てを『穴を開けるべきものかどうか』という視点で捉えるようになってしまいます。

例を挙げるならば、オブジェクト指向型プログラミング言語を用いると、まずは「これはどのようなオブジェクトに設計すればいいか」と考え始めてしまうようなものです。

そうならないために常に情報提供を心がけ、ソフトウェア技術だけでなく、数学、物理、哲学なども学び続け、有益な刺激を得続け与え続けることが私の役割です。