「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

順番に見ていきましょう。
まずは予備知識として「要件定義」と「プロセス」について説明します。
「そんなの説明されなくても知ってるよ！」な人は適当に読み飛ばしてください。

要件定義は「お客さまの要望を まとめる工程」です。
システム開発における最初の工程です。



システム開発において、スタートは お客さまの「何がしたいか」です。
自社サービスの場合は、社長とか発案者が お客さまの立ち位置になります。



ゴールは「できあがったシステム」です。



システム開発というのは、スタートの「何がしたいか」をゴールの「できあがったシステム」に変換する作業です。



とはいえ、一足飛びにゴールにたどり着くことは できません。
一歩一歩進んでいく必要があります。

最初にやるべき作業は、お客さまの「何がしたいか」を まとめることです。

お客さまだって人間です。
自分の言いたいことを きちんと伝えられるとは限りません。
あるいは、お客さま自身が自覚していない「やりたいこと」もあるはずです。

ですから、お客さまの実現したいことを詳しく聞き取ります。
そして「あなたが やりたいのは、こんなことだよね？」を お客さまと一緒にまとめます。
これができれば、後から「本当は こんなことを やりたかったのに！」と文句を言われる可能性も減るでしょう。

この

やりたいことを まとめる工程

が要件定義です。
「どんなシステムが欲しいのか？」もしくは、そもそもの話として「何をやりたいのか？」の認識を お客さまと作る人たちで合わせるために やります。



あと、ついでなので書いておくと、その後は

・基本設計
・詳細設計
（・プログラム設計）
・プログラミング
・単体試験
・結合試験
・総合試験

のような工程を経て、システムは完成します。



プロセスは、今回は「過程」とか「工程」とか「手順」とか「やり方」とか、そんな感じの意味です。



以上を踏まえて

要件定義の工程

が「要件定義プロセス」です。



ここまでの説明を読んで「つまり、要件定義のこと？どうして『プロセス』を付けるの？」と思う人もいるでしょう。

言葉の意味を素直に捉えたら、要件定義は

お客さまの要望を まとめたもの

です。
文字通り「要件」の「定義」が「要件定義」です。

例えば「要件定義書」という用語があります。
要件定義書は、お客さまの「こんなものが欲しいんだよね～」をまとめた資料です。



要件定義書は、文字通り「要件」を「定義」した「書（書類）」です。
この文脈では、要件定義は「お客さまの要望を まとめたもの」と解釈するのが自然でしょう。

ただし「要件定義（お客さまの要望を まとめたもの）を作る工程」を指して「要件定義」と表現していることも少なくありません。
むしろ、私の体感では「工程」を指して「要件定義」と表現していることが多い気がします。
例えば「まずは要件定義をやるよ。その次に基本設計をやるよ」の言い方を普通にします。



推測ですが、そこら辺の あれやこれやを気にした人が「これは工程（プロセス）だよ！」と強調するために、後ろに「プロセス」を付けたのだと思います。