システム開発の要求仕様の重要性と作成工程まとめ

システム開発において重要な書類データとなるのが要求仕様書です。受注側と発注側でやり取りされる書類データとなっており、お互いで開発を進める際に必要不可欠な存在となっています。

本記事では、要求仕様書について詳しく解説します。要件仕様書と要件定義書の違いやREPの存在についても解説しているので、これからシステム開発を行う予定がある場合は、是非ご参考ください。 要求仕様書作成の相談が可能な開発会社一覧を見たい場合は、「見積依頼が可能なソフトウェア・業務システム開発の会社一覧」をご覧ください。

1.　要求仕様書とは

要求仕様書と要件定義書

システム開発においては、開発を行うにあたって発注側および開発側の認識をあわせるため、もしくは開発側の開発に関わるチームメンバーの認識をあわせるために、いくつかドキュメントと呼ばれる書類が作成されます。

主にこれらのドキュメントは開発会社側が用意することが多いのですが、後々思っていたシステムと違うという相違を防ぐためにも、発注側はそのドキュメントをベースに自分たちの作りたい内容のすり合わせが行われるということを理解しておくことをおすすめします。

その中でも非常に重要度の高い書類データなのが、要求仕様書と要件定義書です。名前が似ていますが、この2つには下記の様な違いがあります。

●　要求仕様書

エンドユーザー（発注側）の機能修正、機能追加の要望に沿って、対応の詳細、対応にかかるコスト、かかる開発期間、注意点の有無などを記載し、確認するためのドキュメントを指します。この要求仕様書があると、エンドユーザーと細かくすり合わせを行うことができるので便利です。
実際に開発側はこの要求仕様書を確認して、プログラミングにおける設計書とすることが多いため要求仕様書を細かく詰めることが求められます。より充実したシステム開発のためにも、発注側と受注側で要求仕様書を完璧なものにすることがおすすめです。

● 要件定義書

要件定義書は、システム開発側から見た、ユーザーからの要望に応えるための機能を記したドキュメントです。
具体的には下記のような機能が挙げられるでしょう。

• システムの概要
• 入力要求と出力要求
• システム導入後の細かい導入フロー
• セキュリティに関する要求

実装する機能を整理した情報をクライアントに提出するために必須なものとなるので、要求仕様書と同じく非常に重要度の高いドキュメントになります。

要求仕様書とRFP

RFPとは提案依頼書のことを指し、具体的には発注側がシステムなどを調達する際に、開発側が具体的なシステム提案を行うように要求すること、またはその調達要件などをまとめたシステム仕様書を指します。つまり、RFPは発注側が準備する依頼内容をまとめた書類と捉えるとよいでしょう。 RFPには作りたいものに関する仕様など以外に、予算や納期、開発環境などの情報についてもまとめて作成します。

開発側はRFPを参考にした上でシステム設計を行って提案書を作成し、発注側に提出して細かいすり合わせを行います。受注側はその提案書を確認して、調達先の決定や契約の締結を検討します。
要求仕様書は基本的に開発着手後の最初のフェーズで作成を進めていくことが多いため、RFPの後に進める内容となります。

実際にREPの内容で受注が決まるので、非常に重要度の高いドキュメントと言えるでしょう。開発側が確実に受注を狙う場合はREPを綿密に策定する必要があります。発注側の要望や課題を汲み取り、発注側が満足できるREPを作成して提示できると効果的です。

要求仕様作成などシステム開発の依頼先でお悩みの場合は、リカイゼンにお任せください！
リカイゼンでは、熟練のマッチングスタッフが、希望条件に応じて適した開発会社候補を選定し、無料紹介いたします。
まずはご相談からでもお気軽にご連絡ください。

2.　要求仕様書の設計方法

ここからは、開発会社側が用意していくドキュメントとなりますが、どのように進められるかを発注側が知ることによって、事前に準備しておいた方がよいことや、開発会社側に共有しておいた方がよい情報なども把握できるようになります。

システム開発は、開発会社側だけに任せて進めると、実際に使う際になって想定と違ったなど結果的に困ることになってしまうのは発注側になるため、発注側も積極的に開発会社に情報を提供したり、確認を行うようにしましょう。

要求仕様書には設計方法が存在します。あらかじめ設計方法を把握しておくと、要求仕様書に関する理解や作成スピードが向上します。よりスムーズに要求仕様書を作成するためにもあらかじめ要求仕様書の設計方法は必ず把握しておきましょう。

要求仕様の作成工程

要求仕様書に必要となる作成工程は下記の通りになります。

• 要求収集
• 要求分析
• 要求定義（要件定義）
• 要求仕様記述

それぞれの作成工程を順番に行うことで質の高い要求仕様書を作成することが可能です。いずれの工程も重要度が高いので発注側とすり合わせをした上で、慎重に行うことが求められます。ここからはそれぞれの手順について詳しく解説するので、システム開発の際のご参考にしてください。

