こんにちは、モバイルエンジニアのころむにーです。
普段、モバイルアプリを通じたユーザーへの価値提供を目指すプロジェクトに、技術リードという立場で参加しています。
本記事では、コードの内部品質について、私が直近のプロジェクトで取り組んできたことをまとめました。
背景
プロダクトで継続的に価値を提供していくために、コードの内部品質を高く保つのは重要です。
内部品質は目に見えにくく定量的な成果が出にくいものであるものの、中・長期的にビジネスの成長に大きく影響してきます。
私がジョインした開発チームでは、各メンバーごとの内部品質に対する意識がまちまちでした。
コードの内部品質に関して、重要視しているメンバーもいればそうでないメンバーもいるという状況でした。
その中で、技術リードとして、内部品質をチーム全員で高めていくために取り組んできた内容を振り返ってみます。
私の立場
iOS、Android アプリの開発を担当しているエンジニアがそれぞれ 4 人程度いるチームで、モバイル全体のリードを担当しています。
iOS、Android それぞれには、リードエンジニアが 1 人ずついて、それぞれのチームを牽引しています。
私は、リードエンジニアたちを中心にサポートをしつつ、チーム全体でパフォーマンスを発揮できるように様々な取り組みを行っています。
取り組みの一環で、コードの内部品質を高めるための取り組みを行ってきました。
やってきたことの概要
ある程度の規模のチームだと、1 人 1 人の全ての作業に対してマイクロに指示を出していくことは現実的でないです。
そのため、目指すべき方向性を抽象的に伝え、1 人 1 人に自律的に考えて行動してもらえるようにしました。
一方で、目指すべき方向性を抽象的に伝えるだけでは、実際に行動に移してもらえないことの方が多い。
そのため、具体的な行動につながっていくよう、自ら手本を示したり、細かい仕組み化を行ったりしました。
さらに、これらの改善活動が本当に改善に繋がっているかを確認することも重要です。
そのため、定量的、定性的な評価を見え、定期的に観測するようにしました。
以上のように、方向性を示す、運用する、観測するといった 3 つの観点から取り組んできました。
それぞれを詳しく以下に記していきます。
1. 正しい方向をチームに示す
チームは 10 人弱のメンバーが所属しているため、1 人 1 人の全ての作業に対してマイクロに指示を出していくことは現実的でないです。
そのため、目指すべき方向性を伝え、1 人 1 人に自律的に考えて行動することを促しました。
1-1. 理想状態を共有する
まず、目指すべき方向性を抽象的に伝えるミッションステートメントを制定しました。
また、そのミッションステートメントにつながるマインドセットも明文化し、共有しました。
具体的には、「チーム全体で内部品質を高め、困難なバグ対応に苦しむことなく、クールに価値提供していけるチームを目指す」というミッションステートメントを伝えました。
また、マインドセットとしては以下のようなものを伝えました。
- いつやるか？ → 全てのタスクで
- 誰がやるか？ → 全員で
- どうやるのか？
- スピードよりも内部品質の高さを優先する
- 短いコードよりも、誰がみても誤解しないコードを目指す
- 修正する範囲のベストよりも、既存コード全体でベターな書き方を目指す
1-2. 現状を共有する
ミッションステートメントなどを伝えるのととともに、現状をメンバーに正しく把握してもらうことが重要です。
現状を把握することで、ミッションステートメントにおける理想状態とのギャップを認識し、全員で課題に一丸となって取り組むことができるようになるためです。
逆に、メンバー間で把握している情報の格差があると、課題感の重要度などの目線が揃わなくなり、一丸となって取り組むことが難しくなります。
プロジェクトでは、以下のような取り組みを行いました。
- 定量的に見える内部品質をダッシュボード化して、全員が見えるようにした
- こちらに関しては、後の章で詳しく記述します。
- プロジェクトで発生した課題について、全員が正しく把握するような機会を作った
- 重大なバグが発生した際には、その重大度を共有した
- 重大なバグに関して、原因分析と再発防止策をチームを巻き込んで特に念入りに行った
1-3. 日々の活動で、向かう方向を共有し続ける
前述の理想状態に向かうためのマインドセットは、日々の活動で常に意識し続けることが重要です。
常に意識することで初めて、日々の 1 つ 1 つの行動が良い方向に向くためです。
プロジェクトでは、常に私から向かう方向を共有し続けるようにしました。
例えば、メンバーに何かやってもらいたいとき、やってもらう内容だけでなく、なぜそれをやってもらいたいのかという背景や意図を明確に伝えるようにしました。
以下は、コードレビューで指摘する際のコメント例です。
この実装方法を採用した背景をコードコメントとして残しておいて欲しいです！
以下が背景です！
- 後からこのコードを見た際に、実装時の背景を考慮せずに変更を加えて意図せずバグを発生させることを防ぐ
2. 正しい方向に向かうように運用する
前章では目指すべき方向性を抽象的に伝える方法について記述しました。
一方で、目指すべき方向性を抽象的に伝えるだけでは、実際の行動に繋がりにくいです。
そのため、具体的な運用につながっていくよう、細かい仕組み化を行ったり、自ら手本を示したりしました。
2-1. 一定のコストを確保して取り組み続ける
内部品質向上の取り組みは、常に一定のコストを確保して取り組むことが重要です。
短期的な成果が見えにくい内部品質向上の取り組みは、他の業務に比べて優先度が低くなりがちなためです。
特に機能開発やバグ修正など、ユーザーに分かりやすく価値を提供しなければならないプレッシャーが強いと、内部品質向上の取り組みは後回しになり、一向に取り組まれないということはよくあります。
このプロジェクトでは、「毎スプリントの 2 割程度のコストを内部品質向上などの改善活動に充てる」という方針を採用しました。
これにより、以下のような効果がありました。
- 週次の改善タスクの実施により、各メンバーが様々な内部品質に関するトピックに対して意識を向けるようになった
- この結果、コードのリファクタリングやドキュメントの更新などが定期的に行われるようになり、コード全体の可読性と保守性の向上につながった
- 開発メンバーが背景に関するコードコメントを書くようになった
2-2. 仕組み化する
内部品質に関する改善は、ルールを決めたらできるだけ自動でチェックされるよう仕組み化することが重要です。
これらは決めの問題であることも多く、都度メンバー同士で議論していると、時間的コストや感情コストが過剰にかかってしまうことがあるためです。
プロジェクトでは、 PR での自動チェックに以下のような内容を設定しました。
| 項目 | 利用ツール |
|---|---|
| 静的解析の指摘が増えていない | SwiftLint、SwiftFormat、Android Lint、detekt |
| デッドコードが増えていない | Periphery、Qodana |
| Typo が増えていない | CSpell |
2-3. 文面で示す
内部品質改善に関する方針は、明文化しておくことが重要です。
明文化しておくことで、同じことを何度も説明する必要がなくなりますし、新規メンバーが入ってきた際にも、方針を理解しやすくなります。
例えば、以下のように明文化しました。
PR の修正行数はできるだけ少なくします。これにより、レビューの効率が向上し、問題が発見しやすくなるため、品質の維持が容易になります。
プロダクトコードとテストコードは同時に修正します。
PR には、修正した理由や背景を説明します。
2-4. 自ら行動して手本を示す
自らが実装する際に手本を見せたり、メンバーのコードレビュー時に指摘をすること繰り返すことで、メンバーに働きかけ続けることが重要です。
これにより、メンバーが目指すべき方向性を具体的にイメージしやすくなりますし、他のメンバーにも行動を促すことができるためです。
具体的には以下のような取り組みを率先して行いました。
- コード中で分かりにくい箇所を発見したら、リファクタリングのタスクを起票しておく
- 実装時に、仕様の背景に関するコメントを残す
- コードレビュー時に、分かりやすさや既存のコードとの整合性について指摘する
3. 正しい方向に向かっていることを観測する
前章までで、大局的な目線合わせや具体的な運用について記述しました。
一方で、これらの改善活動が実態として改善に繋がっているかを確認することも重要です。
そのため、定量的、定性的な評価を見え、定期的に観測するようにしました。
3-1. 定量的なデータの収集と共有
内部品質に関する定量的なデータは、定期的に収集してチーム内で共有することが重要です。
これにより、定量的な部分での改善の進捗について、チームメンバー全員で認識を合わせて、適切な軌道修正につながっていくためです。
プロジェクトでは、以下のようなデータを定期的に収集し、チーム内に共有しました。
- 静的解析の指摘数
- 単体テストのカバレッジ
- Typo 数
これにより、以下のような効果がありました。
- コード品質が順調に維持・向上しているかを確認できるようになった
- 開発メンバーがコード品質のメトリクス(単体テストのコードカバレッジ)を意識する場面が見られた
3-2. フィードバックサイクルの確保
定性的な意見によるフィードバックサイクルも確保しておくことが重要です。
定量的なデータだけでなく、チームメンバーの定性的な意見も含めて見ることで、偏った判断を避け、総合的な判断を下せる可能性が上がるためです。
プロジェクトでは、チームメンバーによる定性的な自己評価を定期的に実施していました。
定性的な自己評価では、複数人からコードの内部品質に関して特定のトピックを改善したいという意見が上がってきました。
振り返りなどで詳細をヒアリングし、スプリント計画に組み込んでいます。
振り返りでは、Mad Glad Sad のフレームワークを用いていました。
最後に
本記事では、コードの内部品質について、私が直近のプロジェクトで取り組んできたことをまとめました。
内部品質は目に見えにくく定量的な成果が出にくいものであるものの、中・長期的にビジネスの成長に大きく影響してきます。
そのため、今後も引き続き、内部品質に対する意識を高め、チーム全体で取り組んでいきたいと考えています。
Discussion