最近流行り始めているGoogleのモバイルアプリ用フレームワーク『Flutter』。iOSでもAndroidでも同じアプリがリリースされることが当たり前となる中、一度に両方のコードを開発できる便利さが注目される理由だ。

「一度触ってみたい」とトップエンジニアの間でも話題になっているが、開発言語はDartと呼ばれる、まだそれほど一般的ではない言語。これまでDartを経験したことがない人にとっては、手を出しづらい側面もあるかもしれない。

そんな中、開発言語を「フルDart」に振り切ってしまった会社がある。開発不要でネットスーパーを垂直立ち上げできるサービス『Stailer（ステイラー）』を提供する10Xだ。

自社に開発リソースがなくてもネットスーパーを立ち上げられるプロダクトとしてコロナ禍で注目を集め、イトーヨーカドーをはじめとする大手スーパーにも導入されている。

もともと献立アプリ『タベリー』を提供していた同社だが、新たに『Stailer』をリリースするタイミングでFlutterを採用し、全社的にDartでの開発に舵を切った。これにより、それまでSwiftやKotlinで開発していたエンジニアも、全員Dartで開発することになったという。

10Xでは、なぜ「フルDart体制」を選択するに至ったのか。使い慣れた言語からDartへどのように切り替えたのか。CTOの石川洋資さんを訪ねた。

株式会社10X　Co-Founder, 取締役CTO
石川 洋資さん

大学にて経営工学を専攻。在学中にスタートアップの創業メンバーとなり、iOSアプリの開発に取り組む。大学卒業後は面白法人カヤック、LINE株式会社、株式会社メルカリで新規アプリの開発に携わる。その後、メルカリで同僚だった矢本と株式会社10Xを創業し、CTOとしてプロダクト開発全般を担当する

iOSもAndroidもサーバーも１人で書けるマルチスキル集団

もともと当社はマルチスキル体制で開発してきました。『タベリー』を作っていた頃から、エンジニア全員がiOS、Android、サーバーと１人で三つの言語を書いていたんです。

当時は、iOSがSwift、AndroidはKotlin、サーバーはGoで書いていて、創業時に僕１人で開発していた『タベリー』も、最後の方は５人で開発するようになっていました。その全員が、マルチスキルという状態だったんです。

これにはメリットも大きかったのですが、それぞれの言語で開発環境が異なっていたので、iOSを書くときはXcodeで書いて、バックエンドを書くときにVS Codeに切り替える……という感じで、開発箇所ごとにエディターを切り替える負担がどうしても大きくて。

『Stailer』を作る時にクロスプラットフォーム、ワンソースにしたかったので、フロントエンドはFlutterを採用することに決めていたのですが、サーバー側をどうしよう……といろいろ悩んだ結果、Dartにしたんです。

10Xでは創業当初からエンジニアの役割を「サーバー」「モバイルアプリ」などに分けることなく、「全員ソフトウエアエンジニアとしてなんでもやる」体制にしたいと考えていました。これは、マルチスキルを持つ１人のエンジニアが一つの機能を作り切ることで、生産性が上がっていたからです。これからプロダクトや組織をスケールさせていくことを考えた時、今までのようにSwiftとKotlinとGoの三つを同時に書けるエンジニアはそんなに多くないと思います。

だけど、クセの少ない言語であるDartなら、SwiftやKotlinなどのメジャーな言語を書いた経験があればオンボーディングしやすい。全社的に言語を一つに絞ることができれば、全てのエンジニアがiOSもAndroidも、バックエンドも開発できるマルチスキル体制を維持できるはずだと思いました。

言語シフトの「三つの壁」を乗り越えた方法

エンジニアにとって開発言語をシフトする上で三つの不安があると思っていたので、その不安を一つ一つ解消していきました。

一つ目は開発環境のサポート状況です。Dartの場合、VS CodeでもIntelliJでも書けるので、エディターをいちいち切り替える必要がないですし、それぞれのエンジニアが自分の使いやすいエディターを選べます。

二つ目に、言語のクセ。Dartは良い意味でエッジが立ち過ぎていなかったので、先ほどもお伝えしたようにSwift、Kotlin、TypeScriptなどのメジャーな言語のいずれかを書いたことのある人なら大きな問題なく書けると考えました。

それから三つ目が、SDKやライブラリの充実具合です。例えばGoならGoogle Cloud PlatformのSDKをはじめとしたライブラリが充実していますが、Dartにはまだ揃っていません。

必要なものが揃っていないとき、エンジニアはいつでも「自分で作る」という選択肢を持っています。実装コストはかかりますが、Google Cloud PlatformのSDKを自分たちで作ることも可能なわけです。われわれの場合、サーバーの言語もDartに統一して自分達らしい開発カルチャーを強化することの方が、SDKの実装コストよりも大事だと考えました。

全くありませんでした。長いことiOSエンジニアをやっている人はみんなそうだと思いますが、僕も以前Objective-Cでコードを書いていた時期がありまして。それがSwiftに切り替わったとき、それまで知らなかった新しい概念に触れることができました。

