ソフトウェアの仕様、挙動、バグ、利用者の期待

仕様

• 「このように動く」と定義したもの

挙動

• 実際にこのように動く、という実態

バグ

• 「仕様」と「挙動」の不一致のこと

利用者の期待

• 「こう動いてほしい」という期待
• 「こう動くだろう」という想定

現実に起こること

• 仕様 ＝ 挙動 ＝ 期待
  • みんなハッピー

• (仕様 ＝ 期待) ≠ 挙動
  • バグ
  • * 「期待と違います」とフィードバックすることでバグが修正されることを願おう

• (仕様 ＝ 挙動) ≠ 期待
  • 仕様通りの挙動を持っているが、残念ながら期待とズレてしまっている
  • このときに利用者が「バグですか？」「バグだと思います」とフィードバックすると「バグではありません」と返ってくるかもしれない
    • なぜならバグではないので
  • 「ユーザビリティが低い」と言える状況かもしれない
  • 仕様を決める時点でミスっていて「仕様バグ」と言える状況かもしれない
  • * 「期待と違います」とフィードバックすることで「仕様と挙動」が変更されることを願おう

• (挙動 ＝ 期待) ≠ 仕様
  • バグ
  • バグではあるが、利用者の期待通りの挙動が満たされているので、誰も気付かなければハッピーではある
  • 仕様通りにつくると期待を満たさなくなるので「仕様バグ」っぽい

• 図解：「ソフトウェアの仕様、挙動、バグ、利用者の期待」 - Speaker Deck
  • 2021-08-07にtanakenさんが図解してくれた！

テクニック

• 利用者が「仕様ですか？」「バグですか？」と言うのは筋が悪い
  • 「仕様ですか？」という問い
• 利用者は「自分の期待が満たされているか、いないか」という観点でフィードバックするとコストが最小になる

• 提供者が利用者に対して「仕様です」「バグではありません」と言うのは筋が悪い
• 提供者は利用者の期待に合わせて仕様も挙動も柔軟に変更できるとよい
  • 柔軟に変更できない場合、頑なに「仕様を守っていますので」と言っても利用者からしたら知らん話
  • 仕様通りに作られた「バグはないが使いものにならない」ソフトウェアに高い価値はない

• 発注者と受注者の間で「バグか、バグではないか」を見極めたい状況は理解できる
  • 利用者との間でそれをやっても、利用者の問題解決にならない