プログラマーとして夢想する作り捨てを許さない組織文化

自分がソフトウェア開発プロジェクトにプログラマーであったり、プロジェクトリーダーであったり色々な役割を担いながら参加してきて、常に悩まされてきた問題についてちょっと考察してみようと思います。
それは作り捨てと個人的には呼んでいる、小規模な案件に比較的多く見られる事象です。

作り捨てとは何か？

• 作ったシステム、PJ等を技術的負債を残して放置すること

と、とりあえず定義します。

作り捨てられてしまったシステム…。そこでよく見るアンチパターンを列挙してみます。

• ユニットテストなし
• 仕様書なし
  • 機能仕様書
  • 試験仕様書
  • その結果どのように動くのが正しいのか分からない
• その場しのぎの実装
  • staticおじさんの猛威
  • 神オブジェクト
  • コピペの嵐
  • などなどの実装のヤバさ
• 動作環境がない
• バージョン管理されてない

既存機能にテストがないと正直泣ける。
ユニットテストを作る工数を見積に入れざるを得ないけど、高すぎるって言われるんだろうな。 作り捨てで作ったものは利益を先食いしてるんで、後から何かしようとするとコストがかかるというのは先に作った人が説明していないと、後から作る人が肩身狭い思いするんですよね…。
どうにかならんのか。

なぜ作り捨てが起きるのか？

なぜ、こんなことになってしまったのか…。
現在のチームメンバーに聞いてみたところ以下のような答えが返ってきました。

• エース開発者が作って別の案件に引き抜かれる
• 最初に作る人が保守しやすいものを作っていない
  • 自分たちとお客さんがそれを良しとしている
  • 保守性と引き換えに早く作った
  • 利益の先取り

あと、個人的には作り捨てで作ったシステムやそのチームを正しく評価出来ていないということも遠因としてあるのではないか？
とか思うけど、ヒラメンバーとしてはいかんともしがたい…。

作り捨てを文化で防ぐ事が出来ないだろうか？

常に作り捨てに悩まされてきた身としてはなんとしてもこの事態を打開したい。
また、今後作り捨てに悩まされるような不幸なソフトウェアエンジニアを増やしたくない。

• 作り捨てはやらない文化を組織として持ちたい！

どうしたらいい？とこれまたチームメンバーに聞いてみた。

• あるプロジェクトにではレビューまでやらないとリリースしないポリシーでやっている
• 痛い目を見ないと伝わらない？
• 常駐主体だから文化が根付かない？
• リーダーがどういう意識でいるかで決まる？
• 顧客から仕様書・ユニットテストはいらないから安くしろと言われる。
• 仕様書がないと仕様を不具合だと言われたときに逃げられない
• 品質保証部があれば良さそう
  • リーダーの意識で方針が決まってしまうので、第三者が判断したほうが良い
  • PMO、クオリティアシュアランス

ちょっとなぜ作り捨てが起きるかという部分も混ざっているけれど…。
こういうふうに問題提起するだけでも抑止になってくれたりするんじゃないかなぁ。
という感じで結論は出てないけど、少しでも前より良くなっていきたいと夢想するわけです。