要件定義

システム開発で用いられることのあるV字モデルについてご存知でしょうか。様々な開発手法がありますが押さえておくべきモデルの1つです。そこで本記事では、V字モデルについての概要をはじめ、メリットやデメリット、工程やW字モデルとの違いなどについて徹底解説いたします。

V字モデルとは

V字モデルとは、システム開発において開発の工程およびテストの相関をその名の通りVの字で表現したものを指します。具体的にはV字の左上から下まで順番に開発工程を書き出し、右側には開発工程に対応するテストを下から右上に書き出すことて、どの工程に対してどのテストを実施するのかが視覚的にわかりやすいという特徴があります。

V字モデルのメリット

システム開発においてV字モデルを採用することによって得られる代表的なメリットは下記の4点が挙げられます。

• テスト内容を明確にすることができる
• 作業進捗を把握しやすい
• 不具合が生じた場合の修正コスト削減を図ることができる

テスト内容を明確にすることができる

V字モデルを採用することによって、開発工程に対して実施するべきテスト内容を明確にすることが可能です。そのため、漏れがないようにテストを効率よく行うことができ、成果物の品質向上を図ることができます。

作業進捗を把握しやすい

V字モデルでは、テスト内容が明確であるため、テストにかかるスケジュールを見積もりやすいだけでなく、テストの結果によっては不具合が発生して修正を行うことになる際にも工数をチェックしやすいというメリットがあり、他の開発手法よりも作業進捗を把握しやすいと言えます。もし想定よりも遅れてしまっている場合には、人員調整を行うなど、対策も行いやすいでしょう。

不具合が生じた場合の修正コスト削減を図ることができる

V字モデルは、各開発工程に応じたテストが明確になっているため、もしテストで不具合が発生しても原因を特定したり、修正したりという作業が非常に容易であると言えます。他の開発手法であれば、テスト実施時に発生した不具合の原因を特定するのにとても時間がかかってしまうことも少なくないことを考慮すると、非常に効率が良い手法と言えるでしょう。

V字モデルのデメリット

V字モデルを採用すると、効率的かつ品質の高いシステム開発を行うことができますが、下記のようなデメリットも存在しますので、頭に入れておきましょう。

上流工程で問題があった場合手戻りリスクがある

V字モデルでは、各開発工程に応じたテストを実施するため、初期段階の上流工程で何かしらの不具合があった場合手戻りのリスクが大きくなり、想定よりも工数が増えてしまったり、開発スケジュールを圧迫したりということが起きる可能性があります。

V字モデルの工程

V字モデルの概要、メリットやデメリットを理解したところで、本項目では具体的な工程について解説いたします。

• 要求定義
• 要件定義
• 基本設計
• 詳細設計

要求定義

要求定義とは、クライアントの要求および機能をまとめたものですが、具体的には現状抱えている課題を洗い出し、その課題を解決するための理想の状態はどのようなものなのか、課題を解決するためにどのようなシステムや機能があれば良いのかが明確にすることを言います。

V字モデルにおける要求定義では、クライアントの要求を満たしているのかを確認するための受け入れテストとして、機能テストやユーザビリティテストが実施されます。この機能テスト及びユーザビリティテストはPM（プロジェクトマネージャー）が担当しますが、クライアントも積極的に関与しなければ成り立ちません。

要件定義

要件定義とは、クライアントの要求定義を実際にどのような機能を搭載して実現していくのかという要件をまとめたものです。具体的には、システム開発の目的をはじめ、予算や必要な機能、納期、スケジュール、必要人員、想定工数などを決定します。

V字テストにおける要件定義では、総合テストとして、確認テストや評価テスト、負荷テストなどが実施されます。これらのテストも、PM（プロジェクトマネージャー）が中心となって行いますが、クライアントの関与も欠かせません。

基本設計

基本設計とは、要件定義をもとにして、UI（ユーザーインターフェース）などの外側から見たシステム設計を行うことです。具体的には、搭載する機能の洗い出しをはじめ、取り扱うデータを整理したり、データを明確化したり、システム画面のレイアウトを決定したりします。

V字モデルにおける基本設計では、結合テストとしてブラックボックステストやインターフェーステスト、トップダウン・ボトムアップテストが実施されます。主にSE（システムエンジニア）とPM（プロジェクトマネージャー）が中心となりますが、クライアントも関わることができる最終チャンスでもあります。

詳細設計

