編集部より
ここからは、セッション後半のパネルディスカッションの模様をお送りします。
「STUDIO」「Progate」――サービスを作ったきっかけは？
横溝：まずは、サービスを作ったきっかけから聞かせてください。
甲斐：コードベースのデザインツール「STUDIO」を作っています。デザインするだけでコードでできているプロダクトが作れるツールで、簡単にWebサイトを作成可能です。もともとはiOSエンジニアでしたが、人手不足でデザインも担当するうち、開発と両方ができるようになりました。
アプリやWebサイトはデザインを作ってからコードを書きますが、単純に面倒だし、複数で作業しているとコミュニケーションミスが発生しがちです。デザインデータは基本的にイラストベースやレイヤーベースのもので、コードで作るものはWebサイトだとボックスモデルという積み木みたいな構造、つまり構造が違う。デザイナーはプロダクトのデザインをしているはずなのに、構造の異なるものをデザインしていることがおかしいと思ったんです。そこで、実際のプロダクトにでき上がるコードの設計をもとにしたデザインツールを作りたいと考えたのがSTUDIOを作ったきっかけです。
現在、STUDIO 2.0という新しいバージョンのアーリーアクセスをリリースしています。複数選択や共同編集などの機能を一から作り直したことによって、かなりバージョンアップされました。
加藤：オンラインのプログラミング学習サービス「Progate」を初心者向けに提供しています。4～5年前にリリースしたのですが、当時僕はまだ大学4年生で、プログラミングがまったくできず、勉強するリソースも見つけられない状態でした。「どうすれば自分の作りたいものを作れるのか」といったところでつまづいていたので、プログラミングをやったことがない人でも、自分の作りたいものを作れるような世界を作りたいと考えたのがきっかけです。Progateでエンジニアを育て上げていきたいという思いでがんばっています。
プログラミングを始めたきっかけは、大学の情報系の授業でC言語を習ったこと。当時はスマホが出始めた頃で、アプリを作って毎月稼いでいる友だちもいました。僕もどうせプログラミングをやるならC言語を極めて、アプリを作ってみようと思ったんです。
ところがC言語でプログラミングができるようになると、Webサイトを作るにはHTMLやRuby on Rails、アプリならObjective-Cなどの知識やスキルが必要だと気づきました。僕のような初心者が、目的を持っていたとしても何を学べばいいのかわからないのではないか。こうした課題感をそのころから持ち始めたんです。そして、誰でも簡単に始めることができ、何を学べばいいか迷わないサービスを提供したいと思って作ったのがProgateです。
共同経営者と出会ったきっかけ、一緒に始めたきっかけは？
横溝：最初に会社を立ち上げた際の共同経営者と出会ったきっかけや、一緒にやり始めることになったきっかけを聞かせてください。
甲斐：もともとSTUDIOはOHAKOというデザイン会社の中で、社内の会社として作ったんですね。今の代表と出会って買い戻しました。
加藤：僕の場合はお互いに初心者だけど、悩んでいる人を探していて出会ったのが共同創業者です。彼がすごく優秀だったので教えてくれる人も見つけてくれたし、起業するときも2人で相談し合って、2人でエンジニアとしてやっていこうとなりました。
技術選定やチームの開発の進め方――こだわりポイントは？
横溝：技術選定やチームの開発の進め方について、こだわっていることなどを教えてください。
甲斐：STUDIOは基本的にWebサイト上で使えるアプリケーションです。開発にはVue.jsを使っています。最初はプロトタイプ的なものから作るんですが、気軽にどんどん作って壊せることが大事だと思っています。最低限のものは作らなければいけない上で、いかに効率良く作れるかというところかなと。
加藤：僕らはまず背景を考えます。Progateの場合は自分たちの負の体験をもとにして、「それをどうやったら良くできるのか、ユーザーはこう入ってきて、こう迷わずに選んで、こう学んでいって、こうやってほしいよな」というフローを最短で検証したいんですよね。
当時はスタートアップでお金もなかったし、単純に自分が一番書きやすいからPHPを選択しました。もっとたくさんエンジニアを採用したくなった際に、当時はRuby on Railsを書きたいエンジニアが多かったので、そちらに書き変えることもありました。
また、以前はjQueryで書いている部分もありましたが、状態管理が大変で、バグも頻発していました。工数はかかりますが、中期的には体験の向上につながるからと、そこはReact Nativeに書き変えましたね。
Progateのスマホアプリを開発する際に、王道のSwiftやJava、Kotlinで書くのか、React Nativeを選ぶかで悩んで、React Nativeを選択しました。React Nativeでは実現できない部分や、どうしても遅くなってしまう部分があったのですが、僕らが書きやすかったというのが一番の理由です。自分たちが早く書けて、細部までこだわれるほうがいいだろうと。この技術が絶対いいというのはなくて、自分たちが持っているアセットとそのときの状況、費やせる時間を総合的に考えるしかないと思ってます。
必要に応じて書き変えることも結構あります。当時はRuby on Railsがいいと思ったのですが、もう少しレスポンスを早めてユーザー体験をよくするため、今はGoを選択して進めています。
最初はとにかくスピードが大事なので、一番早く最低限の目的を実現できる技術を優先します。それがユーザーにも受け入れられてから、リソースも余裕があるときであればより細部にもこだわって技術選定していますね。
横溝：それは誰がどの技術を、どういうフローで進めて採択までいたるんですか？
甲斐：僕らはまだ数十人くらいの会社なので、CTOともう1人、すごく技術に強い人で決めています。CTOがユーザー体験などの現実的な部分を考え、技術に強いエンジニアが絶対この技術がいいという意見を出し、2人が話し合い、落ち着いたところで採択していますね。
やってみて良かったのが、チームでお互いの書き方でコードを書くという取り組みです。これをやると仲良くなりますよ。「なんでそういう書き方をしていたんだろう」といったことをお互いが理解することにより、チームがまとまりやすくなりました。
横溝：社内でよく使う技術が属人化してしまう課題はどう工夫されてますか？
甲斐：最近その問題に直面しています。コードは1人で集中して書くことが多いので、さっき言った、お互いのスタイルでコードを書いてみる取り組みだけでかなり変わりましたね。
加藤：うちは、あまりそこでもめることはないですね。
