はじめに

こんにちはCDOの山下です。

ANDPADでは現在5種類のアプリをリリースしています。リリース時期もストアのversion 1.0.0が登録された時期から大まかに推定するとこんな感じでした。建築という業界であってもiOSの利用者数は多いため、そちらを先行して開発する傾向にありました。

アプリ名	役割	iOSリリース時期	Androidリリース時期	技術
ANDPAD	施工管理	2016/3	2016/3	swift/kotlin フルネイティブ
ANDPAD CHAT	チャット	2016/5	2017/3	swift/kotlin フルネイティブ
ANDPAD 図面	図面を管理・共有	2018/3	-	swift フルネイティブ
ADNPAD 検査	検査業務に特化	2016/8	2018/2	react native -> flutterに移行予定
ANDPAD 短工事	短期工事のための施工管理	2019/2	2019/4	flutter

私たちが提供しているANDPADというサービスは、2016年3月のサービスリリース以降、全国の職人の方々が毎日の業務の中で非常に頻繁にアクセスして使っていただけるサービスになりました。

頻繁に使ってもらえるという部分では特にモバイルアプリは大きな貢献をしています。データの観点からもモバイルアプリとWebの利用者数を比較してみると2倍以上の差があります。

想定している利用シーンから考えても、現場の職人さんは外で業務を行うためPCからではなく、スマホアプリから情報の確認・登録などのアクションを行なっています。また、建築現場においてもスマホ端末は比較的多くのユーザーが所持していますが、PCはなかなか全てのユーザーが所持するツールではありません。ですので全ての人に使ってもらうには難しい面もあります。

モバイルアプリの開発方針

より早く市場に新しい良いプロダクトを投入するために

サービスリリース当初は、私たちはユーザーの情報共有・コミュニケーション課題を解決するために尽力しており、「施工管理」「チャット」アプリを注力して開発していました。今も注力して開発していることに変わりありませんが、「建築業界自体がIT化が進んでいないこと」と「巨大な市場であること」からプロダクトとして求められる課題解決が多方面に渡ることがわかってきました。

そのような理由から、１つのアプリで課題を解決するのではなく複数のアプリで課題解決していく方針を取っています。このような方針は単一のアプリで勝負していく事業形態とは大きく異なります。

開発視点では、複数のアプリをリリースすることが前提でどのように複数のアプリを磨き込んで作っていけるかが大きな課題となります。日々の開発に埋もれてしまうとその場の戦いになりがちですが、アプリチームでは現在以下の３つの方針で開発を進めていこうという話をしています。

1. iOS/Androidのコードの共通化 - Flutterの採用

リスト表示やグリッド表示などのアプリでよく使われるようなUIで構成されるアプリは、Flutterを採用して開発する方針にしています。

このような標準的なUIに関してはユーザー体験の面でもネイティブと遜色ないパフォーマンスを発揮できるため、クロスプラットフォームのFlutterを積極的に活用したいと思っています。現在新規サービスの短工事のみFlutterで開発していますが、検査アプリもFlutterに置き換えています。また、既存のネイティブアプリにおいても標準的なUIで作られるような機能に関しては年末に正式リリースされたadd-to-appの機能を活用していこうとしています。 flutter.dev

今のアプリチームでは、ネイティブアプリの開発とFlutterでの開発が両方できる必要がありますが、毎朝Flutter勉強会を開催しており、元々ネイティブアプリ専任で入社したメンバーもFlutter開発ができるような状態になってきました。 Flutterは、アーキテクチャの流行り廃りが激しいので既存コードが陳腐化しやすくて大変ですが、エンジニアとしてはその辺りも楽しんでやっています。

2. 共通機能のモジュール化 - 基盤機能の拡充

アプリの中でも特にユーザー体験として重要で、より磨き込んでいくと決めた機能をアプリにおける「ANDPAD基盤」として定義しています。

モジュール化および共通化し、より独立して機能を磨き込んで開発できるようにしています。複数のアプリを作っているとは言っても、高度にモジュール化を進めていければたまたまドメインの境界がアプリの境界となっているだけで、ANDPADというサービス全体で捉えると単一のアプリを磨き込んでいくのと開発アプローチは大きく変わらないのではないかと捉えています。

f:id:oct88:20200608221252p:plain — 複数のアプリをANDPAD基盤を拡充させながら作っていく

ソフトウェア的にはモジュール化することで、複雑なUI操作が入り込んでしまったソースコードなどを既存コードから分離でき、エンハンスできる環境を作れるので良いこともあります。

しかし、人数が少ない中で切り出すと改善のサイクルが回しにくいというデメリットもあります。開発できる環境はあっても工数の問題で改善が後回しになりがちでもあります。直近数十人規模でアプリ開発メンバーも増える計画ですので、人が増えれば解決していく想定をしています。

3. テストコードの拡充

「良いプロダクト」を作るために、我々ができることは品質を上げることでもありますので、テストコード比率を上げていく取り組みもしています。

モバイルアプリのテストは、サービスリリース当初は１年以内にiOS/Android × 施工管理/チャットの計4個のアプリを最速でリリースすることが重要であったため正直、重要視していませんでした。最初の取り組みとしては、テストピラミッドの上部のUIテストから導入していきました。

f:id:oct88:20200712162543p:plain — テストピラミッド

テストの基礎 | Android デベロッパー | Android Developersdeveloper.android.com

現在は「共通機能の切り出し+テストコードの追加」と「リファクタ」によりUnit Testの比率を上げていこうとしています。また、アプリチーム全員がiOS/Androidのテストコードの理解を深める目的で週１で勉強会を行っています。全員が専門領域にとらわれずに全プラットフォームのテストコードを書いている状態を目標にしています。