ITを統べるためのヒント

　今回は、「設計をするとはどういうことか」をテーマに議論を行う。このことはものづくり議論の出発点として欠かせない。しかし、これまでシステム開発において、設計の意味するところをきちんと議論をしてこなかったように思う。そこで、この議論を進めることで、システム開発における設計とは、ものづくり一般の設計と同じように考えられるのか、それとも、システムの設計は特殊で、一般のものづくりとは別物と言ってよいのかが見えてくる筈である。この議論は、日本のシステム開発を解剖する上で、避けては通れないと筆者が考えているテーマなので、ものづくり一般に関する議論がしばし続きますが、恐縮ながら読者諸氏には是非ともお付き合い願いたい。

人工物には設計が不可欠
　当たり前のことだが、システム開発が生み出す情報システムは自然に存在するものではなく、人間が生み出した“人工物（Artifact）”である。人工物を特徴づけるものは、デザイン、つまり、設計という人間の行為が介在しなければ生まれないということである。その際、設計者がどのような意図を持って設計を行ったか、そして、その結果、どのような構造が出来上がったのかが一番重要な情報である。この二つことを同時にさす言葉がアーキテクチャ（Architecture）である。アーキテクチャという言葉は、本来は建築や建築物を指す言葉であったが、その後、色々なものの設計に幅広く使われるようになった。日本語では、前者の設計者の方針や狙いを指す場合、「設計思想」や「設計意図」などと訳される。また、後者の設計行為の出力物を指す場合は、「設計構造様式」などと訳される。コンピュータに関連しては、コンピュータ・アーキテクチャというコンピュータのハードウェア構成を指す言葉として、また同時に、そのような構成に何故なったのかという設計意図を示す言葉としても広く使われてきたので、比較的馴染みのある言葉ではある。

アーキテクチャの定義
　そもそもアーキテクチャとは具体的に何をさすのだろうか。この点について、システム開発に限らず、ものづくり全般に共通する視点からの議論が有効と筆者は考えている。そのような観点で絶好のヒントを提供してくれるのが、東京大学大学院経済学研究科「ものづくり経営研究センター」で「統合型ものづくりシステム」の研究を行っている同センター長の藤本隆宏教授の数々の著作である。例えば、著書「日本のもの造り哲学」(注1)において、設計の最初のステップである基本設計に関して、次のように纏めている。

　『基本設計を通じて設計者によりつくり出される「機能要素と構成部品との対応関係（マッピング）」や「構成部品間のインターフェースのルール」に関する基本的な構想がアーキテクチャ。つまり、機能と構造のつなぎ方や、部品と部品のつなぎ方など設計要素の「つなぎ方」に関する基本的な「ものの考え方」がアーキテクチャ』であると。

　ここで藤本教授が言わんとすることは、第一に、どの部品でどのような機能が実現されるのかという機能とそれを実現する部品要素との間のマッピング関係を決めることである。そして、第二には、部品と部品がどのようにつながるのかを決めることだというのである。この二つを明らかにすることがアーキテクチャを決めること、つまり設計であり、そのような設計の意思を記述した文書の中身をアーキテクチャと称するのである。

　図8-1に示したように、基本設計は、機能の分割・整理を行う「機能設計」とその機能を実現するためのシステムの部品構造を導出する「構造設計」の二つを行い、その過程で、どの機能をどの部品が担い実現するかを決めていくものである。その時に、部品と部品の間の関係を明確にし、その結合ルールなどを記述することが求められる。アーキテクチャとは、設計作業の出力としての技術文書であり、そこに記述されている内容そのものでもある。

モジュラー型VSインテグラル（すり合わせ）型
　次にアーキテクチャには、どのようなタイプが存在し、どのような区分に分かれるのであろうか。藤本教授の前掲書によれば、図8-2に示したように二つの類型に分類可能だというのである。

①モジュラー（Modular）型：機能と部品の関係が限りなく1対1の関係にすっきりと整理でき、それぞれの部品が自己完結し、事前に作成した部品を組み合わせることで、全体として立派にシステムになるというもの。「組み合わせ型」とか「寄せ集め型」とも称される。代表的な例がパソコンで、演算機能はCPU（Central Processing Unit）、表示機能はディスプレイ、記憶機能はHDD（Hard Disk Drive）、そして印刷機能はプリンターという具合に、機能要素を実現する部品が明確に一つの部品に対応する。
②インテグラル（Integral：すり合わせ）型：機能要素とそれを実現する部品との関係が錯綜し、複数の部品が関係すると同時に、一つの部品が複数の機能に関係するような多対多の関係になっている状態がインテグラル型である。自動車が代表例で、例えば、燃費はエンジンだけではなく、その他の部品にも関係があるという具合に、一つの機能がほぼ一対一で特定の部品に対応するのではなく、多くの部品に関係するケースなのである。このような場合、多くの関連部品間の調整（すり合わせ）作業が不可欠になる。

クローズド型VSオープン型
　藤本教授の前掲書によれば、モジュラー型はさらに「クローズド型」と「オープン型」の二つの区別が可能であるという。「クローズド型」とは、モジュラー型の構成要素となる部品群の通用する範囲が、特定企業内部に限定される「社内共通部品」であるような場合を指す。一方、「オープン型」とは、その部品の流通範囲が、業界全般に及び、異なる会社で基本設計された「業界標準部品」を組み合わせることで、まともな製品を作ることができるケースである。図8-3に示したのは、この二つの区分を組み合わせて出来る３つの類型がアーキテクチャの基本タイプなのである。

