【ソフトウェア開発】バグがなければよいものか
ソフトウェアまたはシステムの品質を考えた時、バグが無ければ、十分な品質を満たしていると考えがちな人は多いと思います。「えぇー、そんなことないよー」と言う人も若干はいると思いますが、たとえば
「じゃあ、品質のいいソフトウェアってどういうものだと思う？」
と聞かれたら、みなさんはなんと答えるのでしょう。
私が今まで質問してきた方々の答えの多くには
「え？んー…バグが無いこと…とか？」
と言う内容のものが一番多かったですよ。もちろん、バグが（最終的に）残っていない状態にするのも、良い品質の定義の１つであることは疑いようもありません（厳密には「バグの有無」ではなく、「顧客要求事項を満たす機能」であることかどうかですので、バグが存在したままでも顧客の要求をすべて満たせる機能になっていて、顧客の利用に支障がまったく無ければ、製品としての品質上、なにも問題ではないのです）。
しかし、それだけでは必要最低限…むしろ大前提となることはあっても、良い品質としての条件を満たすには必要十分とは言えません。
エネルギーや資源問題については、ごみのリサイクルのように「環境の"品質"」が社会に認知されています。しかし、「情報取り扱いの"品質"」については未だ具体的に語られていません（ISO 25010のような概要、ガイドラインはハッキリしているんですけどね）。
要は、そのガイドラインを元に、「具体的な品質の定義に落とし込むのは、各企業、各エンジニアが自分たちの関わるプロジェクト特性にあわせて考えなさい」と言われているので、そう言ったことに不勉強な企業、不勉強なエンジニアたちにとっては、個人の力量に依存し、「自由」「無法地帯」「適当」となりやすい分野であるとも言えるのです（いっそのこと、建築や食品、医療のように法で強制してしまえばいいのに…とも思わなくも無いんですけど）。
ＩＴの技術も他の業界と同じように、使い方を誤ればゴミにもなりますし、先を見据えて適切に作成していればリサイクルすることも可能ですが、現時点では
ソフトウェアの品質を良くしなければ、様々な不具合が起きる
と言われ続けて久しく、そして未だにその域から脱却できないままでいます。こうした問題をすべて解決するというのは大変困難なことですが、解決しようという努力、取り組んで当たり前と言う認識を、私たちＩＴに関わるものは一人ひとりが持っている必要があります。その意味で、「ソフトウェアの品質管理」と言うテーマは非常に重要です。
開発現場での「品質管理」と言うと、バグが発生したらその内容を一覧等にまとめてステータス管理し、
今日、バグが何件発生した
今日、何件のバグを消化した
と言った進捗管理をするものと思い込んでいる人も多いのではないでしょうか。
けれども、これはスケジュール管理の基準を「バグ発生／解決」と言う単位で定量的に示しているだけで、品質の管理にはなっていません。
たとえば、このグラフでは、発生したバグそのものの件数を管理してはいますが、バグ１件ごとの影響度、規模、これからかかる工数、類似見直しの有無など、なに１つわかりません。バグ一つひとつの定性的な分析も行われておらず、この内容から再発防止策をひねり出すことは不可能です。ただ現時点での実績を測定するだけのもので、対策について計画することも、対策が完了するまでのスケジュールを予測することもできないグラフです。
他にも、こう言う質問をされた場合、みなさんならどう答えるでしょう。
「バグさえなければ、顧客は必ず満足するか？」
いかがでしょう。たとえば、お客さまにあらかじめ「欲しい」と言われていた機能はすべて実装したとします。バグも一切残っていません。そんなソフトウェアを納入すれば、「必ず」「絶対」「100%」お客さまは喜ぶでしょうか。
もしも、必要な機能が全て備えられていて、バグも一切存在しないソフトウェアが、非常に使いづらかったらどうでしょう。世の中一般的には、使いやすいと言われるＵＩでも、旧態依然としたシステムを長年使い続けたユーザーの場合、急に見た目や使い勝手を変えられると、それに慣れるまでの手間・負担（スイッチングコスト）が大幅にかかりすぎて、不満を仰る方もいます。スマホが普及した当時、ガラケーに慣れ親しんだ一定の人たちはなかなかスマホに移行できませんでしたよね。アレと同じです。
自分にとって、自分の周りの人たちにとって「使いやすい」と思っていても、実際のお客さまと向き合っていないと、お客さまにとっては「使いづらい」かもしれないのです。つまり、ソフトウェアの品質が良いものであっても、「ビジネスの品質」がバグだらけでは商売は成立しないことを意味します。
ただただ、ソフトウェアにバグが無ければ良い、というわけではないのです。テストをして仕様の通りにできていれば合格…と言う考え方だけでは、社会に対するニーズや品質要求を決して満たすことはできません。
テストでバグが出なかった。
お客さまに納品した。
「なんか思ってたのと違う」って言われた。
こう言うことはよくあります。
品質の最終ゴールを「顧客満足度を満たす」ことにターゲッティングできていないからです。ＩＴ業界の仕事を「development（開発）」だと誤解していて、現状の不満に対する「solution（解決）」ができていないせいです。
この意識をソフトウェア開発を担うエンジニアだけでなく、ビジネスのツールとしてソフトウェアを利用している顧客を含むすべての企業が持たなければならないと言うことを忘れてはなりません。
昨今、ＤＸ（Digital Transformation）をパワーワードにする企業も増えてきたと思います（諸外国と比べるとカメ以下のスピードですが）。
ですが、利用する側のユーザーも含め、ＩＴに関わる多くの方々は、そもそもＩＴに何を求め、何が求められているのかを、もう一度再認識する機会を作らなければ、望むＤＸ時代が到来することは、あるいは到来させることは困難になるのではないでしょうか。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。