内部設計の目的

「内部設計」…すなわち基本設計もほぼ終わりに近づき、機能設計を始めた頃でしょうか。こうなってくるとシステム開発も佳境に入ったといえます。私に言わせるなら、「ソフトウェア品質」の大半がすでに決した頃…と考えているかもしれません。

さて。

ここから作成する「内部設計書（俗称）」は、システムが外部設計書の内容を確実に満たすため、また品質の安定したプログラムを製造するための設計書という位置づけです。

内部設計では、外部設計あるいは外部設計書を基にプログラムの内部データを決定するなどシステムの具体的な実現方法を定義します。

たとえば、オブジェクト指向の場合はクラスの構造や組み合わせとその機能を決定し、システムやサブシステムをパッケージやモジュールに分解します。

そして、外部仕様を満たすようにモジュールの動作を定義します。

　「外部設計書からプログラムは作れないのでしょうか」

そうですね…できるかできないかといえば、外部設計書からプログラムを製造することは可能です。実際にそういうプロジェクトはたくさんあります。ですが、それは「内部設計をしていない」というわけではなく、プログラミングの際に個々のエンジニアが頭の中で内部設計をしながらプログラミングしているにすぎません。ただ「内部設計」という名称の工程がないだけで、内部設計自体は、実は実施しているのです。

それにもかかわらず「限りなくプログラムに近い設計書」である内部設計書を作成する目的は次のとおりです。

①プログラム製造時のミスを防ぐために、早い段階から品質を担保する
②プログラマーのスキルによらず、品質が均一なプログラムを製造する
③複数の開発会社で1つのプログラムを製造する場合に、プログラムの結合を容易にする
④プログラムの再利用を促進する『部品化」を容易にする

ライフサイクル全体を見据えた品質を、お客さまに提供する気があれば原則として省くことはないでしょう。「省く」という選択をするのは、

　「お客さまのため」

ではなく、大抵の場合エンジニアがエンジニアの

　「面倒くさいから」

という理由で省いているにすぎません。大幅に作業工数は短縮できるかもしれませんが、そのせいで品質が劣化し、テスト工程以降で大炎上を起こしていては本末転倒です。

たとえば①の早い段階から品質を担保するというのは、言い換えると適切に定義された設計書を用意することがシステムの品質向上につながることを意味します。

また②はプログラマが適切に定義された設計書どおりにプログラミングをすれば、品質が一定のプログラムが出来上がる可能性が高くなることを意味します。外部設計当時から同じメンバーで製造し、リリース後何年もの間、ずっと同じ人が面倒を見ていくのであれば問題ないでしょう。頭の中に設計書のようなもの…が詰め込まれているので、それでも大丈夫なことも多いのです。

　「①と②は比較的わかりやすいのですが、③はよくわかりません」

という声も聞こえてきそうですが、システムが大規模になると製造すべきプログラムの量が多くなり、１社への発注では所定の期日までに完成できないこともあります。その場合は複数の会社にプログラム製造を発注し、最後に各社が製造したプログラムを組み合わせて1つのプログラムにします。

この時、各社が自己のルールでプログラムを製造していると、サブルーチンや関数の呼び出し方、データの引き渡し方、名前の付け方が一致せず、組み合わせが困難になる可能性が高くなります。

内部設計書でプログラムの構造、呼び出し方、データの引き渡し方、名前の付け方などを決めておけば、手戻りの回避につながります。単純に問題発生時の対策コストをかけずに済むため、品質を維持しながらスマートに進めるうえでとても楽になるのです。

最後に④の部品化ですが、たとえば自動車の設計では生産性を高めながらコストを抑えるために、各種の機能を部品として独立させて可能な限り共通の部品を使うと同時に使用する部品の種類を削減することを考えます。

このことは、プログラムの製造でも同じようなことがいえます。

内部設計の段階で汎用性のある処理はプログラム部品として独立させ、同じシステム内あるいは別のシステムとの間で部品を共通させることで、プログラムの製造にかかる手間を減らそうとする場合が多くあります。

