システム開発において、最も重要であるといっても過言ではない要件定義。要件定義がきちんとまとまっていなければ、システムが完成したとしてもクライアントのイメージとは違う成果物ができてしまうといったトラブルに繋がりかねません。
本記事では、要件定義の概要をはじめ、要件定義の流れや進め方、要件定義において実施すべきことや注意点等を徹底解説致します。
要件定義とは
要件定義とは、システム開発及びソフトウェア開発等において、クライアントの要求を実現するために必要な方法について検討を行い、開発のプロセスを文章としてまとめたもののことです。システム開発において、必ず最初に取り組むべきこととして、要件定義が挙げられます。要件定義がなければ、プロジェクトのスタートは不可能であると言っても過言ではありません。
要件定義・要求定義の違い
要件定義と似ている言葉として、要求定義があります。要求定義とは、クライアントが求める最終的なシステムの完成形及び希望等を明確にすることです。前述した要件定義は、この要求定義の内容を加味してまとめられます。さらに、システム開発中に要求定義の内容が変更となる場合があり、その際には要件定義も併せて変更する必要が生じます。
要件定義と基本設計の違い
基本設計とは、要件定義で決定した機能を具現化するための設計作業のことです。要件定義では、systemに搭載する機能を文章で表現していますが、基本設計では、systemに搭載する機能を画面イメージとして設計することで、開発を行うsystemにおいてvender及びclientの間に大きな認識のズレが生じていないかを確認していくことになります。
なぜ要件定義が必要なのか
前述してきた通り、要件定義とは、クライアントが求める成果物をスムーズに納品するために必要な開発のプロセスです。要件定義がなければクライアントの要望と全く違う成果物を納品してしまったというトラブルが多発してしまいます。このようなトラブルが発生するリスクを軽減するために、ベンダー及びクライアントは密な連携を取り合うことが大切です。
要件定義の流れ及び進め方
本項目では、システム開発における要件定義の流れ及び進め方について、解説致します。
- 業務要件の整理
業務要件とは、システム開発及びソフトウェア開発等の初期の工程において、クライアントの現状の業務について詳しく分析を行い、将来新しく実現するべき業務の流れを明確化したものです。
要件定義をまとめる初期の段階で、業務要件の整理を実施することで、開発するシステムに搭載される機能を決定していきます。
- クライアントへの聞き取り調査
前述した業務要件の整理を実施する際にも必要となりますが、要件定義において、ベンダーからクライアントへの聞き取り調査は必須事項です。クライアントが構築し運用していきたいと考えているシステムや、解決したい実務の課題等の要求をきちんとベンダーは認識する必要があります。
ただし、ベンダーはクライアントの言いなりになってはいけませんし、クライアントはベンダー任せにしてはいけません。ベンダーはクライアントの要求が実現可能か否かを判断する必要があります。一方で、クライアントはベンダーに任せきりにしてしまうと、成果物がイメージとかけ離れているといったことになりかねないのです。
- クライアントの要求を細分化
ベンダーはクライアントへの聞き取り調査を実施した後、要求の整理を行い、課題を見つけたり、実現可能性を検討したりする必要があります。
現在の業務フローの作成
クライアントの現状を把握し、現在の業務フローを作成します。
将来の業務フローの作成
新しく開発するシステムを導入することで想定できる将来の業務フローを作成します。この際、前述した現在の業務フローよりも、現場担当者の業務が軽減されていた場合、システムによって効率化されたフローと言えるでしょう。
業務要件一覧の作成
クライアント側が主導となって、現在及び将来の業務フローをさらに一段階掘り下げていき、Excelシートなどに業務要件一覧を作成します。
機能要件一覧の作成
機能要件とは、クライアントの要求を実現するためのシステムを構築するために、必要となる最低限の機能のことです。将来の業務フローの実現に向けて、実際のシステムに搭載する機能の一覧を作成します。
システム構成
機能要件一覧を元に、ベンダーはシステム構成を考案します。
外部システムとの連携
開発するシステムが、クライアントの現在使用している既存システム及び外部サービス等との連携が必要か否かを明確にします。
データベース構造
ベンダーのエンジニアによるプログラミングを効率よく進行していくために、システムに最適なデータベース構成を決定します。
画面構成
ベンダーは、開発していくシステムの完成形をクライアントがスムーズにイメージできるよう、システム開発に詳しくない人でも分かるような画面構成図（どのようなシステムがあるかという一覧）及びワイヤーフレーム（システムのレイアウトを定める設計図）を作成します。
非機能要件
非機能要件とは、システム開発において、クライアントが潜在的に持っているユーザビリティ及びセキュリティなどの要件のことです。前述した機能要件とは違い、クライアント側が明確に意識している要件ではないことが多く、ベンダーは地道な聞き取り調査やコミュニケーションから非機能要件を正確に洗い出す必要があります。
ライセンス一覧
クライアントは、外部のシステムツールを活用する場合、ライセンス取得のため、一覧表を作成し整理する必要があります。
- 要件定義書の作成
前述した1〜3の工程の後、実際に要件定義書を作成します。要件定義書に記載すべき最低限の項目としては、「システム」「機能要件」「非機能要件」の3項目が挙げられます。
システムに関する項目
要件定義書の要とも言われるのが、システムに関する項目です。開発するシステムはどのようなものになるのかをクライアントに詳しく説明する必要があります。
システムの概要
クライアントに対し、開発するシステムがどのような機能を搭載しているのかという点を説明します。
システムを導入する目的
開発するシステムに搭載する機能によって、クライアントのどの要求を実現していくことができるのかという点を説明します。
システム導入後の業務フロー
開発したシステムが導入されると、現在の業務フローに対し、将来の業務フローがどのように効率化できるのかについて説明します。
機能要件に関する項目
開発するシステムの種類及び構造、処理することができる内容について説明します。
非機能要件に関する項目
開発するシステムのユーザビリティ及びセキュリティ等について説明します。
要件定義の成果物とは？
要件定義の成果物は、前述した要件定義書です。システム開発において、要件定義及び要件定義書の作成は、ベンダー及びクライアントの間での認識のギャップを少なくするためにとても大切であると言えます。
しかし、要件定義書には定められたフォーマットがないため、クライアントによって仕様が変わってくるケースが多いです。仕様が変わったとしても、ベンダーはクライアントから見てわかりやすい要件定義書を作成しましょう。
具体的には、階層構造で文章をまとめたり、IT専門用語を使用しないように気をつけたりといった点に気をつけることが大切です。また、要件定義書はベンダー及びクライアント双方の協力の元作成されるべきものであるため、双方の成果物であるとも言えます。
要件定義の成果物サンプル・例
要件定義の成果物は要件定義書であると述べましたが、要件定義書を細分化すると次のような成果物に分けることが可能です。
- システム概要
- 全体図
- 機能一覧
- 業務フロー図
- 非機能要件
- 納品対象
- 現状分析資料
- 用語集 など
実際の要件定義書のサンプルは下記の通りです。
要件定義を行うためにベンダーに必要な4つのスキル
要件定義を行うために、ベンダーに必要とされる4つのスキルについて解説致します。
クライアントの意図を組むコミュニケーションスキル
ベンダーには、システム開発の能力だけでなく、クライアントの意図を汲み取って、引き出していコミュニケーションスキルが必要です。前述した通り、クライアントにはクライアント自身が気づいていないような潜在的な要求が必ず存在します。
潜在的な要求をきちんと引き出すことができなければ、システムが完成した後に、実は必要だった機能が搭載されていないといったトラブルに発展してしまうことがあるので、密なコミュニケーションが必須となるのです。
開発業務に関する知識及び経験
要件定義をまとめるベンダーには、当たり前ではありますが、システム開発業務に関する豊富な知識及び経験が必須となります。知識や経験が浅いと、実際に実現不可能なシステム開発に着手してしまったり、無理なスケジュールを立ててしまったりと、後々クライアントに多大な迷惑をかけてしまうことに繋がりかねません。
スケジュール及びリスク管理のスキル
システム開発において、要件定義をまとめる作業はとても大切ですが、時間がかかりすぎると作業スケジュールに支障をきたします。そのため、要件定義をまとめる立場のベンダーには、プロジェクト全体の進捗状況を把握し、適切に動けるスキル及び経験が必須となるでしょう。
さらに、クライアントの要求を全て実現することが不可能である場合もあり、その際には納期及び予算、実際にシステムに搭載できる機能等も含めて検討を行うリスク管理が行えることも求められます。
ドキュメント作成のスキル
ベンダーにはプロジェクトメンバー全員が、共通の認識を持つことが可能なドキュメント作成のスキルが必要です。見る人によって、捉え方が変わってしまうようなドキュメントを作成してしまうと、ミスやトラブル等の原因となってしまう場合もあります。
要件定義においてクライアント側が実施すべきこと及び注意点
要件定義をまとめていくのはベンダーですが、クライアントはベンダーに任せきりではいけません。本項目では要件定義において、クライアント側が実施すべきこと及び注意点について解説致します。
社内見解の統一
クライアント側に複数の担当者がいる場合、特に重要となってくるのが社内見解の統一です。クライアント側で意見がまとまらない状態で、ベンダーにシステム開発を依頼しても意図しない成果物が完成したり、運用する現場の人間のことを考えて作られなかったりといった弊害が生じてしまう可能性があります。
事前に解決すべき課題を明確化
クライアントは、自社で解決すべき課題を明確化し、ベンダーに詳細を伝えることが必要です。自社でどんな課題を解決したいのかという点が明確になっていなければ、ベンダーもどのようなシステム開発を行っていいのかわからない上、工程に優先順位を付けることも困難となってしまいます。
現場のニーズを汲み取る
クライアントは、システム導入後、実際に運用していく現場のニーズをきちんと汲み取ることが大切です。プロジェクトメンバーに現場担当者も複数名入れ、現場担当者の意見を反映できる体制を整えましょう。
要件定義においてベンダーが実施すべきこと及び注意点
要件定義をまとめていくのはベンダーですが、ベンダーはクライアントの言いなりではいけません。本項目では要件定義において、ベンダーが実施すべきこと及び注意点について解説致します。
クライアントの真の要求を引き出す
ベンダーは、クライアントの潜在的な真の要求を引き出すことが必要です。真の要求を引き出すことができないまま、要件定義をまとめ、システム開発を行ったとしても、成果物がクライアントのイメージと乖離してしまっていてトラブルに発展してしまうといったことになりかねません。
クライアントの要求が実現可能か否かの判断
ベンダーは、クライアントの要求をそのまま鵜呑みにせず、現実的に実現可能か否かを判断する必要があります。技術的な面だけでなく、予算や納期スケジュール等も加味することが大切です。
誰でも理解できるドキュメントの作成
ベンダーは、システム開発に詳しくない人が見たとしても理解可能なドキュメントを作成し、クライアントと内容を共有する必要があります。IT専門用語等を多用したようなドキュメントだと、クライアントは完成後のシステムのイメージを描くことが困難です。また、イメージできたとしても、ベンダーと認識のギャップがある可能性があります。ベンダー及びクライアント双方の認識が共通となるようなドキュメントを作成しましょう。
担当者を明確にする
ベンダーはクライアントの担当者を明確にしておく必要があります。曖昧なままプロジェクトが進行してしまうと、不要な業務が増えてしまう可能性があり、さらに本来クライアント側が実施すべき業務までベンダーが引き受けてしまうことにも繋がりかねません。
まとめ
本記事では、要件定義の概要をはじめ、要件定義の流れや進め方、要件定義において実施すべきことや注意点等を徹底解説致しました。要件定義は、ベンダー及びクライアント双方が密に連携しあってまとめていくことで、クライアントにとって本当に必要なシステム開発に繋げていくことが可能です。ベンダー及びクライアントはどちらかに任せきりにすることなく、積極的にコミュニケーションを取り合って要件定義をまとめましょう。
