正しいものを作ることと正しくものを作ること

プログラムを作ることはそれほど難しいことではない。それを製品にしてビジネスとすることは非常に難しい。「正しくものを作ること」より「正しいものを作ること」のほうがはるかに難しいのである。
いわゆるウォーターフォールモデルでは開発プロセスの初期に仕様を固定してそれを「正しく作る」事に注力する。１千行あたりのバグ数とか月当たりの生産コード行数などが、いかに「正しくものを作ったか」の生産性の指標になる。ソフトウェアファクトリとか日本のソフトウェア産業の得意とするところである。開発プロセスの初期段階で仕様を固定するので、状況の変化とか、顧客の要求の変化とかには取り合えず目をつぶるので、作られたものが顧客に必要とされているものかは、ものができてみないかぎりよく分からない。まあ、原子炉の制御システムみたいに信頼性が絶対条件だとか、システム要件が何年経ってもほとんど変化しないものには、そーゆー開発プロセスはあっているが、コンシューマ向けプロダクトとかは半年、三ヶ月で要件がどんどん変化していくので、ウォーターフォールモデルは適していない。
「正しいものを作ること」が圧倒的に重要になってくるのである。では、どーすれば「正しいもの」を作れるのか？変化を受け入れるのである。仕様を固定するなどということをはじめから考えない（といっては大げさだが感覚的にはそーゆーことである。）いまでこそ、気のきいたプログラマなら、「同期安定プロセス」とか「デイリービルド」、「リグレッションテスト」などという言葉について理解はあるかと思うが、そーゆー事について、実践し血となり肉となっている人がどれだけいるか？

ソフトウエア企業の競争戦略

ソフトウエア企業の競争戦略 マイケル A.クスマノ著、 の４章あたりを読むとその手のベストプラクティスが書いてある。80年代ころから競争力のあるソフトウェア製品を開発していた組織は多かれ少なかれそのような事柄を実践していたわけだが、MITのビジネススクールに取り上げられるのは時間差がある。20年といっちゃああれだけど現場でいろいろ試されているプラクティスが本になって紹介されるのには、やはり相当な年月が必要なのである。日記とかBLOGとか言われるものがこの手のベストプラクティスを記すようになれば面白いなあなどと思ったGWの昼下がりである。