汎用大型機における旧来の開発手法では、
予想外の仕様変更や要件定義の欠落による
スケジュールの遅延、及び開発費が膨れ上がることが多く
開発当事者にとっては、
いわば常識化してしまっていることにより
誰も疑問をさしはさむことなく「仕方が無い」で
済ましてきたものである。
しかし、要件定義手法の新しい考え方の取り入れや、
要件定義を行った人員の有効活用など、
今までの常識を変え、開発手法の変革、
要員活用の改善をすることによって
今まで開発現場で当然のように起こっていた
遅延や開発費高騰を抑え効率的に開発を進めることが
出来ると考えられる。
思わぬ仕様の変更などによる開発スケジュールの遅延は、
開発工程に入ってから具体化する事が多い。
仕様の変更による設計見直し、手戻りの発生、
スケジュールの遅延、またそれらをカバーする為の
要員増強とその結果として発生する開発費の増加など
遅延の要因となりうる作業は殆どの場合、
開発工程で背負うことになり、その問題解決に当たっては、
多大な労力を必要とされる為、
開発当事者の負担も相応に大きくなり
無理な残業や、モチベーションの低下をも招く。
それを繰り返すと、はては相次ぐ離職者の発生と
その補充などで、どんどんと悪循環に陥ってゆくのである。
その先に待っているのは「失敗」であり、
多くの場合それらは見かけ上は「成功」として見られる様に
取り繕われるのだが、その「負の遺産」は
しっかりとシステムの中で生き続け、
ややもすると、ある日突然バグとなって表出し、
とんでもないしっぺ返しを受けたりもする。
多額の開発費をかけたものの相次ぐ不具合により、
現場は荒廃し、優秀な人材は失われ
表面上は何とか取り繕いながら負の遺産を抱えたまま
動いているシステムというのが無数に存在しているのだ。
そういった経緯で生まれてきたシステムは
何時暴発するかもしれない爆弾をかかえているのと
同じ状態で運用されているのが実態だ。
要件定義の出来いかんで、
その後の開発の成否は決まって来る。
どんなに優秀なＳＥやプログラマーが揃っていても
要件定義がきちんと出来ていなければ
開発現場は泥沼と化す。
それでは、いかにして開発を成功に導くことの出来る
要件定義を行うべきかということについて述べていこう。
システム開発の工程としては、
要件定義 ⇒ 基本設計 ⇒ 詳細設計
⇒ プログラム製造 ⇒ テスト
となり、要件定義は開発への最初の入り口となる。
それだけにその内容、成果いかんによって
後工程に及ぼす影響は決して小さくは無い。
要件定義とはシステムを形作る基本要件を決定づける
工程ではあるが、そればかりではない。
最終的にはシステムの使い勝手や性能までをも左右する
システム開発においては決して疎かにはできない
とても重要でデリケートな工程であることを
意識しなければならない。
