Comments
Description
Transcript
ソフトウェアにおけるアーキテクチャ
オンライン ISSN 1347-4448 印刷版 ISSN 1348-5504 赤門マネジメント・レビュー 2 巻 8 号 （2003 年 8 月） 〔研 究 会 報 告〕コンピュータ産業研究会 2003 年 6 月 20 日 1 ソフトウェアにおけるアーキテクチャ ―擦り合わせ型ソフトウェアにむけてー 玉井 哲雄 東京大学大学院総合文化研究科 広域システム科学系 E-mail: [email protected] 1. はじめに ここのところ、経営学ではアーキテクチャという言葉がキーワードになっている。そのよ うな研究では、とくにハードウェアを対象にしたものが多い。それでは、ソフトウェアはど うなっているのだろうか。ソフトウェアは、目に見えないものなので、ハードウェアのよう に注目されることは少ないが、重要であることには異論がない。 今回の発表では、まず簡単にソフトウェア工学の歴史的な流れを見た後で、「擦り合わせ 型ソフトウェア」というキーワードをもとに議論をしたいと思う。 2. 既存研究の概観 そもそも「ソフトウェア」という言葉は、誰がいつ頃言い出した言葉なのだろうか。実は、 意外とよくわかっていない。現在見つかっている最古の用例は、1850 年に「ごみのうち、 腐るものをソフトウェアという」という表現である。現在の意味のソフトウェアという言葉 は、どうやら 1958 年にJ. Tukey 2らが使い出したのでないかと言われている。つまり、それ ほど歴史があるわけではない。 ソフトウェアを理解することを難しくしている根本的な原因は、二つの性質が交じり合っ ているからではないかと思う。人工言語という言葉を使った抽象的な表現であり、いわば芸 術作品の性質を持っている一方で、実世界に直接働きかけるような工業製品としての性質も 持ち合わせていることではないだろうか。この二面性がソフトウェアの理解を困難なものに 1 2 本稿は 2003 年 6 月 20 日開催のコンピュータ産業研究会での報告を立本博文（GBRC）が記録し、 本稿掲載のために報告者の加筆訂正を経て、GBRC 編集部が整理したものである。文責は GBRC に、 著作権は報告者にある。内容の引用または複製には著作権者の許可を必要とする。 John W. Tukey：統計学者。この記事に関しては、http://www.sciencenews.org/20000805/mathtrek.asp 367 ©2003 Global Business Research Center www.gbrc.jp コンピュータ産業研究会 2003 年 6 月 20 日 している。 次に、日本のソフトウェアの現状を見てみると、明の部分と暗の部分がある。まず、明の 部分から見てみると、昔と比べて、利用する場面は格段に多くなってきている。日本の情報 サービスの年間の売上高は、2001 年度の数字3で、13 兆 7039 億円となっている。また、ソ フトウェアの対象領域も非常に広くなった。ゲームや組み込み型の小さなソフトウェアから、 製造、金融、公共システムといった大きなものにまで広がってきている。また、その開発を いろいろな人が担うようになった。さらに需要は増大しつづけている。しかし、暗の部分に 目をやってみると、なかなか安心できない状況である。 まず第一に、マイクロソフトに代表されるような海外企業にパッケージ市場を独占され てしまっている。また、大規模ソフトウェアの開発の現場をインド、中国、アイルランドな どに取られてしまっている。これらの国々の開発現場は、ただ単価が安いだけでなくて、技 術力も相当の水準にある。日本のソフトウェア産業の空洞化が危ぶまれる。 第二に、ハードウェアの進歩と比較すると、ハードウェアが著しく性能を上げている一方 でソフトウェアの生産性や品質の向上は数値化しにくい。例えば、半導体などは、ムーアの 法則に代表されるように、著しく集積度を上げて、スピード的な性能向上をしている。一方、 ソフトウェアの方はといえば、明確な数字は無いが、指数関数的な上昇をしてきていないの は確かである。 最後に、ソフトウェア自体の社会的認知が低いのも、問題を悪化させている。ソフトウェ アは、目に見えないものだから、なかなか認知が広がらない。例えば、ロボットコンテスト は、NHK で放送してくれるが、プログラミングコンテストは、放送してくれない。 このような現状を認識した上で、ソフトウェアのアーキテクチャに関して説明していきた い。 3.ソフトウェア工学の流れ 初期のソフトウェアは、工芸的に作られていたが、これでは信頼性のあるソフトウェアを 大量に作ることは不可能だという意識が業界の中に広まっていった。特に、その当時のソフ トウェアの発注者は、軍関係が多かったため、いっそう深刻であった。このような状況を受 けて、1968 年に NATO 主催の「ソフトウェア工学」会議が開かれ、 「ソフトウェアを工芸品 （クラフト）ではなく、工業製品として作ろう」という流れが確立していった。 3 通産省「平成 13 年特定サービス産業実態調査」 368 コンピュータ産業研究会 2003 年 6 月 20 日 1970 年代には、この流れの中で、構造化プログラミング（ストラクチャード・プログラ ミング）が盛んに主張されるようになった。このとき、構造化設計・構造化プログラミング など、ソフトウェア工学の基本的なコンセプトが次々にできていった。とくにこのころ、モ ジュールという概念が強く打ち出されていった。モジュールとは、抽象化されて、内部構造 はブラックボックスで、外部に対してインターフェースが公開されているもののことである。 大規模システムを作る際に、このモジュールを組み合わせて大きなソフトウェアを構成しよ うとした。 1975 年に出版された The Mythical Man-Month4では、ソフトウェア・アーキテクチャという 言葉が出てくる。この中でのアーキテクチャの使われ方は、現在で言うところの要求仕様と いう意味に近い。The Mythical Man-Month は、古典として何度も読まれているが、ソフトウ ェア・アーキテクチャという言葉をいち早く使っている点でも、重要な文献である。 1980 年代後半から 90 年代前半にかけて、ソフトウェア工学の焦点がプロダクトからプロ セスに移っていった。ソフトウェアを作り出す工程（プロセス）自体も、デザインでき、プ ログラム可能ではないかという発想である。プロセス・プログラミングと呼ばれるものであ る。これは、後の Business Process Modeling のきっかけとなった。とくにアカデミックの世 界で主流になっていったとおもう。しかし、産業界のほうは、ISO9000 や ISO9001 または CMM（プロセス成熟度モデル）のようなものに流れていった。全体的に見ると、80-90 年代 は、研究と実践が乖離していった感がある。 1990 年代後半に入ると、それまでプロセスに焦点があったソフトウェア工学も揺り戻し があり、プロダクトのデザインへの関心が復活した。Shaw and Garlan (1996) が書いた「ソ フトウェア・アーキテクチャ」では、ソフトウェアのデザインに影響を与えるようなシステ ム全体の構造という観点からアーキテクチャのパターンを説明してる。たとえば、部品合成 としてのシステム組織、大域的制御構造などを扱っている。 ソフトウェア・アーキテクチャの中身を整理すると、 ・ 計算部品とそれらの相互作用という形でシステムを記述するもの。 ・ システム要求と構築されるシステムの要素との対応をつけ設計判断に根拠を与えるも の。 ・ システム・レベルの性質として、容量、スループット、整合性、部品の適合性などを 考慮するもの。 4 1975 年 F. Brooks 著。IBM の技術者であった筆者が、1960 年代に体験した IBM の System/360 の OS である OS/360 での開発での知見をまとめたもの (Brooks, 1995)。 369 コンピュータ産業研究会 2003 年 6 月 20 日 ・ アーキテクチャの設計とは、合成の規則と振る舞いの規則を定めること。 であると言えると思う。 たとえば、データフローのアーキテクチャの場合、パイプとフィルタといった代表的なパ ターンがある。また、例えば、呼出・復帰システムの場合、層別（各レイヤーは、境界を通 してしか、他のレイヤーとやり取りをしない）がある。 4. モジュール設計 モジュールに関しては、1970 年代からの話であるので古くて新しい話である。ソフトウ ェアの設計とは、いいモジュールを追い求めての設計である。しかし、なかなかモジュール 化設計はうまくいかない。なぜ、ソフトウェアは、部品化できないのか、再利用化できない のか、なぜうまくいかないのか。 ひとつには、モジュールの単位がはっきりしないことにある。いままでの歴史を振り返っ てみても、以下四つのレベルがある。 ① 手続き：関数やサブルーチンのこと。 ② 抽象データ型：Ada や Modula といった言語で採用された抽象的なデータ型。 ③ オブジェクト：オブジェクト指向言語におけるモジュールの単位。抽象データ型に近 いが、抽象データ型よりは、アクティブで自分の状態を中に持っている。 ④ コンポーネント：オブジェクトに近いが、直接流通し、中身はブラックボックスとし て直接利用する。オブジェクトよりは、もう少し大きい単位であることが一般的。 このように、モジュールのレベルを何処に持ってくるかだけでも、これだけのレベルがあ ることが、モジュール設計がなかなか簡単にはいかないことを示している。 また、モジュールを設計する時に、どういう観点から設計するかによっても、最適なモジ ュール設計は異なってくる。たとえば、ある観点からのモジュール化ができたとしても、パ フォーマンスという別の観点から、また、セキュリティーという別の観点からのモジュール の分割方法を考えると、あるモジュールの分け方が、よくないモジュールの分割方法になる。 このようなことを解決するために、関心事の分離（separation of concerns）をし、局面（aspect） 指向プログラミング（セキュリティーの面からの再設計する場合、今までの設計を壊さない ように、付け加えられないか）が考えられているが、まだ、実際の現場では利用されていな い。 370 コンピュータ産業研究会 2003 年 6 月 20 日 5. アーキテクチャ コンピュータの世界では、アーキテクチャという言葉は、古くから使われている。 ひとつめは、ハードウェアの分野で CPU などが理解する命令のセットを指して、コンピ ュータ・アーキテクチャと呼んでいる。「どういう風に命令のセットをつくり、どういう風 にそれを実現するか」、アーキテクチャの中心だからである。もう少し広い意味では、回路 の構成だとか、部品の配置もふくむ｡5 二つ目は、通信の分野でネットワーク・アーキテクチャがある具体的には、通信の際の約 束・プロトコルの集まりをアーキテクチャと呼ぶ。例えば、ISO/OSI のプロトコル階層モデ ルなどがこれにあたる。 それに対しソフトウェアの分野で基本的な設計構造をアーキテクチャと呼ぶのが一般化 したのは、1990 年代の半ばからである。またソフトウェア・アーキテクチャに関連する概 念として、フレームワークと設計パターンがある。フレームワークとは、特定の領域向けに アーキテクチャを具体化した骨組みであり、それにモジュールを付け加えることで、効率的 に応用システムを開発することができる。一方、設計パターンは、アーキテクチャよりは小 さい単位で、能力がある技術者だと知っている設計上のパターンである。オブジェクトの関 係パターンをライブラリ化してやることで、それを活用して質の高い設計を行うことができ る。 特に設計パターンの話は、建築の専門家 Christopher Alexander6 からとても影響を受けてい る。1994 年に発表された Gamma, Helm, Johnson, and Vlissides (1994) 以降、広まり、ソフト ウェアのパターンライブラリの収集・公開活動が続けられている。 6.「擦り合わせ型アーキテクチャ」 いままで、ソフトウェア工学において、モジュールやアーキテクチャといった概念がどの ように用いられてきたかを概観した。ここから本題の「擦り合わせ型ソフトウェア」の話題 に入る。 日本のソフトウェア開発のいい部分を上げると、たとえば、 ① きめの細かい顧客対応 ② 計画フェーズに時間をかける ③ いったんはじめたら、なかなかやめない 5 6 たとえば今でも、PC のことを「x86 アーキテクチャ」と呼ぶ。 Alexander, Ishikawa, and Silverstein (1977). 371 コンピュータ産業研究会 2003 年 6 月 20 日 ④ 日本語という防波堤があるので、海外企業参入の障壁になっている といったことが挙げられる。これらの特徴を持ったソフトウェアの持つアーキテクチャを 「擦り合わせ型」アーキテクチャという喚起力のある言葉によってまとめられるかもしれな い。 しかしながら、今のところこれらの性質が、マイナスの方向に向かってしまうことがある。 上記の①～④に対応して、その負の側面を見てみると、 ① きめの細かい顧客対応Ù顧客にひきずられている ② 計画フェーズに時間をかけるÙ計画フェーズの生産性が悪い ③ いったん始めたら、なかなかやめないÙ結局、やるべきかどうかの見切りがつかない。 ④ 日本語という防波堤があるので、海外企業参入の障壁になっているÙ世界から孤立 といったマイナス方向があり、現在なかなかプラス面を完全に生かしきれていない。 以前 IBM の大和研究所にいた Les Belady 博士は、つねづね A 型ソフトウェアと B 型ソフ トウェアの違いについて述べていた。 A 型ソフトウェアとは、おもにコンポーネントになるソフトウェアのことであり、標準化 されやすいソフトウェアのことである。一方、B 型ソフトウェアとは、コンポーネントを組 み合わせて、もっと大きなシステムをつくるソフトウェアのことであり、領域依存のソフト ウェアのことである。A 型ソフトウェアと B 型ソフトウェアの対比の中で、彼は、 「これか らは B 型ソフトウェアが重要になる」と主張していた。 振り返って、日本のソフトウェアの現状を見ると、日本のソフトウェア産業は、ソフトウ ェアを作るツールの部分をアメリカに抑えられている。ユーザーの問題もあるだろうが、作 り手側の問題として、パッケージソフトとしてのプロダクト化の動きが弱いと思う。その反 動として、B 型ソフトウェアの範疇であるようなシステムソフトを富士通、NEC などが請負 ビジネスとして作ってきた経緯がある。 しかし、そのような請負ビジネス的な雰囲気があるせいか、なかなか、本質的に日本のソ フトウェア産業が強いというところに結びついていない。たとえば、 ① 類似のソフトウェアをあちこちで作るという業界の横並び意識。 ② 類似のソフトウェアを何度も作る。これはメンテナンス技術力の不足、設計技術力の 不足かもしれない。 ③ 下請け構造による見せかけの産業規模の拡大：丸投げ・丸投げを繰り返しているので 実際に作っているものよりも大きな金額規模。 372 コンピュータ産業研究会 2003 年 6 月 20 日 ④ 出来高制による見積もりの弊害。ソースコードの行数に応じて、価格を決定するため、 なるべく行数を多く見せるようにする。 ⑤ 組合せただけでは動かないソフトの調整。しかしながら、調整（tailoring）にとどまる レベルなので、産業力としては弱い。 擦り合わせは、産業として、必要な要素である。標準仕様だけでは動かない部分がまだま だ多くあり、その部分での本質的な優位の可能性がまだ残っていると思う。しかし、擦り合 わせとはいっても、調整（tailoring）にとどまるレベルでは、産業として優位であるとは言 えないだろう。 今後、日本のソフトウェア産業にとって、B 型ソフトウェアという意味での本質的な「擦 り合わせ型アーキテクチャ」が向かうべき道ではないだろうか。 参考文献 Alexander, C., Ishikawa, S., & Silverstein, M. (1977). A pattern language: Towns, buildings, construction. New York: Oxford University Press. Brooks, F. P., Jr. (1995). The mythical man-month: essays on software engineering (Anniversary ed.). Reading, MA: Addison-Wesley. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design patterns: Elements of reusable object-oriented software. Reading, MA: Addison-Wesley. Shaw, M., & Garlan, D. (1996). Software architecture: Perspectives on an emerging discipline. Upper Saddle River, NJ: Prentice Hall. 373 コンピュータ産業研究会 2003 年 6 月 20 日 374 赤門マネジメント・レビュー編集委員会 編集長 編集委員 編集担当 新宅 純二郎 阿部 誠 粕谷 誠 片平 秀貴 高橋 伸夫 西田 麻希 赤門マネジメント・レビュー 2 巻 8 号 2003 年 8 月 25 日発行 編集 東京大学大学院経済学研究科 ABAS/AMR 編集委員会 発行 特定非営利活動法人グローバルビジネスリサーチセンター 理事長 片平 秀貴 東京都千代田区丸の内 http://www.gbrc.jp 藤本 隆宏