シス開発：注目すべき重要技術 |
オブジェクト指向技術が実用期に突入して、様々な技術やツールが登場している。また、普及が進むとともに、いろいろな設計術や管理術も単行本の形で紹介されるようになった。きちんと勉強すれば、かなり高度な設計も可能な状況である。
オブジェクト指向技術は、最初はプログラミングが中心になって発達した。オブジェクトのカプセル化や継承などの機能により、柔軟性が高くて再利用しやすい形でプログラミングできる。また、クラス・ライブラリが充実するほど、開発する量が減っていく。こうしたメリットにより、開発や保守が容易になる。
最近では、オブジェクト指向の影響が、プログラミング以外の要素にまで広がった。オブジェクト指向データベース、分散オブジェクト技術、オブジェクト指向に対応したテスト方法やツール、プログラミングから問題領域までのデザインパターン、UMLを代表とする表記方法などがある。
まず最初は、オブジェクト指向技術に関係する全体像を理解しなければならない。個々の技術や標準だけでなく、設計術や管理術も含めて、全体像を表にまとめてみた。技術や標準だけでなく、設計術や管理術も含めてある。
開発の要素 個別の技術、標準、ツール 設計術や管理術 プロジェクト管理 − OO時代のプロジェクト管理
OO時代に適した開発組織開発手法 OO時代の開発手法
（例：ユニファイド・プロセス）開発手法のアレンジ 問題領域の設計 − アナリシスパターン
特定業務の設計例システムおよび
システム間の設計分散オブジェクト技術
各種フレームワーク上位のデザインパターン プログラム設計 OO対応のプログラミング言語
各種クラス・ライブラリデザインパターン データベース オブジェクト指向DBMS（ODBMS） ODBMSでのデータベース設計 テスト OO対応のテスト支援ツール OO時代のテスト手法 表記方法 UML、UML支援ツール UML未規定部分の表記術 旧式の資源 レガシー接続ソフト レガシーラッピング設計 OO以外 XMLなど 対象ごとのOOでの設計術
これが現状での全体像である。プログラミング言語や、実装レベルのデザインパターンだけではなく、もっと広い範囲に影響が及んでいる。
上記の表に含まれる要素を、簡単にだが順番に説明しておこう。どの要素にも、設計術や管理術が含まれている。
まずは、プロジェクト管理だ。オブジェクト指向の開発では、開発する対象をいくつかに分割して、時期を少しずつずらした刺身型（ガントチャートで描いた様子が、刺身の盛りつけの形になるから）の部分並行開発が可能になる。また、再利用の度合いを高めるなら、仕事の担当を新しい形で分割しなければならない。こういった点を考慮した開発組織に変え、それを上手に進められるプロジェクト管理を用いる。
開発手法も、オブジェクト指向を前提とした方式を採用する。いろいろな手法が乱立していたが、３つの手法の提唱者が協力した「ユニファイド・プロセス」の登場により、デファクト・スタンダードが決まりそうな気配を感じる。１つの手法に収束する必要はないが、初心者が学ぶ際には標準があったほうがよい。この種の開発手法では、システムの用件定義段階から最終テストまでサポートし、オブジェクト指向の分析や設計も含まれる。自分たちの仕事に合いそうな開発手法をどれか１つ選び、仕事に適合させる形でアレンジすると開発が成功しやすい。
設計に関しては、いろいろなレベルで技術や設計術が登場している。問題領域レベルでは設計術だけだが、デザインパターンとして「アナリシスパターン」という本が出ている。かなり凝った設計術をいくつも紹介してある。これとは別に、特定業務の問題領域レベルでの設計例も、似ている業務ならば設計の参考となる。
実装レベルの設計は、システム全体およびシステム間と、プログラムおよびプログラム間の２つに分けられる。プログラムに近いレベルの設計では、オブジェクト指向に対応したプログラミング言語を用い（あえて「対応」と表現したのはC++などを意識したため）、ターゲット環境で利用可能なクラス・ライブラリを活用する。ここでの設計では、「デザインパターン」の本に紹介されているパターンが役立つ。より上位の実装レベルにあたるシステム全体およびシステム間の設計では、CORBAのような分散オブジェクト技術や、対象システムに適したフレームワークを利用する。このレベルでのデザインパターンは何層かに分けられ、「CORBAデザインパターン」の本が詳しく説明している。
データベースでは、オブジェクト指向データベースを用いることで、オブジェクトの参照関係をそのまま保存できる。オブジェクトへの変換する処理を作らなくて済むなど、余計な部分を開発しなくて済むのがメリットだ。システム設計においては、オブジェクト指向の特徴を最大限に生かすとともに、特定のデータベース製品に依存しないように作ることが大切である。
システムのテストは、オブジェクト指向になると非常に難しくなる。クラスの場合は、単純に呼び出すだけでなく、サブクラスを作って一部を上書きするとか、より多様な方法で使われるからだ。また、再利用を重視すると使われる範囲が広がり、仕様を変更したときにはテストすべき範囲が多い。全部をテストするのは理想だが、工数を考えると上手に手を抜く技が求められる。それを考慮し、システム設計の段階では、テスト範囲が広がり過ぎないように、直接的な影響範囲を限定する工夫が、現実的には必要だろう。そうすることで、トラブルが及ぶ範囲も狭められる。こういった工夫は、既存のデザインパターンにまだ含まれていないようだ。
システム設計内容の表記方法としてデファクト・スタンダードとなったUMLは、支援ツールを用いて利用する。良い仕様書を作るためには、UMLの表記だけでは不十分で、より多くの情報を加えなければならない。どんな項目を追加し、どのように書くのかを決めるのが、活用のポイントといえる。
RDBMSといった以前からある技術を用いたシステムも、そのまま使い続けなければならない。それらを変更せずに用いて、オブジェクト指向で設計したシステムと接続するのに、専用のツールを利用する。それがレガシーラッピングだ。その際には、既存システムの将来の入れ替えも考慮して、対象システムを設計する必要がある。
実際のシステム開発では、データ記述規格XMLやウェブサーバーなど、オブジェクト指向以外の技術や規格も一緒に用いる。オブジェクト指向技術の影響範囲が広いのに加え、こういった技術のオブジェクト指向設計での扱い方も知らなければならないため、オブジェクト指向技術を総合的に習得するのは非常に大変だ。自分が利用する部分を優先して、順番に習得するのが現実的だろう。
オブジェクト指向技術を利用すると、保守性が高くて再利用が可能なシステムを作れる。しかし、そのメリットを最大限に生かすためには、次の２点を注意しなければならない。１つは、開発の工数を減らすために、フレームワーク、クラス・ライブラリ、各種ツールなどを積極的に利用して、自作する部分を減らす点だ。保守性を高めるだけでなく、開発の負荷や期間も小さくできる。
もう１つの注意点は、開発する技術者にオブジェクト指向技術を身に付けさせること。デザインパターンを多用して柔軟性を高める設計は、それなりの技術を身に付けていないとできない。さらに問題なのが、システムの保守だ。凝った設計の内容を理解できる技術者がいなければ、せっかく考慮した設計が逆に障害となり、システムを修正できない事態に陥る。下手に変更すると、場合によってはシステムをボロボロにしてしまう。
実は、オブジェクト指向技術の最大の問題は、技術者に求められる能力が以前より高い点にある。構造化の設計やプログラミングは、頑張って勉強すれば理解できる程度の技術なので、多くの人が習得できた。しかし、オブジェクト指向の特徴を生かすデザインパターンは、構造化と比べて理解しづらい。それだけ敷居が高いので、以前よりも教育を重視する必要がある。だとしても、もともと簡単ではないため、理解できない人の割合は以前よりも高い。つまり、オブジェクト指向とは、システム開発の適性が高い人に向いた技術なのだ。
ただし、ライブラリやツールを最大限に活用することで、１人で開発できる量が増えるメリットもある。適性の高い人が集中して作業できれば、少ない人数でも同じ規模の開発が可能だ。とはいえ、要件定義やテストの工数はあまり変わらないので、その作業の人数を減らすのは難しい。やはり、理解している技術者を増やすしかないようだ。
では、現実の開発ではどうすればよいのだろうか。最初にやるべきなのは、技術者の教育である。オブジェクト指向の流れは止められないので、全員に習得してもらう。その結果、適正が明らかになるはずだ。
理解している技術者が不足する場合は、各人の適正に応じた担当分けをするしかない。オブジェクト指向技術を使いこなせる技術者には、システム全体や中心となる箇所の設計を担当させ、オブジェクト指向のメリットを生かす形で作ってもらう。逆に使いこなせない技術者は、複雑な関連を持つクラス設計などには深入りさせず、部分だけの設計に限定する。その設計結果は、詳しい技術者がレビューして、設計の質を確保する。理解する技術者が不足する限り、こういった方法の採用はやむを得ないだろう。
分かる技術者が十分に確保できない場合には、凝った設計だと保守できない心配もある。そんな状況を防ぐために、凝った設計を避ける決断も必要だ。凝ったデザインパターンをどうしても採用するなら、変更する際にどこをどのように直すかまで説明した書類を、分かりやすく書いて残しておくしかない。もちろん、それで絶対に大丈夫とは限らない。比較すると、凝った設計を避けるほうが安全である。
今後のシステム開発では、オブジェクト指向技術の活用が欠かせない。それだけに、オブジェクト指向技術の習得度の不足も、場合によっては大きな障害となるだろう。習得した人を集めるとか、既存の技術者に教育をするとか、何らかの対処が求められる。
将来的には、もっと高度なフレームワークやライブラリだけでなく、もっと新しい形式のツールが登場し、１人で設計できる規模が今よりも拡大するだろう。さらにテストのツールも進歩すれば、全体としての工数を大きく減らせる。そうなったら少数先鋭で開発でき、人材不足を解消できる。また、ツール類が高度になることで技術的な敷居が低下し、条件を満たす技術者が増えるかも知れない。その意味で、ツールの進歩は非常に重要だ。
以上が、システム開発でオブジェクト指向技術が関わる領域の全体像である。これを理解しながら、自分に必要な技術や設計術を優先的に習得していこう。まずオブジェクト指向に対応したプログラミング言語から始め、オブジェクト指向の本質を理解し、しだいに習得範囲を広げれば、段階的にスキルを向上できる。
これからのシステム開発では、オブジェクト指向技術が不可欠であり、それを習得せずに最新の設計はできない。全体像の多くを習得してしまえば、本格的な開発に参加しても、貴重な人材として活躍できるはずだ。
（2000年１月４日）
オブジェクト指向技術：実用段階だが難しさも残る |