詳細設計では、基本設計をベースとして、プログラマーに伝わるようにプログラミングの指示書及び設計書を作成します。V字モデルにおける詳細設計では、単体テストとしてホワイトボックステストを中心として行い、SE（システムエンジニア）が担当します。

V字モデルとウォーターフォール

ウォーターフォールは上流工程から下流工程に向けてまるで滝のように進んでいく開発手法です。万が一大きな不具合が発生してしまった場合などに手戻りのリスクが大きいというデメリットがあります。

しかしV字モデルであれば、各開発工程ごとに行われるテストが明確であるため、ウォーターフォールの進化版と言えるでしょう。

V字モデルとアジャイル開発

アジャイル開発とは、システム開発の過程では仕様及び設計の変更があって当たり前という前提のもと、開発当初から厳密な仕様は決定せずに大まかな仕様だけで細かなイテレーション（反復）開発を行い、小さな単位での実装からテスト実施を繰り返すことで徐々に開発を進めていく手法のことです。

ウォーターフォールの進化版とも言えるV字モデルとはそもそもの開発工程が大きく異なりますが、それぞれの開発工程に対応したテストを実施するという面では、慎重に品質を担保しながら開発を進めることができるので、似ている手法であると言えるでしょう。

V字モデルとW字モデルとの違い

W字モデルとは、V字モデルにおける左側に書き出される開発工程及び対応するテスト工程の作業を並行して実施する開発手法のことです。つまり、V字モデルの品質向上の方法をさらに詳細に表現したものであり、V字モデルの進化版と言えます。

V字モデルとW字モデルとの違いとしては、次の3点が挙げられます。

• 開発とテストを同時並行に進めていく
• 手戻りが少ない
• テストエンジニアが上流工程から参画

開発とテストを同時並行に進めていく

V字モデルでは、あくまで各開発工程に対応したテストを明確にするだけですが、W字モデルでは、同時並行で各テストを実施することになるため、V字モデルの唯一と言っても過言ではないデメリットである上流工程で不具合が発生してしまった場合にもカバーすることが比較的容易です。

手戻りが少ない

W字モデルでは、上流工程からテストを同時並行で実施するために、次の工程に進む際の不具合発生頻度は必然的に減少するという特徴があるため、結果的に手戻りも少なくなり、品質を向上させたり、コストカットやテスト工程の負担軽減を図ることができるでしょう。

テストエンジニアが上流工程から参画

W字モデルでは、上流工程からテストエンジニアが参画するため、他の開発手法とは異なり、テストエンジニアのプロジェクトに対する理解度が大きいと言えます。そのため、テストも効率よく実施できるのです。

まとめ

V字モデルについて、本記事では、V字モデルについての概要をはじめ、メリットやデメリット、工程やW字モデルとの違いなどについて徹底解説いたしました。

システム開発において、ウォーターフォール開発の進化版とも言えるV字モデルの効率の良さをご理解いただけたのではないでしょうか。品質を担保しつつ、各開発工程に対してのテストが明確なV字モデルを活用してプロジェクトを進めていってください。

システム開発において、要件定義については良く耳にするかと思いますが、「要求定義」について明確に説明できるという方はそう多くはありません。そこで本記事では、システム開発の要求定義について、概要をはじめ要件定義との違い、工程や成果物、ポイントなどを徹底解説いたします。

要求定義とは

要求定義とは、非技術者であるクライアントの目的及びニーズをヒアリングし、これから開発するシステムに何を求めているのか、そもそもなぜシステム開発をするのかを技術者であるベンダーが明確にする工程のことです。

もちろんヒアリングした内容だけを明確にすれば良いと言うことではなく、非技術者が言葉にできていない部分についても想像を張り巡らせつつ、過剰及び過少な要求はないかなど、最終的に実現可能なシステムの形を明確にする必要があります。

要求定義と要件定義の違い

よく耳にする要件定義とは、技術者がシステム開発するために定義する仕様のことを指します。つまり、非技術者であるクライアントが求めている要求をどのようなシステムで実現するのかをより具体的に考え、概要や機能要件、非機能要件などを定義するのです。

一方要求定義は、前述したとおり、あくまで非技術者であるクライアントからヒアリングを実施し、目的やニーズなどから開発するべきシステムはどのようなものなのか、なぜ開発が必要なのかを明確にすることであり、言葉は似ていても要件定義とは異なる意味を持ちます。

また、一般的なシステム開発工程としては、まずはじめに要求定義を行ってから要件定義を行い、基本設計、詳細設計、などと進めていきます。このことからも、要求定義は要件定義の前に行うべきものであり、本来要件定義の中で一色単にされない別工程という認識となります。

