システム化要求と要件定義
システム化における要求とは、ユーザー（依頼主）がどの様なシステムを実現して欲しいのか、具体的にまとめたものです。要求定義とも言われます。
本来、システム化要求はユーザー（依頼主）から提出されるべきモノですが、
ほとんどの場合、合理的に整理されていないのが実情だと思われます。
要件定義では、この要求をふまえ、システムの実現可否や必要性や具体的な実現方法などを整理します。
そもそも、ユーザー（依頼主）からの要求が実現不可能な場合もあります。
要求を全て実現すると予算や納期を大幅に超過してしまう場合もあります。
要求自体が曖昧だったり、不整合な場合もあります。
ユーザー（依頼主）が示した要求は、必ずしも「真の要求」ではありません。
要件定義ではまず「要求」が本当に正しいのかから精査することになります。
システム化の目的や目標を軸として、曖昧な「要求」から精緻な「要件定義」をまとめていかなかればなりません。
「要件定義作業」では、最終的なシステムイメージをわかりやすくユーザー（依頼主）と共有する必要があります。
システム化イメージを作成して、業務フローに合わせて、一つ一つ確認するウォークスルーレビューを実施すると効果的です。
レビューの結果、懸念点や課題を整理し、改善案を盛り込んで何回かウォークスルーレビューを繰り返しておくと、開発側とユーザー（依頼主）とのイメージのギャップは少なくなります。
システム化イメージは実物に近いものが好ましいですが、コストと時間がかかるので、どのレベルまで作成するかは悩ましいところです。
また、実現可能性も事前に確認しておく必要があります。データ量やユーザー数が多くなると、パフォーマンスが劣化したり、ロジックが複雑になるとそもそも実現不可能だったりします。セキュリティ上問題や開発予算も考慮しなければなりません。ユーザー（依頼主）は全ての要求を満たす事を希望しますが、ほとんどの場合は全ての要求を完璧に実現することは予算上難しいと思います。どこまでを実現すると、当初予定していた目的や目標が実現できるのか、全体のバランスを踏まえ、予算の範囲でスコープ定義をする必要があります。要件定義は全ての要求を拾う作業では無く、不要な要求を切り落とす作業だと考える方が現実的です。ユーザー（依頼主）から示された、目的や目標を実現しつつ、無理無駄を排除しバランスの良い要件定義を行うよう心がけましょう。
システム化要求の曖昧さはどうして発生するのか
ユーザー（依頼主）からの「要求」は、明示的に伝えられるとは限りません。
ほかの要求から暗黙的に示されていたり、ほかの要求から派生したりする場合も多くあります。
要求の曖昧さはどのようにして発生するのでしょうか？
- ステークホルダーがよく考えないで要求を表明する
- そのときは正しいと思っても、よく検討してみるとよい要求ではなかった
- あるステークホルダーはよいと思っているが、会社全体で見るとよい要求ではなかった
- 要求の表明が曖昧で、的確に伝えられていなかった
- 複数の要求が矛盾してしまい、同時に実現することができない
- 実現の可能性が低く、とても具現化できない要求であった
そもそもユーザー（依頼主）は情報を整理して、要求を伝えてきているとは限りません。
ユーザー（依頼主）の要求を鵜呑みにすると、後で痛い目に遭います。
よって、要求≠要件である事を前提に要件定義をしていかないといけません。
近年の複雑化したビジネス要求が求められる時代においては、ステークホルダー自身も明確な要求のイメージを持ち切れていないことが多いのです。この明確でないステークホルダーの漠然とした要求を洗練させて、真の要求にしていくことが要件定義作業に求められます
要求から要件にしていく過程
要求から要件にしていく過程において以下の様な変遷を辿ります。
- 要求が出された（要求が整理されていない、定義されていない、矛盾もある、曖昧なものもある状態）
- 精緻化された（整理された、定義された、矛盾は解消される。要求間の整合性は未だ確認されていない、実現可能性も未だ確認されていない）
- 検証された（要求間の整合性は確認された、実現可能確も確認済み、業務との整合性も確認された、予算と費用対効果について未確認）
- 妥当性確認された（予算・費用対効果の妥当性が確認され、優先順位も決まる。スコープの最終確認がされていない）
- 承認された（スコープが確定、予算確定。承認済）
上記のように、要求を要件にしていく過程において色々な変遷を辿ります。
要件定義ではスコープをドキュメントにて明確に定義し、具体的な要件（どこまでの機能をどのように実現するか。機能概要）としてドキュメントにて明確に定義し、金額や納期と合わせて契約として取り交わす必要があります。
要件定義を曖昧なままに終わらせておくと、最終ゴールの合意が取れないまま、プロジェクトが進むため、後続のフェーズで揉めることになります。
要求の曖昧
要求の曖昧さは、定義したドキュメント上に現れてきます。
曖昧となる事象を参考までに以下に挙げておきます。
- 用語が曖昧
- 一つの用語が複数の意味で用いられている
- 異なる状況で同じ単語が用いられるときに、単語の意味が異なる
- 用語の指示範囲が曖昧
- 「その」や「この」など指示代名詞の指示範囲
- 「すべての」「などの」などの副詞の指示範囲
- 「～し」や「かつ」「あるいは」「しかし」「そして」「また」などの接続詞の指示範囲
- 「～のとき」や「～でないとき」など条件節の指示範囲
- 暗黙の前提によって解釈が変化する
- 適用分野の知識がある前提で説明が省略されている
- 難しい専門用語で表現されているが、記載の意味が理解できないので、妥当性を判断できない
- 組織内部では当たり前のイベントや業務の順番や相関関係が伝わっていない
- システム化対象の定義が曖昧
- 類型とその個体で同じ名称のモノが存在した場合どちらなのか明確で無い
- プロセスとプロダクトで同じ名称のモノが存在した場合どちらなのか明確で無い
- プロセスやデータの生存期間の曖昧で、永続的とするのか揮発的とするのかが明確で無い
- 要求間の重複や矛盾
- 要求の重複
- 要求間の矛盾
- 要求の必要条件が不明確
- 要求の制約条件が不明確
- 要求が未定状態
- 要求が複数の意味に解釈できる
- 要求の関係性の不明
- 関係の型の不整合
要件定義をミスると修正コストが大きくなる
システムにおける修正コストは、「要求定義」フェーズで修正すれば１の工数で済むものが、
「設計」フェーズに持ち越せば数倍に膨らみ、
「テスト」フェーズまで持ち越してしまえば、10倍程度まで膨らみ、
「運用」フェーズまで持ち越してしまえば、100倍まで膨らむといわれています。
要件定義が曖昧のまま進めていくと、数倍から100倍のリスクが発生すると考えられます。
要件定義の品質管理を含めてしっかりとやっていかないといけません。
意識しないと「要件定義」は曖昧になってしまいます。
顧客の要求は必ずしも正しくないことを理解しましょう。
Follow me!
コメント