要件定義はシステム開発を進める上で必須の工程です。
本記事では要件定義とは何か、要件定義の進め方、成果物の書き方について解説します。
システム開発のプロジェクトに参加する機会のある方や、IT業界を志している方はこの記事を読んで要件定義についての知識を深め、スムーズなプロジェクトの進行にぜひお役立てください。
目次
要件定義とは何か？
まず始めに、要件定義とは何かについて解説します。
要件定義とは、クライアントの要望と、その要望をどのように叶えるのかを文章としてまとめたものです。
要件定義はプロジェクト成功の鍵となる
プロジェクトは、例えばウォーターフォール型開発であれば、要件定義→設計→製造・テスト→導入の順で進められます。
要件定義ができなければ、プロジェクトはスタートしないと言っても過言ではありません。要件定義の段階で、クライアントが実装して欲しい機能をヒアリングして引き出していきます。
ヒアリング調査をしないとクライアントの要望を満たせません。要件定義に基づいて業務フローを作成し、クライアント側との認識に齟齬がないか確認しながら進める必要があります。
開発者側はクライアントからの要求に対して、実装可能な機能かどうかを判断します。搭載する機能を決めていくフェーズですが、この段階で時間をあまりかけすぎると、設計や製造・テストの工程が圧迫されてしまいます。
インプットの工程も大切に
クライアントから新しい機能の実装を依頼される場合の多くは、既存システムの改良なので、まずはプロジェクト開始の準備段階として、クライアントの現状や既存システムについて調査する必要があります。
現在の業務フローを確認したい場合は、RFP（提案依頼書）などの書面で確認させてもらいましょう。
書面で用意されていない場合の調査方法は、システムの保守担当やクライアントからヒアリングして整理していきます。この工程を「インプット」と呼びます。
成果物は要件定義書
要件定義の最終的な成果物は要件定義書と呼ばれる書類です。
要件定義書とは、実装する機能などの整理した情報をクライアントに提出するために開発側が記述するものです。
システムを実際に開発する前に提出する書類なので、実装予定の機能についてできる限り詳細に記入しなければいけません。
作成目的はクライアントに対する説明です。そのため、システム開発のプランについて専門的な知識がない人に対しても分かりやすいように記述する必要があります。
書面の内容はクライアントからの要望を満たすように、クライアントと協議し、先方から合意を得たものとなります。
クライアントと細かく内容についての打ち合わせを続けることで、実装後に「イメージしていた機能と違う」などといった不満の噴出を避けられます。そのため、要件定義書は開発側の専門的な知識・経験を活かした内容となるケースが多いです。
要件定義書に記載すべき必須項目
ここでは、要件定義書に記載しなくてはならない最低限の項目について解説します。機能要件や非機能要件の違いもあわせて確認しておきましょう。
システムに関する項目
要件定義書の要とも言うべきは、システムに関する項目です。どのようなシステムを導入する予定なのかを詳細にクライアントに説明しましょう。
1.システムの概要
どのような機能を備えたシステムなのかについて説明します。業務要件はエンドユーザーの視点で作成し、システム要件はエンジニア視点で作られます。
たとえば、サイトに「商品購入」ができる機能を実装して欲しいとの要望があったとしましょう。その場合の業務要件は「商品購入」であり、システム要件は「カートに商品を入れる」といった項目を挙げます。
2.システムを導入する目的
こちらはある機能を導入することで、どのような要望を実現できるかについて説明します。
3.システム導入後の業務フロー
システムを実際に導入すると、業務フローがどのように変化するのかについて説明します。たとえば自動釣銭機を導入する要望を叶えた場合、実際に自動釣銭機を導入すると、これまでとはレジ打ちの方法が変わってきます。このような業務上の変化について記述します。
機能要件に関する項目
機能要件とは、クライアントが求めている機能のことを指します。
システムを実装することで何ができるようになるのかが記述されます。プロジェクトの目標ともなるので、SEにとってはプロジェクトのゴールがはっきりと分かるようになるのです。
具体的には、データやシステムの種類・構造や、システムが処理可能である内容について記述します。
機能要件は、要件定義における初期段階で定義されるものです。クライアントが完成形のイメージを持っていない場合は、ヒアリング調査を何度も行いながら、機能要件を見つけ出していくことになるでしょう。
また、クライアントの予算内に収まるように計算しながら項目を洗いだしていく必要もあります。
非機能要件に関する項目
非機能要件とは、クライアントが機能面以外で求める要件のことを指します。
システムの性能や効率性、セキュリティや保守・運用サービスなどについて記述します。こちらも機能要件と同じく、システム構築のゴールと言えます。
非機能要件は、要件定義の初期段階でヒアリングしておく必要があります。しかし、クライアントは非機能要件までイメージしていない場合が多く、SE側が要求を満たすよう動いていかなければいけません。そのため、機能要件よりも非機能要件の方が難しいと言えるでしょう。
非機能要件を洗い出すのは、機能要件が明確に定まった後になります。機能要件が決まり次第、非機能要件のヒアリング調査に入り、クライアントとの細かい打合せが必要となります。
スムーズに行える要件定義の手法
ここでは、よりスムーズに要件定義を進めるために必要な手法について解説します。
既存の業務フローとシステムについて知る
プロジェクトによって叶えたいクライアントの要望は、実に様々なものです。その中には、現行のシステムや業務フローに課題があり、直面している問題を解決したいというものが多くあります。
要件定義段階で必要になるのは、現在用いられているフローや既に使われているシステムについて知ることです。どの部分に問題があり、どのように解決しなくてはいけないかが分かるからです。
システムの設計書通りに業務を行っていないケースもあります。つまり、要件定義をより細かく設定するためには、保守担当者やシステムを利用している関係者からもヒアリング調査しなければなりません。
このフェーズは時間やコストを割かれてしまいがちですが、要件定義にできる限り工数をかけないためには、問題を理解し解決策を練る必要があるのです。
要求定義書と要件定義書のすり合わせをする
要求定義書とは、クライアントが解決したいと考えている課題や、導入したいシステムについての要求をまとめた書類です。要件定義書は、要求定義書をもとにして作られます。
そのため、要求定義書を読み込んで、要件定義書がクライアントの要求を叶えたものになっているかどうかすり合わせることが大切になります。
すり合わせは、製造やテストなど、後のフェーズで改善や手戻りの工数を削減させるために必要な行為です。特にウォーターフォール型開発では、手戻りが重大なタイムロスとなってしまうため、すり合わせは慎重に行いたいものです。
さらに、2つの書類を突き合わせて、クライアントとSE双方で納得できるよう協議を重ねましょう。
丁寧な要件定義書を作り共有する
実装可能な機能とクライアントの要望をすり合わせるためにも、できる限り詳細に記述された要件定義書を作成しましょう。協議の場を設け、逐一共有するようにして、認識に齟齬がないか確認しておきたいものです。
しかし、先方にも都合があるので、打合せを何度もするのは難しいものです。最低限必要な打合せの回数について考えておきましょう。
そして、最終的な成果物がイメージできる要件定義書を作り、関係者間で合意を得ることが必須となります。合意を得る行動には、後々クレームに繋がらないよう防ぐ役割があります。
成果物がイメージできるようであれば、クライアントにとっても分かりやすい要件定義書になっていると言えます。
担当者を明確にしておく
プロジェクトの担当者を明確に決めておきましょう。曖昧なままにしておくと、後々になってからやらなくてよい業務が増えていく可能性があります。不要な業務が増えると、本来するべき業務の進行に支障が出ることもあるのです。
クライアント側がやらなくてはいけない業務までSEなどの開発側が引きとって作業してしまうケースも少なくありあせん。例を挙げると、現行業務の整理、将来的なビジョンの策定などは、本来であればクライアントがやらなければならない仕事です。
役割分担を明確にして、担当者が明確に定められていない業務が無いように心がけましょう。すべてのタスクについて、担当者が適切に決められていれば、不要な業務で工数を圧迫する可能性もなくなります。
良い要件定義書の必須条件
ここでは、「良い要件定義書」の必須条件について解説します。主に2つの観点から説明します。
専門知識がなくても内容が分かる
良い要件定義書には、実際にシステムを利用するクライアントが理解しやすくなっている文章が記載されています。クライアントはIT分野の専門知識に乏しいケースがほとんどだからです。
そのため、書面ではIT分野に関する専門用語や専門知識を極力使わないようにしましょう。書面の内容を理解してもらえないと仕上がりがイメージできず、クライアントの不信感が高まってしまいます。
誰が読んでも分かりやすい文章になっているか、気をつける必要があります。
問題の解決策が記載されている
要件定義の最終目的は、クライアントからの要求をまとめるだけではありません。クライアントが何を求めているかを見定めるのはもちろんのこと、その要求をどのようにして叶えるのかという「答え」にあたる文章を記載する必要があります。
クライアントもSEがどのような対処をとってくれるのかが分かりやすくなります。答えを記述して、要件定義書は初めて完成と見なされるのです。
まとめ
要件定義とは、プロジェクトのスタートと共に始まります。ヒアリング調査などで現在の問題を洗いだし、クライアントにも分かりやすい言葉を使って書類を作成しましょう。
問題をどのように解決するのかも記載しておくと「良い要件定義書」が作成でき、スムーズにプロジェクトが進行します。そのためには、タスクの担当者を明確に割り振ることを忘れないようにしましょう。