場所 ：SRCセミナールーム (東京・高田馬場)
日時 ：2001/12/20 (木) 〜 21 (金)
主催 ：SRC
講師 ：中山 秀樹 氏

1.エクストリーム・プログラミング（XP）入門解説

2.エクストリーム・プログラミング（XP）解決技術解説

3.リファクタリング導入技術解説

4.リファクタリング基礎技術解説

• ウォーターフォールは元元ハードウェアの製造工程をソフトウェアに流用したもの
  
  「ソフトウェアはハードウェアのおまけの時代」だった
  
  
• しかしハードウェア開発とソフトウェア開発では性質が異なる
  
• ハードウェアでは製造途中や製造後に機能を変更する事はない
  
• 「子供が生まれた時に成人する迄の服を纏(まと)め買いする」のがウォーターフォール型
  
  XP では「子供の成長に合わせて服を買う」
  
  
• ウォーターフォールはナンセンス -> でも中中脱皮出来ない
  
• ウォーターフォール -> スパイラル -> 新しいスパイラル開発へ

• '80 年代頃〜 Smalltalker 達のコミュニティで XP のプラクティスのような実践
  
• 2000 年になって Kent Beck 等から XP の流行 <- 背景として最近の Java 等に因る第二次オブジェクト指向方法論ブーム
  

• 先ず Kent Beck の本を読んで Kent Beck の真似をしよう
  
• 次に Kent Beck が読んだ本を読もう
  

○ 先ず前提として - ソフトウェア開発上のリスクについて

・「スケジュールの遅れ」，「プロジェクトの中断」，「システムの陳腐化」，「システムの欠陥」，「ビジネスのへの認識の不足」，「ビジネスの変化」，「機能が利益を生まない」，「スタッフが居なくなる」
-> プラクティスを実践しよう

○ オンサイト顧客 (On-Site Customer) - チーム全体 (Whole Team)

・顧客に理解してもらう

・顧客の承認の元 Proxy (代理人) を置く手も有る

・「ソフトウェア作業には製品顧客とソフトウェア開発者間の定常的な対話が必要である」(ワインバーグ)

○ 計画ゲーム (Planning Game)

・顧客と開発者の間で「ルールを作る」

・「目標の無いバーは跳び越せない」

・顧客が作る (ストーリーカードに書くのはプログラマでも良いし UML で書いても良いが理解し承認してもらう: ストーリーカードに印鑑を押す等)

・時間又は御金で見積もる

○ 小さなリリース (Small Releases)

・少品種多量生産 -> 多品種少量生産の時代へ

・ビジネス的に価値の在るものから小さいリリースを繰り返す
    「一年後の天気」は判らないでしょ?

・寧ろベンチャー ビジネス向け

○ シンプルな設計 (Simple Design)

・Let's KISS (Keep It Small and Simple)

・Once And Only Once

・「全てのテストに合格」して「表現すべき考えが網羅されている」最も少ないコード

・how だけでなく what がコード上に表現されているか

  例.
    ・悪い例 (コメントで説明)

    ・良い例 (コメントは不要)

・「若しスケジュールを守る事が最優先なら最先端技術には近づくな」(ワインバーグ)

・「其の人にとってのシンプルさ」を目指すべき
    例えば「デザインパターン」が其の人にとって「消化されている技術」なら「デザインパターン」を使う事がシンプル

・シンプルにするのは簡単ではない

・「モデル要素は大き過ぎてはならない (さもなければ反応が遅く成る)」(ワインバーグ)

○ ペアプログラミング (Pair Programming)

・何故ペア プログラミングは効果的なのか
    1 + 1 が 3 にも 4 にも成り得るから
    一人一人では発想に限界がある
    どちらも持っていなかった発想が二人だと生まれる
    ペアを組替える事で全体に其れが広がって行く

・プログラマとプログラマのペアだけとは限らない (プログラマと顧客のペア等)

・「仲良しグループ」に成らないように

○ テスティング (Testing) - テストファースト開発 (Test-First Development)，顧客テスト(Customer Tests)

・テストケースはストーリーを満たすものだけを作る
    テストのカバレッジは十分か?
    ストーリーに書かれていない事は顧客との契約には無い
    ストーリーに在る事について 100% テストする

