【徹底解説】要件定義とは、外部設計との違い

要件とは

要件定義の解説前に、まずは要件とは何かについて解説します。

ITシステム開発における要件とは、実際に実現する事です。要件は、要求を基に定義します。

次に、ITシステム開発における要求とは、システムの買い手・利用者の「こういうことがしたい」という希望です。

ITシステム開発では様々な制約があります。金銭的な制約もあれば、納期の制約もあります。出てきた要求を全て実現できれば良いですが、制約によってはそれが無理なケースも多いです。

そのため要求を洗い出したら、そのあとは制約を踏まえて「実際に実現する事」を決める＝要件を決める必要があります。

要求・要件は、ビジネスレベル・業務レベル・システムレベルに分かれてそれぞれ定義されます。

ビジネスレベルでは、事業としての要求・要件を定義します。例えば売上や投資利益率を改善する等です。ビジネス要求を定義したら、制約を踏まえてビジネス要件を定義します。

業務レベルでは、ユーザーの行動レベルでの要求・要件を定義します。これは上記で定めたビジネス要件を達成するための要求・要件でなければなりません。例えば、売上の停滞理由は営業の客先訪問率の低さにあるが、営業は事務業務のとある箇所に時間を取られすぎて客先訪問に集中できないためその業務を効率化する等です。業務要求を定義したら、制約を踏まえて業務要件を定義します。

システムレベルでは、システムとして何をするかの要求・要件を定義します。これは上記で定めた業務要件を達成するための要求・要件でなければなりません。例えば、業務のとある箇所を改善するためにシステムでこういう機能を実現する等です。システム要求を定義したら、制約を踏まえてシステム要件を定義します。

要件定義とは

要件定義とは、要件を決めることです。

しかし「決める」と言っても、お客様ありきの仕事では単に自分の中で意志決定するだけでは終わるものではありません。定めた要件がわかる成果物があることと要件についてのステークホルダーとの合意が最終的には必要となります。

ITシステムの開発プロジェクトの失敗理由のひとつとして、要件定義の失敗がよく挙げられます。単純に決めた要件の質が低いこともあれば、合意できていないステークホルダーがいたためにトラブルとなることもあります。

外部設計との違い

要件定義よりもう一段具体度の高い作業ステップとして、外部設計があります。

要件定義が最終的に何が実現出来れば良いかを決めるのに対して、システム開発における外部設計はそれを実現するためのシステムの振る舞いを決めます。例えば画面や操作方法等です。

しかし、現実的には会社によって言葉の指す範囲が異なる可能性はあり得ます。実際に仕事で成果物を作る際には、その会社の相場を理解しそれによって両者を分割することは必須となるでしょう。自分としての見解は持ちつつ、コミュニケーションのために柔軟に対応していくのが良いでしょう。

https://envader.plus/article/55

成果物

要件定義の成果物を何とするかについては統一的な見解があるわけではありません。しかしIPAが提供する「ユーザのための要件定義ガイド」が「要件定義ドキュメント」と称して要件定義の成果物を定義しており、ベンチマークとなるでしょう。（参照先：ユーザのための要件定義ガイド 第2版）

ステークホルダーとの合意

成果物はその内容をステークホルダーと合意する必要があります。

ステークホルダーとは対象プロジェクトの利害関係者です。プロジェクトとの利害関係はプロジェクトごとに違うため、プロジェクトが立ち上がる都度洗い出す必要があります。

ステークホルダーと要件を合意していなければ要件の是非を問えず要件定義が無意味化し、ステークホルダーに漏れがあればトラブルの危険があります。この合意を経てようやく要件定義が完了したと言えます。

誰が、いつ、どう要件定義するか

責任者と主体

要件定義には、責任者と主体がいます。責任者とは「この要件定義の内容で問題ない」と最終的に承認する者であり、主体とは実際に要件定義を行う者です。

自社開発であれば言わずもがな両者を自社が担うことになります。

一方で受託開発であれば、責任者と主体にズレがあります。この場合、責任者は顧客となります。要件定義とは、飲食業で言えば注文内容であり、注文内容の正確性に責任を持つのが注文者というのは当然です。しかし要件定義の主体は顧客と開発企業の両方です。顧客はITのプロではない以上、開発企業も主体的に要件定義を行わなければ、プロジェクトはほとんど確実に失敗するでしょう。

