こんにちは。HRの大畑です。

8月21日、渋谷ヒカリエ17Fにあるレバテック様のオフィスをお借りして、and factory主催イベント、
【マンガUP!、マンガPark、GANMA!】漫画アプリ開発の裏側、全部お見せします！を開催しました！

今回はGANMA!を運営するコミックスマーケット取締役の福西様にも参加頂き、マンガアプリの裏側を余すことなくお話させていただきました。当日多くの方にお越しいただきましたイベントのレポートをさせていただきます。

まずはマンガアプリ事業を展開するSmartphone APP Division取締役の青木です。

＜当日資料＞

and factoryの企業情報やオフィス環境などの基本的なお話から、今回のテーマであるマンガアプリ事業の成り立ちの説明に移ります。

2017年1月スクウェア・エニックス様との「マンガＵP！」、2017年8月には白泉社様との「マンガPark」をそれぞれリリースしました。

また先日発表した新たなリリースにも触れ、マンガアプリの成長性と関わるプロダクトが増えていることで「マンガアプリといえばand factory」となるような、点から面での拡大を目指しているといった戦略の部分にも触れています。そしてこの早い成長スピードを実現する要因として「コンパクトで距離の近いチーム」、「非常に大きい個の裁量」、そして「意思決定の速さ」の3つを挙げました。

プロデューサーを筆頭に、「開発」「マーケティング」「デザイナー」と少人数のチームを組んでプロダクトに臨むため、コミュニケーションロスが少ないことは特徴です。
エンジニア目線でいえば、新たな言語や開発手法を導入するといった際には現場の意見を最優先とするため、上長確認や稟議などで発生するタイムラグは存在しません。

もちろん裁量が大きい＝責任の大きさに繋がりますが、各々を認めあいながら働くことができる「プロフェッショナルの集合体」として、個の強みを最大限発揮できる環境だと言えます。

組織や事業の全体的な概要をお話させていただき、今回のテーマである「マンガアプリの開発裏側」の内容に繋げるべく、エンジニアの2人にバトンを渡しました。

続いて、iOSエンジニアの川辺裕太が登壇しました。

＜当日資料＞

川辺は2015年10月入社以来、and factoryのサービス開発基盤を支えてきたエンジニアです。

現在進行中のものも含め、3つのマンガアプリにおけるiOS開発の技術変遷を「設計」「レビュー」「通信」「自動テスト」という4つの観点で振り返っています。

■設計

・MVCの導入

最初のマンガアプリはMVCを用いた開発でした。ただしMは”Massive”のM、つまり巨大なViewControllerが存在するだけでした。この方法では、学習コストをかけずにすばやく開発することができるので、エンジニアとしても組織としても未熟な当時としては適切な方法でした。

ただし、マンガアプリは中長期の保守が前提となるため、保守コストが非常に高いMassiveVCは改善の余地が大いにありました。

・MVPの導入

そこで2番目のアプリではMVPを導入し、巨大なVCとなっていたものを3つの役割に分割しました。

役割ごとにクラスを分けたことでコードの見通しがよくなり、書き方の個人差も小さくなりました。

一方で、どこに何を書けばいいのか迷う場面が増えました。正解を探すためにミーティングをしたり、サンプルの学習などしていたため、開発時間も増えました。ただ、保守のコストを下げるために必要な時間でした。次のアプリでは更に役割の分割を進め、Clean Architectureを導入します。

・Clean Architectureの導入

新規プロダクトではClean Architectureをアレンジしたものを導入しています。

MVPと比べクラスの責務がより小さく明確になりました。これによってクラスの再利用や入れ替えも容易になり、保守性が大きく向上しました。

一方で、ファイル数が激増、依存関係が多いためクラスの生成が大変、などの欠点もあります。これらはツールやライブラリをうまく活用することで効率化を図っています。

■レビュー

次にレビューについてです。実際には2つ目のアプリからレビューを導入しています。

実施方法は、

• githubのPullRequestベースで実施（PullRequestテンプレート使用）
• チームメンバー全員で確認
• コーディングスタイルはSwiftLintで補助

レビューが行われることで属人性を低くし、コードの品質を高めることができました。

3つめのアプリではペアプロ、モブプロも並行して実施しています。指摘と修正のタイムラグがないため、効率よく開発出来ています。また、開発中に指摘が来るので受け入れやすく、チームの関係を良好に保つことが出来ています。

■通信

最初のアプリではAlamofireとjson、ドキュメントにApiaryを使っていましたが、ドキュメントと実装の乖離が度々起きていました。

そこで次のアプリではgRPCを導入しました。サーバとクライアントの乖離は防げるようになりましたが、コネクションのハンドリングで苦労するなど、gRPCのクセに悩まされました。

最終的にはそれまでのいいとこ取りをしたような、AlamofireとProtocol Buffer、ドキュメントにMarkDownの組み合わせに落ち着きました。現状改善すべき点は特になく、よい形にできました。

■テスト

自動テストは現在開発中のアプリから導入しています。

Clean Architectureのうち、ロジックを持つPresenterとDomainModelを中心にテストを行っています。依存クラスが多いためにモックも必要となりますが、Cuckooというテスティングフレームワークを使用しています。

学習コストとテストを書く時間は必要ですが、安心感とデグレの早期発見のために今後も継続して行なうつもりです。

■まとめ

ここに挙げたのは一例です。これまで多くの技術を試してきましたが、結果としてどの観点においても当時より良い方向へ進めることが出来たと感じており、今後もより良いアプリを作るための改善を進めながら、自分たちもレベルアップしていきたいと考えています。

