ObjectSquare [2009 年 8 月号]

[技術講座]


アジャイルモデリングへの道

第 5 回:XP とウォーターフォール開発の設計作業

( 株 ) オージス総研 技術部 アジャイル開発センター 藤井拓

時が経つのも速いもので, 前回の記事を執筆してから別の記事をいくつか書いている間に1年経ってしまいました. 前回の記事と少し被る部分もありますが, 今回の記事では XP ( eXtreme Programning ) [1] における設計作業を取り上げ, 従来のウォーターフォール開発における設計作業の違いや両者の有効性について考えてみます.




1. XPとウォーターフォール開発の設計作業の違い

前回の記事では, 代表的なアジャイル開発手法の 1 つである XP においてインデックスカードを用いた「ストーリーカード」や「タスクカード」を用いたモデリング作業が行われていると書きました. ただ、これらのモデリング作業は「プログラミングする対象のクラスを特定する」という設計のためのモデリング作業ではなく, 「要求」や「タスク分割」のためのものです.

XPにおける設計作業は, 以下のプラクティスや開発段階において行われていると考えられます.

「テストファースト」で設計を考える作業は, 各イテレーションで「タスクカード」が割り当てられた開発者の各ペアが行うことになります. また, これらの作業を通じて設計されたクラスを実装した後に, 「リファクタリング」 [2] を行うことで設計構造の改善を行うことが推奨されています.

これに対して, ウォーターフォール開発の設計作業は以下のような段階を通じて進行します.

また, 基本設計や詳細設計において「設計レビュー」を実施することで, 設計上の問題をプログラミングの前に発見し, 修正することが可能になります.

これらの両者の設計作業を少しウォーターフォール開発寄りの立場で分解すると以下のようになります.

ウオーターフォール開発では, これらの作業が「アーキテクチャに対する解決策」と「エンドユーザ機能に対する解決策」の 2 つのレベルにおいて行われると考えることができます.

これらの作業で, XP とウォーターフォール開発が大きく異なるのは以下の 3 点においてです。

これらの 3 点において XP とウォーターフォール開発の設計作業の違いをまとめたのが表 1 です.

表 1 XP とウォーターフォール開発の設計作業の違い
XPウォーターフォール開発
表現手段明確に決まっていない文書
共有(伝達)方法会話文書と説明
範囲開発者ペア異なる開発工程の作業者間
検証改良方法レビューやリファクタリング設計レビュー
当事者開発者ペアプロジェクトのメンバー(全員または一部)+(場合によっては)プロジェクト外部レビューアー

この表で示される XP とウォーターフォール開発の違いは, 「開発途上で(要求等に起因する)変更が発生する度合い」と「開発プロジェクトの規模(=要員数)」に対する想定の違いに起因しています. ここでは、「開発プロジェクトの規模」が 10 名以下の場合を「小規模」, 10 名を超えて 20 名以下の場合を「中規模」, 20 名を超える場合を「大規模」とします.

XP では, 「開発途上で変更が発生する度合い」が「大きい」と想定しています. また, 「開発プロジェクトの規模」について筆者は「小規模」を仮定していると思います. そのため、変更により柔軟で低コストに対応するために以下の方針を用いています.

すなわち, 開発途上での変更で修正のコストが大きくなる「文書」ではなく,「会話」での情報伝達を多用しています. また, 設計は開発ペアの間でレビューされ, 実装後は適宜リファクタリングにより改良します.

ウォーターフォール開発では, 「開発途上で変更が発生する度合い」が「小さい」と想定しています. また, 「開発プロジェクトの規模」について筆者は「大規模」を仮定していると思います. そのために、大きなソフトウェアを分業で作るために以下の方針を用いています.

すなわち, 分業を行う人の間やプロジェクト内で解決策の伝達や共有を行う手段として文書を多用します. また, 比較的少数の設計レビューにより設計の品質を高めようとしています.



