もし、あなたがITシステムで訴訟を起こされたら裁判に勝つ自信がありますか？
今回は、前回の「もし、ITシステムで訴訟を起こされたら」の続きです。
まず、ITシステムで訴訟に発展する内容として考えられるものの一番として挙げた
1）システム要件を満たさなかったから契約を解除したい。
ユーザーがお金を支払う気が無い。
について取り上げます。
今回の内容は、いつもにも増して真面目で固い（？）ので覚悟してください。
ユーザーが求める「システム要件」とは何を指すのかを考えます。
現在のシステム構築のガイドラインとなっている、共通フレームワーク2007（※）の開発プロセス1.6.2に
※解説 http://www.atmarkit.co.jp/aig/04biz/slcpjcf.html
システム要件定義について以下のように書かれています。
*------------------------------------------------------*
業務全体に対して定義された利害関係の要件のうち、
システムに関する部分について技術的に
実現可能であるかを検証し、システム設計が可能な技術要件に
変換することである。
*------------------------------------------------------*
また、このようにも書かれています。
*------------------------------------------------------*
開発者が契約に従って、実施または支援する
*------------------------------------------------------*
どういった要件を記述するかということも書かれていますが、一番注目したい個所はそのあとです。
*------------------------------------------------------*
1.6.2.2 システム要件の評価
次の基準を考慮して、システム要件を評価する。
評価結果は文書化する。
(a)取得ニーズへの追跡可能性
(b)取得ニーズとの一貫性
(c)テスト計画性
(d)システム方式設計の実現可能性
(e)運用及び保守の実現可能性
*------------------------------------------------------*
つまり、システム要件については、
●利用・運用・保守を含めて示す。
●ユーザーが期待する効果を技術的に実現できるかどうかの根拠と可能性を示す必要がある。
●ニーズを実現したかどうかの評価方法を前もって決めておく。
こう書かれているのです。
これは、当たり前といえば当たり前のことです。
しかし、開発側は、
・要件定義の肝がこういったものだということをユーザーに提示していないのではないか？
・本来のシステム要件の目的をきちんと理解してユーザーに説明していないのではないか？
なぜなら、開発側には数多くの「本当のことが言い難い」理由があるからなのです。
そこで、
・お決まりのドキュメント雛型に収めてごまかして通してしまうことが多いのではないか。
・言い難いと曖昧にしたことが、トラブルを引き起こすひとつの原因になっているのではないか。
と考えるのです。
開発側が考える「システム要件」とユーザー側が考える「システム要件」の違い、これを次回は考えてみたいと思います。
Vol.00183