システム開発が失敗する原因として、一般的に「要件定義が不十分だった」という指摘がよく挙げられます。日本情報システム・ユーザー協会の調査でも、遅延や予算超過の主な理由として「要件仕様の決定遅れ」や「要件分析の不足」が指摘されています。しかし、システムそのものが廃棄されるような大きな失敗の場合、その根本的な原因は要件定義だけではなく、もっと深い問題に起因していることが多いのです。
業務システム開発の基本的なプロセスは、以下の通りです：
1. 業務要求
システムを導入・開発する際に解決したい課題や達成したい目標を具体化したものです。これは、現場や経営者がシステムに何を期待するかを明確にする出発点となります。
2. 要件定義
業務要求をもとにシステムで実現すべき機能や性能を詳細に整理し、具体的な仕様を決定するプロセスです。これがシステム開発の土台となり、開発の成否を大きく左右します。
3. 設計
要件定義で決まった内容を基に、システムの構造や画面、データベースなどを詳細に設計します。このプロセスでは、開発者がスムーズに作業できるよう仕様を具体化します。
4. 開発
設計をもとに実際にプログラムを作成し、システムを構築するフェーズです。コードを書く作業だけでなく、データベースの構築や外部システムとの連携設定も含まれます。
5. テスト
開発したシステムが要件を満たしているか、設計通りに動作するかを確認する作業です。バグや不具合を見つけて修正し、システムの品質を保証する重要なプロセスです。
通常の開発プロセスでは、要件定義が適切に行われればスムーズに進行すると言われています。しかし、要件定義自体は業務要求を基に作られるため、業務要求が安定していない場合、完成したシステムが企業のニーズに合わないという事態が起こり得ます。これが「使えないシステム」が生まれる原因です。
部門システム時代と現代の全社システムの違い
かつての部門システムでは、利用者は特定の部門だけであり、対象業務が限られていたため、業務要求が安定していました。このため、システム担当者がヒアリングを通じて業務要求を整理すれば、問題のないシステムを開発することが可能でした。
しかし、ERP（全社統合システム）の登場により、状況は一変しました。関係者は経営者から各部門まで多岐に渡り、対象業務も会社全体に広がりました。その結果、業務要求が部門間で異なり、複雑で不安定なものになったのです。
単に各部門の要求を集めるだけでは、全社システムの業務要求としては不十分です。部門間の要求や利害の衝突を解消しないまま業務要求を決定すると、開発中やシステム稼働後に衝突が顕在化し、要件定義の変更や予算超過、システムバグの多発といった問題が発生します。
システム成功の鍵：システム構想
業務システムを成功させるためには、部門間の要求や利害の隠れた衝突を顕在化し、解消することが重要です。このプロセスを「システム構想（システムデザイン、上流工程）」と呼びます。
システム構想の具体的な作業として、関係者が一堂に会し、議論を通じて隠れた問題を発見し解決することが挙げられます。ヒアリングだけでなく、関係者自身が意見を交換しながら、全社最適化の視点で業務要求を考えていくことが求められます。
このとき重要となるのが、次の4つの視点でバランスよく議論を進めることです：
1. 経営の視点
システムを経営の武器とするために、経営者や経営企画部は、業績や資金情報をタイムリーに把握することを求めています。
2. 会計の視点
経理部は仕訳の作りやすさ、検証のしやすさ、支払や入金確認の効率化を重視します。
3. 業務の視点
現場部門は、システムの使いやすさや業務の効率化、省力化を期待します。
4. システムの視点
情報システム部は、予算や期間を考慮しながら現実的な手段で業務要求を実現する必要があります。
システム構想の成果
システム構想によって業務要求を安定化させることができれば、その後の要件定義で大きな見直しが発生することはなくなります。これにより、システムを当初の計画どおりに安全かつ効率的に開発することが可能になります。
全社システムの導入においては、単なる要求の寄せ集めではなく、部門間の隠れた衝突を解消し、全社最適化の視点で業務要求をまとめるプロセスが不可欠です。このプロセスを適切に行うことで、企業全体にとって価値のあるシステムを構築できるのです。
システム開発を成功に導くために、今一度システム構想の重要性を見直してみませんか？