Drop version 2.0 Beta Q&A

このページでは、オブジェクト指向方法論version2.0 Betaの内容に関するご質問とその回答、そして新しいDropの内容に対する読者からのアドバイスを掲載していきます。

よりよい方法論となるようみなさんのご協力をお待ちしております。

内容に関しては適当に抜粋、編集して掲載いたします。

ご質問とアドバイスはE-mailにて受け付けております。Subject: を「Question of Drop v2.0」とご指定の上、info@takumi-lab.co.jpまでお送り下さい。ご質問者のお名前を掲載することもあります。匿名希望の方はその旨お書き添え下さい。

Since 15.Feb.1999


  1. コンポーネント開発のレベルをどう分ければよいかわかりません。
  2. Dropでは戦略モデルをつくることは必要なのでしょうか?
  3. 開発モデルとプロトタイプは、どこの開発サイクルに当てはまるのでしょうか?
  4. Dropのプロトタイプは全て行うべきですか?
  5. 要求モデル-概念オブジェクト-要求オブジェクトの関係がわかりません。
  6. モデルとは果たして、文章なのか? 図なのか? オブジェクトなのか?
  7. 第3章「エキストラ」と「アプリケーション」には違和感がある。
    第3章「エキストラ」と「アプリケーション」についての提案。
  8. 「生産性を期待できない」のであれば、生産性以外に何を求めればよいのか。
  9. ODGに技術的負荷が高くなる?
  10. デザインパターンに対する知識はADGになくていいの?
  11. クラス図には、開発システムのすべてのクラスを書くべきか?それとも?
  12. モデリングの中で、クラス図以外は省略できるか?
  13. Dropのインスタンス図はUMLのオブジェクト図と同じものか?
  14. Dropのシステム構造図はUMLの配置図と同じか?
  15. コンポーネントを追加する際にはクラス図にどのように反映させるのか?
  16. 開発環境(RDB、ORB、JDK、CVS)の管理は誰が行う?
  17. 現状認識モデルと戦略モデルの表記法は何がよいか?
  18. オブジェクト指向初心者の悩み「ゲーム作りの要求定義とデザインについての質問」
  19. オブジェクト指向の理論的将来性
    オブジェクト指向の理論的将来性の続き
  20. 再利用コンポーネント開発に対するコストについて書かれていない?

Q.コンポーネント開発のレベルをどう分ければよいかわかりません。

第1章を読んで、コンポーネントのレベル分け(Generic,App Parts,App)とADGとODGの境界がよくわかりません。(ODGのコンポーネント提供とは、コンポーネントのどのレベルまでをさしているのか?)

電総研 Drop勉強会[1998/6/11] 三上 剛さん(株式会社エムティシー)、平野 聡さん (電総研)

A.「第18章 再利用基盤モデル」のクラスレイアカテゴリのGeneric部分はODG、App部分はADGとなり、AppParts部分は、ADGのシステム分析者が主催するシステム共通ワークショップの「ADGとODGの設計作業分担計画」にて明らかにされます。App部分についても場合によってはODGにより作成されることもあります。元々、再利用レイアのApp Parts部分の範囲は、Drop利用者の組織もしくはチームで決める性質のものですので、ADGとODGの作業範囲もそのプロジェクトのリーダの話しあいの場(ワークショップ)によって契約がとり交わされるわけです。詳しくは、Dropv1.0 開発フェーズリファレンスのシステム共通設計を見てください。Drop v2.0では、ワークショップをもう少し強化しようと考えています。

Q.Dropでは戦略モデルをつくることは必要なのでしょうか?

電総研 Drop勉強会[1998/6/11] 平野 聡さん (電総研)

A.「Dropでは戦略モデルを作ることを必要とするのか?」という質問でしたらYESです。戦略モデルは現状認識モデルと同様に重要です。しかし、「Drop方法論は戦略モデルを対象としているか?」という質問でしたらNOです。モデルの存在は肯定してもそれを作るプロセスは示していません。 なぜなら、私個人の考えとしては、戦略モデルは企業戦略モデルの一貫として唱えるべきものであり、それを説明するにはいわゆるビジネスプロセスの領域に足を踏み入れることになるからです。そうなるとDropと同じ位の本をもう一冊書かなければならず、ソフトウェア開発という部分が薄れてしまうこらです。

