*begin *back *foward *end *contents

プロジェクトチーム構成編

第６章　Dropのチーム構成




６．１　Dropチーム構成における基本的なコンセプト

　Drop方法論は、以下の２つの目標をチームのゴールとして定める。
　この２つの目標は、「第１章　Drop構成用語集（オブジェクト指向用語編）」で解説したように、ADGとODGという「技術者の持つ２つの観点」または「２つのチーム」によって支えられるものである。

ADG(Application Development Group)
  • チーム目標.... 開発システムを期間中に要求どおりのものとして完成させる
  • 要求される責務.... アプリケーションの仕様に責任を持つ
  • 要求される視点.... システムの境界を定める。
  • 要求される知識と技術.... 対象システムの専門知識を持ち、システムを構築する技術を持つ。
ODG(Objects Development Group)
  • チーム目標.... ソフトウェア資産としてのクラスライブラリを成長させる。
  • 要求される責務.... コンポーネントの仕様に責任を持つ
  • 要求される視点.... コンポーネントの境界を定める
  • 要求される知識と技術.... ソフトウェアプラットフォームに対する専門知識やコンポーネント構築技術を持つ。


６．２　オブジェクト指向による思考方法とチーム構成


　オブジェクト指向技術の根底部分には、開発者に対して、再利用性を考慮させる思考を強いるアプローチを備えている。 このことを無視するような技法や、意識できないチーム構成は、分析・設計フェーズにおいて多くの無駄を作ってしまうことになる。 オブジェクト指向を採用するかぎり、再利用性の向上をシステム開発とは別の観点として進めるべきであり、そうでないものはオブジェクト指向の分析・設計過程に含まれる潜在的な再利用性に対する思考コストが一切無駄となるばかりか、システムの品質まで悪影響を及ぼすことにもつながる。 Dropのチーム構成アプローチは、オブジェクト指向の特徴を十分に活かすために、再利用性を高めるための観点(ODG)を持つことによってこれを解決するものである。ODGは、コンポーネントを構築し管理するという、いわゆるライブラリアンの役割も受け持つ。
　Dropのチーム構成を計画的に発展させることにより、ADGとODGはそれぞれチームとして独立した存在となる。図6-1はDropチーム構成における発展系を示す。図のように、ODGは１つ以上のADGの再利用コンポーネント開発を担当するようになる。

sorry this is image

図6-1 Dropで目標とするチーム構成




６．３　システム開発の現状からみたチーム構成

　複雑化した大規模システムでは、システム要求や仕様の把握、決定のために大きな労力が必要とされる。 さらに、実装技術についても、開発環境が複雑化することで、非常に専門的な知識が必要とされている。
　このような仕様の複雑さと実装の複雑さという２つの困難を克服しながらプロジェクトを円滑に進めるためには、 「システム境界を定める」ことと「オブジェクト境界を定める」という２つの異なる観点（またはチーム）を持つことが重要となる。
　そこで、再利用資産を構築できる専門家集団(ODG)の存在が重要となる。 ODGが存在することによって、ADGは問題領域の要求分析や仕様の把握に集中できることになり、ADGも短期間で高度なシステムを構築する専門家になることができる。
　ソフトウェア開発における外的要求(要求された機能を期間通りに作成する)を満たすチーム(ADG)と内的要求(再利用性や保守性を高める)を満たすためのチーム(ODG)という構成は、オブジェクト指向分析・設計で陥りがちな下記のような問題を解消することができる。


　Dropによって、ソフトウェア開発にADGとODGの視点を導入することで、「システム境界を明確にしながら」、同時に「再利用コンポーネントを構築する」という、相反する２つの目標を同時に持つよう開発者の意識改革がなされるのである。 ADGとODGの共同作業イメージを図6-2に示す。ADGは、システム要求を明確に固め、その中から要求に適合する概念的なオブジェクトを抽出する。 このように問題領域分析フェーズで作成されるモデルを要求モデルという。 ODGは、ADGとは独立した次元で、ADGの要求をODGの再利用基盤モデルに写像し、そこから再利用可能なコンポーネントを抽出する。


sorry this is image

図6-2 ADGとODGの共同作業イメージ




６．４　再利用コンポーネントの早期開発

　Dropによる開発では、ODGによってシステムの開発工程の初期段階から部品化の検討が行われることになる。ODGは、システムの問題領域分析の段階から汎用的な共通部品を抽出するためにユーザやADGと共同で分析作業を行う。これによって、従来の設計工程から部品化を図る方法と比べて、部品開発の遅れを解消することになり、「部品が開発されないので、工程が進まない」や「部品の品質が悪い」といった問題を解消することができる。


６．５　プロジェクトチームのビジョン策定