○ リファクタリング (Refactoring) - 設計の改善 (Design Improvement)

・地道な作業

・対費用効果が見え難い (顧客から)

・スケジュールを立てる時には，コーディング時間 (デバッグ時間)，テストの時間の他にリファクタリングの時間も入れておこう

・毎日リファクタリングしよう
    「食後の歯磨き」のように．最初は面倒に感じるけれど，習慣にすれば其の内リファクタリングしないと気持ち悪く感じるように成る．

○ 継続的インテグレーション (Continuous Integration)

・結合テストに失敗したら結合を放棄して最初から

○ メタファー (Metaphor)

・共通の用語 (概念) で短い言葉でコミュニケート

・問題について適当な抽象度でコミュニケート

○ 共同所有 (Collective Ownership) - コードの共同所有 (Collective Code Ownership)

・「無所属モデル」でも「個別所有モデル」でもない

・「所有者がいない」のでなく「全員が所有者 (責任者)」

・全体の規模が大きく成っても「シンプルな設計」であれば大丈夫

・個人の成果は無い -> どう評価する?
    評価し合う (ポイント制等)
    「個人の成績よりチームの勝利」
    個人プレーの方が効率が良い人もいる -> XP に向かない人 -> XP のチームから外してアドバイザ等に成ってもらう

○ コーディング標準 (Coding Standard)

・プログラマの個性が出ないように

・決めたら従う
    「どうしても嫌」なら "indent" のようなツールを使って，自分のコーディング時だけ別のスタイルにする

・ツールが使えるなら使って良い

・「JDK に合わせる」のような決め方も有る

・「日本語でプログラミングして良いかどうか」も決める

○ 40 時間労働 (40-Hour Week) - 持続可能なペース (Sustainable Pace)

・40 時間とあるが最適な週当たりの労働時間は人によって異なる
    もっとも効率的に働ける時間を元に計画を立てる

・実際の開発でこの時間を超えるようなら「危険信号」 -> プランニングを見直す為のフィードバックにする (そうしないと「其の場凌ぎ」に成る)

○ オープン ワークスペース(Open Workspace)

・集中している時に一分でも割り込まれると元の集中力を取り戻すには時間が掛かる -> 理想的なエンジニアリング時間で仕事をするには「閉鎖的な空間」も必要

・手の届く範囲にものを置くのが効率が良い -> 其の範囲が其の人のテリトリー (「閉鎖的空間」)

・ペア プログラミングの時も同様 (其のペアにとっての「閉鎖的な空間」が必要)

  例.  (Visio で筆者が作成)
    ・有り勝ちなレイアウト： 「此れで能率上がります?」

○ プログラマ

・分析，設計，テスト，実装，結合等を行う
・XP の主役

○ 顧客

・XP の顧客に成るのは容易ではない
・「ストーリーに盛り込んだ内容を受け取る」と云う契約である事を理解する
・顧客のコスト (人件費) も開発費に盛り込むべき
・開発していない時は本来の自分の仕事をしていて構わない
・エンドユーザーが参加出来ない時はエンドユーザーを代弁出来る人
・権限の有る人でないと駄目 (権限の無い人と長時間話をしても何も決まらない)
・「開発者が選択肢を示さない限り顧客は自分の真の要求に気付かない」(ワインバーグ)

○ テスト担当者

・顧客の (曖昧な) 要求に従って現実的なテストを構築

○ トラッカー

・予算と対費用効果のデータを取る
・ツール・テスト・アンケート等の評価を行う
・レポートを作って開発チーム，顧客，管理者にレビューする
・チームに新しく入った人には先ずはトラッカーをやらせてみると良い
・二人一組でやらせても良い (ペア プログラミング)

○ コーチ

・XP をより深く理解している
・XP の導入時は重要 -> チームが成長して行くに従って役割は小さく成って行く
・幾つかの XP チームを掛け持ちしても良い

○ コンサルタント

・顧客だけでは問題領域への解決策が判らないとき等
・問題の解き方をアドバイスする
・XP の専門家である必要は無い

○ 上司

