問題が発生する要因

では、これらのエンドユーザに不利益をもたらす問題はどうして起こるのでしょうか?
問題の発生パターンは状況により様々ですが、大きく分けて以下の4点が考えられます。

1.エンドユーザと開発者間のコミュニケーション不全。
2.開発者側の立場で行われる情報の隠蔽。
3.調査分析不足により発生する開発後半での大規模修正。
4.工期に間に合わす為の品質管理面への省力。

通常、開発はエンドユーザから大手のSIベンダーが受注し、下請けを雇い入れする、もしくは丸投げする形で行われます。
これは、SIベンダーにその時必要な技術力が無いか、または人材がいない・足りない等の状態で行われるのですが、窓口として最低限のSIベンダー社員を配置します。 この時、下請けの技術者がエンドユーザとの会議に出席できれば問題はありませんが、一般的には下請けの技術者はエンドユーザとのやり取りに参加できません。 もともと技術力の不足がある為に下請けを入れているのですから、このような状態において行われる会議で十全な要件定義が行われるのは難しいのです。

また、たとえSIベンダー責任者の能力が充分であっても、SIベンダー側にはSIベンダー側の都合があり、その提案は必ずしもエンドユーザの求めるものと完全に合致するとは限りません。
開発者側が「この部分は運用面で対応します。」といって開発から外すものが果たして本当に運用で対応せざるを得ないものなのか、また、運用のみで本当に問題なく対応できるのかを、エンドユーザの立場から検討してみる必要があります。

これらのコミュニケーション不足や開発側都合による必要機能の削除は、開発の後期になってシステムがエンドユーザの目に見える形になった際に、必要な機能が含まれていない等の問題となって表面化します。
そうなった場合、当然のことながら、エンドユーザとしては充分な機能が満たされていない為、クレームを挙げ、開発側に修正を依頼することになります。そして、こういった修正が様々な波紋を呼ぶことにつながっていきます。
このような場合の修正は往々にしてシステムの基本設計にまで遡る必要があり、その修正は根本的なシステムの再構築をすることにもなりかねません。 その場合、SIベンダーは、小手先の修正で誤魔化す場合と実際に修正を行う場合があります。 小手先の修正を行う事は、システムに歪みを生じさせ、後々問題を発生させる原因となります、また、実際に修正を行うとしてもむしろ問題の悪化を招きます。
なぜなら既に後期段階に入った開発では、納期が迫っているため、SIベンダーとしては納期に間に合わす為の無理な注文を下請けに強要するからです。 下請けの開発会社としては、客であるSIベンダーの要求は呑まざるを得ず、徹夜等をして対応していますが、これはプログラム品質の低下を招き、結果として不安定なシステムが出来上がります。
更に、このような状況では、徹夜作業をしても時間的に到底間に合わないため、エンドユーザのチェックがかかりにくい部分、例えばドキュメントやプログラム中のコメント(説明文)等を省略するなどして、とにかく納期にあわせようとします。 これらの努力をもってしても納期が延期され、エンドユーザの業務に影響を与えることも多々ありますが、次に述べる隠れた問題は更に深刻です。
火事場の騒ぎのような開発現場で作られた不安定なシステムは、納品後も多くのエラーを包含する可能性が高く、それらエラーの発生時にプログラムを修正しようにもドキュメントが実際と異なったり、存在しなかったり、通常含まれているべきプログラム中のコメントが無かったりするため、プログラムの修正はソース(プログラムそのもの)を解読するより他なく、エラー個所の発見は『砂浜で針を見つけるような作業』になります。

これらを防ぐ為にエンドユーザができることは無いのでしょうか?
あります。 それはエンドユーザ側がSIベンダーの都合に左右されない専門家の協力を得る事です。AIT Lab.はエンドユーザの側に立って、よりよいシステム開発をサポート致します。



ユーザを困らせる問題システム 安定したシステム構築の為の対処策