• データの不整合、プログラムの不具合等の障害が頻繁に発生するため、日々の業務が滞る
• 障害発生時に障害箇所の特定に時間がかかり、修復までの間、運用の負担が大きい
• 障害対応・機能改修を行う度に、高い運用・保守コストがかかっている

これらの原因は、アプリケーションの品質、保守性が悪いプログラムによるものと考えられます。
プログラム（ソースコード）は、設計やプログラミングを理解しなくては、お客様自身で品質をチェックすることが難しいものです。往々にして、開発者が属人的なプログラムを作成し、プログラムの品質低下を招くことがあります。

このため、開発コストを抑えることができた場合でも、運用・保守で多額のコストが発生してしまいます。

• 処理毎の役割を明確化する
• 共通化部分の再利用性を向上する
• 回帰的なテストを実施する

• 機能拡張・機能変更を行う場合、プログラムを変更する箇所の特定が容易となる
• 障害が発生した場合、障害箇所が局所化でき、影響範囲の特定が容易となる
• 処理を分離することで、要員のスキルに適した処理を割り振ることができる
  （例：画面描画処理はデザイナー担当、業務処理はプログラマー担当）
• 処理を分離することで、処理の共通化が容易になり、品質のバラつきを抑えることができる
• 業務処理単体でテストが行えるため、複雑な処理やバグが多い処理を重点的にテストができる

• 処理の共通化により、開発に掛かるコストを削減できる
• 変更箇所・障害箇所の特定が容易になり、調査に掛かるコストを削減できる

• 小さく部品化することで、部品毎の役割が明確になり、プログラムを変更する箇所の特定が容易となる（例： 画面の入出力を行う。計算処理を行う。データベースを検索する。）
• 障害が発生した場合、障害箇所が局所化でき、影響範囲の特定が容易となる
• テスト用の部品を組み合わせることで、プログラムモジュール毎のテストが容易になる
• 部品間の依存関係を設定ファイルで設定することができるため、部品の差し替えが柔軟にできる
• 部品化することで、共通化部分の再利用性が高まり、個別実装による品質のバラつきを抑えることができる
• 部品間の関係が疎結合となるため、部品単位で機能を強化することができる

• 共通化部分の個別実装を排除することで、開発に掛かるコストを削減できる
• 変更箇所・障害箇所の特定が容易のため、調査に掛かるコストを削減できる
• プログラム変更の影響が小さく済むため、プログラム変更に掛かるコストを削減できる

• 同様のテストを回帰的に実施する場合、毎回簡単にテストを実行することができる
• 自動的にテストが行われるため、人的なミスが発生しにくい
• テストが容易なため、より多くのテストを実施することで、意図していない箇所の不具合を発見しやすくなる

• テストが自動的に行われるため、手動によるテストと比べてコストを削減することができる