・資源を割り当てる
・必要でない時は邪魔をしないように

・とても Cool な研修であった．XP な人と云うのはどうして皆楽しいのだろう．
この際なので (謎) 一番前の真中に陣取って，様様な疑問点の解消を図った．

・「XP 流の研修」との事．

私流に解釈すると，

1. 顧客 (受講生) のリクエストで始める
2. 顧客からのフィードバックによって次の内容を決めたり内容を修正したりする
3. 顧客を研修に参加させる (此れが難しい… 先ずは受講生の名前を覚えて呼び掛けてみよう)
4. 目的は? 顧客にとっての価値を最大にする事

見習わないと…

・(研修は良かったが) 大切なのは実践．先ずはワークショップから始めよう．

・XP は実践が難しそうな気がしていたが，実は技術的な問題は其れ程大きくない．「やるか，やらないか」の問題が最大のものである．実は「やらない」理由を探すのは簡単だと思う．唯 XP が現在のプロセスより役に立たない事を証明するのはとても困難だと思う．

・品質には金が掛かる -> でも金は無い．こんな時に XP は最適かも．対費用効果が良さそう．RUP だと毎年 & プロジェクト毎に結構な金が掛かりそう．

タイトル：XP 祭り 2002
場所 ：国立オリンピック記念青少年総合センター 417号室
日時 ：2002/7/8（月）
主催 ：日本XPユーザグループ

■ 「XP、はじめの一歩」
(株) テントアーニ 木幡 善文

• 先ずは基本的なプラクティスから
  
  • 顧客が参加しない
  • チームで一斉にやらなくても可
  • 他のプラクティスへの依存が少ない
  • 単独で効果が有りそう
  • 例えば三つのプラクティス
    
    • ペア プログラミング
    • テスト ファースト
    • リファクタリング


• ツールの使用
  
  • ユニット テスト
    テスティング ツール JUnit (*1)
  • 継続的な統合とコードの共同所有
    バージョン管理ツール CVS (*2)

(*1) JUnit.org <http://www.junit.org/> を参照のこと
(*2) CVS Home <http://www.cvshome.org/> を参照のこと

■ 「Scrumの紹介とXPへの適用」
梅澤 真史

• XP に限界を感じる部分
• Scrum (*3) の歴史
• Scrum の概要
• XP との違い
• XP にどう適用していくか

(*3) メタボリックス - SCRUM: 超生産的ソフトウェア開発のための拡張パターン言語 <http://www.metabolics.co.jp/XP/Scrum/Scrum.html> を参照のこと

■ 「がんばれC++/CppUnit」
'河童'プロジェクト επιστημη/もりりん

