ソフトウェア設計 －ソフトウェア設計の問題の背景－
ソフトウェア設計の問題の背景
歴史的にみるとソフトウェア設計はメカやエレキに比べて新しく、一昔前はほんの一部にだけ入っている程度だった。その頃は電気回路設計の一部といった扱いで、少人数で細々と開発を行い、ソフトウェアの規模も小さかった。しかし、徐々に規模は膨れ上がり、今では独立した組織になるほど大人数で、さらに国内外のソフトウェア会社を使い、何十万、何百万ステップものソフトウェアを開発するようにまでなっている。この変化は急激で、それまではソフトウェア開発言語をちょっとかじった程度の開発者が集まってとりあえず動くものを作っていた状況だったため、ソフトウェア規模が大きくなるにつれバグも増え品質問題が多発した。現在では、構造化設計等の手法導入でよりしっかりしたソフトウェア構造のソフトウェアが作られるようになり、またCMMI他のプロセス改善活動により品質に対する意識も高まってきてはいる。しかし、依然として機能・性能を達成すること、納期を守ることに最大の努力が払われ、既存ソフトウェアをベースに増築を繰り返しているため、徐々にソフトウェアの構造が崩れているのである。この問題を少し前ならソフトウェアを捨てて新規に作り直すことで解決できたが、ソフトウェアの規模が大きくなり作り直すためのコストと期間は、低コスト短納期の現在の厳しいビジネス環境にあっては許されなくなってきている。
スパゲティ状態を生み出す過程
構造化設計などの手法でしっかりした構造をもったソフトウェアを設計したにも関わらず、その後機能追加を繰り返す中でソフトウェア構造を維持できなくなるのは、開発者にも一因がある。開発者が望んでそうしているわけではないが、納期に追われる開発者にとっては目先の開発が最優先であり、将来の保守や機能追加を容易にするためにソフトウェア構造を維持しようという意識はあまり働かない。管理者も進捗と品質をチェックするだけである。委託会社についてはそうする理由もない。そのため、構造を維持するためのルールは無視され、手っ取り早く関数や変数が作られ、いつの間にかあってはならないところに依存関係ができるなどして構造が崩れていく。また開発者が交代していく中で、なぜ新しい関数や変数ができたのか、なぜ依存関係があるのか、大事な情報がもれ落ちていく。
スパゲティ状態になれば、複雑怪奇な構造を正しく設計ドキュメントに表すのは困難で、多くの場合設計ドキュメントも残っていない。この状態になるとソフトウェアの保守や機能追加には、長年このソフトウェアの開発にかかわった生き字引のような開発者が必要になってくる。属人化が進み組織を硬直させてしまい、組織と個人の両方にとって決して望ましい姿ではない。
開発者と話をすると、「見直したいんですけどね」とあきらめも混じった言葉が返ってくる。開発者自身は機能拡張や変更が容易で作業的にも品質的にもよいのでソフトウェア構造を維持したいと思っている。しかし、納期優先でソフトウェア構造は二の次なのである。
◆7つのキープロセスのインデックス
Follow us
