[ホームへもどる]

Object Day 2001 - XP 談義 準備資料

2001/05/18 石井 勝

自己紹介

• 石井 勝
  • ほとんどの仕事は少人数による開発
    - いつも 2,3 人程度の開発で，最近は Web アプリの案件ばかりです．
  • ペアプロ歴 10ヶ月
    - 去年の 5月 からペアプロを導入してます．
  • UML を使った開発経験なし
    - 開発にオブジェクト指向言語を使ってるだけです．いわゆるオブジェクト指向開発の経験はありません．
  • UML はまともに書けない
    - 仕事でちゃんと使ったことないのでまともに書けないし，別に気にもしてません．
  • RubyUnit の作者さんとはお友達
    - 助田君に XP の Testing Framework の説明をして，Ruby 版を作ってもらいました．
  • PalmUnit の作者さんとはペアプロのパートナー
    - PalmUnit は Palm の Testing Framework です．PalmUnit はよく知らないですが，毎日作者の加藤君とペアで仕事してます．

XP に対する意見

• XP はマニュアルではない
  • XP は手段の一つにすぎない
    • あくまで自分の開発プロセスの改善が目標
    • XP をどう利用できるか考えることが大切
    • まず 4つの価値 を高めること
  • ペアプロと Unit Test は普遍的
    • 12 のプラクティスにこだわらない
    • ペアプロと Unit Test から始めては？
    • XP じゃなくてもこの２つは有効なはず

最近は XP の本もよく出てますが，単純にそれらのプラクティスに従う，というのは駄目だと思います．あくまで自分が担当している開発を中心にして，そこでXPをどう利用できるかを考えるべきだ，ということです．それには， XP の4つの価値（つまり 単純さ，コミュニケーション，フィードバック，勇気）を高めるにはどうすればいいかということを考えるとよいと思います．XP ではコードが開発文書だ，とか言ってますが，もしそれで開発者間のコミュニケーションが下がるのなら間違いです．あくまで4つの価値から考えないと失敗すると思います．

といっても， XP のペアプロとUnit Test についてはどんなプロジェクトでも部分的に導入しやすいし，効果があるので，まずこの2つから始めればいいのではないかと思います．

仕様抽出や知識獲得

XPは製造についてのプラクティスが中心となっているが、ソフトウエアの仕様抽出や獲得の方法やプロセスが疎かになっているのではないか？

XPではストーリーカードで仕様を抽出しますが，僕もストーリーカードだけでは仕様抽出や知識獲得の部分が弱いと思います．XPの考え方としては，それを顧客と開発者とのコミュニケーション，つまり対話で補う，ということなのでしょう．つまり，「オンサイト・カスタマ」や「ペアプログラミング」によって補うということです．

でも，ここでいっておきたいのは，XPは従来のウォータフォールなどの開発プロセスとはアプローチの仕方が違うということです．それを説明するには，「精度と正しさ」の観点からみるといいと思います．

そもそも「精度」と「正しさ」は違います．これは Alistair Cockburn の本 に出てる例ですが，例えば「円周率が 4.141592 である」といった場合，精度は高いですが正しくはありません．まだ精度は低くても「円周率は 3 である」といった方がましです．これと似た状況が XP と ウォーターフォールにあると思います．

XP の場合，仕様抽出について低い精度のものしか求めない代わり，まず正しさを確かめようとします．XPの開発プロセスでは，一番最初にリリース計画として全体の分析を行ってから，すぐ細かい（例えば2週間単位の）イテレーション開発に入ります．各イテレーションでは，分析・設計・実装・テストをほぼ同時進行の形で行います．精度の低い仕様で始め，実際にそれが正しいのかすぐ実装・テストの段階にまでもっていって検証しよう，というアプローチです．

一方，ウォーターフォールの場合は，最初にできる限り精度の高い仕様を準備しておき，その後実装・テストで開発の後になって初めて正しさを検証する，というアプローチです．最初の精度の高い仕様が正しければいいですが，最初の1桁目が間違っているのに精度を上げ，開発の後段階でダメージを受けるというリスクがあります．

僕は，どちらのアプローチが正しくて，どちらのアプローチが間違っている，と一概には言えないと思います．それは，開発プロジェクトに依存します．その判断基準の一つとして挙げられるのが，いわゆる「変更コストカーブ」というものだと思います．

もしあるプロジェクトを開始するとき，ユーザさんとの交渉に失敗してオンサイト・カスタマや2週間単位のイテレーション開発で行うことに同意してもらえなかった場合を考えてみます．そして，この業務分野のエキスパートを最初の一ヶ月間だけ分析のために用意しましょう，あとの3ヶ月でシステムを開発してください，となってしまったとしましょうか．

この場合，あきらかに変更コストカーブは増大します．つまり，プログラマが実装するかなり後の段階になって「まてよ，こういう例外が起こった場合どういうビジネスルールが適用されるんだ？ これはユーザさんに聴かないとわからないぞ」となったとしても，もうその質問に答えてくれるエキスパートは近くにいません．したがって，この場合は仕様の精度を上げ，最初の一ヶ月でその例外を処理する方法を解決しておくほうがいいわけです．

変更コストカーブが増大するのが運命づけられたプロジェクトなのに，XP が流行っているからといって，Embrase Change とかいっているのは馬鹿げてます．