• '河童'プロジェクト (*4) による CppUnit のための各種ツールと「テスト ファースト デザイン」の実演
  
  • 子河童 (cocuppa): CppUnit のためのテストコードの雛形を作ってくれる
  • 子狐 (cofox): (マルチ プラットフォーム GUI ライブラリ "FOX" を使用した子河童の GUI 版．

(*4) SourceForge.jp: Project Info - 河童 <https://sourceforge.jp/projects/cuppa/> を参照のこと

■ 「ネットワーク管理アプリケーション開発におけるXP利用報告」
横河電機株式会社 R&D IT プロジェクトセンター 井上 健 ・ 山川利治

• 新人を三人を含む四人のプロジェクト
• 新人の XP による教育効果
  • ペア プログラミングによる教育
  • XP の「ハート」の伝授
• XP 導入結果
  • 各プラクティスはどの位適用出来たか

■ 「週一放課後XPでZopeProduct作成」
eXtremeWays チーム

• 週一回集まって勉強会
• Zope (*5) を使った開発
• Python (*6) による開発
• Wiki (*7) で会議を行っている
• XPlanner (*8) の使用
• 勉強会のこつ

(*5) Web アプリケーション サーバー，コンテンツ マネジメント システム，Web アプリケーション開発環境．日本Zopeユーザ会 <http://zope.jp/> を参照のこと．
(*6) オブジェクト指向スクリプト言語．日本Pythonユーザ会（PyJUG） <http://www.python.jp/> を参照のこと．
(*7) WikiWikiWeb <http://www.c2.com/cgi/wiki> や zwiki.org <http://zwiki.org/> を参照のこと．
(*8) XPlanner <http://xplanner.sourceforge.net/> を参照のこと．

■ 抽選会

・私は，「Java 開発者のためのアンチ デザインパターン」 (*9) という本が当たりました．

(*9) Amazon.co.jp： Java開発者のためのアンチデザインパターン―失敗を回避する秘訣 <http://www.amazon.co.jp/exec/obidos/ASIN/4774114901/qid%3D1026805849/249-9007428-5189111> を参照のこと．

■ ライトニング・トーク
持ち時間 5 分の範囲で十人位の講演者が自由に講演

• XP のゲーム
  
  • eXtreme Hour (*10)
  • Pair Draw (*11)
  • XP カード ゲーム
    


• Agile 原理主義
  
  • プリペード型契約: 白紙のタスク カードを渡す (*12)
    


• Zope の紹介
  
  • <http://zope.jp/>
  • <http://mojix.org/>
  • <http://zwiki.org/>
    


• UP + XP = UXP の紹介
• ペアプロ環境
• XP に最適なお菓子

等等

(*10) Extreme Hour <http://c2.com/cgi/wiki?ExtremeHour> や メタボリックス - Extreme Hour <http://www.metabolics.co.jp/XP/ExtremeHours.html> を参照のこと
(*11) Industrial Logic - PairDraw <http://www.industriallogic.com/games/pairdraw.html> を参照のこと
(*12) 日本ＸＰユーザグループ関西支部 <http://members6.tsukaeru.net/xpjug-kansai/> -「ＸＰのビジネスメリット」を参照のこと．

今回，XP に関する沢山のホットな実践を識ることが出来た．

XP の「三段階の習熟度レベル」

• レベル 1: 本に書かれたとおりに全てのプラクティスを実践する．
• レベル 2: XP をローカルな条件に適応させる．
• レベル 3: もう XP を実践しているかどうかなんて，気に止めたりしない．

XP 等の開発プロセスはあくまでも「勝つ」為の手段なので，「開発プロセスをどう使って勝つか」を考えて行かなければならない訳である (*13) が，その為には，今回のような場で多くの実践を見聞きして行くことが不可欠であると考えている．

(*13) 開発プロセスを使わずに勝とうとする人もいる．
それどころか失敗したか成功したかの評価の予定すらないプロジェクトが沢山進められているらしい．
それでどうやって「勝つ」というのだろう．「負け」を認めていないだけなのではないだろうか．

「戦わなきゃ現実と!」(アポジカ風)

タイトル：エクストリーム・プログラミング & アジャイル開発プロセスセミナー (eXtreme Programming & Agile Software Development)
場所 ：大手町サンケイプラザ 4Fホール
日時 ：2002/09/09(月) 〜 10(火)
主催 ：日本XPユーザグループ，(株)テクノロジックアート，(株)エクイティ・リサーチ

• 09/09
  
  • [挨拶]
    (株)テクノロジックアート 代表取締役 長瀬 嘉秀氏
  • 『看板方式とソフトウェア開発』 (Lean Software Production)
    スリーリバーズ インスティチュート ファウンディングディレクター ケント・ベック (Kent Beck) 氏
  • 『さまざまなアジャイル開発プロセスとその適用』
    メタボリックス 代表取締役 山田 正樹氏
  • 『アジャイル開発方法論への流れ』 (Agile Software Development Part1 〜 Understanding for Agility 〜)
    ヒューマンズ アンド テクノロジー コンサルティングフェロー アリスター・コーバーン (Alistair Cockburn) 氏
  • 日本XPユーザグループによる懇親会


• 09/10
  
  • [挨拶]
    (株)エクイティ・リサーチ 取締役 大槻 繁氏
  • 『アジャイル・ソフトウェア開発概要』 (Agile Software Development Part2)
    アリスター・コーバーン氏
  • 『複雑さと情報処理』
    東京大学工学部計数学科 工学博士 合原 一幸教授
  • 『テスト駆動開発』 (Test Driven Development)
    ケント・ベック氏
  • 講演者による Q&A