and factoryの黎明期から技術面を支える川辺だからこそ見える技術変遷を丁寧に話してくれました。

次の登壇はAndroidエンジニア渡邉亮です。

＜当日資料＞

渡邉は2017年10月の入社からマンガＵP！の開発を中心に、現在進行中の新規サービス開発にも携わっています。入社直後から開発体制の改善に臨んでいて、今回「チームビルディング」について話しました。

■入社後すぐに行なったこと

これまでのand factoryの開発体制を整理したところ、以下のようになっていたことがわかりました。

良くも悪くもいわゆる「ベンチャー感溢れる開発体制」を整えていく必要があると考えました。

■整えるためには・・・

・リリースサイクルを1ヶ月1回に定義する。
　⇨そのためにもカンバンとWikiの作成をすることにしました。

カンバンにはTrelloを導入。ビジネスサイドを含めたチーム用と、具体的な開発タスクを追加する開発用の2つを用意。チーム用ボードはアイデア出しも含む、3つの目的と開発用ボードは進捗管理としています。

ただし、当初プロジェクト自体を1つのボードで管理していたため、改善したい点や施策アイデアなど溢れてしまい、結果カオスな状態となってしまいました。

機能を実装する上でAPIドキュメント項目に到達する時間がかかっていたこと、またマーケティングが共有してくれるKPIがチャット上で共有されていたために見辛いといった意見もあり、WikiにはConfluenceを採用しました。これはプロデューサーやマーケティングなどエンジニアが関わらない連携で使用するドキュメントのルートとしても使ってもらうことで、チーム全体のコミュニケーションを円滑にすることができました。

また、チームの結束が強くなったことは非常に意味があります。特にビジネスサイドにも課題や進捗を共有できるようになったので、開発上のタスク消化率をあげる必要性も伝わりやすくなりました。

■新規プロジェクト開発体制について

これまでの結果から新規プロジェクトではさらに改善を行います。

中でも顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供できるアジャイル開発の導入を決めました。アジャイル開発において守るべき原則は、

・動くソフトウェアこそが進捗のもっとも重要な尺度であること
・ビジネス側の人と開発者はプロジェクトを通じて日々一緒に働かなければならないこと

この二つを通じて、協業先（顧客）である出版社様とプロダクトに参加出来るスケジュールを組みます。

「設計」「実装」「テスト」「FB対応」という4つのフェーズで成果を上げますが、2週間をイテレーションと設定。最後出版社様との定例前にチェックとフィードバック対応を行ない、リリースまで繰り返していきます。

そして効率性を維持するためデイリースクラムとKPTを使ってアジャイルの原則を守りながら、最も効率的に情報を伝えられる「対面でのコミュニケーション」を行っています。

①デイリースクラム

朝、業務開始時にTrelloを大きなディスプレイに映しながらタスクの状態を確認します。細かく状況を設定することで小さな成果を可視化させ、ゴールへ前進しているイメージを持つようにしています。

②KPT
イテレーションが終わるごとにKPTを実施。改善点だけを指摘するのではなくメンバーの良かった点や振る舞いも挙げることで、改善とチームワーク維持に繋がるよう心がけています。特に能力でなく状況に対して問うことが重要であり、状況にフォーカスをすることで議論の土台を作ります。

KPTの結果がこちら。左からKEEP、PROBLEM、TRY、TODO、GOODと、一番右が今回のイテレーションの結果速報です。最初は元気なかったチームがイテレーション4では非常に活気づいているのことが分かっていただけると思います。

このように最良のアーキテクチャ要求設計は、チームで力を合わせながら生み出されるものです。

そしてさらにチームワークを磨き、生産性を追求するためにも「モブプロ」や「ドメイン駆動設計」を取り入れました。

③モブプロ

モブプロのことは先の川辺もお話しましたが、心理的に楽であること、チームで作業している雰囲気がとても気に入っています。疑問はその場で解決することで個人で解決するときに起こりがちな実装完了までの紆余曲折をなくすようにしています。

④DDD（ドメイン駆動設計）

設計フェーズでAndroidとiOSチームでどちらも同じクラス名・メンバー名を使っていくことで、これまで出来ていなかった知識の継承もしやすくなります。これはサーバークライアント間も同様に行っており、Protocol Bufferが共通のコミュニケーション媒体として機能していると感じています。

■まとめ

協業スタイルだからこそアジャイル開発が適していると感じたエピソードとして、出版社様から「こういった開発の進め方は初ですが、なんか良い」といったフィードバックを頂けています。

自律的な行動やリスクヘッジとなるような発言、また自分が他の作業をしていても滞りなく開発が進んでいたり、対面でのフィードバックループが出来ていることからもチームが機能していることに充実感を感じていて、開発メンバーには非常に感謝しています。

今後もさらに開発環境を改善していく活動を通して、

・ソフトウェア開発という仕事のネガティブなイメージを払拭し、チーム開発の楽しさを取り戻したい。
・チームに奉仕することでエンジニアが働きやすく、いいサービスを作り上げる環境の追求をしたい。

と、考えています。

現状に満足せず、より良いものを常に追求し続けている渡邉からは、これまでの改善結果とともに未来に向けた熱い想いを発表してくれました。

次回後編ではコミックスマート取締役、福西様と弊社青木のトークセッションをお届けします！
お楽しみに！

and factoryでは社内イベントであるBeer Bashやハッピーフライデーなども開催しています。
次回は9月26日（水）の19:30〜21:30にAndroidエンジニア向けイベントを行います！
ぜひお気軽にお越しください！（気になる方、コンタクトお待ちしています）