iOS版「Graffity2.0」開発における3つの初体験
Graffity iOSを先日大幅にアップデートしました。僕は「Graffiy2.0」と呼んでいます。
このアプデに当たって、僕は３つの初体験をしました。
人生において童貞を卒業するチャンスは１度しかありませんが、「Graffiy2.0」開発においては３回卒業したようなものです。そのくらいいい経験だったと思います。
ってことで、
- 実装
- チーム構成
- PMF達成に向けた開発
の豪華３本立ての初体験を紹介します。
初めての実装
今回のGraffityではiOSで用意された様々なフレームワークを使いました。
- ARKit
- SceneKit
- CallKit
- PushKit
- Contact
- AVFoundation
- MessageUI
- Codable
また、サードパーティでは、
- FirebaseDynamicLink
- KingFisher
- Hydra
などを使っています。
一番苦戦したフレームワーク
一番苦戦したのは、PushKitとCallKitです。 VoIPプッシュという存在さえ知らないところからだったので、いろいろわからなくて苦戦しました。 Qiitaとかで概要をまとめられたらと思います。
JSONのparseはCodableが便利だと実感
今回APIから受け取ったJSONは全てDecodableに準拠したentityを作ってparseしました。 また、リアルタイムで相手に線を送るためにp2p通信しているのですが、その時もCodableのentityでJSONにして受け渡ししています。 慣れるとめちゃ便利です。 今まではSwiftyJSONやUnboxを使っていましたが、今後はCodable一択になりそうです。
やっとARKitの理解
JOINした当初はARKitに対してコミットするよりも、 既存のUIを整えたり、全体のリファクタリングばかりやっていたのですが、 その辺も整ってきて、3Dプログラミングの勉強とARKitとSceneKitで用意されているAPIの理解するために時間を使えるようになってきました。 エンジニアとしてGraffityでやりたかったことができています。
初めてのチーム構成
実はリニューアル前のGraffityはReact-Nativeで作られていたのですが、今回から全部swiftにしました。 それにあたってiOSはほとんど１から作り直しています。
今回のリニューアルは、着手から１ヶ月半 でリリースまで行ったわけですが、僕以外に２人のiOSエンジニアが開発に携わっています。お２人の許可もいただいたので、紹介させていただきます。
@gomachan_77
１人目は @gomachan_77です。
副業で手伝っていただきました。 以前はCyberAgentでiOSをやっていて、今は某コンシューマゲーム会社で皆も知ってるあのゲームを作っているそうです。
朝から２時間稼働、夜に２時間稼働！みたいなスタイルで、手伝っていただきました！ 彼がいなかったらこのスピードでこの品質のアプリは作れていないと思います。
僕よりエンジニア経験が多い先輩なので、書き方を吸収させてもらいました😆
@shu223
あの @shu223 さんです。
iOSxBLEの本やARKitSamplerなどのSamplerシリーズ、この前の技術書店では Metal入門 が話題でしたね！
GraffityのCEOの森本君の繋がり経由でお手伝いいただくことになったのですが、自分が #筋肉swift で目立っていたことで認知されていたのは大きかったですw
@shu223 さんには、主にネオンペンという光るペンの実装や、その他パフォーマンスまわりの改善や相談に乗っていただきました！
おかげさまでARKitの勉強になりますし、Metalの実装を一緒に仕事をしながら目の当たりにできているのは大きいです。 また、パフォーマンス向上のためにInstrument等を活用して調査することを全然してなかったので、実践的な使い方を教わることができたのも良かったです。
↑堤さんのブログにもちょろっと出てます。
副業も含めた少数精鋭チーム
以上の優秀なお２人にパートタイムで手伝っていただきました！ つまりiOSは僕入れて３人チームです。 また、APIは @mutun が頑張ってくれました😍
フルタイムのエンジニアは、僕とmutunだけで行ったGraffityですが、パートタイムのメンバーを含めた新しいチームでの開発によってリリースしたことが良い経験となりました！
パートタイムの２人がバリューを最大限発揮するために心がけていたのは、
- 最終的には自分が責任をとるというスタンスでいること
- できるだけ実装に集中できるようにタスクを明確にすること
です。
もちろん完璧にディレクターをやったわけではないですが、開発以外の無駄な時間を２人にできるだけ使わせないようにしたいなと思っていました。 自分も副業や個人アプリ開発では、短い時間で効率よく進めることを意識するので、その辺を気をつけることができたかなと思います。
初めてのPMF達成を意識した開発
最後に。今回は、PMF達成に向けた開発を意識しています。 というのはつまり、無駄なことをせず、変化に強くなるよう開発したということです。
優先順位をつけて開発しないと一生リリースできなくなってしまいます。 リリースが遅延すればするほど、仮説検証が遅れてしまい、PMF(プロダクトマーケットフィット)が遠のきます。
３ヶ月かけて自分たちの思う完璧なアプリをリリースするより、 １ヶ月半でMVP(Minimum Viable Product)を開発し、仮説検証をスタートすることが効率的な時間の使い方です。
今回リリースしたプロダクトは新たな仮説検証のためのベースであり、完成品ではないという考え方を持っています。 その考え方を持って開発して具体的に何をしたかというと、
- コードを捨てやすいようにDDD構成にした
- deploygateにすぐあげてデザインチームに毎日共有した
この２つです。ちょっと説明します。
DDD
ここでいう、DDD(Domain Driven Development)は、CleanArchitectureのpresenterは作らない構成です。
- 仕事ごとにUseCaseを作って分ける
- APIはCodableに準拠したentityにparse, Translaterが使いやすいDomainModelに変換してからUseCaseに渡す
て感じです。
使わなくなった機能はUseCaseごと捨てるだけで済むようにします。いろんなところに散らばると捨て難くなるからです。
また、entityとDomainModelを分けることは、APIの変更とUIの変更の影響を小さくすることに貢献します。
機能はすぐに変わるので、変化に強くしようと思ってこのようにしていますが、なかなか良いです👍
deploygateにすぐあげてデザインチームに毎日共有した
今はfastlaneにdeploygateに上げるlaneを作って、Bitriseでdeploygateに自動であげています。
それの準備が間に合ってない時は、ローカルで dg コマンド使ってdeploygateにあげていました。
デザインのチームが常に最新版を使ってヒアリングができるように、毎日deploygateに上げることはワークしたと思います。 今後もAppStoreのアプリのアップデートだけでなく、deploygateの検証版でデザインチームにヒアリングしてもらって、改善を重ねていくと思います。
「頑張ってAppStoreのアプリをアップデートしたけど、方向性が間違っていて、ユーザーに使ってもらえませんでした。」という言い訳を言うことがないよう、細かく仮説検証してPMF達成に近づいて行きたいですね。
まとめ
以上、今回のリニューアルでは３つの初体験をしました。これからもGraffityで面白い経験を積んで行きたいです。
日本語対応はしばしお待ちを！！では！
