【社員インタビュー】既存スマホアプリをFlutterに切り替えた背景とそのメリットとは

− まずは簡単に自己紹介お願いします

宮木：宮木修平と申します。スマートドライブでモバイルアプリエンジニアをやっています。受託開発企業、モバイルアプリ開発パッケージの運営企業を経て、スマートドライブには2018年に入社しました。スマートドライブではAndroid、iOS、 Flutterアプリの開発保守業務と、モバイルアプリ関連施策について社内での各種調整業務を行っています。

− 今回のプロジェクトが始まったきっかけを教えてください

宮木：プロジェクトのモチベーションとしては大きく3点ほどありました。 1点目はコードの保守効率が低下してきたことです。従来から提供しているSmartDrive Fleetアプリは、2017年5月からサービスが始まり、サービスの発展とともに拡張されながら現在まで運用を続けてきました。その時点その時点での方針や人的リソースの状況、アプリ開発におけるトレンドなどの影響を受けつつ機能が増築されてきたことで、以前からの機能は古いつくり、新機能は新しいつくりになっていたり、iOS版とAndroid版でも微妙に仕様が異なっていたりして複雑さが増していました。 2点目として、モバイルアプリエンジニアのリソースの観点でも、開発効率を改善したい状況がありました。2021年ごろまではiOS版とAndroid版についてそれぞれエンジニア1人ずつで分担し、同様の機能、同様のUIをそれぞれ開発していました。これは個別に開発工数がかかるだけでなく、細かい仕様に関して相互にすり合わせが必要で、コミュニケーションコストもかかります。また、一方のエンジニアがボトムアップで細かい改善を発案しても、他方のエンジニアは別の部分を重視していたりするとチームとしては合意が得られず、改善の腰が重くなりがちです。1人で両OSの同じトピックを担当する形も試しましたが、いずれにしても2度手間ですし、コードベースの違いから同じようには改修できないこともありました。

3点目としては、UIや提供機能の面での状況です。SmartDrive FleetはいままでWeb UI先行で機能が拡充されることが多かったため、Web UIで提供している要素をネイティブアプリに反映しきれていない状況や、エンジニアのリソースの都合がつかずiOS版またはAndroid版の片方だけ先行して改善をせざるを得なかった状況などがありました。また、時を同じくしてSmartDrive Fleetのサービスにおけるネイティブアプリの位置付けの見直しが行われ、既存のUIでは今後の機能拡充への対応が難しく、UIのリニューアルを必要としている状況もありました。これらの状況から、アプリのリニューアルとともにアプリの開発を効率化する機運が高まりました。

− その対処法として、今回採用したFlutterを検討したということですか？

宮木：そうですね。コード面、コミュニケーション面、人的リソース面をシンプルにするための解決策としてFlutterを採用することにしました。Swift/Kotlinで最新の動向を踏まえて実装を一新させることも考えましたが、開発体制を根本的に改善し得るという点ではFlutterにより大きな魅力を感じました。FlutterはiOS版とAndroid版を共通のコードベースで実装できるので、基本的には双方同じ挙動になりますし、前述のような実装面での2度手間やiOS版とAndroid版の間での仕様調整が大きく削減できます。ネイティブアプリのエンジニアが2名いるならば、一方は機能開発、他方は保守や突発対応やメンテナンスといったように、それぞれ別の施策を並行して推進でき、効率化が期待できます。 Flutter以外にも、React NativeやXamarinなども選択肢にはあったのですが、メンバーの関心度としてはFlutterが高かったのと、FlutterはGoogleのサポートやドキュメントも充実しているので、良いのではないかと。

− それでFlutter を採用するに至ったと

宮木：はい。別の背景として、Flutterの状況と、スマートドライブの状況がマッチするようになってきたこともあります。Flutter自体は以前からありますが、社内でも何度か検討し見送ってきた経緯があります。 2018年に別の新規アプリの構築時に検討してみた時点では、当時まだどの程度普及するかが未知数で、ネイティブアプリエンジニア間でも意見の分かれる状況でした。また、当時のFlutterはGoogle Mapのサポートが未整備で、デバイスの位置情報を扱うSmartDriveのサービス上、構築できるUIに制約がある状況でした。 UIデザインの面では、FlutterはGoogleのマテリアルデザインに対するサポートが充実していることがメリットの1つとして挙げられますが、SmartDrive独自の事情として、弊社のチーフデザイナーが創業当初から独自のスタイリングを持ったUIポリシーを構築してきていたことから、この共存がうまく行えるかどうかについて当時は検証しきれない状況でした。

