システム開発の要件定義の進め方とは？成功のコツと外注時のポイントを解説

システム開発に関わっていると出てくる「要件定義」という言葉。どこでも「要件定義は重要！」と言われていますが、でもなんで？という疑問を持たれる方もいるのではないでしょうか。

今回はそんな「要件定義」について、結局のところなんで重要なの？どのように進めると失敗しない？という疑問を解決すべく説明していきます。

要件定義などについて相談できる開発会社一覧は、「見積依頼が可能なソフトウェア・業務システム開発の会社一覧」よりご覧ください。

1. システム開発における要件定義とは

まずは、システム開発における要件定義について、確認しておきましょう。要件定義とは、「システムや製品の開発において、何を作るべきかを明確に定義する作業」のことを指し、システム開発を進める際のプロセスの1つとも言えます。

要件定義を行うことで、ユーザーが求めているシステムとはどのようなものなのか、システムに求められる役割や効果、必要とする機能や性能を明確にし、それを実現するための条件や制約、品質要件を定義することによって、望んでいるシステムを具体化していきます。0から作るシステム開発は、実際にある商品を購入するのとは異なり、無形であり、どのようなものをつくるのかというのはシステムを作りたい担当者の頭の中にしかないため、頭の中にあるシステムの構想を関わる人全員と共通するために言語化し、共通認識を作っていくこととも言い換えられるかもしれません。

システム要件定義では、ユーザーのニーズや期待、目的などを把握することが非常に重要であり、そのためには関係者とのコミュニケーションを通じて、常に更新・改善されることが望ましいです。明確に定義された要件は、開発チームや関係者が共有し、システムの品質や機能性を担保するための基盤となります。

要求定義との違い

システムの要件定義について調べていたり、理解を深めていくと、「要求定義」という言葉が出てきます。

要求定義とは、システム開発において、「どのような機能や効果を実現することが求められているか」を明確にする作業を指します。要件定義の前に、要求定義が行われるケースが多いです。

要求定義を行うことで、開発プロジェクトにおける方向性や目標を明確にし、システム開発の成功確率を高めることができます。また、開発プロジェクトにおいて、発注側と開発側間での要件や目的の共有やコミュニケーションを円滑にする効果も期待できます。以下の比較表で、それぞれの違いの理解を深めましょう。

要件定義を行う目的

要件定義は、「どんなシステムを作るかを明確に定義すること」を目的として行われます。その背景には、システム開発の依頼者、開発者の間で齟齬をなくし、情報を適切に共有するという意図があります。

もし、要件定義を行わずにシステム開発を進めてしまうと、後々のシステム開発において依頼者と開発者との間で認識にズレが生じ、開発の方向性がずれたり、先に定めていれば必要がなかった追加コストや時間がかかってしまったりなど、システム開発がスムーズに進まない原因ともなりまかねません。

また、要件定義が不明確であると、開発会社の中でも必要な機能を見落としたり、手戻りが発生してしまうこともリスクとして挙げられます。要件定義はシステムに携わる全員の認識を揃えるために行われると言っても過言ではありません。

要件定義の位置づけ

要件定義は、システム開発の初期段階で行われる工程であり、開発プロセスの中で最も重要な工程の一つです。

システム開発におけるモデルであるウォーターフォールモデルでは、要件定義が後の工程に大きな影響を与えるため、要件定義の正確性や完全性が不足していると、開発プロセス全体が混乱し、時間とコストがかかる可能性が高くなります。

上記のようなウォーターフォールモデルで進めるシステム開発において、要検定義はその役割をしっかりと果たします。しかし、反対に要件定義ができない場合は、ウォーターフォールモデルを取ることが難しく、アジャイル開発が向いています。つまり、「要件定義ができる/できない」によって、システム開発のモデルを変更が求めれる場合があります。

簡単にいうと、「作りたいもの（機能）が說明できる」場合には要件定義が向いています。システム開発において、作りたいものが明確である方が不明確要素をへらすことができるので、コストも開発工数も少なくできるため、まずはウォーターフォールモデルでの開発を検討した方がよいでしょう。