また、最終的な責任者は基本的には顧客ですが、それを理由に開発企業がプロとしての水準を満たさない仕事をした場合、開発企業側も責任を負うことになる可能性はあり得ます。詳細は記事「【徹底解説】非機能要件とは何かについて完全に理解する」の「専門家の責務としての暗黙の要件」をご参照ください。（参照先：【徹底解説】非機能要件とは何かについて完全に理解する＞専門家の責務としての暗黙の要件）

要件の変更を許容するか

要件が定まるタイミングついて、論点となることは2点あります。「いつ決めるか」「決まった後に変更を許容するか」です。

まず「いつ決めるか」ですが、要件定義は開発の最初期に行われるべきです。なぜならシステムの挙動も実装も、要件によって決まるからです。要件とは「何を作るか？」であって、それが決まっていない段階でモノを作ることはできません。

次に「決まった後に変更を許容するか」についてです。

当然ですが、「許容せず、最初に決めた内容で開発する」のが最も望ましいことは言うまでもありません。これは俗にウォーターフォール開発と呼ばれます。ただしこれには条件がつき「最初に決めた内容が正しければ」という但し書きがつくでしょう。では、最初に決めた内容が正しくなかった場合はどうなるのでしょうか。そもそも最初に正しい内容を決め切ることなど無理であればどうすべきでしょうか。正しくないと判明したにもかかわらず開発を続けるべきでしょうか。

「現実的に最初に正しい要件を定め切るのは難しく、要件定義フェーズ以降も要件定義の変更可能を認める」という立場がアジャイル開発です。こちらではビジネス上必要とあれば要件を次々に変更していきます。

しかし当たり前ですが、納期やスコープに変化がない状況で要件ばかり変えていたらプロジェクトは立ち行かなくなります。アジャイル開発は納期等の制約への変更なしに要件定義を可能にする魔法の杖ではありません。間違っていた要件＝実現しても無価値なものを実現するぐらいであれば変更すべきであり、素早く価値検証することでその誤りを早期検知しようというスタンス・方法論でしかありません。

そのためこれらの開発体制には契約内容が関わってきます。契約の種類は多くありますが、ここで問題となるのは請負契約と準委任契約です。非常に簡略化すると、前者は完成物に対する責任を負う契約で、後者は工数に対する責任を負う契約です。要件定義で言えば、前者は完璧な要件定義に対して責任を負うことになり、後者は要件定義を行う工数に対して責任を負うことになります。

つまり、アジャイル開発をしたいのに請負契約をしてしまった場合、開発企業は要件の変更がどれだけあっても無償でそれに対応しなければならなくなります。これはビジネスとして現実的とは言い難いでしょう。そのため、アジャイル開発であれば基本的には準委任契約でいくべきです。もし請負契約でやるのであれば、そもそも要件の変更を認めない（アジャイルとはしない）か、相当なバッファを見込んだり、要件変更時の対応について現実的な方策を契約で合意するしかないでしょう。

要件をどう定めるか

要件定義のためにはまずは顧客の要求をヒアリングするところから始めます。

しかし顧客が言う要求が常に正しいとは限りません。要求内容自体が正しくない可能性がありますし、仮に要求内容が正しかったとしてもその表現が正しくないため開発側が取り違えていたりする可能性があり得ます。前者であれば「なぜそれがしたいのか？」を問うことで、より根源的な欲求を探る必要があるでしょう。コンサルティング業界でしばしば言われる「顧客が欲しいのはドリルではなく穴である」というような話がありますが、手段ではなく目的を把握することでより良い手段を検討できる可能性があります。後者であれば自分なりの整理や他事象との矛盾の検討等によって、顧客と認識をすり合わせる必要があるでしょう。

定められた要件は最終的には文章として成果物化する必要があります。これは曖昧さのない表現で記述される必要があります。2つ以上の意味に解釈できる場合、認識にズレが起き得ます。しばしば「エンジニアに必要なのは日本語の力」といったことが言われますが、要件の記述に必要であることがそう言われる理由のひとつと言えるでしょう。