要求定義の工程

要求定義の工程は、下記のようにさらに細かく分類することができます。

• プロジェクトの目的を明確にする
• 現状から理想形を明確にする
• 品質やコスト、納期を明確にする

プロジェクトの目的を明確にする

要求定義を行う際、なぜ非技術者であるクライアントがシステム開発を行いたいと考えるに至ったのかという現状の課題と、その課題を解決するためにどのようなシステム開発を行うのかといったプロジェクトの目的を明確にする必要があります。

現状から理想形を明確にする

プロジェクトの目的を明確にしたら、非技術者であるクライアントが現状抱えている課題を踏まえながら、業務フローについて図に表すなどして業務の可視化を行い、さらにシステム開発後の理想形の業務フロー図も作成して、それぞれの業務の課題を照らし合わせつつ、開発するシステムについて搭載すべき機能などをすり合わせていきます。

品質やコスト、納期を明確にする

どれくらいの品質のシステムをどれくらいのコストや納期で開発するのかを非技術者であるクライアントに確認し、合意をとることも必要です。

要求定義の注意点

要求定義を行う際には、特に次の3点に気を付ける必要があります。

• プロジェクトが複雑化する
• クライアントの目線と開発者の目線は異なる
• 要件定義と一色単にしない

プロジェクトが複雑化する

何度も述べていますが、システム開発において要求定義では非技術者であるクライアントの目的やニーズ、要求を具体化します。しかし、クライアントが求める理想のシステムは、単に業務が効率化されれば良いというものではなく、あくまでビジネスの成長に欠かすことができない経営基盤の1つとして捉えられることが多くなってきており、だんだん複雑化してきているという現状があります。

そのため、要求定義の時点で、本当にクライアントが求めている正確な要求というものを明確にすること自体が難しかったり、明確にできても、プロジェクト自体がとても複雑なものだったりと様々な問題が生じる場合があるため、どこかで落とし所を見つけなければならないことも多々あるでしょう。

クライアントの目線と開発者の目線は異なる

当たり前のことですが、非技術者であるクライアントの目線と、技術者であるベンダーの目線は異なります。特にクライアント側は、要求定義の段階で、知識がないからとベンダーに多くを任せてしまうと、本来求めている使いやすいシステム開発ではなく、ベンダーが開発しやすいシステム開発に気づかずうちに舵を取られてしまい、最終的に完成したシステムが実際の現場では使用しにくく結果的に従業員達に利用されないものとなってしまうこともあるため、知識がなくとも、任せっきりにせず、要求をきちんとベンダーに伝えることが大切です。

もちろんベンダー側ももし多くを任せられることになったとしても、クライアントの目線で本当に使いやすいシステムなのかを所々で立ち止まって考える必要があるでしょう。

要件定義と一色単にしない

前述したように、要件定義と要求定義は本来異なり、別の工程となるべきものですが、多くの場合、要件定義の段階で要求及び要件のどちらも取り扱うことが多いという現状があります。しかし、それでは、非技術者であるクライアントの本来の要求を明確にする作業が曖昧なまま要件も並行して定義していくことになってしまうため、最終的に完成したシステムを納品した段階でクライアントが求めていたものと大きく異なるという事態になりかねません。

このことからも、あくまで要求定義を行ってから要件定義を行うように徹底することが大切です。

要求定義の成果物

要求定義での主な成果物としては次の2点が挙げられます。

• RFP（提案依頼書）
• 提案書及び見積書
• 要求仕様書

RFP（提案依頼書）

RFP（提案依頼書）とは、非技術者であるクライアントがベンダーに対して提案を依頼するためのドキュメント資料のことです。

RFP（提案依頼書）は、相見積もりをとる際にも用いられることがあり、具体的には、システム開発の目的をはじめ、自社の概要や組織体系、業務内容、現状抱えている課題、課題に対して達成したい理想的な形、開発するシステムに求める要求、プロジェクトに対しての自社の体制及び役割、技術者であるベンダーに依頼したい範囲、予算、想定納期、ベンダーに提案して欲しい事項などをまとめたものになります。一方でベンダーはクライアントから受け取ったRFP（提案依頼書）を要件定義に活用できます。

提案書及び見積書

非技術者であるクライアントからのRFP（提案依頼書）に対して、技術者であるベンダー側からの回答の役割を持つ資料が提案書及び見積書です。

具体的には、システムの提案をはじめ、プロジェクトの進行方法、ベンダーの体制及び役割などを、クライアントから提示された予算及び納期を踏まえて作成されます。

