プロダクトの開発ポリシー検討に「緊急度と重要性のマトリクス」を使ってみた
この記事は約1400文字。3分くらいで読み終わります。
私たちのチームは社内ツール開発を行っており、様々なところから要望が届きます。「これは確かにやった方が便利になるね」というものから「今これ必要なのかな？」と思うものまで多種多様に。
そうすると自然と「何のためにそれを開発するのか？」という話が出てきます。
「私はこう思う。」「いやそれは違うんじゃないか？」「要望の意図は何なのか？」いろんな切り口や意見が飛び交いますが、明確な開発のポリシーを特に決めていなかったため「結局どうする？」となり決められなかったので、「じゃあ開発のポリシーを話し合おう！」ということになりました。
しかし「開発のポリシー」を話し合おうにも、さっきのように議論が四方八方に飛び交ってしまうと結局「開発のポリシー」が決められない（もしくは決めるのに時間がかかってしまう）かもしれないと思ったので、進め方を考えていたところ「緊急度と重要性のマトリクス」を使うと「開発のポリシー」が自然と出てくるのでは！？とロマサガ2的な閃きがあったので、早速やってみました。
緊急度と重要度のマトリクスとは
緊急度と重要度のマトリクスの詳細については、こちらをご覧ください。
4象限に置く「理由」にフォーカスする
緊急度と重要度のマトリクス
このマトリクスは本来
重要かつ緊急
緊急ではないが重要
重要ではないが緊急
重要でも緊急でもない
の4象限に分けてタスクをそれぞれの枠に置いていくことで、タスクの優先度や実施しないものを振り分けるために使うのですが、今回は「開発のポリシー」を決めるので、そのタスクをなぜその象限に置いたのかの「理由」にフォーカスし、深掘りしていく中でポリシーを定義していく、ということ行いました。
4象限に置いていくのは、いただいている機能要望です。
チームメンバーそれぞれが1人2つの要望を選び、自由に各象限に置いてもらいました。
「緊急」と「重要」の定義
4象限に置いてみて、結局開発しているプロダクトにおける「緊急」と「重要」が何なのか？が決まらないとポリシーがブレそうだよね、ということになり、それぞれ定義しました。
緊急
サービスインしているものに不具合・障害がある
ユーザーに不利益がある
スケジュールが決まっている
重要
ユーザーにメリットがある
会社としてメリットがある
（社内で）ちゃんと使ってもらえる
面白かったのは定義が明確になると、各自が置いた付箋たちに動きが出たことです。この定義なら「緊急ではないが重要」かな？「重要かつ緊急」なんじゃないか？当初の目論見通り議論は活発化し、1時間で「開発のポリシー」を決めることができました。
完成した「開発のポリシー」
完成したら終わりじゃない
「開発のポリシー」は一度決めたら終わりではなく、状況の変化に応じて変わっていくものだと思っています。なので決めたことがそぐわなくなってきたり、追加することが出てきたらまたディスカッションしよう！とチームメンバーと認識合わせもできました。
毎週一度、新規に追加されたタスクのストーリーポイント決め、バックログの棚卸しを行なっているのですが、早速今回作った「開発のポリシー」と照らし合わせて、ロードマップの優先度変更を行うことができました。
いやー、作ってよかったです！😄
もし「開発のポリシー」作りに悩まれている方がいらっしゃいましたら、参考になれば幸いです。