現在地 HOME > 掲示板
> ＩＴ４ > 486.html
★阿修羅♪
|
現在地 HOME > 掲示板
> ＩＴ４ > 486.html
★阿修羅♪
|
|
(回答先: 非ユークリッド幾何学の歴史とソフトウェア工学の進化（前編）（CNET Japan12月9日） 投稿者 シジミ 日時 2003 年 12 月 16 日 22:15:03)
http://blog.japan.cnet.com/kenn/archives/000899.html
2003年12月15日
本編前に、少しお知らせです。このBlogについてのご意見・ご感想をいただくチャネルとして、今はコメントとトラックバックというチャネルがあるわけですが、いずれも第3者に対してパブリックな経路なので、内容によっては多少なりとも心理的バリアがあると思います。そこで、新たにメールアドレスをチャネルに追加しました。ここに送られたメールは編集部と私に届きますので、お気軽にどうぞ。
抽象化された設計図は工学の基礎
IT業界には、ソフトウェア工学という分野があると言われている。これは主としてソフトウェアの生産性・品質・再利用性などに関する様々なアプローチを総称するものであり、これまでにも論文や書籍が山ほど書き上げられてきたが、どれひとつとっても「工学」と呼ぶには躊躇してしまうようなシロモノばかりである。
なにしろ、ソフトウェア工学とやらの世界でベストセラーになる書籍といえば「やる気こそ成功の鍵」のような精神論的なものか、失敗談やジンクスのようなものが沢山載っている訓話集のような具体的なものばかりである。実際、こういった書籍のいくつかにはそれなりに面白くて価値があることも多いが、逆にアカデミックなアプローチを試みたものとなるとほぼ例外なく読むに値しない。
工学というものが応用・展開・生産のパラダイムである以上、ある対象を「工学する」という場合、その対象を抽象化した設計図を書くことができるはずである。例えば土木建築から航空機に至るまでのハードウェア工学では、CAD/CAMに代表される幾何学を基礎とした設計ツールを用いて設計図を作成し、質量や電位といった物理モデルを与えてシミュレーションすることができる。
一方、ソフトウェアの世界で唯一の体系だった抽象化ツールといえばプログラミング言語のソースコードだけである。プログラミング言語だけが論理的に閉じた世界観を提供し、厳密な意味での設計図としての役割を果たす。しかし、ソースコードというものはテストやデバッグという試行錯誤な工程を経て固められていくものだし、設計図と呼ぶには枝葉末節で複雑すぎる。だから、誰もソースコードが設計図であるとは信じることができないのだ。つまるところ、ソフトウェアの世界ではまだ適切な粒度で設計図を書けるだけの抽象化手法がどこにも存在していないのである。
モデリング技術とソフトウェア設計
設計図というものは、簡潔に記述できて広く正確に情報を共有でき、それをもとにコミュニケーションが促進されることが重要である。従って、一部のプログラマー（例えば、書いた本人）にしか理解できないという属人的な性質から逃れられないソースコードは設計図としての目的を果たすことができない。
ソフトウェア設計におけるこの種の複雑さに取り組むため、次に考え出されたのは設計の階層化すなわち「メタ化」のアプローチである。設計図の設計図、つまりモデリング技術に白羽の矢が立った。現在ソフトウェアの世界で設計図といえばこうしたモデル図のことを言う。そして、今ではモデリング技術がソフトウェア工学の基礎をなすであろうと広く信じられている。
UMLなどのオブジェクト指向モデリング技術を追求しているエンジニアたちは「設計図（UMLなど）を書けば自動的にソースコード（Javaなど）を生成してくれる世界がやってくる」というようなことを頻繁に口にするが、それは本質的なところで間違っているかも知れない。実は設計と製造で言語が分かれているという考え方自体が、ある種の先入観なのだ。先にも述べたように、工学の基礎をなすものは必ず論理的に閉じた世界観をもつものであり、ソフトウェア工学にとってそれはプログラミング言語をおいて他にない。ここでも忘れてはならないのは、ソフトウェアのプログラミングは本質的には製造ではなく設計の工程であるということだ。
断言するが、真の意味での究極のゴールは「設計と製造が同じ言語で行われること」であり、モデリング言語とプログラミング言語の完全な統合である。ではなぜそれができないのか？を追求すべきなのであり、課題の設定を間違えると時間を浪費してしまう。
私の見るところ、現在のモデリング技術は設計対象の静的な側面（データ構造やインターフェースの一部）と正常系のアクティビティはそれなりにスッキリと記述できるようになってきた。しかし、例外系のプロセスやふるまいの依存関係などを書き下そうとすると（そして現実世界では例外系の方が圧倒的に多く、しかも重要であったりする）あっという間にグチャグチャの醜い設計図になってしまうのだ。意外に思われるかも知れないが、設計を詳細に突き詰めればソースコードになってしまうのだから、ある意味では当たり前のことである。
こうして、UMLダイアグラムには（厳密な論理規則ではなく）直観によって典型パターンや正常系の部分だけが割り切って記述されることになる。設計者は解釈者が都合よく補完してくれることを暗に期待しているのである。これは、率直に言って設計図などではなくチュートリアルである。つまり、UMLが実際に行ったのはポンチ絵の描き方を緩やかに標準化した程度のことで、網羅性や論理的無矛盾性のような工学の基礎とはかけ離れたものだ。そんなオモチャのようなモデルからソースコードを生成してもらっても、ほとんど助けにはならない。マンションのパンフレットに書かれた間取り図をもとに建築作業にかかろうとするようなものだ。ポンチ絵の本質的な役割は、非専門家に理解を促しフィードバックをもらうことにある。従ってそこには主観や誇張が常に入り込むものだから、残念ながらどこまでいっても自動化工程に組み込めるようなものにはならない。むしろ逆方向の翻訳、即ちソースコードからポンチ絵の雛形を生成する方が現実味があると思えるぐらいだ。しかし、それでもUMLがポンチ絵の描き方を標準化したことにはそれなりの価値があるということも添えておこう。
問題の核心は、設計作業を上意下達の決定論的なプロセスと捉えていることだ。これは、設計という工程のイロハがハードウェアを扱う既存工学分野から持ち込まれたことに起因する。しかし、ソフトウェアは大量生産のためのパラダイムではなく、人間を支援する目的で使われるものなのだ。ハードウェア工学では設計図どおりのものが正しく製造できることが重要だが、ソフトウェアにおける製造の歩留まりは100％（バイナリをデジタルコピーするだけ）であるから、そこには価値を置いていない。むしろ人間の思考と連動して柔軟であることを求められる点で、既存工学の考え方と重ね合わせにくいのは当然なのである。
マクロな視点からみたソフトウェア
さらに、ソフトウェア工学のうち特に品質や再利用性について議論をする場合に「規模」は重要なファクターである。ソフトウェアは後方互換性の強迫観念により不可逆に大規模化していく性質を持つものであるから、当初は小さなスコープから始まったプロジェクトであっても時間とともに大規模化し、いずれ再利用性や品質に関する様々な事柄がのっぴきならない問題へと発展する。この大規模化傾向は、ソフトウェアを工学する上でとても重要な性質である。
例えば、ソースコードが100行程度の単一目的のプログラムは、その時点ではソースコード自体が設計図として十分に役に立つ。しかし、その100行のプログラムをコンポーネントとして使いまわそうと考えた途端、話はそれほど簡単ではなくなるのである。
ユークリッドの幾何学では「点」や「線」を定義し、公理から定理を、定理から各種命題を厳密に導出していった。定義済み公理や導出した定理に間違いが発見されると、それを利用している上位層（どう使われるかは事前に予測できない。だからこそどう使われてもいいように厳密性が重要となる）がガラガラと音を立てて崩壊してしまい、その喪失のコストたるや計り知れないものになることを知っていたのだろう。ソフトウェアの世界でも、基礎コンポーネントの入出力インターフェースの思想や目的などが厳密に定義されなければ、そのコンポーネントを再利用する上位層ではあっという間に先入観が入り込んできてしまう。例えば自分が想定するパターンだけテストし、それが通れば満足してしまう。致命的なバグや不具合に限って深いところに潜在化してしまう最大の誘因はこれである。
仮に、あるコンポーネントのインターフェースが利用者に正しく解釈される可能性を99％と仮定する場合、2連結では98％の信頼性を維持できる。しかし、同様のインターフェース品質99％のプログラムが100個ほど連結されるシステムを考えると全体の信頼性は37％にまで落ちてしまう。途中までは現場監督がハンマーやノコギリで何とか補修してこれたとしても、ここまで劣化するとどのみち破綻するのは目に見えている。海を渡ってみたら地球が丸かったように、ソフトウェアもマクロに見ると曲がった空間なのかも知れないのだ。特に可用性やインターフェース品質といった直列性・依存性・微分可能性のあるパラメータは、ユークリッドの平行性公準のように巨視系での誤差は許容しがたいものになる。しかも我々は、ソフトウェアの空間がどのような形状をしているのかについてさえ、まだ全く知り得ていないのである。
ソフトウェア工学の未来
ここまでの議論が暗示しているように、現時点で私が得ている結論は「まだソフトウェアは工学として成立していない」というものだ。もう少し言うと、その準備段階にあると考えられる。「工学する」ことができないから、プロジェクトを正しく見積もることさえできない。見積りさえ正しく出せない状況の中でビジネスを行っているのだから、基礎品質が悪く頻繁にトラブルが起きるのは当たり前である。今、ソフトウェア開発に従事する人々は前編に述べた紀元前1700年頃のバビロニア人と同じ水準にあるといっていい。
それでも、一部の優秀なエンジニアの頭の中には成功と失敗のパターンがしっかりと刻まれている。彼等がプロジェクトをうまくコントロールするための条件が整えば、ロープで測量するような原始時代でも立派な巨大ピラミッドを驚くほど正確に建造することができるのだ。古代バビロニア人が経験則で見つけたピタゴラスの定理を文章で表現していたように、数式や代数規則のような簡素化・抽象化された道具立てがない中で「要件定義書」という名の落書きのようなポンチ絵をもとに想像力を膨らませ、チームをなだめたりすかしたりといった人間力をふるいながら、まるでマジシャンのようにシステムを作り上げていく。何世紀後かに、ソフトウェア考古学者あたりが「人類は20世紀末から21世紀初頭にかけて、十分なテクノロジーがないにもかかわらず、多くの犠牲者を出しながらも世界遺産に値するシステムをいくつか作り上げていた」として、その功績を称えることだろう。
ソフトウェア工学が成立するとき、設計図の概念は「完成したら石版に刻んで飾っておくもの」から「いつまでも未完成で変化を続けているときにこそ最大の価値がある」ものへと大きく変貌しているに違いない。これまでの工学分野は物理や化学のようにルールが安定しているものを扱ってきたのに対して、ソフトウェアが不安定さを扱う人間工学のフロンティアであるならば、工学というパラダイムの定義を変えてしまうポテンシャルさえ持っているのである。
誰がいつソフトウェア工学の『原論』を書き上げるのか興味は尽きないが、それは少なくとも10年後や20年後ではない。人類はソフトウェア工学の世界で航海を始めたばかりなのである。ソフトウェア産業の生産性は年率5％程度のペースで向上しているが、これは一般的な製造業より少しマシといった水準である。ハイテク業界の幻想が醒めてきたからといって落胆する必要はない。本質的な部分は昔から何も変わっておらず、静かに進行中なのだから。いつかはコロンブスになれるかもしれないという希望を胸に、いまは原始時代を生きる人として文字通り汗水たらして働くとしよう。
♪ Matt Bianco / Gypsy Lady
題名には必ず「阿修羅さんへ」と記述してください。