情報システムは常にビジネス環境の変化に対して後手にまわってきた。結果、屋上屋を重ねるようにして追加、変更を繰り返したシステムはメタボ化し、そのうち命にかかわる事態に陥る。これまで、そうなるのに約３年から５年かかってきたから、システム自体もこのくらいのサイクルで最初から作りなおす、ということが行われてきたのである。
３年から５年といっても、開発に莫大な費用がかかる企業の基幹システムをこのサイクルで作り直すのは大変だ。どうにか開発を効率化すべく、最初に考えられらのが、標準化である。これはどちらかというと保守性を向上させ、システムのライフサイクルを延ばすことが目的だったと言える。あわせて、プログラムの部品化も行われるようになった。単純な例は、よくつかわれる処理を共通化し、サブルーチンにしてライブラリとしてまとめることだ。たとえば、Ｃ言語の標準関数などはその典型だし、アプリケーションのカテゴリごとに、さらに上位の処理をライブラリ化しておけば、開発効率は大幅に上がる。
スパゲティー化を阻止するたえの構造化が言語自体に組み込まれていく話は、先に書いたが、この部品化も同様に、開発環境に組み込まれていくことになる。いわゆるオブジェクト指向の登場だ。プログラムをライブラリ化して標準にしようとすると、同時にそのプログラムが取り扱うデータ構造も標準化する必要がある。ならば、特定のデータ構造に固有の処理を紐付けて一体化できないだろうか、そういう発想から生まれてきたのがオブジェクト指向だ。たとえば、Ｃ＋＋やＪＡＶＡの「クラス」はＣの構造体に、その構造体を取り扱うための関数ライブラリをメンバとして組み込んだような形をしている。クラスで定義されたデータ構造を取り扱うには、そのメンバである関数を使うしかない。だから、データに対して設計者が想定していないような処理をプログラマーが書いてしまうことも防止できる。
オブジェクト指向も、プログラマーの意識変革を必要とした。とりわけ設計者にとっては、いかに整然としたクラスの体系を定義するかということが最も重要になってくる。クラスは、継承が可能だから、基本的なデータ処理のクラス、たとえば、ツリー構造やリスト構造のポインタ処理のクラスを定義しておき、それを継承して、実際にツリー化やリスト化したいデータ構造とその取り使いを行うクラスを作るといった整理が可能になる。こうしてけば、テスト済みのクラスを継承すれば、その部分は追加のテストは不要になる。保守性も上がる。実際、私もＣ言語でプログラムを書く場合は、まず頭の中で全体の処理を描き、必要なパーツを洗い出してから、まずそうしたパーツとなる関数から書きはじめることが多い。オブジェクト指向はこのやりかたを必須としたものだ。だが、これは言うほどやさしくはない。私がそのような書き方ができるのは、何度もプログラムのスパゲティー化に苦しんできたからであって、どうすれば共通化や標準化がうまくいくかを体で覚えているからである。しかし、いきなりオブジェクト指向をつきつけられた開発者の中には、こうした本質を理解できず、結果的にクラスを体系化できないまま、似て非なるクラスを量産するものも出てきた。こうなってしまうとせっかくのオブジェクト指向も意味なしだ。つまり、これらの考え方は、大規模な開発を前提に、トップダウンで効率よく開発を進めていくことを前提にしているわけで、少数精鋭の設計者とその他多くのプログラマーが存在するプロジェクト向けのモデルなのである。つまり、製作と保守を容易にする反面、設計者は、スキルと経験をより要求されることになる。この点が理解できていないと、プロジェクトは悲惨な末路をたどる。
これは、プログラミングという一段低いレイヤの話である。システム全体のアーキテクチャとしてはどうだろうか。先にも書いたように、プログラムのスパゲティー化は阻止できても、システム全体としてスパゲティー化していたのではしかたがない。そういう意味ではシステムにも、ある種の構造化が必要になってくる。
（続く）
コメントする