品質が悪いのは、極論すれば最初から悪くなるような作り方をしていると考えてもいいように思っています。
本来、開発プロセスが洗練されてきた経緯を鑑みれば、品質を悪くする要素を少しでも早く取り除こうとする方向にプロセスはできています。
ドキュメントを作ってレビューするのもそうした考えの具体策というものでしょうか。
それでは、ソフトウェアの利点と考えていた柔軟性が失われてしまうということから、アジャイル的な作っては直すプロセスも生まれましたが、個人的に思うことは、品質が悪くなる要素をいかに早い段階で取り除くかという点はぶれていないと思っています。
例えは乱暴ですが、ドキュメントでは良いのかどうかわからない人でも、モノが動くことろを見れば良し悪しについて具体的な議論ができる側面もあるし、作りながら品質を高めていこういう考え方と取ることもできると考えています。
では、品質が悪くなる作り方とは、一番は、ゴールが動くことは最も品質を悪くする要素の一つです。
目的地に到達する速さを競う競技があったとして、目的地がどんどん遠ざかっていくのでは、計画が意味を成しません。そんな場所に行くための計画など持っていないのですから。
これで、品質を維持できるはずもありませんが、頑なに仕様追加や変更を拒否したら、売れないものしか出来上がらないかもしれません。まあ、それは開発というより企画なのでしょうけどね。
そういうところもひっくるめて計画なのであり、計画を維持してくれない味方は敵よりも厄介なものでしょうか。
実はメーカには品質より大事なものがあるのです。いや、メーカに限らずどんな会社でもそうなのでしょうけど、実はお金が一番なのです。
売り出すものがあるのとないのでは雲泥の差があるので、品質には目をつぶってもという部分が顔を覗かせる可能性は否定できません。
目先の問題と普遍的な問題はありませすが、稼ぐ力が会社の力量である以上、そこから逃れることはできません。
だからと言ってそれが正しいと言っては、作り手の意地が立ちません。
だからより売れるは正義であり、仕様は変化することから逃れられないのです。
とは言え、その仕様変更のプロセスが稚拙だと、品質の低下は加速すると考えています。
品質が悪くても出荷してしまうのであれば、品質を求めることなど誰もしなくなります。
品質を追及することが会社の儲けを阻害しているように見えてしまうからでしょうか。
どこで線を引き、品質を守るために死守するラインが引けている会社は、踏みとどまれます。
しかし、それすらない会社はプロセス以上に厄介なモチベーションまでも品質の敵に回り始めると考えます。
そうなってからでは、いろいろなことが困難になると思います。
客観的に自分のいる組織を見回して、冷静に分析してみてもいいかもしれませんね。