では、なぜDropで取り扱わない戦略モデルを紹介しているのか?ということに疑問が残るでしよう。これは戦略モデルをあたかもDropで対応しているようにごまかしているわけではありません。:-)
理由は、「要求モデルの範囲を明確にする」ということです。つまり、Drop要求モデルとは、現状理解をし、それを基に戦略を立て、その戦略を基に期間とコストを考慮した要求モデルを作るというプロセスを解説することで、要求モデルの範囲を明確にしようとしました。Drop v1.0では、Drop対象外の部分の解説を簡略化するために、現状認識モデルと戦略モデルを合わせて現実モデルとしていましたが、これはあまり得策ではないことに気がつきました。やはり要求モデルに行き着くまでのプロセスが重要だったからです。 よって、戦略モデルについては、現状のDropでは対象外なのですが、今後なんかの形で私なりの考えを打ち出していこうと思っています。

ただ、Dropには組織戦略の章を設けました。これは、まだまだ未完成ですが「第8章 Dropによる組織改革」の部分です。この章は、開発対象の戦略モデルではなく、開発するための組織編成に対する変革のための戦略モデルを示したものです。

Q.開発モデルとプロトタイプは、どこの開発サイクルに当てはまるのでしょうか?

第2章を読んで、「2.3 開発モデル」「2.4 オブジェクトモデルのライフサイクル」 開発モデルのどこに開発サイクルがあてはまるのでしょうか。また、プロトタイプはどこにはいるのでしょうか。

電総研 Drop勉強会[1998/6/11] 藤本 真さん (株式会社PFU)

A.プロトタイプについては、標準的なタイプを示し、それがDropの開発サイクルのどこで使われるのかを説明しています。新しいバージョンでは、「第12章 プロトタイプ開発の利用」になります。

「2.3 開発モデル」と開発サイクルは、直交するものです。つまり、あまり直接的関係はありません。開発モデルは開発サイクルを横断して使われるものです。しかしながら、開発サイクルが「分析」から「設計・実装」と進むにつれモデルを見る視点は変化していきます。これが「2.4 オブジェクトモデルのライフサイクル」です。この詳細は「第14章 オブジェクトモデルのライフサイクル」で解説する予定です。

このように開発モデルは開発サイクルを横断して使われますが、その使い方については、物事をとらえる視点が異なるために多少違いがでてきます。その違いについては、開発モデル編の各章で解説されます。

Q.Dropのプロトタイプは全て行うべきですか?

「2.5 プロトタイプ開発」の図2-6について。プロトタイプはクラス構造評価などの項目について全て行うべきか、それとも項目のどれかを選択して行うべきでしょうか。また、図2-6が説明の「プロトタイプの乱用」にどのように役立つのですか(説明と図の内容の関係がわからない)

電総研 Drop勉強会[1998/6/11] 平野 聡さん (電総研)

A.プロトタイプの標準例として示しているもので全てを使うというものではありません。プロジェクトリーダが目的に合わせて選択できやすいように例を示したものです。

後、説明と図の関係がわからないというご質問についてですが、この部分だけでは、わかりませんよね。早速、以下のように変更しました。:-)

-----(ここから)----

プロトタイプ開発の役割は、分析・設計結果をそれぞれの初期工程で検証し、さらに洗練作業を行うことができるという意味で非常に重要なものである。しかしながら、プロトタイプの安易な乱用や開発プロセスとの混同によって、「プロトタイプは、開発者の自己満足だけに終わってしまった」、「ソフトウェア製品の品質を落としてしまった」など、思いがけなく悪い結果を引き起こすこともある。