それに、キャッチアップしていく中でエンジニアとしてのレベルが上った実感があったんです。新しい言語が出てくる時って、そのとき重要とされている新しい問題を解決できるから盛り上がるわけですよね。

新しい言語を次々と学ばなきゃいけないのは、たまに面倒だと思うこともありますが、その後に役立つ考え方が身に付くなら問題ない。エンジニアとしては、技術の移り変わりをポジティブに捉えたいと思っています。

特別に勉強時間を取るというよりは、仕事の中でさまざまな開発を経験しながら身に付けている人が多い印象です。

当社の場合は全員が同じ言語で開発しているので、プルリクエストのタイミングや、他のエンジニアが開発した機能を「担当替え」でメンテナンスすることになった時などに、他のエンジニアのコードを読んだり、触ったりする機会が多いんですよ。

すると、「こういう時はこんなふうに書けばいいんだ」という知見が自然と蓄積されるので、スキルアップも早くなる。全員同じ言語を扱えることのもう一つのメリットだと感じています。

さらに言えば、これはあくまでも僕自身の考えですが、「もくもく会」とか「勉強会」も大事だけれど、実際の業務でリアルな問題にぶつかったときの方が感性が磨かれるし、どうすればこの難題を解決できるかを見極める勘が働くような気がするんですよね。

だからプライベートで勉強時間が確保できなくても大きな問題ではないかなと。

まさに僕が、長い目で見てコツコツ勉強するのが苦手なタイプで（笑）。エンジニアの中には数年先を見据えて勉強できるタイプと、仕事で必要にならないと学べないタイプがいると思うんです。僕は後者なんですよね。

仕事でぶつかった課題を、「この技術を使ってどう乗り越えるか」と考えながら試行錯誤することで、結果的に早く、そして深く身に付けることができる。子育てや介護などで勉強時間が限られるエンジニアにとって、「仕事の中で身に付ける」という振り切った考え方も、一つの方法だと思います。

ええ。実際に、当社ではDartを触ったことがない人も採用しています。ただ、そうした場合はキャッチアップできる人かどうかを、トライアル期間で見極めるようにしています。

10Xの採用では必ず１日以上一緒に働く「トライアル」を設けており、期間中は「自ら課題を設定し、プロダクトに実装してリリースする」というプロセスに取り組んでもらいます。

その中で、もし分からないことがあれば自から周りに聞いて解決するとか、ただやるだけじゃなくて目的を理解しているかとか、10Xのバリューに合うかどうかをお互いに見極めます。トライアル期間中に「この人なら背中を預けることができる」と感じた人は、実際に入社後も問題なく活躍してくれていると思っています。

「一つのチームが同じレベルで言語を理解していること」の重要性

開発する上で起こるいろいろな問題を細やかにケアできるようになりました。

今ではフロントエンドに強かったメンバーがサーバーを書き始めているし、サーバーに強かったメンバーがアプリの方を開発してみよう、といったことが起きているんです。

すると、フロントエンドをメインで書いている人が「こういうリクエストの出し方をすると、サーバー側の人は困るかもしれない」といったことが考えられるようになってきて。各領域において何をケアすべきか、エンジニアみんなが分かるようになりました。

むしろ逆で、言語を統一したことでメンバーの強みが自然と現れてきている気がしています。

言語に強い人は言語の良いプラクティスをチームに広めてくれますし、インフラに強い人はみんなに良い仕組みを提供してくれますし、データベースに強い人はデータ設計のポイントを教えてくれたりします。言語の垣根がないので、各メンバーの強みが広い範囲に行き渡ってくれています。一つの言語にみんなで向き合うことで、強みを生かして補い合えることが分かりました。

各メンバーがそれぞれの強みを発揮しているおかげで、自分では想像もしていなかったくらいにシステムが良くなっていることもあります。エンジニアが自走してプロダクトを良い方向に進められるって、すごく理想としていた状態なんですよね。

今後は組織がスケールしても、この状態が続くことを目指したいと思っています。プロダクトがいろんな人の手を介することで、より良いプロダクトになるし、知見も広がっていくといいですよね。

大切なのはその言語を使う目的と「どんな問題を解決したいのか」を考えることだと思います。10言語を扱っている組織にしても、きっと事業フェーズやプロダクトの状態など、その時抱える課題や目的に応じて最適な方法を選んでそうなっていると思うんですよね。

うちの会社もプロダクトが増えたりして、Dartだけでは困るような状況になれば、また言語を増やすことだってあるかもしれません。流行っているからといって組織やプロダクトが抱えている問題を解決できないなら、その言語を採用すべきではないですし、新しい言語で自分たちが解決したい問題を解決できるなら、そのためのハードルはフットワーク軽く乗り換えるべき。

組織のフェーズや目的によって正解が違うので、ただ「新しいから」「人気だから」ではなく、その時に抱えている課題を解決するために、言語を選び取っていくスタンスが大切なのだと思います。

取材・文／石川香苗子　編集／河西ことみ（編集部）