要件定義とは？
要件定義とは、開発工程に入る前の段階で開発者の視点から要求をまとめて、具体的に進める方法を定義づけることです。
発注者の要望を踏まえたうえで、開発に関して下記を定義づけします。
- 概要
- 目的
- 人員
- 開発技術
- 必要な機能
- 必要な予算
- スケジュール
例えばシステム開発においては、クライアントの要求実現がゴールです。
そのため開発工程に入る前に、要求をもとにした性能や実装機能などを要件定義に定めて、具体的なスケジュールを組まなくてはいけません。
まずはクライアントの要求をヒアリングして整理したり、開発工程を設計するために業務フロー・シナリオを作成したりします。
要求を実現するためのゴールが不明確な場合、進め方が分からなくなるためプロジェクトが失敗に終わってしまうでしょう。
また、開発途中で仕様が変わる可能性もあるので、最低限のコンセプトも決める必要があります。
要件定義と要求定義の違い
要件定義と要求定義の違いは、定義づけされるタイミングです。
それぞれのタイミングは、下記をご覧ください。
- 要件定義：開発前に入る前のタイミング
- 要求定義：要件定義の前のタイミング
つまり、要求定義を決めるのはクライアントになるため、現場業務を整理して「何をシステムで実現できるか」を定めます。
一方の要件定義は、要求定義を受けてからシステムに落とし込む工程です。
納期や予算の関係で全ての要求に対応できないので、要求を整理して必要なものだけに絞り込まなければいけません。
また、要求定義を定める段階でクライアントの希望を把握できていなければ、工程遅延やトラブルを引き起こす可能性があるので慎重に行いましょう。
要件定義と基本設計の違い
要件定義と基本設計の違いは、下記の通りです。
| 要件定義 | 基本設計 | |
| 整理の対象 | 整理対象は、クライアントからの要求事項。システム企画書や提案書、既存の業務フローなどから整理を進める。 | 整理対象は、要件定義工程におけるアウトプットの資料一式。該当資料として、業務・機能一覧や要件定義所、非機能要件一覧などが該当する。 |
| 目的 | クライアントの要求を満たすために何を作るか・どんな機能や性能が必要なのかを明確にすることが目的。 | システムで用件を実現させるには、どのように実装すればいいのか深掘りすることが目的。 |
| コミュニケーション | クライアントとコミュニケーションを図りながら開発を進めていく。 | クライアントだけでなく、開発メンバーや外部システム開発担当者とコミュニケーションを図る場合がある。 |
基本的な設計以降は、製造や詳細設計、テスト、開発工程などは下流へ進んでいきます。
クライアントとシステムの完成イメージをすり合わせできる最後の機会なので、齟齬が起きないように打ち合わせを行いましょう。
要件定義書作成までの流れ
ここまで、要件定義の概要や要求定義・基本設計との違いをお伝えしました。
続いて、要件定義書作成までの流れを解説します。
- 要求をヒアリングする
- 実現できる内容か整理していく
- 要件定義書を作成する
ひとつずつ解説していきます。
要求をヒアリングする
要件定義書を作成するにあたって、クライアントに要求をヒアリングしていきます。
要件定義の役割は、クライアントの要求をシステム設計の要件に変換することです。
そしてヒアリングの際は、下記の点に注意しましょう。
- クライアントの言いなりにならない
- 要求する機能・システムを決定する権限を持っている方に参加してもらう
クライアントの要求には実現できるか判断したうえで、適切な開発スケジュールや解決策が求められます。
また、ヒアリングの際にプロジェクト全体の意思決定を行える、もしくは業務担当者に参加してもらえるように調整しましょう。
実現できる内容か整理していく
クライアントの要求をヒアリングできたら、実現できる内容か整理していきます。
システムを開発する際は、必須要件と希望要件の2つに分類しましょう。
それぞれの違いは、下記の通りです。
- 必須要件：必ず実現したい機能などの要件
- 希望要件：できれば実現したい要件
希望要件より必須要件の方が、優先順位は高くなります。
要件定義では要求が多くなりやすいですが、実際は期間や予算が限られています。
そのため対応できるものを絞り、費用対効果についても検討しなければいけません。
まずは要求を細かく整理して、実現できる内容なのか詳細な要件・要求を決めていきましょう。
要件定義書を作成する
実現できる内容を整理できたら、要件定義書を作成していきます。
ここまで整理した内容は、今後の開発フローで重要になるので、ドキュメントに残しておくことが必要です。
要件定義書は開発側とクライアントの両方が確認するので、仮に開発に詳しくない方が見ても理解できるように作成しなければいけません。
そのため要件定義書を作り込むことで、開発側とクライアントの認識の不一致を防ぐ効果もあります。
次に、要件定義書を作成する際に明記すべき項目を見ていきましょう。
- 機能要件
- 非機能要件
- サイト要件
- インフラ要件
- セキュリティ要件
- 品質管理要件
それぞれ解説していきます。
機能要件
機能要件とは、システムの重要な部分となる「必ず実装すべき機能・レイアウト」です。
機能に関する内容が、システムを実装するゴールになるので、クライアントだけでなくSEとの認識も調整していきましょう。
機能要件として明記すべき内容は、下記の通りです。
- 外部との連携機能
- データ・システムの種類
- レイアウトなどのUI要件
- システムの構造や処理内容
クライアントによっては、上記以外の記載内容が必要となる可能性もあります。
また、機能要件は「最低限できて当たり前」のラインなので、機能要件が明確になることでプロジェクト全体のスケジュールも把握できるでしょう。
非機能要件
非機能要件とは、機能面以外で実装されるべき要件です。
具体例として、下記があげられます。
- 移行性
- セキュリティ
- システム性能
- 性能・拡張性
- 保守・運用サービス
非機能要件は、システム開発において重要度の高い項目ですがイメージしづらいため、評価に結びつかないと思われやすいです。
しかし、動作速度が速かったり機能の利便性が高かったりすることで、ユーザーの満足度アップにもつながります。
つまりユーザーの長期的な利用によって、クライアントからの新規発注が期待できるでしょう。
非機能要件はユーザーが表には出さない要望であり、システムを支える重要な部分といえるのです。
サイト要件
サイト要件とは、Webサイトを定義するための要件です。
あくまでもWebサイトは開発側ではなく、ユーザーに利用してもらわなければいけません。
そのため、必要ページのカテゴリやタイトル、ディレクトリ構造などを明記します。
ほかには、Webサイトに下記の機能を持たせるか定義します。
- ログイン機能
- SNSシェアボタン
- フォーム情報送信による自動の資料ダウンロード
クライアントからブラウザ、利用端末、SEO対策についてもヒアリングして、ターゲット層を明確にしていきましょう。
こちらの記事では、SEO対策にかかせない「検索順位チェックツール」の重要性や種類、おすすめのツールを10個紹介しているので、ぜひ参考にしてください。
インフラ要件
インフラ要件とは、サーバーやSSL証明、DB、ネットワークといったシステム環境を定義するための要件です。
Webサイトに設置するドメインやサーバーを定めていきます。
高性能になるほどコストがかかるので、クライアントの要望を踏まえながらメリット・デメリットを伝えていきましょう。
またドメインとサーバーの取得は、開発側・クライアント側のどちらが行うのかも明記します。
セキュリティ要件
セキュリティ要件はWebサイトを安全に運用するために、セキュリティの目標を定めた要件です。
膨大な機密情報を扱うため、下記の対策が求められます。
- IP制限
- SSL対応
- 情報漏洩
- ウイルス感染
- セッションタイムアウト
- データベースの脆弱性対策
そのため想定できる攻撃に対して、防御方法やパターンを想定してシステム構築に臨まなければいけません。
また、セキュリティ強度を向上させると開発コストも増えるため、データの機密性に応じた設計が必要です。
こちらの記事では、実際にあった5つの情報漏洩の事例と対策について解説しているので、ぜひ参考にしてください。
品質管理要件
品質管理要件とは、Webサイトを確認・検証するために定義する要件です。
具体的に定める項目は、下記の通りです。
- 検証範囲
- 検証内容
- 修正回数
またスケジュールが遅延した場合は、対応方法や仕様変更、スコープの拡大といったリスクも想定されます。
そのため「別途費用がかかる」「スケジュールが変更される」旨を明記しておきましょう。
要件定義をうまく行うためのポイント
ここまで、要件定義書作成までの流れをお伝えしました。
続いて、要件定義をうまく行うためのポイントを解説します。
- ヒアリングを行うコミュニケーションスキルを磨く
- システムを具体的にイメージする
- 工程を逆算して進める
- 要件をドキュメント化する
ひとつずつ解説していきます。
ヒアリングを行うコミュニケーションスキルを磨く
要件定義をうまく行うポイントして、ヒアリング時のコミュニケーションスキルが求められます。
コミュニケーションスキルの中でも、要件と要求の間にある意識のズレをなくすためにヒアリングスキルが重要です。
また、クライアントの意図を汲み取ったうえで、要件定義書に落とし込む必要あるので覚えおきましょう。
実際に要件定義を行う際は、下記の2つを意識します。
- クライアントの要求をパソコンの動作として理解する
- アナログ部分も含めて、全てどういった動きになるのかヒアリングする
要件と要求の切り分けが難しい場合は、後々のバグになる可能性があるので、システム化できない理由も明確にしなければいけません。
その場合は、「妥協する」「代替案を模索する」のどちらかの選択を求められます。
システムを具体的にイメージする
要件定義をうまく行うためには、システムを具体的にイメージする必要があります。
イメージの具体例は、下記の通りです。
- システム化された場合、要求がどういった動きをするのか
- クライアント側のオペレーションがどのようになるのか
例えばプログラミングを行う際は、完成したシステムの動きをイメージする能力が求められます。
そのためプログラミングやテスト経験が豊富であれば、無意識にシステムをイメージするスキルを向上できるでしょう。
工程を逆算して進める
運用されるまでの工程を逆算して進めることも、要件定義をうまく行うためのポイントです。
クライアントの要求をシステム化して、明確に運用状態をイメージできると、プログラミングやテストなどの工程を逆算できます。
工程を逆算するメリットは、下記の通りです。
- ある程度の工数を把握できる
- だいたいのスケジュールを掴める
- プログラムをどのように動かすべきか分かる
逆算する際に開発時の役割分担もイメージできれば、後々の工程設計をスムーズに進められるでしょう。
要件をドキュメント化する
要件定義には、要件のドキュメント化もポイントです。
クライアントの要求をシステムに落とし込みドキュメント化するには、システムの詳細を言葉や数値で正確に表現しなくてはいけません。
実際にドキュメントを作成する際に意識する点は、下記の2つです。
- 第三者が見ても分かる表現を使う
- システムが稼働して、数年後に改良が必要になった際でも読める
要件定義書が完成した後で、システムやプログラミングでの手戻りはできません。
そのためドキュメント化する前には、表現方法やフォーマットを統一しておきましょう。
こちらの記事では、さまざまな要件をドキュメントする際に活用できるファイル管理ソフトを20個紹介しているので、ぜひ参考にしてください。
まとめ
今回は、要件定義の概要や定義書作成までの流れ、うまく進めるためのポイントを解説しました。
要件定義とは、開発工程に入る前の段階で開発者の視点から要求をまとめて、具体的に進める方法を定義づけることです。
また、要件定義書の流れとして下記の3つをお伝えしました。
- 要求をヒアリングする
- 実現できる内容か整理していく
- 要件定義書を作成する
要件定義書を作成する際は、明記すべき項目もあるので確認しておきましょう。
本記事でお伝えした要件定義をうまく行うためのポイントも参考にして、自社のシステム開発に活かしてください。
【SNSフォローのお願い】
kyozonは日常のビジネスをスマートにする情報を毎日お届けしています。
今回の記事が「役に立った！」という方はtwitterとfacebookもフォローいただければ幸いです。
twitter：https://twitter.com/kyozon_comix
