【弐】「~と同じ」という要件はない。「~と同じにする」ための要件定義をする。【弐】「~と同じ」という要件はない。「~と同じにする」ための要件定義をする。12:00よく「いつもと同じ」というニュアンスで要望が出されることがありますが、は「いつも同じ」はいつも同じではありません。なにが「同じ」なのかをはっきりとさせるところがトラブル削減のポイントです。「いつもと同じ」はいつも同じではない「今と同じ」「前と同じ」、「他と同じ」、「いつもと同じ」、私たちが生活の中でよく使う便利な言葉です。私もよく床屋さんで使います。それでも春夏秋冬、「いつもと同じ出来上がり」は微妙に異なります。この言葉、厳密さを要求されるシステム開発の場でも頻繁に使われるのですが、使われた時、よほど気を付けないと、とんでもないトラブルの種となります。システムを作り直し、業務の効率を上げようなどというプロジェクトが行われた場合を考えて見ましょう。業務設計をしている時、「この部分は今と同じでよい」などという決め方をよくします。業務要件としてはある意味大変わかりやすいものなのですが、それを実現するためのシステム開発となると、「今と同じ」...でよいケースは希、ほとんどないと言ってよいでしょう。頼む方は、今と同じに使えればよい、とすることは、極めて明快な要件定義と思っているケースが多く、加えてどこか直さなくてはいけないのかもしれないが、同じでよいのだから簡単だろうと思うのが一般的です。今のを作った時の要件定義があるだろうし、今動いているものがあるのだからそれ以上に明快な明確でわかりやすい表現はないと確信しているわけです。思っている場合もあります。一般的には簡単だと思っていることが多いように思われます。作り直して、全く同じ機能のものを作るのは神技です。不可能と言ってよいでしょう。受ける方も、「同じでよい」と言われた時、あまり考えずに「同じでよい」を、要件として飲み込んでしまった人には、同じに動くように作るための要件定義が必要、などということは意識の外だと思います、結果、作りはじめてから、次々と、ここはどうしましょうということになります。同じにするために要件定義が山ほど発生することがある...などとは思いもよらない開発依頼者は、「同じでいいと言ったじゃない。そのくらい調べてよ」という態度になりがちです。同じにするために次々に沸いてくる、課題、難問に真剣に受け答えてくれないことさえおこるのです。これではシステム開発がうまく行きません。開発依頼側にはイライラと不信、開発受託側には赤字と徹夜が待ち構えています。※この続きは、会員の方のみお読みいただけます(登録無料)。会員登録(無料)ログインはこちら※この続きは、会員の方のみお読みいただけます(登録無料)。