ソフトウェアがどのように開発され、どのような問題がコードベースに潜んでいるかを知ることで、ビジネスマンや弁護士は、ソフトウェア・リスクとその緩和方法を理解しやすくなります。
統制のとれた開発は、まさにプロセス主導型です。組織の規模や段階に合わせて、適切に実行される優れたプロセスがあれば、優れたソフトウェアが生まれます。しかし、多くの組織にはしっかりと明確に定義されたプロセスがありません。特に、急成長を遂げた企業では、小規模なチームには有効なプロセスがあっても、そのプロセスをチームに合わせて拡張していないことがあります。最適でないプロセスや不適切なプロセスでは、問題のあるソフトウェアが生まれる可能性があります。
同様に、優れたプロセスがあっても、それに従わないと、ソフトウェアの品質が低下します。適切なプロセスが守られない理由はたくさんあります。教育と文書化の不足が原因であることは確かです。しかし、より大きな要因は、ほとんどの組織で、ビジネス上のプレッシャーにさらされたときにプロセスを守るための統制がとれないことです。このため、短期的には役立っても、既知および未知の問題を未来に先送りするような簡単な方法が採用されてしまうのです。
技術的負債の例
技術的負債とは、このような簡単な方法を採用した結果です。実際、将来対処しなければならない問題をなおざりにすることは「それらの対処に係るコストを借入」（つまり、明白な、あるいは潜在的な問題への対処を先送り）することで、ソフトウェアをすぐに市場に出すことができるというわけです。技術的負債の例としては、QAにかかる時間を最小限に抑えて、ただうまくいくことを願っている状態や、将来的に拡張できないことを知りながら、その場しのぎの策を実行することなどが挙げられます。多くの場合、開発者は「後」でそれらの問題を修正するつもりで、こうした近道をしますが、粗悪なソフトウェアがリリースされてしまうのは、そのような意図によるものなのです。
深刻なのは、プロセスを維持するための統制がとれていない組織では、技術的負債を構成する問題を追跡する能力も欠けている可能性が高いということです。そのため、問題を定量化することができず、開発サイクルのたびに問題の重さを感じるだけでしかありません。
ソフトウェアデューデリジェンスの準備
ソフトウェア開発がどのように失敗するかを理解することで、ビジネスマン、投資家、そしてそのアドバイザーは、ソフトウェアリスクの影響をより適切に評価して理解できるようになります。
Continue Reading
