本連載では,“オブジェクト指向開発方法論”を取り上げます。オブジェクト指向開発方法論を専門に研究されている方や,豊富な開発経験を持つ方なら,これから私がやろうとしている作業が決して生易しいものではないことを理解されていることでしょう。なぜなら,現在提唱されているオブジェクト指向開発方法論は,大小合わせればその数は数百に上ると言われているからです。

 このため,記事を起草する私の立場に立てば,論じる視点の設定がきわめて重要な意味を持ってくることになります。視点がなければ,あるいは,視点の設定が適切さを欠いていれば,記述内容が整理されず,読者の皆さんをがっかりさせてしまうことになります。

視点の設定

 現在公開されているオブジェクト指向文献の多くは,オブジェクト指向プログラミング言語の1つであるSmalltalkに触れながら,オブジェクト指向の歴史を振り返り,そして徐々に,オブジェクト指向の“オブジェクトとは何か”という用語定義作業に入るのが一般的です。本連載では,このような進行方法ではなく,次のような視点をまず設定します。

“オブジェクト指向開発方法論は,私たち普通の人々にどのようなメリットをもたらすのか?”

ここで一部の読者は,次のような疑問を持つことになるでしょう。

“普通の人々とは,この場合一体どのような人々を指すのだろう?”

 ここで私が想定している“普通の人々”は,インターネットを日常的に利用するWebサーファであったり,オンライン・ショッピングや最新音楽の試聴コード・ダウンロードなどをしている,通常はプログラム開発作業に従事しない人々を指します。

 一見するとこれら普通の人々は,深遠な世界観を唱えるオブジェクト指向開発方法論とは何ら関係ないように思えてます。しかし,オブジェクト指向はこのような人々の視点から考察する時期にきているのではないか,と私は考えています。理由は本連載を最後までお読みいただければわかります。

 本連載の視点は,オブジェクト指向開発方法論がプログラミングをしない人々にもたらす利益に設定しています。しかしだからといって,本連載内容が開発現場で日々汗を流す現役プログラマや,プロジェクトを率いる管理者にまったく利益をもたらさない,ということではありません。先ほど定義した“普通の人々”は,現実社会において,プログラムの発注者になるケースが結構多いのが現実だからです。

 それでは,発注を受ける開発者の立場からオブジェクト指向開発方法論を眺めてみましょう。開発者にとっては,オブジェクト指向開発方法論はソフトウエア開発作業をする際の方法論であるばかりではなく,発注者からの予期せぬ要求変更や将来の機能拡張に備えるための戦略指針でもあります。要求変更と機能拡張は,インターネットが普及した現在は当然発生する出来事です。インターネットからのアクセス件数が増えれば,何らかの機能拡張が必要になります。発注する側はだれでも,アクセス件数が増え,収益が激増することを望んでいます。その逆を望む発注者など存在しないと考えてよいでしょう。この意味では,オブジェクト指向開発方法論はいまやビジネスの本質と直結しているといえます。

 これは極論でしょうが,発注者のニーズを理解し,多少なりとも発注者を開発プロセスに参加させなければ,ソフトウエア開発は開始できないはずです。「納品後にいろいろ文句を言われた」という話はよくあることです。原因はいろいろあるでしょうが,基本的には発注者と開発現場とのコミュニケーション不足,つまり,開発者側のヒアリング不足ではないかと思います。旅行に例えれば,オブジェクト指向方法論は,基本的に後戻りを許さない滝(ウォータフォール)のある,上流から下流への一方向の急流下りを推奨するのではなく,必要なときには自由に後戻りのできる往復旅行(ラウンド・トリップ)を推奨していると思います。さらに演劇を例に取れば,発注者の描くシステムという舞台で演技する俳優(アクター)を最終的に決めるのはあくまでも発注者です。

 ここまでの内容を一読後,開発業務に携わっている一部の読者は,次のような抗議文を用意することでしょう。

“発注者が優柔不断で,何もかも一任されされた場合の結果責任はどうする?”

 現在のオブジェクト指向開発方法論の多くは,チーム開発を唱え,ソフトウエア品質をチーム一丸となって保証するための責任の明確さの必要性を強調していると思います。発注者が優柔不断な態度を取った場合,責任の所在が不明確になり,最終的にはソフトウエアの品質保証はできないことになります。満たすべき要求が明確にできないのですから。このような場合,現状では理想論かもしれませんが,発注者を“基本経営教育の必要ある組織”として分析し直し,適応する方法論をオブジェクト指向開発方法論からビジネス・モデル構築方法論などに切り替える必要があると思われます。事実,オブジェクト指向分野のカリスマ集団が創業した株式会社「豆蔵」は,教育は当然のこと,経営コンサルタント業までを視野に入れた企業活動を目指そうとしています。

 “オブジェクト指向開発方法論は,普通の人々にどのようなメリットをもたらすのか?”。このテーマに入る前の準備段階として,今回,次回の2回にわたって,オブジェクト指向開発方法論の現状を見てみることにします。