①　要求収集

要求収集ではその開発対象のソフトウェアに何を実行させたいか、どのような役割を担わせたいかを、関係者からのヒアリングなどを通して収集します。インタビューやアンケートを用いて、発注側からの要望を汲み取りましょう。マインドマップなど全体的な構想をスムーズに可視化できるツールも非常に便利です。使えそうなツールは積極的に使うと良いでしょう。ただ、インタビューやアンケートのみだと表に出ていない要望があるケースもありえます。

システム開発でありがちな傾向としては具体的なシステムの動作などについては要求されるものの、セキュリティ面や品質については特に話がないという場合です。長くシステムを使い続ける上でセキュリティ面や品質は非常に重要な要素なので、再度ヒアリングするか、過去のノウハウを活かしていくことがおすすめです。

②　要求分析

要求分析では、聞き取りや話し合いを通じて集められた複数の要求が、それぞれ矛盾しないかどうかの一貫性と、抜けている部分がないかを補うための完全性の検証を行います。チェックリストなどを用いて発注側からの要求を洗い出すと効率的です。シンプルで手軽に要求に関する矛盾点を洗い出すことができます。矛盾点を探るために関係者を招いてワークショップを開き、細かく検証することも大切です。複数の人の視点で見ることでさらに効率よく要求分析することができます。

また、開発前に受注側に対してアプリケーションを視覚化して見せるためのプロトタイプを開発するのも1つの手段です。本格的に開発に入る前にプロトタイプで確認することで、両者の齟齬を無くしながら工程を進められます。より安心できる形で要求分析を行いたい際に有効な手段です。

③　要求定義（要件定義）

要求定義の段階では、要求分析で得られた情報やデータを元に、実際にソフトウェアを開発する人たちに要求を理解させるための文書を作成します。この段階で発注側に理解させる文書を作ることができればさらにスムーズに工程が進むので、細かく作りこむことが重要です。

発注側が思い付きで言ったレベルのものから、本当に必要な機能を割り出し可視化することで、発注側も自分たちのニーズを分かりやすく理解することができます。お互いの認識のズレを効率よくすり合わせることができるので、要求定義の段階は疎かにせず細かく詰めていきましょう。

④　要求仕様記述

要求仕様供述は、固まった要件定義を元に、要求と設計の橋渡しとなる文書を作成する工程です。システムが使われる領域に適したルールに従い、システムの作成/修正を指示するような形で作られるのがほとんどのケースとなります。

要求仕様作成の最終工程となり、システムの作成や修正と言った非常に重要な部分なので今までの工程を振り返りながら供述することが大切です。

要求仕様作成などシステム開発の依頼先でお悩みの場合は、リカイゼンにお任せください！
リカイゼンでは、熟練のマッチングスタッフが、希望条件に応じて適した開発会社候補を選定し、無料紹介いたします。
まずはご相談からでもお気軽にご連絡ください。

3.　要求仕様書の書き方

要求仕様書は下記の項目を書くことがほとんどです。

• 背景・現状の課題
• 目的
• 機能
• 開発体制
• 開発スケジュール

要求仕様書は、発注側と細かくすり合わせを行いながら、上記内容を文書に残していくかたちになります。ここからはそれぞれの項目の詳細について細かく解説するので、要求仕様書作成の際のご参考にしてください。

背景・現状の課題

要求仕様書を書く場合は発注側の背景や現状を細かく理解することが重要です。「なぜ今回発注を行ったのか」「発注側の現在の課題は何なのか」細かく理解することでより充実した要求仕様書の作成が可能になります。

発注企業側は、スムーズな開発のため、背景や現状の課題をできるだけ細かく開発会社に共有していきましょう。ここがぶれてしまうと、開発されるシステムもずれたものになってしまうため、発注側も主体的に情報発信を行なうことが大切です。マインドマップなどのツールがあると、発注側の背景や現状の課題を分かりやすく可視化することができます。

背景・現状の課題をしっかりと発注側と開発側で齟齬なく認識を統一し、言葉のニュアンスを含め、しっかりと文書にまとめられるようにしましょう。

発注側も、この背景・現状課題のヒアリングに関して、開発会社側が向き合って取り組んでくれるか否かは重要です。言われたことだけを記載している開発会社は不安要素が残ります。認識を統一しようと話を聞いてくれる、また例を出してくれるような開発会社を選びましょう。

目的

発注側の背景や現状の課題を聞き終えた後はシステムを開発する目的を記載しましょう。どのような目的に対して、システム開発することによる効果を明確にするとより分かりやすくなります。ここでシステム開発の目的を明確化しておくことで、後にシステム開発が進んで要件やスケジュール変更が必要になった場合の指針になります。

発注側にシステム開発の目的をヒアリングする際には、「このシステムで何を達成するつもりなのか」具体的に聞きましょう。「管理システムを開発して、顧客情報をより有効活用したい」など具体的に聞き出すことで、発注側が目指している目標が判明します。開発が完了するまで方向性が不安定にならないように、この段階で目的を明確にするように心がけましょう。

