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

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

第3回 「典型的なOO開発」と「XP」のプロセス比較

　今回から、UMLを活用した典型的な「オーソドックスなオブジェクト指向開発プロセス」と「XP」を比較することで、それぞれの相違点を浮き彫りにしていく。どちらも「開発プロセス」という共通点があり、要求分析、システム分析、システム設計、実装、テストという開発の流れそのものに違いはない。しかし、それぞれの要素ごとに明らかな違いがある。ここで展開する分析は、結果的に、どちらが優れているかということを問題にはしていない。重要なのは、「オーソドックスなオブジェクト指向開発プロセス」を選択しようが、「XP」を実践しようが、開発プロセスの基本を理解していなければ、効率のよい開発作業を進めることは不可能だということだ。

　今回比較対象とする「オーソドックスなオブジェクト指向開発プロセス」は、CBOP（ビジネスオブジェクト推進協議会）が標準化しているコンポーネントベースの開発プロセスである（図1）。ベテランのエンジニアならこれを見て、いままで自分が行ってきた“開発”と大きな違いはないと感じるだろう。もちろん行うべきことに変わりはない。個々の要素がオブジェクト指向になっているという点が決定的に違うだけだ。

図1 CBOP（ビジネスオブジェクト推進協議会）のコンポーネントベース開発プロセス（クリックすると拡大）

　開発プロセスを構成する要素を分割すると、要求分析、システム分析、システム設計、実装、テストとなるだろう。この一連の流れと並行しながら、アーキテクチャを決定する作業を行う。この手順で順番に作業していくと、いわゆるウォーターフォール型となるのだが、スコープを分割し、この流れを繰り返し行っていくことで、イテレーティブ型に変貌（へんぼう）する。

　それでは、コンポーネントを活用したオーソドックスなオブジェクト指向開発プロセスとアジャイル開発プロセス（ここではXP）を比較しながら、開発プロセスの要素の相違を詳細に分析していこう。今回は始めとして、要求分析とシステム分析の2つのフェイズに焦点を絞る。

要求分析フェイズにおける相違点

　

　要求分析とは、業務フローの洗い出しと構築、スコープの明確化である。従来、コンサルティング会社が行っていた領域だが、オブジェクト指向の普及により、エンジニアがより上流の仕事をするようになってきている。

■コンポーネントベース開発プロセスではこうなる

　UMLによるオーソドックスなオブジェクト指向開発プロセスでは、UMLのアクティビティ図を使う（図2）。業務フローをビジネスプロセスとしてアクティビティ図に記述していく。もちろん、現状／今後ということを考慮するのであれば、as is／to beを作成する。

　ビジネスプロセスを整理していくことによって、そこで使われる機能の粒度（大きさ）も揃えることができる。アクティビティから起動される機能が、ビジネスコンポーネントのアクション（操作）になる。UMLでいうならば、ユースケース（機能）が起動される。すなわち、ユースケースは、アクティビティより小さいのである（組込みのシステムは逆に大きい）。

図2 UMLによるオーソドックスなオブジェクト指向開発プロセスでは、UMLのアクティビティ図を使う

　このアクティビティ図は、受注入力というビジネスプロセスを表している。ビジネスプロセスの整理は、次のようにビジネスプロセスを構造化していけばいい（図3）。

図3 ビジネスプロセスの構造化（例：販売管理システム）

　販売管理を受注、発注、顧客管理、在庫管理というビジネスプロセスに分割する。これは従来、サブシステムとして扱われていたような考え方である。さらに、受注を受注入力、出荷、請求というビジネスプロセスにさらに細かく分割していく。

　たいしたことがなさそうな考え方であるが、ビジネスプロセスをアクティビティ図で表現する段階で構造化を行っておかないと、ビジネスプロセス同士が複雑に絡み合ってしまい、収拾がつかなくなる。このような手順に従って、ブレークダウンしていくことがビジネスプロセス整理の秘訣である。

　次に、ビジネスプロセスから起動される機能を見ていこう。この機能をコンポーネントベース開発手法では、アクションと呼ぶ。このアクションを整理するダイアグラムが次のマインドマップである（図4）。

図4 マインドマップ：受注入力システム（システム化範囲設定後）