オブジェクト指向開発方法論の現状報告

 私は本連載を引き受けたとき,オブジェクト指向開発方法論の現状は今一体どのようになっているのだろうと不安になり,相当数の関連Webサイトを訪問する激務が待っていることを覚悟しました。と同時に,次のような角度から現状を観察する必要性を感じました。

・理論と実践のかい離
・ソフトウエアの部品化(コンポーネントの再利用)の流れとオブジェクト指向開発方法論の関係

 それでは,「理論と実践のかい離」という角度から収集したオブジェクト指向開発方法論に関する最新情報をご報告いたします。以降の文章を読まれる場合には,本連載で設定した視点“オブジェクト指向開発方法論はどのようなメリットを私たち普通の人々にもたらすか?”を決して忘れないようにしてください。私はこの視点を本連載の最終回まで堅持します。

理論と実践のかい離

 理論と実践のかい離現象は,オブジェクト指向開発方法論が単なる技術輸入ではなく,文化や思想の輸入という側面を持っているからではないかと思います。つまり,輸入内容を理解するために膨大な時間とエネルギーが消費されても,現実に適応できる何かを効率よく習得できないということでしょう。例えば,皆さんは次のような文章を提示された場合,どのような感想をもたれるでしょう。

An object has state,behavior,and identity; the structure and behavior of similar objects are defined in their common class; the terms instance and object are interchangeable.
(出典:Grady Booch. Object-Oriented Analysis And Design With Applications,2nd Ed. Benjamin Cummings.)

(私の解釈:Identityは「自分自身であることを証明する内容」という意味を持ちますから,オブジェクトを定義する作業はその意味の検出を意味します。この検出作業は専門用語ではクラス抽出と呼ばれ,オブジェクト指向開発者の素質が問われると言われます。オブジェクトとインスタンスは入れ替え可能と明示されています。また,類似オブジェクトの構造と振る舞いは共通のクラスとして整理できるとも述べています。このあたりは,専門用語では汎化と特化といわれているようです)

We define an object as a concept,abstraction or thing with crisp boundaries and meaning for the problem at hand.
(出典:James Rumbaugh ,et al. Object-Oriented Modeling and Design. Prentice Hall)

(私の解釈:目前に発生している問題へのソリューションを必死で探している人向けのアドバイスと取ると便利かもしれません。単なる抽象概念ではあっても,その役割を明確にして「オブジェクト」として定義すると便利な場合もある,と述べているようです)

Approach to identifying objects through use-cases (scenarios),leading to a use-case driven design.
(出典:Ivar Jacobson,et al. Object-Oriented Software Engineering - A Use Case Driven Approach. ACM Press/Addison Wesley)

(私の解釈:オブジェクトを見つけ出す場合,具体的なシナリオ(シミュレーション)を描き,その本質を見つけ出すとよい,というアドバイスのようです。直訳すると,ユースケース駆動設計という表現が使用されていますが,オブジェクトの本質を見つけた後のことでしょう。オブジェクトの本質に応じて,その構造と振る舞いが決まると思います)

 これら3種類の文章はオブジェクト指向開発方法論の歴史では必ずといっていいほど言及されるGrady Booch氏,James Rumbaugh氏,Ivar Jacobson氏が用意したものです。Object,State,Behavior,Identify,Class,Concrete,Abstraction,Instance,User-Caseなどという用語が入り乱れ,彼らの真意を理解するためには,相当の時間が必要であることが分かります。

 上にあげた3つの文章を理解しようと悪戦苦闘しているときにも,仕事依頼は到着します。普通の人々がその仕事の発注者となった場合,彼らはWebサーフィンで30分前に仕入れたばかりのオブジェクト指向という用語を,契約の会議の席で次のように持ち出してくることも考えられないことではありません。また,発注者はその権利は有しています。

“このプロジェクトには,オブジェクト指向開発方法論を採用してほしいのです”

 日常的にWebサーフィンを楽しむ普通の人々は,高品質の拡張性に優れたソフトウエアを開発するならオブジェクト指向開発方法論,というスローガンをどこかで目にしているものです。文化や思想は短時間で習得できません。結論としては,契約の場に重々しい空気が流れることになるでしょう。この空気こそ,理論と実践のかい離の本質ではないかと思います。

 それではここで多少角度を変え,オブジェクト指向開発方法論の1つであるUnified Process(現在適切な訳語がないため,英文表記をそのまま使用します)を提唱している米Rational Softwareの現状認識を見てみましょう。ちなみに,上に紹介した文章を書いたBooch氏,Rumbaugh氏,Jacobson氏は,いずれもRationalで活動しているといわれます。RationalのWebサイトには,Rumbaugh氏の最近の発言が公開され,同氏はその中で次のような現状認識を示しています。

