要件定義とは?進め方や失敗しないための発注側と受注側の注意点

要件定義は、システム開発をスタートするときの最重要プロセスになります。要件定義は、発注側と受注側の共同作業で進めていきます。要件定義の時点で受注側と発注側のギャップが生じないようにしなければなりません。

しかし、ベンダー(受注側)とクライアント(発注側)のギャップは生じやすいのが現実です。一般的に受注側は専門知識が豊富である一方、発注側は受注側と同様の知識をもちあわせていないことが多いからです。
また、受注側は発注側の事業内容や業務内容について知識を持ち合わせていません。

そこで今回は、業務システムの開発を例に、システム開発をスタートするときの最重要プロセスである要件定義の概要から進め方、受注側と発注側がそれぞれすべきこと・注意点をわかりやすく解説します。

目次

要件定義とは?

要件定義とは、ひとことでいうと「発注側の要望を開発者視点からまとめたもの」です。システム開発をスタートする前に、要求をもとに機能や性能などを要件定義に定め、どのように開発を進めるか決めます。

要件定義は「発注側の要望を開発者視点からまとめたもの」ですので、前段階で「発注側の要望」が必要になります。

システムは業務の効率化や業務改善などを目的として導入をすすめるものです。システムを必要とする発注側の社員の多くは、システム開発のスキルや専門知識が豊富な技術者ではありません。こうした非技術者がシステムに求める仕様を定義するものを「要求定義」といいます。

発注側の担当者はシステムに何を求めるのかという要求定義をしっかりとまとめて社内の技術者やベンダー(受注側)に伝えなければなりません。システム開発やシステム導入では、発注側の要求定義を満たすシステムを動かすための仕様として要件定義をしていくわけです。

発注側の最も重要な仕事

要件定義は、システム開発において発注側と受注側で共同作業をすすめていくもので、工数や費用の見積もり、システム設計など、システム開発全てに関わってきます。

要件定義の段階でミスをしてしまうと、最悪の場合システム開発を再度見直さなければならないケースも発生します。

システム開発がやり直しになれば、その分コストと時間が無駄になる訳です。そういった意味では要件定義のプロセスは発注側にとって最も重要な仕事であり、システム開発を成功させるために最も大切と言っても過言ではありません。

要件定義では、発注側は要求を正しく伝える努力が大切であり、受注側も発注側の要求をもれなく請け負うように努めなければなりません。

要件定義の進め方

要件定義の段階で、発注側と受注側のギャップを発生させないためには、要件定義の進め方が重要です。ここでは、要件定義を成功させるための進め方を紹介します。

要望のヒアリング

要件定義は、発注側の要望を具体的にどのようにシステムによって実現していくかを決めていく作業になります。そのためにはシステムの知識を有する受注側は発注側に具体的なシステムに落としていくための聞き取りや現状の課題や要望をヒアリングします。

要望の細分化

要望のヒアリングでシステム開発やシステム導入を実現していくための全体像ができあがった後は、システムで対応できるように細分化します。具体的には下記のステップですすめていきます。

細分化は、受注側が主体となって発注側にシステム化を想定した視点でヒアリング等を実施しながらすすめていきますが、発注側もシステム化によって実現したい要望をもれなく伝えるように努めます。

1.現在の業務フローを作成

システム化を考える上では、ビフォア・アフターの考え方が必要です。そのためには、発注側の現状を確認します。受注側は、システム構築を考慮しながら、現在の業務フローを作成していきます。

業務フローの作成においては、必要に応じ発注側の担当者にヒアリングを行います。場合によっては実際に業務を実施している現場の担当者にヒアリングを実施し、現在のフローの課題を洗い出します。

発注側は、システムに何を求めるかの要望を受注側に伝えていますが、システムの専門知識を持っている受注側のヒアリングによってさらに効果的なシステムの活用が見つかるかもしれません。

一方、発注者がシステム導入で問題点が解決できると期待していた要望が、システムでは対応できないことが判明するケースもあります。

2.将来の業務フローを作成

現在の業務フローの作成ができたら、受注側は、業務のシステム化によって課題が解決された将来のフローを作成します。

発注側の要望を実現するためには、現在の業務フローのどこをシステム化するといったプランを具体的に示します。

将来の業務フローを作成した結果、業務担当者の業務が減っていたら効率化されたフローといえます。

3.業務要件一覧を作成

現在の業務フローと将来の業務フローを作成したことによって、システムによる業務のビフォア・アフターの青写真ができあがりました。システム導入によって効率化が確認できたら、システム化に向けて業務フローを一段落とし込みます。

具体的には以下のような手順で発注側がメインとなり業務要件一覧を作成します

  • 現在の業務フロー一つ一つに、作業内容と担当者をExcel等に書き出す
  • 同様に、将来の業務フロー一つ一つに、作業内容と担当者を書き出す

業務要件一覧を作成するにあたって、現在のフローが廃止になったり、内容が変更になる場合があるでしょう。

ここまでが、発注側(クライアント)の大きな仕事になります。

4.機能要件一覧を作成