また別の新規アプリを開発する際にも改めて検討しましたが、スマートドライブの状況として、当時はスマートフォンと接続するBLEデバイスを提供していました。この接続の際に用いるSDKをSwiftとKotlinで個別に構築しており、このアプリでは要件上それらを組み込む必要があったため、Flutterと繋ぎこむと複雑さが増すことへの懸念と、ネイティブで書いた方が動作を安定させやすいだろうとの判断から再度見送っています。その後、Flutter上でGoolgle Mapがサポートされるようになり、Flutterでの独自のUI構築も問題なく行えることが確認できてきたこと、SmartDriveとしてもBLEデバイスの提供が終了し他のデバイスが主流となってきたこと、Flutterに対するネイティブアプリエンジニアの機運の高まりもあり、今回はFlutterが使える環境が整ったと判断し採用することになりました。

− チームでFlutterを採用するうえで、どのようにキャッチアップをされていったのでしょうか?

宮木：キャッチアップは基本的にはエンジニア各自に依存していますが、Flutterは各種ドキュメントや動画でのインストラクションが非常に充実しているので、開発に必要な情報はスムーズにキャッチアップすることができると思います。ネイティブアプリの開発経験がある方であれば、つまづくところはあまり多くないのではないでしょうか。実際、直近で1名、面接時点でネイティブアプリのiOSやAndroidの開発経験があり、Flutterの開発は未経験のエンジニアの方が入社されましたが、問題なくキャッチアップいただいて成果を出されています。

− Flutterを使用した開発はどのように始まり、進んでいったのでしょうか?

2020年の暮れごろにネイティブアプリチームでFlutterを触ってみる機会ができたので、一旦、原型になるようなアプリを組みました。そこから、少し間が空き、2021年3月ごろから再始動しています。当初は他のメンバーがそれぞれ別の案件を抱えており、まずは私一人で動き始めました。

少し話がそれますが、時を同じくしてドライバーの方々向けのUIとして、ドライバー各個人のスマートフォンではなく拠点に設置したタブレットから限定的な操作が行えるアプリも提供しようという話が挙がっていました。SmartDrive Fleetのお客様が抱えるドライバーの方々の中には社用のスマートフォンの貸与を受けていない方も多く、SmartDrive Fleetアプリを利用できないお客様もいらっしゃいます。他方、新アプリは今まで提供している要件+αをすべてFlutterで再度実現する必要があり、ある程度期間を要します。そこで、いきなり既存のSmartDrive Fleetアプリをまるごと置き換えるのではなく、次のように計画を立てました。

タブレット向けアプリをFlutterで新規構築しリリース
タブレット向けアプリのコードベースを新アプリと共通のものとしてみなし、タブレット向けアプリと新アプリの双方を作成できるように拡張
コードベースに共通で拡充したい機能と新アプリ特有の機能を順次拡張

まず、タブレット向けのアプリをFlutterで構築することにしました。このアプリは規模的にも小さかったのでスモールスタートとしてもちょうど良い題材ですし、後ほど説明しますがこのアプリを構築すること自体が新アプリを構築する上での実装の積み上げにも寄与するよう企図しました。タブレット向けアプリは早期にリリースができるため、お客様への価値提供を最大化することもできます。ここで完成したアプリはタブレット向けのSmartDrive Fleet Boardアプリとして現在提供中です。

− タブレットアプリは初めてでしたよね。何か障壁はありませんでしたか?

宮木：実際、アプリのUIとして組み立てる要素は、スマートフォン向けでもタブレット向けでも基本は変わりません。どちらの端末を主な利用端末として位置付けるかという違いはありますが、タブレット向けとして構築されたアプリがスマートフォンにインストールされることもありますし、その逆もできるので、いずれにせよ双方を考慮する必要があります。このタブレットアプリの特有の要件としては、各拠点に設置されることです。例えば寿司チェーン店やファミリーレストランなどで見かける注文用端末のような据え置きのタブレットで利用されるアプリは起動と終了を繰り返すのではなく、1度起動されるとそのまま使われ続ける場合がある点が挙げられます。アプリを起動したままでも表示情報が定期的に更新されるようにするなどの配慮を行なっています。

− Flutterで開発して Fleet Boardアプリはどれくらいの期間を要しましたか?

宮木：トータル3ヶ月程度で最初のリリースを行なっています。早期にリリースしたい状況であったため、紙ベースでのプロトタイピング後、Flutterの長所を生かして実装ベースのプロトタイピングに移行し、手応えを確認しながら実装していきました。初版の段階ではある程度Flutterでの構築しやすさを優先するため、UIデザインについてはデザイナーと連携しつつ、ブランディングが崩れない範囲で立ち上げやすい内容として一旦着地させています。その後のアップデートを経て、UIはより質の高いものに改善をしています。

