企業システム戦略 ◆運用試験で業務マニュアルを使用する意義は？
システムは、機械系と人間系が有機的に連動してこそ、相乗効果が得られる。人間系の部分に関して必要になるのが業務マニュアルである。運用試験は、この業務マニュアルに対する試験でもあり、利用者に対する実践的な教育の場でもある。
企業システム戦略
企業システム戦略 企業システム戦略 ◆仕様変更など追加発注での注意事項は？
運用試験において、実業務遂行や運用において不都合が発見された場合は、仕様変更をして追加発注となる。ここで、運用試験中に発見した処置事項を、その都度、発注するのは効率が悪い。できれば、運用試験が終了後に、まとめて発注するのがよい。
企業システム戦略 ◆運用試験に準備すべきテストデータは？
運用試験の目的は、システムに対する要件や要求仕様が、実際の業務において問題が無いかを、実業務に沿って検証することである。運用試験で準備するテストデータは、この目的に沿った準備して効率的に行うことが重要である。
企業システム戦略 ◆運用試験／実用展開に必要な体制、キーマンとは？
運用試験で決められた期間内に、実業務で発生する、さまざまなケースを想定し試験を実施するには、相当な労力を要する。試験スケジュールが、ズルズルと延長したり、あるいは、手を抜いてしまい、実用開始後に不具合が多発するということになる。そこでキーマンを巻き込みことが重要性となる。
システム開発 ◆第三者による監理、助言の重要性とは？
システム構築において、やはり専門知識においてユーザ企業は弱者である。例えば、ハードウェア能力にしても、業者から、レスポンスを確保するためには必要ですと言われれば、高価であるとは思いながらも購入するしかない。やはり、第三者による監理や助言が必要になる。
システム開発 ◆欠陥防止に向けた発注側の対策は？
欠陥防止のポイントは、業者に任せ切りにせず、主体性を持って適宜、チェックを入れることと、第三者の専門家による検査を実施するということ。
システム開発 ◆双方が譲らない場合に和解する方法とは？
欠陥と仕様変更は必ず発生する。欠陥の場合は、業者側に修繕義務や損害賠償責任が発生する。仕様変更の場合は、発注側に追加発注という費用負担が発生する。そこで、両者の過失を相殺するというのは、いかがだろう。
システム開発 ◆その要求仕様は常識？それとも非常識？
仕様書に書いていなくても、当然、機能として盛り込まれていなければならないと主張する根拠として、それが、常識的なものであるかどうかが争点となる場合もある。ところが、この常識というのが非常にあいまいであり、どこまでを常識というのかがはっきりしない。
システム開発 ◆仕様変更か欠陥か問題の切り分け方は？
検収で必ず争点となるのが、発注側が「欠陥」と主張するのに対し、業者側は、仕様に書いていなかったので「仕様変更」と反論されること。主張が通らなければ、是正の費用を負担することになるので、どちらも簡単には譲らない。問題の切り分けに対する考え方を説明する。
システム開発 ◆瑕疵とは？その対応方法は？
受入検査の結果、要求事項に対して正しく作業されていない点については「瑕疵」として、業者に是正を要求する。この場合の是正作業に要する費用は基本的にベンダの負担、すなわち無償となる。その為、業者としては、瑕疵であることを簡単には認めないことも少なくない。