いい感じにiOSアプリ開発プロジェクトを立ち上げる方法を考える
ここ数年、新規に開発するモバイルアプリのリードになる機会が何回かあり。プロジェクトの開始時期に毎度、README.md に開発方針を記述していたのだけど、いつも似たような内容になり公共性がありそうなのでそのままブログにした。
普段から「今回はアーキテクチャは何を採用しましょうか?」みたいな段階から議論がはじまるのを避けた方が建設的だと思っているので、その思想が反映されている。
想定する状況
我が社はこれからゼロからモバイルアプリを使ったサービスを提供するところであり、人手は少ないが開発初期段階から技術に投資する意気込みはあり、いずれはサービスの大ヒット、組織の大規模化を見据えて段階的に成長するアーキテクチャをバーンとやっていきたい。
事業領域は例えば決済サービスやビジネス系のモバイルアプリを想定している。
これは何?
iOSアプリのソフトウェア設計面についての現時点での考えを未来のメンバーに共有するための文書
基本方針
「ふつうのことを普通にやる」
ふつうとは—— ふつうの〇〇プログラミングというシリーズの良書があったり、Railsコミュニティなどでコンテキストとして利用されていたりする便利なイディオム。*2
僕の解釈では問題に対して多くの開発者が共通認識で選択する解決手法を採用すること。それによって環境要因や個人の嗜好によって偏りができるのを防ぐことができる。
なぜそうしたいのかというと、先の見えない開発なので技術的に凝ったことや挑戦に労力を使うよりプロダクトのUXに大きく寄与する部分に注力するため。技術的な挑戦がUXに直接的に関わる時は別。個人やチームの成長のための技術的投資は基本的にサイドプロジェクトでやることにしてる。
プロダクトの特性上、モバイルのアプリケーションの表面上でできる体験より。バックエンドのビジネスシステムの信頼性や運用にかかる効率化が価値となると考える。 (一方TikTokやインスタみたいな没入型の体験を提供するアプリケーションの開発に従事する人たちにはまた別の価値観があるのかもしれない)
決めたこと
- React Nativeを使わない
- 開発対象が素朴なUIを持つツールである。ドラゴンも出てこないしアイドルのライブ配信もない
- ユーザーがKyashやメルカリみたいなものを期待するとギャップが生じガッカリさせてしまう
- アップデート・保守面のコストが許容できない
- PMF検証フェーズであり、クロスプラットフォーム提供の旨みがない。アーリーアダプタもほぼiOSユーザーと予想
- RxSwift/MVVMでがんばらない
- Storyboardを利用。Feature単位でファイルを切る
- 多人数開発ではないのでコンフリクトのリスクが低い
- 標準コンポーネントを使って、デザイナ作業が不要である程度楽に開発が進む
- 単体テストは書く
迷っていること
- サーバーサイドとのデータやりとり
- 受信のみ。送信のみ。双方向。リアルタイム性。などの性質を加味して検討してる
- 巨大なHTTPライブラリ: Alamofireのようなものを採用するのか。範囲を絞って小さく使うのはありかもしれない
- またはAPIKitの仕組み: ユーザーは少ないけど筋がいい
- REST API: protobufやswagger-codegenみたいなものである程度自動生成するのか。実践したことないのでわからない
- gRPC: サーバーがPaaSなど制限があると検討外になりそう
- Firestore: 最近うまくいった(レイテンシ以外は) *3 APIクライアント層を書くかわりにサーバーエンジニアがCloud Functionsを書くことになりがち
- AppSyncやApollo: GraphQLツール群次第
Firebaseを使った成長するモバイルアプリのための高速なプロダクト開発 / Rapid Mobile Application Development using #Firebase
「Firebaseを使った成長するモバイルアプリのための高速なプロダクト開発」というプレゼンテーションのスライドを公開します。
2018年にバンコクにきて以来取り組んでいたプロジェクトについて技術的な内容をトークにしました*1。以下が概要です
モバイルアプリケーションの開発プロジェクトはあらゆる意味で速度との闘いです。
複雑化するシステムアーキテキチャやプラットフォーム、開発ツールのエコシステム。数多くある選択肢の中から私達は2018年にFirebaseを使い、1つのモバイルアプリケーションを開発しました。
本トークではその時の経験を元に、プロダクト開発を高速化するために技術者視点でどのような貢献ができるのか？ という知見をシステムアーキテクトの立場としてお伝えします。
開発中はFirebaseコミュニティの情報などが非常に助けになりました。この場をお借りして感謝の御礼を申し上げます。
*1:実はDroidKaigi 2019 応募用に書いていたやつ
WEB+DB PRESS Vol.108 に「フルスタックエンジニアの憂鬱」というエッセイを書いた
いつものごとくインターネットでイキっていたところ、突然発言数0でデフォルトアイコンのTwitterアカウントから執筆依頼のDMが送られてきたので快諾しました。
でも初見では完全に信用していなくて、この話に乗っかると僕の暗号通貨ウォレットの秘密鍵がコインをチェックされてしまうやつ*1だと疑っていたので、とりあえず締切前まで放っておきました。
自分ならどうやるかなーと考えてみたけどcon📛passで取引所のエンジニア特定してWEB+D💮 PRESSの者ですが寄稿しませんかとアプローチするhttps://t.co/PA4vhfyLr8
— laiso🇹🇭 (@laiso) 2018年5月12日
しかしその後の担当の人のメールの文体がいかにも編集者っぽい口調だったので本物っぽいなと思いながらやり取りしていました。万が一、入稿用のバイナリ実行ファイルが送られてきたら、たぶん話は終わっていましたけど……
どういう理由で執筆依頼が来たのかはよく理解していません。インターネットで見かけました、と聞きました。界隈の知り合いやその知り合い・他が既に執筆していたことがあるので、リファラルが効いてるのか上位互換の面子の誰かが受けられなかったのか、技術書書きたいと言ってたのを拾ってもらったのか、最近数ヶ月に１回は真面目にブログを書いていたからなのか、カンファレンスなどに出席してまともに対話できる相手だということがバレてしまったのか。
どうやったらWEB+DB PRESSに執筆できるのか？(コネか？) とよく周りで話題になっていたので、僕の結論としてはとりあえずインターネットでイキるのがよいのでは。という答えになりました。
閑話休題。エッセイは「壁の先に見えたもの」というテーマがあり、4人の著者がそれぞれフリーで2ページの文量を書いているそうです。独立した執筆なので他の人のことはよく知らないので発売当日に読むのが楽しみです。あとZOZO開発の特集も面白そう。
企画の「壁の先に見えたもの」というテーマを聞いた時の印象としては、なんかエモい感じの原稿が収集できそうな題材だなと思いました。ので素直にそれに乗っかりました。今考えると絶妙なお題だったのかもしれない。
書いた内容は要約すると、少数派な技術的志向を持つソフトウェアエンジニアでも強く生きろというもので、いつも説教臭くボヤいてるようなことです。「フルスタックエンジニアの憂鬱」というタイトルはとくに助言されたわけではなく自分でウケそうなやつを嗅覚で選びました。別に I'm フルスタックエンジニア. というわけではなくて、専門性を1つに絞れない立場である人(CTOとか)、または難儀な性格な人(自分)、を対象にしていて、詳しくは読めばわかります。短かいし。
WEB+DB PRESS Vol.108 にどうぞご期待ください。
- 作者: WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2018/12/22
- メディア: 単行本
- この商品を含むブログを見る
ボツネタ
- 詐欺師症候群について延々と説いていたらそれだけで埋まってしまったので全部消しました。Web検索してください
*1:NEM強奪犯は半年前から社員と交流を重ね、信用させたうえでウイルスを仕込んだメールを送りつけていた http://b.hatena.ne.jp/entry/s/www3.nhk.or.jp/news/html/20180512/k10011436321000.html
iOSエンジニアが知るべきProgressive Web Apps開発のエッセンス #iOSDC 2018
iOSDC Japan 2018 に採択されたトーク「iOSエンジニアが知るべきProgressive Web Apps開発のエッセンス」のブログ版記事です。
CfP提出後に内容は二転三転しまして、当初は最新Web開発事情について技術的に突っ込んだ内容にしようと目論んでいたのですが、「iOSエンジニア」へ「伝えたいこと」という軸で作っているうちにこの内容に落ち着きました。
当日聞きに来てくださった方、声をかけていただいた方。このような場を下さったiOSDCスタッフの方々にはたいへん感謝しています。
Introduction📛
昨年末 SafariにService Workersが実装され「iOSがPWAをサポートした」というニュースが業界内で話題になりました。 (※Progressive Web Apps 以降 PWA という略称で話します)
この時話題になっていたSafariのPWAサポートとはすなわちService WorkersのAPIの実装を指していたようです(Service Workersについては後ほど解説します)
このニュースは憶測や曲解を呼び、時には「ネイティブアプリの時代が終わった」という強い主張になって話される場面もありましたので、みなさんもどこかで目にしたことがあるかもしれません
状況を整理しましょう。SafariでService Workersが使えるようになったは事実です。これは既にその時点での開発計画にありましたので規定路線でした。
そして「ホーム画面に追加」でお馴染のSafariのWeb Clipの機能がWeb Manifestファイルに対応してアイコンなどを指定できるようになりました
しかし実際のアップデートはこれだけで、間違ってもAppleの誰かが「PWAに対応しました」などの声明を出したわけではありません
このようにPWAを取り巻く情報の解釈は複雑です。
私が思うに業界内で刺激的な話題が先行してしまったのは、Webとネイティブアプリ開発それぞれの側面で技術をただしく評価できていなかったからではないかと感じました。
ですから先ずWebアプリとネイティブアプリの開発者の目線で、Service WorkersとPWA、iOS Safariのことを理解するのが必要だと考えています。
このトークの前にiOSアプリ開発をしている知り合いのエンジニアたちへ「PWAという言葉を聞いてどう思うか」と質問してみました。
そこではUIやUXのクオリティやアプリストアでのファイダビリティの懸念などの意見をいただきました。
そこで気づいたのですが、PWAと名前が付けられたことによってネイティブアプリと比較して優劣を語る人の多さでした。ここの思い込みを先ず解かないといけなさそうです
また現状はAndroidのChrome上での体験とSafariでの体験は全く別物であると言えます。
その為、同じPWAという言葉を使って話していても、iOSユーザーとAndroidユーザーで捉えている像がそもそも噛み合わないということが起りえました
「PWAがネイティブアプリを置き換える」というストーリーは本質的ではありません
まず私が主張したいのがこれです。
その根拠となる理由を今からお話していこうかと思います
まず私がどういう立場でお話するのかというのを明確にするために、ここで自己紹介をします
私は普段スタートアップで Webエンジニアとして 仕事をしています。
そしてスマートフォンのアプリ開発も長く手がけているので、 iOS エンジニアのみなさんと近い価値観でお話できると思います
新しい技術全般が好きで、特に GUI のアプリケーション開発環境のことをよく調べています
PWAについて本質的な部分を知る
PWAという言葉は、広義ではWebアプリのUXを向上するムーブメント(運動)の通称です
最初はGoogle Chrome開発者らによって提唱されました
PWAに限らずGoogleは一枚岩の組織ではありませんから、Googleのどのチームの人達が言っているのかというのに注目するのがよいと思います
次に各プラットフォーマーにとってPWAがどのような意味を持っているのかというのに触れたいと思います。
Googleは古くはGearsやIE拡張、DartVM、Chrome Appsなどあらゆる方向からWebをよりよくする為の改善を続けています、その延長線上にPWAがあるのは不思議ではありません。
MicrosoftもWindows向けのHTMLアプリの強化を近年進めていて、先日正式にMicrosoft StoreへのPWAの登録を可能にしました。タブレットやデスクトップ向けのアプリ開発市場を活性化させたい意図が見えます。
MozillaにとってWebであることはNativeなのでWeb技術でネイティブアプリを作るのは当然のことです(ex: Firefox OS)
しかしAppleさん、完全にノーポジです。
WebKitにService Workersは実装されましたが、Appleは基本的にPWA関連の戦略を発表していません。
余談ですがiOS SDK誕生以前、アップルはサードパーティの開発者がWebアプリとして自分のアプリを公開するような構想を持っていました
これはセキュリティ上の理由による決定だったらしいのですが、開発者らの猛反発にあい現在のネイティブSDKの提供となったわけです
PWAとは元々、ネイティブアプリでは実現できるがWebアプリではできない体験の溝を埋めるために、ブラウザ側に実装された新機能を使うべしという側面があります。
Service Workers は「Webページ」という層より更に低レイヤー・ネイティブに近い層として処理を記述できる仕組みが用意されています。
そのため、PWA関連機能はService Workersと組み合わせて使うという例がよく出てきます。
では Service Workers とは何ものでしょうか? それは「ブラウザのオフライン基盤」と捉えるのがより本質的だと思います。
「プログラミング可能なネットワークプロキシ」という表現もされています。
この「ローカル」というのを「アプリがインストールされる」と考えるとiOSエンジニアにも理解しやすいと思います。
実際Service Workersの登録・アップデートの管理をブラウザが透過的に行ってくれる仕組みを含んでいます。
これによってWebページによるアプリの表の面とシステム上で動く「裏の面」が表現されているのです。
その他のブラウザの新機能(API)の例も見ていってみましょう
Android端末ではこのようにManifestとService Workersが定義されたWebアプリを開くとインストールを訴求するバナーが出現し、ホーム画面に追加できるようになります
一方Safariについてですが——
「ホーム画面に追加」 と Safari
PWA関連の記事で、まるで最新のアップデートでWebアプリのアイコンをホーム画面に追加できるようになったかの記述を見かけます
しかし、これは「Web Clip」という機能で、iPhone 3G時代から存在しました。
旧来、独自メタタグをHTMLヘッダに埋め込む形式の仕様だったものがService Workers実装後にWeb Manifest(JSON形式)をサポートしました。
このようにホーム画面に登録したページはSafariから切り離された単独のウィンドウとして管理されます(しかしcredentialの管理など既知の問題もあります)
次にPush Notificationです、Safariは今のところPush APIに非対応です。
デスクトップ向けにSafari Push Notificationsという独自の仕様があり、これとiOS Safari+APNsを統合しないことにはPush APIはiOSにくる未来はおそらくないのでしょう。
Payment - 支払い関連のAPIも最新のSafariで利用できます。
iOS SafariでもApple Payは利用できますし、この機能はうまくWeb標準とAppleの仕様が噛み合った例としてうまく機能しています。
つまりPWAとは、ブラウザに実装された、新機能を使うと、従来のWebアプリに不足していたUXが実現できる。
というだけの話なんです。
もしくは、WebアプリのUX向上のために新たなルートが引かれたと解釈すると良いかもしれません
なのでネイティブアプリと比較して優劣を語るのではなく、すべてのブラウザ共通で動作する従来のWebアプリと比較するべきなのです
Webアプリとネイティブアプリの比較
そうしたことをふまえて、次に「Webアプリとネイティブアプリの比較」です
Webアプリの利点として「動作環境が多用 」ということと「柔軟な配布方法」できる。ということがあげられるかと思います
Webアプリは外部アプリのWebViewの中からでも起動できますし、ブラウザさえあればどこでも動作します(そしてホーム画面からでも)
Webアプリの柔軟な配布方法についてです。Webアプリは常にサーバー上の最新版を参照し、Service Workersによってイントールする単位をインクリメンタルに管理することも可能になりました。
ここでいうオフラインファーストとは何でしょう。 それは、データを取得しなくてもUIを構成できるということです。
具体例としてはキャッシュされたアセットやレスポンスから読み込むことができます。
App ShellモデルというのもChromeチームが提唱したWebアプリのアーキテクチャの名前で、ネイティブアプリのメンタルメデルに近いのでiOSエンジニアには理解しやすいかと思います。
しかしiOS開発でオフラインファーストを意識する場面はどの程度あるでしょうか?
ネットワークのリトライ処理やキャッシュのハンドリングなどを独自に実装されている方も多いと思います。
WebアプリがWebであるがゆえに根本的に抱える問題というのもあります。
OSが持つ機能との接続はAPIが存在するか次第でありますし、ネイティブに見た目を近付けるほどその違和感が出てくるジレンマなどもあります。
UI遷移などはおもたる例で、ブラウザ上のレンダリングエンジンでOS権限でグラフィックAPI叩けてハードウェアに近い最適化のできるネイティブな実装に近付けるのは指南の技でしょう。
一方Safariの課題としては、Windows版Safari廃止以降に進んだOS独自機能の取り込みというのがあげられます
機能によってはWeb標準への準拠の動きはコンフリクトするため、うまく統廃合する必要があるでしょう
またiOSではChromeやFirefoxなどのサードパーティのブラウザはWebKitの利用を強制され、システムのデフォルトにできません。
ホーム画面にショートカットを置けるのもSafariだけです。
このためAPIの実装の進んだブラウザを使うという選択をとることができません
これは個人的な予想と願望なのですが、Appleがなぜ今頃になってWeb標準の実装を進め出したのかというと
既に世界的にシェアがあるモバイルブラウザ向けに作られたWebアプリをiOSで動かし利用者を取り込みたいのだと思います
つまり、AppleはAppleで自社デバイスのUX向上のためにSafariを改善していくのではないか? ということです
iOSエンジニアがWebアプリ技術に注目しておいた方がいい理由
2014年に話題になった「ロードマップ指向とエコシステム指向」というブログ記事があります。
ここでは、大きな企業が主体となって推進する技術的なトレンドが、オープンソースのコミュニティを中心とするエコシステム=生態系が技術を進歩されるということが示されています
エコシステム指向とはなんでしょうか? それは技術の革新を牽引する存在がプラットフォーマーなどの大きな企業から、それぞれの意思を持つ小さなコミュニティに移り変わったことだと思います
例えば、Googleのように。モバイルOSの開発をしつつブラウザ体験をよくする、しかしそれを置き換えるような新プラットフォームも開発している。という企業はそれぞれの方向性は違うが時には統合して進化している。という点が、非常にエコシステム的であるといえます
ここで注目したいのは現代でエコシステムを中心に急成長してきた技術としてのWeb開発環境です
ブラウザベンダーは標準化された仕様の実装でそれぞれ競争し、サードパーティのライブラリは各分野で御互いのいいところを取り込んだり、もっと良いやり方を提案したり巨大なOSSプロジェクトを戦略的に企業が運用・参加しています
Web技術のコミュニティではエコシステムで進化を促進する仕組みが機能しているのです。
iOSエンジニアの皆さんに近年のWebアプリ開発技術の進化の速度がすごい! というのを本日は知っていただきたいのです。
なぜWeb技術の進化が早くなるのか。それは、Webに関わる人口の多さが関係しているのだと思います。
ウェブブラウザやデバイスの利用環境は多様化していますし、Webアプリのフロントエンド開発技術はJavaScriptに集約されています。
思い起してみると今から10年前の2008年に「iOSエンジニア」という職業は存在しませんでした。
この10年、CocoaからiOS開発の環境は目紛しく変化しました。毎年OSやIDEが一新され、アプリは壊れ、プログラミング言語すら切り替わってしまいました。
AppStoreとわたしたちデベロッパーが作り出したアプリ開発のエコシステムが「iOSエンジニア」を作りだしたわけです
それと同じようなことはWeb開発の世界では今起っています。
AppleのロードマップによるiOS開発環境の進化を待つだけでは、もはや劇的な進化は訪れません。
私たちデベロッパーがエコシステムを乗りこなし、iOSの開発環境を進化させるべきだと思います。
例えばServer-side Swiftなどはまだまだ未成熟なので、非常にコミットする余地のある領域だと思います
10年後の「iOSエンジニア」を思い浮かべてみてください。Swiftで変わらずにアプリを開発しているでしょうか? それともFlutterでDartを書いているでしょうか?
10年後もiOSプラットフォームがユーザーにとって魅力的であるように…iOSエンジニアという職業を残すには、自分たちで未来を作ることが最良の選択です
そのために最新のWebアプリ開発技術を正しく理解して評価し、iOSアプリ開発に活かすのは重要なことだと思います
スタートアップの技術選定とアプリケーションプラットフォーム
photo by pexels.com
*1
この記事を書いたきっかけ
「PinQulをクローズします」にて事業のふりかえりをしている文章の中に「アプリビジネスは完全にダウントレンドにある」という一節があって、ここから話題が広がっていったのを機に上記の記事を読みました。そして色々思うところがあったのです。
(Twitter上で多くの共感を集めた投稿)アプリビジネスは完全にダウントレンドというのは自分も前から思っていた。リッチな体験、通知を遅れることはアプリの利点だが、他PFからの流入なども含めたプロダクトのコアな検証はwebモバイルが1番早いはず。
— sadakoa (@sadako_a_) August 16, 2018
例えば「モバイルアプリがWebに負けはじめた理由」ではWebアプリがモバイルアプリに比べて優れているでろうという点を分析させています。
そして僕が注目したのは以下の部分について
もっとサービスレベルの話でいくと、初めからwebでやればよかったというのもミスだったと感じている部分です。
最初にアプリで出すことにこだわりすぎてしまい、プロダクトの検証が遅くなってしまいました。ライブコマースの視聴・購入体験をよくするためにアプリでなければならないと思っていましたが実際にはwebでもほとんど遜色ないものを提供することができました。
PinQul のこれまでの軌跡をみると、2017年10月にiOS版リリース。2018年04月にAndroid。5月にWeb版。という情報がありました。
つまりiOS版をリリース後に少なくとも半年はAndroid版やWeb版を開発しつつ、iOSアプリの方向性を変えPMF(プロダクト・マーケット・フィット)を探っていたことになる。 その期間を3プラットフォーム並行開発するよりWeb版一本でフォーカスしたかったな、という後悔が出てしまうのは共感できた。なぜなら我々も同じような状況で悩み、現在モバイルアプリを開発しているからです。
そんなPinQulのIF...を元に、改めてスタートアップが新規プロジェクトなモバイルアプリを今0から作りはじめるとき、技術的な観点でどの道具を選択するのか、というのを考えてみたかった。
新規プロジェクトというのは俗に言うスタートアップでなくても1企業の新規事業部が0から作り出すソフトウェア製品のことでもいいです。
2012年のビーンボール
最初にPinQulの記事を読んだ時に2012年のマーク・ザッカーバーグのインタビューから起ったネイティブ/Web論争を思い出してしまいました。
これは当時Firebug作者でありiOS向けフレームワークthree20開発者でもあるJoe Hewittを中心に開発されたネイティブ実装で評判もそこそこ良かったFacebookの公式iOSアプリを、ある時に全面的にWebベースのハイブリッドアプリに置き換えようとした所、パフォーマンス問題などが顕著になりネイティブアプリに作り替えた時のものです。
マーク・ザッカーバーグのこのきわどい発言は、その場では投資家向けの弁明も含むもので、補足もされたのですが。様々な反論や憶測を呼び、業界を騒がせることになりました。
その後FacebookはPHPの魔改造Javascript拡張からReactを生み出し、2度3度ネイティブアプリ開発への移植に挑戦した後にReact Nativeを軌道に乗せているわけで、先の弁どうりWeb技術を諦めていない。というのはガチであったことが伺えます。
この一件は、PinQul とFacebook のビジネスのフェーズが全く異なるにも関わらずダブって見えます。おそらく2012年時点で「Webアプリはダウントレンドで、我々はネイティブアプリにフォーカスする必要がある」という空気が業界を襲ったことへの揺り戻しを感じさせるからでしょう。
当時の時代背景を知る手段として「Webはクソ。ブラウザはマジなんとかしろ」の記事をあげます。ここでは進化の遅く足並みの揃わないWebアプリ開発プラットフォームはネイティブアプリに比べて遥かに劣っているという意見が述べられています。
いま、Webは重要な転換期の中にいると私は思う。Webはデスクトップアプリケーションと同等になるのに10年以上かかってるし、しかもイマイチだ。そしてネイティブアプリが加速していく中でWebは絶滅の危機に瀕している。
——そして話は現代に立ち戻ります
モバイルWebファーストと貧者のツール
「貧者のツール(道具、技術)」とは、より少ないリソースしか消費できない環境で、なんとか道具を工夫して製品開発を達成するための考え方の通称で、「人ナイ物ナイ金ナイ」のスタートアップ向きであると言えます。
この貧者のツールとして、スタートアップが新規プロジェクトにモバイルWebファーストを採用する利点としては以下があげられると思います。
チームのエンジニアや開発するコードベースを最小にして高速に開発できる
通常のアプリ開発プロジェクトではWebバックエンド/iOSアプリ/Androidアプリ/フロントエンド。など技術やプラットフォームによって開発担当者をアサインすることが多いかと思います。
モバイルWebファーストにすることで、iOSアプリやAndroidアプリの開発に1-2人ぶんのリソースが取られることはなくなります。またWebアプリ開発者はバックエンド開発の片手間にフロントエンド開発も身に付けている人材が多いので、API→アプリクライアントサイドのコミュニケーションも短縮できる可能性があります。
高速に仮説検証できる
変更する対象コードが少なくデプロイも早い。担当する開発者間のコミュニケーションも省ける。となると高速にプロダクトを仮説検証できる 、というのが想像できると思います。
留意すべき点
しかしモバイルWebファーストの良い面の裏に、思わぬ落し穴が隠されているケースもあります
高速な開発を実現する為に選んだモバイルWebファーストが逆に開発の遅延を招く可能性も考慮すべきです。以下はその一例です
- Webアプリの方が実現が難しい機能
- デバイスに近いAPIを活用するアプリ
- ネイティブアプリで楽に実装できるパターンがよく知られている機能
例えば「QRコード決済アプリ」。これを僕が最初に想像した時はMediaDevices系のインターフェイスでWebでもサクっと実現できそうだなー、という印象でした。
しかし現実の QRCode Scanner のデモコードを見るとC言語のライブラリをJavaScriptに変換し、バックグラウンドでカメラをオーバーレイしたcanvasから抜き出した画像データを送りつける、という過激な実装で実現されています。
またデバイスに近いAPI、OSの機能を呼び出して実装するアプリはウェブで自力実装しづらいだけでなく、実現不可能=詰み状態が訪れる危険性もあり、注意が必要です。
その機能要件はネイティブアプリのが実現しやすいのか? Webで充分に開発できそうか? というのは結局両プラットフォームに精通した視点が要ります。貧者の組織にそのような人物の助けを借りることができるか? というのは怪しかと思います。
PinQulの開発が開始されたであろう2017年の春頃にライブECの要件(明日にはガラっと変わるかもしれない!)はWebアプリで充分に満たせるはずだ! と0ベースの状態で断言できるエンジニアはいないと思います。
スタートアップはスピードが命ですから、もしそれをやるにはプロジェクトの開発が決定する前からアイデアの技術的な検証を普段から行っていないとできません。
Komercoの技術選定
Backend as a Service (BaaS)を活用してサーバーサイド開発の工数を減らし、徹底的に仮説検証して高速に新規サービスを開発するぞ！ という考え方があります。
理想的なプロジェクトではバックエンド開発に携わる工数を大幅に削減でき、貧者のツール的であると言えます。
この思想でFirebaseをフル活用して作られたサービスに、クックパッド新規事業「Komerco」というアプリがあります。
Komercoは2018年6月にリリースされ、現在はiOSアプリしか提供されていません。
Komerco開発チームがこのままAndroidアプリやWeb版を開発するつもりなのか、iOSだけでサービスを検証してゆくのかは注目どころです。
※ 同じ手法で開発された「Cookin'」というプロジェクトはiOSアプリだけをリリースした後に、7ヶ月でサービスが終了しました*2
螺旋の原則
「技術選定の審美眼 」という名スピーチがあります。
ソフトウェア業界の技術トレンドは、一見振り子のように同じ場所に戻ってくるように見えるが、螺旋状に変化している。螺旋を作り出す技術要素の差分と、変化の中でも変らない抽象的な考え方に注目することの重要さが説かれています。
この螺旋の原則でいうと。モバイルシフト、アプリファーストの後にWeb回帰というストーリーに中に以下のような差分が潜んでいるのだと思います
- アプリがコモデティ化して、ネイティブアプリであること自体の競争力が弱くなった
- PCのWebブラウザからモバイルのブラウザへ主戦場が移った
- ブラウザやフロントエンド開発環境が劇的に進化した
例えばフリルやメルカリが世にリリースされたのは奇しくもFacebook HTML5ショックの2012-13年です。この時期にモバイルアプリファーストの開発に注力しているサービスは少なかったと記憶しています(そしてフリルはTitanium Mobileによるハイブリッドアプリ技術を選択し、メルカリはネイティブアプリSDK開発を選びました)。
多くのサービスは先ずデスクトップ向けサイトがケータイ対応し、それを元にスマホ対応→アプリリリース。と開発うるのが通例だったと思います。
この時期にネイティブアプリのUXを高めることにすべてを投資したプロダクトは現在も伸びています。
はたして2018年にモバイルWebファーストで開始するサービスはどうなるでしょうか、非常に気になるところです。
私たちのケース
締め括りに身の上話をさせていただくと、先日私たちもPinQulと同じような状況でネイティブアプリ開発に舵を切りました。
その時は直前までWebアプリ以外にもReact NativeやFlutterでの開発を考えて綿密にプロトタイプ開発をして準備を行っていましたが、スタートアップにありがちな「ある日状況が変わった」というやつが発生しました。
その時の意思決定の理由は以下です
- 一番手を動かしてコミットしてくれそうな新入社員のエンジニアがネイティブアプリ開発が得意だった
- それをサポートするエンジニア(僕)がだいたい何でも対応できた
- AWSからGCPに切り替えることができ、Firebase(BaaS)を全面採用できた
- 開発対象の要件がだいたい想像できた
そこから学んだことは以下です
- 仮説検証やPMFは1プラットフォームで行った方が良い
- 選択するプラットフォームは人的要素で決める
- 「隣の芝生は青い」を乗り越えるにはプロトタイプを作り続けるのが重要
P.S. 現実のプロジェクトとして実際に手を動かし、そのふりかえりを共有してくださったPinQulチームと井手さんに心から感謝します
iOSDC Japan 2018 に laisoから 1名 が登壇いたします
「iOSエンジニアが知るべきProgressive Web Apps開発のエッセンス」と題しまして、PWAムーブメント以降のWebアプリ開発のお話しをさせていただきます。
10年ビジネスとしてiPhoneアプリ開発を、個人の楽しみとしてウェブ開発とクロスプラットフォームのフレームワーク研究を嗜んできた私が現在関心を持っているのがこの最新のWebアプリ開発手法についてです。
おそらく以下のような内容になるかと存じます
「PWAとは?」でウェブ検索してキャッチできないような技術者的観点からレビューしたPWA論
マーケット、ビジネス的、組織的観点のPWA評はおそらく期待できません。ウェブに情報が溢れているので自身で見てもらった方が良いと思います。
クロスプラットフォームツールとして見たWeb開発
近年最も高速に進化しているGUI開発環境であるWebアプリのフロントエンド開発について、私見を交えiOS開発者にとって参考になるような内容にします。
抽象的で観念的なGUI開発の蘊蓄
好きなので。
複数のプラットフォームに精通するとGUI開発を多面的に捉えることができ、そこから発見できる自己理論を持ち出すことができます。
以下は本トークの雰囲気に近そうな窪塚洋介氏のインタビューです。
Google Docs でiOSアプリの画面を作る
アプリ内に設置する「利用規約」や「プライバシーポリシー」を前々から Google Docs のドキュメントを直でホストすればいいんじゃないと思っていたので実現方法を調べた。
Google Docs のドキュメントは
- URL末尾
/editで共同利用する状態 /previewで書類フォーマットの閲覧だけするURL/pubでWebページとして公開する時のURL
という3つのものがあり、 /pub をアプリ内に WKWebView で直接埋め込む。
Google ドキュメント、スプレッドシート、スライド、フォームの公開と埋め込み - パソコン - ドキュメント エディタ ヘルプ
見た目が気にいらない部分はJSで書き換えてしまう(Googleの標準フッタの表示を消してしまうと怒られそうではある)
webView.evaluateJavaScript(
["document.getElementById('contents').style.margin='0 50px';",
"document.getElementById('header').hidden=true;",
"document.getElementById('footer').hidden=true;"].joined()) { result, err in
assert(err == nil, err?.localizedDescription ?? "")
}
様子
Drawingや他ツールと連携できるので比較的表現力の高い利用規約が作れるような気がする
まとめ
- 作っては見たものの、アプリとウェブサイトで共有するために結局自社でホストするURL振った方がいいのかもしれない
- 閲覧者がリビジョン履歴を見たり「現在利用規約の見ているユーザー数」などを共有して盛り上がれるといいと思ったけどパブリッシュ済みのドキュメントはその機能はなかった