[イベントレポート] CAMPFIRE iOS #1 に参加して来ました！ #yjcamp

はじめに

おばんです、最近RustというゲームをSteamで始めたのですが、農耕したり狩りをしたり鍛治をしたり家を建てたりしていい感じに原人から文明を成長させていったところで、野原の向こうから銃を持った三人に襲われて早速軽くトラウマ気味になった田中です。楽しいです。

さて今回はヤフー株式会社主催のCAMPFIRE iOSという勉強会のレポートになります。テーマが「アプリの設計」ということで、個人的にも最近関心の強いテーマなのでとても楽しみです！

CAMPFIRE iOSとは

iOS / Swift や、その周辺技術について情報共有する会です！

開発する上で浮かんでくる課題や、目まぐるしく進化を続ける Swift とどう向き合っているか、 そのときの課題や取り組みについて共有することで、

・新しい知見、発見を得る

・技術交流の輪を広げる

ことができる場を目指しています！

Connpassより引用

セッション

「最適な設計でアプリを作る」 田中 達也 ◆ ヤフー株式会社

「アーキテクチャを選定する理由が曖昧であるならば是非再考していただきたい！」という内容。try! Swiftでも話題になっていたMinimum Viable Architectureに共感したという田中さん。

アーキテクチャ選定を考える上でまず大切なのはチームで話し合うこと。設計方針を決定させうる要素はさまざまあるが、「大事にしたいこと（評価軸）を決めること」が大切とのこと。また、モックを作ってコードベースで役割をチームメンバー間で共有することも重要だとのこと。

「Wantedly Peopleが辿り着いた設計」　多和田 侑 ◆ Wantedly, Inc.

[後ほどスライドを挿入します]

Wantedly Peopleで採用してきたアーキテクチャについて。

リリース初期はMVVM × Rx × Realmを採用。APIの直列・並列を扱えるのでRxを採用。アプリの開発初期では12画面程度で他のアーキテクチャと比較して実装コストが低めで、コードの重複も少なかったのでこの設計を採用。

グロースの段階においては、MVVM + Interactor + Router × Rx × Realmを採用。ここでは20画面以上で、複数の画面に同じ操作を入れる必要が出たり、複雑になっていった。Interactorを設けることで、ViewModelの役割が小さくなり、コードの重複をおさえることができたとのこと。

「ホットペッパービューティーリプレイスとMVCP」　韮澤 賢三 ◆ 株式会社リクルートライフスタイル

ホットペッパービューティーのリプレイスにMVCPを採用した話。

ホットペッパービューティーは6年半稼働しているアプリで、秘伝のタレ化している部分もなかなか多い。1000行越え、2000行のVCも存在していた。MVCPというのは内部での呼び方で、つまりMVPのこと。Passive ViewのMVPを採用している。Passive ViewタイプのMVPの説明を実際のコードとともに紹介いただきました。

MVCPを導入を採用してみてわかったメリットは、以下とのことでした。

• 学習コストと得られるメリットの費用対効果が高かった
• 導入のハードルが低い
• ViewControllerの見通しが良くなる
• UnitTest可能範囲が明確になる

デメリットとしては以下とのこと

• MVCに対して登場人物が増える

「10分で振り返る、ソフトウェアアーキテクチャの歴史2017」 関 義隆 (@takasek) ◆ フリーランス(ほぼ株式会社FiNC)

年代を追いながら、MVC、MVP、MVVM、FluxをGUIの観点から紹介し、Model層に対する話としてLayered Architectureなどの紹介を順に紹介いただきました。アーキテクチャの説明を適切に分類して、網羅的に説明した良い資料があげられましたので、要振り返り！

「マネーフォワードの設計へのアプローチ」 児玉 孝太郎 ◆ 株式会社マネーフォワード

マネーフォワードではクリーンアーキテクチャを採用しているとのこと。クリーンアーキテクチャでは各レイヤが何を担当するのかを明確にしたり、レイヤ間の依存を最小限にできることなどがメリットとしてあげられる。それに対してコード量、ファイル数が多かったり学習コストが高いなどのデメリットもあるというのを、クリーンアーキテクチャが適している場合、適していない場合の具体的な例とともに紹介いただきました。

「Yahoo! JAPAN アプリという大規模アプリの設計と開発」 作井 吉満 ◆ ヤフー株式会社

Yahoo! JAPANアプリでは20名ほどの開発体制をとっているとのこと。約一年前、Swiftに乗り換える決断をした。

10名以上になって起きた課題として、全員で集まることが難しかったり、こまかな設計や仕様の共有が難しくなってくる。知らないところで案件がうまれ、仕様が決まり、実装が進むということも。それまで曖昧なMVCなどを採用していたが、同じ思想・パターンで並行開発できる設計が必要だという学びがあった。

そこから、役割を明確にしたレイヤーを分離させ、開発体制や急な仕様変更に対応できるようにしていった。

まとめ

最近の個人的な学習範囲が今回のテーマと同じ「アプリの設計」ということもあり、共感の多い良い会でした。抱えている課題とそれに対する様々なアプローチ、いかに乗り越えたのかという話も多く、ためになりました。

業界的にも設計についての議論が最近多いように感じますが、セッションの中でも各アーキテクチャに対して会場・登壇者共々同じ解釈をしているというような雰囲気があるようでした。業界内での認識の共通化が図られるのは、開発が加速するので良いですね！