*begin *back *foward *end *contents

開発サイクル編

第９章　Drop開発サイクルの考え方




９．１　開発サイクルの諸問題

　オブジェクト指向開発をどのように進めていくかという戦略を示すモデルのことを開発サイクル（または開発サイクルモデル）という。オブジェクト指向開発のおける開発サイクルは、従来の主流であった「ウォータフォール型」から「反復開発」「ラピッド・プロトタイピング」といった開発サイクルに移り変わろうとしている。しかし多くの方法論では、開発プロセスの欠如しているため、実際の開発サイクルを構成するフェーズで何をすればよいかが明確でないものが多い。具体的にいうと「どんなドキュメントが必要か」や「どんな観点でモデル化を図るか」などが解説されていない。そのため、開発システムの工程管理が困難になりやすいという問題がある。Dropの開発サイクルでは、この問題を解決するため、チームごとに明確な開発サイクルを開発プロセスの一環として定義していることが特徴である。


９．２　２つの開発サイクル

　第６章で述べたように、Dropでは、システム開発と再利用の促進という問題を区別し、それぞれにチームを割りつけている。ADGはシステム開発を円滑に行うためのチームであり、ODGは再利用可能なコンポーネントを開発するためのチームである。開発プロセスにおいても、この２つのチームをベースとした２つの開発サイクルを持つというフェーズ戦略を展開する。

コンポーネント開発サイクル....ODG主体の開発サイクル
システム開発サイクル....ADG主体の開発サイクル

　２つの開発サイクルは、システム開発によって同期を取りながら進んでいくこととなるが、それぞれの開発プロセスのライフサイクルとそのスタイルには基本的な違いがある。

主体となるチームライフサイクルスタイル
コンポーネント開発サイクルコンポーネント開発（ODG）チーム再利用クラス開発に依存積み上げ反復
システム開発サイクルシステム開発（ADG）チーム開発対象に依存カスケード・ウォータフォール

表9-1　　２つのチームの開発サイクル




９．３　Drop開発サイクルの原型

　ここでは、Dropで採用した開発サイクルのスタイルについて、その基本モデルとなった開発サイクルの特徴と、なぜDropがその開発サイクルを採用したのかという理由を解説する。

* 積み上げ反復（コンポーネント開発サイクル）

　積み上げ反復とは、ソフトウェアを小さな増分(increment)の積み重ねにより組み立てる方法である。新たに増分されるものは、それだけでも十分利用可能な機能を有するものであり、それを積み木のように積み上げていくアプローチである(機能を限定したものを段階的に拡張・変形するアプローチではない)。
　この開発スタイルは、再利用コンポーネントの構築プロセスに最適なサイクルである。なぜなら、再利用コンポーネントは、パッケージ(利用される単位に再利用コンポーネントをグループ化したもの)を単位として、序々に積み上げ拡張するからである。従来の手法(非オブジェクト指向)では、新規の増分を融合する際、技術的な問題があった。それは、ソフトウェアを小さな増分(部品)としてまとめるための手法と実装技術がなかったためである。非オブジェクト指向の開発では、データと機能を別々にモデル化し実装しようとした。一方、オブジェクト指向では、データと機能をカプセル化する技術や、似たような構造を組織化するクラスと継承などの技術により、積み上げ反復は部品構築の領域に採用できるようになった。

sorry this is image

図9-1 積み上げ反復



* カスケード・ウォータフォール（システム開発サイクル）

　カスケード・ウォータフォールとは、従来のウォータフォールモデルの欠点を補うために、それぞれのフェーズが重なり合うことができるように改良したものである。このモデルは、「前フェーズが完了しなくとも後フェーズを並行して行うことができる」と定義することで、適度な柔軟性を導入する。それによって、ウォータフォールモデルから以下の長所を継承しつつ、前フェーズの遅れによる作業の停滞を解消できることや、フェーズ間を行き来しやすい構造をもたらす。

