コンピュータ・システムやソフトウェアやアプリケーションの開発は、必ず要件定義から始まります。もしくは、要件定義の準備から始まります。
要件定義がシステムなどをつくるときのスタート地点になるのは、この仕事を終えないと作業に着手することも作業を終えることもできないからです。
要件定義は、システムを使うクライアント（システムの発注者）の要求を盛り込んだものです。そのため要件定義に失敗すると、完成したシステムが使いものにならなくなる恐れがあります。
要件定義がどのようなもので、要件定義をつくるのにどのようなスキルが必要になるのかなどを解説します。
アプリ・システム開発のプロが開発のお悩みを解決します
アプリ・システム開発の6割が失敗すると言われています。クライアントのリピート率100%のリレイスにご相談ください。
＼ まずは無料相談！1営業日以内に返信 ／
目次
要件定義とは
自社で使うシステムを自社でつくることもありますが、ここでは、システムを必要としている企業（クライアント企業）が、システム開発会社に製作を依頼するケースを考えていきます。
システム開発は、クライアントがシステム開発会社に「こういうシステムをつくって欲しい」と依頼することから始まります。
「こういうシステム」とは、システムに搭載する機能や性能になります。
要件定義は、システム開発会社とクライアントが話し合って、システムに搭載する機能や性能などを決める作業です。
要求を明確にして仕事の進め方を決めること
クライアントはこれからつくってもらうシステムについて、さまざまな要求があるはずです。しかしそれらの要求をすべてシステムに盛り込むと、開発費が莫大なものになったり、納期がかかったりしてしまいます。
そこで要件定義という作業のなかで、システムに盛り込むべきクライアントの要求を明確にしていきます。
プログラマーのなかには要件定義のことを、クライアントの要求を整理する作業ととらえている人もいます。
要件定義ではさらに、開発工程や作業フロー、業務シナリオもつくっていきます。仕事の進め方を決めることも要件定義に含まれます。
要件定義は、システム開発の設計図とスケジュール表を作成する作業です。
要件定義ができたら、あとはシステム設計（コーディングやプログラミングなど）→実装→テスト→完成という手順で進みます。
要件定義と要求定義の違い
要件定義と似た作業に要求定義があります。
「要求」という言葉は「クライアントの要求」といったように使われます。クライアントが最初に提示する「こういうシステムにして欲しい」という内容のことを要求といいます。
要求定義は、クライアントの要求を整理する作業になります。
要求定義ができたら、さらに内容を詰めていきます。その作業が要件定義になります。
要求定義は要件定義の前段階の作業です。
要件定義書とは
要件定義書は要件定義した内容を盛り込んだ文書（ドキュメント）で、とても重要な書類になります。
要件定義書の役割
要件定義書には次の内容を書き込みます。
■要件定義書の内容
●機能●画面●帳票●情報とデータ●インターフェース●ユーザビリティとアクセシビリティ●システム方式●規模・性能・拡張性など●情報セキュリティ●テスト●運用や保守●スケジュール●その他
要件定義書が「設計図とスケジュール表」であることがわかると思います。
要件定義書は、要件定義を元にシステム開発会社がつくり、クライアントにみせます。クライアントがこれを受領すれば、システム開発会社はこのとおりのものをこのとおりにつくることになります。
ポイントは「このとおりのものをこのとおりにつくること」です。
要件定義書をつくることでクライアントは、求めていたシステムを手に入れることができる、と期待できます。また開発工程もわかるので「ちゃんとつくってもらえる」と期待することもできます。
さらに、要件定義書があれば、思っていたものと違うものができてしまったときに、クライアントは「要件定義書とおりのものではない」とシステム開発会社に伝えることができます。
一方、システム開発会社は、要件定義書があればここに書かれてないものはつくらないで済みます。これから始める作業の内容を確定することができるのでコストがわかります。また、システムが完成したときにクライアントから「思っていたのと違う」といわれても、「要件定義書とおりのものです」と説明することができます。
このように要件定義書は契約書と同じくらい重要な書類といえます。
要件定義書をつくる際のポイント
要件定義書をつくるときは、 1 ）具体的で明確なヒアリングを実施する、 2 ）要求を細分化する――の 2 点に注意しましょう。
具体的で明確なヒアリングを実施する
適切な要件定義書をつくるには、適切な要件定義が必要で、適切な要件定義は、具体的で明確なヒアリングがないと実現しません。つまりシステム開発の担当者は、クライアントからしっかり聞き取らなければなりません。
ここで次のような疑問が湧くと思います。
●要件定義がクライアントの要求がベースになっているなら、クライアントに要求を出してもらえばそれで済むのではないか
それはそのとおりなのですが、システムについて詳しくないクライアントは少なくありません。というよりほとんどのクライアントは「この業務をシステム化して効率化させたい」という要望は持っていても、システム開発に必要な情報をシステム開発会社にどのように提供すればよいのか知りません。
そこでシステム開発担当者のほうからクライアントにしっかり尋ねなければならないわけです。
要求を細分化する
要件定義の要件はクライアントの要求がベースになっているので、要求を整理しないと要件定義はできません。
要求の整理は細分化することで可能になります。
要求の細分化でよく行われているのは、必須要求と希望要求にわけることです。
システム開発担当者は、クライアントがシステムを使って何をしたいのかを把握します。それを把握すればクライアントの数多（あまた）ある要求を、必ず要件定義に掲載しなければならない必須要求と、可能であれば掲載する希望要求にわけることができます。
必須要求と希望要求は、要件定義のなかでは必須要件と希望要件になります。
必須要件と希望要件は複数個挙がるので、重要度と優先順位をつけます。
重要度と優先順位をつけることで、作業の順番が決まってきます。作業は例えば「重要度高＋優先順位高」→「重要度低＋優先順位高」→「重要度高＋優先順位低」→「重要度低＋優先順位低」の順に進めることができます。
要件定義に必要なスキル
システム開発に携わるプログラマーやエンジニアなどは、要件定義をつくるのに必要なスキルを身につける必要があります。
ここでは次の 4 つのスキルを解説します。
■要件定義をつくるのに必要なスキル
●顧客の意図を読んで要求を引き出すスキル
●システム設計のスキル
●ドキュメント作成のスキル
●スケジュール管理のスキル
顧客の意図を読んで要求を引き出す
実際にシステムを使うことになる顧客やクライアント、ユーザーの意図をつかめるかどうかはシステム開発の根幹をなす作業といえるでしょう。
完成したシステムに必要な機能や性能が備わっていなければ使えないものになってしまいます。不要な機能や性能を載せてしまうとコスト高ものになってしまいます。ユーザーの意図を正確に把握してシステムをつくっていかなければなりません。
ユーザーの意図をつかむには、コミュニケーション・スキルが欠かせません。システムに詳しくないクライアントであれば、極力専門用語は避けて平易な言葉で説明することになります。システムに詳しいクライアントであれば、そのレベルに合わせた会話が必要になります。
クライアントが言葉に発する要求だけでなく、潜在的な要求も引き出していくことが理想です。
システム設計のスキル
要件定義の段階でもシステム設計のスキルが必要なのは、要件定義の段階で、クライアントの要求や要件が実現可能なのかどうか判断しなければならないからです。
要件定義や要求定義の打ち合わせをするとき、クライアントは「このようにできるといいのですが可能ですか」と尋ねてくるはずです。それに対してシステム開発担当者は「可能」「不可能」「可能だがコスト高になる」と回答したいものです。
ドキュメント作成のスキル
ドキュメントとは文書という意味で、要求定義でのドキュメントの最終形が要件定義書になります。
要件定義書は、要するに要件定義を可視化したものです。したがって、クライアントとシステム開発担当者で詰めて完成した要件定義は、要件定義書にすることで初めて関係者で共有することができます。
要件定義書がいい加減なものになってしまったら、開発チームのメンバーにクライアントの要求が伝わらないことになり、せっかく質の高い要件定義ができても水泡に帰してしまうでしょう。
スケジュール管理のスキル
システム開発には必ず締切や納期があり、締切と納期があれば必ずスケジュールが要ります。
そして、これからつくるシステムの規模が大きくなるほど、さらに、システム開発チームのメンバーが増えるほど、スケジュールの重要性は増します。「ちゃんとした」スケジュールが組めないと作業が混乱して、無理と無駄が発生してコスト高になり、システムの質にも影響します。
システム開発は分担作業であり流れ作業であり、前工程と後工程があるので、「ちゃんとした」スケジュールがあって、スケジュール管理がしっかりしていれば、無理も無駄も出さすにスムーズに終わらせることができます。
まとめ～スタート地点でありゴールも決める
要件定義はシステム、ソフト、アプリ開発のスタート地点であり、完成品の成否すら左右します。なぜなら要件定義はシステムを必要としているクライアントの要求を聞くことから始まり、「こういうシステムをつくる」ということを決める作業だからです。
クライアントの多くは、システムに詳しくありません。システムでできることもできないこともわかっていないクライアントは、自分たちの要求をうまく伝えることができません。
そのためシステム開発担当者は、クライアントから要求を引き出さなければなりません。
クライアントが望むことをすべて要件定義書に盛り込むことができたら、要件定義は成功したといえるでしょう。
