1分で分かる！システム開発における要件定義とは？
ねぇねぇ、ジャバ―ド先生、聞いてもいい？
ことりん君どうしたの？
提案っていう工程はよく分かったんだけどさ、もしその提案がクライアントに採用されたらどうなるの？
たしかに気になるところだよね。では、今日は提案の次工程である「要件定義」について教えるね。
お願いしますっ！
先生がことりん君にスマートフォンアプリの開発を発注したと仮定してみよう。作ってほしいアプリは「ジャバ―ド先生のかっこいい写真を共有できるアプリ」だよ！ことりん君は、つぎに何をすればいいとおもう？
ん～。よくわからないけど、早く完成させたいからプログラミングかな？？
じゃあ、プログラミングしているときに、先生が急に「やっぱり動画も投稿できるようにしたい」とか「投稿したものにコメントできるようにしたい」って言ったらどうする？
ジャバ―ド先生のこと嫌いになっちゃう！
もう少し優しい表現が嬉しいけど…。そうだよね。ことりん君は納期も迫っている中で、急にやることが増えると困っちゃうと思うんだ。でも、実際の開発現場で似たようなことがたくさん起きているんだよ。
え、ジャバ―ド先生たくさん嫌われたの？
えっと、似ているのはそこじゃないよ。例えば、クライアントは「この機能は必要だって言ったよね！」、エンジニアは「そんな話は聞いていない！」みたいに、言った言わないで、もめちゃうことがあるんだよ。
それはちょっと困っちゃうよね…。
そうなんだ。要件定義が必要な理由はそこにあるんだよ。要件定義は、アプリケーションが実現すべきこと（要件）について、きちんと定義してあげるという工程なんだ。つまり「このアプリケーションはこういう事ができるよ」っていうのを整理・資料化していく作業だね。要件定義をすることで、クライアントとエンジニアで実現するアプリケーションについて、共通認識をつくることができるんだ。
そっか！、要件定義をすればさっきみたいな「言った・言わない」のやり取りは防ぐことができるよね！そうすれば、ジャバ―ド先生も嫌われないで済むね！
例えばの話で、先生本当に嫌われてないからね…
要件定義とは？要件定義の基礎知識
要件定義の業務内容
要件定義とは、アプリケーションが実現しなければならない機能や、アプリケーションが達成しなければならない性能などを、1つずつ定義していく作業です。なお、アプリケーションが実現しなければならない機能は「機能要件」、アプリケーションが達成しなければならない性能は「非機能要件」といいます。
非機能要件には、セキュリティ、処理速度、障害発生時の復旧方法、ユーザーの使いやすさなどといった「機能」として定義できないものを指します。
要件定義の詰めが甘いと、後の工程に進んだあとにクライアントから「ほしいものと違う」「そんなことは言っていない」などと言われるリスクを抱えることになります。また、エンジニア側も、クライアントと事前に打ち合わせしていたにも関わらず、対応が漏れてしまうこともあるのです。
このような単純ミス、認識齟齬などを防ぐためには、きちんと要件定義をおこなうこと、そして作成した要件定義についてクライアントに確認してもらい、きちんと内容の合意を得ること（そのエビデンスを残しておくこと）が大事です。
要件定義に対するエンジニアの関わり方
要件定義は、エンジニアが主体となって作業をすすめます。要件定義を行うために必要となる情報は、提案工程と同様にRFPとなります。
※ 内部リンク：提案
エンジニアは、引き続きRFPの内容を元にしながら、システムに必要な機能などの求められるものを洗い出していきます。ただし、RFPだけではクライアントの業務がわからなかったり、情報が不足していることも多々あります。そのような場合は、随時クライアントから詳細内容をヒアリングすることも、エンジニアの重要な仕事の1つです。
特に、前述した「非機能要件」については、あまり意識していないクライアントが多いです。そのため、エンジニアが主導しながら、非機能要件を確定させていくケースも少なくありません。
また、最終的に要件定義の工程では、要件定義書といわれる成果物を作成します。エンジニアは、その資料も作成する必要があります。