このような問題は、プロトタイプの目的、利用範囲、期待する効果、評価方法などがプロジェクトチームにおける開発プロセスの中で明確に定義されていないことからくる。

Dropでは、このようなプロトタイプ開発によって引き起こされる問題を未然に防ぐために、図2-7に示す標準的なプロトタイプ開発をDrop開発プロセスに組み込んでいる。実際には、どのプロトタイプを利用するかはプロジェクトリーダが決めるものであるが、いざ実施することになれば、プロトタイプの実施方法はDrop開発プロセスに準拠しておこなうことになる。

-----(ここまで)----

で、Dropではプロトタイプ計画書を作らせ、チームの中で目的や利用範囲、期待する効果、評価方法などを明確にして、Dropの開発サイクルに組み込む形でおこなうのです。

Q.要求モデル-概念オブジェクト-要求オブジェクトの関係がわかりません。

電総研 Drop勉強会[1998/6/11] 平野 聡さん (電総研)

A.これは、Dropv1.0では完全に混同して用語を使っていました。:-)

v2.0では、

  • 「要求から作成するモデルは要求モデルである」
  • 「要求モデルの対象となるオブジェクトは要求オブジェクトである」

で統一します。混乱させてすみません。(98/8/15修正)

Q.モデルとは果たして、文章なのか? 図なのか? オブジェクトなのか?

第2章を読んで。現状認識モデル、戦略モデル、要求モデルという各モデルの具体的なイメージが与えられていないまま、説明が進んでいく。モデルとは果たして、文章なのか? 図なのか? オブジェクトなのか? 初出の時に Dropにおける各モデルのごく簡単な例を与えてもらえると、具体的なイメージをもって読み進められる。

要件定義は文章らしいと検討がつく。要求モデルは要求オブジェクトによって定義するらしい。そのオブジェクトは、オブジェクト指向プログラミングでいうところののオブジェクトなのか? それとも箱や丸でいいのか? 文章はいらないのか?と疑問を抱いたまま進んでいく。人によっては、概念オブジェクトのクラス図を書くことが、要求モデルをつくることだ、と思うようだ。

電総研 Drop勉強会[1998/6/11] 平野 聡さん (電総研)

A.これは非常に反省するところが多いです。私自身、モデルをある時は「図式表現だけ」に絞って解説していたり(これは、たとえば従来方法論はモデル依存症であると指摘する時など)、ある時は文章を含んで解説しています。

で、モデルとは何なのか?平野さんがお察しのとおり、「対象問題の深い理解を得るために、その対象をある目的または観点から眺め、重要でない部分を取り去り重要な部分だけにしたもの」のことをいいます。この行為をモデリングと呼び、その行為の成果物がモデルです。つまり、実世界や開発対象の姿を単純な図や文章にして表すことがモデルです。また、モデルである以上、そのモデルを見た人たちの頭の中で問題の本質部分で単純化されたモデルのイメージを共有することが重要となります。

これについては、第2章にモデルの解説を含めようと思います。ただ、まだまだコンセプト編として解説していた方がよいもの、たとえばモデルと開発サイクルなどもあります。もう少し構成を考えてみます。どうもアドバイスありがとうございます。

Q.第3章「エキストラ」と「アプリケーション」には違和感がある。

第3章「エキストラ」と「アプリケーション」には違和感があります。本文はこちら。

電総研 Drop勉強会[1998/6/11] 平野さん、浜崎さん(電総研)

A.やはり違和感を感じますか。:-)

ここは、私の頭ではストーリが連続していたんですがスーッと解説を流していたようです。

この部分は、平野さん、浜崎さんのアドバイスを参考に解説の仕方を変えるようにしたいと思います。もう少し考えさせてください。お二人のアドバイスは非常に考えさせられるものでした。ありがとうございます。と書きながら今考えてみました。:-)

次のように変更します。またわかりにくければ何度でも変更します。とにかく、ここはDrop方法論の敷居を低くするためのもにですから、ねちっこくやりたいと思ってます。

-------(ここから)------

