システム開発における要件定義の進め方とは？事例から学んでみよう
システム開発の基礎知識
業務に関わるシステム開発において、要件定義が重要であることは言うまでもありません。
昨今では特にビジネスプロセスの変革や経営・事業に貢献するシステム構築が求められるようになり、その重要性はますます大きくなっています。
一般的に要件定義は、システムをビジネスに活用する当事者であるユーザー企業が自ら中心となって行うことが良いとされています。
とはいえシステムの専門家でもない限り、要件定義をユーザー企業のみで進めることは難しく、多くの場合、要件定義はユーザー企業とシステム開発ベンダーが協同で実施することになります。
そこで本記事では、これからユーザー企業の立場で要件定義を担当される方や、自社システムの導入や企画を担当される方へ向けて、要件定義の進め方、注意すべきポイントなどを解説します。
１．要件定義のシステム開発における必要性
システム開発において要件定義が重要なのはなぜでしょうか。
要件定義とは、開発するシステムに求められる機能（要件）を決めていく工程です。
要件定義の前工程には業務課題を解決するための企画フェーズが存在し、後工程にはシステムの設計フェーズが存在します。
要件定義では企画フェーズでシステム導入が必要となった目的や解決すべき課題から目をそらさず、具体的にシステムとしてどのような機能が必要かを検討、整理していきます。
要件定義で決められた事柄は、後工程である設計、開発、テストすべてにおいての指針になります。
後工程のシステム設計で判断に迷うことになった場合、要件定義でどのように定められていたかに立ち返ることが少なくありません。
要件定義がうまくいっていれば後工程をスムーズに進めやすくなる一方、要件定義がうまくいかないと後工程でもさまざまな問題が発生し、何度も要件定義をやり直すようなケースにもなりかねません。
２．システム開発における要件定義の成功事例と失敗事例
システムエグゼではこれまで多くのユーザー企業とともにシステム開発を行ってきました。
その経験から、特に初歩のポイントとなるような成功事例、失敗事例を紹介します。
成功事例
最適なプロジェクト体制を構築して総合的な合意形成を可能に
要件定義をする際、最適な体制を構築することが成功のための最初のポイントです。
要件定義は業務担当者のみでもシステム担当者のみでも、ましてや開発ベンダーのみでもうまくいきません。
これまでの経験から、経営層（に深く関わる方）、業務部門、システム部門、開発ベンダーが揃って、要件定義の期間中にボリュームにより異なるものの週1回程度の定例会を実施できると、うまく進められるという感触があります。
つまり、ひとつひとつの要件に対して最低でも経営視点、業務視点、システム運用視点、システム開発視点という複数の視点で要否の判断や実現可否、他業務、他システムへの影響を考慮していく必要があるということです。
このような視点で十分に検討、そして決定されたアウトプットは手戻りが起こりにくく、その後の工程でも明確な指針として機能します。
システム開発を行う範囲を明確にすることでプロジェクトの肥大化を防ぐ
要件定義が開始されると各ステークホルダーからさまざまな要望が出てきます。
プロジェクトではできる限り多くのステークホルダーから多くの要望や意見を集めることが重要です。
そして、成功するプロジェクトでは必ずその要望や意見の取捨選択を行います。
開発するシステムにおいて実現する機能や性能の範囲、レベルを明確にし、逆に実現しないものも明確にするということです。
この範囲、性能が明確であることが、その後の設計、開発でプロジェクトの肥大化を防ぎます。
システム開発はステークホルダーが増えることで要望が肥大化し、スケジュールやコストの増加原因になるケースが数多くあります。
範囲、性能レベルを要件定義で決めておくことはプロジェクトの成否を分ける重要なステップになります。
失敗事例
ユーザー企業側の時間がなく要件定義が進まない
要件定義はユーザー企業とシステム開発ベンダーが協同で実施することが多いと前述しました。
しかし、ユーザー企業の担当者の時間には限りがあります。
また、要件定義は開発ベンダーが行うものでありユーザー側の時間を割くものではないとして、そもそも時間を取っていないケースがあります。
そのような場合、何かを決めようとしても関係者が揃わない、開発ベンダーがドキュメントを作成してもユーザー企業側でチェックが進まないなどの問題が発生します。
当然、要件定義に想定以上の時間がかかり、スケジュールが遅延し、後工程も遅れていきます。
要件定義において、作業と名の付くものは開発ベンダーが対応することが多いのは事実です。
プロジェクト成功のためにはユーザー企業の担当者も確認、検討、社内関係者の合意を取り、意思決定をする作業に相応の時間を必要とします。
これから要件定義に参加される方はこの時間の考慮、確保をしておくことを強くお勧めします。
要件定義で考慮不足があるためテストケースが不足
いわゆるウォーターフォール型開発の場合、要件定義で決められた内容がしっかりとシステムに実装されたかの確認は、総合テスト工程で最終チェックされることになります。
要件定義が過不足なく完了していれば、その内容に沿ったテストケースを作るので、必要なテストが漏れることは考えにくいです。
ところが要件定義に不足があると、それがそのままテストケースの不足に直結します。
最悪の場合、実際に業務にシステムを利用し始めてから考慮不足に気づくことになります。
また、総合テスト時に要件定義の不足に気づいたとしても、そこから遡り要件定義を補修するのは大きな二度手間が発生します。
このように、要件定義はシステム開発の最後まで深く関わってくることを意識する必要があります。
３．システム開発の要件定義の進め方
一昔前までは、システム開発は全工程一括請負が一般的でした。
ところが現在、要件定義の工程は準委任契約で行うことが良いとされており、システムエグゼでもそのような進め方をお客様へお勧めしています。
これは成功のポイントでも述べてきたとおり、要件定義はユーザー企業とシステム開発ベンダーが協同で行うものであるからです。
要件定義はシステム開発ベンダーにお任せではうまくいきません。
要件定義における開発ベンダーの役割は、豊富な経験を基にユーザー企業に対し適切な助言等の支援を行い、後々のスケジュールや費用を考慮に入れた上で、要望、要件をシステム設計に落とし込めるレベルまで具体化、明確化することにあります。
これに対しユーザー企業はあくまで主体的に、自らの業務プロセス及び問題の理解、今後のあるべき姿を追求することが重要です。
その過程で課題が抽出され、取捨選択が行われます。
この時に重要となるのが開発ベンダー側の有能なプロジェクトマネージャーです。
予算に応じた機能の取捨選択をするに留まらず、さまざまなアイデアによってシステム開発の観点から課題の解決方法を提示します。
４．要件定義のポイント
本記事では、要件定義の進め方、ポイントとなるような点について記載してきました。
最後に、これまでの内容のポイントをまとめておきます。
- 要件定義はシステム開発の成否を決めるほど重要な工程という共通認識を持つ
- 要件定義はユーザー企業とシステム開発ベンダーが協同で進める
- 体制は経営層、業務部門、システム部門、開発ベンダーが最適
- システム開発の対応範囲、性能レベルを明確にし、取捨選択する
- ユーザー企業は主体的に要件定義に参加する
- ユーザー企業でも要件定義に関わる方は十分な時間を確保しておく
- ベンダー側に有能なプロジェクトマネージャーを選定することが重要
システムエグゼでは、長年にわたりさまざまなユーザー企業様と対話をしながらシステム開発を行ってきました。
その実績を支えてきた有能なプロジェクトマネージャーが多数在籍しています。
システム開発や検討の際にはきっとお役に立てると自負しています。
システム開発をご検討の際は、ぜひお声がけください。
