長瀬嘉秀のソフトウェア開発最新事情（2） 長瀬嘉秀 テクノロジックアート 2003/1/25

ソフトウェアの開発手法を巡る動きが活発化している。ウォーターフォール型開発手法の神話はすでに崩れ去ったと言ってよいのだろうか？ 反復型開発手法の雄「RUP」は果たして定着するのか？ アジャイル開発プロセスの思想が、一時期のブームに終わってしまう可能性はないか？ 開発手法を巡るさまざまな潮流の観察者がおくる連載コラム。（編集局）

第2回 「開発方法論」と「開発プロセス」

　今日、オブジェクト指向を活用したソフトウェア開発手法が開発現場の主流になりつつある。“オブジェクト指向開発”という言葉を使うとき、多くの人はUMLを分析段階でのモデリング言語として採用した開発方法論を思い浮かべるだろう。確かに、UMLを採用した開発方法論の認知度は日進月歩で向上しているのがよく分かる。書籍売り場の「開発」コーナーに行けば、“UML”や“オブジェクト指向”の言葉がまさにはんらんしているのを目にすると思う。だが、これらの言葉が象徴するのは、あくまで開発方法論であることに気付いている人がどれだけいるだろうか。特にこれからオブジェクト指向を学ぼうとする人々の大半は、そのことに気付いていないかもしれない。実際に開発を行う場合、開発の全体を貫く一本の柱として、開発方法論は重要な位置を占めるのだが、開発手順としてのプロセスが存在しなければ、作業を進めることは不可能である。開発方法論と開発プロセス、この2つの違いについて、まずは説明しよう。

　開発方法論には、例えば、Unified Process（UP）やComponent Based Development（CBD：コンポーネントベース開発）などが挙げられる。開発方法論は、開発の技術的な側面やテクニックであり、プロジェクト管理などは扱っていない。詳細についても、書籍やWebサイトで情報を得ることができるし、トレーニングやコンサルティング・サービスを提供する企業も存在する。

　一方で、開発プロセスについての明確な解説情報は、実はほとんどないのが実情である。先ほど、開発プロセスとは開発作業の手順だと述べた。つまり、どのように作業を行っていくかという規範を示したものである。開発方法論が開発にかかわる領域を包含するのに対し、開発プロセスはコーディング、テスト、要員管理を含む作業手順と理解すれば分かりやすい。具体例を示そう。

　開発プロセスは大きく、ウォーターフォール型、イテレーティブ型、アジャイルの3つに分類できる。ウォーターフォール型は、従来のレガシーなプロセスであり、COBOLなどの非オブジェクト指向言語や開発環境に適している。いまや、新規のオブジェクト指向システム開発で利用されることはほとんどない。

　イテレーティブ型は、オブジェクト指向によるシステム開発の基本的なプロセスと考えられている。1タームを約3カ月間と設定し、このタームを繰り返すことで、徐々にシステムを開発していくのである。大ざっぱにいえば、細かい部品を少しずつ作り、テストを行い、動作することを確認してから、次の段階に進んでいく。分析、設計という一連の作業は3カ月間の1タームに凝縮されているため、作業を繰り返すことで、精度が向上していく。オブジェクト指向では、開発の初期段階から高精度の設計を行うことは困難なため、このプロセスとの相性がとても良いのである。そして、オブジェクト指向開発環境下では、最初から完璧な設計を実現することは事実上不可能とされているので、完璧な設計書を前提としたウォーターフォール型の開発プロセスは適用不能ともいえるのである。もし、ウォーターフォール型で開発プロジェクトを成功に導いたとしたら、それはオブジェクト指向のメリットを活用していないことの証左であろう。

　開発プロセスの最後の分類は、アジャイルである。アジャイルとは、「俊敏」「機敏」という意味だ。ビジネス環境の変化、ニーズの多様化に対応するための企業システムの機能拡張（あるいは改変、リプレース）要求はすさまじい勢いで開発者にプレッシャーを与えるだろう。たった3カ月間でシステムに対する要求が変わることは日常茶飯事となっている。このような過酷な状況は、必然的に開発成果物の短納期化を導き出す。アジャイルはまさに、こんな市場環境に適したプロセスともいえる。

　過激ないい方かもしれないが、アジャイルと比較すれば、イテレーティブ型もすでにレガシーなプロセスと考えられる。アジャイルでは、イテレーション（1回の開発単位）を2週間や1カ月に設定する。これは、開発を行うスコープを切り分けることにより可能になる（図1）。

図1 スコープと開発フェイズ

　XP（Extreme Programming）に代表されるアジャイル開発プロセスは、リファクタリングやペアプログラミングといったプログラミングの技術に注目が集まっているが、実際の利点は、開発対象のスコープの分割とリリースまでの期間を短くすることで、開発のターゲットがぶれないようにし、リスクを低減させることにある。これにより、要件の理解ミスや変更による作り直しを最小限にくい止めることが可能になる。バブル時のように、開発予算が豊富にある時代であれば、開発コストが見積もりの3倍に膨れ上がろうとも問題はなかったかもしれないが、いまどき、そんな余裕のある企業はない。

　一口にアジャイルな開発プロセスといっても、数多くの種類があることはさまざまな雑誌やWebサイトを通じて知っている人も多いだろう。代表的なアジャイル・プロセスを表にまとめてみた。

　アジャイル・プロセスという共通要素を持ってはいるが、それぞれに切り口が異なるという特徴を備えている（表）。

