佃です。
２５章の抄訳を送付します。
意訳している箇所がかなりあります。
間違いの指摘、コメントなど、お願いします。
Chapter 25 When You Shouldn't Try XP
＜私の思い込みによるまとめ＞
XPを行うべきでない場面を説明している。
・ 企業風土 軌道修正を認めない 大量の仕様書を望む 残業に
よる企業への忠誠心
・ 規模 ２０人以上ではだめ。１０人なら可能。
・ 技術 simplestを実施できない技術
・ 開発環境（マシン） １日数回のインテグレーションができない
環境、重要なテストが１日で終了しない環境
・ 開発環境（部屋） ペアプログラミングをする２人が快適に過ご
せることができない空間
最後から２番目の段落の意図が今ひとつわかっていません。（英
語がちゃんとわかっていない）
大規模システムを開発する場合には、XPは適用できないものなの
でしょうか？ コンポーネント分割までは少数精鋭チームで実地
し、各コンポーネントのインタフェースをきっちり決めておき、分
割後はコンポーネント毎にチームを構成し、その中でXPを実践すれ
ば、うまくいくのでしょうか？
２０人以上ではだめ、と真っ向から否定されると困ってしまう。
XPと大規模システム開発について記述している資料があるのであれ
ば、誰か教えて下さい。
＜タイトル直下の要約部分の全訳＞
XPの正確な制約はクリアではない。しかしＸＰの動作を妨げる明
白なショーストッパは存在する。それは大きなチーム、信用しない
顧客、礼儀をわきまえた変更(graceful change)を支援しない技術
である。
＜本文抄訳＞
ＸＰプロジェクトを失敗に導く、時間、場所、人、顧客が存在す
る。それらのプロジェクトにＸＰを使用しないことが重要である。
ＸＰプロジェクトの成功への一番大きな障壁はカルチャーであ
る。国のカルチャーは影響を与えるが、もっと問題なのはビジネス
（企業？）のカルチャーである。最初に決めた通りに実施するよう
に試みようとする(trying to pointing the car in the right
directionの意訳)プロジェクトを実行しているビジネスは、度重な
る軌道修正(steering)を主張するチームともめるでしょう。
「最初にきめた通りに実施(pointing the car)」の変形は、大量
の仕様書である。顧客やマネージャがプログラミングを開始する前
に完全な仕様書や分析、設計を主張すれば、チームのカルチャーと
顧客、マネージャーのカルチャーとの間に摩擦が生じるようになる
であろう。
私は大量の紙を愛する銀行の顧客と働いたことがある。彼らはプ
ロジェクトの間中、システムを文書化しなければならないと主張し
た。我々は、機能が少なくなって紙がさらに多くなることを望むの
であれば喜んで従う、と彼らに言い続けた。我々は一ヶ月の間、
「文書化」について聞きつづけた。プロジェクトが進行し、テスト
がシステムの安定化とオブジェクトの意図された使用方法のコミュ
ニケーションにどれだけ価値があるかが明確になってきたときに、
文書化についての意見がだんだん静かになった。最後の方では、開
発マネージャの要求は、システムの主要オブジェクトについての４
ページのイントロダクションだけだった。
ＸＰにとって有害な別のカルチャーは、「会社への責務」を証明
するために、長時間勤務を要求されることである。ＸＰプロジェク
トにおいて２週間連続の残業はプロセスがうまく機能していない確
かなサインであり、プロセスを修正すべきである。
賢いプログラマは情報の共有（close communicationをこんな風
に意訳して見ました）と継続的な革新のために「正しく想像する」
ゲーム("Guess Right" game)というつまらない時間を過ごさなけれ
ばならない。
サイズは大きな問題である。ＸＰプロジェクトは１００人のプロ
グラムでは運営できない。５０人でもだめである。２０人でもたぶ
んだめ。１０人であれば確実に可能でしょう。３，４人であれば、
イテレーション計画ゲームのようなプログラマの調整に関係したい
くつかのプラクティスを省略できる。開発する機能の量とその開発
者の人数は単純なリニアの関係ではない。おおきなプロジェクトで
は、どのくらいのスピードで開発できるかを調べるため、小さなチ
ームで一ヶ月ほどＸＰを経験しなければならない。
スケールに関するおおきなボトルネックは、シングルスレッドの
インテグレーションプロセスである。シングルインテグレーション
マシンによって単純に適用するのではなく、どうにかしてこれをよ
り多くのコードストリームを扱うように拡張しなければならない。
本質的に指数コストカーブである技術を用いる場合には、ＸＰを
用いるべきではない。例えば、Ｎ世代において同じＤＢを用いてメ
インフレームシステムを開発する場合、将来のある時点でデータベ
ーススキーマが変更しようと思っても、それまでに開発したプログ
ラムのための変更できないのであれば、ＸＰを使うべきではない。
ＸＰではコードを常に単純に保つことが重要であるので。
フィードバックに時間がかかる環境もだめ。コンパイルとリンク
に２４時間かかるのであれば、統合、ビルド、テストを一日に数回
することが困難になる。重要なテストが一日以下で実行できない環
境はだめ。そのような環境では、ソフトウェアの設計を進化させる
気がしない。
仕切り板がほとんどない大きな部屋で、中央のテーブルにパワフ
ルなマシンがある環境は、私が知っているベストの環境である。
個々の部屋に仕切られていても、１つの部屋で２人が快適に過ごせ
るのであれば、その環境でもよい。
２つのフロアにプログラマを抱えるのであれば、それを忘れなさ
い。１つの部屋で広範囲に分離されたプログラマを抱えるのであれ
ば、それを忘れなさい。制限されたインタラクションのみで関係す
るプロジェクトで働く２つのチームを抱えるのであれば、それも可
能でしょう。私なら、最初のリリースでは１つのチームで実施し、
それからアプリケーションの自然なラインに沿ってチームを分割
し、各部分を成長させるでしょう。
最後に、赤ちゃんが叫んでいるような部屋でXPは絶対にうまく機
能しません。これについては私を信じなさい。
--
佃 軍治 tsukuda@....jp
日立製作所システム開発研究所第２部