一方で、要件定義ができないもの、つまり「何が必要か、一旦作ってみないとよくわからない」などの場合には、作りたいものが定まらないため、アジャイル開発と呼ばれる何度も開発を繰り返して作っていく手法が採用されることが多いです。

これは、ウォーターフォールモデルが、要件定義でしっかり固めた内容から外れた開発を行うと手戻りが多く、開発工数を逆に増やしてしまうというところから、アジャイル型が採用されることが多いのですが、アジャイル型の場合は開発のゴールポイントを最初に定めない分、開発工数ばかりが増えていく可能性があるということを前提に置き、開発をコントロールしていく必要があります。

要件定義が存在しないと言われるアジャイル開発にも、開発の指針は共有されていないと何を作ればよいかわからなくなるため、要件定義の代わりのようなかたちで「ユーザーストーリー」というドキュメントを用意して、開発を進めていきます。

要件定義の成果物

要件定義のプロセスにおいて、最終的には、成果物として要件定義書（ドキュメント）を作成することになります。要件定義書は、「システム開発の際に発注者の要望を実現するための機能や画面イメージなどを文書にまとめたもの」であり、システム開発の目的やゴールとなる「なぜ（Why）」と、実装すべき機能や必要な技術・ソフトウェア・ハードウェアなどの「なにを（What）」が明確にされている必要があります。

具体的に、要件定義書の内容は大きく以下のように分けられます。

業務要件

業務要件とは、システムを導入することで実現したい業務上の目標や要件を定義することを指し、「ビジネス上の課題や問題点を明確にし、システムを通じて何を解決したいのか」がまとめられています。業務要件の作成時には、依頼者側は業務に詳しい担当者が打ち合わせに参加するなど、開発会社側の理解・認識への齟齬が生まれないようにすることが大事です。

システム要件

システム要件は、業務要件に基づき、システムに必要な機能や性能などを明確にするための要素であり、システムのハードウェアやソフトウェアの要件、システムのインタフェース、データの管理方法などが含まれます。「システム」での実現可否を検討することで、場合によってはシステム化の対象から外れる業務要件も出てくることがあります。ここで、依頼者側と開発会社側とで歩み寄りながら、実現可能な方法を決めていくことが大切となります。

機能要件

機能要件は、システムに必要な機能を具体的に定義するための要件の一つです。システムに必要な最低限の機能を洗い出し、その機能がどのような操作で実現されるかを明確に定義します。例えば、あるオンラインショップの場合、商品を検索する機能やカートに商品を入れる機能、注文を確定する機能などが機能要件にあたります。また、機能要件は、開発チームが開発すべき機能を確認するために、クライアントやユーザーとのヒアリングを通じて具体的に定義されることが一般的です。

非機能要件

非機能要件は、ユーザーがシステムに求める機能以外の要件を指します。例えば、性能、セキュリティ、信頼性、拡張性、保守性、利便性、品質などが挙げられます。システムが実際に稼働する環境においてどのように動作するか、またシステム利用者にとってどの程度使いやすいかといった点に焦点を当てています。

その他の要件

上記以外にも、要件がある場合は要件定義書に記載するようにしましょう。
（例）

• 技術要件：システムに関するその他の技術的な要件。例えば、プラットフォーム、フレームワーク、開発言語、データベースなどが含まれます。
• 規制要件：システムに関する法的な要件。例えば、知的財産権、個人情報保護法、特定電子メール法、輸出禁止技術などが含まれます。

そのほか、業務要件定義書とシステム要件仕様書の間の関連を示した、要件トレーサビリティマトリクスなども作成すると共通認識を取りやすくなります。

2.要件定義書作成の具体的な進め方

要件定義は、以下のようなプロセスによって進められていきます。要件定義では、依頼者側と開発会社側の認識・理解を揃えていく軸となる部分ですので、ユーザー側となる依頼者企業も積極的に参加することが求められれます。

ステップ①：課題と目標の明確化（システム開発の企画・業務設計）

システム開発を行う際には、必ず解決すべき課題や目標が存在するはずです。たとえば、時間のかかる作業の自動化や新しいアプリの制作などです。このステップでは、なぜシステム開発が必要なのかを明確化します。

具体的には、以下の項目を検討し、課題の特定と理想状態を定義します。

