アジャイルモデリングへの道5 XP とウォーターフォール開発の設計作業

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

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

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

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

• アーキテクチャスパイク
  • 開発の初期においてアーキテクチャを確立するために設定される期間
• テストファースト
  • 実装すべきクラスに対するテストケースを考えることで, そのクラスのインターフェースと振る舞いを決めていくプラクティス

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

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

• 基本設計
  • アプリケーションを肉付けするためのアーキテクチャを構成するソフトウェア要素, それらの連携方式, ハードウェアを決定し, それを文書化する
• 詳細設計
  • アプリケーションに必要な画面やロジックを実装するためのクラス（モジュール）の仕様と振る舞いを決定し, 文書化する

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

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

• 解決策を発想する
• 解決策を表現し, 共有（伝達）する
• 解決策を検証し, 改良する

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

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

• 表現手段
  • 解決策を表現するための方法
• 伝達の方法と範囲
  • 解決策を共有（伝達）するための方法と範囲
• 検証改良の方法と実行者
  • 解決策を検証し, 改良するための方法とそれを実行する人

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

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

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

• 開発作業を工程ごとに分業しない→解決策を伝達する必要性を減らす
• 解決策の伝達（共有）に文書を用いない→会話を用いる
• 品質を高めるために, ペアプログラミングを行い, 実装後にリファクタリングを行う

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

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

• 開発作業を工程ごとに分業する→解決策を伝達（共有）することが不可欠
• 解決策の伝達（共有）に文書を用いる
• 品質を高めるために実装前にレビューを行う

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

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

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

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

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

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

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

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

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

• アーキテクチャスパイクでのアーキテクチャの設計作業が不明確
• 設計の品質が開発者ペアの設計スキルによってバラツク可能性がある

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

3. 終わりに

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

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

参考文献

• [1] ケント・ベック: XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法, ピアソンエデュケーション, 2000
• [2] マーチン・ファウラー: リファクタリング―プログラムの体質改善テクニック, ピアソンエデュケーション, 2000