iOS／Androidで、一度に両方のコードを開発できる便利さが注目されるGoogleのモバイルアプリ用フレームワーク『Flutter』。新たに導入を検討する開発チームも多いのではないだろうか。

そこで今回は、４月13日（火）～17日（土）にオンライン開催したエンジニアtype主催の『ENGINEER キャリアデザインウィーク』（ECDW）内のセッション「言語・体制の選択基準は？～注目スタートアップ10X×SYN CTO対談～」の一部を紹介。

Flutterを採用して開発に取り組む10X CTOの石川洋資さん、SYN CTOの八木達也さんに、Flutter開発のメリットや、開発言語・体制の選択基準、意思決定の方法についても語ってもらった。

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

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

株式会社シン　CTO　八木 達也さん

東京大学工学部を卒業後、2010年にDeNA新卒入社。入社後6年程度国内のソーシャルゲーム事業に従事し、サーバーサイド/クライアント開発、ゲーム企画、経営企画などを経験。16年４月にメルカリに転職し、子会社のソウゾウにて新規事業の開発やPOを経験。その後、2019年8月にSYN, Inc.にジョイン

２社がFlutterを採用した理由

石川：技術選定は、チームや事業が置かれてる状況と技術的な性質の組み合わせによって行われるべきだと思っていて。当社の場合は、Flutterが一番良い手段でした。

選んだ背景としては、僕らは前のプロダクトで『タベリー』という献立アプリを作っていたのですが、その時は５、６人のメンバーで全員がiOSもAndroidもサーバーも全部書く、といった体制だったんです。

そういった体制で開発してると、例えば一人が「ここの機能を開発する」となった時に、まずサーバーでAPIを書いて、その後iOSかAndroidで好きな方を書いて、似たようなコードをもう一つのプラットフォームに書く……といった進め方になります。

この進め方だと単純に「同じコードを２回書く」のもダルいし、何かが起きたときに少しずつプラットフォームごとにコードの断片化が起きてしまうんです。iOSとAndroidでは別のライブラリを使う、とか。

すると、ベースとして提供したい体験は同じなのに、手段が異なってくる、ということが生まれます。一人の人が二つの方法で一つのことを実装する……といった、良くない状況です。

そこで、それぞれにとってベストな方法は何かを考えた結果、今手掛けている『Stailer（開発不要でネットスーパーを垂直立ち上げできるサービス）』を作るときにフレームワークをFlutterに、言語をDartに切り替えました。

もちろん「うちはちゃんとiOS専門部隊がつくれる」というチームであればそのままでもよかったかもしれないんですけれど、われわれの当時の状況で、少ない人数でレバレッジをかけるならFlutterだなと考えたんです。

八木：うちも同じで、もう石川さんが言ったことがすべてですね（笑）

当社はフードデリバリーアプリ『Chompy』を手掛けているのですが、このサービスではユーザー、配達員さん、店舗さん用と、最低でも三つのアプリケーションが必要です。

でも社内には創業当時エンジニアが６、７人くらいしかいなかったので、１、２人で一つのアプリを開発しなければなりません。AndroidとiOSのどちらも提供したいとなった際に、この人数でどちらも書くのはしんどいなと。

そこで、マルチプラットフォームを検討したという経緯です。僕は個人開発でReact Nativeを使ってハマった（※うまくいかなかった）経験があったので、Flutterを採用しました。

石川：Flutterは「ハマる」ことを徹底的に排除しようとしてますもんね。セットアップのところから懇切丁寧にガイドしてくれるし、ドキュメントも充実している。

八木：はい。Flutterも以前から触ってはいたのですが、改めて使ってみると、フレームワーク自体の思想や視点が結構違うことに気付きましたね。

開発体制の変更には「クリアな伝達」がマスト

石川：はい。フルDart・Flutterにすることで一つの機能を開発する時でも一人で完結できるので、コミュニケーションコストが節約できるし、特定のプラットフォームや特定の場所を属人化しない点でメリットがありましたね。