機能

発注側の目的を明確にした後は用途、ユーザー、性能、制限事項など具体的な機能を確認しましょう。発注側から必要な機能をヒアリングする際に、必ず優先順位を付けることが大切です。

必要度の高い機能と低い機能をふるい分けることによって、さらに効率よく開発することができます。また、優先度だけではなく、その機能がなぜ必要なのかという理由まで聞けているとベストです。

また、機能などはラフでも構わないので画面一覧／画面構成図／画面遷移図を用意するとさらにスムーズです。図があると発注側と受注側でより明確なイメージが生まれるので、話し合いや開発もさらにスムーズに進みます。お互いで齟齬が生まれないためにも文面だけでなく、図も積極的に活用しましょう。

開発体制

要求仕様書では開発の体制（PM、エンジニアなど）を取りまとめることも非常に重要です。開発体制の充実はそのままシステム開発のスピードにも繋がるので、なるべく明確に定める必要があります。

まずPM（プロジェクトマネージャー）の決定を優先しましょう。PMはプロジェクト全体の責任者となるので、優先順位が高くなっています。PMのスキルやノウハウ次第でシステム開発の効率も変わってくるので慎重な決定が必要です。

その後は、エンジニアを決めてチームに配属します。システム開発に必要な知識やスキルを持ち合わせているか、経験はシステム開発に見合うものかなど入念に吟味した上で確認しましょう。場合によってはアウトソーシングを図り、優秀なエンジニアをチームに入れることもあります。

開発スケジュール

最後に開発スケジュールを設定しましょう。開発スケジュールを綿密に設定しておくことで、もし開発に遅れが発生した場合でも、後戻りを少なくした上で工程を進めることが可能です。

まずは全体のスケジュールを設定し、大まかなスケジュールの流れを発注側と開発側で確認します。その後、細かいスケジュールを設定して詰めていくとより詳細にスケジュールを設定することが可能です。

また、スケジュールを設定する場合はExcelやスプレッドシートなどでスケジュールや工程表を作ると共有しやすくなります。発注側と受注側が分かりやすい状態で共有できるように心がけましょう。

要求仕様作成などシステム開発の依頼先でお悩みの場合は、リカイゼンにお任せください！
リカイゼンでは、熟練のマッチングスタッフが、希望条件に応じて適した開発会社候補を選定し、無料紹介いたします。
まずはご相談からでもお気軽にご連絡ください。

4.　要求仕様での重要なこと

要求仕様で重要かつ注意すべき点がいくつか存在しており、その注意点を知らずにいると要求仕様書のスムーズな作成が難しくなります。ここからは要求仕様での重要なことについて解説するので、1つずつチェックしましょう。

曖昧性を無くす

要求仕様書は、基本的に発注側がシステムに求めるもの、およびシステム導入後に実現したい世界が記載されていることがほとんどです。ただ、一概にそれが正解とは言えず、文脈の裏に、業界的な当たり前・ルールが潜んでいることもあるので、発注側としても自分の希望はすべて伝えたと思っていても伝わっていないこともありえます。

そのため、開発側は先方の業界や業務知識などを把握しておく必要があります。発注側の希望を全て鵜吞みにせず、自社の知識やノウハウを活かしながら足りない部分は積極的に提案していきましょう。

認識をあわせる用語定義

要求仕様をまとめていくときには、用語定義が重要となります。発注側と受注側で用語に関する認識がずれていると、それだけで意識のすり合わせが上手くいかなくなってしまうので注意が必要です。

また、要求の優先順位などが定義付けられていることも大切です。できるだけ発注側の意思を汲み取り、システム開発において何を優先したいのか積極的にヒアリングすることで確認するようにしましょう。

要求仕様に関する重要点まとめ

要求仕様を作成するためには、これらのステップが踏まれます。
もっとも大事なのは、いかに1の要求収集を徹底的に行えるかということであり、関係者へのヒアリング等を含めて、たいていの場合1ヶ月は要すると言われています。

5.　まとめ

システム開発における要求仕様の工程は、発注側と受注側が共通の認識を持つために行う大切な内容です。要求仕様をおろそかにしてしまうと、発注側と受注側で認識齟齬が発生してしまうなど、結果的に開発が遅れたり、追加費用がかかったりなど、お互いにとってよくないケースに繋がりやすいです。

システム開発の発注側も、開発会社に丸投げするのではなく、実現したいことがちゃんと伝わっているかや自分でわからないところは開発会社に質問するなどして、できるだけ不明瞭なものがないようにこの工程を進めていくことが成功への近道です。

システム開発について具体的に相談をしたいという方は、ぜひリカイゼンにご連絡ください！サポートデスクが、一次ヒアリングを行い、ご要望を整理しますので、初めての発注で不安な方も安心してご利用いただけます。