検討項目

• 現状
• 理想状態・ゴール
• 解決すべき課題

ステップ②：システムの全体的な構成を明確化（要求定義）

次に、課題を解決するために必要なシステムの概要と具体的な機能を定義します。具体的のレベルについては、「同時に1000人以上のユーザーがアクセスしても安定して処理するシステム」や「商品の在庫数が0になったら自動で再発注する機能」といった表現であれば十分です。

ここまでのステップ①の内容と、ステップ②の内容を、「提案依頼書（RFP）」としてまとめておくと、複数の開発会社に見積もりを依頼する際に役立ちます。

ステップ③：機能要件/非機能要件を定義

次に、機能要件や非機能要件について定義します。このステップは専門的な概念も含むので、それほど具体的でなくてかまいません。開発者会社側とのコミュニケーションを通して詳細を検討しましょう。

機能要件の整理プロセス

業務フロー図、ER図、データフロー図などを用いて、要件定義の段階で要所を押さえつつ、システム開発に必要な情報を明確にしていきます。
具体的に機能整理する際には、業務フローについて「As is」「 to Be」を定義したり、扱う概念や情報（データ）の構成や流れを整理したり、ユーザーユーザーとシステムの関わり方をユーザーインタフェース（UI）のイメージを持ちながら整理したりと進めていきます。

非機能要件の整理プロセス

性能や容量、セキュリティなど機能以外に満たすべき事項や制約を定義します。その際には、RASIS（Reliability・Availability・Serviceability・Integrity・Security）というフレームワークを用いて、要件の抜け漏れがないように進められることが多いです。

非機能要件について詳しく知りたい場合は、「非機能要件とは？システム開発における重要性を解説」を参照ください。

ステップ④：要件定義書を作成

ここまで決めてきた内容を整理し、今後プロジェクトを進める際に全員の認識が合うようにドキュメントとしてまとめます。

要件定義書を読むことで、どんなシステム開発プロジェクトが始まるのかを一覧できると理想的ですが、作成スケジュールによっては、内容が大雑把になることもあります。特に機能要件や非機能要件の作成に当たっては専門的な知識を必要とするため、焦って作成する必要はありません。

知識の豊富な開発担当側の企業と綿密なコミュニケーションをとりながら、認識の齟齬が生まれないように正確な内容を心掛けるようにしましょう。

完成イメージとしては、以下のサンプルをご参考ください。

▶要件定義書サンプルを見る◀

3.理想的な要件定義書とは

押さえておきたいポイント

理想的な要件定義書を作成する上で、押さえておきたいポイントを紹介します。

開発目的と理由が明確

システムを開発する目的とその理由を明確にすることは、要件定義の中で最も重要なポイントの一つです。明確な開発目的と理由がない場合、開発者と発注者との認識齟齬が生じ、プロジェクトの進捗が遅れたり、コストや品質が悪化することがあります。一方で、開発目的と理由が明確に伝わっている場合、優れた開発会社は他の要件についても柔軟に対応し、プロジェクトを成功に導くことができます。プロジェクトの成否を分ける要素となりますので、開発会社と齟齬がないように徹底的にコミュニケーションを図りましょう。

スコープをはっきりさせる

スコープがあいまいだと、役割分担が不明確で責任の所在で揉めてしまったり、開発過程での方針決定が遅れたりなど、プロジェクトの品質を落としてしまう要因になってしまいます。「ここは依頼範囲となっているだろう」などと思い込まず、スコープとしてテキストベースで役割を明確にしておくことが大事です。

誰が見ても理解できる

要件定義書は、プロジェクトに関わるさまざまな人が確認する重要な書類です。発注者や開発担当のエンジニア、プロジェクトマネージャー、営業担当など、バックグラウンドが異なる人々が読むことがあります。誰が見ても理解できるように、わかりやすい言葉を使い、必要に応じて図表を活用することが大切です。

発注会社が知っておいた方がいい・準備した方がいい3要素

依頼者となる発注会社が知っておいた方がよい要素について整理します。

「開発のプロではないから」と言って開発会社に丸投げしてしまうと、残念ながら、そのプロジェクトが暗礁に乗り上げることが予想されます。「作りたいシステム」を知っているのはあくまでも依頼者側（発注側）であり、費用を支払うのも依頼者側（発注側）です。

