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