はじめに
webサイト開発のエンジニアや、テクニカルディレクターとして働いていると、「要件定義」をしてほしい、「要件定義」のフェーズから関わってほしいと依頼されることは多いと思います。
一般的に「要件定義」は具体的に一体何をすることなのだろうと改めて思い、まとめてみました。
参考書籍：Webディレクションの新・標準ルール システム開発編
まとめるにあたり、以下のようなプロジェクトを想定します。
- CMSを導入したWebサイト開発
- 発注者 ＝ ディレクター
- 受注者 ＝ フロントエンドエンジニア及び、バックエンドエンジニア（テクニカルディレクター）
要件定義とは
「要件定義」の他に「要求定義」という言葉もあり、まずはその違い含めて考えてみます。
要求定義と要件定義
要求定義
利用ユーザーの立場で考えて、ビジネス要件を整理すること。
クライアントがどのようなwebサイトを望んでいるか、どのような機能を「要求」
しているかなどをまとめていく。
要求定義で考える4つの項目
- 開発のゴールと手段
- リリース時期
- 開発体制
- 運用方法
要件定義
「要求定義」をもとにwebサイトが担うべき役割を機能に落とし込み文書にまとめていく工程のこと。
要件定義書の作成において、メンバーの主観によって解釈が変わるような曖昧な記述は避けるようにする必要あります。
要件定義で考える7つの項目
- 全体方針
- ビジネス要件
- 機能要件
- 非機能要件
- 性能目標
- セキュリティ要件
- 運用管理
開発の遅延理由の主な原因
要求定義と、要件定義に関連する以下の5項目が、日本情報システム・ユーザー協会によると、開発の遅延理由の半数を超えているとしており、要件定義の重要性がわかります。
- 目的不適当
- 提案依頼書の内容不適当
- 要件仕様の決定遅れ
- 要件分析作業の不十分
- 開発規模の増大
以上が「要件定義」の概要になりますが、「要件定義で考える7つの項目」のうち、重要な3. 機能要件と4. 非機能要件について、本記事では深ぼって考えてみます。
機能要件
どのような機能を実装するのかをまとめたものになります。
CMSを導入するサイトにおいては、CMS化する要素や、絞り込み機能などの機能実装が該当してきます。
CMS化する範囲や、機能実装する箇所を決める
次の観点で考えていきます。
- CMS化することや、機能を追加することで、明らかに効果（価値）が認められるか
- 開発の工数に対して効果が釣り合っているか
発注者と受注者との連携
機能要件は、発注・受注双方でヒアリングを重ねることで、より精度の高い要件の定義が可能になります。
発注者の姿勢
自分たちが出す要求に対して、どのような機能があれば実現できるかなどのイメージは発注者は持つべきです。
そのために、類似するサイトやサービスを研究して、開発するサイトにも有効なのかなど、検討が必要です。
機能要件を決めるにあたり積極的に参加して、要求を伝えるだけで終わらないようにする必要があります。
受注者の姿勢
発注者の目線に立って懸念となる事項は細かく確認を行い、技術的な知見を活かして、良い別案があれば、提案をしていくとよいです。
発注者からの要求の意図を汲み取り、機能要件を考えていく必要があります。
何を定義するか
-
処理内容
CMS化する要素、機能をリスト化します。
例えばコーポレートサイトだと、お知らせ機能や、役員一覧ページなど、機能のカテゴリ毎にまとめていくとよいです。 -
画面構成や操作方法
ユーザーインターフェースとなる「画面」について定義します。
画面一覧、画面遷移、画面の入出力要素、画面の操作を図表に用いて表現していきます。
非機能要件
非機能要件とは？
サイトのパフォーマンスや、機能の使いやすさ、CMS管理画面のわかりやすさなど、「機能ではない」要件を「非機能要件」と呼びます。
クライアントからヒアリングするものでもなく、テクニカルディレクターやエンジニアなどITの専門家が要件を定めていき、発注者やクライアントに説明していくものです。
非機能要件の例
非機能要件は例えば、以下のようなものがあります。
- 性能・拡張性：動作速度などの性能
- 運用・保守性：マニュアルなどの整備
- セキュリティ：ウイルス対策や不正アクセス
- UX：使いやすさなどのユーザー体験
どう考えるか？
サイトの規模によっては、非機能要件のクオリティに差が出ていないのが理想ですが、開発側からすると、全ての案件で、すべての非機能要件を最上にするのは難しいため、どこかでバランスを取る必要があります。
発注者やクライアントなどと相談して、決めていけるとよさそうです。
まとめ
機能要件や、非機能要件以外にも、セキュリティ要件や、ビジネス要件などもあり、「要件」を定義する工程は思ったより、幅広いと感じました。
自身の職能を超えて、いろんな観点や知見で、「要件定義」に関わっていければと思いました。