全てを解決する銀の弾丸は無いが、個別を解決する銀の弾丸は存在する

ソフトウェア業界における、問題解決手段でどんな問題でも解決ができるという万能な方法は無いとして、皮肉として言われ続けている「銀の弾丸はない」という言葉ですが、このセリフをよくいう人には要注意しなければならない。 wikipedia 今回はソフトウェアの不具合について考えてみたい。

どのような問題があるのか？

ソフトウェアの問題といえば、ほとんどの場合がバグと仕様不具合である。 バグとは、「プログラムの記述ミス」の事で、仕様不具合はバグは無いが、仕様として不備があるという事。 これらの多くが発生すると、とにかく開発元としての責任が追求される。 製造物責任法 製造を行なった人の責任で、「瑕疵」や「瑕疵担保責任」などと言う風に契約を交わすことが多い。 とにかく、瑕疵（不具合）はどのようなレベルでも責められるという事は製造担当の人たちは認識しなければならない。

不具合の種類

一言で不具合と言っても様々なモノが存在する。 普通、「不具合」と聞くとマイナスな事しかイメージできない。 wikipediaで調べてみても、

物事の調子や都合、状態が悪いこと。具合が良くないこと

と書かれている。 そして、ジャンル別に分解してみると、

1. ソフトウェアが動作しなくなる
2. ソフトウェアは使えるが、見た目がおかしい

大きなモノも小さなモノもこの２種類に分類できると思われる。 要するに１番に関しては致命的な不具合として改修対象になるが、２番に関しては、このソフトウェアに関わり方によって、判断の仕方が変わる。

認識のズレ

多くの人が、「見た目」がおかしいが正常に使える状態は

ガマンすればいい

という風に思われる場合もあり、この場合の不具合かどうかの切り分けが難しくなるポイントでもあることは間違いない。 製造元は、改修作業をできるだけ行いたくないため、こういった曖昧なモノに関しては、「正常に動作が行える」という事を理由に不具合としないケースもあり、 実際に使用しているユーザーは少しの違和感も気に入らなければ不具合として改修してもらいたいと考える。 実際に、ショップで購入した商品が少し汚れていると、新品と交換してもらいたいというユーザー心理は多くの人が考えるユーザーの当然の権利として考えられるはずです。

多くの不具合が事後確認される

不具合というのは、事前に確認されるものは「検証」や「テスト」として扱われるため、この段階では不具合とされない。 製品リリースをして、ユーザーが使用して発生したものが、初めて不具合として認定される。 ただ、製造者クオリティは認識しなくてはいけない。 開発員によっては、テスト段階で不具合を多発する者と、その段階から修正が少ない者がいるが、開発クオリティはこの時点で把握しなければいけない。 多くのソフトウェアは、公になる事後不具合について判断されるが、こうした不具合についても、そもそも開発クオリティが低い者が開発した製品については、「起こるべくして起きる不具合」であり、 開発クオリティが高い者が開発した製品については「テストや検証でも見つけられなかった希少な不具合」とされる。 多くの会社でこういった開発クオリティが考えられずに、リリース後のクオリティで考えられる事がほとんどの為、開発品質の向上が行われない現場が多い事も、問題視した方がいい。

製造クオリティの向上に向けて

多くの開発者が、不具合をつきつけられた時に 「開発時間やリソース」を原因に上げることが多く、聞く人によれば、まるで開発者が「自分は悪く無い」「会社の体制が悪い」という風に責任転嫁の姿勢を持つ開発員も意外と少なくない。 また、同じようなコーディングミスを繰り返す開発者、自ら複雑なコード構成を作り「アルゴリズムが破綻している」とそもそもの基板設計などを否定し始める開発者 多くは現場のマネジメントに原因がある事が多いため、製造クオリティ自体は組織体制の問題と考えるが、個別の問題に目を向けることも忘れてはいけない・ そして、こういった不具合の対応について「銀の弾丸は無い」と言い始める製造担当者がいたとすれば、その製品に未来はないのである。 解決方法で求められるのは総合的な「銀の弾丸」ではなく、個別に対応する「銀の小弾」ということを認識するべきである。 開発員教育とは是非こういった視点で行われると組織の発展にもつながるはず。