多事想論articles

ソフトウェア設計 -はじめに-

(1/6)

 iTiDコンサルティングが実施した第2回開発力調査では、ソフトウェア設計について、成功プロジェクトと失敗プロジェクトに差があることが確認された。成功しているプロジェクトはどこが違うのだろうか。 以降では、まずソフトウェア開発における設計の問題について考察し、開発力調査において『ソフトウェア設計』の評点が高かった企業の具体事例を通して成功要因を読み解いていくことにする。

ソフトウェア設計の問題

 唐突だが、テレビ朝日で放送されている「大改造!!劇的ビフォーアフター」という番組をご存知だろうか?人気の番組だからご存知の方も多いと思うが、古く狭い問題を抱えた住宅をリフォームの達人が住人の希望や気持ちを汲み取りながらリフォームする様子を紹介していく番組である。

 そして番組で紹介される問題住宅は、もともと店舗だったものや、共同住宅を壁を壊してつなげただけの住宅や、倉庫に壁を作り住宅にしたものなど、視聴者誰もが大変だと感じるものばかりだ。 大変なことはよくわかるが、もともとの目的や当初の住人構成と異なる住宅に住もうとしているのだから無理があるのは仕方がないように思える。

外観は問題なく見えても内部に問題を抱えている←外観は問題なく見えても内部に問題を抱えている

 さて、これと同じ様な状況がソフトウェアの開発にもあてはまる。ソフトウェアは当初の目的(仕様)を満足させるために開発されるが、その後機能追加を繰り返したり、機能的に似ているソフトウェアに流用されたりしている。 開発コスト抑制と開発期間の短縮が期待できるので、機能追加や流用することは別に悪いことではなく一般的に実施されている。 ソフトウェアが提供する機能は機能追加で充実され洗練されていくようにさえ感じるが、実際にはソフトウェアの内部構造はその過程で複雑に入り組み歪な構造になっている。 一般にスパゲティといわれる状態にまで複雑に入り組んでくると、一部の機能を修正すると関係ない機能でバグがでるなど品質問題が起きやすく、品質保証するためにもぐらたたきのようにバグ修正とテストを繰り返す、効率の悪い開発に陥ってしまう。

資料ダウンロードはこちら