要件定義に関するメモ

要件定義書とは、その内容を請負として発注したのならば、誰が実装したとしても問題ではなく、その定義書を満たしているか、満たしていないかを客観的に判断できるように、当該の開発依頼における要件を明確化したもの、と考えられる。

フルオーダーメイドなシステム発注の要件を全部書き下す必要があるため、発注側にリテラシーが求められることになるが、発注側は、必ずしもシステム開発について詳しい訳ではない。そのため、この要件を決定すること自体を、(おそらく)準委任でまた外部に発注する。

準委任された側は、善良な管理者の注意義務をもって、システム要件のまとめを行わなければならない。 何をやっていればこれを満たしたことになるのか、ということについて、 IPA が、要件定義プロセスについての、標準的なあり方を提示している。

ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ | 書籍・刊行物 | IPA 独立行政法人 情報処理推進機構

情報処理推進機構（IPA）の「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」に関する情報です。

www.ipa.go.jp

特に会社などの大きな組織がシステムを欲する場合、その開発要件は、複数人存在するステークホルダーたちの要求を、まとめて整理して優先順位をつけた上で、そのうち予算的に実現可能な範囲について、開発の要件としてまとめたものである必要がある。

ちょうど、プロジェクトマネジメント行為自体が PMBOK などのように標準化可能であるのと同じように、要件定義行為もある程度標準化が可能であり、その結果を上記 IPA の資料はまとめている、と考えられる。 特に、会社などが依頼する開発は、業務で利用するためのシステムである場合がほとんどであるため、上記資料はそれ前提のプロセス定義になっている模様。(ビジネスプロセスの分析などのプロセスがあることが見てとれるため) また、1点物を作るという意味で、要件定義自体がプロジェクト的であるため、プロジェクトマネジメント的な要素も、要件定義行為に含まれることになっている。

補足として、近頃流行りのアジャイルは、顧客が最も必要としている機能をインクリメンタルに開発していくことで、すべてを準委任で開発していく開発委託プロセスのこと、と理解できる。 (開発を他社に委託する場合)