ミラティブエンジニアチーム四季報（創刊号）

こんにちは Mirrativ CTOの夏です。

現在、ミラティブでは事業部単位でチームや目標を管理しており、エンジニアが所属するチームとして以下の6つがあります。今回はこのうち、エンジニアチームについて、2019年度に行ってきた取り組みの振り返りをしたいと思います。

ライブプラットフォームチーム
- ユーザの定着を追う
マーケ連携チーム
- ユーザの新規獲得を追う
エモモチーム
- 3Dアバターであるエモモを使った新体験の創出・基礎体験の向上を追う
ストリーミング改善チーム
- モバイル端末でのライブストリーミングの配信・視聴の品質改善を追う
インフラチーム
- クラウド上での安定したインフラ基盤の設計・構築を追う
エンジニアチーム
- お問い合わせ調査、不具合・障害の再発防止、開発体験の向上を追う
AI技術部
- コミュニティやストリーミングとAI活用の可能性を追う

4~6月

全プラットフォームで負債の洗い出し

当時、まだAndroid4やiOS10系のサポートを行っており、シェアが少ない古いOSのために開発工数・QA工数が使われていました。そこで、コミュニティチームを巻き込んで、終了するとどういうことが起きるのか含めて、上手くユーザに説明できるように、コミュニケーション方法・時期について練りながら、古いOSのサポートを終了するなどの対応を行いました。

また、会社設立当初は、各プラットフォームそれぞれ1人で開発している状態で、短期的なリリーススケジュールを優先してきた結果、状態管理が複雑化し、新規機能追加時やバグフィックス時に該当箇所以外の理解や暗黙的な知識が求められていました。

その結果、副業や業務委託の方が入っても、なかなか生産性がスケールしなかったり、リモートで稼働している人にとって、キャッチアップに時間がかかる状態が続いていました。

そこで、見通しの悪さの原因の1つである、最強のBaseクラスの再設計を行ったり、不要になったライブラリの廃止（AndroidAnnotationなど）、ディレクトリ構造の見直し、Fluxの導入、分析ログの送信機構の改善、Lintの改善などを行ってきました。

tech.mirrativ.stream

これにより、開発体制がスケールする仕組みに向き合う土壌ができ、開発体験の向上戦略が整ったかなと思います。

リリースフローの整備

また、今まで、開発が完了した修正からアドホックに検証・リリース作業を行ってきたのですが、QAの日程調整やリリース作業の煩雑さを抑えつつ、毎週アプリの更新を行えるようにするために、以下のようなリリースフローを整備しました。

機能改修などのPRは基本的に金曜日までにQA済みの状態でdevelopへmerge
日曜日にbotにより自動でリリースブランチとリリースビルドを作成
月曜日・火曜日に本番環境でリグレッションテスト
火曜日の夕方にアプリを申請し、審査が通り次第（最速で水曜日の朝）にリリース

7~9月

🚑119番の開始

4~6月を通して、開発体験の向上のためのチームづくりは出来たものの、反省点としては、PMの熱量に負けてプロダクト側の開発を優先してしまい、なかなか開発体験向上のための時間をとれずにいました。

そこで7月からは新たに119番なるものを組成し、エンジニアが毎週日替わりで担当し、その日の担当者はプロダクト開発を行わない曜日としました。（カレンダー・ガントチャート上で抑えてしまいます）

行う業務としては

お問い合わせ1次調査 & 対応
エラー、クラッシュ、障害、その他不具合対応
パフォーマンス改善、障害再発防止対応
エンジニア以外からの細かい依頼タスク
PRレビュー、開発体験向上、フルスタック化、その他

などがあります。

週1日プロダクト開発できないとリリースサイクルが遅くなる恐れがありましたが、もともと属人的に依頼されていたタスクを当番制にすることで、残りの4日間はメリハリを持ってプロダクト開発に専念できたり、普段扱わない領域のコードを触る癖ができたかなと思っています。

