ObjectSquare

[レポート]


XP 祭り2004参加報告

(株)オージス総研
ビジネスプロセスモデリング部
米田 匡史

1.はじめに

去る7月26日、早稲田大学にて日本 XP ユーザーグループによる、「 XP 祭り2004 −アジャイルソフトウェア開発の最新事例と国際事情−」が開催されました。定員オーバーになったため予約が締め切られるほどの人気でした。会場には 200 人以上の参加者が集まり、XP がますます盛り上がってきているのを感じました。

XP(eXtream Programing) が誕生してからだいぶ経ちますが、XP を用いて開発したという事例をあまり耳にした事がありませんでした。そこで、今 XP はどのような状態にあるのかを知りたいと思い参加してきました。

この記事では、XP 祭り2004でのセッションについて報告したいと思います。

2.XP カードによる XP 体験:入門編 
(XPJUGスタッフ)

XP の理解を深める方法として、面白いツールが紹介されました。それが、Industrial Logic 社から提供されている XP カードです。XP カードは、XP を多人数によるカードゲームを行うことにより、XP について学ぶことができます。

XP カードの構成は以下のようになっています。

表1 XP カードの種類    
Problem(問題)カード ×44枚
Solution(解決)カード ×48枚
Value(価値)カード ×8枚
Joker(ジョーカー) ×1枚

遊び方としては、4 つほどあるのですが、今回行なったのは「XPWar」というゲームです。XPWar は XP プロジェクト上で起きる問題(解決策)として重大なものは何かを、議論を通して学ぶことができます。XPWar では Problem または Solution のカードを用います。XPWar はプレイヤーに問題(解決)の書かれたカードが 1 枚配られ、その中でどのカードが最も重要であるかを議論します。そして最も重要であるとプレイヤーから支持を得たカードを持つ人が勝ちとなります。


図 1 XPWar

