システムに組み込む要望をまとめる要件定義が曖昧なものだとその後のシステム制作にも影響が出ます。
要件定義は上流工程として重要な役割を担っているのです。
要件定義の進め方について詳しく知りたいと考えている方もいらっしゃるかもしれません。
この記事では要件定義の進め方について解説していきます。
どのようなスキルが必要なのか、記載すべき項目は何であるのかも紹介していますので参考にしてください。
目次
要件定義の役割
要件定義はクライアントの要望をまとめ、どのように対応していくかを記したものです。
クライアントの要望をしっかりと聞き取り、正しく認識していなければ要件定義が行なえません。
クライアントはシステムを導入することにより、抱えている問題を解決したいと考えているのです。
そのため、問題解決のための要望を理解することが大切です。
的はずれな要件定義を行ってしまうと、クライアントの問題は解決しません。
要件定義の役割を理解して、クライアントの要望に応えられるようにしましょう。
プロジェクト成功の鍵
プロジェクトを開始する際は、まずは要件定義から始めることが多いでしょう。
クライアントの要望を明確にしてそれにどう対応していくのかを決めることでシステムの内容も決まるのです。
要件定義でクライアントの要望を明確にしておかなければ、どのようなシステムを作るのか誰もわかりません。
クライアントからしっかりとヒアリングをして、抱えている問題点と要望を明確にしましょう。
要件定義を適切に行うことでプロジェクトが成功に近づくのです。
インプットの工程も大切に
クライアントは今現在抱えている問題を解決するために新しいシステムの導入を検討します。
要件定義をする際はクライアントの現状を把握するインプットの工程も大切です。
システムの改善や刷新などは、まずクライアントの現状を把握することから始まります。
クライアントが現状どのようなシステムを保有し、どのような問題を抱えているか調査しましょう。
システムの書面があれば見せてもらい、ない場合は担当者などからヒアリングします。
成果物は要件定義書
要件定義は最終的に要件定義書を完成させて成果物とします。
要件定義書は実装予定のシステムをクライアントに説明するものです。そのため実装予定のシステムを詳細に記述します。
クライアントはシステムのプロではありません。そのため要件定義書はプロだけに通じるような書類では意味がないのです。
クライアントが要件定義書を見て理解し納得できるよう注意しましょう。
UX・CXの事例はこちら
要件定義書を作成するステップ
要件定義の成果物である要件定義書を作成するステップを紹介します。
クライアントの求めるシステムを完成させるためにも、それぞれのステップのポイントをおさえておきましょう。
クライアントが読んで納得できるような要件定義書を提出することにより、信頼関係が生まれます。
ユーザーからの要求をヒアリング
ユーザーからのヒアリングは要件定義やシステムの品質に大きく影響します。
ユーザーがどのような問題を抱えているのか、何を解決してほしいのかを見極めるのがポイントです。
気をつけなければならないのは、ユーザーの要望をすべて受け入れるわけにはいかないという点です。
ユーザーはシステムに関してはプロではありません。そのため実現不可能な要望を提案することもあるでしょう。
制作側としてできないことをクライアントとすり合わせていく必要もあります。
要求を細分化
ヒアリングが終われば、ヒアリングして得た情報を分析してクライアントの要望を細分化していきます。
要望を細分化するのが要件定義です。
クライアントの要望を鵜呑みにするのではなく、様々な角度から検討しましょう。
クライアントの抱える問題点と解決策をひとつずつ検討して文章に落とし込みます。
要望を細分化することで、クライアントの抱える問題を解決できるようなシステムを考えることができるのです。
要件定義書を作成
最後に成果物である要件定義書を作成します。
要件定義書には以下のような項目があると良いでしょう。
- システムの概要
- システム制作のフロー
- クライアントの要望と必要要件
この他に、細分化した機能の要件を記載することもできます。
要件定義書はクライアントにも理解できるよう、専門的な言葉には注釈を入れるなど工夫しましょう。
・ヒアリングでクライアントの要求を把握する
・要求を細分化して明確にする
・読みやすい要件定義書を作成する
UX・CXの事例はこちら
要件定義に必要なスキル
要件定義をする上で必要なスキルを紹介します。
要件定義では「ヒアリング」「要求の細分化」「要件定義書作成」という段階がありました。
それぞれ求められるスキルが異なりますので、段階ごとに必要なスキルを確認しておきましょう。
要求を引き出すスキル
要件定義の最初のステップであるヒアリングには要求を引き出すスキルが必要です。
クライアントとコミュニケーションを取り、クライアントの抱えている問題点を引き出すことになります。
クライアントの意図を正しく読むことができなければ抱えている問題点の認識も間違ったものになってしまうのです。
要件定義でクライアントの要望を知ることができなければ、クライアントの問題点を解決するシステムを作ることはできません。
その結果、クライアントが求めているシステムとは違ったものができあがってしまうのです。
そうならないためにも、クライアントの要望を正確に引き出すスキルは重要になります。
実現可能なシステムの設計を把握するスキル
クライアントはシステムのプロではありませんので、好きなように要望を出します。それはクライアントとして当然の姿勢です。
少しでも問題点を解決できるようなシステムが欲しいクライアントは、多くの要望を出すことが正しい姿勢といえます。
しかしクライアントの要望の中には実現不可能なものも含まれているでしょう。
それが実現可能かどうか判断するスキルが必要です。
実現不可能なものを実現可能なシステムにすり合わせるのが、クライアントとの話し合いでは重要になります。
要件をドキュメントに落とし込むスキル
要件定義は要件定義書を作成することが目標です。
クライアントの要望を盛り込み、問題点を解決できるようなシステムをまとめた要件定義書が成果物になります。
要件定義書はクライアントも見るものです。
そのため見る人によって受ける印象が違うといったドキュメントは要件定義書にはふさわしくありません。
要件を誰が見ても意図が伝わるようにドキュメントへ落とし込むスキルが必要になるでしょう。
・ヒアリングで正確な情報を把握するスキル
・実現可能なシステムかどうかを判断するスキル
・読みやすいドキュメントを作成するスキル
支援実績やコンサルティングの詳細は、実績・事例紹介のページをご覧ください。
要件定義書に記載すべき項目
クライアントはそれぞれ違う悩みを抱えています。そのためクライアントによって要件定義書の内容は違うものになるでしょう。
しかし、ドキュメントにまとめる際に記載すべき項目が分かっていれば何を書けばよいかも考えられます。
この章では要件定義書に記載すべき項目をまとめていますので参考にしてください。
その1:システムに関する項目
システムに関する項目は以下のようなものが考えられます。
- システム概要
- 導入の目的
- システム導入後の業務フロー
どのようなシステムであるかを説明するためシステム概要の項目が必要です。
また「機能を導入する目的」では、システム導入後どのようにクライアントの要望が実現されるのかを説明します。
システムを導入するとどのように業務を行うのか、システム導入後の業務フローも必要です。
その2:機能要件に関する項目
クライアントが求めた機能を機能要件に関する項目でまとめます。
クライアントが求めている機能が明確化されれば、システムを制作するSEもイメージがはっきりとするでしょう。
システムで解決できる内容を提示しておくのもこの項目です。
クライアントの予算を考えながら、予算内で実現できるように項目を調整します。
その3:非機能要件に関する項目
システムの機能以外でクライアントが求めているものをまとめる必要もあります。
システムの保守や効率性など、システムでは表現できないものも明文化しておく必要があるのです。
しかしクライアントはシステムのプロではありませんので、非機能要件を十分に考えていない場合もあります。
機能要件が定まった後、クライアントと打ち合わせを重ねて非機能要件の必要性をイメージしてもらいましょう。
良い要件定義書の必須条件は
要件定義書はシステムを開発するすべての情報を把握できる文書になります。
システム開発に関わる人に情報を共有するための文書ですので、読んだ人に正しく理解してもらえるものが理想です。
良い要件定義書の必須条件を紹介しますので、ポイントを確認してみてください。
専門知識がなくても内容が分かること
要件定義書を読むのはシステム開発のプロだけではありません。
自社の社員はもちろんのこと、クライアントも要件定義書を読んで内容を確認するのです。
そのため、要件定義書はシステム開発の専門知識を持たないクライアントが読んでも内容がわかる文書である必要があります。
要件定義書を読むすべての人が理解できるような表現を心がけてください。
専門的な用語の羅列はなるべく避けましょう。もし専門用語を使用するのであれば、解説を入れるなどの工夫をします。
項目ごとに分かりやすく記載できているかを確認するのも良いでしょう。
問題の解決策が記載されていること
クライアントは抱えている問題を解決するためにシステムを導入するのです。
そのためシステム開発の全容がわかる要件定義書には「導入するシステムでどのように問題を解決するのか」を記載してください。
問題の解決策がないままでは、実際にどのようなシステムを開発すればよいのか共有もできません。
・クライアントでも理解できる内容
・問題解決方法が共有できている
要件定義と要求定義が異なる点
要件定義に似た言葉で要求定義というものがあります。
システムを動かすための仕様を定義したものが要件定義です。
クライアントの問題を解決できるシステムの詳細を詰めていくことで定義することができます。
一方、要求定義はシステムに何を求めるかを定義したものです。
どのようなシステムが欲しいかを吟味して要求をまとめたものになります。
できる人は要件定義をどう進める?
要件定義をスムーズに行える人はどのように要件定義を進めているのか気になる方もいらっしゃるかもしれません。
クライアントからヒアリングする際も、ポイントを理解しているとスムーズに話し合いが終わります。
クライアントからのヒアリングでは、現在使用している業務フローをしっかりと確認するようにしてください。
まずクライアントからの要求をまとめた要求定義書を作成するのもひとつの手です。
要求定義書をまとめることによって、クライアントの要求とそれに応えるためのシステムが見えてくるでしょう。
またプロジェクトでの担当者を明確にしておくのも重要なポイントになります。
現在の業務整理や将来的なビジョンの明確化などはクライアントの仕事として明文化することも必要です。
支援実績やコンサルティングの詳細は、実績・事例紹介のページをご覧ください。
要件定義を的確に行い、開発プロジェクトを成功させる!
要件定義でクライアントの要望を正確に把握することで、それに対応するシステムを制作することができます。
プロジェクトをスムーズに進行させるためにも、最初にしっかりと要件定義を行うことが重要なのです。
的確に要件定義を行うことにより、クライアントの要望を実現できるシステムが出来上がります。
抱えている問題を解決できるシステムが納品されるとクライアントは喜ぶでしょう。
クライアントが納得して新しいシステムを使用することが開発プロジェクトのゴールなのです。
要件定義を的確に行い、開発プロジェクトを成功させましょう。
要件定義の進め方で悩んだら
要件定義の進め方にはいくつかの段階がありました。それぞれの段階で必要なスキルも異なります。
開発プロジェクトの要ともいえる要件定義は重要だといえるでしょう。
要件定義をスムーズに行うことに不安や悩みを抱えている方もいらっしゃるかもしれません。
要件定義の進め方で悩んだらデジマクラスにご相談ください。
どのステップに問題があるかなどを一緒に検討して、要件定義を成功に導きます。
UX・CXの事例はこちら
まとめ
プロジェクト開発には要件定義は欠かせません。
クライアントの要望を正確に把握して、それに応えるシステムを考えましょう。
システムの専門家だけではなく、クライアントが読んでも理解できる要件定義書を目指します。
的確な要件定義書を作成することでシステム開発のプロジェクトがスムーズに進行するでしょう。
もし要件定義での進め方に不安がある場合はデジマクラスにご相談ください。
一緒に問題点を解決して、的確な問題提議書を完成させましょう。