要求仕様書

正式な依頼となったら、ベンダーはRFP（提案依頼書）と提案書及び見積書を取りまとめ、よりわかりやすく要求仕様書を作成しておくとよりスムーズです。

要求定義のポイント

要求定義の段階では、様々な問題が出てきますが、解決するポイントをご紹介いたします。

要求仕様書を図式化及びレビューする

RFP（提案依頼書）などをもとに作成された要求仕様書は、文字だけでなく図式化したり、関係者間でレビューを実施することで非技術者であるクライアント及びベンダーの中でのギャップを埋めておくことができます。また、クライアントには可能な限り実際に使用するであろう現場の従業員を含めたレビューをしてもらうことが大切です。

まとめ

要求定義とは、本記事では、概要をはじめ要件定義との違い、工程や成果物、ポイントなどを徹底解説いたしました。

要件定義の中で要求定義も行われることが慣例化されている場合も多くありますが、本記事で述べた通り、本来は要求定義と要件定義は分けるべき工程です。非技術者であるクライアントのニーズにしっかりと応えるためにも、要求定義をきちんと行うようにしましょう。

システム開発において、最も重要であるといっても過言ではない要件定義。要件定義がきちんとまとまっていなければ、システムが完成したとしてもクライアントのイメージとは違う成果物ができてしまうといったトラブルに繋がりかねません。

本記事では、要件定義の概要をはじめ、要件定義の流れや進め方、要件定義において実施すべきことや注意点等を徹底解説致します。

要件定義とは

要件定義とは、システム開発及びソフトウェア開発等において、クライアントの要求を実現するために必要な方法について検討を行い、開発のプロセスを文章としてまとめたもののことです。システム開発において、必ず最初に取り組むべきこととして、要件定義が挙げられます。要件定義がなければ、プロジェクトのスタートは不可能であると言っても過言ではありません。

要件定義・要求定義の違い

要件定義と似ている言葉として、要求定義があります。要求定義とは、クライアントが求める最終的なシステムの完成形及び希望等を明確にすることです。前述した要件定義は、この要求定義の内容を加味してまとめられます。さらに、システム開発中に要求定義の内容が変更となる場合があり、その際には要件定義も併せて変更する必要が生じます。

要件定義と基本設計の違い

基本設計とは、要件定義で決定した機能を具現化するための設計作業のことです。要件定義では、systemに搭載する機能を文章で表現していますが、基本設計では、systemに搭載する機能を画面イメージとして設計することで、開発を行うsystemにおいてvender及びclientの間に大きな認識のズレが生じていないかを確認していくことになります。

なぜ要件定義が必要なのか

前述してきた通り、要件定義とは、クライアントが求める成果物をスムーズに納品するために必要な開発のプロセスです。要件定義がなければクライアントの要望と全く違う成果物を納品してしまったというトラブルが多発してしまいます。このようなトラブルが発生するリスクを軽減するために、ベンダー及びクライアントは密な連携を取り合うことが大切です。

要件定義の流れ及び進め方

本項目では、システム開発における要件定義の流れ及び進め方について、解説致します。

1. 業務要件の整理

業務要件とは、システム開発及びソフトウェア開発等の初期の工程において、クライアントの現状の業務について詳しく分析を行い、将来新しく実現するべき業務の流れを明確化したものです。

要件定義をまとめる初期の段階で、業務要件の整理を実施することで、開発するシステムに搭載される機能を決定していきます。

2. クライアントへの聞き取り調査

前述した業務要件の整理を実施する際にも必要となりますが、要件定義において、ベンダーからクライアントへの聞き取り調査は必須事項です。クライアントが構築し運用していきたいと考えているシステムや、解決したい実務の課題等の要求をきちんとベンダーは認識する必要があります。

ただし、ベンダーはクライアントの言いなりになってはいけませんし、クライアントはベンダー任せにしてはいけません。ベンダーはクライアントの要求が実現可能か否かを判断する必要があります。一方で、クライアントはベンダーに任せきりにしてしまうと、成果物がイメージとかけ離れているといったことになりかねないのです。

3. クライアントの要求を細分化

ベンダーはクライアントへの聞き取り調査を実施した後、要求の整理を行い、課題を見つけたり、実現可能性を検討したりする必要があります。

現在の業務フローの作成

クライアントの現状を把握し、現在の業務フローを作成します。

将来の業務フローの作成　

