00:05
こんにちは、10X CTOの石川です。
10X.fmは、10Xで働くメンバーがゆるく話すポッドキャストです。
今回は、ソフトウェアエンジニアの久市に来てもらいました。
久市、自己紹介をお願いします。
10Xのエンジニアの久市です。よろしくお願いします。
久市と僕は、会社のメンバーでもあるんですけど、
新卒の同期なんで、今日はカジュアルな距離感。
緊張感のない感じで進めていきたいですね。
言うて緊張してるけど。
今日は、Flutter for Webについて話そうと思っています。
今、10XでFlutter for Webを検証しているんですけど、
その担当が久市ということで、今回来てもらっています。
Flutter for Webを使うプロダクトは、10Xのメインのプロダクトであるステーラーで、
ステーラーは小売のチェーンの意思を垂直立ち上げするサービスになっています。
今のところ提供しているのはモバイルアプリだけなんですけども、
今後もモバイルアプリにフォーカスしていくということは変わらないんだけど、
Webもチャンネルの一つとしてカバーしていくことになったので、
その流れでFlutter for Webを活用していこうということになっています。
被災地にあるFlutter for Webの活用戦略について、ざっくりと話してもらおうと思います。
活用戦略?
どういうシーンでどういうふうに使おうとしているかとか、
どういう背景でこのFlutter for Webを使うのかというのを、
簡単に説明してもらえればと思います。
モバイルアプリにフォーカスするというので、
モバイルアプリの開発とWebの開発という2つを分けて開発を進めると大変だねというところで、
モバイルアプリのコードをベースに開発できるのがいいよねという話で、
まずFlutter for Webという話があったんですね。
それでFlutter for Webを検証してみましょうという気になったという感じですかね。
今モバイルアプリをフォーカスしていて、そのコードベースの資産を最大限に活用していくというような戦略で、
Flutter for Webが上がってきたというような感じになっているというような、
現状とりあえずこのモバイルアプリで作ったものをWebで動かそうとかしたりしているじゃない。
そこって今どんな感じで動いているかという説明をしてもらっていいですか。
案外普通に動いていて、これ動くの?みたいな感じで、意外と動いているなという印象ですね。
03:03
確かに。
普通にスマホアプリの開発とかしていると、シミュレーターとかエミュレーターとかあって、
それがパソコンの上で動いているというのはあるじゃない。
普段はスマホ上で動いているものが、シミュレーターだとパソコン上で動いているみたいな。
それと同じノリで、あれ、モバイルアプリにブラウザで動いているみたいな。
今までエミュレーターで動いていたものがブラウザで動いて、
しかもブラウザって大きくなったら小さくなったりするから、
それもギュンギュン動いて、「えっ、動いてる?」って。
いいんですか?って。
動いてるじゃんって。
びっくりしましたね、最初は。
そのフラッターがウェブで動くこと自体はみんな知っていると思うんだけど、
どれくらい動くのかとか、どれくらい調整をすれば、
既存のコードベースがウェブ上で動くようになるのかって、
みんな具体的には知らないと思うんだけど、
やっていてもやってきたことを簡単に紹介してもらえる?
そうですね、途中ではあるんだけど、
最近やっていたのは、
モバイルアプリに対応しているけど、
iOSとかAndroidに対応しているけど、ウェブには対応していない、
みたいなライブラリが結構あって、
それを僕たちのほうでラップして、
ウェブでもそれっぽく動くようにするか、
何も動かないようなフェイクのクラフトにするみたいなのをやってました。
例えばどういうものがある?
例えば、
フラッターセキュアストレージっていうストレージのライブラリがあるんだけど、
それはiOSとAndroidでしか対応していなくて、
キーチェーンがないので、
ウェブではそれを使わないようにするとか。
やることとしては、
アプリケーションのコードというか、
ウィジェットのレイヤーから直接使うという形ではなくて、
一枚レイヤーみたいなやつをかませてあげて、
モバイルだったらキーチェーンの実態を参照して、
ウェブだったらそもそも存在しないよ、みたいな感じにするような感じだったかな?
セキュアストレージ以外でも、
例えばウェブビューとかも最近対応してたと思うんだけど、
ウェブビュー?フラッター4ウェブからウェブビュー、
どう扱っていくの?
フラッター4ウェブは、
HTMLをそのままバコって埋め込むってことは、
基本的にはできなくて、
HTMLエレメントビューっていうのがあって、
それを使って表示したりするんだけど、
それを簡単にするためのライブラリみたいなのを、
06:02
僕が対応して作ったって感じ。
なるほど。それはもう、
わりと一通り対応できてるというか。
そうですね。
ネイティブウェブビューっていうのを僕、もともと作っていて、
それはどういうのかっていうと、
iOSとAndroidでウェブビューを扱うようにするっていうライブラリで、
それはウェブには対応してないんですよ、今も。
それを書き換えて、
対応してないプラットフォーム、例えばウェブ以外にも、
macOSとかWindowsとかっていうのも対応してないんですけど、
それも対応してないけど、
ユーザーがある程度ちゃんとしたコードを書いたら、
動きますみたいな実装にした感じで、
それをウェブでもこっち側で対応した。
なるほど。
そんなこんなで、
モバイルアプリで実装していたプラットアプリが、
なぜかというか、不思議とウェブで動くというような状態になったと思うんだけど、
今次のステップとしては、
実際その移植したアプリケーションが、
ウェブアプリケーションとして普通に使えるものになっているかどうかっていうのは、
多分また別かなとは思っていて、
それに対しては次はどういうステップを踏んでいく予定かっていうのを、
簡単に説明してもらえると。
次のステップ。
まずは動かしたじゃん。
でも実際に、
ウェブサービスとしてお客さんに提供するという段階までは、
ジャンプがあると思っていて、
そこのステップというか。
ウェブに特化するレベル。
見た目とか。
見た目とかは、
モバイルアプリそのまま出すと多分使いにくいから、
例えばステーラーだと、
売り場のところとか、
今はモバイルアプリだと、
1列に3個しか出してないけど、
もうちょっと出すようにするとか、
いくつかあると思うんですね。
ナビゲーションとか。
トップのナビゲーションをちゃんとウェブサイトとして。
ステーラーのアプリは、
ボトムナビゲーションを使っているけど、
ウェブでは使うのをやめてとか。
そういう土台の構造を変えていって、
その土台の上に乗っかっているコンテンツは、
基本的には同じものをなるべく使おうとしているというのが、
今僕らがやろうとしていることだよね。
細かいコンポーネントみたいなのは、
基本的にモバイルアプリとウェブで同じものを使って、
大きな枠では別のものになるんじゃないかなと。
09:00
その戦略はすごくうまくいくといいんだけど。
今日デザイナーの住みさんとも話していたんだけど、
完全にゼロからウェブ向けのものを作ると、
全体に乖離が生じるし、
その分二重のメンテナンスコストが生じるなという話はしていて、
ただ、モバイルアプリの画面のレイアウトに対して、
こういう法則で変換するとか、
例えばパッキングがモバイルアプリだったら8のところを、
ウェブだったら12にするとか、
フォントサイズを1点何倍とかにするとか、
そういうシンプルな法則で変換できるのであれば、
それはメンテナンスコストがそこまで生じるわけではないので、
なるべくそういううまい法則を見つけて、
コードベースの断片化をしないまま、
サービスを運用できるといいなと思っていて、
そういうのって成功事例とかはまだこの世の中に存在しないと思うので、
初めての事例になれるといいですね。
挑戦しがいのあるというか。
この状況って、
STELLARというプロダクト自体がモバイルアプリにフォーカスするという戦略で、
とはいえ、チャンネルとしてウェブをカバーするという立ち位置だからこそ、
ウェブに対する固有のリソースはなるべく割かないみたいな戦略を取っていると思うんだけど、
今後もそういう戦略を取りたいアプリケーションって他にもあると思うから、
いい事例になれるといいなと個人的には思っているかな。
ちなみにFlutter4Webって2つのレンダラーがあって、
HTMLとCanvasKitがあると思うんだけど、
これはSTELLARでは今HTMLを選んでいると思うんだけど、
それってどういう意思決定があったのか僕は知らないので、
単純に知りたいなと思っているんだけど。
HTMLとCanvasKitのそもそもの違いを話してみると、
HTMLはモバイル向けで、公式の便で確か書かれていたのはモバイル向けで、
軽いですよ、HTMLの容量が。
ただし動作はちょっと遅いかもみたいな感じで、
CanvasKitは容量がちょっと大きくなっちゃうんだけど、
高速に動作しますよみたいな、アプリケーションらしく動作しますよみたいな感じでしたと。
HTMLを僕たちは選んでいるんですけど、それは何でかというと、
容量の問題とか動作の問題というよりかは、
文字列がちゃんと表示されなかったりとかCanvasKitは、
12:04
日本語が豊富文字みたいになって、一瞬四角の文字になって、
その後日本語に表示されたりとかがあるから、
CanvasKitじゃなくてHTMLでやるかという感じで、
そっちを選んでいるという感じ。
ウォッターフォーウェブも先月ステーブルチャンネルに入って、
ステーブルと言われてはいるんだけど、なかなか状態としては迫力のある感じというか。
そうですね、ガグが全くないなというわけではないので、
これガグだなというのは割りかし見つけるのがあるので、
だから2週経ったり、コメントして直してくれ、
そういうのはあるかなという感じです。
だから全く苦がないわけではない。
その辺は先駆者の宿命という感じかね。
もしCanvasKitの不具合とかが一通り解消されていたら、
そっちを取っていたという可能性はまだ全然ある?
全然あると思う。
ちなみにレンダラーを切り替えるのって大変なの?
ビルドするときにWebレンダラーというオプションを付けていて、
そこにHTMLを付けるかCanvasKitを付けるか、
もしくはオートというのもあって、
そのオートはモバイルはHTMLでみたいな感じだった。
今後も時々CanvasKitのほうでビルドしてみて、
たまにCanvasKitが来てるなというタイミングが来たら乗り換えるみたいなこともできるわけ。
じゃあフラットワークのアプリケーションとしては全く同じコードベースになるって感じだね。
そうですね。
今開発チームがソフトウェアエンジニア11名、
UQ入って3人入ってるから8人っていう状況だけど、
今フラットワーク4ウェブを触ってるのは被災地と北系だけじゃない?
その他のメンバーは、
フラットワークはモバイルアプリのほうでやったことあるけど、
ウェブのほうはまだ全然知らない状態だと思うんだけど、
そういうメンバーも普通にやっていける感じになるのかな?
全然やっていけると思う。
それはめっちゃ楽しみというか。
モバイルアプリを書いてるコードとほぼ全く変わらないくらいじゃないかな?
それはすごいな。
もちろんウェブだけの処理とかがあるから、
考えることは絶対増えると思うんだけど、
分岐とかも絶対増えると思うんだけど、
被災する各コードはほぼフラットワークのコードだから、
15:07
全然同じノリで開発できる気がする。
それはいいよね。
今いるメンバーがいつウェブのことが必要になって開発しようとなってもできるわけだし、
何ならウェブのことを意識してなくても、
ウェブの機能ができてしまう状況になるってことだよね。
そうですね。
基本的には意識しなくて言って、
確認とかリリースする前に意識するくらい。
フラッターもIOSとAndroidの両方を意識して書くことってあんまりなくて、
確かめながら作るときはIOSでビルドしながら作って、
リリースするときにAndroidを見て確認するって感じだと思うけど、
そこの中にウェブが入るみたいな感じになると思っている。
確かにな。
最近フラッターのインテグレーションテストとかもいるので、
そこの実行環境、IOSとAndroid、それプラスウェブでメインのプログラムをカバーできる。
今TENXのチームとしては割と少ない人数で大きいものを作るみたいな感じになっているので、
ウェブをやるってなったときにチームを分割したくなかったっていうのは結構大きくて、
それは普通に満たせてそうだなっていうのは今のところ感じているところで、
最終的にこのままゴールに行けると、
ゴールというかリリースにたどり着いて、
しかるべきお客さんにきちんとプロダクトを提供できるっていうところまでいけるといいかな。
そうですね。できるような気はしている。
今日はそんなところかな。
というわけで、今日はフラッター4ウェブを検証中という話で、
いい感じにやっていけそうという結論でした。