　マインドマップによって、コンポーネントへの起動を整理できる。このアクションが、ビジネスコンポーネントのインターフェイスに相当するのだ。J2EEや.NETによるコンポーネントベースのシステムは、ユースケース駆動ではなく、このようなインターフェイス駆動の方法で、より上流工程からシームレスに実装に持っていくことができる。

■アジャイル開発プロセス（XP）ではこうなる

　一方、XPでは、プログラマ自身がストーリーカードで要件を決めていく（図5）。業務フローや必要な処理をビジネス側のユーザーとプログラマがコラボレーションをしながら構築していく。さらに、確定したストーリーに対して見積もりを行う。これほどユーザーに近づく仕事は、エンジニアにとっては、新たな挑戦だ。

図5 ストーリーカードで要件を決めていく

　ストーリーの作成は、コンポーネントベースのアクションの洗い出しと内容の確定に相当する。そして、ストーリーのメリットは、単位が2週間で開発できる粒度（大きさ）になっていることである。このストーリーやアクションの粒度の調整がキーポイントになる。コンポーネントベース開発では、リファイン（洗練）というテクニックを使って粒度の調整を行う。XPでは、見積もりを通して、ストーリー分割を行い、粒度を合わせていく。ここで失敗すると開発のスケジュール、予算などあらゆるものに影響が出てしまう。これを計画ゲームと呼ぶ。

システム分析フェイズにおける相違点

　

　次にシステム分析フェイズを見ていこう。図1は、コンポーネントベースの開発プロセスなので、コンポーネント外部仕様と内部仕様に分かれている。このフェイズでは、システムの内部の構造を設計していく。

■コンポーネントベース開発プロセスではこうなる

　分析フェイズは、UMLによるモデリングと呼ばれている部分である。前の工程で、ビジネスコンポーネントの外部仕様として、アクションを切り出したが、このアクションが持っているビジネスコンポーネントを明確にしていく（図6）。その後に、ビジネスコンポーネントの内部設計として、データ構造を分析していく。UMLでは、ユースケース図から始まりクラス図までの一連のダイヤグラム作成に当たる。

図6 アクションが持っているビジネスコンポーネントを明確にする（受注コンポーネントのインターフェイス）

　この受注コンポーネントのインターフェイスには、「顧客を確認する（）」「受注内容を入力する（）」「在庫をチェックする（）」「受注内容を登録する（）」「注文をキャンセルする（）」というアクションがある。これらのアクションによって、受注コンポーネント内部のタイプ（情報要素）にアクセスする。このアクセスが、外枠から顧客タイプへの関連になっている。顧客タイプの右から、外枠への線がこれである。「顧客を確認する（）」というアクションが呼び出されると、この関連により顧客データの存在をチェックする。J2EEでは、セッションBeanからエンティティBeanのゲッタの呼び出しに当たる。

■アジャイル開発プロセス（XP）ではこうなる

　システム分析フェイズはXPでは、ストーリーカードとタスクカードに分割して、テストに必要な項目をピックアップしていく作業に当たる。このタスクへの分割の際に、処理やデータの構造を設計していく。タスクへの分割というと単純な作業として見られがちだが、このフェイズは経験が必要で難しいところである。

　例えば、「受注処理をする」というストーリーがあったら、それを「受注コードを採番する」「受注トランザクションを作成する」などといったタスクに分割していく（図7）。これは、まさに設計作業であり、この作業を通じて機能の詳細化を行っているのである。ただし、XPでは、データ構造の明確化は、タスクの内容に含まれるため、タスク分割ではそこまでの作業は行わない。データ構造の明確化は、実際のコーディングやスキーマの生成などにあたる。

図7 ストーリーをタスクに分割していく

　以上、要求分析とシステム分析フェイズでの、コンポーネントベース開発とXPの比較を行ってきた。両者とも開発プロセスとしてみれば、基本的には極めて似通っている。しかし、オーソドックスなUMLによる開発プロセスとアジャイルなXPでは、実際の作業が異なっていることも明らかだろう。開発プロセスの工程では、この作業は何のために行っているのかを考えることが大切である。意味も分からず作業をしていると道に迷ってしまうのだ。

プロフィール

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

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

IT Architect 連載記事一覧