プロセスの名称	提唱者
XP	Kent Beck,Ward Cunningham,Ron Jeffries, James Grenning,Robert Martin
FDD	Jon Kern
アダプティブソフトウェア開発	Jim Highsmith
スクラム	Jeff Sutherland,Ken Schwaber,Michael Beedle
DSDM	Arie van Bennekum
クリスタル	Alistar Cockburn
xUML/MDA（モデル駆動型アーキテクチャ）	Steve Mellor
表 代表的なアジャイル・プロセスと提唱者

　XPは一言で説明するなら、「プログラミングを中心に考えた開発プロセス」という側面を持つ。XPの場合、「ストーリーカード」と呼ばれる要件記入用紙に、要件を適切な大きさで書き込みながら“要件定義”を作成する。このストーリーカードに書き込まれた細かい要件に沿って開発を行っていくのである。効率的なプログラミングという視点から開発作業を見直したプロセスというわけだ。プロジェクト管理を最重要な要素とする開発プロセスもある。スクラムは30日ごとに動作可能な製品を作成するスプリント（Sprint）や毎日決まった時間に決まった場所で行われる短時間のミーティングなどを特徴としたプロセスである。

　アジャイルの共通要素として、イテレーションは欠かせない。イテレーションの期間について、ケント・ベック氏が最近、ある積極的な提案をしている。いままでは、2週間をイテレーション期間として設定していたが、これを1週間にしようというものである。さすがに、1週間で動作するプログラムを仕上げることは大変だ。イテレーション期間が1週間になるからといって、週の労働時間は40時間以内（XPでは週40時間労働が原則）であることに変わりはない。故に一瞬たりとも気が抜けない。集中力を切らすと、仕事がはかどらなくなっていく。週40時間で、仕事が楽になるのではなく、集中力をコントロールしなければ、1週間でプログラムが完成しないのだ。

　これは、スポーツの試合にも当てはまると思う。サッカーは、1試合90分間内で、いかに集中力を維持するかが勝敗を分けるスポーツだ。キックオフ直後という時間帯に得点（相手側にとっては失点か）が多い（という印象が強い）のは、失点した多くのチームにとって、試合開始直後は集中力が希薄な時間帯であることを示していると思われる（図2）。クリスタル方法論の提唱者アリスター・コーバーン氏がアジャイル開発プロセスを「協調“ゲーム”」に例えているのは、まさにそういうことである。

図2 試合開始直後は集中力が希薄になりやすい

　さて、ここまで素晴らしいことばかり指摘してきたアジャイルだが、もちろん問題もある。それをいくつか指摘しよう。

　まずは「契約」である。いきなり実際的な話だが、実際的だからこそ、深刻でもある。ある業務システムの開発案件を受注し、そのプロジェクトでアジャイルを採用することに決めたはいいが、開発側も顧客側も過去にアジャイルを採用した経験がない場合が多い。アジャイル・プロセスでは、開発するシステムのユーザー機能をすべて洗い出してから開発費を決定するわけではないので、開発費用をどのように算定するかが非常に難しい。イテレーションの単位や期間による技術者のアサインなど一応の方法はあるが、ともかく両者にとって初めてのことを行うのは何かと大変なのである。

　多くのアジャイル・プロセスが存在することは欠点であるともいえる。

　オブジェクト指向の設計表記がUMLに統一されたと喜んでいた矢先、開発プロセス（この場合はアジャイルだが）が乱立し、さて、どれを選択すればよいのか分からない。さらに、それぞれのプロセスに関する教育やコンサルティング・サービスはどこで、どうやって受けられるのか、なかなか悩ましい問題である。

　先の問題にも関連するが、技術者の教育もかなり困難である。アジャイル・プロセスで重要な要素にメンタルな部分のトレーニングがあるのだが、これが意外と大変なのだ。プログラミング技術を向上させるには、ともかく黙々とコーディングに励めば何とかなるかもしれない。しかし、プロジェクトをチームとしてまとめあげる技量・力量は机上の勉強で身に付くものではない。チーム内でのコミュニケーションに対する重要度の比重が高いアジャイル・プロセスでは、精神的な強度を1人1人に求めるのである。

◆

　今回のコラムは、「システム開発の手順を示す開発プロセスとは何か」についていくつかの具体例を交えて紹介した。変化の激しいビジネス環境に対応しながら、開発の方法そのものも常に変化していることを実感してほしい。

プロフィール

長瀬嘉秀（ながせ よしひで） 1986年東京理科大学理学部応用数学科卒業後、朝日新聞社を経て、1989年株式会社テクノロジックアートを設立。OSF（Open Software Foundation）のテクニカルコンサルタントとしてDCE関連のオープンシステムの推進を行う。OSF日本ベンダ協議会DCE技術検討委員会の主査。現在、株式会社テクノロジックアート代表取締役。著書に「分散コンピューティング環境 DCE」（共著、共立出版）、「ソフトウェアパターン再考」（共著、日科技連出版社）、「コンポーネントモデリングガイド」（共著、ピアソン・エデュケーション）など多数。また「独習UML」（監訳、翔泳社）、「XP エクストリーム・プログラミング入門」（監訳、ピアソン・エデュケーション）、「UMLコンポーネント設計」（監訳、ピアソン・エデュケーション）、「入門Cocoa」（監訳、オライリー・ジャパン）、「Webサービス エッセンシャルズ」（監訳、オライリー・ジャパン）など海外の最新テクノロジに関する書籍の翻訳作業も精力的に行う。

Java会議室でご意見、ご感想を募集中

IT Architect 連載記事一覧