開発チーム、一言でいうとどんなチームですか？
石黒卓弥氏（以下、石黒）：「開発チーム、一言で言うとどんなチームですか？」という質問なんですが、では順番で10X石川さんからお願いしてよろしいですか？
石川洋資氏（以下、石川）：うちのチームは一言で言うと、仕事がめちゃくちゃ進むチームです（笑）。どういうことかと言うと、メンバーにはけっこう自立してどんどん仕事を前に進めてほしいというのは徹底して伝えていて。その状況の中で、問題ってすごくたくさん出てくると思うのですが、問題をある程度言語化しておくと勝手にみんな仕事を進めてくれるなっていう感じで、仕事がたくさん進むチームです。
石黒：いいですね。仕事がたくさん進むチーム（笑）。じゃあLayerX榎本さん、お願いします。
榎本悠介氏（以下、榎本）：ごはんがススムくんみたいな感じですね（笑）。一言で言うとアニマルです。みんなすごく好奇心が旺盛というか。
かなりドメイン知識が求められるんですよね。証券の例をひとつとっても、僕はなにひとつ証券のこととかわからなかったんですけど、とりあえずゼロから勉強するしかないっていう感じで。言われずともどんどん本を買って勉強して、なんならヒアリングを勝手に設定して、どんどん学ぶし教え合うし、突破していくみたいな。
そういうかなり突破力のあるチームだなと思います。なので、すごく技術的にこうっていうよりか、事業を作っていくのを楽しみながらどんどん進められるチームだと思います。
開発環境について
石黒：仕事が進むチームとアニマルなチームということですね。では2つ目いきましょう。ポンポンいきますね。今日はもちろん、BizDevの方もいらっしゃいますが、ディベロッパーのみなさんがほとんどで、やっぱり開発系の質問が多かったんですが。
会社紹介の中でも石川さんから回答がありましたけれども、「開発環境や言語選定の特徴があれば、考え方を含めお聞きしたいです」という質問です。Dartを使用することについてのコメントが3名くらいからあって、こちらもピックアップしていますので、これも10X石川さんから回答をお願いします。
石川：まず技術の選び方ですが、基本的には開発が生産的に進められるとか、システムが安定するとか自分たちが得たいメリットを得られるかどうかを中心に考えています。
10Xが現在開発しているStailer（ステイラー）の場合はクライアントもサーバーもDartなんですけど、これにはそこそこ事情がありまして。まずもともと前プロダクトのタベリーは、モバイルのほうはNativeで、iOSはSwiftで、AndroidはKotlinで書いていたんですね。サーバーサイドはGoを使っていました。そこからStailerにいくときに、両方Dartになったんですけど。
それにはそれなりに意図があります。まず背景をちょっと共有しますと、うちのチームの場合、僕もソフトウェアエンジニアに入れるとすると7人のチームで今開発を回しています。もう少し前は6人だったんですが……。そういう少ない人数で開発していく中で、役割を分けないのは、僕らが取っている戦略のひとつです。
前のタベリーの状態だと、僕もiOSを書くしAndroidも書くしサーバーも書くという状態でした。そういうスキルセットのメンバーが全員だったんですね。全員、iOSも書けるしAndroidも書けるしサーバーも書けるっていう状態になっていて。
そういう状況においてどういうタスクの割り方をするかと言うと、ある1人がiOSをやって、もう1人がAndroidやって、もう1人がサーバーをやるというのは、まったく非効率なので、基本的に1つの機能に関わるものは全部1人でやるっていうスタンスを取っていました。
そういう状況においては、iOSとAndroidが分かれているのは普通に不便なことなんです。もしそれぞれのプラットフォームに1人ずつアサインできるのであれば、それはそれで別々の言語で書かれていてもぜんぜんいいと思うのですが。
うちの場合は少人数でなおかつ複数の役割を1人でやるというスタンスを取っていたので、これはクロスプラットフォームにいったほうがいいだろうということで、まずFlutterを採用しています。FlutterなのかReact Nativeなのかは、また議論があるポイントだと思うんですけれども、我々の場合はFlutterを選びました。
Go言語をやめてDartを採用した理由
もう1つ、サーバーですね。サーバーでDartを使っている会社を僕はまだ見たことないんですが（笑）、我々は採用しました。どういう理由で採用したかと言うと、サーバーはGoでいいじゃんって思うかもしれないですけど、我々はまずサーバーの言語をGo以外にするというところからスタートしています。
Goはいろいろな場所で活躍していますし、なんでもGoでいいじゃんって思うかもしれないですが、アプリケーションのビジネスロジックを表現するにあたっては、言語仕様が足りないという判断を我々はしました。
それはいろいろなところにあるんですけど、代表的なところだとnullabilityとか、mutabilityとか、そういうところが表現できないのは、ビジネスロジックを表現する言語としては少し不足があると思いました。
それがビジネスロジックではなくて、もっと別のところとか、もっと低いレイヤーのところとかだったら十分というか。実際にすごい実績もありますし、フィットしていると思うんですけど、アプリケーションを記述する言語としては、必ずしもそれがベストではないなという判断で、Goをやめるというところからスタートしました。
じゃあGoをやめて何やるの？ というのはいろいろ選択肢があって。SwiftとかKotlinとか。僕はSwiftの本とか出しているんですけど（笑）、Swiftは言語としてはすごくいいですし、Kotlinも同じくらいよい言語だと思っています。
でもそういう中で、Goのことを振り返ってみると、Goってすごく開発環境が自由で、安定していて、スケールしてもデメリットを受けにくい言語なんですね。なんでかと言うと、ツールチェーンがすごくしっかりしているからです。
サーバーサイドの言語を選ぶうえで、IntelliJを選ばなきゃいけないとか、Xcodeを選ばなきゃいけないというのは、僕は受け入れるべきではないなと判断して、SwiftとかKotlinは外しました。同じ理由でScalaとかも外しましたね。大きい規模になったときに、コンパイルの速度で活動ができなくなるのは、我々としてはちょっと受け入れたくないな、という判断をした感じですね。
そうなってくると、残るのはだいたいTypeScriptとかだと思うんですけど、この言語を選ぶころには、すでにFlutterの採用は決めていました。Flutterのツールチェーンがどういう動きをしているのかはよくわかっていて、Dartも実はいけるなということに、途中で気づいたんです。
Dartを選んだというのは、ある意味Flutterに引きずられてDartを選んだところもあると思います。TypeScriptでやっていても、たぶんデメリットはなかったんじゃないかなとは思うんですが、今となっては、クライアントとサーバーで同じ言語の資産を使えるのは実際メリットがあるなと思っています。
もちろん同じ感覚で書けるようなものではないのですが、例えばリンターが同じとか、そういう言語のプラクティスを引き継げるっていうのは明確なメリットとしてあると思います。まあそんなわけで、ちょっと言語の話になると長くなっちゃう（笑）。
石黒：そうですね。話が急に（笑）。ゾーンに入った感じですかね。
石川：ははは（笑）。
ブロックチェーンを使いやすいTypeScriptという世界観になる
石黒：ありがとうございます。さらにディープな話を聞きましょう。LayerXの榎本さんもお願いします。
榎本：同じ量をしゃべると時間がなくなっちゃうので、さらっと（笑）。この言語じゃないとダメだとか、この言語大好きだっていうよりは、普通に要件を達成できること、採用戦略上とかで弱みにならないような言語というのが基本方針であります。
ただちょっとおもしろいところを言うと、ブロックチェーンを扱っている会社なので、ブロックチェーン側のクライアント・ライブラリの事情とかに引きずられてきたんですよね。Ethereumっていうチェーンを、エンタープライズ側でもQuorumという、それをベースにしたチェーンをけっこう使うことが多いんですけれども、それをまとめるクライアントライブラリがJavaScriptベースのしかなかったりして。
なので、僕は別にTypeScriptがすごく好きとかではないんですけれども、その時点でサーバーサイドはTypeScriptにしておくのが、まあ普通に考えて自然だよねみたいになって。その延長で、けっこうTypeScriptの世界観になっていくみたいなのがわりと今までですね。
ただEthereumベースではないものについては、普通にGolangを使ったりしています。最近R＆DチームでAnonifyというオリジナルのプロダクトをリリースしました。ブロックチェーンでけっこう問題であるプライバシーを解決したモジュールなんですが。
それについてはフルスクラッチで、Rustで書いていますね。メモリ管理がしやすいみたいなところで、ブロックチェーン自体をRustで作るムーブメントがあって、R&DチームはRustで作っていることが多いです。
なので事業チームはTypeScript、少しGo。R&DチームはRustみたいな使い分けが主になっています。
