「要求」と「要件」の違い

ユーザーからの希望や願いは、しばしば「要求」や「要件」という用語で表現されます。多くのＩＴ企業ではどちらかしか使わず、しかもどちらの意味で使っているのかがあいまいなことが多く散見されます。

ですが、実際にはこれら「要求」と「要件」という言葉はまったく異なる意味を持っているものと定義して開発に向き合わないと、プロジェクトの失敗比率が数割上昇します。

要求とは
　　漠然とした希望や願い、思想、経営上期待している成果など

要件とは
　　機能・非機能を含めたシステムに対する実現すべき定義

のことを意味しています（ちなみに英語ではすべて「Requirement」で統一されており、「要求」と「要件」の厳密な違いを意識することはありません）。

なぜ「要求」と「要件」の区別が重要なのか。

それは、そもそもビジネスとＩＴには根本的矛盾があるため、まずビジネスとＩＴの２つの側面から、ユーザーの要望を切り分けることが必要とされているからです。その根本的な矛盾とは、ビジネスとＩＴで

　「情報のとらえ方」

がまったく異なるということにあります。

ビジネスで扱う「情報」とは、あらゆるデバイスやリソース、環境の中に分散しているコンテンツのことであり、ビジネスプロセスの中で必要になるモノ…対象物をさしています。

対してＩＴ側で語られる「情報」とは、基本的に「データ」であり、「インフォメーション」、あるいは昨今のご時世だと「インテリジェンス」のことをいいます。そのデータやインフォメーション、インテリジェンスが、どういう場面で誰に対し有用な“情報”となり得るかは、そのビジネスプロセスのコンテクスト（文脈）に依存します。

そのコンテクストを切り分け、データを“情報”として扱えるようにするのがビジネスシステムの役割となるわけです。つまりシステム開発とは、

ビジネス全体の中で必要な情報と、システムで切り出す情報とを分け、
さらにシステム要件を詰めて実装に落とし込む作業であり、
漠然とした大きな“要求”の中に、ＩＴ実装に必要な“要件”が隠れている。

ということになります。実装に必要となる要望…つまりニーズを、ユーザーの拙い言葉から見いだしていく根気のいる作業が必要で、そこで課題となるのが

　「要求をいかに引き出すか」
　「要求をいかに可視化（定義）するか」
　「要求をいかに管理するか」

という３点であり、この作業をある単位でまとめると”要件定義”というフェーズになるわけです。

中には、ついつい要件定義フェーズでフライング気味に設計をしている企業やエンジニアもいます。それ自体が悪いことだと断定するつもりはありませんが、「何を作るか」というプロダクト脳よりも「何が解決して欲しいのか」というサービス脳で考えようとしない限り、お客さまが真に望む満足にはたどり着けないかもしれません。

先述の通り要件定義と呼ばれるフェーズ、あるいはプロセスと呼ばれる作業の中では大きく３つの課題が存在します。

　「要求をいかに引き出すか（=抽出）」
　「要求をいかに可視化するか（=整理）」
　「要求をいかに管理するか（=管理）」

この３つを満たす作業を構築しなければ、次フェーズに進んでも満足のいく設計作業ができず、確実に手戻りが発生することになりかねません。

仮に手戻り作業が発生しなくても、それは問題や課題に気付かずに作業が進んでいるだけであり、システムテスト工程以降にユーザーの目に留まることで必ず大きな問題となって襲い掛かるでしょう。

これはシステム開発プロジェクトにおいて、マネジメントが不得意なエンジニアがよく経験するトラブルの１つです。

仕様変更、あるいは"仕様通りでない"と言う問題でユーザーと揉めるケースの多いプロジェクトではしばしばこういった事例が見受けられます。では、この３つの課題を実際に達成するための作業とはどのように構成されるのか、またその作業プロセスごとにどのような成果物を残し、次のフェーズに引き継いでいくべきなのか考えなければなりません。

要求をいかに引き出すか（=抽出）

ＩＴアーキテクトに必要な資質として「コミュニケーション力の高さ」が挙げられますが、この能力が発揮されるのがまさにこの「要求管理」の分野においてではないでしょうか。こうしたヒューマンスキルは本人の性質に依存することが大きいので、仕組みとして取り扱うには難しい部分ですが、コツさえつかめば得意／苦手に関わらず、要件定義において必要とされるコミュニケーション力を高めることは十分可能です。

重要なポイントは