新しく開発するシステムを導入することで想定できる将来の業務フローを作成します。この際、前述した現在の業務フローよりも、現場担当者の業務が軽減されていた場合、システムによって効率化されたフローと言えるでしょう。

業務要件一覧の作成

クライアント側が主導となって、現在及び将来の業務フローをさらに一段階掘り下げていき、Excelシートなどに業務要件一覧を作成します。

機能要件一覧の作成

機能要件とは、クライアントの要求を実現するためのシステムを構築するために、必要となる最低限の機能のことです。将来の業務フローの実現に向けて、実際のシステムに搭載する機能の一覧を作成します。

システム構成

機能要件一覧を元に、ベンダーはシステム構成を考案します。

外部システムとの連携

開発するシステムが、クライアントの現在使用している既存システム及び外部サービス等との連携が必要か否かを明確にします。

データベース構造

ベンダーのエンジニアによるプログラミングを効率よく進行していくために、システムに最適なデータベース構成を決定します。

画面構成

ベンダーは、開発していくシステムの完成形をクライアントがスムーズにイメージできるよう、システム開発に詳しくない人でも分かるような画面構成図（どのようなシステムがあるかという一覧）及びワイヤーフレーム（システムのレイアウトを定める設計図）を作成します。

非機能要件

非機能要件とは、システム開発において、クライアントが潜在的に持っているユーザビリティ及びセキュリティなどの要件のことです。前述した機能要件とは違い、クライアント側が明確に意識している要件ではないことが多く、ベンダーは地道な聞き取り調査やコミュニケーションから非機能要件を正確に洗い出す必要があります。

ライセンス一覧

クライアントは、外部のシステムツールを活用する場合、ライセンス取得のため、一覧表を作成し整理する必要があります。

4. 要件定義書の作成

前述した1〜3の工程の後、実際に要件定義書を作成します。要件定義書に記載すべき最低限の項目としては、「システム」「機能要件」「非機能要件」の3項目が挙げられます。

システムに関する項目

要件定義書の要とも言われるのが、システムに関する項目です。開発するシステムはどのようなものになるのかをクライアントに詳しく説明する必要があります。

システムの概要

クライアントに対し、開発するシステムがどのような機能を搭載しているのかという点を説明します。

システムを導入する目的

開発するシステムに搭載する機能によって、クライアントのどの要求を実現していくことができるのかという点を説明します。

システム導入後の業務フロー

開発したシステムが導入されると、現在の業務フローに対し、将来の業務フローがどのように効率化できるのかについて説明します。

機能要件に関する項目

開発するシステムの種類及び構造、処理することができる内容について説明します。

非機能要件に関する項目

開発するシステムのユーザビリティ及びセキュリティ等について説明します。

要件定義の成果物とは？

要件定義の成果物は、前述した要件定義書です。システム開発において、要件定義及び要件定義書の作成は、ベンダー及びクライアントの間での認識のギャップを少なくするためにとても大切であると言えます。

しかし、要件定義書には定められたフォーマットがないため、クライアントによって仕様が変わってくるケースが多いです。仕様が変わったとしても、ベンダーはクライアントから見てわかりやすい要件定義書を作成しましょう。

具体的には、階層構造で文章をまとめたり、IT専門用語を使用しないように気をつけたりといった点に気をつけることが大切です。また、要件定義書はベンダー及びクライアント双方の協力の元作成されるべきものであるため、双方の成果物であるとも言えます。

要件定義の成果物サンプル・例

要件定義の成果物は要件定義書であると述べましたが、要件定義書を細分化すると次のような成果物に分けることが可能です。

• システム概要
• 全体図
• 機能一覧
• 業務フロー図
• 非機能要件
• 納品対象
• 現状分析資料
• 用語集　など

実際の要件定義書のサンプルは下記の通りです。

• 厚生労働省『毎月勤労統計調査オンラインシステムの更改及び運用・保守に係る業務一式 要件定義書』
• 厚生労働省『厚生労働省情報提供システムの更改整備及び運用・保守業務一式 要件定義書』

要件定義を行うためにベンダーに必要な4つのスキル

要件定義を行うために、ベンダーに必要とされる4つのスキルについて解説致します。

クライアントの意図を組むコミュニケーションスキル

ベンダーには、システム開発の能力だけでなく、クライアントの意図を汲み取って、引き出していコミュニケーションスキルが必要です。前述した通り、クライアントにはクライアント自身が気づいていないような潜在的な要求が必ず存在します。

潜在的な要求をきちんと引き出すことができなければ、システムが完成した後に、実は必要だった機能が搭載されていないといったトラブルに発展してしまうことがあるので、密なコミュニケーションが必須となるのです。