万が一プロジェクトがうまく行かなかった場合、不利益を被るのは依頼者である自分たちであるので、依頼者だからこそ、開発に関する理解を深めておくことは大切なのです。

ITに関する学びの意欲を持つ

発注会社の担当者には、多少なりともITに対する理解が求められます。ITの専門用語や技術に疎い場合、要件定義の段階でコミュニケーションに問題が生じる可能性があるため、最低限開発会社側から出てきた言葉については調べるか、開発会社から教えてもらうようにしましょう。

業務を深く理解する

導入目的となるシステムが使われる際の業務を理解しておくことが大事です。直接自分が関わる部署でない場合は、業務への理解が深い担当者をプロジェクトに巻き込めるように調整を図りましょう。せっかくお金と時間をかけて作るシステムですので、「使われる」システムになるように、システムが使われる現場の様子を知っておくことが大事です。

要件定義漏れを防ぐためのフレームワークを把握する

要件定義漏れを防ぐためのフレームワークを把握することも重要です。要件定義自体は、開発会社に作ってもらうケースがほとんどですが、その確認を行い、受領をするのは発注企業である依頼側です。要件定義に抜け漏れがないか確認する必要があります。代表的なフレームワークとしては、「RASIS」「EA（エンタープライズアーキテクチャ）」「5W2H」などがあります。これらのフレームワークを使用することで、必要な情報を漏れなく収集し、要件定義書の質を向上させることができます。

4.システム開発がうまくいく要件定義の作り方

それでは、どのようにすれば要件定義をうまく進めることができるのでしょうか？まず、大切にしていただきたいのが、要件定義工程における発注側の積極的な情報共有です。

開発会社から質問を受けたり、その場でわからないことを確認・準備することは、少々面倒くさいことかもしれませんが、開発会社から「質問がある」ということは、その項目はシステム開発する上で重要な要素ということです。

どのように回答すればよいかわからない場合は、開発会社側にそのまま「どのようにお伝えすればよいですか？」などと聞いてみるとよいでしょう。その回答例などをわかりやすく説明してくれる開発会社であれば、そのまま依頼を進めていってもコミュニケーションが取りやすいかと思います。

一方で、そのときの回答方法を教えてもらえなかったり、よくわからないという場合は、その開発会社とは相性があまりよくないという可能性も出てきますので、今後一緒に長くプロジェクトを進めていくためにも、そのような場合は立ち止まって開発会社の見直しなども候補に入れてみたほうがよいかもしれません。

さて、すこし前置きが長くなりましたが、システム開発における要件定義の進め方のポイントを紹介していきます。

打ち合わせ回数を決めてから実施する

要件定義を固めていく中で、何度かの打ち合わせを行いますが、その回数も予め決めておくことはとても重要です。例えば、要件定義を行う期間において定例で決めて実施するのか、もしくはいつ打ち合わせを行うかを予め日程を決めてしまうのか、何れにしてもどちらか決めて、なんとなく打ち合わせをするということは避けたほうが良いです。

また、打ち合わせを行うためのアジェンダ作成、実施後は議事録を残して共有するなど、後から見返せるようにすることや、言った、言わないで揉めそうなことは予め避けるための行動が必要です。

成果物の共有

要件定義書に記載するものとして、イメージしている成果物が何なのかを記載しておく必要があります。システム開発側とそのイメージのコンセンサスを取っていないと、「あれが必要だった」「いや聞いてない」などの言った言わない問題が生じる可能性が十分にありえます。また、仕様書に関しても、どのようなレベルの仕様書が必要なのか、そこも明記しておきましょう。

役割分担

要件定義が決まったら、開発会社へすべて丸投げは避けるべきです。開発を進めていく中で、細かい仕様の調整や確認が必要になってきます。依頼元の確認やジャッジがなければ、基本的にはシステム開発を進めることはできません。

5.要件定義を外注する際のポイント

要件定義を依頼する際の注意点

RFPを用意する