　この開発スタイルは、ADGによるシステム開発のサイクルに適している。システム開発には、システム範囲の決定、それに対する開発コストの見積もり、エンドユーザの承認獲得というプロセスがある。その中では、段階的でかつトップダウンの決定、それに対する作業を必要とされることが多いからである。そこに、ウォータフォールの長所が活かされる。
　このようにカスケード・ウォータフォールは、ウォータフォールモデルに対してフェーズ同士が重なり合うことができるという改良を行ったものである。しかし、カスケードするだけでウォータフォールの問題点が解決されるという単純なものではない。カスケード・ウォータフォールの初期フェーズの進捗をスムーズにするために、プロトタイプ開発という特効薬が必要とされる。

sorry this is image

図9-2 カスケード・ウォータフォール




* プロトタイプ開発

　プロトタイプ開発は、Dropの開発サイクルの一部として開発フェーズの中に組み込む形で使用される。開発フェーズの中で、プロトタイプを目的に応じて計画的に使用することで、システム要求の決定を早めたり、実現可能性の早期検証を即したりすることが可能となる。詳しくは「第１２章　プロトタイプ開発の利用」で述べる。



９．４　Dropの開発フェーズ戦略

　開発サイクルはフェーズによって構成されている。DropのADG、ODG開発サイクルを構成するフェーズの基本は図9-3のように「分析」-「設計・実装」-「テスト・評価」というように分けられる。このフェーズ分類の考え方は、「開発サイクルの中でフェーズとして分類しやすい箇所」を見つけて、そこを進捗管理のチェックポイントとすることである。
　古いDrop(version1.0)では、設計と実装が分類されていたのであるが、実際の運用ではなかなか設計と実装を分離できなかった。また、実装中にテストをするという意味で実装とテストが同一フェーズとなっていたが、これは基本的に実装とテストをフェーズとして分けるべきであった。
　このような理由で、新しいDrop(version2.0)は、フェーズの分類を改良することにした。さらに、テストフェーズの中に評価を設けることにした。これによって、システム開発やコンポーネント開発の成果物に対して、様々な観点で評価する期間が設けられることとなる。この評価を取り入れたことは、今後のDropの発展において重要なものである。なぜなら、この評価期間を使ってオブジェクト指向開発の様々なメトリクスを収集し統計を取れば、ソフトウェアの生産性を図るメトリクスを持つことができるようになるからである。しかしながら、Drop version2.0は、このようなソフトウェアメトリクス持っている方法論ではない。Drop version2.0では、その前段階として「テスト・評価フェーズ」を設けることにした。


sorry this is image

図9-3 Dropの開発工程戦略




９．５　Dropにおける並行開発サイクルの必要性

　Drop開発サイクルは、システム開発サイクルとコンポーネント開発サイクルで構成され、同時並行的に流れるコンカレントな開発サイクルである。この開発サイクルは、以下の明らかに異なる視点に対して、それに伴うフェーズ戦略が必然的に必要とされるものである。

　従来のオブジェクト指向方法論のほとんどは、これら２つの問題を区別しないまま開発プロセスを述べている。それは、分かりやすい開発プロセスという利点はあるが、オブジェクト指向によるソフトウェア開発の本質から外れるものである。オブジェクト指向技術による開発は、誰もが上記の２つの視点を持つ必要がある。しかし、従来の方法論ではそれをサポートする枠組みがないため、それぞれの相反する特徴が相殺され、そして阻害しあうのである。その結果として従来（非オブジェクト指向手法）よりも悪い結果を引き起こしてしまうこともありうる。
　それぞれに適した開発サイクルを採用し、それを並行して運用することにより「システム開発を成功に導き、企業内の再利用コンポーネントを計画的に構築できる」というオブジェクト指向技術の恩恵を受けることが初めて可能となる。


９．６　ソフトウェア開発形態とDrop開発サイクル

