ITシステムの開発において、要件定義は必須の工程の一つです。要件定義を怠った場合、プロジェクトがうまくいかなかったり、トラブルが発生したりすることもあります。開発をうまく進めていくうえで、要件定義は不可欠といえるでしょう。本記事では、要件定義について解説したうえで、関連用語や役立つフレームワーク・進め方をわかりやすく解説します。
要件定義とは?
要件定義とは、システム開発を行ううえで「何をどのようにシステム化するのか」を明らかにしていく作業です。ITのシステム開発では、要件定義に最初に取り組むことを推奨されるケースが多いです。要件定義を行うことで作業の土台を整えられ、作業全体を効率的に進められるでしょう。要件定義では、顧客からシステムの目的や搭載したい機能などをヒアリングし、顧客の希望をまとめていきます。このとき、顧客からの要望を文章化することで、作業に関わる人たちの間で理解の食い違いを防げます。
要件定義と似た他の言葉との違い
要件定義と似た言葉として、要求定義と基本設計が挙げられます。ここでは、要求定義と基本設定の意味を確認しながら、要件定義との違いについても確認していきましょう。
要求定義との違い
前述したとおり、要件定義は製作者が作業工程を決定するために必要な工程です。一方、要求定義では、制作者が顧客に対してシステムに取り入れたい内容を聞き取ります。また、要求定義には製作側が顧客の要望にどの程度応えられるのかすり合わせる作業も含まれています。制作者は要件定義書を作成する前に顧客に対してヒアリングを実施し、互いの認識の相違を埋めていくことが大切です。すり合わせを事前にきちんと行うことで、納品後に「イメージと違う」といったクレームがくることを回避できるでしょう。
基本設計との違い
クライアントの要件や要望をまとめた要件定義を元にして、システムの外部仕様を決めることを基本設計といいます。基本設計で決定する項目として、主に下記があります。
- 画面レイアウト
- 画面遷移図
- システムインターフェース
- 帳票レイアウト
- コード一覧
- ER図
- CRUD図
基本設計とは要件定義の内容に基づいて、機能ごとに行う開発を決定する工程です。基本設計を作成しておくことで、各機能が何を実現するのか明確にできます。
要件定義への理解を深める、知っておきたい関連用語
要件定義への理解を深めるために知っておきたい関連用語として下記の3つがあります。
- システム要件定義
- ソフトウェア要件定義
- AsIsモデルとToBeモデル
それぞれ詳しく解説します。
システム要件定義
システム要件定義は、システム開発を行うにあたり、実施するべき業務内容を洗い出し、文書化するプロセスです。システム開発では、内容や目的の他、スケジュールや開発メンバー、予算など、事前に決めておかなければならないことが多くあります。システム開発で必要なことを具体的に想定し、文書化することにより、プロジェクトを円滑に進めやすくなります。要件定義はプロジェクトをスムーズに進められるか、事業を成功できるかの鍵といえるでしょう。要件定義は各工程のなかでも重要なフェーズのため、システム開発に精通した人が担当することをおすすめします。
ソフトウェア要件定義
ソフトウェア要件定義とは、開発するシステムのなかでソフトウェアに関する要件を定義することです。近年、多くの情報システムが開発されていますが、ソフトウェアはとくに詳細な要件を詰める必要があります。ソフトウェアにはユーザーインタフェースやデータべースなど、構成要素がさまざまです。
AsIsモデルとToBeモデル
As-IsモデルとTo-Beモデルとは、現状と理想のギャップを把握し、取り組むべき課題の抽出を行い、行動に移すためのフレームワークです。「As IS」と「To Be」には下記の意味があります。
- As Is 現在の状態
- To Be 理想の状態
「As IS」と「To Be」を明らかにすることで、ギャップとなる部分が見えてきます。「As IS」と「To Be」の差分は取り組むべき課題です。As-IsモデルとTo-Beモデルを活用することにより、課題の発見を客観的に行えます。
要件定義を行うときに定義すべき2つの要件
要件定義を行うときに定義すべき2つの要件は下記の通りです。
- 機能要件
- 非機能要件
それぞれ詳しく解説します。
機能要件
機能要件とは、クライアントがシステムに搭載することを望んでいる機能です。 機能要件には画面仕様や入出力機能、画面遷移の流れ、保持するデータ項目などが含まれます。クライアントが実現したい機能や挙動は要件定義工程においてドキュメント化します。
非機能要件
非機能要件とは、機能以外の全ての要件のことです。前述の通り、機能要件は顧客が必要とする機能の要件であるのに対し、非機能要件は顧客が必要とする機能以外の要件です。たとえば、可用性やセキュリティ、性能などが非機能要件です。顧客の希望する機能を全て実装したシステムでも処理性能が低かったり、障害から復旧するのに時間がかかったりする場合、運用に耐えられません。そのため、開発者は顧客の要望に応じるだけでなく、プロの目から必要な要件を洗い出し、定義する必要があります。顧客のなかには実装する機能の要件を選ぶことに注力するあまり、非機能要件を決められない人もいます。そうなると、使い勝手がよくないシステムになるため注意が必要です。
フロー別に詳しく解説!要件定義の進め方
要件定義は下記の流れで進めていきます。
- 業務フローを明確にする
- 新しい業務フローを描く(要求定義)
- 機能要件と非機能要件を定義する
- 予算とリソースを整理する
- 要件定義書を完成させる
各ステップごとに詳しく見ていきましょう。
STEP1.業務フローを明確にする
要件定義をはじめるにあたって業務フローを明確にします。具体的には、システム化の方針を明確にし、要件定義の体制図を作成します。このときに、各フローごとのスケジュールも作成しておきましょう。業務フローを明確にした後、計画書を作成することが多いです。計画書を顧客に提示してはじめて、顧客から作業費用をもらえることも少なくありません。
STEP2.新しい業務フローを描く(要求定義)
顧客から計画書の内容に同意を得られたら、要求定義を行います。顧客がシステムに求めていることや、搭載を希望している機能などをヒアリングします。新しい業務フローを描く際、顧客の要望のなかからできることとできないことを明確にすることも重要です。また、予算が限られる場合は、顧客に希望している機能などに優先順位をつけてもらいましょう。
STEP3.機能要件と非機能要件を定義する
システム要件を機能要件と非機能要件に分類していきます。機能要件には主に下記のものがあります。
- 画面要件
- 帳票要件
- システム機能要件
- 外部インターフェース要件
- データ要件
非機能要件には主に下記のものがあります。
- ユーザビリティおよびアクセシビリティ要件
- システム方式要件
- 情報セキュリティ要件
- 情報システム稼働環境要件
- テスト要件
- 信頼性要件
- 拡張性要件
- 上位互換性要件
- 継続性要件
- 移行要件
- 引継ぎ要件
- 規模要件
- 性能要件
- 教育要件
- 運用要件
- 保守要件
機能要件と非機能要件を定義し、クライアントが満足してくれるシステムの構築を目指しましょう。
STEP4.予算とリソースを整理する
システム開発にかかる予算を見積り、予算オーバーしていないか確認を行います。代表的な見積り手法として、下記の3つがあります。
- 類推見積り
- パラメトリック見積り
- ボトムアップ見積り
類推見積は過去の類似プロジェクトから類推し、予算を見積もる方法です。精度が粗い算出方法ですが、要件定義の段階では問題ないケースも多いといわれています。パラメトリック見積りは機能数や画面数などに係数をかけて算出する方法です。利用実績が多々ある企業では係数の信頼性が高いため、顧客からの理解も得やすい傾向にあります。ボトムアップ見積りはプロジェクトの作業を洗い出し、工数を算出する方法です。作業ベースで見積るため最も精度が高い方法といわれています。また、システム開発の管理者はリソースを確立するために、リソース定義を行うことも忘れてはいけません。リソースをきちんと整理しておきましょう。
STEP5.要件定義書を完成させる
予算を考慮し、顧客の要望やシステムに必要な機能を整理できたら、要件定義書を完成させます。
要件定義は誰がやるのか?求められる5つのスキル
要件定義で求められるスキルは下記の5つです。
- 基本的なITスキル
- 下流工程での十分な経験
- コミュニケーション力・ヒアリング力
- 他業種について学び、理解する力
- 各種フレームワークに関する知識
それぞれ詳しく解説します。
1.基本的なITスキル
要件定義を行うためには、基本的なITスキルを持っていることが前提です。顧客のヒアリングや設計図の作成などを行ううえで、基本的なITのスキルは不可欠です。また、顧客との面談ではITに関する質問を受けたり、システム開発について相談されたりすることもあります。こうした場合も、基本的なITスキルがなければ、対応できないでしょう。
2.下流工程での十分な経験
要件定義は上流工程ですが、下流工程について理解していることが前提です。設計図が机上の空論にならないためには顧客や自身の理想ばかりでなく、現場の状況も考慮したうえで要件定義する必要があります。また、プログラミングを行うにあたって、要求がシステム化された後についてイメージできなければなりません。イメージするためには、下流工程であるプログラミング経験が必要です。
3.コミュニケーション力・ヒアリング力
開発者は顧客とコミュニケーションをとり、顧客のニーズや要望を引き出さなければなりません。また、顧客によっては思い描いているシステムを適切な言葉で伝えられないため、開発者には顧客の考えや要望を汲み取る力も求められます。また、顧客自身がシステムに抱える問題点に気付くには、要件定義を進める開発者のスキルや能力も重要です。
4.他業種について学び、理解する力
顧客はIT業界に携わっている人だけではありません。さまざまな業界に身を置く人たちからシステム開発について相談を受けることになるでしょう。そのため、開発者はIT業界のみならず、他業種についてもある程度精通している必要があります。顧客の期待に応えられるシステムを開発するためには、さまざまな業界について学んでいかなければなりません。
5.各種フレームワークに関する知識
要件定義において漏れを防ぐためには、そのシステムがどういったケースに問題が発生するかのか予測し、未然に問題発生を回避しなければなりません。各種フレームワークに関する知識があれば、トラブルを防ぎやすいだけでなく、作業を円滑に進めやすくなります。
要件定義に役立つ5つのフレームワークとツール
要件定義に役立つ5つのフレームワークとツールは下記の5つです。
- 要求定義を効率よく「EA」
- すべきことや役割を明確にする「5W2H」
- 非機能要件の定義に「RASIS」
- 業務フローを理解する「ERD」
- データの流れを定義する「DFD」
それぞれ詳しく解説します。
要求定義を効率よく「EA」
EAとは、企業が新サービスや製品を提供するまでの構想や機能、実装、構造について、専門家が表現した設計図です。EAは工業製品の製造で作成されることが多いといわれています。図面を作成するにあたり、顧客のニーズを収集し、整理したうえで、合意を得てから機能設計を行います。EAは必要な部品に展開し、調達や製造、組み立てなどの各工程における担当者間の合意形成、および作業の指示書となります。
すべきことや役割を明確にする「5W2H」
「5W2H」は5つのW(why、what、where、when、who)と2つのH(how、how much)で構成された言葉です。5W2Hに答えるかたちでシステム開発の目的やスケジュールを明らかにしていきます。
- why なぜシステム開発をするのか
- what 何を作るか
- where どこまで作るか
- when いつまでに作成するのか
- who プロジェクトの役割
- how どのように作成するのか
- how much 開発費用はいくらかかるのか
5W2Hを活用することで、システム開発を行うにあたって必要な要素を漏れなく、明確にできます。
非機能要件の定義に「RASIS」
RASISとは、コンピュータシステムに関する評価指標です。RASISは下記の言葉の頭文字で構成されています。
- Reliability 信頼性
- Availability 可用性
- Serviceability 保守性
- Integrity 保全性
- Security 安全性
RASISは上記5つの観点からシステムを評価するフレームワークです。非機能要件の定義漏れを防止したい場合に活用できます。
業務フローを理解する「ERD」
ERDとは、「Entity Relationship Diagram」の略語です。ERDはデータベース設計の代表的な設計図のことです。ERDはデータ中心アプローチの技法で、作成したER図をそのまま物理データベース上に変換できます。データベース設計手法のデファクトスタンダードで、大規模なシステム開発を行うにあたって不可欠なものといえるでしょう。ERDには、後戻りのコストを削減できる、運用・保守フェーズで役立つなどのメリットがあります。
データの流れを定義する「DFD」
DFDは、Data Flow Diagramの略語で、システム設計時に用いられるフレームワークです。DEDを活用することで、データの発生や流れ、出力、保管などを図式化できます。DFDは機能(プロセス)や入出力、データストア(ファイル・DB)、データの流れを各表記法に従って記載可能です。システムの構成要素を分割し、図形を用いてデータの流れを中心に記述します。曖昧さを排除できるため、システムの抜け防止に効果的です。
要件定義でもっとも重要なのは「コミュニケーション」
要件定義をしっかりと行うことで、開発者と顧客との認識の乖離を狭められます。要件定義を行うには、基本的なITスキルや下流工程での経験など、知識やスキルにおいて必要とされる要素も多いです。しかし、要件定義でもっとも重要なのは、顧客とのコミュニケーションといえるでしょう。顧客のなかにはITの知識がなかったり、自身の希望をうまく言葉で伝えられなかったりする人も少なくありません。開発者には要件定義の段階で顧客の希望を汲み取る力が求められます。コミュニケーション力が高い開発者であれば、顧客のニーズをうまく把握し、顧客が希望するシステムを開発できるでしょう。また、要件定義を行うにあたってフレームワークを活用することで、システム開発を行うための基盤をよりスムーズに構築できるはずです。