プロダクトアプリグループの太田です。
今回はココナラアプリ開発チームの紹介と抱えている課題、これからの未来について書こうと思います。
ココナラアプリについて
ココナラはWebとアプリでサービスを提供しています。
ココナラには、イラストやデザイン、プログラミング等の主にPCでやり取りが行われるサービスが多く出品されています。 にもかかわらず、モバイルアプリでの取引の比率が非常に高く、かなり重要なプロダクトに成長しました。 2年半前のネイティブアプリリリース時は雀の涙ほどの流通高で、クラッシュしてもほぼ影響がない勢力でした（泣）。 それが今や、メインのプラットフォームになり感慨深いです…。
常にとどまることなく機能を追加してきた結果、ココナラは仕様が複雑で巨大なサービスになりました。検索一つとっても「サービス」「出品者」「公開依頼」の複数軸があり、かつ個別に見積り依頼を出すことができ、様々な仕事の受注・発注の仕方を拡充しています。 アプリの機能としても電話サービスで利用する VoIP 技術を採用していたり、ぱっと見のただのECサイトっぽさからは想像もできない程の機能を抱えています。
これだけの機能を開発してきて市場にもある程度認知されてきましたが、稼働させていれば勝手に成長するような 運用フェーズにまったくなく、今後もどんどん新しい機能開発や技術的チャレンジ をしていきます。
開発チームと環境について
- エンジニア全体で22名
- 機械学習/分析：2名
- SRE（開発基盤）：7名
- プロダクトWeb
- フロントエンド：4名
- サーバサイド：5名
- プロダクトアプリ
- iOS：2名
- Android：2名
これを見てお気づきでしょうか…。
中核を担うアプリエンジニアが圧倒的に少ない！にもかかわらず圧倒的スピードで機能開発を進めてきました。施策ごとに動きながらもそれに関連する改善タスクを積み上げながら効率的に行なっています。
効率的に行うための仕組み
アプリ開発チームでは定期的に「もみもみ会」という名の各種検討会議を開き、細かい課題の共有や提案を持ち寄り、影響範囲含めてどう進めるべきかをチームで議論し、実際のタスクとしてチケット化します。
チケットは Zenhub でカンバン運用し、細かいタスクのリスト化を行なっています。小さめのものは常にできるものとして ToDo パイプラインに控えておき、ある施策対応と同じような影響範囲であれば一緒に開発を行ない、実装工数とテスト工数を削減しながら進行しています。
チャレンジできる環境
ココナラの文化は、ユーザファーストであれば新しいことをどんどんチャレンジできます。
一方で、技術のための技術は推奨されません。ユーザにメリットがある、セキュリティが向上する、DXが向上して素早くユーザに機能を提供できる等であれば積極的に行なっています。
また、新しい技術を試すためのサンドボックス環境も各チームに用意があり、自由に活用することができます。この環境で検証した結果実際に機能として採用されることもあります。
開発担当に関しては、アプリ開発チームだからといってサーバサイド (php, go, rails) を触らないということはありません。一応チームとして括りはありますが積極的に他領域の開発に携わりチーム内で開発が完結するのも少なくないです。チーム内でもiOS, Android,サーバサイドすべて開発するメンバーもいれば、全く経験のないプラットフォームにチャレンジしているメンバー ( https://yomoyamablog.coconala.co.jp/entry/2019/04/24 ) もいます。
やりたい熱意があれば実現できる環境がココナラにはあります。
チームで取り組むべき課題
新しい機能追加に耐えられるアーキテクチャの採用
AndroidではMVVM + Repositoryパターン、iOSではClean Architecture で運用に最適化したアーキテクチャを採用しています。常に新しい機能を追加し続けていくと、いずれ既存の運用に耐えれない局面がやってきます。
Androidでは一足早くその局面が訪れ、昨年の7月にリアーキテクチャを断行しDXが大幅に向上しました。
iOSは継続的コードベース改善を行った結果、新旧アーキテクチャが混在し、新たに加わったメンバーがどちらを採用すべきか迷ってしまう問題に直面しています。迷った結果、一番古いメンバーが指南し進めるという、その場で対応者が判断しづらい状態になっており、それぞれが独立して判断して動ける状態にするための整備が急務となっています。今後も継続してチームで最適な設計方針を検討し続けていきます。
- 関連記事
- Android開発環境について
- iOS再設計について
- アプリが巨大が故にビルド時間が長すぎる
メンバーの増加に耐えられる環境整備
今後のメンバー増加にあたって、前述の最適なアーキテクチャの採用も大切ですが、それ以外に早く立ち上がり、かつ無駄に消耗しない環境整備が必要になってきます。
人数の増加により、知らない情報があるがゆえのインシデント発生をとにかく防ぎたい。そのために各種ドキュメントの整備や、最速で立ち上がるためのオンボーディングが重要になります。
各種API仕様についてはすべてGithubで管理し新規追加や修正がある場合はドキュメントを修正し、プルリクを出すことによって施策ごとの変更点が即座にわかるように運用しています。その他の機能仕様ドキュメントが十分とは言えず、一部大きな機能に対しては詳細の仕様があるが、改善が入り続けるものに対しては更新が追いついていないものもあります。
今後は運用コストとクオリティのバランスをとって、継続的にドキュメントを正しい状態にし、オンボーディング内容と合わせて常に改善し続ける必要があります。
また、ジョイン直後は全仕様の把握は到底不可能なため、開発箇所の影響範囲を考慮するのが難しいです。考慮漏れ等のヒューマンエラーでの事故を防ぐために Unit Test を全部書く！が理想ですが、コスト見合いでそうもいかず、現状は最低限の箇所での自動テストが行われているのみとなっています。AppStoreへのサブミットやDebugビルドの配信は自動化が対応されているので、これに加えてテストコードの範囲を広げ自動化を更に強化していきます。
最速で問題を検知する仕組みづくり
課題として書かせてもらってますが、これは割と整備されつつあります。
基本的にはすべてSlackに通知しており、KPI系のアラートやクラッシュは即座に検知できるようになっています。サーバサイドのクリティカルなアラートも自動検知がどんどん進んでいます。
ただし、描画速度やAPI通信速度等のパフォーマンス系の自動検知がまだまだできておらず、一時期パフォーマンスが低下したまま稼働していたこともありました。アプリ基盤の整備と合わせて問題の可視化を進めていきます。
- 関連記事
- Firebase × BigQuery × Redash で快適アプリ分析
- Redashによるアプリ障害最速検知
今後のロードマップ
新機能開発や前述の課題の改善とともに、アプリ改善プロジェクトとして以下を計画しています。
gRPC
既存の Rest API での通信を Google が公開した Protocol Buffers を利用する RPC フレームワークである gRPC に差し替えるプロジェクトです。現在絶賛進行中で、gRPCの導入により、パフォーマンスの向上やスキーマ共通化によるAPIの安定化といったメリットが期待できますが、プロダクトへの投入には「運用のしやすさ」や「問題があった際の検証方法」等が確立されていなければなりません。
また、独立管理されたprotoファイルをどのように参照するのかも課題です。ひとまずある期間本番さながらの環境でテストし通信速度と運用のしやすさ両面で問題ないと判断できれば本採用していきます。
- 関連記事
- マイクロサービス化スタートしました！(api-gateway + golang + gRPC)
トークルームのリアルタイムチャット化
現状のトークルームとダイレクトメッセージはよくあるチャットアプリのようなUIをしているが、実はプッシュされて情報が来るのではなく他画面と同じくプル型の通信方式を採用しています。かなり低コストなプッシュ通知トリガーで実装しており、閲覧しているページに関するプッシュ通知を受信したら追加情報を取りに行く仕様になっています。
プッシュ通知をオフにしていたり通信環境によっては受信できないタイミングもあり、UXとして好ましくない場面があります。 これを正しくコミュニケーションが取れるようにする、リアルタイムチャット化プロジェクトです。市場にあるアプリの、あって当たり前の機能としてあるものは、すべて違和感なく使えるようにしていきます。
一部機能で Flutter の導入
アプリのクロスプラットフォーム開発界隈で Flutter 人気がかなり高まっています。これまでのXamarinやReactNativeと比べると一つ抜けた印象です。 これまでのクロスプラットフォームフレームワークは栄枯盛衰のサイクルが早くて、手を出すのに躊躇 (手を出したら最後までお付き合いしないといけない…) してしまっていました。そんな中、2018年12月に Flutter 正式版がリリースされます。おそらくそれまでの1番手ReactNativeと比較すると以下メリットがあると感じています。
- オブジェクト指向言語Dart採用でネイティブエンジニアの学習コスト低い
- 既存アプリへの正式な導入サポート ( https://github.com/flutter/flutter/wiki/Add-Flutter-to-existing-apps )
- ある程度の機能は標準ライブラリでサポート
そもそも想定されてるFlutterの使いかた「ミニマムに最速でサービスをリリースしその後グロースしたら各ネイティブエンジニアが面倒見る」ものと (勝手に) 思っておりそれに完全に逆行しますが、ココナラアプリには iOS/Android で完全に共通でシンプルかつ重要な機能が多々あり、それらを1ソースで管理できることにかなりの魅力を感じています。
「ちょっとした機能で試して、だめだったら取り下げる」といった軽い導入が可能なのでまずはチャレンジしていきます。
まとめ
現在の開発チーム状況を紹介させていただきましたが、いかがでしたでしょうか？
赤裸々にできていないと思える部分も語りました。まだまだ発展途上でチーム一丸となってあれこれ試行錯誤中です。
僕たちと一緒にココナラ成長させてくれるメンバーを絶賛募集中です！まずはふらりと遊びに来てください。
ユーザー志向のアプリエンジニア募集。技術選定の裁量あります - 株式会社ココナラのモバイルエンジニア中途の求人 - Wantedly