　ソフトウェアの開発形態は表9-2、表9-3に示すように「契約主導型」と「発想主導型」という２つの形態に分類することができる。これは「契約の遵守」と「発想の具現化」のどちらに開発プロジェクト全般の意志決定行為が主導されているかという違いによって分類したものであり、契約主導型に、発想によるソフトウェア構築が必要とされないということではない。
　筆者の考える理想のソフトウェア形態像は、両者を融合させてその長所だけを生かしたものである。
　なぜなら、受注ソフトにも、その内容によってはソフトウェアに求められる要求が従来の契約主導型のようにすべて初めから分かっているものではないものもあり得るからである。
　しかしながら、現実的には、開発責任者（管理者）は、開発内容が、この２つの開発形態のどちらに重きを置くべきタイプなのか判断しておく必要がある。よって、Dropでは、下記のように２つの形態に合わせた開発サイクルを提唱する。

契約主導型開発サイクル「第１０章　開発サイクルの基本形」の１０．２　契約主導型開発サイクル
発想主導型開発サイクル「第１１章　開発サイクルの応用形」の１１．１　発想主導型開発サイクル


　
形態例説明特徴
契約主導型受注開発
製品開発		ソフトウェア開発が、他社との契約行為によって始められる。約束された開発期間、約束された開発内容が何よりも重視される。ソフトウェアの品質は要求定義に定めた約束事に沿って評価される。詳細な要求定義がなされ、開発依頼側と合意してから開発に取り組む。実績のある技術が採用される傾向がある。
発想主導型研究開発
製品開発		ソフトウェア開発の動機が、個人または複数人のアイデアを実現することから始められる。ソフトウェアの価値は、アイデアをソフトウェアとして具現化できるかである。なお、具現化とは、研究開発の場合は研究目的の達成であり、製品開発の場合は市場を獲得することである。ソフトウェアの改良・改善のための試作開発を繰り返し、同時に市場の要求を吸収していくことで、最終的に完成されたソフトウェアを目指す。最新技術を採用される傾向がある。

表9-2　　ソフトウェア開発形態



形態項目内容
契約主導型長所
  • 開発当初より、開発依頼側と開発側の中で、開発期間や開発内容が明らかにされるため計画的なソフトウェア開発が可能になる。
  • 実績のあるソフトウェア製品を利用することで、生産性を安定させ、工数や期間算定が容易になる。
  • 計画的なソフトウェア開発をこなせるソフトウェア開発チームを育てやすい。
短所
  1. 開発内容に対する約束が初期フェーズで行われるため、開発内容に対する評価（本当に有用か？）が疎かなままプロジェクトが進行してしまいがち。
  2. 新規分野の開発に対して弱腰になりやすく、すべてが先に予測できない問題に対して適した対応が取りにくい。
  3. プロジェクトの進行に柔軟性がなく、長期間のプロジェクトでは時代の変化に追従できないことが多い。
対策
  1. プロトタイプ開発を使って、未知の問題を初期段階にてクリアにする。
  2. 新規分野の開発では、開発依頼側を巻き込んで、発想主導型的開発を応用できるよう意識改革を図る。
  3. 長期にわたる開発では、開発フェーズを最長半年毎に区切り、契約面、工数、期間、開発内容を見直すことで、環境の変化に対応できるよう柔軟性を持たせる。
発想主導型長所
  • 開発当初は、プロダクト成果に対する明確な約束などはなされず、いくつかのアイデアをソフトウェアに具現化することだけに集中できる。
  • チーム全体の雰囲気が、新規分野へチャレンジする好奇心と遊び心に旺盛で、アイデアの具現化の過程で新たなアイデアを見つけることも多い。
短所
  1. 個人の力量に頼る傾向があり、個人の能力や、やる気にプロジェクトが左右されやすい。
  2. プロダクトのゴールを見定めたプロジェクト運営が難しい。
  3. 計画に柔軟性があるだけ未計画になりやすい。
対策
  1. 個人能力重視の組織体制、報酬制度、社員の意識改革が必要とされる。
  2. 個人の能力を最大限発揮しながらも、チームとして統制を取っていける管理能力を持った人材が必要とされる。
  3. 発想主導型にも開発フェーズを導入する試みが必要。(これがDropの試み)

表9-3　ソフトウェア開発形態の長所・短所、短所に対する対策





*begin *back *foward *end *contents