ざっくりと要件定義とは
- システムの目的と機能を明確にする
- クライアントと開発者が共有する基盤
- プロジェクトのリスクを減らす
要件定義とは、システムの目的と機能を明確にする行為です。
概要説明
要件定義とは、システム開発の初期段階で行うプロセスである。なぜならば、この段階でシステムの目的や必要な機能を決めるからだ。
例えば、オンラインショップなら商品の表示方法や決済方法を決める。そして、これが明確でないと開発が進まない。
つまり、要件定義はプロジェクトの成功のための基盤である。だから、非常に重要。
職業職種
プロジェクトマネージャー
プロジェクトマネージャーは、要件定義を主導する。なぜなら、プロジェクトの全体像を把握する必要があるから。例えば、タイムラインや予算の設定。
システムエンジニア
システムエンジニアは、要件定義を具体化する。なぜなら、技術的な観点からシステムの機能を設計する必要があるから。例えば、データベースの設計。
クライアント
クライアントは、要件定義において要望を出す。なぜなら、最終的なシステムが自分たちのニーズに合っているか確認する必要があるから。例えば、特定の機能の追加。
要件定義は、名前の由来は「必要な条件(Requirements)を明確に定義する」からです。
要件定義の代表例
IBM
IBMは、要件定義で有名である。なぜなら、長い歴史と経験を持ち、多くの大規模プロジェクトでその技術を証明しているから。例えば、Watsonやクラウドサービスなど。
Atlassian
Atlassianは、要件定義で名高い存在である。なぜなら、JiraやConfluenceなどのツールを提供し、要件定義プロセスを効率化しているから。例えば、Jiraの要件管理機能。
Ken Schwaber
Ken Schwaberは、要件定義で世間に知られている。なぜなら、Scrumフレームワークの共同創設者として、アジャイルな要件定義に多大な影響を与えているから。例えば、Scrumガイドや著書。
手順例
以下は、要件定義の基本手順です。プロジェクトの目的を明確にする
目的を明確にすることは基本である。なぜなら、目的が不明瞭だと要件もぼやけるから。例えば、新しいウェブサイトの目的が「売上向上」なら、それを基に要件を考える。
ステークホルダーとコミュニケーションを取る
ステークホルダーとのコミュニケーションは必須である。なぜなら、彼らの要望や問題点を理解する必要があるから。例えば、顧客や開発者、マネージャーとのミーティング。
要件をドキュメント化する
要件をドキュメント化することで、後で確認できる。なぜなら、口頭での合意は忘れやすいから。例えば、要件定義書や仕様書の作成。
要件を優先順位づけする
優先順位をつけることで、効率的に開発できる。なぜなら、すべてを一度にやるのは非効率だから。例えば、必須の機能から開発を始める。
定期的にレビューを行う
定期的なレビューは、プロジェクトを健全に保つ。なぜなら、進行中に新たな要件や問題が出てくる可能性があるから。例えば、スプリントレビューなど。
類似語
仕様書
仕様書は、要件定義の類似語である。なぜなら、どちらもシステムやソフトウェアの設計に必要な情報をまとめるから。例えば、機能や性能を詳細に記述する点。
プロジェクト計画
プロジェクト計画は、要件定義の類似語である。なぜなら、プロジェクトの目的やスケジュールを明確にする点で似ているから。例えば、タイムラインやマイルストーンの設定。
ユーザーストーリー
ユーザーストーリーは、要件定義の類似語である。なぜなら、アジャイル開発でよく使われ、要件を短くシンプルに表現するから。例えば、”As a [user type], I want [an action] so that [benefit/value].”という形式で要件を表す。
反対語
即興開発
即興開発は、要件定義の反対語である。なぜなら、計画や設計をせずに開発を始めるから。例えば、アイデアが出たらすぐにコードを書く。
アドホック
アドホックは、要件定義の反対語である。なぜなら、特定の問題を解決するためだけに作られ、将来の拡張性や再利用性が考慮されていないから。例えば、一回きりのプロジェクト。
無計画
無計画は、要件定義の反対語である。なぜなら、何も計画せずに行動するから。例えば、目的もなくコードを書く。
要件定義の注意点
要件定義を行う時の注意点はコミュニケーションである。なぜならば、ステークホルダーとしっかり話し合わないと、本当に必要な要件が見落とされる可能性があるからだ。例えば、顧客が求める機能を見落とすことである。そして、後で修正する手間が増える。だから、しっかりとコミュニケーションを取る。
要件定義と仕様書は、間違えやすいので注意しましょう。
要件定義は、システムが何をしなければならないかを決めるです。
一方、仕様書は、それをどう実現するかを詳しく書くです。
コメント