実際に映画を撮影する際には、俳優の他にエキストラが必要となる。よってそれらを準備してから撮影に入るだろう。ソフトウェア開発においても、アプリケーションに特化する問題領域をソフトウェア化するためのクラスを開発しなければならない。これらのクラスをアプリケーションクラスと呼ぼう。

エキストラの中には、演技の優秀さを見いだされ映画俳優になってしまう人もいるだろう。ソフトウェア開発においても、アプリケーションクラスが汎用的なコンポーネントに変化することも起こりうる。

しかし、自然にエキストラが映画俳優に、アプリケーションクラスが汎用的なコンポーネントに変化するということではない。素質のあるエキストラは、映画監督にその素質を見いだされたとしても、監督が自ら育てることはないだろう。映画学校などで徹底的に訓練を受け、自らも努力を重ねることで、初めて映画俳優の切符を手に入れるのである。同様に、アプリケーションクラスに若干の汎用性が多少あったとしても、すぐコンポーネントになるわけではなく、コンポーネントとして、さらなる改善を受け洗練されて、初めてコンポーネントとなるのである。

つまり、コンポーネントの中には再利用要求が初めから明確でトップダウンによって設計されるエリートコンポーネントもあれば、アプリケーションクラスから汎用性を持つよう洗練・改善を繰り返しながらボトムアップにアプローチで再設計される、たたき上げコンポーネントもある。

また、この解説で注意すべき点は、映画におけるエキストラをソフトウェアにおけるアプリケーションクラスと表現していることである。

実際に映画を撮影する際には、俳優の他にエキストラが必要となる。よってそれらを準備してから撮影に入るだろう。ソフトウェア開発においても、アプリケーションに特化する問題領域をソフトウェア化するためのクラスを開発しなければならない。これらのクラスをアプリケーションクラスと呼びます。

エキストラの中には、演技の優秀さを見いだされ映画俳優になってしまう人もいるだろう。ソフトウェア開発においても、アプリケーションクラスが汎用的なコンポーネントに変化することも起こりうる。

しかし、自然とエキストラが映画俳優に、アプリケーションクラスが汎用的なコンポーネントに変化するということではない。素質のあるエキストラは、映画監督にその素質を見いだされたとしても、監督が育てるわけではなく、映画学校などで徹底的に訓練を受け、自らも努力を重ねることで、初めて映画俳優の切符を手に入れるのである。同様に、アプリケーションクラスに若干の汎用性が多少あったとしても、すぐコンポーネントになるわけではなく、コンポーネントとして、さらなる改善を受け洗練されて、初めてコンポーネントとなるのである。

つまり、コンポーネントの中には再利用要求が初めから明確でトップダウンに設計されるエリートコンポーネントもあれば、アプリケーションクラスから汎用性を持つよう洗練・改善を繰り返しながらボトムアップにアプローチで再設計されるたたき上げコンポーネントもあります。

また、この解説で注意すべき点は、映画におけるエキストラをソフトウェアにおけるアプリケーションクラスと表現していることである。

これは、アプリケーションに特化するクラスの位置付けが映画のエキストラ程度の重要度しかないということでは決してない。むしろソフトウェアにおいてアプリケーションクラスは問題領域の要求に密接に関係する非常に重要なクラスである。しかしながら、コンポーネント化(部品化)できないアプリケーションクラスは、そのソフトウェアにおいてのみ有用であり、そのような性質は1つの映画でしか登場できないエキストラと類似している。

-------(ここまで)------

Q.第3章「エキストラ」と「アプリケーション」についての提案。

すでにQ&Aにて、表題の質問と回答がされていますが、まだちょっと説明不足ではないか?と思われます。本文はこちら。

阿部隆さん(未来社)

A.どうもご提案ありがとうございます。3章の冒頭に提案どおり文面を加えようとしましたが、どうも事前の説明が長くなってしまうように思えました。よって、のように書き換えました。

Q.「生産性を期待できない」のであれば、生産性以外に何を求めればよいのか。

