*begin *back *foward *end *contents

コンセプト編

第３章　オブジェクト指向開発の考え方(映画撮影のように）




３．１　オブジェクト指向は映画撮影のように

　本章は、オブジェクト指向によるソフトウェア開発プロセスの理解を深めるために、映画を撮影するプロセスと比較しながら解説する。しかしなぜ、ソフトウェア開発の比較材料が映画撮影なのだろうか？
　その理由は、映画撮影のプロセスとオブジェクト指向開発プロセスには非常に多くの共通点を見いだすことが可能だと考えたからである。 素人が考えるレベルの映画撮影プロセスは、映画やドラマを見た人であれば誰もが想像できるだろう。 誰でもイメージしやすい映画の撮影プロセスを解説しながら、それをオブジェクト指向開発のプロセスと比較することで、オブジェクト指向開発プロセスの必要性や本質について理解を深めることができるのでは？と考えて、この章をコンセプト編に設けることにした。
　ここで言う開発プロセスの本質とは、Dropにおける開発プロセスの基本となるものである。 よって、この章の目標は、Dropの開発プロセスを映画の撮影プロセスを使って解説することで、Drop開発プロセスの必然性を理解してもらうことにある。


sorry this is image

図3-1　ソフトウェア開発と映画撮影





３．２　映画撮影プロセスとソフトウェアプロセス

　映画撮影のプロアセスは、映画監督を始めとする大勢の人たちの共同作業となる。それは、創作的な活動でありながらも、工業生産的なプロセスが必要とされるものだろう。
　ソフトウェア開発においても同じことが言える。ソフトウェア開発の管理者が、ソフトウェアを単なる工業生産的な尺度でしか計れないとすれば、その開発は現実に即さないものとなる。逆に、創作活動とだけ見なしてしまうと開発工程を管理することなど到底できないものとなる。
　このように、映画撮影のプロセスとソフトウェア開発プロセスには、創作活動と工業生産活動とをうまくバランスを取りながら進めていかなければならないという共通点がある。そしてこの共通点の本質には、「実世界の問題を対象に、仮想の世界を、大勢の人間が協力して計画的に創作する」という開発プロセスが存在している。つまり、「仮想の世界を創作する」ことが創作活動的であり、「大勢の人間が協力して計画的に」という部分が工業生産活動的なのである。
　ソフトウェア開発プロセスにおいては、この「創作活動」と「工業生産活動」という二面性をしっかりと把握しなければならない。 そして、それぞれを活かすためには「創作活動」の中から「工業生産活動」が可能な部分をできるだけ抽出し、そこに形式的なプロセスを導入することが重要な課題なのである。
　Dropは、ソフトウェア開発プロセスにおいてまさにこの課題をクリアすることを目指している。


sorry this is image

図3-2　創作活動と工業生産活動




３．３　映画撮影のプロセス

　映画撮影では、映画監督がストーリとコンセプトを決め、そのストーリにあったシーンを創造し、そのシーンに適した登場人物を決めなければならない。 また、それ以外に、撮影場所の選定、撮影方法、テスト撮影、登場人物に合った役者などを選定するという仕事もある。 このような仕事は、映画監督一人では全てを掌握できない。 よって、複数の助監督に適切に仕事を振り分けることになるだろう。 また、作業を振り分けられた助監督は、それぞれの担当者に作業を割り振ることになる。
　図3-3は映画撮影のプロセスにおける監督と助監督の作業分担を示している。 この図のように、一度分担が決まれば、それぞれの仕事は同時並行的に進めていくことができる。


sorry this is image

図3-3　映画撮影のプロセス




３．４　映画撮影 vs オブジェクト指向開発

監督の作業　vs　分析者の作業

　映画監督の作業とシステム分析者の作業を比較したものを図3-4に示す。 両者とも、作成対象に対して「何を（ストーリ）作る」ということを明確にしなければならない。 そして、それをベースに「どのように（シーン）」と「誰が（登場人物、要求オブジェクト）」を定めていくことになる。
　映画における登場人物は、映画監督が描く概念的な人物であり、その人物を演じる上で理想的な俳優を想定したものである。 同様に、ソフトウェアにおける要求オブジェクトとは、実装上のオブジェクトに割り付けられているわけではなく、システム要求を実現する理想的な「概念オブジェクト」である。 このようにシステム要求を前提とした概念的なオブジェクトをモデル化したものをDropでは要求モデルと呼ぶ。また、要求モデルによって作成されるオブジェクトのことを「要求オブジェクト」と呼ぶ。
　ここで重要となる点は、ソフトウェア開発にはなんらかの明確な要求に基づく要求定義が必ずあるということだ。それは「あなたが映画監督になって映画を作るとしたら最初に何をやるか？」と考えると理解しやすい。かならず、映画のストーリやコンセプトをしっかり考えるはずだ。ソフトウェアも映画と同じように明確な要件定義や前提条件（映画のストーリとコンセプト）を定める必要がある。
　「そんなことは、当然なのでは？」と思われる人も多いだろうが、実は要求定義を明確にせずに失敗するソフトウェア開発は、結構多いのである。オブジェクト指向開発では、オブジェクトモデリングだけに気を取られてしまい要求定義が明確になされないといった、落とし穴にはまることがよくあるのだ。
　このような状況を映画にたとえると、登場人物だけを決めて映画のストーリを定めていないことに等しい。オブジェクト（映画の登場人物）は、開発システムを実現する登場人物であり、それは要件定義（映画のストーリ）がなされないかぎり対象の開発システムにおいて存在価値などないのである。


sorry this is image

図3-4　監督の作業　vs　分析者の作業




助監督の作業　vs　設計者の作業

　助監督の作業とシステム設計者の作業を比較すると図3-5のようになる。この作業の観点は、実現方法を定めることにあり、下記のように大きく３つに分類できる。






sorry this is image

図3-5　助監督の作業　vs　設計者の作業




撮影作業　vs　アプリケーション実装・テスト作業

　実際に映画を撮影する際には、俳優の他にエキストラが必要となる。映画は、数人の俳優だけで作れるものではない。俳優とエキストラをうまく活かしながら映画全体の調和を取り、映画監督がイメージする世界を実現する。
ソフトウェア開発においても、アプリケーションに特化する問題領域をソフトウェア化するためのクラスを開発しなければならない。これらのクラスをアプリケーションクラスと呼ぼう。
　エキストラの中には、演技の優秀さを見いだされ映画俳優になってしまう人もいるだろう。ソフトウェア開発においても、アプリケーションクラスが汎用的なコンポーネントに変化することも起こりうる。
　しかし、自然にエキストラが映画俳優に、アプリケーションクラスが汎用的なコンポーネントに変化するということではない。素質のあるエキストラは、映画監督にその素質を見いだされたとしても、監督が育てることはないだろう。映画学校などで徹底的に訓練を受け、自らも努力を重ねることで、初めて映画俳優の切符を手に入れるのである。同様に、アプリケーションクラスに若干の汎用性が多少あったとしても、すぐコンポーネントになるわけではなく、コンポーネントとして、さらなる改善を受け洗練されて、初めてコンポーネントとなるのである。
　つまり、コンポーネントの中には再利用要求が初めから明確でトップダウンによって設計されるエリートコンポーネントもあれば、アプリケーションクラスから汎用性を持つよう洗練・改善を繰り返しながらボトムアップにアプローチで再設計される、たたき上げコンポーネントもある。
　また、この解説で最も注意すべき点は、映画におけるエキストラをソフトウェアにおけるアプリケーションクラスと表現している点である。
　これは、アプリケーションに特化するクラスの位置付けが映画のエキストラ程度の重要度しかないということでは決してない。むしろソフトウェアにおいてアプリケーションクラスは問題領域の要求に密接に関係する非常に重要なクラスであることが多い。つまり、開発するアプリケーションの立場から考えると、アプリケーションクラスは主役ということになる。しかしながら、コンポーネント化（部品化）できないアプリケーションクラスは、開発対象のソフトウェアにおいてのみ有用であるため、そのようなアプリケーションクラスの性質の１側面を持ってエキストラに例えている。


sorry this is image

図3-6　撮影作業　vs　アプリケーション実装・テスト作業




３．５　２つの観点とその並行性を考える

　いままで解説した映画撮影とソフトウェア開発の類似性を前提にしながら、それぞれに必要となるプロセス（作業）の並行性と観点について、いくつか考察してみよう。これにより、ソフトウェア開発に本質的に必要となる「様々な観点」と「開発プロセスの並行性」について理解することができる。


アプリケーション開発とコンポーネント開発の観点

　まず映画作りと俳優の関係について考えてみよう。俳優は映画作りのプロセスとは独立して育つものである。実際の俳優の中には、映画と共に成長する場合もあるかもしれないが、基本的には、映画作りとは独立した個人としてのライフサイクルを持っている。よって、以下のような質問はすべてＮＯと言える。

映画撮影と俳優

  • 登場人物を定めてから俳優を育てるだろうか（NO）
  • 監督は俳優を育てるということに全力を注げるだろうか(NO)　　　　　　　　　　　　
  • 優秀な俳優を集めるだけで優れた映画が作れるだろうか(NO)　　　　　　　　　　　　


このことをいままで映画撮影と対比してきたソフトウェア開発の言葉で置き換えてみると以下のようになる。

アプリケーション開発とコンポーネント開発

  • 要求オブジェクトを定めてから再利用コンポーネントを開発するだろうか？(NO)
  • 開発マネージャーは再利用コンポーネントを育てることに全力を注げるだろうか？(NO)
  • 優秀なコンポーネントを集めるだけで優れたアプリケーションが作れるだろうか？(NO)

　上記は「アプリケーション開発とコンポーネント開発には、それぞれ異なる観点を持つ必要がある」ということと「アプリケーション開発とコンポーネント開発は、開発サイクルが異なり並行的に開発することが必要である」ということを表している。Dropは、この２つの観点のことを、ADG(Application Development Group)とODG(Objects Development Group)と呼ぶ。 Groupと記している意味は、２つの観点をまずは１人の開発者が持つことからスタートし、徐々にそれぞれの役割に特化した人間を育成し、 何れはADG、ODGという２つのチームによる並行開発へと段階的に発展を遂げることを、Dropの提唱する組織戦略としているからである。


sorry this is image

図3-7　アプリケーション開発とコンポーネント開発の並行作業




分析と設計の観点

　映画監督は、映画を効率的に仕上げるために、助監督との共同作業を行うだろう。その作業の中で、監督がすべての映画のストーリとシーンを定めるまで、撮影場所や撮影方法を考えないということはナンセンスであり、できるかぎり並行して作業を進めるだろう。
　ソフトウェア開発も同様に、すべての分析が完了しない限り、システム構成やアーキテクチャ設計を行わないということはナンセンスである。しかしながら、分析ありきということは当然ともいえる。
　そもそも、分析・設計というものは「ソフトウェア工学的な工程」と「視点」という性質を合わせ持っている。このことを開発者は頭においておかねばならない。 つまり、分析をして設計をするといった工程として両者を捕らえることと併せて、分析的視点と設計的視点という2つの視点で問題領域を観察し構築する習慣が常に必要だということなのである。



sorry this is image

図3-8　分析と設計は視点でもある




プロトタイプと分析・設計の観点

　映画撮影は、ストーリのイメージを検証・洗練するために幾度もテスト撮影を行うだろう。ソフトウェア開発においても同様に、システム要求の妥当性や構築法の検証を行うことで、開発フェーズの早期に問題点を発見したり洗練させたりするためにプロトタイプ開発を行う。プロトタイプ開発は、「分析・設計」結果を検証し洗練するために、「分析・設計」と同時並行的に行うべきプロセスと考えることができる。



sorry this is image

図3-9　プロトタイプ開発は「分析・設計」結果を早期に検証し洗練させる




３．６　Dropにおける分析の考え方


分析における観点

　映画監督は、映画の題材を探すために実世界のある出来事を分析する。 また、その出来事を分析した結果に対して新たなアイデアを加え映画としての理想像を考えるだろう。そして、それを基に、現実的な撮影技術や予算に応じた作成が可能なレベルに対象を落とし込むだろう。 ソフトウェア開発も同様に、以下のような作業を行う。
　もし、これら分析的な行為を、分析という言葉でひとくくりにして、その違いを曖昧にしていたらどうなるだろうか？
　その結果は、現状理解の為のモデルからそのまま設計に進んでしまったり、理想的なモデルである戦略モデルを、期間と要求を加味せずに設計に落とし込むようなミスを犯してしまったりすることになるだろう。
　これらは、同じ分析行為であっても明らかに分析対象が異なっており、分析する観点も異なっていることに注意しなければならない。
分析する際に、常に頭の中で「認識」「戦略」「要求」の違いを区別し、モデリングを進めることが重要なのである。
　Dropの開発フェーズの問題領域分析では、「要求モデル」を抽出することから始める。


ODGにおける分析作業

　ソフトウェア開発において、分析は問題領域の本質だけを対象としていることが多いだろう。 しかしながら、Dropでは、コンポーネント開発という新たな視点を持つODGがある。 よってODGでも分析が必要となる。 ODGの分析は「コンポーネント分析」と呼び、再利用資産を構築するために保守対象の現状を把握し、戦略的な計画を立て、コンポーネント開発の範囲を決めることをいう。






*begin *back *foward *end *contents