− そのプロセスの中でのチャレンジは？

バックエンドのAPIはSmartDrive Fleet Boardアプリでも新アプリでも同じものを利用します。そのため、APIのクライアント側の実装や、ログイン/ログアウトに関する部分や、アップデート表示、メンテナンス表示など、どんなアプリでもベースとして必要となる要素はSmartDrive Fleet Boardアプリと新アプリで共通化ができ、これらはそのまま新アプリにも資産として活用できます。これによりSmartDrive Fleet Boardアプリの開発をそのまま新アプリのFlutter化の第1段階としての位置付けることができました。

− その後、SmartDrive Fleetアプリのリニューアルに進んでいくわけですね

はい。SmartDrive Fleet Boardアプリは2021年7月にリリースしましたが、新アプリは実際のところリリースまでにさらに１年ほどを要しました。まず、前述のように、SmartDrive Fleet Boardアプリのコードベースから、SmartDrive Fleet Boardアプリと新アプリの2つのアプリを構築できるような拡張を行いました。このあたりは単にFlutterに置き換えるという点以上に意欲的な部分になっていると思います。

FlutterでiOS版とAndroid版を共通化できたとしても、SmartDrive Fleet Boardアプリと新アプリの2つのFlutterアプリを保守する必要性が生じてしまっては結局似たような問題が起きてしまいます。そこで、単一のコードベースからSmartDrive Fleet BoardアプリのiOS版とAndroid版、新アプリのiOS版とAndroid版のトータル4つのアプリを構築できるようにしました。 UIに関しても、デザイナーと相談し、SmartDrive Fleet Boardアプリと新アプリはある程度共通で利用可能なように一体感を持たせたデザインとしています。その後、SmartDrive Fleet Boardアプリと新アプリに必要な機能を拡充していきました。元々のSmartDrive FleetアプリとしてSwiftとKotlinで作ってきた資産は、仕様上の参考にはできても活用はできないのでそれらをDartで書き直す作業が必要です。最初は私1人で着手しましたが、各メンバーそれぞれ抱えていた案件が落ち着き次第、開発に合流しています。途中、メンバーの入れ替わりもありましたが、最終的には5名ほどで仕上げています。最初の立ち上げなので、途中でUIデザインについての再検討があったり、若干ウォーターフォール的なプロセスになったところや、期間の関係上要件を先送りして削ぎ落とした部分もありましたが、エンジニアリングチームだけでなく、CSや営業チームにもなるべく早めに触ってもらえる環境を用意してフィードバックをもらいつつ、進めていきました。

− 開発期間中には、元のアプリの改修や機能追加もありましたか？

宮木：SmartDrive Fleetアプリの方は一旦開発の手を止めさせてもらいましたので、集中して新アプリの開発を進めることができました。元のアプリを並行して機能追加してしまうと、新アプリの仕様も追従する必要がでてしまうため、SmartDrive Fleetアプリの方は不具合対応、かつ顧客影響度の高いもののみに絞って対応しています。組織としてこの方針決定ができたことは、Flutter化を進める上ではとてもありがたかったです。SmartDrive Fleet Boardアプリについては新アプリのコードベースと共通ですので、途中、随時改善のアップデートリリースを挟むことができました。

− 9月についにリリースされましたね

宮木：はい。新アプリについては、別の新規アプリとしてSmartDrive Fleet Driverアプリという名称でリリースしています。当初元のアプリのアップデート版として新アプリをリリースする案もありましたが、機能やUIも大きく変わっており、変更点の規模が大きいためアプリの利用者が混乱するリスクをさけるため、元のアプリは提供し続けたままとし、お客様側で準備ができた段階で順次移行してもらうという形としています。従来のアプリの改善を一時的にストップしたことで、お客様からの改善要望についてしばらくお待たせしてしまう形にはなりましたが、今回新アプリにそれらのリクエストをある程度盛り込む形で提供することができました。リリース後、お客様からも使いやすくなったというご感想も早速いただいています。

− お客様目線での新アプリのメリットとは？

大きく分けると以下の3つになると思います。

アプリの位置付けの見直しに伴ってUIが整理された
要望の上がっていた改善やWeb UIのみで提供していた仕様が取り込まれた
ニーズの大きかった新機能が搭載された

− 具体的にどのような点ですか

