瑕疵について思ったことまとめ。ソフトウェアの欠陥といっても実は4種類ある。SWEBOK的に考えて。

請負契約でプロジェクトを始める前や、納品・検収が近づくと発注者・受注者間で必ずと言って良いほど交わされる会話がある。

• 受注者「納品後にバグがありましたら瑕疵として対応いたします。」
• 発注者「それは安心ですね。ところで瑕疵ってどの程度のバグは瑕疵ですか？」
• 受注者「えーとですね、それは、、、仕様通りに動作しない箇所は瑕疵ですね。」
• 発注者「そうですか。わかりました。」

このやりとり、もうちょっと掘り下げたい。

まず「仕様通りに動作しない箇所は瑕疵」というのは正しいが解釈としては乱暴。一口にソフトウェアの仕様といっても様々なレベルがある。たとえばシステムの機能要求に対するものもあるだろうし、明確なコーディング規約をもうけたにもかかわらずそれに従っていないのであればそれも仕様通りとはいえない。また非機能要求を満たせない状態も、非機能要求が仕様書のどこかに明文化されていればそれも含まれる。ユーザビリティは品質要求に含まれることもあるので、納品後に「なんだか使いづらい」とユーザから指摘をされたときも瑕疵として扱うのだろうか？

つまり瑕疵の前に、何をどのように作るのかといったことを発注者、受注者の間でしっかりとした共通認識がとれていることが前提条件となる。当たり前の話と言えばそれまでだが。

しかしプロジェクト開始前にしっかりとした共通認識をとっても、実際はそんな単純ではない。ソフトウェアの開発ではプロジェクト中に仕様が変わることは多々ある。スコープと品質でトレードオフが頻繁に発生することは当たり前で、お互いの妥協点を探りながらリリースを迎えるわけだ。ちなみに悲しいかな納期とコストはこのトレードオフに加わることが少ない。ビジネス上の制約は強いのだ。

変更というのは発注者側からされることが多い。作りながら考えることが多いため、仕様が動的になってしまうのは避けられない。そうなった場合、発注者側から瑕疵を主張するのには無理がでてくる。事前に定めた仕様を変えてしまっては、バグがでるのも仕方がないので、それを瑕疵と主張するのは無理がありませんか、と。

これは正とされる仕様がどの時点の何なのか、変更要求をしっかり行うしかない。地味で手間もかかるがそれ以外の回避方法はないだろう。

ちなみに私は、営業として参加したプロジェクトで、開発中にステークホルダーの同意の下で実装量を増やし品質を意図的に下げた機能について、プロジェクトが終了して数ヶ月後に発注側の担当者が変わってしまい「品質の不備について瑕疵として対応せよ」と主張されたことがある。メンバーは休日も返上して発注者の満足のために開発していたことを知っているだけに非常に悔しい思いをした。

話がそれたが本エントリー主張したいことは以下だ。

ソフトウェアの欠陥（バグ）と一口にいっても、実は4種類ある。これをきちんとするだけでも瑕疵に対する認識を明確に共有できるはずだ。

1. エラー　(error)："計算された結果と正しい結果との間に存在する差異"
2. フォールト　(foult)："コンピュータプログラムにおける不正なステップ、プロセス、またはデータ定義"
3. 故障　(failure)："フォールトが及ぼす[不正な]結果"
4. 間違い　(mistake)："不正な結果をもたらす人のアクション"

　（「ソフトウェアエンジニアリング　基礎知識体系　─SWEBOK2004─」より）

　

まず、わかりやすい「４．間違い」について。これは単純だ。ユーザーの操作ミスによって引き起こされる欠陥（現象といった方が適切だと思うが）であり、運用上の問題である。

「２．フォールト」「３．故障」は場合によってはテスト中、検収中に発見するのは難しいかもしれない。プログラムレベルの欠陥が紛れ込んで発生するのが希少な場合は実際に使ってみるまで発覚しない。私自身はフォールトと故障こそ、ただしく瑕疵だと考えている。

「仕様通りに動かない」のであれば「エラー」も瑕疵に含まれるだろうが、これはちょっと考えてほしい。つまり「"計算された結果と正しい結果との間に存在する差異"」はテストと検収で十分、発見できるはずであるし、できないのであればその方法に問題がある。言い換えれば検収自体がエラーだ。

こういったことを頭の片隅に起きつつ、全段で説明した会話を思い出してほしい。もう少しつっこんで話すべきだし、双方、成果物の何を検証し、どういった役割分担でそれを行うのか、話すべきことはいくらでもあるはずだ。

• 受注者「弊社では要求仕様書をもとにシステムテストを行います。御社で行われる検収もあわせて、システムの振る舞いが正しいかどうかは十分に検証できると考えますので、瑕疵はプログラムレベルで入り込んだ通常のテストでも発覚しないレアな現象が対象になります。したがって、機能要求通りに動いていないといった欠陥はテストミスおよび検収ミスとみなし、責任は双方にあるので費用は折半させていただきます。場合によっては全額御社の負担です。」

これくらい言っても良いのではないだろうか？　いや、言えないんだけどさ(苦笑)。

ソフトウェアから欠陥を完全に取り除くことは現実、ほぼ無理だろう。だからといって欠陥の除去に対して怠慢でよいわけではない。仕様通りに動かなければ瑕疵、というのも間違ってはいないが、それを安直に受け止めて品質改善の努力を怠るのもよくない。

現状をより正確に把握できれば、効果的な対処方法も講じやすくなるはずだ。

多分ね～。