ObjectSquare

[ObjectDay2001特集]




ObjectDay2001 体験XPレポート
- 嗚呼、人生即二人実装哉

XP体験

(株)オージス総研
梅澤真史、畑理介
(株)永和システムマネジメント
平鍋健児




概要

この記事は、5/18のObjectDay2001で行われた「体験XP」のレポートです。 このワークショップは、事前にXPペアを6チーム一般公募し、 ObjectDay当日にその場でXPを体験しながら実装してもらう、 という企画です。

中身の濃〜い2時間の内容でしたが、できるだけ 現場の雰囲気が伝えられるようにレポートしていきたいと思います。


参加ペア

実際に申し込みがあったペア6組は、以下の通りです。みなさん、なかなかの 意気込みで体験に臨んでいただきました。それぞれのチームの「名前の由来」 も合わせて聞いてみました。

N
  • N & F
    中垣健志さん、古川 弘さん
    日ごろの、仕事でOOを使えないフラストレーションを思う存分解消したいと思っています

  • Extreme Challengers
    小薮 隆史さん、佃 軍治さん
    あんまり深く考えてません・・

  • ビューティーペア
    三上 昌晴さん、秋間 忠さん
    これ以外に咄嗟におもいつかない

  • ペア・カモ
    野中 愛さん、小川 健一さん
    果たしてペアなのか !?

beaty-pair
5th-year-pair
  • 5年目ペア
    青木 淳夫さん、佐藤 治夫さん
    新技術追求を楽しんでいる社会人5年目ペアです。

  • X is not Peke.
    佐藤 貴行さん、石橋 賢治さん
    日本で使われるX印はバツ(ペケ)印でもあるが、視点を変えることによって無限の可能性を秘めたX(エックス)にもなる。

「X is not Peke.」さんのネーミングは深い!
「ペア・カモ」も好き!

やる気をみなぎらせて来てくださったチームあり、ひまだから出てみようか、 というノリのチームあり、みなさん、それぞれに XPを楽しむ積りで参加して 頂きました。

今回は、ギャラリーとして多くの方が途中経過を覗いてくださいましたが、 会場では、 「参加者が楽しい」ことを基本に進めました。


ストーリー

用意したストーリーは、次のようなじゃんけんゲームです。


-マルチユーザ参加型じゃんけんゲーム-

Object Day2001 XP workshop
2001/04/23 M. Umezawa


基本ストーリー

  1. じゃんけんプレーヤーはじゃんけんゲームに参加できる。
  2. じゃんけんプレイヤーは「ジャンケンポン」の合図でグー、チョキ、パーのいずれかが出せる。
  3. じゃんけんのルールは通常と同じ。
  4. 誰かが一人勝ち残るまでじゃんけんを繰り返す。
  5. 最後まで残ったプレイヤーが優勝。

マルチユーザ対戦用ストーリー

  1. プレイヤーは「ジャンケンポン」の合図でグー、チョキ、パーのいずれかをファイルに書き込む。
    • ファイルのフォーマットは以下のとおり。”GOO”などの文字列の後、改行する。

      < GOO | CHOKI | PAR ><改行(CRLF)>

    • ファイル名は<チーム名>.te とする。
    • ファイルは上書きモードとする。

※主に「基本ストーリー」について作業を行っていただきますが、最後にみんなでじゃんけん大会をしたいので、時間がなくなってきた場合には「マルチユーザ対戦用ストーリー」を優先させてください。

以上

このストーリーは参加ペアに事前に配布し、ある程度準備をしてきてもらって もよいことにしました。


ペアプロスタート!

ペアが会場にそろったら、もうどんどん実装していきます。 その前に、ペアプログラミング のペアプロの心得、として、「ペアプログラミング10則」を確認しておきましょう。

ペアプロの2人の役割を、ドライバー(プログラムを書く方)とパートナー (その後ろで見る方)と呼びます。ドライバーとパートナーの交代タイミングや、パー トナーのツッコミの要領などが書かれています。


ペアプログラミング十則

Object Day2001 XP workshop
2001/04/26 K. Hiranabe


ペアプログラミングでは、書く人を「ドライバー」、見る人を「パートナー」と呼びます。