・インターネットの時代の特徴は,分散(distributed),要求の同時多発(concurrent),and 相互接続(connected)である
・開発経費は膨れ上がり,開発すべきシステムは予想を越えるほど複雑になっている
・結果的に,要求があいまいになり,品質の高いソフトウエア開発の最大の障害になっている

 多少私の方で整理していますが,本質は把握していると思います。 詳細を確認したい方はこちらを閲覧されてください。この現状認識は普通の人々も先端開発者もそれほどの苦労もなく,しかもかなりの実感をもって理解できるはずです。しかし,“要求があいまい”になっているという認識項目への理解度にはかなりの温度差があるのではないか,と思われます。

 “要求があいまい”という状態は,発注者と受注者に好ましいことではありません。解決すべき問題がはっきりしていないからです。開発プロセスを開始する前に,要求のあいまいさを整理する作業が必要になります。この作業では,どのようなプログラミング言語を採用するか,あるいは,どのようなOSを採用するか,などはそれほど重要ではないことがはっきりしています。要求のあいまいさの整理作業が,発注者の参加なくしては不可能であることは,だれの目にも明らかです。発注者が“普通の人々”の場合,先端開発者がオブジェクト指向開発方法論を支える高度な専門概念を持ち出しながら,彼らと会議することは望ましいことではありません。そのような場合,彼らの協力を得ることができないという悲劇さえ生むでしょう。ここではコミュニケーション・スキルが重要になりますが,オブジェクト指向方法論では“絵”を描きながら,要求内容を明確にする作業を推奨しています。最初は,普通の人々にも理解できる単純な絵から描き始めることになります。先に紹介したRumbaugh氏は“あいまいな要求”時代の解決策として次の5つの解決策を提案しています。

・modeling before construction(モデル化を行うこと)
直面している問題を単純化して絵に描く,と考えるとよいでしょう。

・architecture based on experience(経験に基づくアーキテクチャの構築)
普通の人々の視点に立つと,開発者の経験を重視することを意味します。開発者側からすると,経験を積むための社内環境であったり,オブジェクト指向開発方法論を学習できる社内風土が重要である,といえるでしょう。

・a process based on best practices(現時点でもっとも有効な開発パターンの採用)
最新事例や各種実装基盤(プログラミング言語も含む)の研究を怠ることなく,自分たちの開発方法論を構築することの重要性を指摘しているのではないかと思います。発注者の視点に立てば,発注先選定の重要な基準になるのではないかと思います。

・building with reusable components(再利用可能なコンポーネントの採用)
今CBD(Component-based Development)という用語があり,コンポーネントを積極的に採用して,開発効率を改善するとともに,将来の要求変更にもタイムリーに対応しようとする動きがあります。これは基本的に普通の人々目には入らない項目かもしれません。どちらかの言えば,技術詳細の一部にはいるのではないかと思います。この項目は,次回以降普通の人々の視点から具体的に説明することになっています。

・use of tools to leverage the developer's time and skill(適切なツールの採用)
絵を書くツールであったり,ソース・コードの一部を自動生成してくるツールを採用することを強調していると思います。“要求があいまい”の時代は,あるとき突然,新たな要求が発見される開発者にとっては物騒な時代であることも意味します。そのような場合,要求項目管理を自動化しておくことが重要といえるでしょう。

 初歩的な絵の描き方を含めて,開発手順を整理し,1つの言語として体系化したものの代表に,UMLといという言語があります。UMLはUnified Modeling Languageの略称です。言語といってもプログラミング言語ではありません。絵を描くときの約束事であると考えておいて下さい。太陽と月を描いた場合,その区別がつかないようでは困ります。私たちは常識に従って描いているものです。「一体この絵は何?」という問いが発するようでは,ビジネスが効率的に動きません。

 UMLはRationalが開発し,1997年1月にUMLバージョン1.0として標準化団体であるOMG(Object Management Group)に提出され,同年12月にUMLバージョン1.1が標準モデリング言語として正式承認されたと言われます。オブジェクト指向方法論の歴史はすでに25年以上あるといわれますから,それに比べればUMLの歴史はそれほど長いものではありません。また,Javaが1995年5月に発表され,同年8月にはWindows 95が発売されています。そして今,米Sun MicrosystemsのEnterprise JavaBeans(詳細はこちら参照)や,米MicrosoftのCOM(詳細はこちら参照)などの再利用コンポーネント技術が提唱され,モデリング(現時点では,現実のビジュアル表現と考えておいて下さい)言語としてのUML仕様もその影響を受けないはずはありません。明日は,次の議論であるソフトウエアの部品化とオブジェクト指向開発方法論に移りたいと思います。ごきげんよう。