エクストリームプログラミング（XP）は大変興味深いものだが、
はっきり言って従来の常識ではとんでもないと思ってしまう開発手法だ。
では、なぜこの開発手法が注目されているのか？
根拠はどこにあるのか？
無根拠でいきなりこんなことを言い出すやつはいないし、賛同するやつもいない。
みんなどこかで、この方法がある程度有効だなと思う経験や知識があるはずである。
ということを、勉強のために、少ない経験から推察し、
一見常識はずれでありそうでも、実はしっかりとした従来からある理論に基づいていそうなことを示す。
と、言っても自分の読んだことのあるものからしかとってこれないのですが。
読書量の不足分は[1]「ソフトウェア開発２０１の鉄則」でおぎないましょう。（いい本だね）
問題はなぜこれらを組み合わせると、効率がいいのか？
そもそも本当に効率がよくなるのか？
内容はeXtreme programming FAQより、紹介も兼ねて勝手に引用してしまう。
計画ゲーム(The Planning Game)
ビジネス優先度と技術的見積により次回リリースの範囲を早急に決める。現実が計画と変わったら、計画を更新する。
[1]「ソフトウェア開発２０１の鉄則」 原理１５９「計画を常に更新せよ」状況が変化したときは必ず計画を更新せよ。このような状況には、要求しようの変更、日程からの贈れ、方針の変更、過剰なエラーの発見、またはその他の当初の条件からのずれを含む。
小規模リリース(Small Releases)
シンプルなシステムを早急に生産に投入する、それから新バージョンを非常に短いサイクルでリリースしていく。
これは間違いなくかの有名な[2]「伽藍とバザール」で説明できるでしょう。
と思ったけどちょっと違うような気がしてきた。7. はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこと〜〜（中略）〜〜〜〜〜〜〜〜〜〜〜
じゃあ、もし急速リリースと、インターネットの徹底的な使い倒しが偶然ではなくて、労力を最小限ですまそうとするリーヌスのエンジニアリング上の天才的洞察の不可欠な部分だったんなら、かれが最大化しているのは何だったんだろう。この仕組みからかれがひねりだしているのはなんだったんだろう。
こういう問題のたてかたをすれば、質問自体が答になる。リーヌスは、ハッカー/ユーザたちをたえず刺激して、ごほうびを与え続けたってことだ。刺激は、全体の動きの中で一員となることでエゴを満足させられるという見込みで、ごほうびは、自分たちの仕事がたえず（まさに毎日のように）進歩している様子だ。
比喩(Metaphor)
どの様に全体のシステムが機能するかを示すシンプルな喩え話(メタファー)をメンバーが共有することで全ての開発を導く（ガイドする）。
不明たしかに概念を共有するのは重要だが、たいていは仕様書がその役割を担うため、微妙に違ってくる。
明確にこのことをうたっている文献は記憶にない。
シンプルデザイン(Simple Design)
いつでもシステムは出来る限りシンプルに設計されるべきだ。余分な複雑さは見つけ次第取り除かれる。
[1]「ソフトウェア開発２０１の鉄則」 原理６７「単純に作れ」
単純な基本構造、または単純なアルゴリズムは、高い保守性の達成に向けての一里塚である。
「常に単純さを保て」を座右の名にせよ。
テスティング(Testing)
プログラマは継続的にユニットテストを書く、それは開発を続けるために完全に動かなければならない。顧客は、機能の開発が終わったことを示す機能テストを書く。
[1]「ソフトウェア開発２０１の鉄則」 原理108「テストを行う時期よりずっと前にテストを計画せよ」
テスト計画を作ることは重要な仕事であって、製品の開発と平行して行う必要があるので、テスト計画の作成と初期の（すなわちテスト以前の）開発作業は同時に完了する必要がある。[1]「ソフトウェア開発２０１の鉄則」 原理123「単体テスティングが済む前に統合するな」遅れた日程を取り戻すためのはかない試みとして、別々に単体テストを行っていないコンポーネントが往々にしてサブシステムに統合されることがある。そのような試みは、実際にさらにひどい日程の遅延をもたらす。[2]「伽藍とバザール」Linux の場合の特別な性格で、デルファイ効果的な形でとても役にたっているのは、どんなプロジェクトでもその貢献者は自薦だということだ。初期にコメントをくれた人が指摘してくれたことだけれど、貢献は、ランダムなサンプルから出てくる訳じゃなくて、そのソフトを使うだけの興味を持って、その仕組みを学び、出くわした問題への解決を探そうとして、まあまともそうな解決策を作るだけのことをした人から寄せられる。これだけのフィルタを全部突破してくる人は、貢献できるだけのものは持っている可能性がかなり高い。
リファクタリング(Refactoring)
２重コードを取り去り、コミュニケーションを改善し、単純化し、柔軟性を加えるために、プログラマは、システムの動作を換えることなくシステムを再構成する。
[3]「リファクタリング」というそのものずばりの本があります。
が、著者とXPの提唱者が多分同一人物なので、真実味は少し低いですが、カプセル化で説明できるの…か？
今日買ってきたばかりで読んでないので。
ペアプログラミング(Pair Programming)
全てのコードは２人のプログラマにより一台のマシンで書かれる。
[4]「プログラミングの心理学 または、ハイテクノロジーの人間学」P82〜「エゴレス方式」（ビルの13行のプログラムに対し、マリリンは17個のバグを見つけたことに対し）
マリリンの方も、この問題について自分がした仕事に不当な自信を持ったりしなかった。彼女は、17個もの誤りが見つかったのだから、多分後いくつか有るだろう、と考えた。特に彼女は、そのプログラムを長い時間いじってきたために、最初から自分で書いたのではないにもかかわらず、それがもうビルと同程度に頭に入ってしまっている、ということを知っていた。彼女の判断は正しかった。ビルが自分の失敗を肴にしてみんなを笑わせている間に、マリリンとほかの批評家達は、その日が終わるまでにあと3個の誤りを見つけたのである。
テスティング(Testing)をそのまま適用すると発生する
[1]「ソフトウェア開発２０１の鉄則」 原理109「自分のソフトウェアを自分でテストするな」
[1]「ソフトウェア開発２０１の鉄則」 原理110「自分のソフトウェアのテスト計画を自分で作成するな」
の矛盾に対する解答にもなる他にもいろいろ考えられますが、問題は二人で一つということは作業効率は二倍以上必要ということ。
でも、いけそうな気がする。（要スキル）ラピットディベロップメントという本に、ペアプログラミングについて詳しく載っているそうだ。
共同所有権(Collective Ownership)
誰でも、どのコードでも、どこででも、いつでも、プログラマはコードを修正できる。
[4]「プログラミングの心理学 または、ハイテクノロジーの人間学」P82〜「エゴレス方式」プログラムの交換は、可能な限り常に行われたので、誰も他の誰かに批判されていると感じるような立場にはならなかった。だが、ビルの場合、彼はこの方法になれ尽くしていたので、交換条件になっていようといまいと、それは同じことだった。ことプログラミングに関しては、こそこそ隠し立てをして、俺のプログラム、おまえのプログラムなどと考えるのは誤り、開放的で共有的名やりかたが正しい、というのが彼の価値観だった。彼が書いたプログラム（「彼の」プログラムではないーそう言ういい肩はこの職場では使われないのだから）に誤りが発見されたとすれば、将来の改良のために事実が明らかにされた、というだけのことであって、断じて彼個人へのこうげきではなかったのである。
継続的インテグレーション(Continuous Integration)
システムを一日に何回もインテグレードしビルドし、テストを
100% パスさせる．
[5]「デスマーチ なぜソフトウェアプロジェクトは混乱するのか」ｐ149〜「毎日の構築」という概念MicroSoft社のVisualC++製品のマネージャであり、Dynamics of Software Developmentの著者でも有るJim McCarthyが好んで言うように、「毎日の構築は、プロジェクトの心臓の鼓動であり、これがプロジェクトマネージャがプロジェクトが生きていることを知る方法なのだ」。そして、デスマーチプロジェクトのまねーじゃにとって、これ以上優先度の高い重要なものは、ほとんどないはずだ。もし、一週間過ぎてもぬかるみにはまったときのタイヤのように、みんなが空回りするばかりで、この新奇なオブジェクト指向データベースが、彼らが開発しているクライアント／サーバのアプリケーションと正しく通信できないことを、誰もプロジェクトマネージャに報告する神経を持たなければ、プロジェクトは大幅に日程を遅れるだろう。（2001/6/6追記 ）
[7]「人月の神話」p186複雑なソフトウェアシステムは、それ以上に働き、動き、処理するものだ。そうした働きのダイナミクスを創造するのは難しい。したがってソフトウェアのはたらきを計画する場合、顧客とデザイナーとの間であらゆることについて繰り返し話し合うことをシステム定義の一部として認めることが必要である。
私はさらに一歩進んで、顧客にとって、たとえソフトウェアエンジニアとこのように仕事をしているとしても、自分で用件を指定した製品を数バージョン構築して使ってみたことがなければ、完全に的確にしかも正確に現代のソフトウェア製品の正しい用件を指定することは、実際問題不可能だといいたい。
週40時間(40-Hour Week)
週４０時間以上仕事をしてはいけないのがルール。
[6]「デッドラインソフト開発を成功に導く101の法則」p198「時間外労働のマイナス要素はみんな知ってるわ。燃え尽き、エネルギーの低下、ミスの増加…」
「通常勤務時間の無駄が増える」とアリストテレスが付け加えた。
「どうして」
「何度もミーティングがあったり、中断があったりしても、夜に取り戻せばいいと思うようになるからさ」
「なるほどね。残業を許さないといえば、効率良く行動せざるを得ない」
ピープルウェアに載っていそうな気がするが、手に入らない。
オンサイト顧客(On-Site Customer)
現実のユーザをチームに加えて、フルタイムで質問に答えられるようにする。
どこかで適当な文書を読んだ記憶があるのだが、失念。（2001/6/6追記 辻 忠一さん提供の情報より）
[7]「人月の神話」p186ソフトウエア製作者が顧客のために行う最も重要な仕事は、製品の用件を繰り返し抽出し、洗練していくことだ。実際のところ、顧客自信何を希望しているのかわかっていないものだ。彼らは通常、どんな質問に答えなくてはならないかを理解しておらず、指定しなければならない問題の詳細さについて考えたことなどほとんどない。「これまで人がやっていた情報処理作業と同じように動く新しいソフトウェアシステムを作ってくれ」という単純な答えでは、実際まさしく単純すぎる。顧客は、性格にそれを望んでいるのではない。複雑なソフトウェアシステムは、それ以上に働き、動き、処理するものだ。そうした働きのダイナミクスを創造するのは難しい。したがってソフトウェアのはたらきを計画する場合、顧客とデザイナーとの間であらゆることについて繰り返し話し合うことをシステム定義の一部として認めることが必要である。
コーディング標準(Coding Standards)
プログラマは、コーディング標準に従って全てのコードを書く。
当たり前すぎて、手元にある文献には重要性を解くものがなかった。
後記：
「ソフトウェア開発でもっとも重要なのはピープルウェアである。」とデマルコが言っていた気がするが、このことを正しいとするならば、ソフトウェア工学はどうなるのか？開発手法はどうすべきなのか？
「ソフトウェア開発に銀の弾丸はない」のであるならば、どんなに新しい開発手法を開発しても、（将来的に大きな差になろうとも）それが受け入れられる可能性は少ない。
１０％程度の改善のために「QWERTY」配置のキーボードを捨てることができないのと同じ原理だ。
つまり、開発手法の研究も大事だが、我々が求めているのは優秀な人材である。
しかし、優秀な人材が自動的に生まれてくるのを待っているわけにはいかない。100倍近い生産性を誇る彼らの人数は少なすぎる。
これから求められる手法は従来の「無能な人材を底上げする」だけでなく、「優秀な人材を育成する教育方法、それも仕事をこなしながら」または「ブルックスの法則を覆す人月の置換を可能とする画期的な手法」だ。
「どちらも無理だ」というのはもっともな主張だ。しかし、ある程度現状を打破しようと考えている技術者だけが勝手に新しい手法を開発しても、それが底辺の技術者に配布されなければ意味がないのである。
「現状と計画が違ったら計画を変更せよ」無理だと思っても、どう考えたって現状はおかしい。「銀の弾丸」でもできなければどんなに方法論を改善しても世界はそう簡単には動かない。何か方法を考えなくてはならないのである。
それが、今後インフラが整備され、知的労働者が快適に働く環境が構築されても「知的労働者がそもそもいない」という状況を回避するための唯一のしゅだんではないだろうか？
（2001/6/6追記）
現在の開発手法というのは人材の育成までも視野に入れなければならない、それがペアプログラミングなどにより、可能となのがXPであり、非常に期待しているところである。
参考文献：
[1]「ソフトウェア開発２０１の鉄則」 アランMデービス著
松原友夫訳 日経ＢＰ刊
[2]「伽藍とバザール」
Eric S. Raymond 著 山形浩生 YAMAGATA Hiroo 訳
[3]「リファクタリング」 マーチン・ファウラー著
児玉公信 友野晶夫 平沢章 梅沢真史訳
[4]「プログラミングの心理学 または、ハイテクノロジーの人間学」ジェラルド・M・ワインバーグ著
木村泉・角田博保・久野靖・白濱津雄訳
[5]「デスマーチ なぜソフトウェアプロジェクトは混乱するのか」エドワードヨードン著
松原友夫 山浦垣夫訳
[6]「デッドラインソフト開発を成功に導く101の法則」
トム・デマルコ著 伊豆原弓訳
[7]「人月の神話 狼人間を打つ銀の弾丸はない」（原著発行20周年記念増訂版）
フレデリック・P・ブルックス Jr.著 滝沢徹 牧野裕子 富澤昇訳
| SEO | [PR] 爆速!無料ブログ 無料ホームページ開設 無料ライブ放送 | ||
