estie の @hikrrr です。
Expo と Firebase を使って、社内向けのモバイルアプリ & Web アプリをつくってみました。ほかの業務と並行し、かかった期間は 1.5 ヶ月ほどです。リリースして 2 ヶ月が経ち、イケてない点の改修もコツコツ進んできたのでブログにしてみます。
使った技術について
ひとりで開発するにあたり、自分にとっての書きやすさを優先して言語は TypeScript を選びました。全社的にも Web 技術に親和性があり、ネイティブ言語を選ぶ理由はほとんどありません。
構成のメインは Expo + Firebase です。これらのおかげでとても効率的に開発できた気がしています。
Expo
- React に馴染みがあるので Flutter の学習コストを避けた
- これやりたい！って時に大抵モジュールが用意されていて、開発者体験が圧ッ倒的によかった
- Web アプリは
react-native-webでつくった。インタラクティブな挙動やスタイリングを実現しづらい
Firebase
- 認証や DB など諸々をおまかせ
- 複数の外部サービスを使うにあたって BFF 的な Cloud Functions for Firebase を作成した
どんなアプリ？
estie はオフィス不動産向けの SaaS を開発しています。
8 万棟のビルをはじめとし、データの数量・品質が肝となる事業です！
詳しくは企業秘密！ってことになりますが、ビルのデータを最新化するためのアプリです。「外出のついでにデータ収集できたらいいな〜」と思い立ち、今回開発しました。ユーザはモバイルアプリ（下図）を使ってデータを集め、Admin ユーザが Web アプリにてそのデータを確認・適用します。
アプリを二分した理由
Admin 側にデータの確認作業・適用権限を寄せたのは、表記ゆれによるデータ品質低下を恐れてのことです。例えば「〇〇ビル」との名称を持つ物件があったとします。それが “まるまるビル” や “マルビル（略称）” のようにゆれてしまうと、データとして正しく紐付けられません。
そのほか、ユーザが出先でデータをちまちま書き換える手間も懸念しました。
ただ Admin ユーザが確認すべきデータは多量で、作業にも正確さが求められます。その運用の重さが段々とわかってきました。技術や人力でどうにかカバーするより UI デザインの改善により解きたい（解くべき）課題と思っています。
figma はメモ的に使う
下図・左より、
- アイデア共有用のモックアップ
- 開発に向けて要件を取り入れたモックアップ
- 実際のプロダクトのスクリーンショット
です。詳細な UI デザインやスタイリングは、コードベースで行いました。
設計
Firestore への read を除き、アプリは Cloud Functions とだけやり取りするようにしています。
ユーザ側のユースケースは下記の流れです。
- 周辺ビルのデータを取得する
- 差分を見つけて入力する
- ビルのデータ更新を申請する
ユーザが誤ったデータを投稿する可能性は否めません。申請データ・確認済みデータについて、Firestore のコレクション構造を切り分けることで安全性を担保しています。
得られた成果
アプリのリリース前後で、収集されたデータ量を比較してみました。
ノイズデータを取り除けていないので実際は少し減ると思われますが、 10 倍以上のデータが収集されていることがわかります。データ精査における課題（先述）は残されつつも、数量については一定の効果があると言えそうです。
会社・事業が抱える課題へのチャレンジは、デザイナーの視点からすると (?) 新鮮に感じました。ユーザ・顧客の課題に寄り添うのとはまた違う刺激がありますね。
Slack の活用
今回はミニマムな手段として Slack を擬似的なストレージに採用しました。半恒久的にファイルを残せるので、定期削除や容量圧縮を考えなくて済みます。
Cloud Storage for Firebase を用いるほうが処理しやすいでしょうし、関連してユーザの待ち時間も短く済むはずです。しかし社内アプリなので、なるべくコストがかからず事業価値はより高まる（と思われる）方法を優先しました。
またリリースしてみて分かったのですが Slack App を組み込むと、運用・保守の面でコミュニケーションしやすいのもよかったです。補足情報の投稿やエラーの報告がパッとできるので重宝しています。
反省点
Expo を使うと、実機での検証がとても楽でおどろきました。開発用 PC と検証用のスマホを同じ IP につなぐと “Expo Go” アプリを介して起動できます。当然ながら開発中は Wi-Fi に接続していたので、通信環境が悪い状況を想定できていませんでした。不覚……！
フロントエンドに処理を寄せすぎた
リリースしてみると、アップロード失敗が多発します（エラー率およそ 10%）。
ただ、そもそもの原因は通信速度ではなく、アップロード処理のすべてをフロントエンドに任せていたことです。内実、アプリ側から段階的に複数のリクエストを投げるようにしていました。その結果、ヘビーユースしてくれる同僚をパケ死へ追いやることに……。
UI デザインの観点でも、ユーザとしては “投稿ボタン” を押せば投稿完了すると考えるのが自然でしょう。システムとして未完了な状態で、アプリを閉じてしまうのもなんら不思議ではありません（通信に時間がかかる場合は特に）。
そこでモバイルアプリは 1 つの Cloud Functions さえコールできれば済むように改修しました。 Cloud Functions がほかのバックエンドサービスとやり取りするかたちです。また、コールし切れなかった場合やサーバ側でクラッシュした場合などに備え、処理を再試行できるよう UI とアルゴリズムを変更しました。
バックエンド・コンプレックス
UI デザインとフロントエンドの統合に挑めば挑むほど、バックエンドを理解する必要性を実感してきました。ユーザへ快適なインタラクションを提供するためには View とその状態管理・表示分岐だけでなく、 DB とのやり取りやモデルの在り方など含めて設計しなきゃいけませんね。
これまでも「UI コンポーネントとデータモデルは互いを規定しうる」ような意識はありました。しかしデザインからエンジニアリングへ入ると、バックエンドまでの距離を感じてしまって……。今後ぜひ学んでいきたい分野です。
SaaS デザイナーとして
デザインの 1 つの効能は「ものの見方を変えること」だと思っています。つまり、サービスや製品を通してそれを使うひとの見る世界へ変化をもたらすことです。
みんなの解像度を上げたい
estie の開発メンバの多くが入社してはじめて不動産に関わります。ドメイン知識を重視するとは言え、ビジネス職の面々に比べると “愛着” みたいなものは（相対的に）薄いかもしれません。
そんななか、ビルの見え方を変えてやろうとの野望は少なからずありました。 業務で取り扱う存在（DB レコードや JSON データ、UI に表示するシンボル）を超えて、遊んで楽しめるようになれば不動産への解像度はさらに高まるかもと。
リリース後には「アプリを開いて街を歩いたらビルが解体済みだと気づいた」「それで顧客への提供データを修正できた」などの声をもらい、デザイナー冥利に尽きるなぁと感じました。
プロダクト開発のド真ん中にいたい
ひとの認知の仕組みや心の動き、人びとが営む文化・社会について強い関心があります。私がデザイナーを自認する理由です。しかし estie に入社して、事業を進めるにあたり肩書きにこだわっていてはダメだと確信しました。
ただその「何でもやる」ような広さこそ、デザインの特徴を表す概念と言えないでしょうか。ビジネスの起こりからプロダクトの仕上げまで、どんなところにも入り込めると思うからです。あらゆる職種と協業して価値を生み出す――それこそデザイナーの役目だろうし、私のやりたいことだ！
