本記事はREADYFOR Advent Calendar 2025 10日目の記事です。
はじめに
こんにちは。READYFORでプロダクトチームのリードを務めている斉藤です。
私たちのチームはPdM2名、エンジニア4名の6名体制で、2週間スプリントのスクラムで開発を行っています。
現在の体制で開発を始めてから1年以上が経過し、スクラムにより開発のサイクルがうまく回るようになってきました。
一方、技術的負債の解消や機能改善、UI改善など、改善系タスクに関してはなかなか手が回らず、課題を感じていました。
本記事では、私たちのチームがこの課題にどのように取り組んできたかを紹介します。
棚卸し
まず取り組んだのは棚卸しです。
元々3ヶ月に一度実施していましたが、あまり時間を割けず、直近で開発する予定のIssueを整理する程度になっており、古いIssueはずっと放置されたままでした。
一旦全部整理しようということになり、古いIssueも含めて全て見直すことにしました。
本来であればチーム全員で実施したかったのですが、この時点で約160件のタスクが溜まっており現実的ではないと判断し、以下の２つに分類し、それぞれ分担して進めることにしました。
- PdM起票のIssue： PdMと私で実施
- 新規開発のスコープから外れたもの
- 社内外からのフィードバックや改善要望があったもの
- 軽微な不具合の修正やUI改善など
- エンジニア起票のIssue： エンジニアメンバーと私で実施
- コードのリファクタリングや技術的負債の解消など
それぞれ毎週30分ずつ実施し、完了するまでに約5ヶ月かかりました。
あまりに大変だったので棚卸しを終えて満足してしまいそうになりましたが、 ここで辛い思いをしたのが現状を改善したい強いモチベーションになりました。
Issueの内容を理解するのに時間がかかる
特に古いIssueの見直しは想像以上に大変でした。
数年前に作成したIssueのことなんて覚えているわけもなく、内容を把握するのにとても時間がかかりました。
今も対応が必要かの確認に時間がかかる
数年も経てば状況は大きく変わっています。
起票当時の課題がまだ残っているのか、すでに解決しているのか、現状を確認してから判断する必要があり、これも時間がかかりました。
やるやらないの判断に時間がかかる
起票したからには、解決すべき課題があるはずです。
それをやらない決断をするのは非常に難しいと感じました。
「今までやらなくても困らなかったし、いつ着手できるかもわからないから一旦閉じよう」、「いや、でもやっぱりやった方が良い」などと行ったり来たりして、判断するのに時間がかかってしまいました。
結局大半のIssueは残すことになったのですが。
現状分析
なぜこんなにIssueが溜まってしまうのか？
Issueをクローズするには、2つの方法しかありません。
- 開発してクローズする
- 開発しないでクローズする
改めて考えてみると、今まではこのどちらもあまり実施されていませんでした。
開発してクローズする
新規開発と改善タスクを同じ土俵に載せて優先度づけしてしまうと、改善タスクの順番が回ってくることはほとんどありません。
それぞれ分けて管理し、開発の計画に組み込む仕組みが必要です。
開発しないでクローズする
上述の通り、やらない判断をすることは簡単ではありません。
期限を決めずに積んでおくと、いつまで経ってもなくなることはありません。
やらない判断をしてクローズするには、明確な基準を設ける必要があります。
どうすれば取り組めるようになるのか？
優先度を決めるのは原則PdMですが、技術的負債の解消などの優先度をPdMが判断することは難しいでしょう。
そのため、PdMが優先度を判断できるもの、エンジニアが判断できるものを分けて管理することにしました。
棚卸しの際に分担したものと同じです。
- PdMが優先度を判断できるもの
- 新規開発のスコープから外れたもの
- 社内外からのフィードバックや改善要望があったもの
- 軽微な不具合の修正やUI改善など
- エンジニアが判断できるもの
- コードのリファクタリングや技術的負債の解消など
仕組み作り
開発してクローズする仕組み
「一人1改善Issue」ルール
新規開発とは別に、必ず毎スプリントの計画に入れる方針にしました。チーム内で合意したのは「毎スプリントで一人1改善Issueを進める」というルールです。
まずは少しずつでも確実に消化していく流れを作ること目標に、 優先度の高いものの中から基本的には最も小さいストーリーポイントのタスクから着手しています。
以前にも開発の20%を改善タスクに充てる試みなどをしたことがありましたが、基準が曖昧で次第にやらなくなってしまいました。
なので今回は、「一人1つ」という小さな目標を設定し、継続を重視しました。
安定してきたら、「一人1改善Issue」に加えて、技術的負債の解消も組み込むことを検討しています。
AIコーディングツールの活用
弊社では、Claude CodeやGitHub CopilotなどのAIコーディングツールを積極的に活用しています。
詳しくはこちらの記事をご覧下さい。
社内に知見が溜まってきたこともあり、 ちょっとした改善タスクならIssueなどにしっかり要件を記載しておけば大抵はほぼコードを書くことなく実装が出来ており、新規開発と並行して進められています。
開発しないでクローズする仕組み
自動クローズの導入
1年以上更新のないIssueは自動でクローズする 仕組みにしました。
GitHub Actions の actions/stale を利用しています。
- 毎週1回実行
- 1年以上更新がないIssueにstaleラベルを付与
- さらに1週間経っても更新がなければ自動クローズ
今まではなかなかやらない判断が出来ていませんでしたが、「1年以上手をつけなくても困らなかったなら、やらなくても大丈夫。必要になったらその時にまたオープンにすれば良い」と割り切ることにしました。
最初は「本当にクローズして大丈夫？」と不安もありましたが、 実際に導入してみると特に困ることはありませんでした。
これまでの成果
この取り組みを始めて数ヶ月、着実に成果が出ています。
定量的な成果
- Issue数が100件以下に減少（まだ多いですが）
- 毎スプリントで一人1つ以上の改善タスクを消化
定性的な成果
- チーム全体で改善に取り組む文化の醸成
- バックログ管理に対する心理的負担の軽減
最後に
ようやく改善系タスクの取り組みに対する課題解決の第一歩を踏み出せたと感じています。
この記事が、同じ悩みを抱えるチームの一歩を踏み出すきっかけになれば幸いです。
明日は READYFOR Advent Calendar 2025 11日目、kecy さんの担当です。
お楽しみに！
「みんなの想いを集め、社会を良くするお金の流れをつくる」READYFORのエンジニアブログです。技術情報を中心に様々なテーマで発信していきます。 ( Zenn: zenn.dev/p/readyfor_blog / Hatena: tech.readyfor.jp/ )
Discussion