寄付窓口はこちら

スタートアップのSwift | try! Swift Tokyo 2017 #tryswiftconf Day2-6 聞き起こし

twitter.com

スタートアップのチームはまだ小さいですが定期的に重要なプロダクトの変更をする必要があります。そのため慌ててコードを書いては書き直してということになる可能性があります。幸いなことにあなたたちにはSwiftがついています。このトークではHey! VINAというアプリをMVP(Minimun Viable Product)から1日に数千ユーザーが使うアプリにするまでのここ1年でSwiftを習得した教訓と、どの言語の特徴が大胆に動きつつも不安定さを避け、安定してアプリを提供するための柔軟さをもたらしたかを紹介します。

スタートアップのSwift

f:id:niwatako:20170303124154j:plain

過去一年ビギナーとしてSwiftに取り組んだ経験をはなします。

スタートアップでプリローンチで2000人のユーザーが出来た

2016年初頭に製品を打ち出しました。

f:id:niwatako:20170303124228j:plain

f:id:niwatako:20170303124238j:plain

女性の友人同士の友情を育むアプリです。友情以外で新しい街に引っ越したとか人生に変わったイベントが有ったあと、友達と出会うのはなかなか難しいですね。

素晴らしいアイディアだということで参加したんですね。

2人の創立者がいてそのアプリを出していた。でも問題も有りました。6ヶ月でこれだけのものが完成したのは素晴らしいし、彼女がアプリを作ったのがこれが初めてでしたのですごいことでした。

f:id:niwatako:20170303124429j:plain

専門知識もあまりなくいろんなことを学んでいかなくてはいけない。

f:id:niwatako:20170303124447j:plain

ビギナーとしての視点が役に立ったこともあった。

共同創業者がフルスタックエンジニアでした。Parseを使ってアプリを出しました。

私はTwitterにいました。Objective-Cの組織だった環境でした。Parseを使ったこともないし、Xcode以外のツールにのめり込むこともなかった。

すぐにコントリビュートする必要がありました。Push通知の問題を解決する必要がありました。Parseとうまく動かない。原因がわかりませんでした。

Swiftはシンプルで読みやすいですね。おそろい強い思いはせずに済みました。

f:id:niwatako:20170303124447j:plain

CocoaPodsなど今までのものを活用すればよく悩まずに済みました。

f:id:niwatako:20170303124727j:plain

最初の2週間で10万人のSubscriberが集まりました。

f:id:niwatako:20170303124832j:plain

f:id:niwatako:20170303124828j:plain

これほど多くの人がダウンロードすることを想定できていませんでした。

上限を超えたので制限をしてLAに限定して、星1をたくさんもらってしまいました。

でもアクセスをしたユーザーには良い体験をしてもらったということが大事だったと思います

アーリーアダプターでない人たちが使い始めるといろんな問題が出てくるようになりました。

Slackチャンネルを使って熱心なユーザーとつながり、TestFlightをつかってすぐにフィードバックを得られるようにしました。沢山のフィードバックを得られました

クラッシュの報告を受けて、クラッシュが再現できないと修正はできません。CEOが呼びかけて、クラッシュを経験した人に声をかけたら、来てくれた。彼女のiPhoneを繋いで、CEOと話して、すぐに問題が見えました。基本的に彼女のカードスタックの上で起きていることだとわかりました。

f:id:niwatako:20170303125120j:plain

そのユーザーはファーストネームがなかったんですね。

なぜ名前が入っていないのかわかりませんでしたが、リクエスト上限を超えてその間、名前がはいらなかったというようなことがあるのではないか、そして名前がNillであり続けないように対応して、クラッシュを避けることができました。

そしてUnwrapされている箇所を見直しました。switchのデフォルトシンタックスもよくある問題のパターンがあって学びました。

f:id:niwatako:20170303125243j:plain

Swift開発者が最初にやるべきことだったかもしれませんが知らなかったんですね。

ですのでこれによって多くのバグを減らすということをできます。

重要なのは新しいフィーチャーに対してコードベースを改善できます。

スキルを改善することでアプリケーションもアーキテクチャもブラッシュアップされていきます。

f:id:niwatako:20170303125401j:plain

資金用龍もして、、、などの段階になると良いコードを書くことはコストではないということになります。この段階でははじめに書いたコードをほぼ全て入れ替えています。

そうした時、リリースした日にParseが終了しました。非常に残念な瞬間でした。

マイグレーションは全員一気にやる必要がありました。

f:id:niwatako:20170303125511j:plain

同期を取れていないといけない。旧から新へ一気に移行するのが望ましいということになり、ダウンタイム数時間で実現しました。Parseにも新しいバックエンドにもアクセスできる、古い方から新しい方へ一方方向でUpdateする、ダウンタイム内に移行する。

難しいのはAPIに特化したコードがなかった。Parseはそれが無かった。新しいメソッドと置き換えするインタフェースもなかった。置き換えるコードがないわけです。

f:id:niwatako:20170303125640j:plain

こういうことをViewControllerでやっていて、あまりクリーンじゃないコードになっていました。

なのでリファクタリングをはじめました

f:id:niwatako:20170303125706j:plain

コードベースを複製して対応。Parseコードクリーンアップも楽にできます。 Parseと書かれたファイルを削除する。コンパイルが文句を言えば消す。

f:id:niwatako:20170303125816j:plain

プロトコルを作ってモデルオブジェクトのハンドリングをするということをしました。ロケーションを表示

新旧のロケーションオブジェクトがプロトコルを満たしていさえすれば良い

f:id:niwatako:20170303125853j:plain

プロトコルは抽象化で役に立つのでその後も残しました。

f:id:niwatako:20170303125938j:plain

個々までSwfitの使い方についてはじめの6ヶ月で優れた点を述べました。全て良かったわけではない。依存度合いが高まったり、Swiftバージョン以降も大変でした。頻繁に起きますよね。これだけ早くコードを書いていて誰もチェックしないとバグが起きる。

我々の状態だとダウンサイドも管理しやすいということが有りました。はじめの6ヶ月でこんなことが起きたという話でした。

f:id:niwatako:20170303130053j:plain

f:id:niwatako:20170303130059j:plain

Swiftは速やかな学習カーブが特徴です。初心者でも貢献することができます。 少数精鋭のチームを作ることができます。

リファクタリングもすぐにすることができます。

もっとも重要な部分に力を入れられることが重要です。

アプリケーションを次のレベルへ高めることに力を割くことができました。

現在はバックエンドのアップデートよりも活を提供することに力を阻塞事ができています。

はじめにサッと作ってみる、変化に対応する、そしてSwiftで作ってみる、ぜひやてみて下さい。

Q&A

2つ質問をしたい。スタートアップとして新しいアプリを作る場合でも、Parse.com などを使っていったほうが良いか。Parse.comから移行した際に独自にインフラに書き込むようにしたということだが、OpenSourceParseサーバーを建てなかった理由は

ちょっと明確化が必要です。なぜ違うバックエンドネットワークに行ったのか、自社のインフラを作らなかったのかという質問ですか?

これは制限があるんですが、チームメンバーの制限ですね。ブランドも考えてみたんですね。ユーザーは多くなっていたので。フルコントロールを握ったほうが良いとも思った。Railsに詳しかったので移行しようかと思った。考えなければならなかったのは他にどんなテクノロジーがあったかを考える必要があるしチームにどんなスキルが揃っているかということを考える必要があると思います。