XP寺子屋第5回「ペアプロ体験」ふりかえり

盛況の内に終了しました。

あらかじめ参加者にパソコンとペアを各自用意して頂いた。その結果，欠席者ゼロというスゴイ記録が生まれた。通常，参加者の１〜２割が欠席するのが常識となっているのに，「欠席者ゼロ」とはスゴイ事である！

当初，参加条件が厳しかったためか参加者集まらなくて焦りを感じたので，下記２点の初の試みを実施。

■その１：資料の事前公開
いつも資料は当日まで公開されないが，参加者が内容を事前に把握した方が安心できると思い，事前公開してみた。

■その２：目立つテンプレートの使用
見た人に興味を持ってもらう様，目立つテンプレートを使用した。
いつもお世話になっているMS様のテンプレートでは物足りず，フリーのテンプレートを探し，印象に残るものをチョイス。

実際のワークも盛り上がった。
最初の15分でインストラクション＆アイスブレイク。アイスブレイクで久々に「しりとらず」を実施したが，凍り付いた場が数分で和やかな空気に変わるのを感じた。
残りの時間をペアプロに割り当てた。あるペアはタスクかんばんを使い，あるペアはデザインパターンで熱い議論を交わし，会場は静かにヒートアップ

最後に「拍手２回でふりかえり」を行い全員の感想をシェア。「有効なやり方」「会社では教えられない細かい事を指導できた」「楽しかった」「もっとやりたい」等々，前向きな意見が多かった。

◆◆◆◆◆◆◆◆◆
自分自信のふりかえり

■KEEP
・ペアプロのワークショップを実現した
・期待していた効果が得られた
・参加者が１０名を超えた
・ソフト業界以外の方も参加

■PROBREM
・ヘルプファイルを忘れていた
・見学者への対応が不十分だった
・自分も開発していたので十分フォローできなかった

■TRY
・XP寺子屋継続
・XPの全プラクティスを使ったWSの開催
・IT業界へのペアプロの展開


これからも，XP寺子屋を続けて行きたい。

XPの真価を伝えたい

2007年，XPJUG関西のスタッフにして頂いた。

当時，「XPをもっと世間」に広めたいという思いを強く持っていた。

人に自分の知識を教えるのが好きな性格だったため，XPJUG関西を通じて誰かにXPの良さを伝えたかった。それを形にしたのが「XP寺子屋」である。

今まで通算4回開催し，本当に多くの方々に参加頂き，様々な気付きを頂いた。

今月，5回目を開催する。
内容は，念願のペアプログラミング。「やってみたいXPのプラクティス」で常に上位にランキングされるプラクティスである。

ただ，予算の都合上，様々な制約事項をつけなければならなかった。

機会があれば，制約事項を減らして再度企画してみたい。

ペアプログラミング

ＸＰのプラクティスの中で注目度の高いプラクティスの一つである「ペアプログラミング」、通称「ペアプロ」。

「ＸＰを知ってますか？」と聞くと、殆どの方が「ＴＤＤとかペアプロするんですよね」と答える、ＸＰの代名詞と言っても過言ではないプラクティスである。

ＴＤＤ、リファクタリング、コード共同所有、シンプル設計、ペアプロなど、開発に直結するプラクティスの内、ペアプロだけが一人で試すことができない。できないからこそ、注目度が高いのではないのだろうか。

或いは、「２人で１台のパソコンを使って開発すると、生産性を落とさず高品質になる」という、従来の考え方（個々人の能力の高さが生産性と品質に直結する）と相反する考え方だからだろうか。

私は、両方の理由からペアプロに挑戦しようと考え、約３年間取り組んできた。
その経験から学んだ事は、「ペアプロは、ペアを組む相手により結果が変化する」という事である。
 特に、ペアプロを有効と感じないメンバーが居るプロジェクトでは、上手く機能しない。つまり、２人１組で開発することの弱点となる。

ここを上手くクリアできなかればべ、ペアプの有効性を感じることは難しい。

XPと受託開発はマッチしない

「XP祭り関西2010」が無事終了した。
今回のテーマは「アジャイルマインドの育て方」となっており，ご登壇頂いた皆さん，アジャイルマインドについて，熱く×100語っていた。
特にpapandaさんの熱さには驚かされた。
◆　◆　◆
基調講演で「XPと受託開発はマッチしない」というお話しがあった。
曰く，「品質よりスピード」，「シンプルより多機能」，「（契約の関係で）複数回リリースより１回リリース」という，XPと異なる価値を重視しているためである，と。
「XPはお客様と協調し，良い製品を作るための手法だ」と言われて久しいが，（少なくとも）日本ではXPの価値がお客様の満足度に貢献できていない様に感じる。
お客様にとって，開発手法は重要ではない。「XPは素晴らしい」と言っても，お客様の満足が得られなければそれは技術者の自己満足でしかない。
イベント終了後，知人とそんな話をしていると，ふとアイディアが浮かんだ。
「受託開発者で，お客様が満足するプラクティスを開発する」
ケント・ベックが教えてくれた「プラクティス」を実践するという事は，「守破離」で言う『守』の段階である。だから，受託開発に最適化したプラクティスを開発（『破』）し，成功（『離』）を目指さなければ単なる開発者の自己満足で終わってしまう。

