フロントエンド開発者は品質改善やTime to Recover短縮のために何ができるのか：Webフロントエンドエンジニアだけでスマホアプリ開発（終）

リクルートテクノロジーズが開発している、B2Bのスマホアプリ『Airシフト メッセージ用アプリ』。Webフロントエンドエンジニアだけで行っている開発の裏側を明かす連載。最終回は、品質改善で取り組んでいることや、テスト実施時間短縮に向けた取り組みなどについて。

[辻健人，リクルートテクノロジーズ]

　Webフロントエンドエンジニアだけで行っている開発の裏側を明かす連載「Webフロントエンドエンジニアだけでスマホアプリ開発」。最終回の今回は、B2Bスマートフォンアプリ『Airシフト メッセージ用アプリ』（以下、メッセージアプリ）のフロントエンド開発の品質改善で取り組んでいることや、テスト実施時間短縮に向けた取り組みなどを紹介します。

品質改善で取り組んでいること

「SonarQube」を活用した複雑なソースコードの検出

　「SonarQube」は、ソースコードの品質を、幾つかのメトリクス（コードスメル、カバレッジ、循環複雑度、重複など）から総合的に評価、管理できるサービスです。メッセージアプリでは、開発段階からSonarQubeを活用して継続的なソースコード品質の計測を実施してきました。

ソースコードの行数とメトリクスから計測した推定メンテナンス時間（左）と、品質のグラフと複雑度の遷移（右）

　計測した結果については、週に1回実施している「フロントエンド会」でグラフをチェックし、多責務になっているファイル・関数・クラスがないかどうかを確認しています。ここでは、具体的に「NG」となる指標は決めておらず、改善すべきかどうかはその都度チームメンバーとディスカッションして判断しています。

積極的なドキュメンテーション活動

　認証やプッシュ通知といった、プロセスが比較的ややこしい部分など、ハイコンテクストな箇所についてはソートコードと同じリポジトリにドキュメントを設置して、なるべくソースコードと近い場所で書いたら終わりではなく、日々更新しながら運用しています。ドキュメントを運用する上でこだわっている点は「書いたら終わり」ではなく、日々変化する仕様に追従してドキュメントを更新していくという点です。

ドキュメントの例

　それを踏まえて、「Confluence」で管理していたドキュメントのうち、より内部の実装に関するものをソースコードと同じリポジトリで管理し、いつでも閲覧できるようにしました。また、同じリポジトリで管理しているドキュメントから、Confluenceを始めとした関連ドキュメントへ飛べるようにしました。

　この取り組みは、当初はチームに浸透させるまでが課題だと感じていました。というのも、ドキュメンテーション活動は、正直なところ、実装より優先度が下げられがちだったり、「面倒な作業」と感じる人もいたりするからです（必要性を感じるまでの筆者も、面倒だと感じるタイプの人間に該当していました）。

　この文化を根付かせるため、軌道に乗るまで自分が積極的にドキュメントを書き、「ドキュメントがあると便利」という感覚をチーム全体に体感してもらう方法を採りました。その結果、チームメンバーそれぞれが、筆者も詳細まで把握していないような詳しい部分をドキュメントに書いてくれるようになりました。

「Sentry」を活用したTime to Recoverの短縮