Rally Software：大衆のためのアジャイル開発環境

　開発コミュニティでの最近の流行は、アジャイル開発だ。私はこれまでそれらの開発手法に対しては反対の立場だったが、過去1年間ほどの間に、私が持っていたアジャイル開発に関する情報は、良くない情報源に頼ったものだったことが分かった。

　アジャイル開発とは、「プロジェクトマネージャとビジネスアナリストは捨てて、プログラマーに直接顧客と話させよう」というようなものではない（確かに多くの場合こういうことも起こるが）。アジャイル開発とは、従来の計画に従うアプローチで起こりがちな、成果に対する過剰な期待と、それを満たせないという問題を避けようとするものだ。

　私がアジャイル開発について多くのことを学ぶことができたのは、Spiceworksの人たちと定期的に話をしているからだ。Spiceworksはアジャイル開発とクラウドソーシングを組み合わせ、開発チームと25万人のユーザーとをつなげることによって大きな成功を収めている。

　私はSpiceworksの物事への取り組み方にいつも感銘を受けていたため、Rally Softwareのバイスプレジデントの1人と話す機会があった時、同社がSpiceworksのことを思わせることに驚いた。

Rally Softwareのソフトウェアとアジャイル開発の問題

　米国時間2008年8月7日、私はRally Softwareの製品マーケティング担当バイスプレジデントのRichard Leavitt氏と話す機会を持った。Rally Softwareはアジャイル開発環境で開発プロジェクトを管理するソフトウェアを作っている。Rally Softwareは2つのバージョンのソフトウェアスイートを持っている。小規模な開発チームのための無料のRally Community Editionと、大規模な開発チームやプロジェクトのためのRally Enterprise Editionだ。私はこのソフトウェアをアプリケーションライフサイクル管理（ALM）のためのものだと呼ぶことには、ためらいがある。なぜなら、Rally Softwareのソフトウェアスイートは従来のALMソフトウェアよりもはるかに多くのことをカバーしているからだ。私はRichardとの会話の冒頭に、私はまだアジャイル開発について懐疑的ではあるものの、意見としては柔軟な姿勢だと話した。私が柔軟な姿勢を取っていた理由の1つは、私の以前の同僚が、Rallyのソフトウェアを使って大いに成功を収めており、そのソフトウェアを褒めていたからだ。

　Rally SoftwareのPRチームは私に、さまざまな規模のプロジェクトを持つ5社で、どれほど開発効率が改善されたかを調べたプレスリリースを送ってくれた（注：CNETもその5社のなかの1つだ）。この調査では、開発効率をコード行数で計測しており、コードの品質はバグの数で測っていた。現場の開発者は、コード行数や報告されたバグの数はあまり問題ではないことを知っている。結局、コード行数が多いのはプログラマーがいい加減だからかもしれず、報告されたバグの数は、バグが見つかった場合にしか意味がない。

　Rally Softwareはアジャイル開発が簡単なものでないことを理解している。これが、私がアジャイル開発についてもっとも難しいと思っていたことの1つだ。アジャイル開発が成功するためには、多くの労力と熟考を必要とする。Richardは私に、アジャイル開発を採用している多くの開発会社が、どのような困難を抱えているかについて徹底的に話してくれた。コードを納品可能なものに近いものに維持すること、要件を変える準備をしておくこと、開発サイクルの成熟した段階でQAスタッフを投入し品質管理プロセスを実行することなどだ。Rally Softwareのソフトウェアスイートでは、これらの問題やその他の問題について、計画、追跡、協調などの観点から解決している。

　Richardの言い方によれば、Richardの姿勢は「ソフトウェアは団体競技だ」というものだ。私は、この考え方には全面的に賛成だ。われわれの多くは、連絡の失敗や情報伝達の遅れなどが、どのようにプロジェクトを失敗させるかを実際に目にしている。これは、アジャイル開発による圧力がない場合でさえ起こる。Rally Softwareのソフトウェアスイートは、単なるバグトラッキングやバージョン管理を超えて、顧客からのフィードバックの促進から最新バージョンの公開に至るまで、アジャイル開発サイクル全体を統合するものだ。