タスクは何から決まるのか
目標を決めても、そこから直接タスクが出てくるわけではない。「読み込みを速くすれば離脱が減る」という因果の想定を経由して、はじめてやることが決まる。この想定が仮説であり、仮説が確からしくなければタスクも妥当ではない。
バグ修正やライブラリの更新は、目標を持ち出さなくても着手の理由が立つ。ただし、直すべきものが同時に複数あれば、どれを先にやるかを選ぶ理由はいる。
仮説を明示していなければ、そのタスクを選んだ理由を言葉にできない。手は動かせる。優先度を比べる根拠がない。それでも順番は決まる。決めるのは、声の大きい人の意見や締め切りの近さだ。
「UX向上」と書かれたタスク
明示すればよいわけではない。書き方によっては、明示していないのと変わらない。
説明欄に「UXが向上する」とだけ書かれたタスクを考える。仮説の形はしているが、何が起きたら外れと言えるのかが書かれていない。
リリース後にどの数字を見ても、向上したと言える。同じ数字で、足りないとも言える。外れの形を決められない仮説は、検証の対象にならない。
「検索結果の初期表示が2秒を切れば、その画面からの離脱が減る」と書いてあれば判定できる。2秒を切ったのに離脱が変わらなければ、その仮説は外れである。
この違いは優先度をつけるときにも表れる。外れの形が書かれていれば、2つのタスクを想定の確からしさで比べられる。書かれていなければ、どちらも「良くなるはず」としか言っていない。明示したと言えるのは、外れの形まで書いたときだ。