業務フロー、業務要件一覧の作成ができたら、機能要件一覧を作成します。機能要件とは発注側の要望を実現するシステムを構築するための機能のことです。機能一覧を作成して将来の業務フローを実現するためのシステムに必要な機能を洗い出します。

機能要件は発注側の要件を実現するために必ず必要な機能であるため、受注側はヒアリングなどにより要望された内容をもれなく機能に落とし込むことが必要です。機能要件は必要最低限の機能であり納品時実装されていないことはありえない項目になります。

5.システム構成を決める

機能要件一覧ができたら、受注側は必要な機能を実現するためのシステム構成を考えます。

6.外部システムとの連携を考える

システムは単体で機能するケースはすくなく、発注側の企業で使用している既存システムや外部サービスとの連携が発生するのかを考える必要があります。たとえば以下の点などに注目します。

  • HTTPSなどどのようなネットワーク・プロトコルで繋ぐか
  • JSONなどのデータ形式はどうするのか
  • 連携タイミングはどうするか(随時、時間毎、一日ごとなど)

7.データベース構造を決める

システムのプログラミングが効率的に進行するために、システムに最適なデータ格納方法(データベース構成)を決めます。データベース構成を説明するには以下の形式などを活用します。

テーブル一覧

テーブルとは、Excelに例えるとシートのことです。
データ種類やプログラムの利便性を考慮して、複数のテーブルでデータベースを構成します。

ER図

ER図はEntity Relationship Diagramの頭文字をとった略語で、データベースの関係性を表現する代表的な設計図です。

8.画面構成を決める

システムについて発注側がイメージしやすいように、共有化をはかっていくための分かりやすい図やワイヤーフレームを作成していきます。

画面構成図

画面構成図の代表としてはウェブサイトにどのようなコンテンツがあるのかを一覧にしたサイトマップがあげられますが、システムの共有化にも有効です。

ワイヤーフレーム

ワイヤーフレームによって発注者にシステム画面の大まかな構成をイメージさせることが可能となります。具体的なツールとしてAdobe XDなどがあります。

9.非機能要件を決める

要件定義においては、発注側の要望を実現するために必要な機能である「機能要件」のほかにも、要望されている主体的な機能をより有効に活用するためのユーザビリティやセキュリティを確保するための「非機能要件」があります。

非機能要件は、発注側から直接要望として出てきているものではありませんが、専門的な知識を持っている受注側の立場から考えて一般的に必要であると考えられる機能については提案することが必要です。

非機能要件としては、ユーザビリティ、拡張性、セキュリティなどの機能が想定され、システムの品質を向上させることができます。非機能要件によって発注側のシステムに対する満足度は上がるはずです。

受注側は、機能要件について発注側の要望にもとづいて必要な機能をもれなく洗い出す必要があり、非機能要件については、品質向上のために必要であるがコストや工数の増加がかかる可能性があることもふくめて提案していく必要があるでしょう。

発注者側は、機能要件が要望を満たしているか確認し、非機能要件については費用対効果を確認していくことに努めることが大切です。

IPA(情報処理推進機構)が非機能要件グレード表を出してるので参考にしてもよいでしょう。

参考:システム構築の上流工程強化(非機能要求グレード)

10.ライセンス一覧

外部ツールを活用する場合、ライセンスを取得しなければならないため、一覧表を作成して整理をしていきます。

特に外部ツールを契約する際の社内の手続きに時間がかかる場合は、それを見越して事前に契約手続きを開始する必要があります。

要件定義書作成

要件定義で決定したシステム要件など全てのことを、最終的に発注側と受注側で認識を統一するものとして「要件定義書」にまとめて、お互いに責任を持ちます。要件定義書は受注側から発注側に提出されるもので、発注側の要望の実現策が明記されている書面になります。

要件定義書は受注側が理解できるものでなければなりませんので、専門的な知識がなくても理解できるように専門用語などは使用しないことが原則となります。

要件定義書には、前述の要件定義のフローですすめてきた内容をもれなく記載します。具体的には、発注側の要望を解決するためにどのようなシステムを導入する計画であることを具体に分かりやすく記載します。

また、機能要件について発注側の要望をすべて満たした内容で記載します。非機能要件について、発注側とコスト面もふくめ詳細に打ち合わせた結果を記載します。

さらに、システム導入によって従来の業務がどのように変わるかを具体的な業務フローの変化を明記して記載します。

発注側がすべきこと・注意点

要件定義において発注側がすべきことの基本は、受注側に要望を正確に伝えることです。要件定義の段階で生じていた受注側とのギャップが埋められないまま、気づくことなくプロジェクトがすすんでしまうと、最悪の場合システム開発を再度見直さなければならないケースも発生します。システム開発がやり直しになれば、その分コストと時間が無駄になってしまいます。

また、社外の受注側だけでなく、社内のギャップにも注意が必要です。「現状の業務フローの改善を求めている社内の担当部の要望とは違った方向でシステム開発がすすんでいた」などのミスが起きないように社内の見解の統一や課題や問題点を明確にしておくことも重要です。