　このように、ADGとODG構成はDropプロジェクトチームの基本的なコンセプトとなるものである。この考え方は、組織的に分割されていない１つのチームや１人だけの開発であっても、２つの観点で開発を行う概念的なチーム構成を計画するために摘要される。ADGやODGの観点を習得して、何れチームに発展させるには、ADGとODGについて下記のようなチームとしての明確なビジョンを策定しなければならない。このビジョン策定により、様々な意志決定におけるチームの共通指針をチームメンバに示すことができる。
　このように、Dropのチーム構成にあったビジョンをチーム全体で掲げながら、そのビジョンに向かって仕事をこなしていく姿勢を持つ集団のことをビジョン主導型チームと呼ぶ。さらにビジョン主導型チームであるためには、チーム全体としてのビジョンだけではなくチームメンバがそれぞれのチーム内での役割に応じたビジョン策定が必要となる。これについては、「第７章チームメンバの役割」で解説しよう。




*ADGのビジョン

ADG(Application Development Group)
  • チームの位置づけ
    問題領域におけるソフトウェア構築技術を有する専門家
  • チームの戦略
    開発メンバが問題領域に対して確実な知識を得るようなインフラを構築する
    ソフトウェアの要求を定め、ソフトウェアに付加価値を与えるような提案ができる人材を育てる
  • チームの目標
    開発システムを期間中に要求どおりのものとして完成させる
    開発システムをより早く、より正確に開発する
    開発システムの保守性、拡張性を高める
  • 要求される責務
    アプリケーションの仕様と実現に責任を持つ
  • 要求される視点
    システムの境界を定めようとするアプリケーション提供の視点
    ODGコンポーネントを再利用するためのコンポーネント利用の視点
  • 要求される知識と技術
    対象システムの専門知識
    システムを構築する技術
    ユーザの要求を実現可能な仕様に落とし込むための問題解決能力と交渉技術
  • 誤ったアプローチ
    コンポーネントの仕様を理解する努力をせずに、コンポーネントが使えないと主張する
    コンポーネントを使ってみようという気がない





*ODGのビジョン

ODG(Objects Development Group)
  • チームの位置づけ
    　再利用ソフトウェア資産構築技術を持つ専門家
  • チームの戦略
    企業における再利用資産を構築するためのインフラを整備していく
    問題領域の中から再利用可能な部分を抽出でき、コンポーネント設計・実装に落とせる人材を育てる
  • チームの目標
    ソフトウェア資産としてのコンポーネントを成長させる
    コンポーネントをできるだけ多くのシステムで再利用させる
  • 要求される責務
    コンポーネントの仕様と実現に責任を持つ
  • 要求される視点
    コンポーネントの境界を定めようとするコンポーネント提供の視点
    低レベルのコンポーネントを再利用するためのコンポーネント利用の視点
  • 要求される知識と技術
    ソフトウェアプラットフォームに対する専門知識
    一般的なコンポーネント構築のためのデザイン手法と実装技術
    再利用コンポーネントを構築するためのプラットフォームを分析する技術
    ADGの問題領域から再利用可能な部分を抽出するための分析技術
  • 誤ったアプローチ
    コンポーネントが使えない理由を分析しようとせず、常にコンポーネントユーザの責任にする
    コンポーネントを使ってADGの要求を解決する方法や必要となるクラス設計に対してアドバイスしようとしない





６．６　ADGとODGの責任と権限

　ADGにとって、ODGの存在はソフトウェア実装におけるよきアドバイザーであり、役に立つコンポーネント提供者である。ODGの存在により、ADGは対象システムの複雑な問題やユーザ要求について実装方法とは独立した立場でシステム分析、設計に取り組むことが可能となる。 また、ODGは、ADGの存在によって再利用ソフトウェア資産の構築ということに力を入れることが可能となる。
　しかしながら、このことは「ADGは、オブジェクト指向やソフトウェア開発についての知識は必要ない」あるいは「ODGは、対象システムにおける専門知識は必要ない」ということではない。ADGはODGに対して必要なクラスを要求し、開発されたクラスを利用するためのオブジェクト指向に対する基本的な知識が必要となる。また、ODGも対象システムにおける専門知識を得ないかぎり、ADGから要求されるクラスを理解することはできず、提案することさえもできない。
　すなわち、ADGとODGの分類は責任と権限の分類とも言える。ADGはシステムに対して責任と権限があり、ODGは再利用ソフトウェア資産に対して責任と権限があるのである。


６．７　ADGとODGの作業分担

　ADGとODGには、コンポーネントユーザとコンポーネント提供者という関係がある。
　ODGはソフトウェア資産を構築するとともにADGのサポートを行う必要がある。ODGの作業範囲は、ADGのシステム固有部分に入り込むこともあるだろう。 たとえば、１つのシステムの中で、システムに共通するフレームワークを開発する場合などは、ODGがADGのシステム要求から、フレームワークとしての仕様を定めて実装することになるだろう。 その際にフレームワークの原型だけをADGに提供することで、実際のフレームワークの構築はADGによってなされるかもしれない。
　また、ADGのメンバがクラス実装について経験が浅い時などは、ODGがクラス実装を指導し、クラスの原型となる部分を実装し手渡すことにより、クラス実装のノウハウについて教えることになるだろう。
　これらのことは、ADGとODGのメンバによる高度なコミュニケーションによって初めて成立するものである。 Dropでは、開発フェーズの中でいくつかのワークショップを開催する。 ここでは、システムを共同で開発するために円滑なコミュニケーション促進が図られ、ADGとODGの作業範囲が明確にされる。


*begin *back *foward *end *contents