紛争勃発に備えよ!──受け入れ検査時のトラブル対策:企業システム戦略の基礎知識(10)(1/2 ページ) 受け入れ検査において、明らかに「欠陥」であると判定できる場合は問題ないが、発注側では欠陥だと思って指摘しても、業者からは「それは欠陥ではなく、仕様書に書いてなかったので仕様変更である」と反論されることが少なくない。これは、業務という抽象的なものを対象としているうえに、要求仕様が日本語特有のあいまいな表現で記述され、発注側の意図が業者に正しく伝わっていないことが要因である。 こうした“見解の相違”は、欠陥であれば業者が無償で是正することになり、仕様変更であれば発注側が追加費用を負担する──つまり両者の利害は対立しているので、容易に紛争へと発展する。そうなった場合に、できるだけ禍根を残さずに両者が納得できるような形で解決するには、どうすればよいか考えてみたい。 仕様変更か、欠陥か──それが
“常識的な判断”って何? 前編(「コレだけ準備すれば分散開発に失敗しない」)では、(遠隔)分散開発に携わる、アーキテクチャやチーム運営、設計手法に主な視点を当ててきました。後編ではむしろ、実装からリリースまでのより現場の中で起きていたことに焦点を当ててゆきます。この分散開発中に東京の元請けから発せられた言葉で非常に印象に残っているものがあります。興味深いと思われるので紹介します。プロジェクトの初期に画面設計書の記述をするに当たって、仕様の確認をしていたときに顧客から“そこは常識的な判断でお願いします”と仕様の不明確な部分に関して言葉を濁されてしまったことが何度かありました。 システムを作るうえで“常識的な判断”って何でしょうか? 複数のラジオボタンが並んでいてもある人は当然単一選択だと思い、また別の人は複数選択できるかもしれないと考えるでしょう。この企業間、個人間の“常識”という言葉の食い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く