①クローズド・インテグラル型：機能と部品の関係が多対多の関係で、当然ながら、それらにより作り出される部品の流通範囲は社内限定というケース。
②クローズド・モジュラー型：部品と機能との関係は一対一であるが、部品の流通範囲が社内限定であるもの。代表例として、汎用コンピュータ（いわゆるメインフレーム）。
③オープン・モジュラー型：部品がモジュラー型であり、しかも、業界インターフェースが決まっているために、各社が自由に製造した部品を組み合わせることで製品ができてしまうというタイプである。例えば、パソコンは明らかにこのケースであるが、それ以外に自転車が有名で、シャフトの形態や接続部分の業界標準ができているので、他社製のギアを付けても問題なく接続できる。

設計は機能設計と構造設計の二つで構成
　以上の議論をまとめてみよう。設計という行為は、作るべき人工物（我々の場合は、それが情報システムである）に要求される機能の分析を行い、求められる機能構造を明確にする機能設計と、さらに、求められた機能群を実現するために必要な部品群（システムではコンポーネントと呼ばれる）を設計する構造設計の二つが行われる必要があるということだ。そして、当然ながら、機能と部品の間の関係や、部品間のインターフェースなどを整合性のあるものにして、それを文書に残すのである。この設計という行為の有り様は、システム全体、それぞれのプログラム、あるいはデータモデル、さらには、システム基盤のプラットフォームなどにおいて、すべてに共通する構造を示している。

システム開発で設計対象となる４つのアーキテクチャ
　現在の多くのシステム開発では、４つのアーキテクチャが設計の対象となる。それぞれのアーキテクチャに関しては、表8-1にまとめた。

①システムアーキテクチャ：既に述べたように、システムレベルでの機能と構造要素の関係を記述したものが、このアーキテクチャの内容となる。
②システム基盤アーキテクチャ：システムプラットフォームという呼ばれ方もする、開発対象のソフトウェアが動作をする基盤となるシステムの体系であり、一番下のハードウェア（具体的には、どのようなサーバーを使うのか）からOS（Operating System）DBMS(Data Base Management System)ソフト、OLTPなどのミドルウェア・ソフトなどの構成をどのようなものにするのかがこれに該当する。
③データアーキテクチャ：いわゆるデータベース設計により生まれるデータ構造をまとめたものが、データアーキテクチャを記述した文書である。これを設計することは、システムアーキテクチャの構成要素間のデータインターフェースを決めることに他ならない。以上が、基本設計工程で行われる作業で生まれるものである。
④プログラムアーキテクチャ：個々のプログラム・レベルにおける実現機能と構成要素の関係を記述したものが、このアーキテクチャの内容である。

オンラインのシステムアーキテクチャは“すり合わせ型”
　筆者は1970年代に都市銀行で勘定系オンラインの開発に従事したが、この時代の処理方式は、バッチ（一括）処理法とオンライン即時処理（OLTP）法を組み合わせることで構成されていた。筆者はその中で、主に勘定系オンライン処理の開発を担当した。この時代のオンラインシステムのアーキテクチャは、図8-4に示すように、まず、実現すべき業務機能を分割して結果を縦軸に置く。次に、横軸に全体を俯瞰して抽出した共通機能を書き、丁度、マトリックスのように交差した部分の構造設計を行うという方法が取られた。オンライン処理の流れは、１）入力されてきたトランザクション（取引）情報を内部の標準形式に正規化するノーマライズ処理、２）入力された情報が正しいかどうかの検証を兼ねてデータベースの情報を読み出しチェックする検証処理、３）指示された作業内容を行い処理結果をデータベースに書き戻す更新処理、４）処理結果を入力のあった端末に出力処理するとともに、処理結果の集計処理を行う、というような流れで行われる。筆者は、その中で共通アプリケーション（CA：Common Application）という担当であった。そして、普通預金や、当座預金、定期預金、貸し付け、外国為替等の担当者と、すべての取引に関してプロセスフローを確認するという膨大な打合せを行い、大量の資料を記述したものだった。つまり、オンライン処理は、完全なすり合わせ型だったのだ。従って、実現機能群と構成要素群の間の機能の割り振りが複雑化し、多くのインターフェースの設定が必要となり、前出の図で要素間のマトリックス状に交差した個所では、極めて困難なすり合わせ作業が必要となったのであった。

　つまり、本質的にソフトウェアというものは、多くのすり合わせが必要なインテグラル型の人工物であるということだ。そして、もし、何らの工夫がなければ、勘定系オンラインのような大きな規模の基本設計では、機能と構造のマッチングを行う際に、多くの設計者が関わるようになる。その結果、必要となる打合せの数が人数の二乗のオーダーで増加することになる。そして、開発プロジェクトは、設計者間の打合せの激増でコストと時間の大半を消費されるという悪夢に苛まれることになると思われた。しかし、実際の日本の開発現場では、打合せの数を限定できる工夫がなされ、そのような危機は回避された。次回は、その辺りの打合せ回数を制限できる日本のシステム開発での工夫について述べることにしたい。

（注1）：『日本のもの造り哲学』藤本 隆宏著　日本経済新聞社　2004年刊