東京高等裁判所 IT専門委員　細川義洋

システム化の範囲を定義するときに、業務の目的を実現するための「方針」に着目すると、合目的性の高いシステム作りができます。

ユーザーから要件をヒアリングするときには、単に業務プロセスを確認するだけでなく、オペレーターの振る舞いや属性に着目すると、思わぬ発見があるものです。

要件定義の無い開発の紛争は、双方の主観的な主張が入り乱れて泥仕合化することが多いようです。しかし双方が協力して要件さえ固めれば、仲直りも再開も可能です。

悪意の有る無しにかかわらず、ベンダーと仲が良過ぎるユーザーが要件を担当すると、ベンダーにとってのみ都合の良い要件や、業務知識不足による要件不備を招く危険があります。

システムの要件、設計、プログラムはお互いに複雑に関係し合っています。相互の関係を管理するトレーサビリティマトリクスを作成しないと、修正が発生した際に、その影響がどこまで出るか把握できず、トラブルを招くことになります。

インターネットを介したシステムの応答速度のように、外部ネットワークによって左右される性能を約束するのは困難です。しかし何も約束しないと、ユーザーに損害をもたらす危険があります。

システム開発では、要件の全てが要件定義工程の完了時点までに決まることはまれです。決まらない要件は未決事項とし、解決担当者や期限などを定めて継続的に管理することが大切です。

パッケージソフトの導入には、ベンダーのスキル不足や業務との不適合といった危険が常につきまといます。そうした問題に直面したとき、ユーザーとベンダーはお互いの状況や立場を積極的に共有し、垣根を超えて話し合うことが重要です。

システム化対象業務の基本的な機能を備え、設定とアドオンを行えば使用できるパッケージソフトウェアは、コストと品質面でとても有用です。しかし、自社の業務にフィットしないソフトを導入したことによる紛争も、数多く発生しています。

ITシステムの要件定義では、対象業務のフローや入出力を決める「業務要件」とシステムが持つべき機能を定める「機能要件」、システムの速度や容量、使い勝手やセキュリティなどを定義する「非機能要件」について、ユーザーとベンダで徹底的に議論することが大切です。

ITシステム開発で最も大切な「要件定義」。だが1度合意したはずの要件に、開発中に追加や変更を繰り返し行われてプロジェクトが混乱する例が後を絶たない。こんなときはどうすればよいのか、IT訴訟専門の美人弁護士「塔子」に聞いてみよう。

要件定義が固まっていない、途中で追加や変更が頻発して大混乱――開発プロジェクトで起こりがちなトラブル事例の対応法を、IT訴訟専門の美人弁護士「塔子」がビシビシと伝授します。