上手＠データ通信システム です。
訳案をつくりました。コメントよろしくお願い致します。
＃●、◇が機種依存文字でしたら、次回修正で直します。
＃化けていたら教えて下さい
１０章 クイックオーバービュー
我々のソフトウェア開発ルールの原材料は
◇ドライブを学ぶの物語
◇４つの変数−コミュニケーション、単純性、フィードバック、そして勇気
◇規律
◇４つの基本的活動−コーディング、テスティング、聴くこと、設計
我々のジョブは４つの活動の構造をつくることだ。単に４つの活動の構
造をつくるだけでなく、それを時には矛盾する規律の長いリストを考慮
しながらやらなければならない。そして同時にソフトウェア開発の経済
的パフォーマンスを十分に改善することも試みなければならない、
誰かがこう聴くように
問題ない
あ．．．
この本の目的はこれ(XP）がどのようにしたちゃんと動くかを説明すること
で、私はXPにおけるプラクティス（実行）の主な分野を手短に説明する。
次の章では、そのような風変わりなシンプルなソリューションがどうやっ
て機能するのかを説明する。プラクティスが弱いところでは、他のプラク
ティスの強さが弱さをカバーする。後ろの章はトピックを詳細にカバーす
る。
最初に、これが全てのプラクティスだ：
◇計画ゲーム
−ビジネス優先度と技術的見積により次回リリースの範囲を早急に決
める。現実が計画と変わったら、計画を更新する。
◇小規模リリースズ
−シンプルなシステムを早急に生産に投入する、それから新バージョン
を非常に短いサイクルでリリースしていく
◇メタファー（例）
−どの様に全体のシステムが機能するかを示すシンプルな例え話を
メンバーガ共有することで全ての開発を導く（ガイドする）。
◇シンプルデザイン
−いつでもシステムは出来る限りシンプルに設計されるべきだ。余分
な複雑さは見つけ次第取り除かれる。
◇テスティング
−プログラマは継続的に単体テストを書く、それは開発を続けるために
完全に動かなければならない。顧客は、機能の開発が終わったことを
示すテストを書く。
◇リファクタリング
−２重コードを取り去り、コミュニケーションを改善し、単純化し、柔軟性
を加えるために、プログラマは、システムの動作を換えることなくシステ
ムを再構成する。
◇ペアプログラミング
−全ての生産コードは２人のプログラマにより一台のマシンで書かれる。
◇集合的所有権
−誰でも、どのコードでも、どこででも、いつでも、プログラマはコードを修
正できる。
◇継続的インテグレーション
−システムを一日に何回もインテグレードしビルドし、毎回タスクは完了
する。
◇週４０時間以上仕事をしてはいけないのがルール。２週連続で残業
するのも駄目。
◇オンサイト顧客
−現実の、生のユーザをチームに加えて、フルタイムで質問に答えらる
ようにする。
◇コーディング基準
−プログラマは、コードを通じてのコミュニケーションを強調しているルー
ルに従って全てのコードを書く。
この章ではそれぞれのプラクティスを実行する際に何が含まれるかを手
短に要約する。次の章（どうやってこれが機能するのか）ではプラクティ
スの間の関係、これにより一つのプラクティスの弱さが他のプラクティス
の強さによって克服される、を確認する。
●計画ゲーム
ビジネスの考慮も技術的な考慮も大きすぎてはいけない。ソフトウェア開
発は常に出来ることと望ましいことの間の長い時間をかけた対話だ。対
話は、出来そうに見えることと、望ましそうに見えることの間で変化する。
ビジネスマンは以下について決定する必要がある。
◇スコープ
−システムが生産に役立つためには、どれだけの問題を解決する必要
があるか。ビジネスマンはどれだけが不足で、どれだけが過剰かわかる
立場に居る。
◇優先度
−最初はＡかＢしか持てないとしたらどちらにするか。ビジネスマンはこ
れをプログラマよりもよりよく決定できる立場に居る。
◇（段階的）リリースの構成
−そのソフトウェアをリリースする時に、どれだけ多く、またはどれだけ少
なく作業をすればビジネスがうまく回るか。この質問に対するプログラマ
の直感はひどく外れる。
◇リリース予定日
−その日にソフトウェア（やその一部）があると大きな差がでるという、
重要な日付はいつといつか。
ビジネスはこれらを真空の中から決定することは出来ない。開発は技術
的な決定をし、それをビジネスの決定のための材料として提供する必要
がある。
技術者は以下について決定する必要がある。
◇見積り
−一つの機能を実装するのにどれだけかかるか
◇結果（＃重要性かもしれない）
−技術的な結果を知らされていないと戦略的なビジネス決定は出来ない。
データベースの選択が良い例だ。スタートアップ（ベンチャー）企業の方が
巨大会社ビジネスはうまく行くかもしれない。しかし、生産性にの要素２
（＃？）は余分なリスクとそれに相当する不満を引き起こすかもしれない。
そうではないとしても、開発は重要性を報告する必要がある。
◇プロセス
−どのように業務とチームは組織されるのか？ チームは仕事をするた
めの文化（カルチャー）をつくらないといけないが、今の文化に組み込ま
れている非合理性を保つより、良いソフトウェアを書くべきだ。
＃今のカルチャーにとれわれず、ゼロからやりやすいものを考えよ。
という意味かな？
◇詳細スケジュール
−リリースの中間では、どのようなストーリーを最初に行うか？ プロジェ
クトの全体的なリスクを軽減するために、プログラマには開発の最もリス
クの高い部分を最初にスケジュールする自由が必要だ。この制約の中
でも彼らは、重要なストーリーをあるリリースの最後になって落とさざるを
得なくなることを減らすために、ビジネス上の優先度の高いものをプロセス
の前の方に持って行こうとする。
●小規模リリースズ
それぞれのリリースは、可能なかぎり小さく、最も価値のあるビジネス要
求を含んでいるようにすべきだ。そのリリースは意味があるべきだ−つま
り、リリースサイクルを短くするために、機能を半分だけ実装し出荷するこ
とはできない。
一度に６カ月や一年の計画をするより、１カ月や２カ月の計画をする方が
はるかに良い。巨大なソフトウェアを顧客に出荷している会社は、このよ
うに頻繁には出荷できないだろう。それでも、可能な限りリリースサイク
ルを短縮すべきだ。
●メタファー（例）
それぞれのXPソフトウェアプロジェクトは頭上の輝くアーチとなるメタファー
（例）によって導かれる。例は時にはうまく機能しないこともある、例えば
契約、顧客、契約違反などの専門用語で語られる契約管理システムが
そうだ。また例は時にはちょっと説明を要する場合もある、例えばコンピュ
ータはデスクトップのように見えるとかとか、年金計算はスプレッドシート
のようなものだと言ったりする。実際に”そのシステムはプレッドシートだ”
とは言っていないのだから、これらは全て例だ。例は、プロジェクトの全員
が基本的な要素とその相互関係を理解するのに役立つ。
技術的なエンティティを識別するのに使われる用語には、いつも例を選ん
でこれを使うべきだ。開発が進行するにつれて例がこなれて（成熟して）
くると、チームの全員が例を使うことに新しいインスピレーションを見いだ
すようになる。
XPにおける例は他の人たちが”アーキテクチャ”と呼ぶもののほとんどを
置き換える。10000ｍにも見える（？）システムのアーキテクチャに当たる
際の問題点は、アーキテクチャが必ずしもシステムをわかりやすく見せて
くれないことだ。アーキテクチャはととも大きな箱と関係の集合だ。
”駄目なのはアーキテクチャが駄目だからだ”という声が聞こえるが、我々
は、自然でわかりやすいストーリー、その中で仕事をし、ビジネスマンも技
術者もたやすく共に担えるストーリー、を全ての人に与えつというアーキテ
クチャのゴールを強調しておきたい。例を求めることにより、我々は伝える
のも追加するするのも容易なアーキテクチャを得られそうだ
●シンプルデザイン
どんな時でも正しいソフトウェア設計とはこのようなものだ
１．全てのテストで動く
２．２重のロジックを持たない。並行クラス階層など隠れた２重化に気を
つけよう
３．プログラマにとって重要な目標(intention)が全て記述されていること
４．出来る限り最少のクラスとメソッド
システムの設計のどの全ての部分は、これらの条件により自分の存在
を正当化できなければならない。Edward Tufferはグラフィックデザイナ
の訓練をしている。
−あなたの描きたいものを何でも描きなさい。それから、もうどんな情報
も削れなくなるまで、できるだけ消しなさい。もう消せなくなった時に残っ
ているものは、グラフの正しいデザインなんだ。
シンプルデザインはこのようなものだ
−ルール１、２、３を侵すこと無しに、取り去れるどんなデザイン要素も取
り去りなさい。
これは、あなたが普通聞いているアドバイス：”今日のために実装せよ、
明日のためにデザインせよ”とは逆だ。もしあなたが未来は不確実だと、
そして自分の考えを低コストで変えられると信じるなら、機能で投機をす
るのはクレージィだ。必要なものは、必要になった時に作ろう。
●テスティング
自動化されたテストの無いプログラム機能は存在しない。プログラマは、
プログラムの動作についての自信がプログラムそれ自身の一部になる
ことができるように、単体テストを書く。顧客も、プログラムの動作につい
ての自信がプログラムの一部になることができるように、機能テストを書
く。その結果、プログラムは時間が経過するにつれ、より満足のいくもの
になる−変化をより多く、より少なくではない、受け入れることができるよ
うになる。
あなたの書いたそれぞれのメソッドについて、テストを書く必要は無い、
止まる可能性のある生産メソッドだけで良い。
＃以下、意味不明。何がいいたいのでしょうか？
いつか、何かが可能か見つけたくなるだろう。３０分探す。可能だ。さあ
コードを離れ、またテストを始めよう。
●リファクタリング
プログラム機能を実装している時、プログラマはいつも、その機能を単純
に追加するための、既存のプログラムを修正する方法があるのではない
かと問う。機能を追加した後、プログラマは、こんどは、まだテストケース
が動いているのに、プログラムをより単純にするにはどうするかを問う。
これはリファクタリングと呼ばれる。
これは、動いているある機能を得るために絶対的に必要とされるよりも多
くの仕事を時々する、という意味では無いことに注意せよ。そうでなく、こ
の様に仕事をすることで、次の機能を、そしてその次も、その次も、合理
的な量の努力で追加することが出来ることが確実になる。しかしリファクタ
するのは投機によってでは無い；システムがあなたに求める時だ。システ
ムがコードをコピーすることを要求した時、リファクタリングが要求されてい
る。
もし動くテストを得るための１分間の醜いやり方と、シンプルな設計によっ
て動くテストを得るための１０分間のやり方をプログラマが眼にしたら、正
しい選択は１０分間を使うことだ。幸いなことにあなたは、システムの設計
に対するラジカルな変更でも、小さな、低リスクのステップで行うことが出
来る。
●ペアプログラミング
全ての生産コードは二人で、一つのマシン、一つのキーボード、一つの
マウスを使って書かれる。
それぞれのペアには二つの役割がある。パートナーの一人、キーボード
とマウスを使っている人はこのメソッドを実装する最も良い方法を考える。
別のバートナーはより戦略的に考える：
◇このアプローチ全体はうまくいくだろうか？
◇まだ動かしていないテストケースはどれだろうか？
◇システム全体を単純化し現在の問題を雲散霧消させる方法は無い
だろうか？
ペアの組み方は動的に変化する。朝二人がペアを訓でも、午後には二
人は他の人と簡単にペアになるかもしれない。もし不得手なある領域
のタスクに責任があれば、最近経験している人にペアになってくれるよ
う頼むかもしれない。いつも、チームの誰もがパートナーとして活動する。
●集合的所有権
誰でも、コードのどの部分であれ価値を追加する機会を持ったら、いつで
もそうしなければならない。
これを他の二つのコード所有権のモデル−所有権無しと個人所有権、を
比較する。その昔は、コードの特定の部分の所有権など誰も持っていな
かった。もし誰かがコードを修正しようと思ったら、その変更がすでにある
コードとうまく合うかどうかにかかわらず、自分の目的を達成するために
そうした。その結果は混沌だ、特にコードのラインの関係がわかりにくい
ものに対して。コードは急速に大きくなり、同時に急速に不安定さを増す。
この状況をコントロールするために、個人のコード所有権が生まれた。コ
ードの一片を変えることの出来た個人がその公式な所有者だった。その
コードを見て修正が必要な他の人は彼らの要求を所有者に伝えなけれ
ばならなかた。厳密な所有権の結果、みんながコードの所有者を煩わす
のを嫌がるに連れ、チームのコードの理解が分散してしまった。結局、彼
らは、後ではなく、今修正することが必要だ。それによりコードは安定す
る、しかしそれはそうあるべき程速くは成長しない。それから所有者が消
え・・・・
XPでは、誰もがシステム全体に責任を持っている。誰もが全ての部分を
同じように良く知っているのではなく、全ての部分について何かを知って
いる。もしあるペアがコードを改良する機会を見つけたら彼らはすぐ前に
進みコードを改良し、彼らの生活をより楽にする。
●継続的インテグレーション
２、３時間から最大でも１日の開発の後、コードは統合されテストされる。
これを行うための一つの単純な方法はインテグレーション用の専用機を
持つことだ。マシンが空いている時は、統合するコードを持ったペアが、
現在のリリースをロードし、彼らの変更をロードし（全ての衝突をチェック
し、解決して）、テストをパス（100％正しい）するまで走らす。
●週４０時間
私は毎朝フレッシュで意欲に満ち、毎晩疲れていて満足していたい。金
曜日には、疲れていてたっぷり満足していたい、土日の２日間を仕事以
外のことについて考えられるように。そして月曜日には火の玉（fire)と沢
山のアイデアに満ちて戻って来たい。
これを週きっちり４０時間働くことに換えるのはそれほど難しくない。人に
より仕事に対する耐性は違う。ある人は３５時間集中できるし、別の人は
４０時間だ。しかし誰も週６０時間、何週間も働き、まだフレッシュで、創
造的で、注意深く、落ち着いているなんてことはできない。そんなことは
止めよう。
残業はプロジェクトの深刻な問題の兆候だ。XPのルールは単純だ−残
業した週の翌週は仕事にならない。一週間は元気で、陽気で余分な何
時間の残業をすることができる。月曜日に来て”ゴールに間に合わせる
にあｈ、また遅くまで働かなくちゃ”と言った時、あなたはもう、さらに残業
するだけでは解決しない問題に陥っている。
関連するテーマは休暇だ。ヨーロッパ人は２，３，または４週間連続で休
みをとる。（＃ウラヤマシー）アメリカ人はたまに、一度に２，３日休むだけ
だ。もしそれが私の会社なら、私はみんなが毎年２週間の休暇をとり、別
に最低もう１から２週間を短期休暇としてとることを主張するだろう。
●オンサイト顧客
実際の顧客がチームと共に居て、質問に答え、論争を解決し、小規模な
優先度付けをしなければいけない。”実際の顧客”とはシステムを生産で
実際に使う人を指す。もし顧客サービスシステムを造っているなら、顧客
は顧客サーブス部門の代表（？）だ。債券トレーディンシステムなら、顧
客は債券ディーラーになる。
このルールに対する大きな反対は、開発中のシステムの実際のユーザ
ーをチームに加えるのはもったいないというものだ。マネージャはどちらに
価値があるか決定しなけらばならない−ソフトウェアをすぐに、より良く稼
働させるか、（顧客が現部門で働いて）一人か二人の成果物を得るかを。
もし前者がビジネスに、一人か二人が（今の部門で）働く以上の価値しか
もたらさないならば、たぶん、そのシステムをつくるべきでない。
しかしこれは、チームにいる顧客が（通常の）仕事をしてはいけないという
わけではない。プログラマも毎週、毎週、週４０時間質問をしてくるわけで
はない。オンサイト顧客は他の顧客と物理的に切り離されているという不
利はあるが、通常の業務を行う時間はとれるだろう。
オンサイト顧客で予想される悪い事態は、彼らがプログラマを助けて何百
時間も働き、そしてプロジェクトが中止されてしまうことだ。彼らのやった仕
事失われ、あなたも、彼らが失敗しつつあるプロジェクトに貢献しているの
でなければ成し遂げたであろう仕事を失う。XPは可能なこと全てをやり、
プロジェクトが失敗しないことを確実にする。
私が仕事をしていたあるプロジェクトでは、一人の顧客が渋々差し出され
た、しかも”ちょっとだけ”。システムが成功裏に出荷され、時間をかけて
継続的に成長できることが明白になった時、顧客側のマネージャは三人
の実顧客を提供してくれた。会社はシステムから、より大きなビジネスへ
の貢献により、より多くの価値を得ることが出来た。
●コーディング基準
もしプログラマ達をシステムのこの部分からあの部分へ担当を変え、１日
に何回もパートナーを取り替え、継続的に互いのコードをリファクタリング
するなら、単に異なるセットのコーディングプラクティスを持つことが出来な
くなる。ちょっと実行しただけで、チームの誰が何のコードを書いたかわか
らなくなる。
基準は、最小限の実行可能な作業を求め、Once and Only Once ルール
（２重コード記述が無いこと）に従っているべきだ。基準はコミュニケーショ
ンを強調すべきだ。最後に、基準はチームの全員に強制では無く喜んで
受入られなければならない。
（ここまで）
---
オリジナル http://www.xprogramming.com/
Copyright (c) 1999, REJeffries et al. (ronjeffries@....org)