一. ドライバー、パートナーは5〜10分毎で適当に交代しよう。ドライバーは引き際が肝心。パートナーの助言が多くなったら交代。
二. やることを紙に項目として書き出そう。終わった項目を横線で消そう。
三. コードより先にテストを書こう。テストをパスさせるための最もシンプルな実装をしよう。
四. パートナーは、ツッコミの要領で助言しよう。

(あ). もっとシンプルな方法はないか。
(い). コードは意図を表現しているか。
(う). クラスやメソッド、変数の名前は意図を表しているか。
(え). タイプミスはないか。括弧の数は合っているか。
(お). テストは先に書いたか。
(か). 次のテストはどう書こうか。テストし忘れていることはないか。
(き). 全体から俯瞰してバランスはとれているか。ヘンな方向に突き進んでいないか。
(く). コーディング標準にあっているか。

五. パートナーは、じれったくなったら「ぼくにやらせて!」と言おう。
六. パートナーは、理解できないコードを見たらドライバーに聞こう。「なんでそうなの?」
七. ドライバーは、パートナーの助言にいつでも耳を貸そう。そしてその助言に返事をしよう。分かったの?分からないの?
八. ドライバーは、行き詰まったら助けを求めよう。このメソッド、ちょっとお願いできないかな?
九. 腹が減ってはプログラミングはできぬ。一緒にお菓子を食べよう。
十. 楽しくやろう。Enjoy Pair Programming!


テストファースト

テストファーストによる設計や、JUnit の使い方に慣れていない人のために、 「JUnitによるテストファースト・デザイン」 (PDF のダウンロードはこちら) という資料も事前に配布しました。XP特有の、テスト-コード-テストというリズム を体験してみたい方は、この資料をステップ・バイ・ステップでなぞるとよい でしょう。

当日も、いくつかのチームは、まず手始めに この資料をなぞることから始めていました。

XPの基本は、

「テストを先に書く。通らないテストがあってはじめてコードを書く」

です。

また、「もっとも簡単なコード」を書くように注意しましょう。未来に必要 となるかもしれない要件のために、凝った設計にしてはいけません。

「それは必要とならない!」

のです。


体験のようす

みなさん、ホワイトボードにタスクを列挙して、 終わったら線を引いて消す、とか、UMLクラス図 を書いて Game や Player クラスの責務分担を決めたりしていました。

部屋の写真その1
じゃ、はじめましょうか。お手柔らかにね。

「XP で UML なんて使うのか」って? XPではチームがコミュニケーションする ことが第一の価値。その方法はUML であろうと、CRC カードであろうと、 こっくりさんであろうと、かまわないのです。

実際にみなさんがペアプログラミングしているようすを、楽しく観察していました。

ドライバーが、「Javaなんか1年くらい書いてないよ〜」と 言いながらびゅんびゅん実装して、パートナーを振り切るペアあり、

パートナーの方が 「そこはフツーequals() でしょ!?、ああ、それを やるなら FileReader ね」っと、マシンガン・アドバイスで 手動権を握り、ドライバーは言われたことを書いているだけ、というペアあり、

パートナーは両腕を組んで後ろに座り、肩越しから、 「ちがう」、「よし」、「そう」、「そこだ」と ゴルゴ13のように、 無口に狙撃するペアあり、

というように、それぞれ独自の コミュニケーション方法で、ペアプログラミングを楽しんでいたようです。

部屋の写真その2
佳境に入ってきたかも。うーん、そこはどうですかねぇ。

じゃんけんゲーム大会

実際の勝者を決定するのは、ストーリーの中の、 「マルチユーザ対戦用ストーリー」、すなわち大じゃんけんゲーム大会です。 それぞれのチームが作ったじゃんけん アルゴリズムを戦わせる訳です。

司会者の

さいしょは、グ〜
じゃんけん、ポン!

という掛け声と共に、全チームがリターンキーを押してファイルに「ぐー、ちょ き、ぱー」の手を書きこみます。全チームが書きこんだことを(口頭で)確認して、それから、あらかじめ準備した集計プログラムで集計して勝ち負けを決めます。デ ジタルとアナログが、仮想空間と現実空間が融合した、 コミュニケーション重視 のすばらしい企画です。ちなみに、この集計プログラムはモーフUIとサウンドを駆使した Squeak プログラムです。

集計プログラムの画像
じゃんけんポン! 実際はドラムロールなど、groovyなサウンドあり。

