システム開発プロジェクトは、要求定義や要件定義、そして設計や開発、テストを経て、ようやく運用に至ります。要件定義でシステムの要件が明確になっていないと、設計工程以降で仕様変更が頻発し、手戻りによるコスト超過やスケジュール遅延が発生してしまいます。そのためシステム開発プロジェクトにおける「要件定義」はプロジェクト成功の鍵を握る特に重要な開発工程と言えます。しかし、要件定義の重要性は理解していても、どう進めてよいのか分からず、苦手に感じる方も多いかと思います。この記事では要件定義の進め方について解説します。
要件定義とは
要件定義とはシステムで実装する範囲や内容（システム要件）を決定する開発工程です。システム開発工程の初期に実施する工程で、前後で実施する「要求定義」や「基本設計」と合わせて上流工程とよびます。企業の達成したい目標や理想像を実現するために、システムの開発範囲を明確にすることが要件定義工程のゴールです。システム開発は、要件定義で決めた内容に基づいて次工程に進んでいくので、開発工程における設計図を作る“最上流工程”であり、もっとも重要なフェーズです。
要求定義との違い
「要件定義」と「要求定義」は混同されることも多い工程ですが、厳密には異なる目的・作業内容の工程です。要件定義はプロジェクト開発における最上流工程とご説明しましたが、要求定義は要件定義よりも前に実施されます。また、要求定義はベンダーではなくユーザー企業・部門での作業範囲となります。要求定義ではユーザー企業・部門がビジネス戦略や目標を実現するためにシステムで実装したい要求事項を検討・整理します。要件定義は要求定義の内容を受けて、システム要件として落とし込む工程のことです。ユーザー側とベンダー側でシステム仕様についてしっかりと認識を合わせる必要があります。
成果物
要件定義工程での成果物は「業務要件に関わる成果物」と「システム機能要件に関わる成果物」に分類できます。企業やプロジェクトによって作成すべき成果物は異なりますが、代表的な成果物は以下の通りです。
業務要件に関わる成果物
業務フロー図、ビジネスプロセス関連図
システム機能要件に関わるもの
画面一覧、画面遷移図、帳票一覧、テーブル関連図、外部インターフェース定義書
要件定義工程での成果物は後続工程となる設計・開発工程のインプットとなる重要な成果物となります。
要件定義の進め方
要件定義の進め方は、企業やプロジェクトによって細かいプロセスが異なるものの、大枠としては以下の通りとなります。
- 業務要件の認識合わせ
- 要件の詳細化
- プロジェクト内容の決定
- 要件定義書の作成
各作業について解説していきます。
業務要件の認識合わせ
要件定義を決定するために、ベンダー側に要件を伝えます。要件の意図を正確に伝えるためのコミュニケーションスキルが必要になります。すでに要求定義が行われている場合は、要件についてベンダー側の視点で意見が出てくると思います。すべてが伝えた要望通りに進められるわけではないので、実現可能性についてこの段階でベンダー側と話し合います。この段階で、内容のすり合わせをしっかりと行い仕様について合意しておくことで、仕様変更が頻発したり、手戻りによるコスト超過やスケジュール遅延を防ぐことができるため、認識合わせは非常に重要です。
要件の詳細化
次は認識を合わせた結果を整理し、システム化すべき要件を検討しましょう。システム化しないといけないものは何か、要件をどう実現するのかの整理に多くの時間を割くことが重要です。現状の問題点、課題などを掘り下げ、解決策をこの段階で検討します。また、要求内容をもとにした機能要件だけではなく、性能やセキュリティなどの非機能要件の検討も忘れずに実施しましょう。機能要件へ関心が向きがちですが、非機能要件にも目を向け、意識的に検討することで、システムの満足度向上へもつながります。
プロジェクト内容の決定
整理したシステム要件をベースにどれくらいの工期・工数が必要になるのかをベンダー側で見積もられます。システム機能として求めるものを網羅的に洗い出せたとしても、プロジェクト発足時に想定していたスケジュールや予算をオーバーしてしまうこともあります。そのため、リストアップした要件に対して重要度や緊急度などで優先順位をつけながら対応範囲、スケジュール、予算などを定め、実行計画として確定させるのがポイントです。ここが曖昧なままだと、後続工程で手戻りが発生したり、予算追加やスケジュール遅延が発生したりと重大なトラブルにつながる恐れがあります。
要件定義書の作成
システム開発の要件が固まったら、要件定義書の作成が行われます。ここまで整理した内容がドキュメントに落とし込まれます。
要件定義書には以下の項目が記載されます。
- 概要と構想
システムの概要や、どのような仕上がりになる予定なのか、プロジェクトの全体的な概要と目的予想が記載されています。
- ユーザーの要求と必須要件
「こうして欲しい、この機能が欲しい」というユーザーの要望と、ベンダー側で出た必須要件を記載します。機能要件以外に、非機能要件など複数の要件がある場合は、カテゴリーで分けられていることが一般的です。 - 目標や目的
システムを導入する目的、それによって得られるメリットなどが記載されています。
作成された要件定義書をユーザー側でレビューを行い、問題がなければ要件定義工程の終了となります。
要件定義の重要性
この記事で「要件定義」は重要な開発工程と何度かご説明しています。その理由は、要件定義書は建築で言うところの設計図にあたるからです。全ての土台となる要件定義書にミスがあれば、大きな手戻りが発生します。またシステムのリリース後であれば、業務に支障をきたす場合もあります。システム開発を失敗させないために要件の細部まで、あるいは運用・保守に至るまでを要件定義工程でミスなく決定しなければいけません。このことから要件定義は難しいと言われています。しかし、逆に言うと要件定義さえしっかりしていれば、その後の開発が非常にスムーズに進むと言うのも事実です。つまり、システム開発は”要件定義で決まる“と言っても過言ではないのです。
まとめ
この記事では要件定義の進め方について解説しました。システム開発のプロジェクトを適切に進めるためにも、要件定義を正確に行うことが大切です。発注者とベンダーで密なコミュニケーションをとりながら、発注者の要求定義に沿った要件定義を作ることができれば、プロジェクトがうまく進行し、最適なシステムも作り上げることができるでしょう。この記事を参考に、要件定義で必要な作業や、重要性について理解を深めていただければと思います。
コメント