宮木：まず、1点目の位置付けについて、SmartDrive Fleet Driverアプリはドライバーの業務上の手間を極力低減させるためのものである点が明確化されました。基本的に、ドライバーは積極的にアプリを使うわけではなく業務上の必要に迫られてアプリを利用します。具体的には各種の報告業務であったり状況の確認であったりするわけですが、これらをできるだけ省力化して行えるような方向性でUIが見直されています。次に要望の取り込みの一例ですが、元のアプリでは、車両予約機能に関してUI上やれることに制約があったのですが、今回、自由度が向上しました。また、車両のリアルタイム表示画面は、PC Web版のUIで提供している内容に追従し、SmartDrive Fleet Driverアプリでも概ね同様の情報を確認できるようになっています。他にもさまざまな細かい要望についても改善が行われました。新機能としては、アルコールチェックや車両の日常点検、各種作業の記録をアプリから行えるようになっています。SmartDrive Fleet Driverを使うドライバーにとってそれらの報告業務はなるべく手早く済ませたいものであると考えていますので、極力スムーズに記録が行えるようなUIを目指しています。

− Webだと管理者視点になるかと思いますが、スマホアプリの場合、ドライバー同士で位置情報が確認しあえるということですか？

宮木：はい。お客様の中にはドライバー同士で状況を把握しあって連携を取る必要がある方もいらっしゃいます。リアルタイム機能についてはWeb UIと共通性のある仕様に変わったことで、すごく使いやすくなったとのフィードバックをいただいております。新アプリから他の車両の現在地や、あらかじめ登録された地点をGoogleマップのナビに目的地設定して向かうこともできます。

− 例えば、弁当配達を提供している会社で、ドライバーAさんがドライバーBさんのところに余ったお弁当を持っていかなければならないとする状況で、Bさんの位置をタップすることでGoogleマップに飛んでルート指定をしてすぐに現地に向かうことができると

宮木：はい。細かいところではありますが、ドライバーさんのスムーズな業務に寄与できていれば幸いです。

− Flutterの採用を検討している企業に参考にしていただけそうなことは？

宮木：先ほど申し上げたようなメリットがあるので、新規でアプリを立ち上げる場合は、Flutterは有力な選択肢の１つになると思います。弊社で提供しているような業務用のアプリなどの用途であれば、Flutterで問題なく開発運用できるかと思います。弊社の新Flutterアプリについても、リニューアル前のネイティブアプリと比べて遜色ないものを提供できていると思います。要件によっては一部まだネイティブアプリの方が良い場合もあるかもしれませんが、ゲームアプリ等は別として、多くのアプリはFlutterで充分いけるのではないでしょうか。また、UIについてはFlutterはUI部分も含めて共通化して構築するので、iOSらしいUI、AndroidらしいUIというOSごとの差異とどうバランスをとっていくかは、各社によって判断が分かれるところかと思います。デザイナーの考え方にもよりますが、各OS向けのアプリらしさを追求すると、Flutterの中でもiOSならこう、Androidならこう、と個別の実装が増えていくので、ここはトレードオフがあると思います。弊社の場合は前述の通り、ブランディング上、比較的独自色の強いポリシーがもともと存在していましたので、ある意味それを逆に活かす形をとって、独自の共通のもので揃える判断をしています。ある程度OSのガイドラインや一般的な操作方法からは外れないような形を維持しつつ、どちらのOSで使っても原則同じUIで表示しています。 FlutterにはMaterial Designに準拠したUIコンポーネントが数多く揃っており、それらを用いて高速にUIを組み立ててしまうことができるメリットがあります。しかし、弊社の場合デザイン上それらは素のままでは使えないことも多く、コンポーネントに細かくスタイルを設定したり、必要に応じて独自のコンポーネントを一通り用意する手間をかけているため、この恩恵は100%享受できてはいない面があります。とはいえ、FlutterはUIコンポーネントの管理が非常にしやすいフレームワークですので、独自のコンポーネントであっても一旦それを揃えてしまった後は、他のコンポーネントと同じように使えるので、以後はFlutterの恩恵を受け続けることができます。

− 最後に、今回の一連の開発経験を通して得られたことについて教えてください

宮木：Flutterの技術的なスキルアップはもちろんできましたし、Flutter化する際に狙ったところについてはしっかり実現できたのかなと思います。 SmartDrive Fleet Boardアプリ、SmartDrive Fleet Driverアプリをリリース後からは、プロダクトチームのアプリの改善速度が一気に向上しています。毎月新機能追加や改善が入っていますし、細かいところも含めてどんどん磨きがかかっている状態になっています。構築済の機能であってもそこに課題があれば見直しをかけて改善するだけのリソースの余力や敷居の低さが生まれていて、これらはFlutterによりコードベースが共通化されたところが大きいです。現在はスマホアプリチームのメンバーが社員で3人、業務委託で2人いますが、以前であれば作業の優先順位的に後回しにせざるを得なかったことにも手が届き、細部の品質も上がっていると実感していますし、OS間や2つのアプリ間での仕様差分なども発生しにくい状態を維持できています。