ふと「ソフトウェア品質のxxx」みたいな文章を見つつ、基本としてはソフトウェアがいかに仕様どおりになっているか確認する話だったので、これってソフトウェア品質じゃなくて、ソフトウェア開発品質だよなーと思った。
実際、ソフトウェア開発の品質と、ソフトウェアの品質には相関はあると思う。とくに1990年代まで、まだITという言葉があまり使われず、OA、つまりオフィスオートメーションがソフトウェアの主な開発対象だったときには、データがちゃんと入ってデータがちゃんと届けられるということが主な処理だったため、ソフトウェア開発の品質と、ソフトウェアの品質はほぼ一致していたと思う。
そういう中で、ソフトウェア品質として、ソフトウェア開発の品質が研究された。
実際、ソフトウェア開発プロセスの基本コンセプトのひとつは、「よいプロセスがよいソフトウェアを作る」ということで、ソフトウェアプロセスの本を見ると必ずといっていいほど、こういった言葉が前書きにある。
ただ、それがちょっと状況が変わった。
んで、2000年代にソフトウェア開発の主戦場がWeb上のサービスになるにしたがって、仕様どおり作るという意味でのソフトウェア品質の優先度が下がって、適切なものを適切な時期に(仕様どおりじゃないにしろ)リリースする、ということの優先度があがり、従来のソフトウェア品質、つまりソフトウェア開発品質は邪魔になってしまった。その代表的なものがウォーターフォールだ。ソフトウェア開発品質をあげようとすると、どうしてもウォーターフォール的手続きは重要になる。
とはいいえ、よいソフトウェアをつくるためにはよいプロセスは必要で、そんななかで、現実解として使われたのがアジャイルでありTDDだと思う。だけど、当初はソフトウェア開発品質のたしなみがある人がかかわってきたものが、どんどんその経験がなくアジャイル・TDDから始めた人が増えるにしたがって、ウォーターフォールに代表されるソフトウェア開発品質と一緒に、ソフトウェア品質そのものがごっそりロストテクノロジーになってしまった。
たとえば、TDDはブラックボックスの品質なので、実際はペアプログラミングによってホワイトボックス的な品質を担保することが必要で、それらをまとめてXPになっていたのだけど、ペアプログラミングは実地ではあまりにも高コストのため、行われなくなっている。かといって、ソースコードレビューをやりましょう、という流れにもなっておらず、気の効いた人・集団がとりいれているという感じ。
一方で、ソフトウェア開発品質のほうにもダメな流れがあって、これをソフトウェア品質と呼んでいたので、とにかく仕様通り作ればいいということになってしまった。
その最たるものがdocomo SPモードメールアプリで、明らかにキャリアの命運がかかってて、予算もそれなりにとれるはずで、今までの使われ方もわかっているようなアプリが、どうやったらこんなクソアプリになるのか。
そういうのがいろんなところにあって、ソフトウェア品質とソフトウェア開発品質が一致できるハードウェアよりのほうはそれなりによくても、そこに乗ってるソフトウェアはぜんぜんダメというのをよく目にする。んで、こういう話をすると、ハードウェアも状況が変わってダメになってますよとか言われたり。
まあ、とにかく、ソフトウェア開発品質と、ソフトウェア品質は分けて考えて、「ソフトウェア品質」としてまとめて語られてきたソフトウェア開発の品質とソフトウェア自体の品質を、もう一度考え直すのもいいんじゃなかろうか。
