要望管理が3か月で止まるのはなぜか
目次
たとえば、導入から3か月たって機能要望の一覧を開いたら、最後の更新が2か月前だったとします。この記事の「3か月」は運用が止まる時期の統計ではなく、状況を考えるための例です。
受け皿は決めました。ツールも入れました。最初は現場の担当者が要望を入れていました。それなのに、いつのまにか誰も一覧を触らなくなっています。
この記事では、要望管理の運用がどこから崩れるのか、どう立て直すのかを整理します。始め方は機能要望の収集を一本化する方法で扱っています。
- 集めた要望を読む人と、判断する人が決まっているか確認する
- 入力が減ったときは、その前に判断や返答が止まっていないかを調べる
- 運用を立て直すときは、溜まった要望を片付けてから始めない
集め方だけでなく、集めたあとの扱いを確かめる
運用が続かないと、担当者はたいてい入口を疑います。入力項目が多すぎたのではないか、Slackから投稿できるようにすべきではないか、といった具合です。
ただ、要望を受け取ったあとの扱いに問題があるなら、入力を軽くするだけでは解決しません。項目を3つに減らしても、入れた要望が定例で読まれず、やるかどうかの返事も来なければ、現場は要望を入れなくなります。
2020年版のスクラムガイドでは、プロダクトバックログは製品改善に必要な作業を順序付けた一覧であり、その項目を具体化するリファインメントは継続的な活動とされています。顧客の要望を集めただけの一覧とは異なり、要望はバックログを検討する材料の1つです。要望管理でも、収集後に内容を確認し、判断につなげる作業を続ける必要があります。
要望のリストは、作った時点で完成する台帳ではなく、手を入れ続ける前提の道具です。 この前提が共有されないまま導入すると、要望管理は一度きりの構築作業として扱われます。
一覧を見るだけの場になると、要望を入れる人がいなくなる
入力の減少に先立って、判断や返答が止まっている場合があります。次の図は、そのような運用の崩れ方の一例です。
月1回の定例で、担当者が一覧を映します。参加者全員でそれを眺めます。「こんな要望が来ていますね」と確認して、次の議題へ移ります。こうした確認だけが続くと、現場が要望を入れる意義を感じにくくなります。
スクラムガイドも、検査を適応につなげることを重視しています。要望を読む場でも、採否をすぐに決められない場合は、追加調査の担当や次に確認する日を決めるところまで進めます。
顧客が要望を言わなくなるのも同じ構造でした（顧客から要望が来ないのは、満足しているからとは限らない）。要望を伝えても返事が来ない経験が続けば、社内の担当者も入力をやめます。
入力の減少は、判断や返答が止まった結果かもしれません。たとえば直近3回の定例を振り返り、何が決まり、何が保留されたかを確認します。
決める人がいないと、要望が溜まるだけになる
では、なぜ一覧を見る場で何も決まらないのでしょうか。多くは、決める人が定まっていないことに行き着きます。
要望は営業、サポート、経営、開発と部署をまたいで届きます。それぞれの部署に言い分があるので、「関係者で相談して決めましょう」という形になりがちです。ところがこの形は、決まらなかったときに誰の責任にもならないという性質を持っています。
スクラムでは、何を先に作るかの順番を決める責任者を「プロダクトオーナー」と呼び、1人に定めています。スクラムガイドは "The Product Owner is one person, not a committee."（プロダクトオーナーは1人であり、委員会ではない） と明記しています。プロダクトオーナーが独断で決めてよいという意味ではなく、多くの関係者の要望を代表してよいことも同じ文書に書かれています。
要望管理でも、誰が判断をまとめるかを明確にし、保留を含めて結果を記録する運用が考えられます。責任者を置くだけで記録が残るわけではないため、判断理由と次に見直す条件も一緒に残します。判断の経緯が消える問題は要望管理をNotion・スプレッドシートで行う限界でも扱っています。
止まった運用は、責任者が1件決めるところから立て直す
運用を再開するとき、担当者が最初にやりたくなるのは溜まった要望の棚卸しです。たとえば200件の要望を頭から読み直し、分類と優先順位を付け直そうとすると、再開までに時間がかかります。
順番を変えます。
溜まったぶんは、いったん置く
全件を片付けてから再開しようとすると、再開そのものが先送りになります。ただし、障害や安全・セキュリティ上の問題、顧客と期限を約束したものは先に確認します。立ち上げのときに過去を遡らないのと同じ考え方です。
直近1か月ぶんだけを見る
まず直近に届いた要望から始めます。たとえば30分の枠を取り、その時間で内容を確認できる件数に絞ります。
1件だけ決める
責任者が、やる・やらない・保留のいずれかを決めます。多く決める必要はありません。決まった状態を1つ作ることが目的です。
決めたことを、入れた人に返す
その要望を登録した担当者へ、判断の結果を伝えます。実装しないと決めた場合でも伝えます。
判断の結果を伝えるところまでを運用に含めます。 登録した要望がどう扱われたか分かれば、担当者は入力する意義を確かめられます。立て直しは要望を整理する作業ではなく、入れた人に手応えを戻す作業です。
よくある質問
定例の頻度を上げれば運用は続きますか？
頻度だけでは続きません。月1回の定例で何も決まっていないなら、週1回にしても決まらない回数が増えるだけです。先に変えるのは回数ではなく、その場で責任者が1件でも判断し、結果を入れた人に戻す運用のほうです。
ツールを変えれば運用は続きますか？
道具が合っていないことが原因なら効果があります。ただ、現場が入力でき、関係者が閲覧もできているのに判断が出ていないなら、ツールを変えても同じところで止まります。道具ではなく、判断の置き場所の問題です。
要望がまだ少ないうちから、仕組みは必要ですか？
件数が少ない時期は、仕組みより習慣が先です。月に数件でも、元の言葉と判断結果は短く記録しておきます。ただ、届いた要望に返事をする習慣だけは最初から持っておくと、件数が増えて仕組みを入れるときの定着が速くなります。
まとめ
入力が減っているときは、その前に判断や返答が止まっていないか確認します。一覧を見る場があっても何も決まらなければ、現場が要望を入れる意味はなくなります。
運用を立て直すときは、溜まったリストを片付けるところから始めないでください。直近1か月ぶんを見て、責任者が1件だけ決めて、入れた人に返します。集めた要望を優先順位に落とす進め方は機能要望管理とは？収集・整理・優先順位付けの基本にまとめています。
