エイチームコマーステックでエンジニアをしている奥田です.ネイティブアプリの開発をメインにやっていましたが,最近は機械学習やデータ分析も担当しています.

今回は,初めて採用したフレームワークであるFlutterを用いてペットフードブランド「Obremo」のアプリをつくった話についてまとめてみたいと思います!

Obremoアプリは,フード購入者向けのペットの体調管理やフード移行をサポートするアプリです

立ち上げの詳細な背景は,シニアデザイナーの @xiolkee のこちらの事例をご覧ください.

新規事業を立ち上げる際の開発は,技術選定からリリースラインの決定,コード品質と開発速度のバランス,開発の期限など,既存事業の運用とは進め方で異なる点が多いかと思います,,,

そこで,今回の新規アプリ開発の一連の流れを事例に,技術選定によるFlutter採用から,アプリに対して「どう要件を絞り込んで」「どうやってリリースを間に合わせたのか」について記載していきます!

過去にいくつかのAndroidアプリの開発を担当してきたため,ネイティブアプリの開発経験はそこそこありました.

これまでの経験もあって今回のObremoアプリの開発メンバーの1人に,,,当初から短期での開発を想定していたため,生産性などの面からFlutterか,React Nativeを検討しました.

FlutterとReact Nativeの比較

技術選定はもう1人のアプリ開発メンバーがメインで実施.技術的な観点をそれぞれ評価するマトリクスを作成して比較しました.

Flutterは初挑戦でしたが,私ももう1人の開発者もネイティブアプリ経験が豊富であること,メインドキュメントの充実度合いや,UIデザインのしやすさの観点から,Flutterを採用することに.

※技術選定当時はFlutter2もまだ出ておらず,現在とは状況が異なりますので,情報が古いかもしれません..

当時は,アプリのコンセプトや仕様はほとんど決まっておらず,「ペットフード購入後の飼い主さまのサポート」を目的にすることだけふわっと決まっていました.

また,アプリに工数を割けるデザイナーも不在で,UIや体験面もほとんど着手できていない状況,,,加えて,もう1人のアプリ開発者もWebサービスの開発を担当することになり,ほとんどのアプリ開発を1人で行わなければならないことになりました..

そのような状況でまず着手したのは,「現時点で得られる情報だけを使い,アプリの構成をひたすら妄想する」ことでした.

一番最初に雑に書いたアプリの流れ(汚くて恐縮ですが,,,)

ざっくりとアプリ上でのユーザー行動を考えながら,簡易な画面遷移やデータ構造などへ妄想を広げていきました.

簡易な画面遷移のイメージ(手書きでないと妄想が膨らまないのは世代かもしれない..)
データベースのラフな想定

デザイナーが後から合流してくれることはわかっていたので,「UIや仕様は変わる前提」で,使われ方の想定を深めていきました.

過去のアプリ新規開発経験から,ざっくりと「アプリはこう使われる」という肌感を持てたことが大きかったかもしれません.

エンジニアのただの妄想と落書きでしかないですが,これを基に,最低限どのような機能が必要か,技術的な懸念は何か,など,実際に手を動かす(開発や検証を行う)「ネタ」を作ることができました!

新規開発では「画面遷移がガラッと変わる」「良いと思っていたものが必要なかった」などは日常茶飯事かと思います.今回のケースでは特に,要件や仕様の変化を想定する必要がありました.

そのため,アプリ開発初期にいきなり全ての機能を精巧につくるのはリスクが高く,保守性の高いコードを書くコストも割くべきではないと判断し,「何度もつくりなおす」ことを当初から考えながら実装をスタートします,,,

一番最初につくったプロトタイプ,リストが閲覧できるぐらいの簡易なものを作成

最初のプロトタイプは,先程の妄想と落書きを基に「ユーザーのペットに関するタイムラインがあるだろう」という想定のもと,リスト表示は絶対にどこかで必要になると思って作った簡易なプロトタイプです.

次に,よりObremo要素を入れて簡易なチュートリアルや,ペット情報の入力などができるように作り直していきます.

徐々にログインなどの認証や利用規約への遷移も追加していきます.

なんとなく形になってきましたね!!