特に、お問い合わせ対応に関しては、Backlogで管理することで、1営業日以内に対応完了できているかどうかを意識し、お問い合わせが放置されない体制作りや、そもそもお問い合わせが来ない（= ユーザが困らない）ために、どう再発防止すべきか、どうアプリのUXを実現すべきかなどをエンジニア自身が意識できるようになったかなと思っています。

新アーキテクチャのリファレンス実装の整備

前期での改善をさらに進め、7~9月はiOS・Android側はFlux化、サーバ側はAPI仕様のOpenAPI（Swagger）化とClean Architecture化を進めてきました。

もともとミラティブではMarkdown形式でAPI仕様を記述できるAPI Blueprintを採用しておりました。しかし、API仕様を形骸化させず、実装との差分をゼロに維持するために、自動テスト時や開発時には自動的にパラメータやレスポンスのValidationを行おうとすると、MarkdownよりもJSONやYAML形式で記述できるOpenAPIの方が仕組み化しやすいと思い、API仕様をOpenAPI化することを決意しました。

現在では移行が済んでいないブラックリスト上APIのエンドポイント以外は全て、仕様と実装に差異があると自動テスト時や開発時にエラーになるようにしています。（本番環境では計算コストを意識し、Validationはオフにしている）

iOS・AndroidのFlux化に関しては千吉良と morizooo から、サーバ側のClean Architecture化に関しては、次回、僕の方からまたこのブログで共有したいと思います。

10~12月

リファレンス準拠100%でレビュー工数削減

7~9月の改善でiOS・AndroidのFlux化のリファレンス実装が揃い、副業・業務委託の方々も含めた全員に共有できたこともあり、10~12月はiOSとAndroidのPRはほぼ全てFlux準拠することが出来ました。これに対し、サーバ側のClean Architecture化は、リファレンス実装の整備が12月までずれ込んだこともあり、PRの準拠100%は2020年1月以降の課題となっています。（そもそもサーバ側は自動テストの書きやすさも手伝ってか、レビュー体制が上手く整備されておらず、こちらもまだ課題として残っています）

障害の再発防止

ミラティブではMVP（Minimum Viable Product）を意識した開発を行っており、できるだけ早くユーザに触ってもらってフィードバックをもらうことを大事にしています。そのため、リリース後に時間を置いてから、開発当初に想定していた以上のアクセス数やデータ量になり、障害につながるケースも存在します。

もちろん、最初からスケーラビリティを意識した開発ができるに越したことはありませんが、綿密に流量を想定し、負荷試験を行って、リリース速度を下げるよりか、開発の練度を上げつつ、障害につながる前兆に早めに気づき、放置しない体制をつくろうと思っています。とくに、障害が起きてしまうと、ユーザの体験が悪化するだけでなく、調査・対応・補填含めてエンジニアのリソースがかなり消費されるため、障害の再発防止がエンジニア組織として最優先となっております。

そこで10月からは、以下のような領域毎にそれぞれ担当者をアサインし、彼らに優先順位を付けてタスク管理をしてもらうようにしました。（実作業は担当者が119番の日を使って行いつつ、時と場合に応じて他のエンジニアへアサインします）

障害の再発防止
- 障害対応した人に振り返りのドキュメントを1週間以内にまとめてもらい、ナレッジを共有することで、チームの練度を上げていく
- 今後joinする方のためにも、そもそも障害が起きない・前兆を早めに気付ける仕組みづくりをタスクとして優先順位付けしダッシュボード化
DB
- 最重要コンポーネントであり、ここの負荷が上がると、Webも詰まり始めるので、優先順位が高い
- tcpdumpとpt-query-digestを用いることで、MySQLへの負荷が支配的なSQLを洗い出し、そこから優先順位付けしてダッシュボード化
Web
- UXの改善やインフラコスト💵の削減に貢献
- 各エンドポイントのパフォーマンスレポート（実行時間やメモリ使用量）から、優先順位付けしてダッシュボード化
エラー
- 既存のエラーが放置され続けると、障害の前兆となるようなエラーが見逃されるため、発見次第潰す体制づくり
- 新規のエラーが発生した際に、原因となる修正を特定し、担当者に連絡