そして，一番重要なのは「XPとは変わる事」だという事。
XPの本質は「ソフトウェア開発において正しい事を最大限に実行する事」であると考えている。その考えに基き，価値と原則とプラクティスが策定されたはずであるが，「価値・原則・プラクティス」は，プロジェクトや前提条件によって変化するのではないだろうか。
ならば，「日本の受託開発」という前提条件を満たす「価値・原則・プラクティス」を考えればよいのではないか。

一つ言える事は，「現状のソフト開発スピードでは，顧客満足が得られない」という事。
ハードウェアスペックの向上によりコンパイル時間は短縮された。次の10年ではソフト開発の時間短縮が実現されるだろう。
その時，XPはどんな進化を遂げているのだろうか。

アジャイル・マインド

「アジャイルを実践している人は，自発的にアジャイルの布教活動を行なう人が多い」

-XPJUG関西代表　細谷氏　談-

経験的に，アジャイル開発実践者は自ら率先して様々な活動を展開する。

ある人は本を書き，ある人はセミナーを開き，ある人はコミュニティーを立ち上げ，ある人は会社でアジャイルを広めようと活動し，ある人は独立してアジャイル開発を実践する会社を作る。

この様に，自発的行動を起こす人が，アジャイル開発実践者の中に多く見られることから，「アジャイル開発実践者によく見られる自発的行動へと駆り立てる心（スピリット）」の事を「アジャイル・マインド」と名付けた。

アジャイル・マインドを持つ開発者が増えれば業界が良くなると考えている。

今年開催される「XP祭り関西2010」では，「アジャイル・マインドの育て方」をキーワードにしたセッションが多数行われる。

このイベントの参加者の中からアジャイル・マインドに目覚める人が一人でも多く現れる事を願わずにはいられない。

「アジャイルって良いのですか？」

「マクドナルドのテキサスバーガーって美味しいのですか？」と同じレベルの質問だと思う。

マスコミやネットで騒がれているが，美味しいかどうかは本人が食べてみなければ判らない。食べてみて美味しいと感じる人も居れば美味しくないと感じる人も居る。

ソフトウェアの開発手法にしても，合う・合わないがあるのではないだろうか。問題は，情報量の少なさだと思う。

専門学校や大学で，アジャイルについて十分教育がなされていないから，認知度が低いのである。

もっと大きな問題は，ソフトウェア開発者が儲らないという点。儲らない業種に学生は集まらないから，授業で取り上げる価値が低いのは当然である。

老体に鞭打って勉強会の場だけでアジャイルを伝えるのは，間違いだと思う。

Agile2.0について思うこと。

「アジャイル」という言葉に、どの様な感想をお持ちだろうか。

10/1/14に、「AGILE2.0 〜 アジャイルなチームで何を提供する？」というタイトルのイベンが開催された。
http://kokucheese.com/event/index/1151/

ちょっと気になって「アジャル２．０」でググッてみると、実は２００６年にも「アジャイル２．０」という言葉が登場する。

■アジャイル2.0ホームコミュニティ
■アジャイルな世界
■Agile, Orthodoxy and a Message From God

だからどうという訳ではないが。

---

最近、某ＩＴ系出版業界の方とお話した際、「最近、”アジャイル”というキーワードの本は、まったく売れなくなった」と聞いた。個人的には最近、アジャイル関係の書籍が多数出版され、読み手も飽きたのではないかと推測している。

話を戻そう。

私は、「アジャイル２．０」という言葉に大きな違和感を抱いている。
アジャイルを簡潔に表現すると「ソフトウェアを素早くしっかり作りましょう」という基本的理念の呼び名であり、この基本的理念は何も変わっていない（はずである）。

「ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法郡の総称である。」

－ウィキペディアからの引用－


「アジャイル開発手法」＝「イテレーション型開発手法」と言われたり書かれたりしているが、実はそうではない。「ソフトウェアを素早くしっかり作る」ことが本質であり、「イテレーション型開発手法」はその実現手段の一つに過ぎない。アジャイル２．０で語られている多くは、実現方法やソフトウェアの品質保証、開発プロセスなど多岐に渡っているが、結局実現手段に関する話題が主体となってる。

「アジャイル開発」の本質は「ソフトウェアを素早くしっかり作りましょう」であり、「イテレーション開発」、「eXtream Programmming」、「スクラム」を実施することではない。この点を見誤ってしまうと、2000年に起こった「アジャイル開発手法の誤解によるプロジェクトの失敗」の再来が起きる。

2000年に「アジャイル開発手法」が日本に上陸した際、アジャイルの誤解による悲劇が起こったと聞く。下記の内容を本気で信じて開発しても、失敗することは明らかである。

・ドキュメントは書かなくても良い

・設計よりもプログラミングを重視する

etc,ect･･････

「アジャイル２．０」、「TiDD」、「スクラム」など、それ単体で確かに価値のある方法であると言えるが、万能な方法ではないことを理解する必要がある。「それは本当に自分にとって有効なのか？」と、常に疑ってかかった方が良い。そうしなければ、アジャイルの誤解によるプロジェクトの失敗を招く結果となる。

他人の考えを鵜呑みするのは簡単だが、それでは失敗してしまう。だから、他人の意見が自分にとって有効か無効か考えて判断することが必要であると言える。