一般的にシステム開発は、
(1)要件定義
(2)基本設計(外部設計)
(3)詳細設計(内部設計)
(4)製造
(5)単体テスト
(6)結合テスト
(7)総合テスト
(8)検収
(9)本稼動
の工程で進んでいきます。
注1)ウォーターフォールやプロトタイピングなど様々な開発方法論がありますが、ここでは方法論を解説するのではなく、ユーザ企業の方にシステム開発はどの様な手順を踏むのかを理解していただく事を目的に記述します。
注2)上記の工程以前にユーザ企業が行わなければならない重要な事は山ほどあります。
それでは、システム開発の各工程でユーザ企業はどの様なことに留意すべきかを考えて見たいと思います。
まずは、要件定義です。
ユーザ企業がシッカリとした要件定義を作成し、ベンダーに明示したとしても、必ずと言っていいほど、ベンダーから示されるシステム開発工程のスケジュールに要件定義の工程が組み込まれています。
- 提案依頼書(RFP)に要件を明記したとしても、ユーザの想いを全て把握する事は困難であり、ユーザ企業の想いや所望するシステムに対する考えを正確に把握するため。
- システム化の範囲を明確にするため。
- システム化対象となる業務を理解するため。
- ユーザ企業から要求される事項を、どの様にシステムへ実装すべきか(システム開発の視点)を明確にし、システム設計工程へ繋げるため。
など、いろいろと理由はあるでしょう。
そもそも 『機能要件』と『処理要件』は違うはずです。
ユーザ企業が示す要件は『機能要件』であり、業務的な視点に重点をおくべきでしょう。
ベンダーがユーザ企業の代わりに『機能要件』を定義することに無理があるのです。ベンダーがユーザ企業の事を熟知していて、業務的な視点でのアドバイザーであれば別ですが。
だからこそ、ユーザ企業は提案依頼書(RFP)で『機能要件』を明示すべきなのです。
ベンダーの要件定義は、どちらかと言うと、『処理要件』であり、コンピュータ的な視点です。
『機能要件』を掘り下げて『処理要件』を確定し、ユーザ企業のやりたい事を、漏れなくシステムへ実装する。
つまり、ユーザ企業がシステム化について十分な検討を行わないと言う事は 『納期遅延』 『開発費の増加』 『システムへの未実装』 などを引き起こす原因と言われる所以です。
『機能要件』 に記載されない事を 『処理要件』 として定義されるはずもないのですから。
この段階での留意点として、ユーザ企業は十分にシステム化の検討、要件定義(機能要件)を行い、ベンダーが正確に把握し、的確にシステムへ実装されるかを注意深くチェックすることです。
ベンダー企業に対して、やりたい事を伝える時間を惜しんだら、後で後悔する事になります。
当社は、顧客の立場に立ち、IT化・システム化戦略の企画・立案および推進、課題解決をご支援させていただいておりますので、お悩み事やお困り事をお持ちのユーザ企業様、お気軽にご相談ください。