今回のテーマは、シンプルで、美しい設計の追求である。ソフトはハードに比べ、一見変更が容易に見える面があり、絶えず変更追加がなされる。しかも長期にわたって使われるだけに、当初からしっかりした美しい設計がなされていないと修正に伴う事故が発生しやすくなり、保守費も増えてしまう。
 |
最近は短納期が増えてきたこともあり、基本設計に十分に時間をかけずに先を急ぎ、「まずいところは後から修正するしか仕方がない」と考える人が散見される。だが、これは大きな誤りである。たとえ時間がかかってでも、まずは徹底的に基本設計を行い、しっかり土台を固めてから先に進むという王道を歩まなければならない。
プログラム構造、基本となるデータベースやテーブルの構造、プログラム制御方式、サブシステム間インタフェース、マン－マシン・インタフェースの基本画面、基本的な操作方式などは最初に必死に考えておかないと、後で大変苦労することになる。最初の設計に時間をかけたほうが後での混乱も減り、かえって進捗もよくなる。
「Design twice, Code once」 である。
 |
共通の基準や仕掛けをプロジェクトの基本計画段階から策定し、全員がこの基準にのっとって整然とした美しい設計が進められるようにしたい。
まずドキュメントの作成基準としては、組織共通の既存基準を適用してもよいが、プロジェクトの特性に合わせたプロジェクト基準を制定したほうがよい場合もある。設計の共通基準としては、例えばテーブルやファイル、インタフェースに関する共通基準、画面表示、標準帳票出力、共通オペレーション/メッセージ/コメント、命名基準などがある。これらををあらかじめ決めて、全体としての美しさを追求したい。
これらの基準は一元管理し、変更発生時の手続き、全員への徹底方式を定めておく必要がある。さらに、プロジェクト全体として、プログラム・ライブラリを集中管理し、最新のプログラムが特定できる仕掛けを整備したい。
 |
よい設計とは、ハード、ソフトに限らず、シンプルで美しいことである。特にソフトは機能が多く、部分的変更や追加開発が続くので、後にシステムを担当する後輩や後継者が、苦労しなくても理解でき、改訂にも失敗しないように、最初の設計はすっきりした分かりやすいものにしておく必要がある。元のソフトが複雑で美しさに欠けると、障害対策などの際にもミスを誘発し、重大事故を招いてしまう。
そのため、設計者は常に美意識を持ち、何かすっきりしないものを感じたときには、別の考え方がないかを多角的に検討することが重要だ。改修の際も、その場しのぎの場当たり的対策を取っていると、だんだんとプログラムが読みにくくなり、修正ミスを起こしやすくなる。特に中枢部分の改修では、時間をかけてでも、美しく、論理が分かりやすい改修を目指すべきである。
 |
美しい設計の特性として、単純性、階層性、対称性、透過性、一様性、明証性、統一性、バランス性、などが挙げられる。だが、どんな場合でも誰でも指摘する特性は、単純性と階層性である。一見複雑なものが階層的に整理され得るかどうかで美しさが大きく変わってくる。
階層化によって機能の優先順位、概念の大小関係がはっきりする。仕様がよく整理され、漏れが少なくなり、誰もが理解しやすくなることは、多数のメンバーが参加するプロジェクトが混乱しないためにも極めて大事である。
かつて先輩から「システムがまとまるとは、全体が1枚の絵にまとまることだ」と聞いたことがある。巨大なシステムを1枚にまとめるためには、機能が階層化できなければ、とてもまとまらない。なんといっても、最上階層の1枚の図を使ってシステムの機能や構造を説明し、顧客や幹部にも全貌を理解してもらえるかどうかがプロジェクト成功の1つの鍵であろう。
複雑な仕様をそのまま受け入れるのはプロの仕事ではない。プロならば、与えられた仕様を階層的に整理し、階層ごとにすっきりした形に仕様をまとめてから詳細設計に臨むものである。
