はじめに
こんにちは。
株式会社HataLuck and Person（以下、HATALUCK）でエンジニアリングマネージャーをしている荒木です。
開発チームが1チーム〜2チームくらいの小規模な状態でプロダクトが急成長してくると、「開発リクエストの渋滞」が起こりやすくなります。
- プロダクトロードマップの機能開発（事業戦略的に外せない）
- 顧客からの改善要望（今すぐやってほしい）
- 技術負債の解消やリファクタリング（手を打たないと後で辛い）
これらが同時に降ってきて「で、何から手をつければいいの？」という状況になりがちです。
本記事では、そんな混乱状態にあった私たちのチームが、「スコアリング」 と 「20%ルール」 を導入して改善に取り組んだ過程と、その後どうなったかを共有します。
よくある問題
まだ小さい組織でのあるあるですが、こんな感じでリクエストが飛んできます。
「この新機能、今Qで絶対リリースしたい！」（PdM）
「◯◯の画面、顧客からまたフィードバックもらいました」（CS）
「この技術的負債、放置すると来月やばいかも…」（開発）
そして…
- 毎週のようにタスクの優先度が変わる
- 誰のための開発か見えなくなる
- コンテキストスイッチで疲弊する
- 結果的に、誰も満足しないリリースになる
という悪循環に陥りやすいです。
優先度を「スコアリング」で見える化する
まず着手したのが、「改善要望の見える化」でした。
施策
- 元々あった改善要望リストをバックログとして整理
- MoSCoW法で「やる／やらない」を大まかに分類
- ICEスコア（Impact / Confidence / Ease）で数値化して優先順位付け
ICEスコアとは？
- Impact：影響度（インパクト）
- Confidence：その効果に対する自信度
- Ease：実装の容易さ
Ease に関してはエンジニアに協力してもらい、初回だけざっと入れてもらいました。以降は差分入力で済むので、運用負荷は最小限です。
↓実際に運用しているバックログ
並行して進めるための「20%ルール」
ただ、優先順位がわかっても問題は残ります。
プロダクトロードマップと改善要望って、そもそも比べられなくない？
その通りです。なので比較しないで済む仕組みを用意しました。
導入したのが「20%ルール」
- 週の20%（＝1日）を改善や技術課題に使う
- スプリントプランニングで以下の割合に分けて見積もり
| 領域 | 割合 | 対象タスク例 |
|---|---|---|
| ロードマップ開発 | 70% | 新機能、戦略開発 |
| 改善対応（20%枠） | 20% | 顧客要望、リファクタ、不急の不具合対応 |
| バッファ | 10% | Hotfix、突発対応 |
20%枠で扱うタスクは、スプリントを跨いでコツコツやるものとして設計しました。リリースまでに期限を設けないことで、スプリント開発のリズムも崩しません。
運用してみて、どうだった？
この仕組みを導入して2ヶ月ほどですが、早くも良い兆しが出てきています。
- 顧客要望が着実に反映されるようになった
- スプリント中のコンテキストスイッチが減少
- 開発メンバーの「これはやるべき価値がある」感が上がった
- リリースノートが厚みを増し、社内からの信頼も向上
特に、「改善にもちゃんと時間がある」 という安心感が、開発メンバーの自律性やモチベーション維持につながっています。
まとめ：小さいチームでも“うまく回す”ために
スタートアップは、どうしても「全方位開発」になりがちです。
でもだからこそ、「やらないことを決める」「比べずに分けて並行する」工夫が必要になります。
今回のように、
- 優先度を数値で判断できるようにし（ICEスコア）
- 改善と新機能の“棲み分け”をルール化する（20%ルール）
というシンプルな手法でも、チームの健全性とプロダクトの推進力を両立させることができます。
小さなチームで「全部やりきれない…」と感じている方の参考になれば幸いです。
おまけ：ツール・運用Tips
- ICEスコアの管理には Notion を使っています
- 20%ルール枠は、Linear のラベルで識別しやすく設定
- スプリントプランニング時に「20%枠の在庫」からタスクをピックアップするだけで運用が回ります
We are hiring!
HATALUCKでは、一緒に「はたLuckシリーズ」を開発してくれる仲間を募集しています。
ご興味のある方は下記リンクからぜひご連絡ください！
Discussion