要件定義において受注側に要望を正確に伝えるために発注側がすべきこと・注意点は以下になります。

社内の見解を統一する

今回のシステムの目的や業務のどこまでをシステム化するのかなど、社内の見解を統一しておきます。

要件定義においては、専門的な知識を持った受注側から、機能要件や非機能要件の提案を受け、判断していく場面がでてきます。

社内の見解は、要件定義のおける判断の基準となりますので、見解を統一しておくことが重要となります。

事前に解決すべき課題を明確にする

要件定義のフローでは、現行業務の整理、将来的なビジョンの策定は発注側の作業によってできあがったデータがベースとなり協議・分析が進行していきます。

現状の調査は、時間と手間がかかります。そのため業務フローと業務要件の整理を事前にしておくのがベストです。

RFP(提案依頼書)を作成するのも良いでしょう。

現場のニーズを正確に汲み取る

現行業務の整理、将来的なビジョンの策定には現場のデータや意見が重要です。現場の現状調査やデータ分析にもとづいて現状を正確に把握することが大切です。

また、実務的な問題点や課題を感じているのは現場担当者(ユーザー)であり、必要に応じて現場担当者にヒアリングやアンケートなどを行いましょう。

現場の二ーズを正確に汲み取り要件定義の場面で受注側に伝えるときに情報が歪まないようにします。

受注側がすべきこと・注意点

要件定義において受注側がすべきことの基本は、発注側のことを知っておくことでしょう。特に、現状はどんなシステムを使用しているかなどのシステム関連については事前調査が必要です。

受注側はシステムに関する知識が豊富ですので、発注側の既存システムを知ることで、どのような問題点や課題があるのかといった点について、専門的な立場で解決策を想定することができます。

しかしながら、事前調査での想定はあくまで想定であり、発注側の要望と必ずしも一致するとは限りません。あくまでも発注側の問題を解決することがシステム導入の目的です。

発注側についてよく調べたうえで、要件定義においては、ヒアリングの方法や実現可能かどうかの判断、分かりやすいドキュメントの作成など注意すべき点がいくつかあります。

本当の要望を引き出すヒアリング

発注者の本当の要望を引き出すためには、ヒアリングが必要です。発注者は本当に必要な要望を正しく言葉に出来ていない可能性があるためです。発注者はシステムについての専門的な知識を持っていないケースも多く 自分が理解できる範囲でしか要望を発想できないことがあります。

そのためにも、現状はどんなシステムを使用しているかなどのシステム関連については事前調査が必要なのです。事前調査が不足している場合は、ヒアリングの場面で聞き出すことが必要です。

発注側の本当の要望を聞き出すためには要望を聞いているだけでなく、要望を引き出していくヒアリングが必要なのです。

機能が実現可能か判断する

発注側のすべての要望がシステム化できるとは限りません。また、費用対効果を考えると必ずしもシステム化が経営にとって最善の方法ではないケースもあります。

受注側は発注側の要望を全て実現しようとするのではなく、費用や工数、技術的な側面からどの機能が実現可能か発注側と判断していく姿勢が重要です。

分かりやすいドキュメントの作成

発注側に分かりやすいドキュメントを作成することも重要です。

受注側は、要件定義書やワイヤーフレーム等、関係者全員の認識に齟齬が出ないように注意します。

発注側と受注側がともに限られた時間を有効に使って、ギャップのない進行をしなければなりません。

そのためには、打ち合わせ等のスケジュール管理も重要となります。

担当者を明確にする

プロジェクトの過程では、発注側の作業も必要となります。たとえば、現行業務の整理、将来的なビジョンの策定など、発注側がやらなければならない作業が発生します。誰が何を用意するのか、発注側の担当者や責任者を明確にしておくことも重要です。

発注側の担当者を明確につかんでおかないと、作業の進行中に発生するさまざまなやり取りがスピーディーに実行されず、二度手間など不要な作業と時間を浪費することになります。受注者は発注側の担当者を明確にするとともに、自社の担当窓口についても発注側に明確に伝えておくことが大切です。

まとめ

要件定義は、発注側と受注側の協力作業です。

要件定義は、システム開発をすすめていくためのベースになるもので、工数や費用の見積もり、システム設計など、システム開発全てに関わってきます。

そのため要件定義の時点で受注側と発注側のギャップが生れないように努めなければなりません。発注側、受注側がお互いに注意点を念頭に置き、やるべきことを実行していくことで、要件定義を最適に実行し、システム導入を成功に導く可能性を高めることができます。

アプリ・システム開発 無料相談実施中
プロフィール背景画像
株式会社オプスイン
システム・アプリ開発
オプスインでは、最短ルートでWebシステム開発・アプリ開発を成功に導く融通の利くシステム開発を行っております。
作りたいものがはっきりと決まっていない場合も、ヒアリングを通して、要件の明確化をサポートいたします。
無料相談実施中!お気軽にご相談ください!
役に立ったらシェアしていただけると嬉しいです

コメント

コメントする

one + 3 =

目次
閉じる