途中、ネットワーク回線が途切れる、ビューティペアが書き出すファイル名 を間違えていた(beauty.te でなくbuauty.te に書いていた!)というハプニングは あったものの、対戦は順調に進みました.

6チームあると「あいこ」がかなり出ます。最後の2チーム(N&Fと5年目ペアの一騎打ち)になったときには、 「もしかしたら同じアルゴリズム で永遠に勝負がつかないか!?」とも思えましたが、結局、 10回以上の対戦の結果、優勝は「5年目ペア」 の青木 淳夫さんと佐藤 治夫さんでした。

優勝者には、「ペアプロの友」として 「お茶とおせんべいのセット」が贈られました。 おめでとうございました。

ここで優勝者の声をきいてみましょう!

「JBuilderやVisualAgeを使いこなすJavaスペシャリストの他チームを相手に、メモ帳でコーディングした私たちのチームが優勝できたのは、やはりペアプロの友情パワーがどこにも負けなかったからだと信じています。優勝商品のお茶セットを食べつつ、これからもXPに励んでいきたいと思います!」 by 青木さん

Greatですね。立派なeXPertがまた誕生しました。


今回実践したプラクティス

XPにはプラクティスが12、一説には14ある、ということはみなさん ご存知と思います。今回の企画では、

を実践していただきました。

時間が2時間と短いため、計画ゲーム、オンサイト顧客などの 見積や顧客に関するにプラクティスは体験できませんでした。

とにかく、「じゃんけんをペアプロで、テストファーストで実装する」 ことだけに熱中していただきました。


アンケートより

終了後に、アンケートを行いました。小さな統計ですが、それぞれの プラクティスの有効さ、それからコメントをお願いしました。

それぞれのプラクティスの印象はどうですか?

◎ うまく機能した
○ 今一つ
× うまくいかない

ペアプログラミング ◎◎◎◎◎◎○○○○○○
テストファースト・デザイン ◎◎◎◎◎◎○○○○○×
ユニットテスト ◎◎◎◎◎◎○○○○○○
シンプルデザイン&リファクタリング ◎◎◎◎○○○○○○××

結果を見ると、ペアプロとユニットテストは、半数が◎と回答しており、 ×と答えた人はいませんでした。 また、シンプルデザイン&リファクタリングでは、◎は減り、×も2名 います。この短い時間では、やはりリファクタリングは困難だった ようです。その他のコメントとしては、以下のようなものがありました。

「体験XP」の最後には、全員に感想を発表していただきました. その中でExtreme Challengersの佃さんがおっしゃっていたように、 今回の体験時間内では、プラクティスが有効か?、という問いに答えるのは難 しい、というのがホントのところだと思います。 みなさんも、このような体験、あるいは、現場で一週間の小プロジェクト をやってみるなどして、ぜひ実際に試してみてください。

それからひとつだけ、

にコメントします(ビューティペアの秋間さん、質問ありがとう!)。 ぼくの私見では、「あるべき」 だと思います。XPは、「再利用可能なデザイン」を捨て、「変更に強いデザイン」を 捨て、「シンプルなデザイン」と「テストしやすいデザイン」を指向するべきだと思います。


さいごに

上記アンケートの中で、「おかしが食べたい」というのがありましたが、 ホテル側の都合で、 「体験ルームでは飲食禁止」ということが 直前に判明しました!

Σ(゚д゚lll)ガーン。

おかしのないペアプロなんて... なんたる不覚。せっかくおかし持参できていただいたみなさん、ごめんなさい...

最後に、このような企画に参加者してくださった皆さんに感謝します。 おかげ様で、講師として有意義な、そして楽しい時間を過ごすことができました. ありがとうございました。

おしまい。


配布資料

当日の配布資料は、3つです。 それぞれのリンクからダウンロード可能です。

  1. じゃんけんゲームのストーリー ... 今回の体験XPのストーリー
    JankenStory.pdf
  2. JUnitによるテストファースト・デザイン ... JUnit の簡単な使い方。テストファースト設計の進め方
    TestFirstWithJUnit.pdf
  3. ペアプログラミング10則 ... ペアプログラミングを行う際の注意点とコツ
    10PrinciplesOfPairProgramming.pdf

以上

© 2001 OGIS-RI Co., Ltd.
Index
Index