「バグ」って何？

「これってバグですよね？」「いやいや、これはバグじゃなくて仕様です」

SEとこんなやりとりしたことはないでしょうか？

どう見てもバグなのにバグと認めないSE……。話が通じなくて腹立ちますね。

今回は「バグ」とはなんなのか詳しく解説してみたいと思います。

バグとは仕様書通りでない挙動のこと

予定通り動かない挙動をバグと思いがちですが、私たちSEからすると少し違います。

正しくは「仕様書通りに動いてない挙動」がバグなんです。

仕様とは、依頼者の要求を実現するためにシステム的に落とし込んだ定義のことです。

例えばWebサイトのお問い合わせフォームであれば、次のようなものです。

• 必須項目は何か？
• 任意項目は何か？
• その項目は自由入力か、選択式か
• 選択式の場合、選択肢は？

このような、システム化にあたって取り決めた内容を「仕様」と呼び、それを記した書類が仕様書です。

「バグ」とは、この仕様書に書かれた通りに動かいてない動作のことを指します。

どんなにおかしな動作でも、仕様書に書かれていたらバグでない

ここで大事なことは、どんなに不思議でおかしな動きだとしても、仕様書に書かれた通りの動きであれば、それはバグではなく仕様ということです。

「でも、やっぱり動きがおかしいから直して欲しい」

とはいえシステムは目に見えないものなので、仕様決めの段階で最終的な動きがイメージできず、そう思う方も多いと思います。

ただ何回ベンダーに説明しても仕様を理解せず仕様書を修正してくれなかったとか、よほどベンダー側に落ち度がない限りは「仕様変更」となり、追加費用がかかる話になってしまいます。

なので、仕様確認はすごく大事なんです。

「仕様書は見ても良く分からないから」と敬遠せず、細部までしっかり目を通すようにしましょう。

そもそも仕様書に記載がなかったら？

仕様書通りの動きだったらバグにならないのは分かった。でも、そもそも仕様書に記載がなかったら？

通常、仕様書に記載がないということは開発当時に挙動を決めなかったということになります。

例えば前述のお問い合わせフォームの例だと、送信ボタンを押したときの動きは決めたけど、キャンセルボタンの動きを決めなかった、みたいな状況があったりします。

そういうものは、しょうがないので後付けで仕様を決めることになります。

この場合、バグなのか仕様なのかはケースバイケースの判断になります。

これはつまり、依頼者とベンダーのどちらに責任があるのか？（改修費用を持つのか？）という話になるので、モメることがあります。

なので、仕様確認はすごく大事なんです。（二回目）

システム開発において「暗黙の了解」と言うものは存在しません。

「仕様書に書かれてない」ことは「やらないこと」なので、どんなに小さなことでも疑問に思ったことはどんどん質問するようにしましょう！

そもそも仕様書を作ってなかったら？

あまり考えたくありませんが、ずさんなベンダーだと仕様書を作らないところもあります。

仕様書を作らない分開発費を下げたり、短納期で開発できます、と言ってきたりします。

正直、仕様書って作るのもその後メンテナンスするのも大変ですからね。

ただこの場合、バグか仕様か判断できなくなるので、開発時は良くても納品後に一番ぐだぐだになるパターンです。

「仕様を伝えた（依頼者）」「いや聞いてない（ベンダー）」の水かけ論になり、最悪裁判に発展してしまうこともあり得ます。

そうなると、最後に頼りになるのは契約書だけになります。

そういうベンダーを最初から選ばないことが一番大事ですが、少なくとも契約書だけはちゃんと作成するようにしておきましょう。（商売の基本です！）

まとめ

いかがでしたでしょうか？

バグと仕様は密接に関係しています。

バグかどうかは、仕様書の記載通りかどうかという話と同じです。

そのため、仕様書は依頼者にとってもベンダーにとっても、とても大事な文書になりますので決しておろそかにしないでください。

仕様書がない場合、最悪バグの改修が全て「仕様追加」という形で費用請求されても文句が言えません。

ベンダーが仕様書を作ってなかったら、絶対に作らせるようにしましょう。