はじめに
こんにちは、LINE上で動くおくすり連絡帳 Pocket Musubiというサービスを開発している種岡です。この記事では、サービスをローンチしてから現在に至るまで、エンジニアの中で技術的負債とどう向き合って来たかをご紹介します。
概要
「日本の医療体験を、しなやかに。」のミッションのもと、Pocket Musubiローンチに向けて日々開発していました。開発過渡期を迎え、徐々に技術的負債が発生し始めましたが、その場ですべてを解消することはせず、一旦ローンチ後に取り扱いを検討することにしました。
そして無事ローンチを終え、棚上げしていた技術的負債に着手。取り組んだ全体感が下図の通りです。
エンジニアメンバーの参画してきたタイミングや経験値も様々だったこともあり、まずはエンジニアチームとしての負債解消の目線合わせからスタート。複数回ミーティングを行い、共通認識を作り上げ、運用・改善を繰り返すことで負債解消の習慣を作ることができました。
以下、フェーズごとに行ったアクションを列挙してみます。
負債解消キックオフと目線合わせ
キックオフで現状確認
- 負債管理はTrelloに専用ボードを作成し、各エンジニア判断で追加されている状態
- 負債の検知と防止のためにローンチ前に組み込んでいたもの
- GitHub ActionsでLintとテスト実行
- SonarCloudによる静的コード解析とカバレッジの経時変化の確認
- Renovateによるパッケージ更新の半自動化
- SENTRYを使ってエラー検知
技術的負債を「なぜやるべきなのか？」や「難しかったこと」を体験ベースで共有
- エンジニアではないメンバーを含めチームのマインド的に「新規開発 ＞ 負債の解消」となり、負債解消に前向きに取り組めない
- 負債が負債を呼んでいる状態が発生していて、誰もやりたがらない(手の付け方が分からない・怖い・モチベーション上がらない)
- 負債が溜まりすぎて、リファクタリングプロジェクトが始動するも空回り
負債解消を行わないと中長期的に開発環境の健康状態が悪化し、場合によっては新規開発を止めざるを得ない状態に陥る恐れがあります。この技術的負債の解消に取り組む意義をエンジニアチームの共通認識として醸成し、開発スケジュールの中に負債解消を組み込む行動を取ることとしました。
解消方法についての検討
- 負債と不具合を切り分ける(何でも負債計上しない)
- 負債棚卸しを行い、優先度のラベリングを行っておく(負債解消に直ぐ着手できる準備をしておく)
- リファクタリングは一気に対応するのではなく、分割して(例えばコンポーネント毎に切り分け)て解消していく
- テストを書いていないビジネスロジックは、急造する必要はないが、関連する解決案件が出てきた時に一緒に対応する
- 負債解消作業自体を属人化せずにエンジニアチームで取り組めるようプランニングする
- エンジニアではないメンバーの理解がないと成り立たないので、負債解消に対する啓蒙の仕方を考える
これらの基準が固まってきた段階で、既に積まれている負債を整理を行い、いつでも負債解消に着手できる準備を整えました。
運用開始とふりかえり・改善
当社ではスクラムという開発手法を導入しています。1スプリントは2週間です。
まずはスプリントプランニングでエンジニアが解消したい負債を宣言し、スプリント内の時間で各自対応するところから始めました。また、隔週で棚卸し・ふりかえりミーティング(30分)を開催し定期的な棚卸しも試みました。こうして負債解消のPDCAを回してでてきた課題と改善策の一部をご紹介します。
棚卸しミーティングを拡張
ローンチ直後ということもあり、負債が計上され易い状態でした。毎週新たな負債が積み上がり、隔週30分では足りず毎週行うことになりました。
負債のラベリングを「優先度」から「重要度」に変更
優先度にするとやらなくてはいけない圧が無意識にかかり、他の開発作業に集中できなくなっていることがわかりました。表記を変えるだけで、精神的に楽になり、負債と向き合いやすくなったという効果がありました。
負債解消DAYの実施
スプリント中に並行して負債解消していくのはつらいことが分かりました。理由としては、「新規開発」タスクを優先してしまうマインドがあること、また、空き時間で負債タスクに着手したが、コンテキストスイッチが発生して集中できないことが挙げられました。
この課題に対しては、負債解消専用の日を作り、スプリントプランニング時にエンジニアではないメンバーに作業宣言する(合意を得る)ことで対策としました。
負債の管理をTrelloからGitHubのプロジェクトボードへ変更と進捗状況の可視化
Trelloでカードとして負債を管理していましたが - 負債カードとGitHubのコードを紐付けられない(後で見返す時に不便) - エンジニアではないメンバーから負債進捗状況を共有して欲しい という課題と要望を解決するためにGitHubのプロジェクトボードの管理に移行し、GitHub APIを活用して進捗確認をRedashで可視化することにしました。
GitHub APIを利用したRedash連携システムの概要
RDSにデータを登録するLambdaとGitHub APIを叩くLambdaを2つ利用し、毎日バッチ実行するシステムを構築しました。
進捗状況を可視化
RedashにサービスのKPIや開発進捗を毎日確認可能なダッシュボードがあります。そこに負債進捗状況のグラフを追加し、スプリントプランニングで進捗を追えるようになりました。
最後に
チームではサービスローンチ後に技術的負債について共通認識を持ち、開発スケジュールの中に負債解消を組み込む運用を行うことができました。また、棚卸しとふりかえり、改善を繰り返すことで習慣として根付かせることができました。これらの行動を繰り返すことで、負債解消が属人化することなく、エンジニアメンバー全員で向き合う姿勢ができたと思います。
さらに、一連のプロセスは細かい会話を重ね合うことで行われました。会話ベースで取り組むという型が自然と形成され、開発体験の向上にも繋がるという副次効果が得られたのも良かったです。
