要件定義とは
いきなりですが、問題です。
要件定義とは、読んで字のごとく「要件」を「定義」することではありますが、何の要件をどのように定義するのでしょうか？
・・・・・
・・・・・
・・・・・
「顧客が要求する事柄を、「業務要件」「機能要件」「非機能要件」として定義する」 これが正解です。
要件定義では、顧客が要求する事柄を「業務要件」「機能要件」「非機能要件」として定義するうえで、さまざまな情報を整理するだけではなく、決まっていないことを決めることが重要です。
要件定義は「理想」
要件定義の前工程では要求定義を行い、後工程では基本設計を行いますが、それぞれの工程で行うことを以下のように捉えると、要件定義の理解が深まります。
要求定義＝「夢」
要件定義＝「理想」
基本設計＝「現実」
つまり、要件定義はまだ「理想」の域を出ておらず、システム化に向けて実現可能性の検討はするものの、システムでは実現できない内容も多分に含まれている可能性があります。
なぜ要件定義は重要なのか
品質は要件定義を含む上流工程が決め手となる
上図は開発手法の一つであるウォーターフォールモデルをＶ字で表したもので、通称「Ｖ字モデル」と呼ばれるものです。
このＶ字モデル左側の上流工程で品質が作り込まれることより、品質の良し悪しの9割は上流工程に委ねられます。
その中でも要件定義工程で作成した要件定義書は開発の起点となるインプット情報となるため、要件定義の出来栄えがシステムの品質を決定づけるのです。
では、なぜそれほどまでに要件定義を含む上流工程が重要になってくるのでしょうか？
その重要性については、以下の2点に要約されます。
大幅な手戻りを防ぐため
要件や仕様の不備や考慮もれは、発見が後工程になればなるほど修正コストが増大します。
よって、要件定義での不備や考慮もれをなくすことに注力することは、プロジェクト成功に直結します。
認識齟齬によるトラブルを防ぐため
「何のために」「誰が」「どのように」使うのかを明確にしないままシステム開発を進めてしまうと、顧客の要求を満たすことができないうえ、場合によってはクレームやトラブルにまで発展してしまう恐れがあります。
よって、要件定義で顧客の要求を十分に引き出し、要件を適切に決めて顧客と合意し、認識齟齬をなくすことが、なにより重要なこととなります。
COFFEE BREAK：考慮もれを防ぐ3つの視点
「繰り返し何回も確認をしているのに、なかなか考慮もれが防げない・・・」そのような場合は、以下の3つの視点で自問自答してみてください。
「本当にそうなのか？」と事象を疑う視点
「どうしてそうなるか？」と理由や要因を探る視点
「つまりどういうことか？」と整理・要約する視点
ついついその物事や事象自体に囚われてしまいがちになりますが、「ほんとに？」と事象を疑い、「どうして？」と理由や要因を探り、「つまり？」で整理・要約することで、物事の本質に迫ることができ、結果的に考慮もれを防ぐ手立てとなります。
ぜひ実践してみてください。
不具合修正コストからみた要件定義の重要性
さて、以下のグラフを見たことはありますか？
このグラフは、「1：10：100の法則」と呼ばれ、不具合の発見が遅れれば遅れるほど、プロジェクトのコストは高くなり、時間も浪費してしまうことを表しています。
このグラフからも、早期に不備や考慮もれ（＝不具合）を発見しておくことが大切であることがわかり、品質のよい要件定義を作成することの重要性が示されています。
システム開発における要件定義の位置づけ
システム開発では、進捗状況の把握や成果物を明確にするため、工程を分けて段階的にプロジェクトを進めていきます。
下図を利用して、ウォーターフォール型開発手法のＶ字モデルで要件定義の位置づけを示します。
各工程で、それぞれ目的に沿った成果物を作成していきますが、要件定義の工程で作成する成果物が要件定義書です。
なお、要件定義書のインプットとなるドキュメントは一つ前の工程で作成する要求定義書（要求仕様書ともいう）です。
要件定義の全体像
要件定義は、「業務要件」「機能要件」「非機能要件」で構成され、この3つの要件が揃うことで初めて「要件が網羅的に定義できた」ということになります。
まずは、要件定義の基本的な流れから見ていきます。
【目的・背景】
なぜ必要なのか？誰が何をしたいのか？ということを「WHY」「WHAT」「WHO」に着目して目的・背景を明確にしていきます。
【業務要件】
業務やサービスの「HOW」に着目し、「誰に対してどのように使われるか？」という問いが顧客の要求に対応できていることを確認します。
この部分を明らかにするために、システム化の対象となる業務を洗い出し、業務フローなどで分かりやすく表現していきます。
【機能要件、非機能要件】
業務要件をインプットとして、システム化に必要な機能や性能等を洗い出し、「どの部分をどのようにシステム化するか」といったシステムで実現するための具体的な手段を「機能要件」および「非機能要件」として定義していきます。
要件定義のプロセス
「よいプロセスからはよいプロダクトが生まれる」といわれるように、要件定義にも基本となるよいプロセスがあります。
詳細については、後ほど「要件定義の基本プロセス」の章で各ステップに分けて解説します。
要件定義のポイント
要件定義を成功させるうえで、必ず押さえておくべきポイントとなる部分があります。
この章ではそのポイントに焦点を当てて解説していきます。
要件定義のポイント① 背景の詳細化
背景については、詳しければ詳しいほど要件定義を進める上でのヒントとなりますので、できるだけ詳しく調査し、詳細化しておくことが望ましいです。
また、背景の調査と同時に環境分析を行っておくことも重要です。
業種業界を理解せず、要件を決めることはできないと心得ましょう。
要件定義のポイント② 目的の明確化
目的は、より具体的に、より明確にしておきましょう。
要件定義で迷ったとき、わからなくなったとき、悩んだときのブレない軸となります。
要件定義のポイント③ スコープの明確化
システム化の対象となるスコープ（範囲）が定まらなければ、システム開発というプロジェクトは定めようがありません。
しかしながら、スコープが曖昧なまま要件定義を進めてしまっているケースが意外と多いのが事実です。
スコープは要件定義を始める前に明確に決めること。この点も必ず押さえましょう。
要件定義のポイント④ ヒアリング
要件定義ではヒアリングスキルも重要になります。
ここでは幾つかの実践方法をご紹介します。
業界特有の業務フローに対しての理解を深める
先に説明しました①背景の詳細化で、顧客の業種業界の理解の重要性に触れましたが、ヒアリングにおいても同様のことが言えます。
業界によってはその業界特有の業務フローがありますので、それがわかっているとヒアリングがとてもスムーズに進みます。
業務フローがその業界特有のものであったとしても、顧客はそのように感じていないことが多いため、わざわざ口にしないことがあります。
その理解が不足していた場合は考慮のしようがなく、後々になって不具合として発覚するといった 事態に陥ります。
そのようなことにならないよう、事前に業界特有の業務フローに対する理解を深めたうえで、業務上の特性を丹念にヒアリングできるように準備しましょう。
インタビューをしてはいけない
ヒアリングをしているつもりで、実はインタビューをしてしまっている場合があります。
この場合、情報収集はできているかもしれませんが、真に必要とする情報が収集できていない可能性があります。
まずは、インタビューとヒアリングの違いから見ていきましょう。
要件定義では顧客から情報収集することが重要であるため、質問をする機会が多くなります。
その質問ではインタビューではなくヒアリングができるように、「目的に沿った質問になっているか」「目的を明らかできたか」といったことに注意を払いましょう。
オープン・クエスチョンとクローズド・クエスチョンを組み合わせる
ヒアリングでは多くの質問を投げかけますが、状況や聞きたい内容に合わせて質問方法を使い分けることができるようにもしましょう。
質問方法には以下の2つの方法があります。
5W2Hのフレームワークで抜けもれをチェックする
5W2Hはあらゆるビジネスシーンで使えるフレームワークですが、何かを解決をしたい場合の抜けもれチェックに使うことができます。
要件定義では、ヒアリングや要件を決める場面で用いることで、抜けもれの防止効果が見込めます。
例えば、要件を決める場面にて、
WHEN＝いつ使うのか？（タイミング）
WHO＝誰が使うのか？（使用者）
WHAT＝何に使うのか？（目的・用途）
WHERE＝どこで使うのか？（環境・状況）
WHY＝なぜ使うのか？（理由）
HOW＝どのように使うのか？（使い方）
HOW MANY＝どのくらい使うのか？（頻度・数量）
というように、5W2Hのフレームワークを活用して要件の抜けもれチェックを行うとよいです。
ちなみに使い方として、「WHAT（目的・用途）」「WHY（理由）」「WHO（使用者）」を確実に押さえてから、残りの「W」と「H」を考えるようにすると、より効果的です。
ヒアリングは最低でも2回は実施する
ヒアリングは最低でも、現状の姿（As-Is）を確認するヒアリングと、あるべき姿（To-Be）を導き出すヒアリングの2回は実施することです。
現状の姿（As-Is）とあるべき姿（To-Be）の確認を1回のヒアリングでまとめようとすると、現状（As-Is）の話とあるべき姿（To-Be）の話が、どのときの話であったかがわからなくなったり、必要な情報を聞きもらしてしまったりといったことが起こり得ますので、ヒアリングは必ず 現状の姿（As-Is）とあるべき姿（To-Be）に分けて行いましょう。
1回目のヒアリングで現状の姿（As-Is）を確認する
1回目は、現状の姿（As-Is）についてのヒアリングを実施します。
このヒアリングを行う目的は、現状の業務や課題の確認がメインとなります。
確認したのちに「現状の業務フロー（As-Is業務フロー）」と「課題一覧」を作成します。
2回目のヒアリングであるべき姿（To-Be）を確認する
現状（As-Is）の確認が終わったら、2回目ではあるべき姿（To-Be）についてのヒアリングを実施します。
このヒアリングを行う目的は、あるべき姿の業務と要求の確認がメインとなります。
確認したのちに「あるべき姿の業務フロー（To-Be業務フロー）」と「要求一覧」を作成します。
要件定義のポイント⑤ 間接的ステークホルダを見極める
ステークホルダ（利害関係者）として、プロジェクトに影響を与える対象を洗い出す際、直接的には関係しないステークホルダの見極めが重要になります。
そのステークホルダを間接的ステークホルダと呼んだりしますが、間接的であるが故、範囲が広く見極めが難しくなります。
間接的ステークホルダを見極めるポイントとしては、プロジェクトに与える影響範囲を広い視点で捉え、プロジェクトへの影響度合いを考慮することです。
また、直接的ステークホルダに関しても抜けもれがないか、注意深く確認を重ねることも重要です。
ステークホルダに抜けもれがあると要求の考慮もれが発生してしまいますので、ステークホルダの洗い出しと見極めについては、細心の注意を払って行いましょう。
要件定義のポイント⑥ 業務フローは目的に適したレベルで作成する
業務フローにはレベル感があります。業務フローを作成する時は、その作成目的や意図に応じてどのような粒度で業務フローを作成するか、といったレベル感を決める必要があります。
レベル0：最も粗いレベル。全体業務を俯瞰できるよう外部との相関も表現できるとよい。
レベル1：事業主が特定できるレベル。部署間の業務をフローで記載する。
レベル2：部署が特定できるレベル。業務担当者間の業務をフローで記載する。
レベル3：業務担当者が特定できるレベル。レベル2よりも更に詳細な作業（プロセス）を記載する。
レベル4：プロセスが特定できるレベル。各アクティビティ（詳細作業手順）を記載する
例えば、業務効率を目的に作成するのであれば、これまでムダとなっていたタスクや短縮できる作業などを洗い出す必要がありますので、詳細作業手順までを記述するレベル4の粒度まで掘り下げるといった具合になります。
要件定義のポイント⑦ 「要件」と「仕様」を確実に区別して整理する
まずは要件と仕様の違いから見ていきましょう。
例えば、家を建てることを例にすると、「2世帯なので玄関と水回りが2つ欲しい」といった要求を叶えるための間取りが「要件」で、コンセント数や棚の位置を決定する設計図面が「仕様」になります。
顧客からは、「これが要件で、これが仕様です」といったように整理された状態で情報が出てくるわけではありませんので、顧客から獲得した要求は、確実に「要件」と「仕様」とに区分して整理する必要があります。
要件定義のポイント⑧ 「業務要件」「機能要件」「非機能要件」のトレーサビリティを確保する
要件定義を構成する要素は、「業務要件」「機能要件」「非機能要件」の3つであり、 それぞれを明確に定義することが要件定義においてもっとも重要なことです。
そして、「業務要件」と「機能要件」、「業務要件」と「非機能要件」との間にはトレーサビリティが確保されていることが重要です。
もし、トレーサビリティが確保されていなければ、要件がもれているということになりますので、細心の注意を払いながら確実にひとつずつ確認しましょう。
要件定義のポイント⑨ 第三者でもわかるように記載する
要件定義書の読み手は顧客側であるため、専門用語や開発者しかわからない高度な内容になっていると読み手に正確に伝わりません。
よって、要件定義書は第三者でもわかるように記載方法を工夫する必要があります。
専門用語は使わない、箇条書きにする、図表を多く用いる、文章ではなくUMLでまとめるなどといった手法を用いてわかりやすく記載するよう心がけましょう。
まずはわかりやすくするための様々な方法の理解から始めましょう。
要件定義のポイント⑩ 顧客との合意形成を重要視する
要件定義書はシステム開発の根幹となる、システム開発でもっとも重要なドキュメントです。
要件定義で顧客と合意できていない部分があれば、その箇所からボタンの掛け違いが起こり、後々大きな手戻りとなるリスクを抱えた状態となります。
よって顧客との合意はもっとも注力すべき重要なポイントです。
また、「要求として抽出したが、機能要件の対象外となった機能」「要件の変更管理に関する方法」「要件定義の制約条件・前提条件」「要件定義では未決で先送りとなった申し送り事項」といった内容についても、顧客と認識を共有し合意をしておきましょう。
要件定義のポイント⑪ 変更を管理し、常に最新状態を維持する
要件定義作成後も、様々な理由で要件の変更や追加が発生します。また仕様の変更に伴い要件が変わるといったこともままあります。
例えば設計に変更があった場合、設計書への反映はもちろんのこと、要件定義にまで遡って変更を反映（修正）する必要があります。
また、変更を反映するだけではなく、変更を管理することも重要です。
変更管理を行うことで、変更の履歴を追うことができたり、変更の矛盾点に気づくことができたりします。
ここまで11の要件定義のポイントについて述べてきましたが、いかがでしたか？
2010年に情報処理推進機構（IPA）から公開された「超上流から攻めるIT化の原理原則17ヶ条」は、タイトルに原理原則が入っているだけあり、要件定義の初心者にも参考になる部分も多いため、この章の最後に紹介しておきます。
要件定義の基本プロセス
さて、ここからは要件定義の基本となるプロセスについて、順を追って解説していきます。
ステップ① 現状把握
まずは、業務内容、目標、課題、問題点など現状を把握したうえで、顧客の要求を精査していきます。
具体的には、以下のような事項をまとめていきます。
・どんな業務規則、制約事項があるのか？
・現行の業務およびデータの流れはどのようになっているのか？
・現行の業務にはどのような問題点があるのか？
・目標達成のためにどんな課題があるのか？
ステップ② ステークホルダの抽出
ステークホルダとして、対象となる業務やプロジェクトの始まりから終わりまでのあいだに利害関係が生じる人や組織をすべて洗い出します。
また、ステークホルダには直接的な関わりを持つ人や組織と、間接的に影響を受ける人や組織に分けることができ、それぞれを「直接的ステークホルダ」「間接的ステークホルダ」と呼びます。
具体的には、ビジネスプロセスに直接あるいは間接的に関与している人や組織をすべて洗い出し、ビジネスプロセスに依存したステークホルダを抽出していきます。
ステークホルダの抽出や取り纏めについては様々な方法がありますが、ここでは代表例を２つあげておきます。
ステークホルダマトリクス
ステークホルダマトリクスとは、事業やプロジェクトを取り巻く人や組織が事業やプロジェクトに与える重要度と影響度を整理するための二軸図です。
オニオンモデル
オニオンモデルとは、ステークホルダを階層レベルで捉え、そのレベル間の関係を説明するための概念モデルです。
REBOKの要求獲得技術によるステークホルダ識別を行うための技法としても知られています。
この場合、中心にはソフトウェアを置いて中心から外側に向けて影響を与えるステークホルダを可視化していきます。
ステップ③ 要件ヒアリング
ヒアリングでは「この業務に関わる方はどの部署ですか？」「この業務の処理はどのように進んでいきますか？」というように、第三者の視点で過不足がないかを確認していきます。
ヒアリング後は、5W2Hの視点で「想像」⇔「箇条書き（まとめ）」のループを繰り返して要件を整理していきます。
ステップ④ 要件と仕様の整理
前章で「要件」と「仕様」について、「要件」は、要求を実現するための条件で、家を建てる場合の「間取り」、そして「仕様」は、要件を満たすための詳細な条件で、家を建てる場合の「設計図面」と説明しました。
上記のことから、「要件」を詳細化したものが「仕様」であり、「仕様」には設計の観点が含まれていることがわかります。
この関係を認識せずに「要件」なのに「仕様」として識別したり、逆に「仕様」なのに「要件」で括ってしまったりする場合がありますので、「要件」と「仕様」の整理は注意深く行う必要があります。
ステップ⑤ 要件の細分化
要件を細分化するとは、「要件」と「仕様」を構造的に捉えることです。
先ほど「要件」と「仕様」の整理について述べましたが、構造として「仕様」に対する「要件」が不足している、あるいは、「要件」として捉えていたものが実は「要件」ではなく「仕様」で、その「要件」に対する「仕様」が考慮できていないといったことがあり、要件の細分化についても注意深く行う必要があります。
「要件」と「仕様」を区別してそれぞれを適切に構造化する、仕様に対する要件を考慮する、要件に対する仕様を考慮する、といった非常に重要かつ綿密な作業となりますので、時間をかけてでも確実に行うようにしましょう。
ステップ⑥ 業務要件の定義
開発するシステムは「誰がどのように使うか」といった顧客の要求を新業務として示す必要があります。その新業務の内容や運用方法をまとめ、業務要件として整理していきます。
業務要件を整理する方法として、システム化の対象となる業務を洗い出し、業務フローを作図して分かりやすくまとめて業務一覧に落とし込むまでの一連の作業を行います。
業務要件の定義は、システム化の目的に対する根拠となるように業務要件を整理してまとめることです。
上記の4つのポイントに従って、確実に業務要件を押さえるようにしましょう。
ステップ⑦ 機能要件の定義
先に定義した業務要件から、人の手で実施する業務と、システム化の対象となる業務をそれぞれ定義したあと、機能間のデータの流れを明確にしていきます。
機能要件では以下のポイントを押さえるようにしましょう。
・どの業務をシステム化するのか明確にする
・各機能の役割、データの流れを明確にする
・システムが処理を行うデータ同士の関連性について図式化 する
ステップ⑧ 非機能要件の定義
先に定義した業務要件から、機能要件以外の要件を非機能要件として整理していきます。
このときにもれなく整理できるようIPA発行の「非機能要求グレード」を活用するとよいでしょう。
参考URL：https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
次に、「どのような内容を非機能要件として定義しまとめていけばよいか」について、具体例をあげておきますので、参考にしてみてください。
次に、もし「非機能要件に抜けもれがあった場合にはどのようなリスクがあるのか」についても記しておきます。
・「可用性」の抜けもれ・・・頻繁に停止するなど、使いたいときに使えないリスク
・「性能・拡張性」の抜けもれ・・・レスポンスの遅延や、リソースが増強できないリスク
・「運用・保守性」の抜けもれ・・・システム運用や保守に対して、多大な時間を要するリスク
・「移行性の抜けもれ」・・・移行が思い通りにいかず、想定外の時間を要するリスク
・「セキュリティの抜けもれ」・・・ウイルスに感染するなど、機密情報が漏洩するリスク
・「システム・エコロジーの抜けもれ」・・・法令違反となり、課徴金の支払いが発生するリスク
ステップ⑨ 要件の調整
「業務要件」「機能要件」「非機能要件」のそれぞれの定義が終われば、最後に各要件の調整を行います。
この際、対応優先度に沿って要件を調整しますが、その優先度は開発プロジェクトの「コスト」「スケジュール」「技術」といった制約 、目的やビジネス価値によるインパクトを考慮した要件の「緊急度」「重要度」といった視点から、事前に指標を決めておくとスムーズに事が進みます。
申し送り事項の作成
要件を調整する際、要件定義内では結論が出ないといったことが起こる場合があります。
その際は「申し送り事項」として確定しなかった事項をとりまとめて、以降の工程に影響が出ないように解決する期限と担当者を設定して管理するようにしましょう。
業務要件を定義する
システム化する目的は、「業務効率化」もしくは「業務改善」にほぼ集約されます。
業務要件は目的を達成するための要件でなければならないため、常に目的に立ち返りながら一つずつ定義していきます。
業務要件の定義においては、まず業務フローをインプットに「業務一覧」を作成します。
「業務一覧」とは、業務を体系的に大分類・中分類・小分類という形式で上位から下位までを一覧にまとめたものです
。詳しくは下図をご参照ください。
業務とは、ビジネス（事業）を成り立たせるためのパーツのようなもので、「業務一覧」はビジネス（事業）を成り立たせるために必要なパーツを全て揃えることと捉えることができます。
この時に必要なパーツとして、イレギュラーパターンや想定し得るシチュエーションにまで幅を広げて揃えるといった考え方ができれば、考慮もれが少なくなるのと同時に、顧客にとって価値ある提案が可能となります。
機能要件を定義する
「機能要件」とは、業務要件を実現するために必要なシステム化対象の機能に関する要件です。
業務要件を定義したのちに、「この業務を実現するためにシステムとして何ができなければならないか」をシステム要件として定義するのですが、このうちシステムが備えるべき機能について定めたものを「機能要件」といいます。
「機能要件」には、「システム化により何が実現できるのか」を記載していきますが、具体的には、データおよびシステムの種類・構造、システムの処理内容などが該当します。
この際、単に要求を要件化するのではなく、「実現可能性が低い」、あるいは「ビジネス上のインパクトが弱い」といった機能要求を、よりビジネス価値を高める代替案を想定しつつ、新たな機能要件として定義できるように取り組みます。このような対応ができるか否かが要件定義の胆になります。
非機能要件を定義する
非機能要件とは、業務要件を実現するために必要となるシステム化対象の機能以外の要件です。
例えば、エンタープライズ系のシステムであれば、情報セキュリティやBCP（事業継続計画）の実現のための可用性や信頼性に重きをおいて非機能要件を定義し、Ｗｅｂサービス系のシステムであれば、使いやすさやわかりやすさ（ユーザビリティ）、応答時間などの性能面を重要視した非機能要件を定義するといった具合になります。
非機能要件を定義するタイミングは、業務要件と機能要件の定義が終わってからになります。
なぜなら非機能要件を考える際、業務要件はもちろんのこと機能要件もインプットとなるため、実装する機能により非機能要件が変わるからです。
非機能要件の定義において気をつけたいことは、顧客からは非機能の要求はなかなか出てこないという点です。
非機能要件は、開発側から顧客に対して提案することを前提として進めましょう。
要件定義の成果物
要件定義では成果物として、基本的に以下に示す項目やドキュメント（別紙）を作成します。但し、プロジェクトの対象や特性によって必要とするドキュメントは変わりますので、その都度必要なものを選択しましょう。
１．業務要件
１－１．システム化の狙い（目的・背景）
１－２．用語定義
１－３．ステークホルダ一覧
１－４．ステークホルダ関連図
１－５．ビジネスプロセス関連図
１－６．業務一覧
１－７．Aｓ－Is業務フロー
１－８．課題一覧
１－９．To-Be業務フロー
１－１０．要求一覧
１－１１．システム化業務フロー
１－１２．遵法性
２．機能要件
２－１．機能に関する事項
２－１－１．機能一覧
２－２．画面に関する事項
２－２－１．画面一覧
２－２－２．画面概要
２－２－３．画面出力イメージ
２－２－４．画面遷移図
２－３．帳票に関する事項
２－３－１．帳票一覧
２－３－２．帳票概要
２－３－３．帳票出力イメージ
２－４．情報・データに関する事項
２－４－１．情報・データ一覧
２－４－２．情報データ処理要件
２－４－３．データ構造
２－５．インターフェースに関する事項
２－５－１．インターフェース一覧
２－５－２．インターフェース定義
高品質な要件定義を作成するための実践テク
ここからは、より高品質な要件定義を作成するためのテクニック的な要素をお伝えします。個人のスキルアップやチームビルディングのベースとしてお役立ていただければ幸いです。
背景と目的は具体的であればあるほどよい
背景と目的からシステム開発で必要なことが導き出しますので、背景と目的は具体的であればあるほどよい、ということになります。
背景と目的が具体的であることにより、システムを活用するシチュエーションを明確に想定することができ、より顧客に喜ばれる要件を定義できることにつながります。
常にシステム化の目的に立ち返って考える
要件定義を進めていくなかで、議論が錯綜したり、要件の優先順位に迷ったりすることがあります。
そのような場合は常にシステム化の目的に立ち返って考えなおすことが重要です。
USDMのフレームワークを活用する
要求仕様を定義するための使用するフレームワークにUSDM（Universal Specification Describing Manner）があるのですが、このフレームワークはもちろん要件定義でも活用することが可能です。
ここではUSDMの特徴から、要件定義での活用方法をお伝えします。
・「業務」と「機能」を階層構造で捉える
要求を「業務」、仕様を「機能」と置き換えて考えることにより、「業務」と「機能」および「非機能」を階層構造的に捉えることが可能となります。
階層構造で捉えることで、「機能」や「非機能」の考慮もれや「業務」との不整合をカバーします。
・「理由」を付けることにより要求を支える
要求に「理由」を付けることによる以下のメリットを活用します。
・「理由」があることで、要求（＝業務）の意味が理解しやすくなる
・「理由」を書くことで、その要求（＝業務）に根拠がないことに気づくことができる
・「理由」があることによって、仕様（＝機能（非機能））が引き出しやすくなる
以上のことより、要件定義でUSDMの考え方を取り入れることにより、業務と機能の紐づけの抜けもれの防止につながるとともに、ステークホルダの認識齟齬が起きにくくなるといった効果も期待できます。
業務要件と機能要件・非機能要件のトレーサビリティを確保する
それぞれ要件として定義した「業務要件」と「機能要件」、「業務要件」と「非機能要件」のあいだでは、トレーサビリティを確保し考慮もれがない状態にすることが重要です。
特に「業務要件」から「機能要件」の抽出は難易度が高く、集中してより注意深く見ていく必要があります。
また、「非機能要件」は考慮もれが発生しやすいため、その点にも注意が必要です。
また、「業務要件」と「機能要件」、「業務要件」と「非機能要件」の関係性は「１：１」といった単純なものではなく、「N：N」となるため、何度も見直しをすることをおすすめします。
ちなみに、要求と要件のフェーズ間におけるトレーサビリティの確保もとても重要ですので、この点も押さえておきましょう。
ソフトウェア品質特性（ISO/IEC25010）も活用する
非機能要件の抽出においては、先に「非機能要求グレード」の活用をご紹介しましたが、ソフトウェア品質特性に焦点を当てているISO/IEC25010を参考にすることも有効な手段となります。
ISO/IEC25010にはソフトウェア品質特性として、8つの品質特性と31の品質副特性を定義していますが、品質特性のなかの「機能適合性」以外が非機能要件に該当します。
非機能要求グレードと合わせてISO/IEC25010を活用することで、より網羅的に非機能要件を検討することができます。
UMLを活用する
文章による記述はどうしても曖昧さや誤認識が排除できず、正しく伝わらない可能性があります。
よって、出来るかぎり図や表を使用することが望ましいのです。
中でもUMLは全世界共通ですので、積極的なＵＭＬの活用をおすすめします。
UMLとは
UMLとはUnified Modeling Languageの略で、日本語では「統一モデリング言語」と呼ばれています。
システムの構造や振る舞いに対して図を用いることにより視覚的に把握できるようになり、効果的なコミュニケーションの手法として活用されています。
2005年にISOで国際標準化されて以降、ソフトウェア業界では国際的な業界標準のグラフィカル表記法として広く普及しています。
機能要件は「MUST」「WANT」「NEVER」で整理する
機能要件を決める段階においては、「MUST」「WANT」「NEVER」の視点を用いると、要件の整理や優先順付けをする際にとても効果的です。
なかでも「NEVER」の視点は抜けやすいため、考慮もれがないように注意しましょう。
「MUST」＝できなければならない
「WANT」＝あったらいいな
「NEVER」＝あってはならない
業務の「時間」「頻度」「量」を確実に押さえる
業務の中でも「時間」「頻度」「量」に関連する情報は、システム化のポイントとなる重要なポイントとなります。
「時間がかかっている業務」「頻度の多い業務」「処理量の多い業務」を見つけ出すことにより、システム化による恩恵が受けやすくなりますので、このポイントは必ず押さえましょう。
「正常処理」だけではなく「例外処理」も考慮する
業務においては正常処理にばかり目が行き、例外処理が考慮できていな場合が多いため、注意が必要でしょう。
また、例外処理のほか特殊処理もある場合がありますので、その点も同じく注意して考慮もれとならないようにしましょう。
数年先のことを想定する
ソフトウェア自体に経年劣化はありませんが、賞味期限なるものはソフトウェアにも存在します。
それは周辺環境の変化によるもので、例えば、業務の変更や法律の改正などにより、そのままではシステムが使えなくなる場合が起こり得ます。
そのため、先の読みにくい時代ではありますが、最低でも3年先、できれば5年先のことまでを想定した要件を定義できるようにすることが望ましいのです。
顧客との合意形成においては読み合わせを行う
要件定義は、「これからどういったシステムを作るかについて」を定めた、いわば顧客との合意書という側面があります。
よって合意形成を確実なものにするためにも、顧客と一緒に読み合わせを行うことが、顧客との合意においてもっとも確実な方法となります。
レビューを疎かにしない
要件定義を始めとする上流工程の品質は、エンジニアのスキルとともにレビューの質にも大きく左右されます。ここではレビューの重要性について確認します。
レビューの重要性
要件定義を含む上流工程においては、レビューによる不具合摘出比率の向上が重要なこととなります。
レビューでの指摘率が高いプロジェクトでは大きな欠陥を出しているケースはないといった報告もあるぐらいで、上流工程のなかでも特に要件定義工程での効果的なレビューは、とても重要なことであると認識しましょう。
レビュープロセスの重要性
効率的かつ効果的なレビューを行えるようにするためには、レビューにルールを設けて、そのルール通りに行えるよう、レビュープロセスを整備することがポイントです。
レビュープロセスである「レビュー戦略」→「レビュー計画」→「レビュー実施」→「レビュー結果分析」→「レビュー改善」・・・の各プロセスにおいて定義を行うこと、またレビュープロセスに従ってＰＤＣＡサイクルを回すことにより、レビューの質および効率の改善が可能となります。
レビューアの重要性
レビューにおいては、レビューアの適切性についても考慮したいところです。
誰がレビューアを担当するかでレビューの指摘件数やその内容に雲泥の差が出ますので、レビューアの適切な選任についても疎かにしないようにしましょう。
レビュー観点の重要性
レビュー観点については、レビューアの適切な選任とともに、レビューの質を大きく左右する重要なポイントとなります。
以下に要件定義におけるレビュー観点の例をあげましたので、参考にしてください。
さいごに
要件定義は、以下の5つの特性を備えておくべきといわれます。
・合目的性…システムの目的が明らかであり、すべての要件はその目的に適っていること
・網羅性…システムの目的に必要な要件がもれなく重複なく示されていること
・整合性…各要件が他の要件と整合したものになっていること
・理解性…全ての要件がわかりやすく表現されていること
・追跡可能性…各要件の起源が明確であり、かつ各要件が後工程で参照しやすいよう容易に識別できるように示されていること
つまり、定義された要件が、もれなく、重複なく、各々の要件が整合しており、かつ分かりやすく表現されているもの。それが品質のよい要件定義の条件といえます。
要件定義工程においては、なかなか明確な成果物を定めにくく、例え成果物を定めることができたとしても、その品質を検証することが難しく時間的な制約もあるため、実際には要件定義が中途半端な形で終わることもしばしば起こります。
その結果、下流工程（テスト工程）になってから、さまざまな不備や不具合が明るみとなり、大幅な手戻りによってプロジェクトのQCDバランスが大きく崩れ、結果的にプロジェクトは失敗の道を突き進んでいきます。
要件定義は難易度が高く、知識と経験の両輪がないことにはなかなかうまくいかないのですが、まずは要件定義についての理解を深めることが肝要です。
そして、理解したことを実際の要件定義で一つひとつ試してみることで、経験を積み重ねていっていただければと思います。
最後に、コンサルタントに要件定義を代行してもらう、支援してもらうという方法もご紹介させていただきます。
コンサルタント利用は効率面でのメリットだけでなく、教授したナレッジは成功法則として継承していけるため、企業の資産となります。
依頼には費用が発生しますが、長い目で見ると費用対効果が高いので、できるだけ早い段階で導入を検討されることをおすすめいたします。
弊社、IT品質コンサルタント株式会社QualityCubeはご相談、お見積り無料です。
お気軽にお問い合わせください。
メルマガ登録
