2008 Rationalの最新動向
前回に続き、Rationalとの出会いを書くつもりでしたが、「IBM Rational Software Development Conference 2008」が開催されたこともあり、Rationalの最新動向について書いてみたほうが面白そうなので、こちらについて書いてみます。プラス、Rationalに絡めて、最近のプログラマ軽視に対する怒りのメッセージも書いてみました。
従来、RUP（Rational Unified Process）は反復型の開発プロセスでありながらも重量級といわれ、重いプロセスの代表とされていました。Rational自身は「RUPはアジャイルだ」と述べていたのですが、ほかのアジャイル型プロセスに比べると個人的にはやはり「重たい」と感じてしまうものでした。
しかし、最近のRationalはツールもプロセスも本当の意味でアジャイルを目指しており、整理し直し始めています。Rationalの目指すアジャイルとは、従来の少人数のアジャイル開発を発展させたエンタープライズ・アジャイルと呼ばれるものです。エンタープライズ・アジャイルでは100人以上の開発メンバーや遠隔地での開発もアジャイルの対象にして、そのような開発でもアジャイルが実現できるようプロセスとツールを整備していこうというものです。
RUP自体は他のアジャイル開発方法論に習い、プラクティスという側面から整理し直されて、開発形態に応じてカスタマイズをするのが容易になっています。
RUPの改良も面白いのですが、やはり開発ツール好きの人間として面白いのはJazzプラットフォームに基づいて開発が進んでいるツール群ですね。 チームのコミュニケーションを極限まで促進させるためのRational Team Concertや、要求収集に役立つRational Requirements Composer、単なるテスト管理を超えた品質管理を可能とするRational Quality Managerなど、従来のRationalツールのサポートが十分ではなくWordやExcelでかんばっていた部分を補完するツールがJazzプラットフォームに基づいて続々登場しています。
上記の部分は従来ではWordやExcelで管理していることが多く、転記の作業が多かったり、はたまた個人で管理しているためにバージョンの先祖返りが起きたりと、システム開発の本質でないところで悩まされたりして、ムダだなあと思うことが多々ありました。上記のツールを新たなRUPと組み合わせ、使いこなすことによって、本質的でない作業を最小化すると同時に、コミュニケーションを最大化してシステム開発で本当に必要な作業に専念できる環境が整ってくるのではないかと思っています。
残念ながら、最近の受託開発の現場では、後藤さんのコラム「下流から見たIT業界 SEとPG、どっちが頭がいい？（1）」でも述べられているように技術者、特にプログラマが軽んじられる傾向がありますが、社内プログラマの経験が長いわたしとしては、良い傾向ではないと思っています。
プログラミングを単純労働として考え、低コストのプログラマの数だけを増やして開発を進めようとする海外オフショアなど、その最たるものといえます（海外オフショア開発がすべてこのようなものというわけではありませんが、建前はともかく実態はそうなっていることが多いです）。
プログラミングは単純作業ではないので、数だけ増やして水平クラスターなど出来はしません。水平クラスターをするためには、その前の段階で膨大なコストがかかり、その部分がコスト高になってしまい水平クラスターの効果を相殺、下手をすればコスト高になってしまいます。そうではなく、海外も含めて真のプロフェッショナルのプログラマ達のコミュニケーションを促進し、少数精鋭で開発を進めるべきです。
Rationalの進めているエンタープライズ・アジャイルの中では、プログラマは独立した専門職であり、テスト担当者や構成管理担当者についても同じです。どの専門が上でどの専門が下とかはありません。そしてプロセスとツールは彼らのコミュニケーションを促進し、彼らの専門性と能力を極限まで上げるために存在しています。
プログラマを始めとする技術者の方はぜひ高度なプログラミング能力に磨きをかけるとともに、Rationalを始めとするプロセスとツール、そしてシステム開発での経験から得た業務知識を武器に、自他共に認められるプロフェッショナルを目指して欲しいなと思います。
ということで、また宣伝になってしまいますが、もうすぐで体験版が出てくると思いますので、ぜひ体験版を触ってみてください。私も社内のサイトで一部のツールをダウンロードして試していますが、本当に面白いです。製品単体のすごさだけでなく「ああ、こういう部分がほかのツールと連携できるとうれしかったんだよね」という部分が非常によく出来ていると思います。私自身も現場に積極的に導入していきたいと思いますので、皆様もぜひ使ってみてください。
次回は開発プロセスの意義について書いてみたいと思います。