Technology部コンサルタントの大畑です。
近年は、IT化やDX化が進み、さまざまなシステムが開発されるようになりました。本記事では、システム開発の要となる最初の工程「要件定義」に焦点を当てて解説します。
要件定義の重要性、プロセス、そして成功のためのポイントをおさえて、ぜひプロジェクト成功にお役立てください。
目次
システム開発における要件定義とは？
システム開発は、一般的に下記のような工程で進められます。
- 要件定義
- 基本設計
- 詳細設計
- 開発
- テスト
- 運用
要件定義とは、システム開発における最初の工程であり、クライアントの要求に対して、必要な機能や要件（条件）を定義していくことです。
基本的に、要件定義で決定された内容をもとに基本設計、詳細設計と進んでいくため、要件定義はプロジェクト全体の方向性を決定する重要な工程となります。
要件定義の目的
要件定義を行うことで、プロジェクトの目的や方向性を明確にすることができます。
要件定義が曖昧だと、開発するシステムの目標や方向性が不明確になり、さまざまな問題が発生する可能性があります。たとえば、開発期限に間に合わなかったり、期待されたシステムとは異なるものが完成してしまったりする恐れがあります。
要件定義は、プロジェクトの成功に向けて非常に重要なステップであり、開発範囲や内容を明確にするための基盤となります。
要件は、ステークホルダーの合意を得る必要があるため、エンジニアなどの技術者ではない方でも理解し、合意できる表現を用いる必要があります。ここでいうステークホルダーには、ビジネスを俯瞰する人、現場で業務を指揮する人、個々の業務に従事する人など、さまざまな立場の人々が含まれます。
要求定義との違い
要件定義の前段階として、要求定義があります。要求定義と要件定義の大きな違いは、誰の視点に立っているかという点です。
- 要求定義：ユーザーが情報システムで実現したいこと
- 要件定義：開発者が要求定義をもとに、制約を踏まえて実際に情報システムに盛り込んでいく要件
クライアントの視点で目的やニーズを定義するのが要求定義です。一方、要件定義は要求定義をもとにして、開発者の視点も加え、システムがどのような機能を持つべきか、どうあるべきかを具体的にまとめる作業のことを指します。
要件定義の重要性
システム開発は決して簡単な作業ではありません。その主な理由は、クライアントが一般的にビジネス側の人物であり、ITに関する知識やシステム開発プロジェクトの経験が乏しいことにあります。
要件定義の難しさを端的に表現した有名な例として、「木のブランコ」という一連の図があります。この図は、システム開発においてクライアントの要望を正確に捉えることがいかに困難であるかを視覚的に示しています。
「木のブランコ」の図は、一つのプロジェクト（木にぶら下がったブランコ）に対するさまざまな関係者の認識の違いを示しています。
たとえば……
- クライアントが望んだもの
- プロジェクトマネージャーが理解したもの
- プログラマーが実装したもの
- テスターがテストしたもの
- 実際にクライアントが必要としていたもの
これらがそれぞれ異なる形のブランコや、時にはまったくブランコとは言えないものとして描かれています。この図は、コミュニケーションの齟齬や認識の相違が、いかにプロジェクトの成果物を本来の意図から乖離させてしまうかを、ユーモアを交えて示しています。
この「木のブランコ」の例は、システム開発における要件定義の重要性と、関係者間の緊密なコミュニケーションの必要性を強調しています。適切な要件定義と継続的な確認作業がなければ、最終的な成果物が当初の期待とかけ離れたものになってしまう危険性を示唆しているのです。
要件定義の主な要素（成果物）
要件定義は、大きく「業務要件」と「システム要件」の2つの要件に分けることができ、さらにシステム要件は、「機能要件」と「非機能要件」に分けることができます。
- 業務要件：開発するシステムの目的と必要な機能や条件を具体的に決めて、業務の流れを明確化したもの
- システム要件：業務要件を達成するためにシステムに求める要件
- 機能要件：実装する機能に関する要件を定義したもの
- 非機能要件：機能要件以外の要件を定義したもの
それぞれについて詳しく説明していきます。
業務要件
業務要件とは、サービスや業務が達成すべき目的と、その達成に必要な機能や条件を具体的に決めて、業務の流れを明確化したものです。業務要件は、下記のようなドキュメントを使用して定義していきます。
| システム化の目的・背景・狙い | システム化もしくはプロジェクトを行う理由を説明した資料。ユーザー企業にヒアリングをしながら問題点・影響・原因・対策を整理して作成していく。 |
|---|---|
| ビジネスプロセス関連図 | 業務の全体像を把握するための資料。関連の部署やシステムの関係がわかるように記載していく。 |
| 業務機能構成表 | ビジネスプロセスから業務作業までを階層的に整理した資料。業務の抜け漏れを防ぐために整理して記載していく。 |
| 業務フロー | 業務のフローがわかる資料。業務フローは、一般的には将来像（To-Be）を記載するが、必要に応じてを現状（As-Is）と将来像（To-Be）の両方を記載する。 |
| 業務処理定義書 | 業務フローでは書ききれない詳細な業務内容がわかる資料。5W2Hの観点で抜け漏れがないように整理していく。 |
システム要件
システム要件とは、業務要件を達成するためにシステムに求める要件のことをいいます。具体的には、「機能要件」と「非機能要件」に分けることができます。
- 機能要件：実装する機能に関する要件を定義したもの
- 非機能要件：機能要件以外の要件を定義したもの
機能要件とは、実装する機能に関する要件を定義し、非機能要件とは、機能要件以外の要件を定義します。これから詳しく解説していきます。
機能要件
機能要件とは、発注側がシステムに求める機能を定義することです。システムに搭載するべき機能はなんなのか、どんな機能を作るのかということを定義していきます。
機能要件の要素として、以下のものが挙げられます。以下は一例であり、プロジェクトの性質、規模、技術スタック、開発方法によって定義すべき項目は変わっていきます。
| 機能一覧 | システムが提供するすべての機能を列挙したリスト。各機能の概要、目的、主な操作などを含む。開発範囲を明確にし、システムの全体像を把握するのに役立つ。 例：ユーザー登録、商品検索、注文処理、レポート生成など。 |
|---|---|
| システム方式 | システムの全体的なアーキテクチャや動作原理を説明。ハードウェア構成、ソフトウェア構成、ネットワーク構成、データフローなどを含む。システムの基本的な処理の流れや、主要なコンポーネント間の関係を明確にする。 |
| 画面要件 | ユーザーインターフェースに関する詳細な仕様。各画面のレイアウト、表示項目、入力項目、ボタンの配置、画面遷移フローなどを定義。ユーザビリティやアクセシビリティに関する要件も含める。モックアップやワイヤーフレームを用いて視覚的に表現することも多い。 |
| 帳票要件 | システムから出力される帳票（レポート、請求書、集計表など）の仕様。各帳票のレイアウト、出力項目、計算ロジック、出力形式（PDF、Excel等）、印刷要件などを定義。 |
| バッチ要件 | 定期的に実行される自動処理（バッチ処理）の仕様。各バッチジョブの目的、実行タイミング、処理内容、入出力データ、エラー処理、パフォーマンス要件などを定義。 |
| テーブル・ファイル要件 | データベースの設計やファイル構造に関する要件。テーブル定義（項目名、データ型、制約条件など）、インデックス設計、リレーションシップ、ファイル形式、データ保持期間、バックアップ要件などを含む。 |
| 外部インターフェース要件 | 他システムとの連携や外部サービスとの通信に関する仕様。API仕様、データフォーマット、通信プロトコル、セキュリティ要件（認証方式など）、連携タイミング、エラーハンドリングなどを定義。外部システムの制約や変更の可能性についても考慮する。 |
非機能要件
非機能要件とは、機能要件以外の要件を定義することです。主に運用や保守に関する条件を定義します。
非機能要件は抽象的な概念のため、定義する際には、IPA（独立行政法人情報処理推進機構）など国の機関が定めたガイドラインが用いられることが多いです。
たとえば以下のようなものがあります。
- 非機能要求グレード：IPA（独立行政法人情報処理推進機構）が定めた非機能要件のフレームワーク
- RASIS：信頼性（Reliability）、可用性（Availability）、保守性（Serviceability）、完全性（Integrity）、セキュリティ（Security）の頭文字を取った非機能要件の評価指標
- SLA：Service Level Agreement。サービスの品質に関する合意事項を定めた文書や契約
今回は、非機能要求グレードの6大項目について解説していきます。
| 可用性 | システムの稼働率や運用スケジュール、業務継続性、業務復旧等を定義する。システムが停止した際に、復旧するまでの時間やバックアップの頻度、非常時の障害耐性なども可用性の範囲となる。 |
|---|---|
| 性能・拡張性 | システムの処理能力、レスポンス時間などの要件。将来的なシステムの拡張性を定義する。 |
| 運用・保守性 | 障害監視システムやメンテナンスに関する要件。運用・保守性の要件定義は非常時の対応と密接な関係があり、運用マニュアルや手順書に要件の内容を作りこむ必要がある。 |
| 移行性 | システムが移行しやすいかを表す要件。移行方式やスケジュールの設定、移行にかかるシステムの停止期間、移行データの種類、移行時の作業分担などが該当する。 |
| セキュリティ | システムを使用する上でのセキュリティリスクを管理する要件。リスクの分析やセキュリティ診断、セキュリティパッチ等の内容があり、認証機能やデータ暗号化、アクセス制限などもセキュリティ要件になる。 |
| 環境・エコロジー | システムの構築や運用を行う際の制約条件、消費エネルギーについて定める項目。消費電力、CO2排出量、耐震性能、騒音性についても検討する必要がある。 |
システム開発会社のプロが教える、失敗しない要件定義のポイント
システム開発の目的や背景の把握
要件定義を始める前に、以下の点を確認することが重要です。
- 提案書や要求一覧の内容
- ベンチマークとなる類似サービス
- 開発対象となるサービスの機能
- 業務フローと機能ごとの遷移
これらを詳細に分析することで、システム開発の目的、背景、狙い、そして現状の課題をより明確に把握できます。新規サービスの場合はとくに、類似サービスの調査が重要となります。
現状の詳細な分析をおこなう
既存サービスの変更や改修の場合、現状のシステムについて以下の点を重点的に分析します。
- 現行サービスの機能一覧
- 各機能の詳細な仕様
- 業務フローにおける各機能の位置づけ
- ユーザーの動線（機能間の遷移）
- 現行システムの問題点や改善要望
この分析により、新しいシステムに引き継ぐべき要素と改善すべき点が明確になります。
クライアントと目線を合わせる
要件定義のポイントは、クライアントとの目線を合わせることです。上記でシステム開発の難しさを説明しましたが、システム開発には技術的な側面が多分に含まれますが、クライアントは必ずしもIT分野の専門家ではありません。多くの場合、ビジネスの観点から課題解決やプロセス改善を求めています。
そのため、開発者側には、技術的な内容をクライアントの視点に立ってわかりやすく説明する能力が求められます。専門用語を多用したり、システムの詳細な仕様についていきなり話し始めたりするのではなく、クライアントの業務やビジネス目標に沿った形で情報を提供することが大切です。
ドキュメント化する
口頭でのコミュニケーションだけでなく、ドキュメントなどの形で合意内容を文書化することも重要です。文書化して双方の認識を明確に整理し共有することで、後々の認識の相違や誤解のリスクを大幅に軽減することができます。
まとめ
システム開発における要件定義は、プロジェクトの成功に不可欠な要素です。プロジェクトの目的や方向性を明確にし、必要な機能や条件を定義することで、基本設計、詳細設計、開発、テスト、運用といった後続工程のスムーズな進行にもつながります。
要件定義の成功のポイントは以下のとおりです。
- クライアントとのコミュニケーション：技術的な内容をわかりやすく伝え、クライアントとの認識のズレを防ぐことが重要。
- 文書化の重要性： 要件を文書化することで、開発の方向性を一致させ、後々の参照も可能になる。
要件定義が曖昧だと、開発が混乱し、期待通りのシステムが完成しないリスクが高まります。しっかりとした要件定義は、プロジェクト全体の効率を高め、クライアントの満足度向上にも直結します。
この記事が少しでもお役に立てれば幸いです。