開発業務に関する知識及び経験

要件定義をまとめるベンダーには、当たり前ではありますが、システム開発業務に関する豊富な知識及び経験が必須となります。知識や経験が浅いと、実際に実現不可能なシステム開発に着手してしまったり、無理なスケジュールを立ててしまったりと、後々クライアントに多大な迷惑をかけてしまうことに繋がりかねません。

スケジュール及びリスク管理のスキル

システム開発において、要件定義をまとめる作業はとても大切ですが、時間がかかりすぎると作業スケジュールに支障をきたします。そのため、要件定義をまとめる立場のベンダーには、プロジェクト全体の進捗状況を把握し、適切に動けるスキル及び経験が必須となるでしょう。

さらに、クライアントの要求を全て実現することが不可能である場合もあり、その際には納期及び予算、実際にシステムに搭載できる機能等も含めて検討を行うリスク管理が行えることも求められます。

ドキュメント作成のスキル

ベンダーにはプロジェクトメンバー全員が、共通の認識を持つことが可能なドキュメント作成のスキルが必要です。見る人によって、捉え方が変わってしまうようなドキュメントを作成してしまうと、ミスやトラブル等の原因となってしまう場合もあります。

要件定義においてクライアント側が実施すべきこと及び注意点

要件定義をまとめていくのはベンダーですが、クライアントはベンダーに任せきりではいけません。本項目では要件定義において、クライアント側が実施すべきこと及び注意点について解説致します。

社内見解の統一

クライアント側に複数の担当者がいる場合、特に重要となってくるのが社内見解の統一です。クライアント側で意見がまとまらない状態で、ベンダーにシステム開発を依頼しても意図しない成果物が完成したり、運用する現場の人間のことを考えて作られなかったりといった弊害が生じてしまう可能性があります。

事前に解決すべき課題を明確化

クライアントは、自社で解決すべき課題を明確化し、ベンダーに詳細を伝えることが必要です。自社でどんな課題を解決したいのかという点が明確になっていなければ、ベンダーもどのようなシステム開発を行っていいのかわからない上、工程に優先順位を付けることも困難となってしまいます。

現場のニーズを汲み取る

クライアントは、システム導入後、実際に運用していく現場のニーズをきちんと汲み取ることが大切です。プロジェクトメンバーに現場担当者も複数名入れ、現場担当者の意見を反映できる体制を整えましょう。

要件定義においてベンダーが実施すべきこと及び注意点

要件定義をまとめていくのはベンダーですが、ベンダーはクライアントの言いなりではいけません。本項目では要件定義において、ベンダーが実施すべきこと及び注意点について解説致します。

クライアントの真の要求を引き出す

ベンダーは、クライアントの潜在的な真の要求を引き出すことが必要です。真の要求を引き出すことができないまま、要件定義をまとめ、システム開発を行ったとしても、成果物がクライアントのイメージと乖離してしまっていてトラブルに発展してしまうといったことになりかねません。

クライアントの要求が実現可能か否かの判断

ベンダーは、クライアントの要求をそのまま鵜呑みにせず、現実的に実現可能か否かを判断する必要があります。技術的な面だけでなく、予算や納期スケジュール等も加味することが大切です。

誰でも理解できるドキュメントの作成

ベンダーは、システム開発に詳しくない人が見たとしても理解可能なドキュメントを作成し、クライアントと内容を共有する必要があります。IT専門用語等を多用したようなドキュメントだと、クライアントは完成後のシステムのイメージを描くことが困難です。また、イメージできたとしても、ベンダーと認識のギャップがある可能性があります。ベンダー及びクライアント双方の認識が共通となるようなドキュメントを作成しましょう。

担当者を明確にする

ベンダーはクライアントの担当者を明確にしておく必要があります。曖昧なままプロジェクトが進行してしまうと、不要な業務が増えてしまう可能性があり、さらに本来クライアント側が実施すべき業務までベンダーが引き受けてしまうことにも繋がりかねません。

まとめ

本記事では、要件定義の概要をはじめ、要件定義の流れや進め方、要件定義において実施すべきことや注意点等を徹底解説致しました。要件定義は、ベンダー及びクライアント双方が密に連携しあってまとめていくことで、クライアントにとって本当に必要なシステム開発に繋げていくことが可能です。ベンダー及びクライアントはどちらかに任せきりにすることなく、積極的にコミュニケーションを取り合って要件定義をまとめましょう。