第5章について。オブジェクト指向技術を採用することによって、「生産性を期待できない」のであれば、生産性以外に何を求めればよいのか。(オブジェクト指向技術の導入メリットが見えなくなってきた)

電総研 Drop勉強会 三上 剛さん(株式会社エムティシー)、矢花 正寿さん(日本データリンク株式会社)

A.オブジェクト指向の究極的な効果はは生産性の向上です。生産性を期待できないと言っているのは導入初期(学習)段階です。それと、あそこで強調しなければならなかったことは「生産性といううたい文句で、上司を釣ってDropチームを作ると後が大変だよ!」 ということです。なぜなら現状プラットホームが変化している段階で、生産性をどうやって評価するのでしょうか?

その評価のためのメトリクスは正しいという根拠を持てるのでしょうか?

何の根拠もないステップ数や人月換算にて急激に変化している時代の生産性を図ることが可能でしょうか?

私は、そのようなでっち上げの評価などせずもっとダイレクトにオブジェクト指向の効果をトップに伝えるために、「安定したオブジェクト指向テクノロジを基盤として人材を育成し、明日の開発を行える組織を作る」ということをうたい文句にしてトップを説得できた方が、健全な戦略を立てやすいと考えて、あの章を作成しました。だから、、「生産性を期待できない」ということではないのです。

もし生産性を評価できるとすれば、オブジェクト指向技術を導入する事で最終的には生産性はアップします。今はそのような時代の変化についていけるようにチームを成長させることに主眼をおいた方がよいだろうというわけです。

三上さん矢花さんの質問によって、第5章が変な誤解を招く可能性があることを知りました。もう一度じっくり読み返して、私の考えがただしく伝わるよう改善を加えます。どうもありがとうございました。

Q.ODGに技術的負荷が高くなる?

第7章について。ADGとODGを比較するとODGに技術的負荷が高くなるのではないでしょうか。(ADG-ODGの作業のバランスを保のがむずかしい)

電総研 Drop勉強会より

A.たしかに技術をオブジェクトテクノロジーという狭い領域だけに限るとそうかもしれません。ただ、複雑な問題領域を扱うADGはソフトウェア技術面でも優れ、問題領域にも強くならなければなりません。その面から考えるとADGも大変なわけです。

また、Dropではその作業範囲を決めていません。それは、ワークショップで2つのチームの代表が話しあいで決定します。問題領域がソフトウェアに近い領域であるあらば、ADGは限りなくODGの領域に近づくでしょう。この辺の解説も追加していこうと思います。

Q.デザインパターンに対する知識はADGになくていいの?

デザインパターンに対する知識がODGを構成するアクターでのみあらわれるのはなぜですか。(デザインパターンの用語説明があるとわかりやすい)

電総研 Drop勉強会より

A.なるほど完全に用語から抜けていました。モデル解説なども含めて用語集を強化したいと思います。デザインパターンに対する知識がADGでも必要です。しかし、その重みを明確にしたいと思い、あえてADGアクターには入れていませんでした。本来ならば、ODG,ADG両方に同じ知識が必要であり、その重要度が違うというだけです。これについては、もう少し説明の仕方を考えてみます。

Q.クラス図には、開発システムのすべてのクラスを書くべきか?それとも?

クラス図には、システムのクラスを全て書くのでしょうか?(論理的には、1枚になるように) あるいは、「ある側面」に関係あるクラスのみを書いて、たくさんの側面についてのたくさんのクラス図が出来るのか?

電総研 Drop勉強会 平野 聡さん (電総研)

A.一枚で全てを表そうとせず、クラス図が意図する意味を伝えるように心がけることが重要です、たとえば、コンポーネントユーザのためのクラス図では、コンポーネントの詳細について情報隠蔽するためにコンポーネント表記「クラスの箱の中の○」が使われます。

また、コンポーネント実装のためのクラス図では、コンポーネント表記内部の構造が主な観点となり、その場合コンポーネント表記は展開され具体的な構造を示す必要があります。同様に、システムのフレームワークやミドルウェアの構造を示す図と、それを利用するクラス図は分けるべきです。