例えば、図 1 のようにカードが配られたとします。次に、プレイヤーは最も問題であると思われるカードを挙げ、その理由を述べます。ここで挙げるカードは自分に配られたカードでなくても構いません。自分が本当に重要だと思うカードを挙げます。例えば、A さんは 3 番目、B さんは 1 番目、C さんは 3 番目、D さんは 4 番目を挙げたとします。この場合 3 番目のカードが一番支持を得たので C さんが勝ちという結果になります。
気づいた方もおられるかも知れませんが、実は最初に引いたカードである程度勝敗が決まってしまいます(^^; 結構、運が必要なんですね。ですから、議論をする事を楽しむというゲームなのかなと思います。また、議論するには業務について経験がない方は議論がしにくいという事も考えられます。そういった場合では、業務経験者と一緒にゲームをすると良いと思います。経験が無い人でもゲームを通して、経験者のノウハウを得るなんてこともできるのではないでしょうか。

私も参加させていただいたのですが、非常に楽しかったです。完全にゲーム感覚なので楽しみながらできるというのが非常にいい点だと思います。
XP カードは日本語訳版がまだ出ていないので、実際に行うには少し難しいかもしれません。ですが、XP について知らない方や、勉強してみたいと思っている方にとって、楽しみながら XP を勉強できるという点は非常に有効だと思いました。

XP カードには今回行った「XPWar」以外にもゲームがあります。詳細は以下のサイトをご覧ください。

   

3.FIT による受け入れテスト
(鷲崎 弘宣さん:情報・システム研究機構 国立情報学研究所)

FIT(Framework for Integration Test) は受け入れテストに使用可能なフレームワークです。HTML 表によるテスト記述や、テスト実行の自動化、XP との相性がよいとされています。

XP において重要なプラクティスとしてテストがあります。プログラムを書く前にテストコードを作成し、テストが通るようにプログラムを組んでいく方法です。このテストにはプログラマがモジュールを作成した後に行うユニットテストと、ユーザが要求通りにシステムができているかを確認する受け入れテスト(ユーザーテスト)があります。現在 xUnit などによりユニットテストは広く普及しています。一方、受け入れテストに関しては、行なわれてはいますが色々な問題があります。たとえば、受け入れテストは現状ではプログラムが提供するユーザーインターフェースを用いて手作業で行うことが多いため、同じ事柄を繰り返して確認するのは困難です。確認作業の信頼性は低く、また、繰り返し型開発に不向きです。しかし、FIT の登場により、こういった問題を解決できるようになります。

FIT を用いた受け入れテストの流れは以下のようになります。    

  1. 顧客は、HTML 形式でテスト記述ファイルを作成する
  2. プログラマは、テスト記述ファイル内に記述された表が示す内容を満たすように、プロダクトプログラムを開発する
  3. テスト記述ファイルとプロダクトプログラムを結びつけるためのフィクスチャを作成する
  4. 顧客(またはプログラマ)は、ランナーにテスト記述ファイルを入力して、受け入れテストを実行し、ランナーが出力するテスト結果ファイルを閲覧することによりテスト結果を確認する。


図 2 FIT による受け入れテスト

これまで、受け入れテストにはフレームワークがなかったため、テスト方法が共通化されていませんでした。これが受け入れテストの普及を妨げていたのではないかと思います。ですが、FIT というテストフレームワークの登場により、これからもっと受け入れテストが広く普及できると思うので、期待したいです。

4.アンチプラクティス:XP 導入後の落とし穴
(倉貫 義人さん:TIS(株))

アンチプラクティスとは、XP の導入時に失敗したパターンではなく、導入に成功した後に発生する問題とその解決策のことを指すそうです。このセッションでは、そのアンチプラクティスについてまとめていました。

XP は人間に焦点があてられていることから、XP の開発で起こる問題も人的要因を含んだものが多いようです。本セッションで取り上げられた問題には、「コードの共同所有」「リファクタリング」といった新しいプラクティスによって発生した問題なども挙げられています。下の表はその1例です。

表 2 アンチプラクティス(ブラウニーズ・ワーク)
名前 ブラウニーズ・ワーク(作った所がなくなった!)
背景 ”コードの共同所有”のプラクティスがうまく働いている。そのため、新人でも積極的にソースをコミットしている。
症状 力作だと思ってコミットしたソースコードが次の日には、まったく別のコードに変わっている。それでも良いコードなので、何も言えないが、やる気は下がってしまう。
原因 新人の作ったコードが気になるベテランが、新人の帰った後に、リファクタリングしている。『コードの共同所有』の招く副作用。
理想 新人は、自分の作ったコードがシステムの一部として動いているのを見て、やる気を倍増させる。
処方 ベテランは、新人の作った部分で、気になる部分を見つけたら、それを作った人間と一緒にペアプロしながら、リファクタリングする。ベテランが 1 人で先にリファクタリングしてしまった場合は、その理由と過程をチームのメーリングリストなどに流すことで、チーム全体への教育効果を図る。

アンチプラクティスは、この表のような形式でまとめられています。今後、XP の事例が増えていくにつれ、どんどん充実していくと思います。

アンチプラクティスは、XP の導入に関しての問題点を解決してくれるわけではありません。しかし、あらかじめアンチプラクティスを知っておくことで、XP を実践したときの失敗を未然に防げる、 また、問題が起こったとしてもすぐに対応することができるようになると思います。

その他のアンチプラクティスについては以下のアドレスに掲載されています。

最後に

ほとんどのプレゼンターの方が「もはや、XP がいいか悪いかという議論をする時期はもう過ぎている。」「 XP を導入するべきかそうでないかを検討して導入すべきならば導入するという判断をするようになった。」と話されていました。今回の XP 祭りでも、アンチプラクティスのように XP 実践時での問題点が出てきたことや、成功事例が集まってきたことにより、本の上で言われていた事が実践により、明確になってきたという事だと思います。また、FIT のようなツールにより、XP をより上手く実践できるようにする試みも現れてきています。

しかし、やはり XP の導入にはまだまだ壁が大きいように思います。事例の紹介で成功した要因として挙げられたのが、「もともとメンバーとの信頼関係があった」「 XP を経験したことがある人がいた」「計画ゲームを顧客が理解していた」といったものが挙げられていました。XP の導入には色々な問題がありますが、その中でもメンバー(ユーザも含めて)に恵まれているかいないかが一番大きい問題のように思いました。


© 2004 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP