XP — 究極の仕事術 ?

ソフトウェア工学やシステム開発の現場で、 ここのところXPという呪文を聞く機会が増えた。

ただしXPといってもWindowsの製品名にあらず。 eXtreme Programming
— その名も「究極のプログラミング」という開発プロセスのことだ。

究極のシステム開発 ?

さてXPとは、Kent Beck、Ward Cunningham(※1)、Ron Jeffries
らにより提唱されている、新しいソフトウェア開発プロセスである。

XPの詳しい解説は永和システムマネジメント社の 「エクストリーム・プログラミング」日本XPユーザ会のページを参考にしてもらうとして、 ここではXPの特徴を簡単に紹介しよう。

XPではソフトウェアを効率的に、かつ高い品質で作成するための様々な技法
(プラクティス)が用意されている(下表)。これらのプラクティスを効果的に活用することで、
ソフトウェアの生産性を高め、バグの少ないシステムを作成しようという試みである。

表: XPのプラクティス
計画ゲーム 常に細かな単位で計画を立てていく
小規模リリース リリースサイクルは短めに
比喩(メタファ) 例えを用いて分かりやすく
シンプルデザイン 設計は単純に
テスティング テストを優先したプログラム開発
リファクタリング コードの見直しを積極的に行なう
ペアプログラミング 二人のプログラマが組になってコードを書く
共同所有権 全てのプログラマが全てのコードにアクセス可能
継続的インテグレーション 常にテストを実行し、動作する状態に置く
週40時間 過度の労働は生産性低下のもと
オンサイト顧客 ユーザをチームに加える
コーディング標準 コーディング規約に従った礼儀正しいプログラミング


なおここ1〜2年では盛んに「アジャイル」開発というキーワードが唱えられるようになった。
アジャイルもXPのように環境の変化に柔軟に対応した開発を進めようという考え方で、
XPや関連する開発プロセスを包括する概念である。

作業者・作業環境に重きを置く

XPはここのところソフトウェア開発の主流となっているオブジェクト指向開発の流れを汲み、
繰り返し開発によるシステムの洗練、設計を単純化することにより思わぬ誤りを防ぐ、
一定間隔でコードのリファクタリング(見直し、再設計)を行なう、 など特定の枠組みに縛られないフットワークの軽い手法だ。

さらにXPに特徴的なのは、ソフトウェアを書くのは人間である、 という当り前の事実を重視していること。
ペアでプログラミングをすることで誤りを防ぐとか、 作業は週40時間までにして頭の疲労を防ぐ、
あるいは概念やコードを共有化してチームの一体感を高めるなど、 人間の活動の結果としてのソフトウェアやシステム作成である、
という指針で開発方法論を提示している姿勢が好ましい。

開発業務以外への適用可能性

現在、私たちの開発現場でもXPの手法をだんだんと取り入れつつある。 そしてXPのコミュニティ活動に参加すると、
そこでは「まずできるところからはじめよう」という意見をしばしば聞く。 XPの風土が育った欧米と日本の職場環境の違いもあり、
仕事の環境をいきなり全てXPスタイルにしようというのはどだい無理な話だが、
まずは美味しいとこ取りでXPの水に慣れていこうという作戦である。

ところで弊社の業務の性質上、 私たちの仕事は開発に留まらず技術調査や特定技術の市場調査など調査業務も任務となる。
私たちにとってはこれらの業務へのXPの適用可能性も非常に興味がある。
もちろんペアプログラミングに相当するプラクティスは何かと問われれば回答は難しいが、
早期リリースや顧客を巻き込む手法などXPのいくつかのプラクティスはそのまま適用できそうだ。

さて、最後にあえて大風呂敷を拡げてしまおう。 開発に限定せずともカスタムメイドの業務のほとんどでは、
XPのプラクティスを活用できるのではないだろうか。 XPが業務の現場において「究極のプラクティス」となる可能性(※2)に、 私は大きな期待を寄せている。

※1 Ward Cunningham
は、コラボレーションツールWiKiの父としても有名。

※2 実はXPの概念が固まる以前に、 XPの父のひとりである Ron Jeffries が XPractices
という文章をまとめている。ここもぜひ参照しておきたい。