ここで問題となるのは、分けた図の一貫性をどうやって保つかということです。この点に私は、CASEツールに多くの期待をかけています。今まで解説した視点ごとに全体モデルの部分を強調して表示する仕組みが必要です。そのようなCASEツールを作成できるようにDropには「+マーク」と「○マーク」を使っています。

DropベースのCASEツールが作られるようになればいいんですが。まあ、よいと評価を受ければCASEツールも作られるでしょう。その前に完成させなければ話になりません。

Q.モデリングの中で、クラス図以外は省略できるか?

私は、モデリングの目標は正しいクラス図を作る事であると思っています。その他のたくさんのドキュメント類は全て、クラス図では表現出来ない事や分りにくいものを表現し補足するもの、また考えをまとめ、ミスを防ぐためにあるものであると思っています。(そしてその結果、全てのメソッドを記述した正しいクラス図が出来あがる。)

別の言い方をすると、クラス図は必ず作成するが、それ以外のものは必要ならば作成するが、自明な場合は作成しなくとも良いと思っています。また、クラス図はシステム全体に渡って記述する必要があるが、その他のものは、システムのある側面やシステムがある状況下にある場合について考察されたものがあるだけである。(もちろんこれらのドキュメントも重要ではある)

このような考えは、Drop には当てはまりますでしょうか。あてはまるならば、17.1 インスタンス図の最後「仕様化する」を「補足・検証する」にしたほうが私にはしっくり来ます。

電総研 Drop勉強会 伊藤 博さん (メディアラボ)

A.私もクラス図以外のモデル図は、クラス図に反映させるなんらかの要素があるという意味では同意見です。また、インスタンス図については「クラス図を補足・検証する」のほうが的を得ています。次の公開予定(7/9日)に修正します。

ただ一つだけ、今回のver2.0では「動的構造モデル」のコラボレーション図やシーケンス図にも力を入れました。その理由は、クラス図では仕様化できない動的側面を仕様化することが目的です。クラス図で表せるものは静的なモデルですので限界があります。

また、クラスではシステム全体のアーキテクチャについては表現できません。そのようなクラス図の限界を補う為に、他のモデルがあり、それもソフトウェアを作る上ではクラス図と同程度重要な仕様化であると考えています。

しかし、おそらくどのモデルよりも安定しており変化が少ないものがクラス図であると私は思います。伊藤さんが主張なさっていることは、安定感のあるクラス図をモデルの中心におくということではないでしょうか?

そうであるならば、私の感覚と同じです。

Q.Dropのインスタンス図はUMLのオブジェクト図と同じものか?

Dropのインスタンス図と、UMLのオブジェクト図は違うものか?また、オブジェクト図ではだめなのか?

電総研 Drop勉強会 平野 聡さん (電総研)

A.名前についてはオブジェクト図と呼んでもらってもいいです。しかし、Dropでは、クラスやインスタンスなどという構造を表すレベルよりも、もっと抽象的に表現する際に「オブジェクト」という用語を使っています。UMLでは「インスタンス」を「オブジェクト」として表現しているようです。今のところUMLに合わせる必要はないと考えます。

Q.Dropのシステム構造図はUMLの配置図と同じか?

「19章 システム構造図」はUMLの配置図と同じか?

電総研 Drop勉強会 平野 聡さん (電総研)

A.そうです。Drop風に拡大解釈している部分もありますが、UMLにステレオタイプが導入されたことによって殆どUMLで表現できるようになりました。

Q.コンポーネントを追加する際にはクラス図にどのように反映させるのか?

コンポーネントの動的な追加(新機能の追加・削除)はクラス図にどう記述するか?

電総研 Drop勉強会 平野 聡さん (電総研)

A.図のバージョンを上げて行くしかありません。この辺は、CASEツールに頼りたい機能です。

Q.開発環境(RDB、ORB、JDK、CVS)の管理は誰が行う?