つまり「みんながみんなの仕事をきちんと理解できる状態」ができたんです。実務レベルで何をケアして、どういう意図でこういう設定してるのか、全員が理解できる状態になりました。

石川：大きなトラブルはありませんでした。というのも、意思決定をする際は、どうしてこの選択をしたいのかということを、なるべくクリアにして伝えることを意識しているんです。いかにその選択が合理的であるか、筋が通っているかを伝えて納得してもらっています。

八木：石川さんの意見にはとても同感します。スタートアップは意思決定のスピードがとにかく早い。だから開発チームに対して「これをやってきましょう」と常に伝え続けることが大事だと思います。

プロダクト開発は「本質理解」が最重要

石川：常に忘れないようにしているのは、「大きなこと、価値が出せることをやりたい」という意識です。そのプロダクトを通じて達成したいことに向かって、適切なアクションを取れているのか。なるべくそこから逆算して判断することが重要だと考えています。

八木：私の場合は、「これは本当にやる意味があるのか」というのは常に考えています。仕事って、ある意味自分の時間を捧げているわけじゃないですか。本当にそれに値するのか、きちんと向き合うこと。今やることよりも意味のあることがあるなら、そちらを先にやるべきだと考えて、常に行動していますね。

セッション後半には、Q&Aコーナーも

イベント後半では質疑応答タイムを設け、参加者から寄せられた多くの質問に回答した。いくつかピックアップして紹介しよう。

八木：都度向き合って話す。これに尽きるかと思います。直接その場で言えることはその場で話しますし、個人的なことだったら１on１で話します。彼らの意見に対して、僕らができることがあれば何でもやるし、難しいことであれば「ここまでだったらできるけど」と素直に伝える。

１on１では、まず相手の話を聞くことを大事にしています。やり方は人によって違いますが、私の場合はコーチングのようなイメージで進めていますね。そのメンバーの想いと向き合う瞬間って１on１くらいしかないので、メンバーが何をしたいのか、何を考えているのか、じっくり聞いてみるという感じです。

石川：僕も、その人が感じてることを聞くのが基本ですね。その上でもし認識の齟齬があったり、向いている方向が違ったりするのであれば、その都度原因を解き明かしていくイメージです。

ただ、10Xくらいの規模であれば、経営の方針も短期的に目指している方向も、繰り返し何度も説明をしていますし、今働いてるメンバーも自分たちが何を目指しているのかを自覚しているはずなので、そこまで意思決定にネガティブな声は挙がりません。

八木：課題があって、これをどうにかしたいとなって初めて、ツールの話が出てくると思います。だから「解きたい課題は何か」というのが一番の軸になりますね。

石川：僕も、自分たちの課題を解くためのツールなのかを重視してます。あとは、それを導入することによって他の何かに弊害が起きないのかは、とても気にしていますね。ツールが増えるということは、それだけチームに複雑さを導入するということ。その複雑さに見合っただけのメリットがないといけません。

八木：若手のうちは、目の前の仕事をちゃんとやるしかないと思います。そこで余裕が出てきたら、自分の仕事について考えてみる。すると「これってちょっと、違うんじゃない？」と思えることが出てきます。それをチーム内に提案したり、発信したりできるといいですよね。そういう目線で働く方が楽しいですし。

石川：僕は、自分が「面白い」と思えることを意識するのがいいと思います。仕事をする上で気にしないといけないことはたくさんあるとは思うのですが、結局は仕事自体が面白いと思えないと、頑張る気が起きないですから。

頑張る気が起きないと、最低限気にすべきことまで気が回らなくなります。それに、面白いと思える場所に身を置いていると、「自分が仕事の手綱を握れてるな」というタイミングが来ると思いますよ。

文／福井俊保　編集／大室倫子

動画アーカイブ

動画でアーカイブを見ることができます。参加者からのQ&Aなど、セッションの全貌はぜひ動画をご覧ください。