検索
「不具合のない世界」は困る？
不具合のあるシステムを納品するほうがビジネスとしては儲かる、そんな皮肉な見方もあります。不具合があれば改修の機会が生まれ、それが次の仕事につながるからです。
この状況が、品質向上への取り組みを阻害しているのかもしれません。表向きは顧客志向を掲げながら、実際には自社の利益を優先しているケースもなかに存在します。
海外と比較しても、日本のシステム開発のあり方には問題があります。海外では、メーカー側が決めたパッケージ製品の仕様の範囲内で品質を担保し、不具合があってもすぐに無償で修正されます。オープンソースの文化が根付いており、エンドユーザーと開発側の協力関係が築かれているからです。
対する日本のSIerはエンドユーザーの要望に合わせてきめ細かくスクラッチ開発をおこない、その結果品質が落ちているという側面もあります。
しかし、品質の低いシステムは、エンドユーザーにとって大きな負担となります。使い勝手が悪く、不具合も多いシステムでは、業務の効率化どころか、かえって手間が増えてしまいます。エンドユーザーは、システムの不備を補うために、手作業で対応せざるを得なくなることもあります。
また品質の低さは、システムの保守性や拡張性を損ない、将来的な開発コストの増大や、システムの陳腐化を招く要因となります。不具合が頻発すれば、その都度対応に追われることになります。
運用コストが肥大化し、本来の業務に支障をきたすこともあります。銀行のシステム障害でATMが使えなくなるなど、一般のユーザーにまで影響が出てしまうことすらあります。そうすれば、企業イメージの低下にもつながりかねません。
セキュリティ対策が不十分なシステムが開発されれば、エンドユーザーの機密情報の漏洩や、サイバー攻撃の被害につながる可能性もあります。
システム開発に携わる者は、品質の重要性を改めて認識する必要があります。品質を二の次にするような開発姿勢は、早急に改められなければなりません。
ウォーターフォール型開発の限界
ここまでシステムの品質低下の問題を見てきました。しかし多重下請け構造のなかでできあがるシステムが抱える問題は、それだけではありません。たとえ100％の品質で作れたとしても、得てして時代遅れなものになりがちなのです。
その要因の一つが、ウォーターフォール型開発の採用です。
ウォーターフォール型開発は、開発工程を明確に区分し各段階を順番に完了させてから次の工程に進む開発方法で、各工程が滝のように上流から下流へと順序立てて直線的に進行されます。多くの日本企業では、市場変化に強いアジャイル型開発の導入が進んでおらず、従来型のウォーターフォール型開発が主流となっています。
多重下請け構造下では、この傾向がさらに顕著になります。各工程が複数の企業に分断されているため、全体最適を図るにはウォーターフォール型開発を用いるほうが良いからです。
ウォーターフォール型開発を前提とした受発注が繰り返され、時代に即したシステムを構築できない。こうした硬直的な開発スタイルが、レガシーシステムを量産する原因となっているのです。
ウォーターフォール型開発の弊害は、エンドユーザーの利便性を大きく損ねます。システム開発会社側には、エンドユーザーの業務を深く理解し、場合に応じて開発手法を使い分けることが求められます。