電総研 Drop勉強会 平野 聡さん (電総研)

A.これは、基本的にプロジェクトマネージャーです。少なくとも、開発の際にどのようなバージョンを使うべきかプロジェクトの中で共通の認識がとれていなければならないと思います。これは、問題領域分析の実装基盤ワークショップにて決定されます。

Q.現状認識モデルと戦略モデルの表記法は何がよいか?

現状認識モデル、戦略モデル、要求モデル、アーキテクチャモデルの表記法についてですが。上の4つはすべてクラス図として表現できるものなのでしょうか?個人的には現状認識モデル、戦略モデルはUMLで定義している表記方ではなく、各自自由な表現方法をとることになるような気がしますが何かいい表記法(表現方法)はありますか?それともUMLで定義している表現方法を使ったがいいのでしょうか?ただ各自自由な描き方だと書く人によってもモデル図から受け止める情報も異なってくるような気がします。

小島さん (日本ユニシス)

クラス図をベースとして図を使うのは重要なことです。しかし、あまりシステマチックにならないように気を付けなければなりません。図を矛盾なく書き上げるという本題からはずれた作業に陥るかもしれないからです。実世界のモデルは非常にあやふやで分析者の主観や価値観に大きくモデルが左右されるため、矛盾しない完璧なモデルなどはあり得ません。よって、図の作成に作業の大半を使い果たすことがないようにしなければなりません。むしろ、現状のプロセスを表すシナリオ記述の方に力を入れるのが重要ですので、シナリオ記述の統一化をされる方が良いかもしれません。

ユーザを含めて分析する際には、ユースケース図はお勧めできるものです。私もこのモデルを明確にできたら、現状認識モデルや戦略モデルをDrop方法論の上位層の方法論を作れるのですが、

Q.オブジェクト指向初心者の悩み「ゲーム作りの要求定義とデザインについての質問」

ゲームをやっていますが、クラスを作り直してばかりで、勉強のマイナスになっているようにも思えます。考えてみると、「ゲームの要求定義を明確にしていない」からではないかと思いました。

(from 千葉さん)

質問と回答の本文はこちら

Q.オブジェクト指向の理論的将来性

うちの研究室の指導教官曰く,「オブジェクト指向は,あれだけ天才が集まって,あれだけしか結果が出てない」と言ってましたが,それについて萩本さんは,どう思われますか?

(匿名希望)

A.ははは。まったくですね。それだけオブジェクト指向は小さな一歩なんだと思います。

むしろ過大な期待は避けるべきだと思うのです。しかし、結果がでていないというと、それも違うように思います。個人ではオブジェクト指向を充分使いこなしている人たちが多いのではないでしょうか?

では、なぜ普及しないか?ということになりますが、個人的な考えでは、オブジェクト指向の考え方を伝える(教える)ためのノウハウがまだ確立されていないのだと思っています。だからオブジェクト指向を身につけた個人の中では、どんどん結果を出していると思いますよ。

Q.オブジェクト指向の理論的将来性の続き

というか,私が言いたいのは,例えば,分散システム(グループウェアシステム)もオブジェクト指向に立脚してますし,オブジェクト指向ネット理論もそうですね.つまり,実装云々ではなくて,理論的に将来性はあるのかどうかということをお尋ねしたわけです.お返事待ってます.

A.上記にはテクノロジーの問題とメソドロジーの問題があり、テクノロジーはどんどん発展してきけるでしょうね。しかし、メソドロジーの発展には恐ろしく時間がかかるものです。たとえば、やろうとしていることがインテリジェンスになればなるほど、テクノロジーの上に乗る普遍的なグローバルビューが必要となるでしょう。ここではそれらを構成する方法をメソドロジーと呼んでいます。オブジェクト指向は、メソドロジーをテクノロジーに連結させるためにも有望視されるものと考えていますが、そのためには技術者のパラダイム(というか、メソドロジーにも興味を持たせる?)を変えていかなければならず、それには教育面の充実や世代交代などを考えると10年単位の時間が必要とされるものだと思っています。