一方で，XP には変更コストカーブを平坦にもっていくようにするプラクティスが用意されてます．変更コストカーブが平坦にできそうなら，ウォーターフォールよりも XP のやり方に従うほうがいいんじゃないか，ということです．

要するに言いたいのは，どんなプロジェクトにも適用できる開発プロセスは存在しないし，XP のある部分が弱いからといって，それを批判するというのはどうかと思う，ということです．XP の弱い部分を補ってカンペキな開発プロセスにしよう，という考えにもあまり同意できません．

開発プロセスの方法もパターンと同じです．どういうプロジェクトに適用するかという文脈に依存すると思います．どんな場合にでも使える開発プロセスなんかは存在しないと思いますし，存在したとしても，複雑すぎるものになってしまうのではないかと思います．

設計やアーキテクチャの位置付け

XPは実装中心の開発であるがゆえに、熟慮することなく実装が進んでしまうのではないか。また、アーキテクチャをどのように見出し、確定していくかという点が不明確ではないでしょうか？

XP は実装中心というよりもまずテスト中心の開発である，といえます．XPでプログラムを書くには，テスト可能なコードにしなければなりません．この制約がソフトウェア設計に良い影響を及ぼしていると思います．例えば，一般に GUI 周りのテストコードを書くのは難しい作業です．したがって，テストしやすいレイヤと GUI のレイヤを分ける必要が出てきます．これが，オブジェクト指向でいう Model と View を分離する，というアーキテクチャにつながります．

また，Unit Test におけるテストファーストプログラミングでは，spoofing とか Mock Object というテクニックが使われることがあります．spoof とか Mock というのは「だます」という意味です．例えば，ある機能を実装しているときにメール送信の機能が必要になったとします．でもまだメール送信機能は実装してない，というとき，テストできるようにするためメール送信のクラスをとりあえず interface で定義しておき，そこからダミーのクラス (Mock Object) を implements してテストしよう，ということです．これによって，インタフェースと実装の分離する，という設計が導入される場合もあるでしょう．

その他にも重要なのが，ペアプログラミングとリファクタリングによる効果です．まず，ペアプログラミングでコードの書き方に統一性が出てきます．クラス名のつけ方，メソッド名のつけ方，アルゴリズム，それらすべて開発者間で統一されるような形になってきます．これは開発者が各自勝手にプログラミングしている場合にはとても実現できないようなことです．

統一性がとれていると，リファクタリングしやすくなります．同じようなコードを発見し，それを一つのメソッドやクラスにまとめる作業が簡単になります．これによって「同じコードは2度書かない」というOnce and Only Once ルールにしたがうきれいなコードを作れるようになると思います．

アーキテクチャを最初に決めるのではなく，XP では実装コードからリファクタリングでアーキテクチャを発見していく，というようになるのではないでしょうか？

ペアプログラミングやCollective Ownership

一般的に実践できる手法なのか？（人格者とスキルの高い開発者のドリームチームを仮定しているのではないか）

一般的に実践できると思います．僕は，ペアプログラミングを始めて一年近くになり，今まで4人とペアを組みました．ペアを組んでいる途中で意見が合わず仕事が進まなかったり，喧嘩してしまったり，というようなことは一度もありませんでした．それはメンバに恵まれていたせいかもしれないですが…．苦労したといえば，最初の数週間はあまりペアを組んで仕事をしてくれなかったことぐらいです．最初はペアを組むように指導してました．普通に他人とコミュニケーションをとれる人なら，ペアプログラミングできない，ということはないと思います．

Collective Ownership は，Unit Test とペアプログラミング，ソースコードのバージョン管理ツールの導入が必須ですが，これらが実践できているのであれば導入可能だと思います．

プロジェクト管理、顧客との関係

計画的な開発は行えるのか？管理者や顧客は開発の進行状況をどのように把握したら良いのか？On-Site Customerは可能なのか？

On-Site Customer は実現できなかったのでわかりません．計画についても，つい最近 XP のプランニングを実開発で試している段階なので回答できません．ただ，このまま XP のブームが広がって顧客側も XP について理解を示してくれるようになれば可能になってくると思いますが．

XPを実践して良かった点

ペアプロでいつも誰か相談しながら開発しているので，仕事に対するストレスやプレッシャーをかなり軽減することができました．ソフトウェア開発が，精神的にかなり楽になったことことが良かった．

また，デバッグで何時間も悩むということがほとんどなくなりました．今ではテスト・ファーストを使わずにプログラムを組むのが苦痛にすら感じます．

それと，On-Site Customer は実現できなかったですが，仕様変更に対する修正コストはそれほど増えなかったと思います．開発の後段階になってもコードをどんどん変えていくことができました．今までの開発では考えられなかったことです．

XPを実践して難しかった点

やはり顧客とのコミュニケーションでしょうか．XP にあるように 顧客は仕様を決め，開発者はそれを評価し，それにしたがって顧客が優先順位を決めて，開発者が実装する，というサイクルにはめるのは，かなり難しいと思います．XP で難しいのは，開発者よりも顧客側だと思います．

XPの適用範囲

すべてのプラクティスを実践するのは難しいし，狭いと思います．XP の役に立つところを利用して自分の開発に生かすという立場が一番妥当なところではないでしょうか？

[ホームへもどる] [先頭へもどる]