2. XP とウォーターフォール開発の設計作業の有効性評価

XP とウォーターフォール開発の設計作業の有効性(効果)を定性的に評価する観点を以下のように設定してみます.

  1. 文書を作成する手間(マイナスの因子)
  2. 成果物を変更する手間(マイナスの因子)
  3. 情報伝達の確実性(プラスの因子)
  4. 大規模への対応(プラスの因子)
  5. チームによる品質向上(プラスの因子)

これらの観点を用いて, 「開発途上で変更が発生する度合い」が「少なく」, 「開発プロジェクトの規模」が「大規模」な場合に XP とウォーターフォール開発の有効性を評価すると表 2 のようになります.

表 2 変更が発生する度合いが少なく, 開発プロジェクトが大規模な場合
評価項目XPウォーターフォール開発
文書を作成するオーバーヘッドなし
成果物を変更するコスト極めて低
情報伝達の確実性
大規模への対応
チームによる品質向上
総合的な有効性評価

この場合には, ウォーターフォール開発の「文書を作成するオーバーヘッド」や「成果物を変更するコスト」というデメリットが相対的に小さくなり, 「情報伝達の確実性」や「大規模への対応」というメリットが相対的に大きくなることで全体的にはウォーターフォール開発の有効性が高いと評価できます.

一方, 「開発途上で変更が発生する度合い」が「少なく」, 「開発プロジェクトの規模」が「大規模」な場合にXPとウォーターフォール開発の有効性を評価すると表 3 のようになります。

表 3 変更が発生する度合いが多く, 開発プロジェクトが小規模な場合
評価項目XPウォーターフォール開発
文書を作成するオーバーヘッドなし
成果物を変更するコスト極めて低
情報伝達の確実性
大規模への対応--
チームによる品質向上
総合的な有効性評価

この場合には、XPの「文書を作成するオーバーヘッド」や「成果物を変更するコスト」が低いというメリットが「情報伝達の確実性」が低いというデメリットを上回り、全体的にはXPの有効性が高まります。

もちろん, 「開発途上で変更が発生する度合い」と「開発プロジェクトの規模」の大小の組み合わせとしてはこれら 2 つの場合以外も存在します. 筆者は, 10 名以上のプロジェクト規模の場合には「情報伝達の確実性」が「低い」という点で XP のようなアプローチはあまりうまくいかないのではないかと考えています. また, 本記事ではあまり言及しませんが, XPの設計作業については以下の2点も懸念されます.

一方で, 近年開発プロジェクトの短期化, 小規模化は着実に進行しており, 「文書を作成するオーバーヘッド」や「成果物を変更するコスト」が無視できない状況になっていることも事実です. そのため, XP の「文書を作成するオーバーヘッド」や「成果物を変更するコスト」が「低い」という長所を生かしながら, 「情報伝達の確実性」を「高める」方法が求められています.


3. 終わりに

前の節では, 「開発途上で(要求等に起因する)変更が発生する度合い」の高い場合と低い場合という2つの場合について XP とウォーターフォール開発の設計作業の有効性を評価しました. ただ, この「開発途上で変更が発生する度合い」の「高い」,「低い」という定性的な形でこの議論を進めることは非常に危険です. 実際には、XP でも反復的な開発でも「開発途上で変更が発生する度合い」に無制限に対応できるわけではありません. その一方で、XPや反復的な開発は「開発途上で変更が発生する度合い」に何でも対応できるという過剰な期待は根強くあり, その期待が満たされない場合に「XPや反復的な開発は期待したほどではない」という失望も生んでいることも多いのではないかと思います.

次回の記事では, ウォーターフォール開発, アジャイル開発, 統一プロセスの3者が「開発途上で変更が発生する度合い」にどの程度対応できるかという点について論じる予定です.


参考文献


記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点
記事に関するコメントがあれば併せてご記入ください。
  

© 2009 OGIS-RI Co., Ltd.
Prev. Index
Prev. Index