「要件定義」に対して見積もりを依頼する場合は、上で説明してきた要件定義として必要な項目や、何のためのシステム開発なのか？などをまとめたRFP（提案要望書）を用意し、開発会社へ渡すことが理想的です。

RFPは要件定義のもとになるような情報が揃っているため、比較的どれくらい工数がかかるのかが出しやすくなります。

RFPの項目としては下記を揃えておくとよいでしょう。

RFPの一般的な記載項目

• プロジェクトの概要
• 背景・課題
• ゴール、達成目標
• 依頼範囲（スコープ)
• 成果物
• 機能要件、非機能要件
• 予算
• スケジュール

機能要件にはシステムに入れたいと考えている希望の機能を記載します。非機能要件は、もし現在の課題で「読み込み速度が遅い」「●●のバージョンまで稼働できるようにしてほしい」などの希望があれば記載しておきましょう。

実際、機能要件や非機能要件は、開発側からの確認内容も含めて要件定義にて細かくすり合わせていく内容になりますので、おおよその希望がわかるよう抽象的でも大丈夫ですので、困っていることや解決したいことを記載しておくことが大切です。それがあることで、開発会社側も実現方法などを考えて提案を行うことができるようになります。

必須要件と希望要件を切り分ける

要件定義の段階で必須要件と希望要件を切り分けることは、後々のスムーズな開発や、システムの利用者にとって必要な機能が実装されることを保証するために非常に重要なポイントとなります。必須要件に優先的にリソースを割り当てることで、優先度の高い機能の実装が保証され、リソースの最適配分が可能になるほか、開発のリスクを最小限に抑えることができます。

必須要件と希望要件を明確に分けておくことで、後からシステムに機能を追加することが容易になり、必須要件が実装されている状態であれば、希望要件をあらかじめ設定された優先順位のもと、順次実装していくことができます。

スケジュールやエラー対応方法の共有

開発プロセス全体を予定通りに進めるために、スケジュールやマイルストーン、作業内容などを共有し、関係者全員が同じ方向を向いて進むことが重要です。

また、要件定義の段階で、システムのエラー対応を前もって想定して準備しておくことも重要です。想定されていない使われ方がされてしまうこともあるため、システムの利用者がエラーに遭遇した場合にどのような対応をするか、あらかじめ考えておくことが必要です。このように、スケジュールやロードマップの共有とともに、リスクマネジメントにも十分な配慮が必要となります。

複数社への見積もり

また、要件定義の見積もり依頼をする場合、複数社の開発会社へお願いすることをお勧めします。もちろん要件定義の先のシステム開発を行うところまでを想定して開発会社を選定した方が良いですが、要件定義をお願いする会社と、開発会社を分けることもできます。

特に初めての発注を行うという場合は、発注会社との相性というものもありますので、何社か話を聞いてみることが大切です。ただし、あまりに問合せをしすぎると判断に迷うこともあるので、3〜5社程度がよいかと思います。

要件定義の作成に関して、複数社から見積もりを取得するなら、「リカイゼン」をご利用ください。リカイゼンでは300社以上の実績ある開発会社から要望に応じた会社を無料で紹介してもらうことが可能です。見積の相談をする会社探しも1社1社行うと大変な作業ですので、そのような場合はリカイゼンにお気軽にご相談ください。

何れにしても、しっかりとした要件定義書があれば、後に続く開発工数も明確に出すことができますし、スムーズにプログラム開発が行えるのです。

要件定義を依頼する開発会社の選定ポイント

それでは、実際に要件定義をシステム開発会社に依頼するときは、どのような開発会社に依頼したらよいのでしょうか。システム開発会社は数多く存在しますが、中には「開発」することを得意とし、要件定義のような上流工程はあまり経験がないという会社も存在します。また、要件定義でも、具体的に依頼者側の要望がまとまっていれば対応できるけれども、抽象度が高い場合はあまり得意ではないという会社もあります。

要件定義が得意ではない会社に依頼をすると、システム開発の最初のポイントで躓くことになってしまうので、依頼先の見極めは重要です。

要件定義に対してノウハウを持っているか