ここまでは教科書的な説明ですが、みなさんのようなプロフェッショナルを目指す方は、この部品化についてもう少し詳しく知っておくことをおススメします。

プログラムの部品化には、プログラム製造の手間を削減するというメリットの裏に、部品として独立させるための作業に手間がかかり、製造のスピードを遅くするというデメリットがある点に注意してください。

汎用性が高く、様々な場面に適用できる部品ならば、多少手間をかけて部品化しても全体としてメリットがあるでしょう。

しかし、その部品を再利用する機会が少なかったり再利用しにくかったりすると、部品化のための作業が逆に製造のスピードを遅らせる原因となります。

プログラムの部品化ではメリットとデメリットの値踏みが重要です。

その部品化にどのようなメリット／デメリットがあるのか、どのくらいの手間がかかるのかを考えてから実行に移すよう心がけましょう。

ところで、内部設計は次に製造という工程があることから、製造で使用するプログラミング言語の特性に合わせた設計手法を使うのが一般的だと思います。

中でもよく使われるのが構造化設計です。

構造化設計は、ある機能はそれよりも小さな機能の集まりで作られると考えるアプローチです。その概念は難しいものではありません。

たとえば、請求書を発行するという機能は、

　①顧客に対する当月売上額を読み出す
　②売上額を合計する
　③合計額を請求書として印刷する

といったより小さな機能の組み合わせで実現します。さらに顧客に対する当月売上額を読み出すという機能を実現するためには、

　①ファイルを準備する
　②指定された顧客の売上額のうち当月分を抜き出す
　③ファイルの後始末をする

などのさらに小さな機能が必要となります。構造化設計の概念に基づいて設計することで、プログラムの全体像と詳細の両方を把握できるようになります。

最近はあまり聞かなくなりましたが、現代のプログラミング言語の多くは「構造化プログラミング」という考え方をどこかしらに必ず取り入れています。

現代のプログラミング言語の特性に合わせるという点で、内部設計で構造化設計の概念を用いることは理にかなっているといえます。

この構造化設計にもメリットとデメリットがあります。

メリットは先に説明したとおり、マクロの視点とミクロの視点を使い分けることができ、目的に応じたわかりやすい視点からシステムを展望できる点です。

一方デメリットとしては、設計が機能に注目して行われ、データに対する配慮が薄いため、データの重複や不整合を招くおそれがあるという点が挙げられます。これらのデメリットをカバーするために、構造化設計でもデータにも注目しながら設計する手法が多く用いられます。DOA（Data Oriented Approach / データ中心アプローチ）という考え方はそうして生まれたものですし、この考え方自体、現在でも有用とはいえかなり古くからある考え方なのでいまさら説明するまでもないかも知れません。

またオブジェクト指向言語が使われる現場も多く、設計もオブジェクト指向設計で行われる傾向があります（あまりきちんとオブジェクト指向を使いこなせているエンジニアを見かけませんが…）。

構造化設計ではデータと処理を分けて考えますが、オブジェクト指向設計ではデータと処理をオブジェクトの中にカプセル化し、オブジェクト同士がメッセージを交換して処理を進めると考えます（OOA（Object Oriented Approach / オブジェクト中心アプローチ））。

考え方に違いはありますが、構造化設計とオブジェクト指向設計は相反するものではありません。構造化設計の考え方は、オブジェクト指向設計の奥底にも流れています。

なお、構造化設計／オブジェクト指向設計ともその手法を使っただけで勝手にきちんとしたシステムができるわけではありません。エンジニアがきちんと考えて設計しないと、「形はできたが、性能が出ない」といったようなシステム…なんてことになってしまう場合もあります。

実際、とある炎上プロジェクトに参加した中で、SQL文やINDEXを見直すだとかってよくありがちな方法では全く改善できず、プログラム構造…構成内容を見直して、性能を40倍も高めた例も過去にありました。