考えのメモ書き

多くのシステム開発プロジェクトが失敗している。
成功しているプロジェクトは、全体の27%程度のようだ。
失敗の理由の半分は、要件定義による。
残りの半分は、開発管理だ。

昔のコンピュータは、
高価で普及していなかったのも理由だろうが、
利用目的が、
大量の人手作業のシステム化
だった。
今は、コンピュータも安価になり、
誰でもが利用していて、
企業の全ての業務エリアが対象になっている。
システム化のためには、詳細な定義が必要である。
コンピュータは機械なので、詳細に手足の動かし方を定義（プログラミング）しないと、
システムにならない。
しかし、業務/ビジネスでは、要件が中々決まらない。
ビジネスサイドの人は、
システム開発には時間がかかるというkとで、
ビジネスの内容も決まっていないうちに、システム開発の開始をしたがる。

これがシステム要件の決定が遅れる理由だ。

ビジネスサイドだけでなく、システムサイドにもまずさがある。
ユーザ（ビジネスサイド）がシステムへの”要求”を言っていると思っている。
ユーザの話しているのは、要求でなく、”要望”である。
要望は、要求ほど詳細化されてなく、
やってみたいな、こんなかなか、
程度の話だ。
これを、SE（システムサイド）は、そのままシステム要件としてまとめようとする。

システム要件は、要求よりも、もっと細かく、
保存するデータ総量がｘｘｘだから、ハードディスクは最低限でもｙｙｙが必要、
などとの機器、ソフトウェアの要件/仕様の決定である。

SEは、
ユーザ要望をユーザの要望として素直に聞取り、
ユーザと話をすめて、要求までに落とす必要がある。
このときには、システムとしての要件などは入れてはいけない。
純粋に、ユーザが希望する”要求”を明確にすることが必要。
そして、ユーザに”要求”は、これでいいのね、
という確認をする。

その後、要求に答えるためのシステム案を検討し、
ユーザの要求と合致するシステム案を完成させる。
このシステム案を実現するためのシステム要件をまとめたものが
要件定義書になる。

SIerと言われる全てのシステム開発企業では、
システム開発標準などを導入し、それに沿った開発を実施している。
しかし、要件定義では、
ユーザ要求を書き出すことから始まるべきなのに、
DFDなどのシステム分析から入っていく。
異常だ。
日本IBMで作り上げた、ADSGなどでも、
ユーザ要求の書き出しは、2,3ページしか書かれていない。
ADSG全体では、数百ページの標準なのに。

変だと思うのは、
・ユーザ要求を書き出すことを規定・推奨していない
・ユーザ要求の分析でなく、システム分析が主体になっている
ことだ

・・・これで何とかまとまるかな・・・