どのようなシステムであっても設計・実装の前に、要件定義は必ず行います。システムに搭載する機能や品質などを明確にし、依頼側と開発側で共通認識を持つためです。
しかし、どのように要件定義をすればよいのか、そもそも何を決めるべきかわからない方もいるでしょう。
本記事では、システム開発における要件定義の概要や進め方、失敗しないためのコツをご紹介します。理想のシステムを構築するために、ぜひ参考にしてください。
アプリ・システム開発のプロが開発のお悩みを解決します
アプリ・システム開発の6割が失敗すると言われています。クライアントのリピート率100%のリレイスにご相談ください。
＼ まずは無料相談！1営業日以内に返信 ／
目次
要件定義とは
要件定義とは、システムを構築する際に必要な機能や条件を文章化する作業です。プロジェクトメンバー同士ではもちろん、開発会社とクライアントでも要件定義をしてどのような完成物を目指すのかを共有します。
要件定義で文章化する内容は、以下のようなものです。
- 開発目的・目標
- ターゲット
- 搭載機能
- スケジュール（納期）
- 開発予算
- 開発メンバー（必要な人員）
- 実装の手順
このような内容を具体的に言語化すると開発の方向性が定まり、プロジェクトを円滑に進められるようになります。
曖昧な内容にしたり、コンセンサスを取れていなかったりすると、想定していたシステムと完成したシステムに大きな乖離が生まれてしまうでしょう。それほど要件定義はプロジェクトの成功を左右する重要な作業なため、時間をかけて検討し、意識の共有をしましょう。
また、要件定義は開発予算にも大きな影響を与えます。もちろん、高度な機能を豊富に盛り込みたい場合、コストがかかってしまいます。しかし、いくらでもコストをかけて良いというケースは少なく、予算に合わせた機能に調整しなければなりません。要件定義は要求したい項目と予算のバランスを取る作業でもあると認識しましょう。
要件定義と要求定義との違い
要件定義と要求定義では、行う人物が異なります。
要求定義とは、システムを作ってほしいと依頼する人や企業がシステムに求める仕様を文章化したものです。システム開発の目的や市場の需要を定義し、システムを使って何を実現させたいかを定義します。
あくまでも、依頼側が希望や要望を書いたものであり、すべてが実現できるとは限りません。しかし、要求定義をもとに要件定義を作成していくため、必要な要求をすべて盛り込んでおく必要があります。
一方、要件定義は、要求定義を受けて技術者やシステム開発会社がシステムを実際に動かすための仕様を文章化したものです。依頼側の要望をどのようにシステム開発していくかを決定していきます。
要求定義に書かれている目的や市場の需要、予算を見て内容を精査し、どれほど実現できるかを検討します。そのため、ここでは具体的な手段や機能について文章化し、依頼側と合意をとっていかなければなりません。
このように、依頼側が要求定義を行い、それを受けて技術者やシステム開発会社が実現可能な内容を精査してシステム開発の大枠を要件定義で定めていきます。
要件定義と基本設計の違い
要件定義と基本設計では、決める内容が異なります。
基本設計とは、要件定義で定めた機能を具体化するために必要な設計作業です。要件定義では搭載する機能について「言葉」で表しますが、基本設計は「ビジュアル」で表します。画面イメージとして設計することで、開発内容に認識の違いが出ていないか確認できます。
基本設計で定める内容の例は、以下の通りです。
- 画面レイアウト
- 帳票レイアウト
- 画面遷移図
- コード一覧
- システムインターフェース
このように、要件定義に書かれた機能ごとにシステムの仕様を具体化・明確化させます。
システム要件定義とソフトウェア要件定義の違い
システム要件定義とソフトウェア要件定義では、要件定義する内容が異なります。
システム要件定義ではシステム開発全体の要件定義を行いますが、ソフトウェア要件定義ではシステムのうちのソフトウェアの部分の要件を定義します。
なぜ2つの要件定義を行うのかと言うと、システム開発におけるソフトウェア部分が重要だからです。ソフトウェアにはユーザーが操作するために利用するユーザーインターフェースや情報収集するためのデータベースなどが含まれます。
ソフトウェアだけの要件定義をしておかなければ、ユーザーが体験できる内容が想定と異なって完成してしまうかもしれません。実現したいことをより具体化させるためにソフトウェア要件定義を行うと覚えておきましょう。
要件定義の重要項目
要件定義における重要項目は、以下の4つです。
- 機能要件
- 性能要件
- 品質要件
- 実行計画
どの項目も、システム開発を進めるうえで重要な内容です。曖昧なまま進めると、「無駄な高機能を付けて予算がオーバーした」「完成したシステムが想定通りの動作をしてくれない」といったトラブルに発展しかねません。
1つずつ詳しく確認しましょう。
機能要件
機能要件では、依頼側がシステムに求める機能を定義します。システムを導入して、どのような体験ができ、どのような効果があるのかといった部分です。
業務システムであれば、「商品の在庫検索ができる」「売上順・価格順に商品の並び替えができる」「指定したデータのみを抽出する」など、搭載したい機能を具体化していきます。
「商品検索ができる」の機能であっても、「フリーワード検索」「カテゴリー検索」「条件検索（価格・在庫有無など）」などの機能を搭載するかどうかまで定めていきます。
性能要件
性能要件では、システムの処理能力を定義します。
ある処理をするために、どれくらいのスピードで処理させるかを具体化するために、前提条件と目標値を定めます。
前提条件とは、処理をするデータの数や取引数、ユーザー数などです。在庫管理システムであれば「データベースに掲載する商品数」「同時にアクセスする従業員数」などを想定しておく必要があります。
一方、目標値とは「応答時間3秒以内」「データ処理能力は1,500件/秒」などの処理スピードです。在庫管理システムなら、「検索結果表示は5秒以内」「分析処理に7秒以内」などと目標を定めます。
前提条件と目標の処理スピードを依頼側が提示し、実現可能な性能を両者で定めていきます。
品質要件
品質要件では、開発するシステムの品質基準を定義します。品質を定義づけることはむずかしく、ユーザーが求める特性と合致するかどうかに焦点を当てます。
一般的に品質要件で検討される項目は、以下の通りです。
- ユーザーの使い勝手
- 期待される性能レベル
- システムが満たす要件
- セキュリティレベル
このような項目について明確に基準を設定し、完成後品質が保たれているかを評価します。
実行計画
実行計画では、各要件を満たすシステムを開発するために必要な工数やコストを定義します。
工数では、開発作業にあたる人員の数や納期を決めます。納期を早めるために人員を増やすことも可能です。各工程後のタスク開始時期・終了時期のタイムラインや、開発者・デザイナーなどの役割やリソースの割り当ても定義します。
また、工数や要件にあわせてコストも確定させます。開発内容や全体のスケジュール、開発に関わるメンバーが確定しなければ、見積書は提示されません。あとから必要な機能を追加で要求すると、必要な人員が増えたり、スケジュールが押したりするため、追加費用が発生します。
要件定義でしっかりと開発するシステム内容や実行計画を定め、円滑に開発を進めましょう。
システム開発における要件定義作成の流れ
システム開発における要件定義作成の流れは、以下の通りです。
- 課題と目標の明確化する
- 要件の抜け・漏れが無いか確認する
- システムの全体構成・内容を明確化する
- 機能要件を定義する
- 非機能要件を定義する
- 要件を評価し要件をブラッシュアップする
- プロジェクトを決定する
- 要件定義書を作成する
ここでは要求定義が終わったあとからの流れを解説します。8つの工程に分けて、要件定義作成の進め方とコツを確認しましょう。
課題と目標の明確化する
依頼側からの要求定義や企画内容をもとに、システムの開発によって解決したい課題と目標を明確にします。
要求定義にも課題と目標を記載しますが、あくまでも依頼側の視点です。技術者や開発側が精査し、実現可能かどうかを見極めます。現実的でない要求に対しては、代替え案を提案したり、コストを見直したりして、双方が合意する課題と目標を設定しましょう。
要件の抜け・漏れが無いか確認する
要求定義をもとに要件の抜け・漏れが無いか開発側と依頼側の双方で確認しましょう。依頼側が要求定義に慣れていない場合、内容があやふやな状態かもしれません。
「この要望のためにはこのような機能要件を加えましょう」「性能要件について抜けています」などの指摘を受けながら、双方で認識を擦り合わせていきます。依頼側の意図やニーズを汲み取りながら、提案をしてくれるでしょう。
システムの全体構成・内容を明確化する
つづいて、システム全体の構成や具体的な内容を明確化しましょう。「システム開発」と言っても、ユーザーの利用環境によって実現方法には選択肢がたくさんあります。
考えられるシステムの例は、以下の通りです。
- ウェブサーバー上で動作させるウェブシステム
- パソコン・スマホ上で動作するクライアントシステム
- iOSデバイス・Androidデバイスなどの特定のデバイス上で動作する組み込みシステム
システム全体としてどのように構成していくのかロジック部分を整理します。
たとえば、「パソコン・スマホで操作を行う」「操作のためにウェブブラウザを使う」「アプリケーションはウェブサーバーを立ち上げる」などです。
実際には、業務フロー図・システム化業務フロー図・ビジネスプロセス図を用いて図式化して認識の共有を目指します。
機能要件を定義する
システム全体の構成が決まったら、機能要件を定義しましょう。機能要件定義とは、システムの機能に関する要件を定めていく工程です。ここではシステム開発を通して、最低限実現する機能について決定します。
システムのコア部分を定義していく作業で、どのような機能を搭載していくかを漏れなく整理していかなければなりません。機能要件定義によって、プロジェクトの予算やメンバー、スケジュールなどが大きく左右されます。
また、予算やスケジュールに制限があるのであれば、必要機能に優先順位をつけることも欠かせません。
非機能要件を定義する
つづいて、非機能要件の定義です。ここでは機能以外の以下のような項目を定義します。
- 可用性
- 保守・運用
- 性能・拡張性
- 移行性
- セキュリティ
- 環境・エコロジー
以上のように、機能に関する項目以外の要件を定義します。たとえば、データベースの処理速度や画面レイアウトなども含まれます。ユーザーの満足度に直結する部分のため、具体的な定義づけが必要です。
ただし、依頼側から非機能要件について話をするケースは少ないです。どちらかというと開発側が非機能要件をまとめ、提示・提案してくれることとなるでしょう。
要件を評価し要件をブラッシュアップする
ここまでで定義した要件を改めて評価し、過不足ないかを確認します。要件をブラッシュアップさせ、依頼側と開発側で認識のすり合わせを行いましょう。要件をより具体化させることで、システム全体の細かな部分まで見えてきます。
プロジェクトを決定する
機能要件・非機能要件をブラッシュアップできたら、最後にプロジェクトを決定しましょう。ここでは、以下の項目を決めていきます。
- 開発予算
- スケジュール
- 開発メンバーと役割
具体的な落とし込みをして、設計・開発・テストなどの工程ごとに必要なエンジニアの数や役割分担、期間を定めます。実作業の内容が大まかに決まっていなければ、予算やスケジュール、役割分担などはできないため注意しましょう。
基本的に、依頼側は開発側から提案を受ける形となります。気になる点や不安点は解消しておき、「もっと費用を抑えたい」「いつまでに実用的に使いたい」と要望を伝えて双方で合意を取りましょう。
要件定義書を作成する
最後に、ここまでで決定した内容を改めて要件定義書にまとめていきます。すでに内容は決定しているものの、依頼側と開発側、双方のプロジェクトチームの全員で認識を合わせるために資料を作成します。
要件定義書の作成は開発側の役目ですが、どのような内容が記載されているのかを確認しましょう。
- システム開発にあたっての目的・目標
- システムの導入環境
- 現在抱えている課題
- システムの全体構造
- 機能要件
- 非機能要件
- 開発予算
- スケジュール
- 開発メンバーと役割
- 工数・工程表
- セキュリティ対策方法
- 依頼側・開発側の連絡手段と頻度
特段、フォーマットやテンプレートは決められていません。そのため、提示された要件定義書に漏れがないか改めて確認しましょう。
曖昧な表現になっている箇所についてはしっかり質問をし、要件定義書通りに開発されれば理想のシステムが出来上がると確信を持った状態で設計・開発プロセスに進めましょう。
システム開発における要件定義の工数比率
システム開発における要件定義の工数比率は、全体の20％程度です。期間にすると、1〜2ヶ月以上と考えておきましょう。
要件定義は、依頼側の要望を実現するために細かな項目を決定していくために欠かせない作業です。中途半端な内容のまま設計・実装に進めると、「思ったような動作ができない」「無駄な機能が実装され費用が高くなった」と理想の成果物ができません。
そのため、両者でしっかりと協議を行って、要件定義をしていく必要があります。
ちなみに、他の工程における工数比率や想定期間、見積もり費用の割合は以下の通りです。
| 工程 | 工数割合（開発までを100％とする） | 想定期間 | 見積もり費用の割合（開発費用全体を100％とする） |
|---|---|---|---|
| 要件定義 | 20％程度 | 1〜2ヶ月以上 | 10％程度 |
| 設計 | 25％程度 | 2〜3ヶ月以上 | 10〜20％程度 |
| 実装 | 30％程度 | 3ヶ月以上 | 50〜60％程度 |
| テスト | 25％程度 | 2〜3ヶ月以上 | 5％程度 |
| 運用・保守 | ー | 継続的に行う | 5％程度 |
参照： ソフトウェアメトリックス調査2020 システム開発・保守調査｜一般社団法人日本情報システム・ユーザー協会
もちろん、システムの規模や割り当てるリソースによって工数割合や想定期間、見積もり費用の割合は変動します。
要件定義で失敗しないコツ
最後に、要件定義で失敗しないための3つのコツをご紹介します。
- 利害関係者からのヒアリングを徹底する
- 要件定義漏れを防ぐためのフレームワークを理解する
- 現行システムの仕様確認を実施する
順番に確認し、理想のシステムを構築するための要件定義を行いましょう。
利害関係者からのヒアリングを徹底する
開発するシステムの利害関係者からのヒアリングを徹底しましょう。利害関係者がどのような機能や使い勝手を求めているのかを深く理解しておかなければ、システムに反映することはできません。
とくに、現場で使う業務システムを開発する場合、実際に利用する従業員へのヒアリングは徹底しましょう。経営者層やIT部門だけで「こんな機能があったら業務効率向上につながる」と憶測したままシステム開発を進めると、実用的に使えないシステムが出来上がるかもしれません。
要件定義漏れを防ぐためのフレームワークを理解する
要件定義漏れを防ぐためのフレームワークを理解したうえで、要求定義をしましょう。せっかくヒアリングで得た情報があっても、開発側にわかりやすく伝えなければすべての要求を反映した要件定義書が完成しないためです。
基本的には文章で伝えることとなりますが、説明しづらい部分では以下のような図表を使って伝えましょう。
- 業務フロー図
- データモデル図
- エンティティ機能関連マトリックス図（CRUD図）
さらに、システム開発会社との意思疎通のために、窓口となる担当者は一定のITスキルを持っておきましょう。専門知識がないと十分な理解や判断ができません。
現行システムの仕様確認を実施する
依頼側で活用している現行システムの仕様確認を忘れないようにしましょう。なぜなら、要件定義には、「現行システムの課題を解決する」という目的が含まれているからです。現在抱えている課題を洗い出すためにも必要な作業です。
また、現行システムの仕様を開発側への共有も欠かせません。開発側は、現行システムの状況を理解したうえで、新たに開発するシステムの定義をします。連動・連携のしやすさや、使用言語、処理能力などが加味されるため、成果物の満足度にも影響を与えます。
まとめ
要件定義はシステム開発において、成功を左右するコアな工程です。
そのため、システム開発会社や技術者からの提案を受けるだけでなく、慎重に1つ1つの項目を決めていく必要があります。依頼側が要望をしっかり伝えなければ、理想のシステムが出来上がることはないと認識しておきましょう。
まずはシステムを開発する目的・目標を定め、それに合う機能や品質を定義していく必要があります。要件定義で依頼側と開発側の意思疎通をしっかりと行い、思い通りシステムを開発しましょう。
