私は、数学を学ぶに当たっては、常識を忘れてはならないと信じている。何年も前に、私は初等代数学を教えたことがあった。ある試験で、私は、母親と父親と子供の年齢を算出するという基礎的な問題を出題した。学生が問題を読み終えた後、「この問題に関して、一つだけヒントをあげよう」と言ったところ、全員が私に注目した。私は続けて言った。「もし子供が母親か父親よりも年上になったら、必ずどこかが間違っているはずだ」（レイモンド・スマリヤン）
人が不具合と思うもの
不具合、と聞いて何を思い浮かべるでしょうか？
- この操作をすれば当然こうなると思ったのに、違う動作になる。
- 何かすればすぐに怒られる。（アラートが出る）
- 言われた通りにしても、その通りにならない。
仕様通りには動いているが、思い通りに動かない。ユーザーは仕様なんて知らないので、全てが不具合に見えます。
これがいわゆる「バグじゃないです、仕様です」という奴ですね。
ユーザーにとっては思い通りに動かないことが不具合なのです。
仕様を設計する観点として「常識」を加える
仕様を設計する観点には「常識」を加えるべきです。
「常識」とは何かと言うと、大きな順に、
- 大多数のものが採用している振る舞い。例えば下線付きのテキストをクリックすれば画面遷移する、など。
- 利用されるデバイス特有の振る舞い。例えば左右にフリックすれば次のデータが見れられる、など。
- その製品の中でのルール。
といったことが考えられます。
最後の「その製品の中でのルール」は、製品の中で統一されている、操作に対する振る舞いです。この製品では特に保存ボタンを押さなくても、自動的に保存される、といったポリシーのようなものでもあります。
このような製品で「保存ボタンを押さないと保存されない」箇所があるといったことがあると、確かに保存ボタンを押さないと保存されないのは仕様通りだけれども、ユーザーから見ると不具合と思われることがあります。
不自然な仕様は、当事者でも忘れることがある
「どうしてこんな仕様なんだっけ？」という経験、ありますでしょうか。
大体が不自然な仕様を作ってしまったために、起こることです。そのときは良かれと思ったことが、後からは余計なお世話になってしまうことが、多々あります。
その場しのぎで作った仕様が、不具合ではないのに不具合のような事態を引き起こすことがある。不具合を抑える開発は実装からではなく、仕様を考えるところから始まります。
実装の不具合はすぐに直せますが、仕様の不具合は、なかなか直せないものなのです。
