要件定義とは、システム開発の最初に、最重視して取り組むべきプロセスです。
また、要件定義は、ベンダー（受注側）とクライアント（発注側）双方が最適な取り組みをしなければならず、さらに相互理解し認識の違いがない状態までもっていく必要があります。
しかし、ベンダー（受注側）とクライアント（発注側）の考え方の相違がある要件定義でシステム開発が進行していってしまう可能性があります。
その原因とのひとつが、ベンダー（受注側）とクライアント（発注側）の知識と経験の差です。
クライアント（発注側）は、ベンダー（受注側）に比べて、システムに関する専門的な知識は、持ち合わせていません。
一方で、クライアント（発注側）にとっては当然のことでも、ベンダー（受注側）は事業内容や業務内容などの基礎知識を落ち合わせていないことも多くあります。
クライアント（発注側）は、そのことに注意して、要件定義をすすめる必要があります。
クライアント（発注側）は、要件定義をベンダー（受注側）に任せてしまうことなく、共同して要件定義を進めていく重要な仕事であることを認識しなければなりません。
そのうえで、ベンダー（受注側）に、要望をわかりやすく伝えることが重要です。
要件定義では、ベンダー（受注側）とクライアント（発注側）の双方でどのような点に注意すべきなのでしょうか。
そこで、今回は、要件定義の進め方や、やるべきこと・注意点をまとめます。
要件定義とは？
要件定義とは、ひとことでいうと「発注側の要望を開発者視点からまとめたもの」です。
発注者の要望をしっかりと開発者であるベンダー（受注側）が把握して、専門的な知識を駆使して機能・性能としてまとめ要件定義書を作成します。
システムを必要としているのはクライアント（発注側）であり、どのようなことをシステムで解決していきたいかという要望はクライアント（発注側）しか分かりません。
クライアント（発注側）は、その要望を明確にベンダー（受注側）に伝えて要件定義を進めていかなければなりません。
このように、専門的な知識やスキルがない非技術者であるクライアント（発注側）がシステムに何をもとめるかという仕様の定義を「要求定義」といいます。
要件定義は、要求定義をベースにしてシステム開発を開始するために必ずやらなければならない過程であり、ベンダー（受注側）とクライアント（発注側）がやるべきことをやらないとうまくいきません。
たとえば、システム開発は企業の業務効率化や業務改善のためにおこなうものですので、クライアント（発注側）の担当者は社内の状況にあった要求定義をまとめベンダー（受注側）にわかりやすく伝えます。
一方、要件定義はクライアント（発注側）の要求定義を満たさなければなりませんので、ベンダー（受注側）は要求定義を漏らさず正確に把握します。
ベンダー（受注側）はクライアント（発注側）の要望を正確に把握して、専門的な知識や技術を駆使して要望を実現出来るシステムを開発するために要件定義を進めていきます。
発注側の最も重要な仕事
クライアント（発注側）が勘違いしがちなケースに、要件定義はベンダー（受注側）の仕事で、要求定義を渡せばあとはベンダー（受注側）に要件定義を任せればいいと思ってしまっているケースがあります。
要件定義についてこういった認識の場合、ベンダー（受注側）にちゃんと伝わっていると思っている要望が伝わっておらず、問題が発覚した時点で初めて後悔することになります。
要件定義は、ベンダー（受注側）とクライアント（発注側）が一緒に進めていく作業で、ベンダー（受注側）だけに任せていく作業ではありません。
要件定義は、基本設計などシステム開発全体に関わるクライアント（発注側）にとって重要な仕事です。
要件定義の失敗によって万が一やり直しをすることになった場合、コストと時間が必要です。
クライアント（発注側）に多大な損害を与えかねないということです。
要件定義では、クライアント（発注側）は正確に伝えることが必要で、ベンダー（受注側）はすべての要求をもらすことなく請け負うように努めます。
要件定義の進め方
システム要件定義は、ベンダー（受注側）とクライアント（発注側）が共同ですすめる作業であるという基本的な考え方は前の章で紹介しました。
特に、システムについて専門的な知識がないことを自負しているクライアント（発注側）は、要件定義においてもベンダー（受注側）に任せきりになってしまう可能性がありますので注意が必要です。
基本的な考え方に立って要件定義を進めていくわけですが、実務上の手順である要件定義の進め方も、ベンダー側とクライアント側でやるべきことをやっていく必要があります。
この章では、要件定義の進め方を解説します。
要望のヒアリング
ヒアリングは、要件定義の最初にやらなければならないプロセスで、ベンダー（受注側）が聞き役となって、システムを想定しながら、クライアント（発注側）の要望や状況、課題をヒアリングします。
ヒアリングにおいての基本姿勢も、ベンダー（受注側）とクライアント（発注側）が、共同ですすめる作業という点で一貫しています。
ヒアリングは、システムについて専門的な知識を持つベンダー（受注側）からクライアント（発注側）に向けて行われますが、クライアント（発注側）は受け身ではなく共同で進めているという意識が重要です。
システムを必要としているのはクライアント（発注側）自身であり、要求定義を伝えるためのヒアリングである点を忘れないで作業をおこないましょう。
一方、ヒアリングを主体的に行う役割であるベンダー（受注側）は、クライアント（発注側）の要望を正確に把握するだけでなく、システムの専門家として今回の要件定義のために聞き取っておかなければならない情報を聞き漏らすことなくヒアリングすることが重要です。
要望の細分化
ヒアリングで得た要望をシステムで対応できるように細分化します。
細分化は、システムの専門家であるベンダー（受注側）が主体となって、クライアント（発注側）にシステムを想定した視点でヒアリング等を実施しながらすすめていきます。
要望の細分化はベンダー（受注側）が主体となりますが、要件定義の基本姿勢である、ベンダー（受注側）とクライアント（発注側）が共同ですすめる作業である点を忘れてはなりません。
具体的には下記の流れですすめていきます。
１．現在の業務フローを作成
システム化では、ビフォア・アフターの考え方が必要です。そのためには、クライアント（発注側）の現状を確認し、現在の業務フローを作成していきます。
ベンダー（受注側）は、必要に応じクライアント（発注側）の担当者にヒアリングを行います。場合によっては、実際に業務を実施している現場の担当者にヒアリングを実施し、フローの課題を洗い出します。
システムの専門知識を持っている受注側のヒアリングによってさらに効果的なシステムの活用が見つかるかもしれません。
一方、発注者がシステム導入で問題点が解決できると期待していた要望が、システムでは対応できないことが判明するケースもあります。
２．将来の業務フローを作成
システム化によって課題が解決された将来のフローをクライアント（発注側）が作成し、現在の業務フローのどこをシステム化するかといったプランを具体的に示します。
作成した結果、業務担当者の業務が減っていたら効率化されたフローといえます。
３．業務要件一覧を作成
業務のビフォア・アフターの青写真ができあがり、システム導入によって効率化が確認できたら、システム化に向けて業務フローを一段落とし込みます。
具体的には以下のような手順でクライアント（発注側）がメインとなり、一覧を作成します。
- 現在の業務フローの一つ一つに、作業内容と担当者をExcel等に書き出す
- 同様に将来の業務フローの一つ一つに、作業内容と担当者を書き出す
一覧の作成により、フローの廃止や、内容が変更になる場合があるでしょう。
ここまでが、要件定義における発注側（クライアント）がメインの大きな仕事になります。
４．機能要件一覧を作成
機能要件を記載した一覧を作成します。
機能要件は要望を実現するシステムを構築するための必要最低限の機能であり、納品時に必ず実装すべき項目です。
将来の業務フローを実現するためのシステムに必要な機能を洗い出します。
５．システム構成を決める
ベンダー（受注側）は、必要な機能を実現するためのシステム構成を考えます。
６．外部システムとの連携を考える
システムは単体で機能するケースは少なく、クライアント（発注側）の既存システムや外部サービスとの連携が発生するのかを考えます。たとえば以下の点などに注目します。
- HTTPSなどどのようなネットワーク・プロトコルで繋ぐか
- JSONなどのデータ形式はどうするのか
- 連携タイミングはどうするか（随時、時間毎、一日ごとなど）
７．データベース構造を決める
エンジニアのプログラミングが効率的に進行するために、システムに最適なデータ格納方法（データベース構成）を決めます。
データベース構成を説明するには、以下の形式などを活用します。
- テーブル一覧
-
テーブルとは、Excelに例えるとシートのことです。
データ種類やプログラムの利便性を考慮して、複数のテーブルでデータベースを構成します。 - ER図
-
ER図はEntity Relationship Diagramの頭文字をとった略語で、データベースの関係性を表現する代表的な設計図です。
８．画面構成を決める
システムについて発注側がイメージしやすいように、共有化をはかっていくための分かりやすい図やワイヤーフレームを作成していきます。
- 画面構成図
-
画面構成図の代表としてはウェブサイトにどのようなコンテンツがあるのかを一覧にしたサイトマップがあげられますが、システムの共有化にも有効です。
- ワイヤーフレーム
-
ワイヤーフレームによって発注者にシステム画面の大まかな構成をイメージさせることが可能となります。具体的なツールとしてAdobe XDなどがあります。
９．非機能要件を決める
「機能要件」のほかにも、要望されている主体的な機能をより有効に活用するためのユーザビリティやセキュリティを確保するための「非機能要件」があります。
専門的な知識を持っているベンダー（受注側）の立場から考えて、検討・提案することが必要です。
非機能要件としては、ユーザビリティ、拡張性、セキュリティなどの機能が想定され、システムの品質を向上させることができます。
ベンダー（受注側）は、機能要件について、クライアント（発注側）の要望にもとづいて必要な機能をもれなく把握し、非機能要件は、品質向上のために必要であるが、コストや工数増加の可能性もふくめて提案していく必要があるでしょう。
クライアント（発注側）は、機能要件を確認し、非機能要件は費用対効果を確認していくことに努めることが大切です。
IPA（情報処理推進機構）が非機能要件グレード表を出しているので参考にしてもよいでしょう。
１０．ライセンス一覧
外部ツールを活用する場合、ライセンスを取得のために一覧表を作成して、整理をしていきます。
特に、外部ツールを契約する際の社内手続きに時間がかかる場合、それを見越して事前に契約手続きを開始するのがポイントです。
要件定義書作成
要件定義では、最終的にベンダー（受注側）とクライアント（発注側）で認識を統一する「要件定義書」にまとめて、お互いに責任を持ちます。
要件定義書は、ベンダー（受注側）からクライアント（発注側）に提出されるもので、クライアント（発注側）の要望の実現策が、明記されている書面になります。
要件定義書は専門的な知識がなくても理解できるよう、専門用語などは使用しないことが原則となります。
要件定義書には、要件定義ですすめてきた内容をもれなく記載します。
また、機能要件について、クライアント（発注側）の要望を満たして記載します。
非機能要件について、クライアント（発注側）と、コスト面もふくめ詳細に打ち合わせた結果を記載します。
さらに、要件定義書には業務フローの変化を明記して記載します。
発注側がすべきこと・注意点
要件定義において、クライアント（発注側）がすべきことの基本は、ベンダー（受注側）への要望の伝達です。
ベンダー（受注側）とのギャップが埋められないまま、気づくことなく要件定義しプロジェクトがすすんでしまうと、最悪の場合、システム開発の見直しも発生します。
また、社外のベンダー（受注側）だけでなく、社内にも注意が必要です。
「現状の業務フローの改善を求めている社内の担当部の要望とは違った方向で、システム開発がすすんでいた」などのミスが起きないように、社内の見解の統一や、課題・問題点を要件定義前になるべく明確にしておくことも重要です。
クライアント（発注側）が要件定義ですべきこと・注意点は以下になります。
社内の見解を統一する
今回のシステム化の目的や業務のどこまでの範囲をシステム化するのかなど、社内の見解を統一しておきます。
要件定義では、受注側から機能要件や非機能要件の提案を受け、判断していく場面がでてきます。
社内の見解は、要件定義のおける判断の基準となりますので、見解を統一しておくことが重要となります。
事前に解決すべき課題を明確にする
現状の調査は、時間と手間がかかります。
そのため業務フローと業務要件の整理は、要件定義より事前にしておくのがベストです。
RFP（提案依頼書）を作成するのも良いでしょう。
現場のニーズを正確に汲み取る
現状把握には現場のデータや意見が重要です。現場の現状調査やデータ分析にもとづいて、現状を正確に把握することが大切です。
また、実務的な問題点や課題を感じているのは、現場担当者（ユーザー）であり、必要に応じて現場担当者にヒアリングやアンケートなどを行いましょう。
現場のニーズを正確に汲み取り、要件定義の場面で受注側に伝えるときに情報が歪まないようにします。
受注側がすべきこと・注意点
要件定義において、ベンダー（受注側）がすべきことの基本は、クライアント（発注側）のことを知っておくことでしょう。特に、既存システムなどは、事前調査が必要です。
ベンダー（受注側）は、システムに関する知識が豊富ですので、どのような問題点や課題があるのかといった点について、専門的な立場で解決策を想定できます。
しかしながら、事前調査での想定はあくまで想定であり、クライアント（発注側）の要望と必ずしも一致するとは限りません。
本当の要望を引き出す
クライアント（発注側）は専門家でないケースも多く、自分が理解できる範囲でしか要望を発想できないことがあります。
そのためにも、既存システムなどは事前調査が必要なのです。
事前調査が不足している場合は、ヒアリングの場面で聞き出すことが必要です。
顧客の本当の要望を聞き出すためには、要望を聞いているだけでなく要望を引き出す視点で要件定義することが重要です。
実現可能か判断する
発注側のすべての要望がシステム化できるとは限りません。
また、システム化が経営にとって最善の方法ではない場合もあります。
ベンダー（受注側）はクライアント（発注側）の要望を全て実現しようとするのではなく、費用や工数、技術的な側面から、クライアント（発注側）と判断し要件定義していく姿勢が重要です。
分かりやすいドキュメントの作成
要件定義書やワイヤーフレーム等、関係者全員の認識に齟齬が出ないよう分かりやすい資料を作成することが重要です。
クライアント（発注側）とベンダー（受注側）が、要件定義時に限られた時間を有効に使うために、打ち合わせ等のスケジュール管理も重要となります。
担当者を明確にする
要件定義時のクライアントとベンダーの役割や、誰が何を用意するのかなど、担当者明確にしておきましょう。
たとえば、現行業務の整理、将来的なビジョンの策定などは、ベンダーではなくクライアントがやらなければならない作業です。
また、クライアントの担当者を明確につかんでおかないと、作業の進行中に二度手間など不要な作業と時間を浪費することになります。
受注者はクライアントの担当者を明確にするとともに、自社の担当窓口についてもクライアントに明確に伝えておきます。
まとめ
要件定義は、クライアント（発注側）とベンダー（受注側）の協力作業であり、システム開発をすすめていくための、ベースになるものです。
要件定義はシステム開発の初めに行う最も重要な作業で、工数や費用の見積もり、システム設計など、システム開発全てに関わってきます。
クライアント（発注側）は、システムについての専門家ではないことが多いですが、ベンダー（受注側）任せでは要件定義はうまくいきません。
クライアント（発注側）とベンダー（受注側）の協力作業であるという考え方が、要件定義を進めていく基本姿勢になります。
基本姿勢を守り、クライアント（発注側）ベンダー（受注側）がすべきことを実行していくことで、要件定義を最適に実行し、システム導入成功に近づきます。
具体的なシステム開発の工程に関してはこちらの記事で解説しているので、よろしければご覧ください。
