オウンドメディアやサービスサイトなどに携わっている方の中には、新たにシステムを導入したいと考えている方もいるでしょう。その際、制作会社から要件定義書が共有されます。
ただ、システム開発に初めて携わる方は「要件定義書とは何か?」「どうして必要なのか?」などといった疑問が浮かんでくるでしょう。
そこでこの記事では、
- 要件定義書とは何か
- なぜ必要なのか
- どんなことが記載されているのか
などといった観点から要件定義書について解説していきます。この記事を読むことで、システム開発に関わる書類について理解できるため、安心してプロジェクトを進められるようになります。ぜひ参考にしてみてください。
要件定義書とは?
要件定義書とは、システム開発を依頼した際の合意内容がまとめられた書類のことです。この書類は制作会社の開発者が作成するので、システム開発を依頼する人が作成に関わることはありません。
また、作成した要件定義書はシステム開発に携わる開発者だけでなく、システム開発を依頼した発注者も読む必要があります。
そのため、基本的には普段からシステムに携わっていないような人でも、内容がわかる書き方がされているのが一般的です。ちなみに、書類のフォーマットは制作会社によって違いがあり、記載内容に修正や変更が入ることもあります。
システム開発に関わる書類は、他にも「提案依頼書」や「情報提供依頼書」があります。ここで、それぞれの書類との違いについて解説していきましょう。
提案依頼書(RFP)との違い
提案依頼書とは、システムの開発を制作会社に依頼する際、どんなものを作成してほしいのか依頼内容をまとめた書類のことです。英語で「Request for Proposal」と言われることから、略して「RFP」と呼ばれることもあります。
提案依頼書との違いを、以下のようにまとめました。
記載内容 | 作成者 | |
要件定義書 | 合意内容 | システム開発者 |
提案依頼書 | 依頼内容 | 発注者 |
大きく違う点は、要件定義書はシステム開発者が制作する書類であるのに対し、提案依頼書は発注者が作成する書類である点です。
提案依頼書があることにより、受注側にとってはニーズを的確に捉えられるので重要な書類となります。もちろん口頭でどんなシステムを制作してほしいのか伝える機会もあるでしょうが、口頭だけでは把握しきれない場面もあります。
また、システム開発は1人で行うものではないので、書類にまとめることで、チーム内でしっかりとニーズを把握できるようになるのです。
情報提供依頼書(RFI)との違い
情報提供依頼書とは、制作会社にシステム開発を依頼する際、情報の提供を依頼する書類です。英語では「Request For Informatio」と言われることから、略して「RFI」と呼ばれることもあります。
情報提供依頼書との違いを、以下のようにまとめました。
記載内容 | 作成者 | |
要件定義書 | 合意内容 | システム開発者 |
情報提供依頼書 | 提供してほしい情報 | 発注者 |
大きく違う点は、要件定義書はシステム開発者が制作する書類であるのに対し、情報提供依頼書は発注者が作成する書類であることです。
発注者は、制作会社の情報が何もないままでは「この会社に依頼して必要なシステムを開発してもらえるのか?」などといった疑問を抱えてしまいます。そこでシステム開発を依頼する前に、制作会社に関する情報をもらいます。
情報提供依頼書では、以下のような情報を開示するよう求めます。
- 会社情報
- 製品情報
- 業務実績
- 開発者に関する情報
これらの情報を得ることで、発注者は制作を依頼できるようになるのです。
要件定義書が必要な理由
システム開発に要件定義書が必要な理由は、2つに分けて説明します。
①双方の目線を合わせる
制作会社が発注者と目線を合わせるためです。どんなシステムを開発してほしいのかまとめた書類がないと、認識齟齬が発生する場合があります。
制作会社の主観によって開発が進んでしまうと、結果的に望んでいたシステムとは全く異なるものを納品してしまう恐れもあるのです。こうした事態を避けるためにも、要件定義書はシステム開発においてなくてはなりません。
②予算やスケジュールの周知と把握
予算やスケジュールを把握してもらうためです。システム開発には様々な工程が発生し、開発の進め方によってスケジュールが変わってきます。また開発者の人数や求める機能によって、予算も変わるのです。
こうした事情を把握してもらうことで、スケジュール内に成果物を納品してもらい、予算内で開発してもらえるようになります。
要件定義書に記載される項目
要件定義書には、一般的に以下のような内容が記載されます。
- 業務要件
- システム要件
- 機能要件
- 非機能要件
- システム導入後の流れ
- セキュリティ要件
それぞれの項目について知ることで、より理解が深まるでしょう。ここからは、それぞれの項目について解説していきます。また、発注者が要件定義書を確認する際のポイントについても触れていきます。
業務要件
業務要件とは、開発の目的を明らかにすることです。「プロジェクトのどんな目的を実現するために、そのシステムを開発するのか?」といった発注に至る経緯などが記載されています。
開発者は、「どんな背景からシステムを発注するに至ったのか?」「今回の依頼が、最終的にどんな目的を達成するのか?」などといった視点から業務要件をまとめていきます。
ここで発注者が業務要件を読む際は、「自社のニーズと認識のずれがないか?」という視点でチェックすることが大切です。そもそも業務要件が理解されていないと、システム内容はもちろん、セキュリティ内容にも影響が出てきてしまう恐れがあります。
自社のニーズが抜け落ちたままシステム開発が行われないよう、認識の違いを感じたら再度話し合いの場を設け、しっかりとヒアリングを行ってもらいましょう。
システム要件
システム要件とは、これから開発システムにどんな機能や性能が必要なのかをまとめた項目のことです。具体的なシステム内容を記載すると言うよりも、「何ができないといけないのか」が中心に書かれます。
システム要件に関連する項目に、「機能要件」と「非機能要件」というものがあります。システムに関する具体的な内容については、この2つの項目にわたって記載されるのです。
システム要件を読む際のポイントは、「必要なシステムの認識が合っているか?」という視点で確認することです。最終的な成果物がここに記載されるので、ここに記載されているシステムが納品されても問題ないことを確認しましょう。
機能要件
機能要件とは、システム要件をもとに「どんな機能が必要なのか?」という情報をまとめた項目のことです。機能要件はシステムの目的に関わる大切な項目です。
例えば自社のオウンドメディアにて、サイト内検索のシステム開発を依頼したとしましょう。最近では、検索にはテキストによる入力の他に、音声入力や画像による入力など様々な方法があります。これらのうち、「どの機能が必要なのか」などが記載されます。
機能要件を読む際のポイントは、「目的に必要な機能が全てそろっているか?」という視点で確認することです。もし不足がある場合は、開発者に連絡しましょう。
連携漏れがあると、開発後に機能が足りないことが発覚し、別途制作を依頼しなくてはならなくなります。するとプロジェクトの進行が遅れ、コストも余計にかかってしまうなどのデメリットが生じてしまう恐れがあります。
非機能要件
非機能要件とは、システムに関わる機能以外のあらゆることについて記載する項目のことです。具体的には、ユーザビリティや拡張性、性能など機能以外に満たしていなければならない性能が記載されます。
非機能要件は発注者からは目に見えにくい部分なので、分かりにくいかもしれません。しかし、非機能要件が満たされることにより、開発されたシステムが使いやすく満足いくものになるのです。
例えば、勤怠管理システムの開発を依頼したとしましょう。そこで開発者がシステムを立ち上げてすぐに表示されるような工夫をしたとします。すると実際の出勤時間とのズレもなくなり、快適に利用できるようになります。
非機能要件には、このような取り組みが記載されます。そのため、普段システム開発に関わっていない発注者には分かりにくいかもしれませんが、目を通して気になる点があれば質問してみるといいでしょう。
システム導入後の流れ
システム導入後の流れでは、開発したシステムが導入された後、どのように業務に関わるのかが記載される項目です。要件定義書によっては、分かりやすくフローチャートなどを用いて記載されていることもあります。
この項目を読む際のポイントは、システムを導入した後、「自社でそのシステムを使いこなせるか?」という視点で確認することです。もし導入後の流れについて不明点があったり、自社ではどうにもならない事情があるようなら、制作会社に確認してみましょう。
セキュリティ要件
セキュリティ要件とは、システムに対してどんなセキュリティを構築するかを明記する項目のことです。企業でシステムを利用する場合、ウイルス感染や情報漏洩などといった脅威にさらされることがあります。こうした攻撃に対し、具体的にどんな対策を取るかを考えて記載されるのです。
とはいえ、システムにあまり携わったことがない発注者の方はセキュリティ事情についてあまり詳しくはないかもしれません。そのため、セキュリティ要件を読む際は不明点がないかどうか確認するといいでしょう。
システム開発依頼の際は提案依頼書が重要
ここまで要件定義書の項目について解説していきました。要件定義書は開発者が制作する書類ですが、認識のズレがないか確認するという点では大切な書類です。
ただ、発注者が制作する書類においては、提案依頼書の作成がより重要となります。その理由は、提案依頼書に必要な情報が書かれていないと、そもそも制作会社の方で要件定義書をまとめられなくなるからです。
自社のニーズにそったシステムを制作してもらうためにも、以下のようなポイントはしっかりと押さえておきましょう。
①目的やゴールなど大枠を書く
②5W2Hを押さえて分かりやすく書く
①目的やゴールなどの記述
目的やゴールなど大枠を書くことです。提案依頼書はあくまで依頼に必要な書類であり、具体的な機能などを記載する書類ではありません。
そのため、「自社でどんなプロジェクトがあるのか」「そのプロジェクトがどんな目的を持っているのか」「システムを用いてどんなことを達成したいのか」などと大枠を記載しましょう。
②5W2Hで記述
5W2Hを押さえて分かりやすく書くことです。上記で「細かい機能は記載しない」とお伝えしましたが、以下のような項目は必須です。
- Why:プロジェクトの目的
- What:システムを用いて行いたいこと
- When:いつからいつまでに
- Who:誰が使うのか
- Where:どこで使うのか
- How:どんなふうに使うのか
- How much:予算
これらの情報を記載することで、制作会社はどんなシステムを開発すればいいのか考えられるようになります。
まとめ
この記事では、要件定義書について解説しました。要件定義は、システム開発を依頼した際に制作会社が制作する書類です。制作会社は発注者との認識をすり合わせるため、書類にまとめます。また、発注者がどんなシステムを求めているのか開発チーム内で共有するためにも用いられます。
発注者が要件定義書を読む際は、「依頼内容に沿っているか?」という視点で確認することが大切です。もしこの段階で認識のズレがあったり、不明点があったりした場合は制作会社に確認してみるといいでしょう。
また、システム開発を依頼する際は提案依頼書が重要です。提案依頼書に必要な情報が書かれていないと、制作会社は要件定義書に内容を落とし込めません。するとシステムを制作しても、実際に欲しかったものとは違う成果物が納品される事態に発展してしまうでしょう。
プロジェクトを成功させるためにも、ぜひこの記事でご紹介したポイントを取り入れてみてください。