ソフトウェアの要件定義とは？システム開発時のプロセスやコツを解説
こんにちは。Wakka Inc.のWebディレクターの安藤です。
ソフトウェアやシステムを開発する上で、実施する業務を固めるのが要件定義です。開発のプロジェクトを成功に導くには、必要な要素を落とし込んだ要件定義を作成する必要があります。
本記事では要件定義はどのようなものか、また開発時のプロセスや要件定義のまとめ方のコツなどを解説いたします。
「ソフトウェアやシステムを発注したが、納品物が思っていたものと違う」
「現在開発中のシステムは、どのような仕様で発注したか確認したい」
といった悩みをお持ちの方はもちろん、自社の思い描いたものとズレのないシステムを開発したいとお考えの方もぜひ参考になさってください。
ソフトウェア開発にはラボ型開発がおすすめ。
SaaSにラボ型開発が最適な理由の資料では、ラボ型開発を活用した柔軟な体制構築ノウハウを解説しています。まずはお気軽にダウンロードしてみてください。
システム開発を検討されている方に向けてすぐに使える『RFP（提案依頼書）テンプレート』をご用意！
編集しやすいパワーポイント形式のテンプレートなので、項目を埋めるだけで簡単にRFPが作成できます。
システム開発におけるソフトウェアの要件定義とは
システム開発におけるソフトウェアの要件定義とは、開発の土台を意味します。開発の前段階で「どのような機能を実装するのか？」「どのくらいコストが発生するのか？」などを明確にするために必要です。
要件定義は非常に重要なものですが、具体的にどの点に注目すべきなのでしょうか。
要件定義は最重要項目
ソフトウェア開発やシステム開発時における要件定義は、最重要項目といっても過言ではないでしょう。要件定義の実際の業務とは、開発に至るプロセスや、業務上行うべき内容をあらかじめ文章化する作業を指します。
要件定義を定めておかないと、必要な機能が実装されていなかったり、求めていたソフトウェアと違うものになったりしかねません。
要件定義書は発注元と開発側の役割分担を明確にするのにも役立ちます。開発をベンダーに丸投げするのではなく、「自社がどれくらいのリソースを持っているか？」の確認作業も必要になるでしょう。
例えば既存のシステムの改修では、現在稼働中のシステムの中身を把握する作業が重要です。
内部の状態によって、ベンダーが開発にどの程度携われば良いかが決まってくるからです。要件定義は開発の骨組みを作る作業なので、念入りに行えば行うほどプロジェクトが成功する確率は上がります。
また要件定義書は開発に携わったメンバー以外が見ても容易に理解できるように、わかりやすく作成しましょう。
専門的な知識を持ち合わせていないメンバーでも理解できるということは、要件定義にズレが生じていない状態と言えます。
あとから「なぜこのシステムを構築したのか？」などの疑問が生じると、システムの再設計にも繋がりかねません。ソフトウェアやシステム開発の骨組みとなる要件定義は、システムを思い通りに稼働させるために念入りに定める必要があるのです。
要件定義と要求定義の違い
要件定義と似たような言葉に、要求定義があります。要件定義はソフトウェアを設計するための設計図のようなものですが、要求定義は発注元の要望を整理するためのものです。
「新しく開発するソフトウェアにどのような機能を求めているのか？」「実装までの期間はどの程度必要なのか？」など、様々な要求を整理していきます。
つまり要求定義は、要件定義を作るための基礎となるのです。
開発元の要求を丁寧にヒアリングし、実装に必要な機能を細分化していくことで要件定義の作成に移ります。要求定義はすべてが実装可能とは限りません。期間や予算の問題で実行できないものもあるでしょう。
必要な機能の洗い出しや、実装できないものの範囲を定めておくことで、認識のズレを少なくできます。
認識のズレが大きくなってしまうとプロジェクトが失敗してしまう可能性もあるため、要件定義と要求定義のすり合わせは重要な工程なのです。
上流工程と下流工程
ソフトウェアやシステムを開発する際によく用いられる用語として上流工程、下流工程があります。文字通り、川の流れにたとえて表現されており、上流工程はプロジェクトの前半で定める重要な部分です。
要件定義は最重要項目なので、上流工程に位置づけられます。他に上流工程に該当する業務は
- プロジェクトの計画
- 基本設計
- 発注元とベンダーとの商談
などが該当します。上流工程を固めておかないと、下流工程に大きな影響があるでしょう。
下流工程は実際のプログラムなど、基本設計や要件定義に沿った開発プロセスです。下流工程に該当する業務は
- 詳細設計
- ソースコードの記述
- テスト運用
などが該当します。プロジェクトの計画や要件定義、基本設計がずれてしまうと、詳細設計からやり直す必要が出てくるため、大きな時間と費用のロスが生じるでしょう。
上流工程に該当する業務は、発注元からの丁寧なヒアリングを重ね、土台を固める必要があるのです。
ソフトウェアの要件定義を行う具体的なプロセス
ソフトウェアやシステムの要件定義をスムーズに行うためには、どのようなプロセスが必要なのでしょうか。
課題を明確に
ソフトウェアやシステムを開発する際は、「既存のシステムではできないこと」「新システムによって解決したいこと」など様々な課題があるはずです。
既存システムの中身を十分に把握する作業が必要なのは、課題を明確化するために他なりません。
システムの改修を行わなくても、既存のシステムで企業の課題を解決できる可能性もあるためです。まずは現状の業務モデルについて、ワークフロー*形式で書き出すのがおすすめです。
ワークフロー形式で書き出すと、「どこに問題点が潜んでいるか？」を明確にするのに役立ちます。
「どのような業務プロセスにしたいか？」といった要望もワークフロー形式でまとめましょう。開発前のシステムと開発後のシステムを比べれば、追加すべき作業や削除すべき作業工程など様々な課題が見えてくるはずです。
課題が明確になれば、方向性が定まるため、開発途中での調整も合意のもとに進められるでしょう。
開発の土台を整えるために、まずは要求定義で「なぜソフトウェアやシステムを開発したいのか？」を丁寧にヒアリングして、目的や必要な機能を明確にしていきます。
丁寧なヒアリングを行うことで、システムの全体像が見渡せるでしょう。
※ワークフロー……業務についての一連の流れを図式化したもの。
機能の細分化
問題点の把握ができた時点で、その問題点にどのようにアプローチしていくかを決めていきましょう。業務フローとも照らしながら、現在のシステムに足すべき機能や削除すべき機能を要件化していきます。
重要なのは、実装すべき機能を取りこぼさないことです。
しかし、すべてを実装できるわけではないため、ベンダー側として実装できる要件とできない要件の線引きは明確にしておきましょう。
使用するインターフェイスを定める
ユーザーが利用するシチュエーションを定義するのも重要です。UI（ユーザーインターフェイス）を定め、ユーザーがどのようなシチュエーションでシステムに関わるのかもヒアリングしていきましょう。
ユーザーがスマートフォンのみで利用するソフトウェアの場合、PC向けのUIを開発するのは不適当です。またOSも異なるため、UIを定めない限り、開発自体がスタートできない恐れもあります。
「開発されたソフトウェアがどのようにユーザーに利用されるか？」を想定するのも非常に重要な要件なのです。
非機能要件を明確にする
非機能要件とは、システムが持つ機能以外の要件を指します。具体的な要件は
- 可用性：システムを継続的に利用可能にする要件
- 拡張性：システムの処理性能や、将来に向けたキャパシティのあり方の要件
- 保守：バックアップの方法や、トラブル時の対応などの要件
- 移行性：新システムに乗り換えるための要件。移行期間や移行手法などを定義する
- セキュリティ：セキュリテイの確保、運用方法、教育について定義する
- システム環境・エコロジー：消費エネルギーなどエコロジーに関する項目を定義する
これらが非機能要件に該当します。非機能要件を明確にするのは非常に大切な作業です。
開発依頼者とベンダーの打ち合わせの中で、大きな主題は機能要求ではないでしょうか。細かい非機能要求について話が出てくることは少ないかもしれません。
システムの専門家であるベンダーから、非機能要求について提案を受ける場面が多いです。一方的なベンダー側の主張ではなく、メリット・デメリットを提示してもらい、開発依頼者が選択しやすくするのも大事なことでしょう。
予算を定める
要件定義により、ソフトウェアやシステムの実装に必要な工程が定められたら、予算の検討を行います。
要求定義すべてを実装すると依頼側の予算がオーバーする可能性もあるため、まずは総工程についての見積もりを作成します。
そこで期間や予算についての妥当性を話し合い、もし要件定義がずれる場合はこの段階で修正しましょう。出戻り開発になると、期間や予算が大幅にずれてしまうためです。
仮に予算内に収まりそうな場合でも、期間が押してしまうかもしれません。その場合、一部の機能を外注するなどの対応も必要になるでしょう。
システム開発の予算はエンジニアの人件費に依存します。外注する場合は外注費も見積もりの中に入れる必要があるため、発注元との合意が必要です。
アサインする人員を決める
要求定義が定まり、非要件定義も定まったあとは、プロジェクトにアサインする人員を定めましょう。アサインする人員は誰でも良いというわけではありません。
要件定義で決定したソフトウェアを実装できるスキルがないと、開発が前に進まないためです。細分化した業務に適した人員をアサインしましょう。
総合的にスキルが高いエンジニアは、採用コストが高い傾向にあります。予算との兼ね合いもあるため、アサインする人員を決めてから予算の見積もりを出したほうが、交渉がスムーズに進むでしょう。
アサインするメンバーのスキルを見極め、細分化した業務に適した人員を配置するマネジメント力も必要となります。
システム開発を検討されている方に向けてすぐに使える『RFP（提案依頼書）テンプレート』をご用意！
編集しやすいパワーポイント形式のテンプレートなので、項目を埋めるだけで簡単にRFPが作成できます。
ソフトウェアの要件定義に役立つテンプレート
要件定義を定めるためには、ある程度型のようなものがあるとブレが少なくなくなり、プロジェクトを成功に導けるでしょう。要件定義でよく使われる代表的なテンプレートをご紹介いたします。
5W2H
5W2Hは、要件定義の前に「システムやアプリケーションをなぜ構築したいのか？」を整理するのに役立ちます。細かいアプリケーションの挙動などを定める前に、まず5W2Hを利用して要点を整理しましょう。
目的や手法が定まると、アプリケーションがズレなく稼働し、出戻り開発などの手間を減らせます。5W2Hは以下の項目で構成されています。
- Who（誰の協力が必要か、社外の力も必要か）
- What（どのような課題を解決するのか）
- When（いつまでに開発するのか）
- Where（どのシステムやアプリケーションを対象にするか）
- Why（どのようなことを目的とするか）
- How（どのような手法で開発するのか）
- How much（どれぐらいの予算で開発するのか）
7項目を詳細に詰めていけば、案件定義がぶれにくくなり、プロジェクトが成功に近づくでしょう。
EA
EAは要件定義を効率的に設計できるフレームワークです。EAとは「エンタープライズ・アーキテクチャ」の略で、経営戦略とITを総合的に最適化し、顧客ニーズや社会環境に対応する構造を構築できます。
2000年代より利用されてきたフレームワークで、要件定義の全体像を把握するのに役立つのです。
EAを構築すると、組織全体として統一化されたシステムや効率の良い業務プロセスを手にできるので、より良いシステムやソフトウェアが実装可能です。EAは以下の4つの構造で構成されています。
BA（ビジネス・アーキテクチャ）
BAは企業全体の組織構造などを定め、業務プロセスをモデル化したものです。現在のビジネスモデル自体を反映するだけでなく、「未来においてどのようなビジネスモデルを展開したいか？」を示す設計図になります。
現在と未来のビジネスモデルのギャップを埋めるために、必要なシステムやソフトウェアをどう構築するかの判断材料になるでしょう。
AA（アプリケーション・アーキテクチャ）
AAはビジネス環境を整備するために、どのアプリケーションを利用するかを定めたものです。
昨今ではWeb会議のツール、チャットツールなど様々なサービスがリリースされていますが、企業全体で利用する共通のアプリケーションを定めます。
AAを定めることで「ビジネスの生産性向上にどの程度貢献するか？」が、各アプリケーション選定の判断材料のひとつとなります。
DA（データ・アーキテクチャ）
DAは、企業が扱うデータの属性情報などを定めたものです。データをどのように再利用するか、またセキュリティ、品質管理などデータに関する様々なものを定めます。
データは正しく保持し、管理されなくてはいけませんが、適切な時期に廃棄する必要も出てくるでしょう。
「どのような手法でデータを廃棄するのか？」「どの程度の期間で廃棄するのか？」など、データの取り扱いを詳細に定めていきます。
TA（テクノロジー・アーキテクチャ）
TAは、会社のIT基盤としてどのようなハードウェアを利用するかを定めたものです。AAはソフトウェアの定義でしたが、TAでは会社で利用するネットワーク、OSなど物理的なインフラを定めます。
またソフトウェアを開発する場合には「どのようなプラットフォームを利用するか？」も定めます。定められたTAが生産性や可用性にどの程度貢献できるかが、各種ハードウェア選定の判断材料のひとつとなるでしょう。
RASIS
RASIS（レイシス）は、非要件定義を定めるのに使われるテンプレートです。
- R（Reliability）
- A（Availability）
- S（Serviceability）
- I （Integrity）
- S（Security）
の頭文字をとった用語です。具体的にどのような指標が非要件定義として利用されるのでしょうか。
R（Reliability）：信頼性
信頼性とは、システムやソフトウェアの壊れにくさを表します。一度導入したシステムやソフトウェアに、生涯に渡って不具合や障害が発生しないことはまずありえません。
しかし、不具合や障害を減らすことは可能です。システムやソフトウェアが安定的に稼働できる平均時間などは、信頼性の指標になるでしょう。安定して稼働できる時間が長ければ長いほど、信頼性は高くなります。
A（Availability）：可用性
可用性とは「システムやソフトウェアがどれだけ長い期間稼働できるか？」を示す指標です。
可用性は信頼性と密接な関係があり、システムの壊れにくさや稼働期間が総合的に判定されます。システムを長期間運用しなくてはいけない事業者は、可用性、信頼性の高さは特に重視すべきでしょう。
S（Serviceability）：保守性
保守性は、システムやソフトウェアの機能の維持しやすさを示す指標です。システムの場合は、ハードウエアのメンテナンスのしやすさなどが判定ポイントです。
ソフトウェアの場合は「不具合が起きたときに、修正をどれだけ容易に行えるか？」も重要な要素でしょう。保守性の高さは、可用性と密接な関係があります。
メンテナンスにかかる時間が短いほど、システムの稼働率が上がり、可用性も高まるためです。
I（Integrity）：保全性
保全性とは、データやシステムが完全に保たれている状況を示す指標です。
「システムの不具合や誤操作、障害などでデータが破損してしまった場合でも、元のデータが完全に保たれているか？」がポイントです。素早く元の状態に戻ればシステムの稼働率が上がるため、保全性が高い状態は可用性にも良い影響を与えます。
S（Security）：機密性
機密性とは、「システムで利用するデータに対して高いセキュリティを維持できるか？」を示す指標です。
例えば個人情報などの重要なデータが外部流出してしまった場合は、システムの稼働を停止し、どこに不具合が潜んでいるかを調べる必要があるでしょう。
「扱うデータがどのように管理されていて、外部からの不正アクセスなどの対策ができているか？」がポイントとなります。
漏えい対策だけではなく、事故を未然に防ぐためのセキュリティ教育なども重要な要素となるでしょう。機密性の高いシステムは、高稼働率を維持できるため、可用性を高めるのにも役立ちます。
ソフトウェアの要件定義とシステム開発の要件定義の違い
要件定義に関わるよく似た用語として、ソフトウェアの要件定義とシステム開発の要件定義があります。それぞれどのような違いがあるのでしょうか。
システム開発の要件定義
システム開発とは、企業が抱える課題を解決するための仕組みづくりです。企業の課題はコストの軽減、業務の効率化、新規事業の参入など、実に様々なものがあります。
このような課題をコンピューター上で解決するための仕組みづくりがシステム開発です。
そのため、システム開発の要件定義は企業の課題の深堀りからはじめ、企業の持つインフラについての理解も必要になります。
場合によってはインフラの再整備など、ソフトウェア開発よりも、より上流の工程まで定義する必要も出てくるでしょう。
ソフトウェアの要件定義
ソフトウェアの要件定義で重要になるのは、「開発したソフトウェアがどこで運用されるか？」ではないでしょうか。求められる機能を実装するのはもちろん、どのような場面で活用するかも要件定義の中で定める必要があります。
例えばモバイル環境で利用されるアプリやソフトウェアならば、スマートフォンなどにダウンロードして利用されるのことが想定されます。
また家電や自動車などに組み込まれるソフトウェアが必要とされるケースもあるでしょう。ソフトウェアの要件定義で重要なのは、「開発するソフトウェアがどこで稼働するか？」までをしっかりと定義することです。
要件定義を行う際に必要なスキル
質の高い要件定義は、開発元にもベンダーにも大きなメリットがあることがわかりました。
しかし、要件定義はプロジェクト全体の上流工程のため、ミスがあったりズレが生じてしまったりすると、プロジェクト進行の大きな妨げとなりかねません。要件定義をスムーズに進めるためには、どのような能力が必要でしょうか。
ITリテラシー
ITリテラシーの高さはソフトウェア、システム開発共に重要な要素です。システムやソフトウェアは細かいプログラミングをまとめ上げたものです。
大きな集合体をいきなり作るのではなく、細かい機能を分散して作成していくため、開発元の要求定義から必要な時間や工程などを逆算できます。
ITリテラシーが高ければ必要な時間や工程、人員などを把握しやすくなるため、作業工程の設計もスムーズに行えるでしょう。要件定義を定める段階では、プログラミングのスキル自体は必須ではありません。
しかし全体像を把握しなくてはいけないため、ITリテラシーは非常に重要になってくるでしょう。
コミュニケーション能力
コミュニケーション能力は要求定義と要件定義を詰めるために必要な能力です。コンピューター上だけでなく、アナログな作業も含めて、業務全体のプロセスがどのように動いているのかを丁寧にヒアリングする必要があります。
要求定義をすべて実装できるわけではありません。ときには発注元との交渉や調整が必要な場合もあるでしょう。
ベンダーとしての発信力はもちろんですが、開発元の詳細な要求までヒアリングで吸い上げる能力は、要件定義では大切なスキルです。
イメージ力
ITリテラシーとコミュニケーション能力を複合的に合わせたのがイメージ力です。
要求定義をシステム化した場合、「どのようなプログラミングが必要なのか？」「利用者はどのようなシチュエーションで利用するのか？」などをイメージできる力が必要です。
プログラミング自体は指示された通りにしか動きませんが、「指示された内容がユーザーの望むような状況か？」は明確にイメージできるのが望ましいでしょう。
プログラミングがユーザーの要求を満たしていない場合には、再度コードを書く工程が発生してしまいます。システムがどのように動き、どのようなプログラミングが必要かをイメージする力は、要件定義をスムーズに作成するには重要なスキルと言えます。
まとめ | ソフトウェア開発は経験豊富なベンダーに依頼しよう
今回は、システムやソフトウェアの開発時に重要な要件定義について解説いたしました。
要件定義には様々なものがありますが、満足できる成果物を求めるならば、開発経験が豊富なベンダーに相談するのが近道と言えるでしょう。要件定義はもちろん、非要件定義についての提案も十分に行ってくれるはずです。
ヒアリングやコミュニケーションを重ねたシステム開発で、大きなビジネスチャンスを掴んでください。
システム開発を検討されている方に向けてすぐに使える『RFP（提案依頼書）テンプレート』をご用意！
編集しやすいパワーポイント形式のテンプレートなので、項目を埋めるだけで簡単にRFPが作成できます。
▼参考記事
学生時代にWebサイトを自作したことがきっかけでWebの世界に。制作会社でデザイン、WordPressテーマ開発の実務を経て、テクニカル・ディレクターとして大規模サイト構築のディレクションを経験。2021年からWakka Inc.の日本拠点でWebディレクターとして参画。最近はブロックエディタになったWordPressをもう一度、勉強しています。
