スタディサプリ小学・中学講座の iOS アプリエンジニアをしている @komaji です。本稿は スタディサプリProduct Team Advent Calendar 2024 15日目の記事で、私が所属する iOS チームでの技術改善の取り組み方について紹介していきます。
技術改善を計画する
継続的にプロダクトを開発する上では、技術的負債の返済や品質改善、開発者体験の改善といった技術的な改善が重要です。例えば、コードのリファクタリングやテスト自動化の導入が挙げられます。
これらの改善は一度実施して終わりではなく、プロダクトの成長や環境の変化に応じて継続的に実施する必要があります。しかし、全ての改善を実施することは現実的に不可能であり、機能開発とのリソースの兼ね合いも考慮する必要があります。そのため、技術改善の効果を最大化するためには、改善内容の優先度を判断し、優先度の高いものから実施していくことが重要です。
このように、計画的に優先度を判断しながら技術改善に取り組むことが、プロダクトの継続的な成長に寄与すると考えています。
将来のプロダクト状態を考える
優先度判断において技術的負債について考える場合、全て同じ期間で対応可能であれば負債の大きいものから順に取り組むのが望ましいです。ただし、現時点での負債の大きさだけでなく、将来的に予測される負債の大きさも考慮することが重要です。
将来的な負債の大きさを予測するためには、今後予定されている変更を把握する必要があります。具体的には、プロダクトの成長に伴う機能開発によって変更されるコードベースや、その変更内容を理解することが挙げられます。これにより、将来的な負債の状況を大まかに予測でき、ある技術的負債が大きく膨らむことが想定される場合には、事前にこの負債を返済する優先度を上げる判断が可能となります。
このように、現時点での負債の大きさだけを見るのではなく、将来のプロダクト状態を考えて技術改善を計画することで、技術改善の効果を最大化できると考えています。
技術改善計画会
これらの点にアプローチするために、私たちのチームでは、今後予定されている機能開発の変更内容の認識を揃えた上で技術改善を選定し、これをプロダクトバックログに組み込む運用方法を取っています。そして、これを四半期に一度の頻度で実施することで、継続的に改善できるようにしています。
技術改善を選定する会のことを技術改善計画会と呼んでいます。この計画会は、FigJam を用いて実施しており、会ごとに Page を作成して実施しています。以下の画像は実施後の Page の画像です。
アジェンダ
技術改善計画会の大まかなアジェンダは以下の通りで、ステップをいくつかピックアップして解説していきます（太字のステップ）。詳細なアジェンダは Appendix として記載しておきます。
- この会のゴール確認
- 前回の計画結果振り返り
- 今後の改修箇所の認識合わせ
- 技術的に困っていること・困りそうなこと・やっていきたいことを洗い出す
- グルーピング
- 共有・具体化
- 優先的に着手したいものを投票する
- 投票されたものに対しておおまかな見積もり
- アサイン決め
この会のゴール確認
この会のゴールはプロダクトバックログにのせる技術改善の選定としています。
技術改善は、1日や2日で終わらないものがほとんどです。むしろチーム内では、完了までに時間がかかるものを技術改善として定義しています。つまり、技術改善を実施するためには十分なリソースを割く必要があり、その間は機能開発に割けるリソースが少なくなってしまいます。これを iOS チーム内のみで暗黙的に進めてしまうと、チーム外からは機能開発の進捗が悪化したというように見える可能性が高いでしょう。そのため、他の開発案件と並べてプロダクトバックログに置き、iOS チーム外からも見えるようにしています。
さらに、プロダクトバックログにのせることで開発案件との優先度の調整が可能になります。可能というよりも必須という表現が正しいのですが、これにより、技術改善に取り組むための時間を確保できるようになります。優先度を調整するためには、 優先度を判断するために必要な情報を iOS チーム外に提供する必要があります。その情報として、「なぜやるのか」「いつ頃やれると良いのか」「どれくらいかかるのか」を挙げており、会を通してこの情報を出していく必要があるという認識を揃えられるように明記しています。
前回の計画結果振り返り
前回の計画会で選定した技術改善の状況を振り返ります。完了していないものがあれば、その理由を議論します。
また、技術改善の運用として、改善が完了したら取り組みを技術改善レポートとしてまとめることにしているため、このレポートの有無も確認しています。レポートにまとめるモチベーションとして、以下の点を挙げています。
- 他のチームの参考になると嬉しい
- 関連した取り組みに巻き込んでもらうきっかけを作りたい
- フィードバックをもらって更なる改善へ繋げたい
まとめ方としては、レポートを記載するための単一の Issue を用意しており、そこに以下のフォーマットに沿って取り組みをコメントするようにしています。
## タイトル ### 背景 ### やったこと ### 成果 ### 次のステップ ### 関連リンク
今後の改修箇所の認識合わせ
一番大事なステップです。私たちの機能開発では GitHub Projects の Board View を用いてプロダクトバックログを管理しています。この中で優先度が高い Issue リストをチームで眺めることで、今後の変更予定の認識を揃えています。
共有・具体化
「なぜやるのか」「何をやるのか」「いつ頃やれると良いのか」を明確にしていきます。これらの情報は、プロダクトバックログ上での優先度判断に必要なだけでなく、iOS チーム内で技術改善の優先度を判断するためにも重要です。そのため、すべての技術改善案に対して実施するようにしています。
一方で、プロダクトバックログ上での優先度判断に必要な「どれくらいかかるのか」を決めるための大まかな見積もりは、iOS チーム内では大きくズレがないと考えているため、iOS チーム内で優先度が高いと判断した改善のみに実施するようにしています。
計画会後に実施すること
計画会を終え、iOS チーム内で優先度を高く実施したい技術改善が決まったら、以下の手順を実施し、その後技術改善を進めていきます。
- 挙がった技術改善ごとに Issue を立てる
- 優先度に関わらず全て Issue 化する
- 優先度高く実施したい Issue の優先度 field に High を設定する
- 選定した技術改善を iOS チーム外に説明してプロダクトバックログに組み込んでいく
これまでに取り組んできた技術改善
この運用は今年から始め、これまでに２回の計画サイクルを終え、３回目の計画会を実施しました。詳細は割愛しますが、2回のサイクルを通して完了した技術改善を紹介します。
- NavigationStack 移行
- iOS 16 以降で deprecated となった NavigationView から NavigationStack へ移行しました。
- フィーチャーモジュール分割
- 単一モジュールで実装していた一部のコードベースをフィーチャー単位のモジュールに分割しました。
- Visual Regression Testing 改善
- スタディサプリ小学・中学講座のユースケースに合わせて swift-snapshot-testing をラップしたライブラリを作成しました。
- SwiftUI fullScreenCover 改善
- UIKit を用いることでモーダルの遷移アニメーションや背景を柔軟に調整できるようにし、よりリッチな表現を可能にしました。
- 認証機能のリファクタリング
- Combine 実装から async/await 実装へ移行することにより、重要機能のメンテナンス性を向上させました。
SwiftUI fullScreenCover 改善は、特に将来のプロダクト状態を考えて実施できた改善だと感じています。改善に取り組む前には、fullScreenCover をリッチな表示にするために、ワークアラウンド的な実装が行われていました。しかし、同様の表現を今後も実施していくことが予想されていたので、ワークアラウンドをやめ、新たな仕組みを導入しました。その後、すぐにこの仕組みを利用するケースが増え、改善の効果が現れました。
事前に改善することで、ワークアラウンドが増えること、もしくは、案件と同時の改善によってリリースまでのリードタイムが延びてしまうことを防げました。
おわりに
技術改善計画会を実施する前の運用としては、各々が Issue を立て、オーナーシップに基づいて不定期にチーム内で議論を行い、チーム外とのリソース確保の交渉を実施しながら改善を実施するというような形になっていました。この運用でも大きな問題はありませんでしたが、今回の運用に切り替えることで、技術改善の継続性や網羅性が向上し、より多く、より効果の大きい技術改善の実施に繋がっていると感じています。
計画会を実施する度にこっそりとアジェンダを改善していますが、引き続き改善しながら、今後も継続的にプロダクトを成長させられるように技術改善を実施していきたいと思っています。
Appendix: 技術改善計画会アジェンダ
技術改善計画会のアジェンダ全文です。これらを全て通すと2時間半くらいかかるので、２回に分けて会を実施しています。
- この会のゴール確認 (2 min)
- 前回の計画結果振り返り (10 min)
- 終わっているか？
- 技術改善レポートは書いた？
- 終わっていなければ阻害要因は何かあるか？
- 今後の改修箇所の認識合わせ(30 min)
- プロダクトバックログにある案件の中から優先度 High を見る
- 技術的に困っていること・困りそうなこと・やっていきたいことを洗い出す (8 min)
- 既存の技術改善 issuesを記載いただいても 🙆♀️
- グルーピング (2 min)
- 共有・具体化 (? min)
- 優先度を判断するために主に以下を話す
- なぜやるのか
- 何をやるのか
- いつ頃やれると良いのか
- 優先度を判断するために主に以下を話す
- 優先的に着手したいものを投票する (2 min)
- 投票されたものに対しておおまかな見積もり (5 min)
- N週間で終わりそう, 一旦N週作業したいなど
- アサイン決め(3 min)