ここで少し,コードを書きながらわかったFlutterのよさを,,,

  • Flutterは宣言的UIを採用しているため,各コンポーネントや画面遷移などの実装が非常に簡単でした!
  • またアプリには,HTMLやCSSのような広く標準と言えるUIを構成するための言語が存在しませんが,Flutterであれば,iOS,Android共に,UIもロジックも1つの言語で記述することができます
  • 更に,独自のレンダリングエンジンでUIを描画しているため,各OSの細かい仕様変更に強く,機種依存や不具合が少なかったです.

元々私にはSwiftUIでのアプリ開発経験があったため,Flutterにすぐ馴染めた,というのもあるかもしれませんが,めっちゃ開発しやすい!!という声は多方から伺っています.

新規開発の際は,各種の条件を考慮した上で,Flutterの導入を検討していただければと思います!

話を戻して,,,こちらはログイン機能を実装した際のものです.

一方デザイナー側は,並行してユーザーインタビューなどプロダクト全体の検証を行っていて,まだまだアプリのことを考える時間が取れない状況...エンジニア側では,技術の習熟度を高めるため,「絶対に必要になりそうなところを」「何度もつくりなおす前提」で実装を進めていました.

こうして出来たプロトタイプを毎週デザイナー含むチーム内で都度レビューし,プロダクトの最新状況が常にチーム内に共有されているようにしました.

開発開始から1ヶ月後,デザイナーの @xiolkee がプロダクトにジョインしたことで,少しずつチームとしてアプリデザインに取り組める時間が確保できるようになってきました.

その辺りの時期に,最初のFigmaによるモックアップを作ってくれました!

当然,今まで作ってきたFlutterのプロトタイプとFigmaのモックアップは異なる点が多くありました.

ただ,プロトタイプを都度レビューしていたことで,エンジニアとデザイナー双方で,取り返しのつかないような認識や仕様のズレに早く気付くことができました.

そこから,プロトタイプとモックアップのズレを徐々に擦り合わせていきました.

ここで一番注意していたのは,「出来上がってしまったものは作り直せない」という誤解を産まないことです.プロトタイプを繰り返しながらアプリ開発を進めていても,この誤解による遠慮が生まれると,進め方が途中でブレてしまい,チームにとって本当に必要なプロダクトが作れなくなってしまいます.

この進め方のメリット最大現活かせるよう密にやり取りしながら,実装を進めていきました.

一方で,開発が進むと,ある時点で「ここから全部作り直すのは無理..」というデッドラインに直面します.

作り直せない状態になることを避ける工夫として,先のデザイナーとの擦り合わせの中で,「最低限これだけの機能があればユーザーがなんとか使える」というメインの導線を抽出して,まずそこを実装することを徹底していました.

もう作り直す必要が無いぐらい確実に「ユーザーに間違いなく使われる」導線に磨き上げた上でデッドラインを超えれば,取り返しのつかない作り直しを避けることができます.

その後,その導線を中心に,関連する様々な機能を実装していき,,,

結果として,リリース期日までに無事リリースできました!!!!

要件がもりもりになったり,大幅な仕様変更があったり,リリーススケジュールが予定どおり?遅延していくケースも多いですが,なんとか間に合わせることができました.

今回は,アプリの新規開発〜リリースまでのゼロイチの流れの中で,私が工夫したことを記載しました!

実際のアプリ開発では様々な事情や条件が絡み合うため,今回の事例が皆さんの助けになるかはわかりません,,,ただ,要件やUIが不確かな中開発を進める必要があったり,途中でUIをガラっと作り直さなければならない,というのは「あるある」としてよく耳にするケースです.

もちろん事前にそういった事態を想定し,組織的に対策をした上で,開発に望むのが理想と言えますが,チーム内だけで組織的な問題を根本的に解決できないことは多いでしょう.そんなとき,チームや自分達(エンジニアやデザイナーなどのクリエイター)だけで,少しでも新規開発の成功確率を上げるために工夫できることがあるはず,,,小さいですが,そんな事例の1つとして,皆さんの参考になれば幸いです!

また,ここ数年,私は機械学習やデータ分析をメインの業務としており,今回は限られた期間だけスポットでアプリの新規開発を経験させていただきました.

アプリ開発技術は,私が初めてAndroid開発に触れた2009年から格段に進歩していて,開発も当時では想像出来ないほど楽に便利になっていることを,Flutterの経験によって改めて実感できました.

あと,アプリ開発の楽しさは相変わらずですね!時間は限られますが,今後もアプリ開発には出来るだけ関わっていこうと思います!

最後までお読みいただきありがとうございました!!

このデザイン組織をもっと知る