要件定義プロセスの重要性につきまして

質問

「システムの欠陥のほとんどは、要件定義プロセスで埋め込まれている」と言われているのは
なぜでしょうか？
V字モデルでは要件定義でのバグの埋め込みはユーザ受入テストまで検出されないため、
システム開発の後半にバグが検出されると手戻りが大きくなるという問題は理解できますが、
「要件定義プロセスで"埋め込まれている"」と言われていることの理由がわかりません。
当然要件定義は開発の冒頭なのでイメージとしては理解できますが、具体的に教えて
ください。よろしくお願い致します。

回答No.4

noname#208507

『「システムの欠陥のほとんどは、～ 具体的に教えて ください。』

こう定義されたの要件に対して、少なくとも四つの回答があり、全て異なっている。
この中に「自分が欲しい回答と違う」と思うものがあれば、それが具体例である。

回答No.3

catpow

私は仕事がプログラマですが、自分が使うためのプログラムを作ることもあります。
軽く設計して作ってプログラムが動きはじめたとき、以下のようなことが起こります。

１）できあがったプログラムを動かした瞬間に「こういう仕様のほうが良かった！」と修正したくなる。
２）こんな仕様であるなら、さらに○○の機能があったほうが使いやすいと追加機能が欲しくなる。
３）プログラムを動かすことで、本来の目的に役立つ要件がやっと理解できてきて、ゼロからやり直したくなる。

つまり、利用者として一番わかっている自分自身が、自分の為に要件定義し、プログラミングしても、要件定義の変更が起こるのです。
まあ、これは「バグ」「システムの欠陥」という言い方にはならないと思いますが、「要件定義プロセスの問題」であることは確かでしょうね。
そして、こういう問題が発生するのを防ぐことは出来ないと思います。

なぜなら、システムを作って欲しいと要望する人も、システムを受注して作る人も、何が「正しい要件定義」であるか誰も知らないのですから。
ですので、最近は、「とりあえず素早く動くものを作って、それを見て、再設計・再開発のサイクルを回す」なんていうアジャイルな手法が増えているのだと思います。

もちろん、理想は、最後までゆるがない「要件定義」が最初からあるほうが、開発はスムーズに進むと思います。
だから「要件定義プロセスが重要」っていうのは、そのとおりであり、そこに誰も知らない”問題”が埋まっているなら、開発後半でそれが判明するのは、当然の成り行きですね。

回答No.2

yakuya5565

昔から、要件定義フェーズで要件一覧や、機能一覧を作っていく作業になりがちです。
結局、ユーザーが機能の中で何を求めているのか、本当に何がしたいのかをヒアリングできているつもりで、できていないのが原因の時があります。
そうなると、ユーザーテストや受入テストで、不具合として報告されたりするのです。

回答No.1

washi001

システムの利用者＝ユーザー、システム構築者＝メーカー　として回答します。
ちなみに私はメーカーです。

簡単に言うと、ユーザーは、受け入れテストの時に初めてそのシステムにさわって、「思っていたのと違う」という後だしじゃんけんをしてくるわけです。
Web画面でいうと、「このボタンを押したとき、こんな画面が出ないと困る」とか、「ここにリンクがないとあれが出来ない」とか、しょーもない事が大半ですが。
この差分が、「欠陥」とされてしまいます。

ユーザー受け入れテスト時のユーザーからの指摘を、「欠陥」とされないために、メーカーは必死に要件定義プロセスで要件定義書なるものを作成し、証拠として残そうとしますが、作りたいものを考える人（ユーザー）と、実際に作る人（メーカー）が違うので、そこに意思疎通の差分が生じて、最後まで残るわけです。

本当は、要件定義はユーザーが行うべきプロセスなのですが、実態は、ユーザーが要件定義書に何を書いたらよいのかわからないので、メーカーやコンサル会社が作成を代行し、要件定義書で合意を取る事が多いと思います。

V字モデル、といっても、ユーザーの要件定義は、その工程だけで終了するのではなく、後工程において出てくる成果物（画面やデモシステム、取扱説明書）などで、メーカーが随時、要件レベルを確認していくのが大事なのではないかと、私は思います。