自己紹介
初めまして、IT経験８年ほどになりますが、今回Qiita発投稿です！
下流から上流まで経験し、今は要件定義フェーズから入る業務に携わっています。UI/UXデザインが得意です。
今回は要件定義について自己学習含めて記録として残していきます。
はじめに
システム開発において、要件定義は非常に重要な初期段階のプロセスです。要件定義について詳しく説明していきます。
要件定義とは？
要件定義とは、簡単に言えば「作りたいものの設計図」を作ることです。家を建てる際に間取り図を描くように、ソフトウェアやシステムを開発する際にも、最初に「どんなものを作るか」を明確にする必要があります。
要件定義の主な目的
- 作成するシステムの目的を明確にする
- 必要な機能を決定する
- 使用者（ユーザー）のニーズを理解する
- プロジェクトの範囲と制限を定める
要件定義で大切なポイント
- ユーザーのニーズを深く理解すること
- 詳細を明確に定義すること
- 全ての関係者（ステークホルダー）の合意を得ること
- 柔軟性を持つこと（要件は変更される可能性があることを念頭に置く）
要件定義のステップ
要件定義の各ステップを具体的にイメージできるよう手順を説明します。
1. 現状分析
目的
現在の状況を正確に把握し、改善点を特定する。
行動指針
・現行システムの機能リストを作成する
・業務フローを図式化する（フローチャートを使用）
・ユーザーの日常業務を観察し、記録する
・現システムの問題点をリスト化する
・クライアントへのヒアリングを実施し、使用状況を詳細に把握する
成果物
現状分析レポート、問題点リスト
2. ステークホルダーの特定
目的
プロジェクトに関わる全ての人や組織を明確にし、その役割を理解する。
行動指針
・プロジェクト関係者リストを作成する
・各ステークホルダーの役割と責任を明確にする
・ステークホルダーマップを作成し、関係性を可視化する
・各ステークホルダーの期待や懸念をリストアップする
成果物
ステークホルダーリスト、ステークホルダーマップ
3. 要求の収集
目的
ユーザーや関係者のニーズを包括的に理解する。
行動指針
・個別インタビューを実施する（質問リストを事前に準備）
・アンケート調査を行う（オンラインツールの活用）
・ワークショップを開催し、グループディスカッションを促進する
・ユーザーストーリーを作成する（「〜として、〜したい。なぜなら〜だからだ。」の形式）
・ユースケース図を作成する
成果物
インタビュー議事録、アンケート結果、ユーザーストーリー集、ユースケース図
4. 要求の分析と整理
目的
収集した要求を体系化し、優先順位をつける。
行動指針
・要求を機能要件と非機能要件に分類する
・MoSCoW法を使用して優先順位をつける
→Must（絶対に必要）、Should（できれば必要）、Could（可能なら実施）、Won't（今回は実施しない）
例えば、新しいウェブサイトを開発するとします。
Must（絶対に必要）: 基本的なサイトのナビゲーション、ユーザー登録機能、SSL証明書の導入
Should（できれば必要）: 検索機能、レスポンシブデザイン（モバイル対応）
Could（可能なら実施）: ダークモードの実装、ソーシャルメディア共有機能
Won't（今回は実施しない）: AIチャットボットの導入、音声認識検索
・要求間の依存関係を図式化する
・矛盾する要求をリストアップし、解決策を検討する
成果物
要求優先順位リスト、要求依存関係図、矛盾要求解決策
5. 要件の文書化
目的
要件を明確かつ理解しやすい形で文書化する。
行動指針
・要件定義書のテンプレートを作成する
・各要件を SMART 基準で記述する
（Specific（具体的）, Measurable（測定可能）, Achievable（達成可能）, Relevant（関連性がある）, Time-bound（期限がある））で記述する
SMARTの具体例
例えば、Makiさんが新しいITコンサルティングビジネスを始める目標を立てるとします。
Specific（具体的）: 1ヶ月以内にITコンサルティングのWebサイトを立ち上げる
Measurable（測定可能）: 1ヶ月以内にクライアントから3件の問い合わせを受ける
Achievable（達成可能）: Webサイト構築は自身のスキルで対応可能で、クライアント向けに初期のマーケティング戦略も準備できている
Relevant（関連性がある）: ITコンサルティングのビジネスを展開するために、Webサイトが必要不可欠
Time-bound（期限がある）: 1ヶ月以内にWebサイトを完成させ、ビジネスをスタートさせる
・ワイヤーフレームやモックアップを作成し、UI要件を視覚化する
・システム構成図を作成する
・データフロー図を作成する
成果物
要件定義書(機能要件と非機能要件)、ワイヤーフレーム、システム構成図、データフロー図
6. レビューと承認
目的
すべてのステークホルダーの合意を得て、要件を確定させる。
行動指針
・レビュー会議を開催する（アジェンダを事前に配布）
・要件定義書の各項目をステークホルダーと確認する
・フィードバックを収集し、修正点をリスト化する
・修正後の要件定義書で最終確認を行う
・正式な承認プロセスを経て、要件を確定させる
成果物
レビュー議事録、修正リスト、承認済み要件定義書
機能要件と非機能要件
要件を文書化する際、大きく分けて「機能要件」と「非機能要件」の2種類があります。これらを明確に区別し、適切に記述することが重要です。
機能要件
開発するシステムやソフトウェアが具体的に何をできるようになるべきかを定義するものです。これは、ユーザーや他のシステムから見て、そのシステムが提供する具体的な機能や動作を指します。
機能要件：機能の有無や正確性で測定（例：注文機能がある/なし）
例：
ユーザーがログインできる
商品を検索できる
注文を確定し、確認メールを送信する
非機能要件
非機能要件は、システムが「どのように動作すべきか」を定義します。システムの品質や性能に関する要件で、直接的な機能ではありませんが、システムの使いやすさや信頼性に大きく影響します。
非機能要件：定量的な指標で測定
例：
システムの応答時間は3秒以内である
1日あたり10,000ユーザーの同時アクセスに対応できる
システムは99.9%の可用性を持つ
データは暗号化して保存される
図表やダイアグラムの活用
要件を視覚的に表現することで、関係者間の理解を深め、誤解を防ぐことができます。以下に、よく使用される図表やダイアグラム、およびおすすめのツールを紹介します。
ユースケース図
概要: システムと外部アクターとの相互作用を表現
ツール:Draw.io,Lucidchart,PlantUML
ER図（エンティティ関連図）
概要: データベースの構造やデータ間の関係を表現
ツール: MySQL Workbench,ERDPlus
フローチャート
概要: プロセスの流れや決定のロジックを表現
ツール: Visio,Lucidchart,draw.io
ワイヤーフレーム
概要: UIのレイアウトや構造を簡略化して表現
ツール: Figma,Sketch
マインドマップ
概要: アイデアや概念の関連性を視覚的に整理
ツール:XMind,Mapify
まとめ：要件定義で重要なポイント
ユーザー中心の思考:
要件定義の核心は、ユーザーのニーズを深く理解することです。技術的な制約にとらわれすぎず、まずはユーザーにとって何が必要かを考えることが重要です。ユーザーインタビューや現場観察を通じて、真のニーズを捉えましょう。
明確性と柔軟性のバランス:
要件は具体的かつ明確に定義する必要がありますが、同時に変更の可能性も考慮に入れる必要があります。詳細を明確にしつつも、新しい情報や状況の変化に応じて要件を調整できる柔軟性を持つことが大切です。
コミュニケーションと合意形成:
要件定義は、技術者だけでなく、ユーザー、経営者、その他のステークホルダーを含む全ての関係者の合意を得るプロセスです。視覚的なツールを活用し、わかりやすく要件を表現することで、関係者間の理解を深め、プロジェクトの成功につながります。