某社のアンケートに答えている最中、何気に [TAB][Space] と、キーインした。すると・・・今まで 15分ほどかけて入力した回答がすべて消えた(・O・;

最後に［クリア］（<input type="reset">）と［送信］（<input type="submit">）があって、［クリア］の方を押してしまったわけですね。

よく確かめずにキーインした自分もアレですが、この［クリア］ボタン、本当に必要なのでしょうか？

ここまで、15分ほどかけて入力しています。それを、なんの前触れもなく“なかったことにしてしまう”ボタン。これ、どんな利用を想定しているのでしょう？

アンケートに答えるのを止めるなら、ブラウザを閉じてしまえばいいのです。特定のテキスト ボックスだけをクリアするボタンなら、あるいはあってもいいかもしれませんが、[Ctrl]+[A] で全選択して、[Del] などで消せるので、あまり必要ではないでしょう。

このように、利用する場面が不明な（「すべての入力をクリアするためにボタンを押す」ではなく、どんなときに「すべての入力をクリアする」ことが必要かが不明な）コントロールを付加すると、利用者にマイナスの効果を与え、自社にもマイナスの結果をもたらします。ええ、また 15分かけて入力するのが面倒なので、アンケートに答えるのを止めちゃいました。

また、アプリケーションの生産性の面でもマイナスです。そのコントロールをテストしなければなりません。テスト項目を作り、項目が妥当か検証し、実施します。コントロールひとつに対するそれらの時間は、微々たるものかもしれません。しかし、塵も積もれば山となるのです。

このとき、ウォーターフォール型であれば、仕様を作り、コードを書き、テスト項目を作ります。しかし、ここの流れを仕様作成→テスト項目作成→コード作成と変更してみると．．．まず、仕様の妥当性を検討できます。そして、テストするという観点から仕様を眺めることで、仕様の抜けを発見できます。

さらに。コードを書いてからテスト項目を作成すると、作成したコードの妥当性を検証するテスト項目となりがちですが、仕様に沿ったコードであるか検証するテスト項目を作成することが出来ます。

こうして、実際に使ってみるテストから仕様を見直すことで、使い勝手の悪そうな仕様を検出することが出来ます。

コミュニティにおける質問で、よく「仕様なので、このように作らなければならないのです」という言葉を見かけます。

仕様だから、その通りに作らなければならない。だったら、その仕様を変えてしまえばいいのではないでしょうか。十分な理由を示せば、それも不可能ではないでしょう。

問題は、あなたが、どれくらい熱心にそれを勧められるか、にかかっています。その為には、十分な知識が必要です。「仕様だから変更できない」と思ってしまえば、変更できる仕様も変更できません。まず、自分が「変更してやる」と、強く思うこと。そこからです。