仕様とバグの境界線はどこにあるのか
仕様とバグの境界線はないと私は考えます。ソフトウェアが自分の思った通りに動いてくれるかどうかは統一された操作感です。そのようなソフトウェアを作るには最初の段階でソフトウェアの基本原則を決めておくことが大事だと思います。作る側が本来の目的を失ってしまわないよう、常に設計思想を忘れないでいたいものです。
バグか仕様か
以下､2001年春の｢２ちゃんねる｣にて展開された､
ドルアーガシリーズの秘密解明
ドルアーガシリーズに関する情報を抜粋｡
作者の遠藤雅伸氏本人が皆の質問に答えている形が中心だが､
それ以外にも有益な書き込みはそのまま転載した｡
これはすごい！こんなスレッドが2chにあったんですね。
ドルアーガの塔ほど人の意見に差の出るゲームも少ないでしょう。ある人は名作といい、ある人はクソゲーと呼ぶ。それだけ好みの分かれるデザインということだと思います。ちなみにヌルゲーマーの私はこのゲームの本質を理解する前に挫折してしまいました。理解したとしてもダメだったような気はしますが。音楽は今でも好きですけどね。
さて、上記スレッド内で遠藤さんがこんな話をしておられます。
そんなあなたには､この名言を！
｢ソフトウェアにおける想定しない動作のうち､発売前に見つかったものをバグ､
後に見つかったものをフィーチャーと呼ぶ｣お後がよろしいようで｡
バグか仕様か。ソフトウェア開発ではよく問題になります。一般的に、利用者は「バグ」、プログラマは「仕様」、と言うことが多いようです。そこにはどのようなギャップがあり、プログラマはどう対処すべきなのでしょうか。自分なりに考えてみようと思います。
問題の種類
プログラムを使っていて、利用者の期待していない結果になる。その原因は様々ですが、大きくは以下のように分けられると考えられます。
環境の不具合
ソフトウェアを利用する上で必要な環境が準備されていない。例えば、ネットワークに接続していない。関連するソフトウェアがインストールされていない。空きメモリやディスク領域が足りない。など。
これはソフトウェアのインストーラーや運用マニュアルの不備によるものが多いです。事前に知らない人に使ってもらったりすると効果的です。
バグ
利用したソフトウェアのミスにより、正しく動かない。例えば、作った時に想定しないデータが来たので、正しく処理できない。ミスによりアクセス違反を起こし、プログラムが強制終了する。など。
ミスが明らかで対処方法が明確な場合は当然プログラムを修正するべきですが、環境やリソース不足などの要因により、対処が難しい場合があります。やむなく「仕様」とする場合でも、ドキュメントの充実やエラーメッセージの詳細化など、利用者が簡単にそのことを知る手段を講じておく必要があるでしょう。
仕様
ソフトウェアは考えた通りに作ったが、利用者がその振る舞いを知らなかった。例えば、多くのデータを登録したら途中で追加できなくなる。データを更新しても、すぐファイルに反映されない。ある条件の検索にとても時間がかかる。など。
コンピュータの処理能力やI/Oの制限・ソフトウェアの規模など、いろいろな要因からソフトウェアには制限がつきものです。万能のプログラムというものはありません。しかし使う人からみれば、プログラムは意図したように動いて欲しいわけで、製作者とのギャップが産まれます。それが仕様とバグの境界線でして、しばしば問題になります。
仕様とバグの境界線
これね｡はは｡ちょっとプログラムの素養があればわかるんだけど､
バグというのは想定されない効果が想定されない状況で起こる不都合なのであって､
この場合はどう見てもフィーチャーじゃないですか｡しかもプレイヤーに有利な｡
さて、仕様とバグの境界線はどこにあるのでしょうか。結論から言えばないということになると私は考えます。
ソフトウェアが自分の思った通りに動いてくれるかどうか。人はどのようにしてそれを判断しているでしょうか。これは私見ですけど、それは高機能かどうかではなく統一された操作感にあります。そのようなプログラムは直感的に使うことができ、予測が容易で、目指す機能も探しやすくなっているものです。
そのようなソフトウェアを作るにはどうしたらよいか。それは最初の段階でソフトウェアの基本原則を決めておくことだと思います。それはどんな機能を実現するかという具体的なものではなく、もっと概念的なもの。例えばユーザがイライラしない待ち時間にするとか、初めての人でも迷わない。遅いマシンでもストレスなく。などなど。ソフトウェアの目指すところを明確にすること。それにはまずユーザの求めていることをよく知り、互いに納得することが大切なのは言うまでもありません。
ソフトウェアで問題が発生すると、それを仕様とするかバグとして扱うかということがよく問題になります。そんな時、コンセプトがはっきりしていれば、原則に照らし合わせることで判断が楽になるでしょう。ユーザへの説明もしやすいに違いありません。
皆さんご存じのように、コンピュータソフトウェアはプログラムを変更するだけで動作を変更できる、とても柔軟性の高いシステムです。しかしそれは同時に、複雑で意味不明な変更もできてしまえることも意味しています。作る側が本来の目的を失ってしまわないよう、常に設計思想を忘れないでいたいものです。
