前回のエントリでは、あちこちに波紋が広がってしまいました....www。
参考になるコメントを頂いてありがとうございます。(各Blog伴に)
「誰が何を要求しているのか」と「各行程の作業実務者の品質意識」と「行程管理者の管理意思」と「各担当の利益」を同一の土俵にするのは不可能に近いでしょう。どこかで妥協しなければなりません。その妥協点が合意出来れば最良なのでしょうが、不満総量が最小になる箇所で自然に落ち着く気がします。大同小異で各行程の人が同じ位の不満を持つ状態が、実務の姿かなぁ。 と斜に構えて、発言してますが、開発者としては寂しいです。
テーマが大きくて、全体的には考えが纏まらないので、「顧客はコード品質を要求しているか」の点で考えて見ました。
一般的な業務アプリは、集計作業の固まりとみて良い思います。(統計分析・予測含む)
機能は、データの入力と抽出と加工と出力 です。(単純化するため制御系や言語系やゲーム系は省きます。)
入力要件と出力要件と応答性が満たされれば、業務システムは合格点と見なされます。製品の品質は不問です。
品質云々は開発者の意識度と、納品監督部署がソースの品質を考慮するかしないかの人間性に依存します。
品質を定量的に測定するツールはないです。テストツールはテストパターンの自動化は厳しいので定量性とは言えないでしょう。
問題を複雑にしているのは、汚いソースでも綺麗なソースでもエレガントなソースでも、要求通り動いてしまうことです。汚いソースでも、正常系処理では落ちない程度の品質は保っているでしょう。(楽観的期待ですが)
異常系操作で落ちても、「想定外のデータを入力した操作員が悪い」という言い分がまかり通る「未熟な実体」も時々目にします。
ラジオやテレビが単純なIC構成であった時代は、回路を平面エッチングで結線していました。エッチングパターンも明らかに下手な配線というのもあって、ノイズの元になったりします。回避策として、回路切断して、ジャンパ配線で取り繕うこともあったようです。つまり、汚いソースのまま納品するのと同じです。でも、顧客は、テレビを見ることは可能なので、回路品質は不問です。
あちこちで書かれているように、ハードに進歩が非効率なソースの冗長性を隠してしまうのが現実です。
5倍遅いソースでも10倍はやいCPUなら結果として早くなるので、困ったものです。
ソースが読める顧客は、要求する品質が可能な開発者に発注するので、この手の問題は起こり難いでしょう。
納品後の改変や仕様変更に対応すること踏まえて、変更の容易さはソース品質に比例します。
変更作業者にとって読みやすいソースが望ましいと考えています。
只、問題があり、新人や知識の少ない変更作業者が保守する会社があることです。その人たちに品質を合わせると、議論が振り出しに戻ってしまいます。
私は「IT業界はまだまだ成長期で、あるべき姿になっていない。」と感じます。