16
13

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

「バグ」を「UX向上作り込みタスク」という言い換えてみた

Last updated at Posted at 2015-06-10

チャット系システムをつくっていて、「"空白文字だけの投稿"などの"有意な文字"を含まない投稿を許可しない」というタスクが出た。
機能仕様には含まれないので「バグ」という分類になっていたがそれについて少し考えた
なおそのタスクは即座に消化された。スピード優先。

この手のタスクをバグと分類すると何がまずいのか(なおこれを仕様バグをして扱うことには異論はない)

・開発者が責められているように感じる。
・外聞が悪い(今週のバグ5件?品質悪いんじゃないの?)
・本来バグとして扱うべき物(クラッシュバグや、TL同士が混線する問題)がこれらの「軽微な問題」に埋もれてしまう
・この手の「バグ」が現れることは常態化しがちなので、バグがあっても当然という意識になりがち
・バグ=問題=瑕疵担保で無償対応、という意識からバグかバグでないかの議論に無駄なエネルギーが割かれがち(受託でよくある問題)

対応として

私としてはこれがバグだろうがバグじゃなかろうがどうでもいい。内製開発だし。
ただこれが許されるとTLの見た目が悪くなるのでUXが悪化する。UXを悪化させたくないので対応したい。

なのでUX向上作り込みタスクと呼称した。
対象は「存在したとしてもUXをクラッシュするレベルではないが、あると使いづらい、ダサい」レベルのバグ
そうすると
・ポジティブに聞こえる
・外聞が良い(ユーザーの方をちゃんと向いているように見える。)
・やばさのあるバグと区別可能
・問題じゃないように聞こえるし「UX向上の作り込みやります!」と言うとやるやらないでもめたりはしない(優先度では少し揉めるが)

ということで名前重要

16
13
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
16
13

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?