デザインとしてのエクストリームプログラミング : エクストリームデザイン #1

この記事は、「デザイン」より広い文脈から捉え直し、未来につなげる連載「エクストリームデザイン」の第一回です。今回は、ソフトウェア開発手法として、1990年台に提唱され、現在まで大きな影響を与えた「エクストリームプログラミング(XP)」を、デザイン行為として捉え直します。本連載の全体像についてはこちらから。

---

25年ほど前にケントベックが考案したエクストリームプログラミング（XP）というソフトウェア開発プロセスを簡単に紹介しましょう。スクラムやアジャイル開発の一連の手法など、その後の開発手法にも大きな影響を与えた手法ですが書籍や論考も数多くあるので、ここでは以下の三点に絞って紹介します。

• 考案された開発プロセスの骨子

• 何が「エクストリーム」であったのか？

• 時代背景と影響

エクストリームプログラミング

エクストリームプログラミングは、大規模になったソフトウェアをより高品質で生産的に開発するために考えられた開発手法で、大きく分けると以下のように分けられます。

• 実践するためのプラクティス（ペアプログラミング、計画ゲーム、テスト駆動開発、継続的インテグレーション、リファクタリング、小さなリリース、コーディング規約、ソースコードの共同所有、シンプル設計、システムメタファー、持続可能なペース）

• 開発を４つのアクティビティ（コーディング、テスト、傾聴、設計）に分ける

• 開発をする人間が共有すべき価値観（コミュニケーション、シンプルさ、フィードバック、勇気、尊重）、原則（フィードバックの原則、シンプルと決め込む、変化の受け入れ）

特に、最後のプラクティスの一つ一つは、今のアジャイル開発では当たり前に受け入れられているものも多いと思われますが、当時の開発者たちが楽しそうにこれらの実践を語ってくれた事を記憶しています。

何がエクストリームであったのか？

これらがなぜ、「エクストリーム」と名付けられたのか？それは、これまでの開発者たちが個別に実践していたベストプラクティスをただの事例集という形だけはなく、提唱者たちが実践した、開発チームの持つべき態度、運営法、プラクティスまでもを含めて、提唱したことにあります。

さまざまなツール（github,CIツール,クラウド環境など）が普及した現在ではそれほど極端に見えないかもしれませんが、提唱された90年代の開発環境下でこれらを実践することの困難さは想像に難くありません。

現在、エクストリームプログラミングの提唱全てを守っている開発現場こそ寡聞にして知りませんが、その哲学や価値観が持っている現代の開発現場への影響は「アジャイルソフトウェア開発宣言」を見れば明らかでしょう。

時代背景と影響　〜開発者たちのコミュニケーションへの視点から〜

開発工程モデルの変化を調べると、1960年代に大規模ソフトウェア向きに、要求定義→設計→開発→テスト→運用のいわゆる「ウォーターフォールモデル」が提唱され、1980年に反復を強調した反復型開発モデル（スパイラルモデルなど）が提唱されたことがわかります。

XPは、反復型開発モデルに含まれますが、反復型開発が求められた背景には、ソフトウェアに対して「顧客の新しい要求に応える」が求められ、「短い開発サイクルによる頻繁なリリース」が要請されたことがあります。

そして、その要請に応えるために、開発プロセスの中にモノ（この場合はソフトウェア）が出来上がる「工程」としてだけではなく、「開発者」の視点を含んだ提案となったことが、非常に重要だと考えています。
XPの提案に、開発者の視点を含んだ理由としてはモノを作る人間達（この場合は開発者）が適切なコミュニケーションを取る必要があり、当時のソフトウェア開発は、そこに大きな問題を抱えていたからではないでしょうか？

単純に考えても、関係性の数は人数の二乗に比例して増えるため、規模が大きくなると、コミュニケーションコストは飛躍的に増大します。
そのために、大規模な開発の場合にソフトウェアやチームを分割し、精査された仕様書を準備し、厳格なルールを設定するなどコストをかけてコミュニケーションを整備してきました。

時代の変化とともに、小さな規模で開発を進める形になり、必要となったコミュニケーションの量が小さくなった一方で、大規模開発の時のコミュニケーション方法が、割に合わなくなったため、新たなコミュニケーション方法が必要となったのではないかと理解しています。

XPが、開発者たちが共通して持つべき価値観を提唱したり、テスト駆動を提案しているのは、大規模な開発の時に機能していた開発手法に置き換わりうるコミュニケーション方法として提案されたと考えることはできないでしょうか？

昔のコンピュータの豆知識
パーソナルコンピュータやオフィスコンピュータと呼ばれる比較的小規模なグループが利用するコンピュータが普及する以前は、NASAや軍などの国家レベル、あるいはメインフレームと呼ばれる大規模な組織のミッションクリティカルな業務・計算がコンピュータ利用の目的でした。（ちなみにですが、トランジスタを使って全世界のコンピュータ市場の1/3を占めたと言われるIBM1401は当時(1959年)の値段で月額＄2500（今の価値で考えると約400万円）の利用費だったそうです。）

まとめ（XPという提案をデザインとして捉えると）

以上の話を、XPが、広い意味でのデザインの行為であったと考えて、Eames夫妻の有名な言葉「望む目的に最も良くかなうように、必要な要素を組み立てる計画がデザイン」に倣って振り返りましょう。

何がデザインされたのか？
ソフトウェア開発者達が共通して持つべき価値観・方法論

望まれた目的：
時代の変化への対応（ソフトウェア開発が普及した結果、新たなコミュニケーション方法が希求された）

組み立てられた要素：
開発プロセスを整理する考え方。（「アクティビティ」）
開発をする人間が共有すべき価値観、原則
実践するためのプラクティス

筆者が感じる「エクストリームなところ」
一見コストがかかることをあえて提案していること
ペアプログラミングから、製品リリースまで、さまざまな規模でのフィードバックループを同時に含んだ提案であること

筆者が感じる「未来から選ばれるコト」とのつながりキーワード
チームによる課題解決　アジャイル　自律分散　変化するループ

Title Photo by stefygutovska