システム開発の現場では、もちろん計画通り順調に進み、成功するプロジェクトもありますが、失敗してしまうケースも数多くあります。システム開発のプロジェクトの70%が何らかの失敗に陥っているという調査結果が出たこともありました。
ではなぜシステム開発の失敗が発生するのでしょうか。その原因について考えていきましょう。
プロジェクト開始時の準備不足
失敗するプロジェクトで多く見られるケースが、プロジェクトのゴール、開発するシステムの役割や、導入後に期待される効果などを明確にしないままプロジェクトを開始してしまい、品質、コスト、納期ともに中途半端な状態でリリースすることになる、といったものです。
これは、開発サイドは納期とコストを重視する傾向があり、そのシステムの目的を正確に理解していない場合が多いこと、ユーザサイドに技術的な理解度が低く、発注以降の管理を開発サイドに全て任せてしまうことなどが原因で発生することが多いようです。
特にプロジェクトの期間が長くなればなるほど、目先の進捗に捉われて、システムそのものの目的や、それによる効果に目がいかなくなりがちです。
こういった目的のブレや認識のずれなどを防ぐ方法としては、そもそも何をどう実現したいのか、なぜこのシステムが必要なのか、をプロジェクト発足時に十分話し合い、ユーザサイドと開発サイドで認識を合わせ、明確にしておくことが重要です。
プロジェクトの軸となる認識の不統一
開発が進むに従ってシステムの姿が目に見えてくるようになると、ユーザサイドから新しい要求や仕様の変更などの要望が発生します。こういった仕様の変更や機能の追加は少量であれば対応可能でしょうが、失敗するプロジェクトの多くで、納期内での対応が不可能な量や内容の仕様変更や追加が行われており、それがプロジェクトの失敗の原因となることは少なくありません。
こちらに関しても、プロジェクト発足時のコミュニケーション不足、認識の不統一が原因であることが多く、プロジェクト発足時に、目的や必要な機能などについて十分な話し合いを行うことで、ある程度リスクを軽減させることができます。
また、プロジェクト工程の後半で大規模な仕様変更や追加を行うことは、プロジェクトそのものを破綻させてしまう危険性が非常に高いため、現実的に実行不可能な仕様変更、追加に関しては、「行わない」という決断ができるかどうかもプロジェクトを失敗させないためには必要となってきます。
優先順位の未評価
システム開発作業工程を進める上で重要になってくるのが、各工程上の作業の優先順位です。
ウォーターフォールモデルでの開発では、各工程を当初の計画通り順番に進めていきます。
そのため、どこかの工程で遅延やトラブルが発生した場合、その工程がボトルネック（クリティカルパス）となり、プロジェクト全体が停滞する原因となってしまいます。
そこで、アジャイルソフトウェア開発手法などの反復型開発手法では、各機能単位でのリリース毎に、優先度の再評価を行うことでこのリスクを軽減させる手法をとっています。
