ヌーラボのアジャイル・ライダー長沢です。本記事では「優先度」を適切に使って、みなさんのタスクの優先順位をスマートに決める方法をご紹介します。
前回の記事では、「優先度」と「優先順位」の違いを考察しました。「優先度」と「優先順位」は補完関係であるとご紹介しましたが、どのように補完するかは現場によっても異なるため、触れませんでした。そこで、今回は優先順位を優先度で“どのように”補完するかをお届けします。
目次
優先順位の根拠を考える
はじめに「優先順位」の根拠を考えていきましょう。前回述べたように「優先順位」は順番なので、何らかの根拠をもとに順序づけられます。この根拠によってその優先順位の妥当性を示させるわけです。
場合によっては、プロダクトオーナーのような責務者に判断を委ねることもあるでしょう。とはいえ、責務者も判断の根拠は持っているはずです。そこには「優先度」も含まれていることでしょう。
しかし、その判断根拠を明示することは、あまりないのではないでしょうか。
なぜならば、根拠は多角的であり、状況によっても変化します。いちいち根拠を示すゆとりがなかったり、それを明示するなら、より良い優先順位づけに注力したりした方が賢明だからです。
優先順位を考えるためのマトリックス
以上のように優先順位を決定する要素はベールに包まれていることが多いのですが、これらをマトリックス状にすることをおすすめします。
例えば以下の表は、一番左の列が要求の一覧で、右に並ぶ列が優先順位を決定する要素です。
要求 |
UX |
新規獲得 |
・・・ |
競合優位性 |
簡易的なユーザー登録ができる |
◯ |
◯ |
◯ |
|
チュートリアルによる簡単習得 |
◯ |
◯ |
||
OAuth認可によるログイン |
◯ |
◯ |
||
・・・ |
この「◯」の多さを根拠の目安として、優先順位を入れ替えていけば、それぞれの要素を踏まえた妥当な優先順位になるはずです。
しかし、ここでひとつの疑問が生じます。
「◯」が多ければ優先度が高いのか?早くやらないといけないのか?
という疑問です。
「◯」が多いというのは、注目すべき要求であることは間違いなさそうです。
しかし、それと優先順位を上げるべきはイコールではない気がします。また「◯」が多いと優先順位が上がるのであれば、ほとんどの要求に「◯」がつきそうですし、そうなったら優先順位は決められません。
この表に対して、「◯」ではなく「指標」を設けてみましょう。
要求 |
UX |
新規獲得 | ・・・ |
競合優位性 |
簡易的なユーザー登録ができる |
高 |
高 |
中 |
|
チュートリアルによる簡単習得 |
中 |
高 |
低 |
|
OAuth 認可によるログイン |
高 |
中 |
低 |
|
・・・ |
すると、「UX」や「新規獲得」などの各判断要素に重み付けがでてくるので、先ほどよりは妥当性が出てきたと感じます。
判断要素を各種の「優先度」とみなすと、優先順位の根拠を優先度が補完している構図ができあがります。
(※判断要素がすべて「優先度」である必要はなく「重要度」でも「ビジネス判断」でも良いです)
判断要素にも重み付けをしてみる
次に、表の例で示しているUXや新規獲得などの「判断要素」にも、以下のように数値で重み付けをしてみましょう。
- UX: 3pt
- 新規獲得: 5pt
- 競合優位性: 2pt
判断要素の「指標」についても数値で重み付けをしましょう。
- 高: 5pt
- 中: 3pt
- 低: 1pt
このように設定すると、以下のように同じ指標判断でも数値が異なる状況を作り出すことができます。
- UX の[高]: 3pt × 5pt = 15pt
- 新規獲得の[高]: 5pt × 5pt = 25pt
- 競合優位性の[高]: 2pt × 5pt = 10pt
これを表にすると以下になります。
要求 |
UX |
新規獲得 (5pt) |
・・・ | 競合優位性 (2pt) |
スコア |
簡易的なユーザー登録ができる |
高 |
高 (5pt) |
中 (3pt) |
46pt |
|
チュートリアルによる簡単習得 |
中 |
高 (5pt) |
低 (1pt) |
36pt |
|
OAuth 認可によるログイン |
高 |
中 (3pt) |
低 (1pt) |
32pt |
|
・・・ |
「スコア」の列は、数値を計算したものになります。明確な数値化によって優先順位の根拠を示せるようになりました。
大切なのはコンセンサス
さて、重み付けについて重要なポイントがあります。それは「コンセンサス」です。
意思決定の重み付けを数値化するにあたっては、関係者で合意の取れた妥当な数字であることが大切になります。したがって、数値がある特定の人にとっての利益に依存してしまうと、その数字の妥当性が乏しくなってしまいます。
ありがちなのは、顧客優位になりすぎてしまったり、プロダクトオーナーの意思が不自然に強くなってしまったりすることです。開発チームの意思判断も盛り込めるような数値による重み付けができるのが良いですね。
コンセンサスを取りやすくするためには、特定の要素だけが過剰に高い数値にならないようにすることも大切です(逆にコンセンサスが取れていさえすれば特定の要素を高い数値にしても良いです)。
合計数字を決めておく
そのために、合計数字を決めておくと良いでしょう。例えば、30ptを各要素に割り振る(全要素の重み付け数値を足すと30ptになるようにする)などです。
すると、各関係者の思いや政治的な思惑なども含めて割り振っていけるので、ある程度の納得感のある割り振りができるはずです。
(※余談ですが、割り振ることが目的でありますが、その関係者での会議は各関係者の価値判断や事情を説明する「場」になるはずなので、そういった機会をあえて設けてみるのもおすすめです)
数値を意識しないで設定する
重み付け(=数値化によりバランスをとる)ができるようになったときに気をつけておきたいことがあります。人は数字がみえてしまうと瞬時に計算がしたくなる生き物です。よって意思決定をするときは数字は伏せておくと良いでしょう。
私は、Excelなどの表計算ツールを使ってやっていました。こういうのは表計算ツール本来の能力として活用したいものです。
以下の2つの表をそれぞれ別シートで準備します。
- 優先度などの要素とその重み付けポイントの表
- 設定指標([高]など)の重み付けのポイント表
表が準備できたら、「スコア」に該当する部分に計算式に基づいた点数が表示されるようにします。最後に、スコアの高い順にソートをするとそのときの優先順位がわかります。
改めて大切なこと
もう一度伝えますが、大切なのは関係者でコンセンサスがとれていることです。
声の大きい人や予算を握っている人だけが権限をもっているよりも、関係者全員が関与していることがわかるようにすると納得感が生まれますし、心理的な安全も保てます。
そしてもうひとつ大切なことは、現時点で取りうる数値化(≒ 客観性)を示すことです。
さらに、もっと大切なことは「現時点でのやり方であり、定期的に見直す価値が十分にあることを、チーム全体で認識していること」です。
ひとつの形ができると、それが絶対的なものに思えてきますがそうとは限りません。
例えば、今回のやり方が一時的にうまくいったとしても、その当時に設定した重み付けに対する価値基準が時とともに変わってくる可能性があります。定期的に重み付けの見直しをすることなども忘れないでおきましょう。
▼仕事の優先順位づけに関連する記事はこちら
こちらもオススメ:
プロジェクト管理とは?目的や項目、管理手法について徹底解説! | Backlogブログ
プロジェクト管理の基本や主な項目を紹介。CCPMやWBSなどのプロジェクト管理の代表的な手法やプロジェクト管理全体の流れを解説。これからプロ…
backlog.com