TRACERYプロダクトマネージャーのharuです。
「要件定義とは何を目的としたプロセスなのか？なにが出来たら完了なのか？」
はじめて要件定義する人は、ここで詰まってしまうことが多いようです。
要件定義は、設計や実装に比べて、具体的な作業がイメージしにくいプロセスです。
そのような背景もあってか、2023年4月のBPStudy#188〜要件定義を学ぼう。ChatGPTを添えてに私が登壇した時の以下のスライドには、945個のはてなブックマークをいただきました*1。
945というブックマーク数は、要件定義というものを具体的にイメージしにくいと感じている人が世の中に多いことの現れかもしれません。
そこで「要件定義とはそもそも何か」について、何回かの記事に渡って説明します。
この記事では要件定義の目的とゴールについて説明します。
プロジェクトの数だけ存在する開発プロセス
世の中のシステム開発現場すべてに共通する開発プロセスは存在しません。
要件定義や設計の具体的な実施内容は、組織の慣習やプロジェクトに関わる人々の経験や知識によって異なります。
下図のように、要件定義や設計などプロセスの呼び方には多様なバリエーションが存在します。
要求や要件に関するプロセスは、たとえば共通フレーム2013*2には、「要件定義」「システム要件定義」「ソフトウェア要件定義」の3つがありますし、それ以外にも「要求分析」「要求定義」などと呼ぶこともあります。
設計も「基本設計」「方式設計*3」「内部設計」「外部設計」「詳細設計」などさまざまなものがあります。
SWEBOK*4は、「ソフトウェア要求」「ソフトウェア設計」「ソフトウェア構築」とざっくりと分けています。
トレラボ（当ブログ）では、「企画」「要件定義」「基本設計」「詳細設計」「実装」というプロセス名を使います。
要件定義の目的
このようにさまざまに表現されるシステム開発のプロセスですが、目的別に大きく分類すると、以下のようになります。
- 企画 『なぜそのシステムを作るのか』という目的(Why)
- 要件定義 『何を作るのか』(What)
- 設計 『どのように作るのか』(How)
- 実装『実際に作る』(Make)
- テスト『品質を保証する』(Test)
要件定義の目的は「何を作るか（What）」に該当します。
「Why」「What」「How」「Make」の視点については、以下の記事で説明していますので参照してください。
要件定義のゴール
上述したように、要件定義はシステム開発において「何を作るか」を明確にするプロセスです。
要件定義は設計プロセスの前段階であり、その成果物が設計のインプットとなります。
したがって要件定義のゴールは「設計プロセスを円滑に進めるための明確で具体的なインプットを提供すること」です。
そのために最低限必要な要件定義の成果物は以下の通りです。
これらにより、開発チームは設計・実装すべき対象と要件*8を把握できます。
しかし、これらは「最低限」の要件であることに注意してください。
システムの全体像や構造を明確にするためには、データ構成*9やシステムアーキテクチャ*10の検討が必要です。
また、システム要件だけではなく、システム要件の上位の目的である事業要件や業務要件を定義する必要があります*11。
要件定義の全体像や、成果物のまとめ方の詳細についての説明は、この記事だけでは収まらないので別記事で説明します。
最後に
本記事では、要件定義が「何を作るか（What）」を決めるプロセスであること、その目的とゴールについて説明しました。
これらを理解することで、要件定義を効果的に進められるでしょう。
※後続の記事は、公開次第リンクを記載します。
*1:2024年6月30日現在。はてなブックマークは約100個ではてなホットエントリーというページに掲載される。ここに掲載されるとその日の中でも話題になったコンテンツであると考えられる
*2:情報システムの開発および運用におけるプロジェクト管理や品質管理の基準を提供するために策定されたフレームワーク。情報処理推進機構（IPA）が発行しているもので、情報システムのライフサイクル全体にわたる一貫した管理方法を提供する。特に日本国内のITプロジェクトにおいて標準的なフレームワークとして広く利用されている。これにより、プロジェクトの一貫性と透明性が向上し、品質の高いシステム開発が可能になる。SEC BOOKS：共通フレーム2013
*3:アーキテクチャ設計のこと
*4:（SWEBOK：Software Engineering Body of Knowledge） は、ソフトウェアエンジニアリングの知識体系を体系化したものです。SWEBOKは、ソフトウェアエンジニアが業務で必要とする基本的な知識や技術をまとめた標準的なガイド。SWEBOKはIEEE（米国電気電子学会）が策定しており、ソフトウェアエンジニアリングの教育や認定、プロフェッショナルな実務において広く利用されている。
*5:品目という言葉は聞き慣れないかもしれないが、ここでは共通フレーム2013の用語に従っている
*6:システムが提供すべき具体的な機能やサービス、操作に関する要件のこと。システムが「何をするか」に関する要件であり、ユーザーやクライアントが期待する具体的な動作や結果を定義する。データ入力、データ処理、データ出力、データ検索、データ保存、ユーザー認証、通知、インターフェース（他のシステムやアプリケーションとの連携）などの機能があげられる。
*7:システムの動作や性能、品質に関する要件のこと。機能要件が「システムが何をするか」に焦点を当てるのに対して、非機能要件は「システムがどのようにそれをするか」に焦点を当てる。セキュリティ、性能、信頼性、可用性、保守性、ユーザビリティ、互換性、移植性、法令遵守などがある。
*8:実現すること
*9:主に概念モデルなど。要件定義手法のRDRAでは情報モデル
*10:サーバー構成や各サーバーに配置されるソフトウェアの関連図で現す事が多い。UMLの配置図が該当する。
*11:システム要件は事業要件や業務要件から導き出されるため。
