業務設計者がどういったわけだか知らないが、その場しのぎで考えたような要件定義を作成することがある。その歪さがどんな感じなのかといったら"1LDKのマンションにトイレが4つあるような"感覚である。常識的に考えて、トイレは1つで充分である。そのようなことが起こるかというと、業務設計者がトイレとキッチンを区別することができていないので起きる。業務に関する手続きの最小単位を見極められず、「キッチンがあったらついでにトイレもあるよね」という考えで要件定義を作成するのであろう。当然のように他の部屋にもトイレを付ける。まともでない要件がシステム開発に降りてくると、複雑なクラス設計になりプロジェクトに悪影響を与える。共通化を使わざるを得ない状況が増えるのだ。無理がない要件は、プログラミングの際に共通化を使う機会が減り、よりシンプルな設計に落ち着く気がしている。業務固有の実装箇所で共通化が発生する場合というのは2つ考えられる。1つはプログラマの腕がヘボくて共通化できないのに共通化してしまっている場合、もう一つは業務設計内に同じ意味を持った処理が分散している場合である。どちらもシステム開発における敗北を意味する。本来は業務特有の処理というのは共通化する必要はなく、それ自体が独自性を持つものである。業務固有箇所で共通化が発生することは問題視されなければいけない。月別アーカイブはてなブログをはじめよう!baito_mo_yamunaiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。