依頼者である発注企業の社内だけで要件定義を正確に行えない場合、開発会社側が要件定義に対してノウハウを持っているか非常に重要となります。要件定義は、システム開発において最も重要な工程の一つであり、要件を正確に定義することができなければ、システムが期待通りに動作しない可能性があります。過去に上流工程から携わった成功事例や、要件定義に関する具体的な提案があるかどうかを確認し、要件定義をサポートしてくれそうか検討しましょう。

業務コンサルを得意・知見があるか

要件定義は、一般的に「上流工程」と呼ばれるもので、依頼者側の「やりたいこと」を整理し、システムに落とし込んでいく必要があります。依頼者側で想定している「やりたいこと」についても、本来はもっとよいやり方や方法があるかもしれません。そのような場合に、業務コンサルなど業務への理解・会社業態への理解があるシステム開発会社であれば、過去の実績も踏まえ、よりよい提案を行ってもらえる可能性があります。他社の成功事例・失敗事例を数多く知っているということも、外注を行うメリットの1つですので、開発会社の知見を見極めることもポイントとなります。

ヒアリングや提案を積極的に行えるか

開発会社側が積極的にヒアリングを行い、必要な情報を的確に引き出し、要件定義に反映させることができるかどうかは、システムの開発プロセス全体の品質に直結します。そのため、システム開発会社のコミュニケーション能力を見極めることが大事です。依頼者側が言ったことのみを対応する場合は要注意、依頼者側が気づいていなかった点などにも踏み込んで提案してくれたり、ヒアリングしてくれる会社を選びましょう。

6.おすすめの要件定義から開発を行える会社4選

ここでは、要件定義からシステム開発を行える会社を4社紹介いたします。

株式会社ウォーカー

株式会社ウォーカーは東京都文京区に本社を置くシステム開発会社です。

Webアプリケーション開発、システム開発、データ解析、ITコンサルティングなどを主な事業としてサービスを提供しています。

AI開発、コンサルテイングを軸に、webメディア、業務システムなど様々な領域で言語問わず、ソリューションを提供できてる点が特徴です。

実現可能性に関わらずお客様のすべての要望に対して「最も効果的な解決策」を提示出来る点が大きな魅力です。

AMELAジャパン株式会社

AMELAジャパン株式会社は東京都江東区に本社を置くシステム開発会社です。

主な事業内容として受託開発、オフショア開発、エンジニア派遣、ITコンサルティングなどのサービスを提供しています。

広い業界知識を活かして上流工程から対応可能な開発体制が大きな強みです。

またマッチング系のスマホアプリ、フリマアプリ、SNS系アプリなども得意としており、要件定義や企画から開発後の保守運用までワンストップで対応することが可能です。

exmilen合同会社

exmilen合同会社は東京都中央区に本社を置くITコンサルティング会社です。

主な事業内容としてITコンサルティング、システム開発、サービス企画・開発・運営などのサービスを提供しています。

全てのメンバーが業界水準以上（コンサルティングファームにおけるマネージャー以上）のベーススキルを持ち、かつ特定の領域に対する専門性を相互補完する形で少数精鋭の組織をコンセプトとしています。

この強みを活かした、広い守備範囲、高い品質とデリバリスピード、及び最適なコストを提供しています。　

株式会社エーブリッジ

株式会社エーブリッジは東京都千代田区にあるシステム開発会社です。ITシステム全般に関するコンサルティング、開発、運用支援を行っており、企業のITシステムをトータルでサポートしています。

システム導入時において、投資対効果の考慮や実際の運用においてのアドバイスまで、あくまでも事業成長に役立つための提案を強みとしています。

また開発パートナーとの協業ネットワークを構築しているため、お客様の要望に併せたコスト、スケジュール感での提案が可能です。

7．要件定義の外注まとめ

システム開発における要件定義の進め方の大切さについて説明してきました。ただ、初めての要件定義を進めていく場合や、これまで行なっていたことが正しいかどうか分からないなどあると思います。

そのような時、多くのビジネスマッチング実績を持つリカイゼンでは、サポートデスクにて無料で対応させていただくことができます。システム開発では、まだ予算が確定していないなどよくあることですので、まずは相談ベースでのご連絡、要件定義の進め方に関するご相談もお待ちしております。プロのサポートを取り入れて、より良いシステムづくりにお役立てください。