タスクに「〜対応」という名前をつけるのを避けたい理由

先日同僚と雑談的に話してたことを書いておく。ソフトウェア開発のバックログにおける話です。

「〜対応」とは

主に差し込みで入ったタスクやなにか早めに単一の解決したい事象のためのタスクに名付けられやすい名前。

あくまでも例としてだが

  • 「マーケから割引データ表示依頼対応」
  • 「監視アラート対応」

みたいなやつ。「〜対応」というのは日本語としてはかなり便利なので、とりあえずバックログに入れておきたいときに使いがち。

なぜ避けたいか

完了基準があいまいになる

タスクを流していく際の問題。

バックログ上のタスクは完了基準を定めておかないと、作業スコープがどんどん広がったり、完了したかどうかを確認する人から見ると完了していないということが作業後にわかったりして不便。「〜対応」という名前をつけるタスクは、そもそもの作業スコープがはっきりしていないことが多く、結果として、作業を始める前に関係者との認識合わせが再度必要になって思ったより時間がかかったり、本来やらなくてよかったところまでやってしまったりするかもしれない。

なにをやっているのかわからない名前になりやすい

作業の透明度についての問題。

「〜対応」というタスクを入れた人がそのままタスクを進める場合に起きがちなケース。やっている人にはある程度道筋が見えているので、作業の進行自体には問題ないことも多い。一方で、他の人からだと話を聞かないとなにをやっているのか見えづらいことがある。実は作業スコープが本来必要なものより大きいこともありえるが、他の人がそれに気づくきっかけが少なくなることがある。

とにかくこなさないとまずいことが起きそうに見える

バックログ上での優先度を決めるときの問題。

「〜対応」ってなんか急ぎっぽいじゃないですか。でも実際はステークホルダーとしては「〜対応」の一部だけ特定の期限までにやってくれればよかったりすることもある。また、「〜対応」のなかにユーザー価値に直結することと技術的タスクが混じっていて、まずはそこの優先順位をつけるべきこともある。

どうするか

いくつか挙げてみる。他にいい方法があったら教えてください。

完了したと明確に言えるタスク名にする

もう少し掘り下げて「〜する」、「〜できる」という方式で名前を考えてみる。最初に挙げた例だと

  • 「マーケから割引データ表示依頼対応」は「〜のページから割引ページが見えるようになる」
    • マーケチームからの依頼という情報はタグなどで表現する
  • 「監視アラート対応」は「〜エラーのアラートが毎朝鳴らないようにする」

みたいに変えると、名前から完了基準が明確になる。加えて、タスクの説明として完了基準を詳しく書いておくとよい。

実は複合的なタスクではないかと疑って分解する

「〜対応」というタスクは実は複合的な作業を表しているということが多い。この場合は、あらためてチームでタスク分解から考えるのがよい。たとえば「監視アラート対応」が

  • 「〜系のエラーは無視して問題ないのでSentryに送らない」
  • 「〜エラーのアラートが毎朝鳴らないようにリトライ機構を入れる」

のように分解できるかもしれない。こういう分解はできればバックログに入れる早い段階でなされるとよい。また、タスクを分解しておくとフロー効率の面でもよい効果があるだろう。

参考