メソドロジーの発展の問題は、オブジェクト指向だから解決するとか、他の技術だから解決するとかいった問題ではなく、人間の抱える抽象概(*注)念の理解と抽象概念の伝達という難しい問題に取り組まなければならないと個人的には思っています。

で、ご質問の理論的将来性について私の考えを書きます。

オブジェクト指向は、構造化プログラミングや構造化設計における自然な発展系であると考えています。オブジェクト指向は、他人が理解しやすい構造的なプログラミングをする上で、必要不可欠なものだと思っています。

もし、将来性がなくなるとすれば、基本的にプログラミングは動けばよく、大量生産、使い捨てでよいといった方向に世の中が動き出した時です。

私は、できればそのような方向に世の中が動かない方がいいと考えているわけです。

構造化か非構造化のどちらかにソフトウェアに携わる人間が向かっていくかによってオブジェクト指向の将来は決まると思っており、私個人としては四半世紀くらいは持ちこたえる考え方で、将来も期待できるものだと思って取り組んでいます。

ただオブジェクト指向で一つ問題かなあと思っているものがあります。

オブジェクト指向は構造を重視するので構造の中を隠蔽することで複雑なシステムを作れるわけですが、この構造重視のために構造の変化に弱い面があることです。

この構造の変化とは、予測していなかった変化のことです。オブジェクト指向の再利用性、拡張性は設計者の予測範囲内ではうまく機能しますが、予測範囲の外では根本的な構造変化を伴うために非オブジェクト指向よりも弱い面があるのではないか考えています。

世の中の発展が複雑・多様になっている今、オブジェクト指向設計者の予測範囲を越えた発展が起こる場合に、オブジェクト指向の使い方(メソドロジー)を考えていかなければならないんだと思い、オブジェクト指向方法論の作成で、いまその問題に取り組んでいるところです。

また、この問題はオブジェクト指向言語を含むオブジェクト指向システムが、もっと発展し、信頼性を保持しながら高度な柔軟性をもたらすようになれば、予測しない変化にも対応できやすいテクノロジーを提供していけることになるでしょう。

(*注)ここで言う抽象概念とは、実体のない仮想的な「もの」と考えることができます。また、なにかを統一的に表現する理論やアーキテクチャなどの概念を構造的に示したモデルのことです。それを理解したり伝達するということは、抽象化された概念の世界を作りだし、そこで共通のモデルを形成しようとし、認識しょうとするといった、人間の自然な(高度な)行為のことです。これらは、まさに理論を作り出すまでに人の中で展開される思考そのものであり、そのやり方をメソドロジーと表現しています。

Q.再利用コンポーネント開発に対するコストについて書かれていない?

「第5章 プロジェクト構成の問題」についてですが、オブジェクト指向技術の導入初期に生産性が向上しない理由の一つに、再利用コンポーネントがそろっていない場合、または既にクラスライブラリが存在していても、社内開発に耐えない場合、その分のコーディング量がシステム開発に上乗せされるのは、周知の事実です。

ですが、その点をはっきりさせておいたほうが、Dropという方法論の公開においては、必要なのではないかと思われます。

問題要因の1と3の中で、技術習得にかかるコストについて触れられていますが、汎用コンポーネントそのものを作成するコストについては触れられていません。

これはある意味、「オブジェクト指向技術を自分である程度習得している者を集めてチームを作ったなら、この問題点は自ずからクリアされるのではないか?」という期待を与える事になるような気がします。

実際には、上記に触れたようにその社内で使うコンポーネントはクラスライブラリだけではカバーしきれず、汎用コンポーネント開発は半ば必須だと思います。

阿部隆さん(未来社)

A.なるほど。第5章を読み直してみるとたしかに指摘どおりですね。

第5章の「オブジェクト指向技術に関する評価・検証の問題」に「再利用可能なコンポーネントを開発する初期コストの把握が徹底されていなかった 」を追加しました。

Dropへ戻る

この記事のトップへ