前回からちょっと時間が…
…空いてしまいましたが、この連載でも取り上げているIBM Rational Team Concert（以降RTC）とIBM Rational Method Composer（以降RMC）が、共に6月にバージョンアップし、ツール間の連携度合いが高まりました。実はこれを紹介したかったから、わざと間を空けていたのであって、決して目先の仕事に嵌まって原稿提出が遅れたわけではなく……（編集担当：「バシッ」）。
今回は、「開発プロセスを運営する」という観点でのお話しです。この話がしたかったから、わざわざ間を空けて……（編集担当：「ドスッ」）。
「開発プロセスを運営する」ということ
開発プロセスといえば標準化、これまで……いやいや、今でも、次のような進め方を目にするのではないでしょうか？
- 半年かそれ以上かけて開発現場の問題点を洗い出す
- 同時にCMMIやCOBIT、PMBOK、SWBOKと必要とおぼしき知識の習得に励む
- さらに半年かそれ以上かけて、標準となるべき手順、仕様書の書式の詳細を決める
かくして、着手してから1年半後から2年後くらいに、「これから10年使う開発標準や基盤環境」ができあがる……はずが、実際には現場の実態とかけ離れたルールブックができあがるという具合です。
ビジネスの変化に即応するスピード感やアジリティが強く求められる昨今、開発現場でのプロセスに対するアプローチも変わっていかねばなりません。
昨今のアジャイル開発の一般化を契機に、開発プロセスの定着と改善について、Rationalチームでは、次に紹介する3つのアプローチを提唱し、RTCとRMCとの連携によって、それを実現しようとしています。
プロセス運営の3つのアプローチ
1. 受動的アプローチ
まず最初に挙げるべきなのは、開発者の振るまいを「受動的」アプローチに変えたいという点です。
品質やコストに問題意識を持っているIT組織の多くが、（1）プロジェクト管理、（2）標準化を強化施策として挙げています。「より高品質＆より低コスト」を求めて、作業手順を詳細に定義し体系づけて、結果として水も漏らさぬ「百科事典」を作り上げるのです。
しかし、その手順にのって開発を進める方は地獄です。社内イントラネットやファイルサーバーで共有された標準規定書に準ずるための活動はすべて人に任されます。今着手しようとしている作業の詳細を手順書で探しだし、完了基準を達成しているかどうかを人が判断し、マスターソースの更新作業の条件を確認し……（少々大げさですが）あらゆる箇所でその手順を意識しなければなりません。
このように、これまでの開発プロセスの運営は、常に『適用される側がプロセスに準ずるために「能動的」に関わること』を求めてきました。
それに対して、「受動的」とは「必要があればツールがガイドしてくれる」という意味です。
具体的には、RTC単独あるいはRMCとの連携で次のようなサポートを実現しています。
- RMCで標準として定義された活動は、RTCのタスクとして登録される（図1）。開発者は、タスクの説明を見たければ社内イントラネットで公開されたプロセス定義の該当箇所を、RTCから直接参照することができる。このように必要なときに必要なガイドを最小限の手間で照会することができる
- 事前条件／事後条件を設定しツールに自動チェックさせる（図2）。例えば、ソース管理で共有領域を更新する場合には、「変更理由を明記するタスクが関連づけられていないと、ツールの側が更新を拒否」し、「その場合の対処法をガイド」してくれる
- タスクとソース（の変更部分）が常に関連づけられていることによって、CI時の各ビルドがどんなタスクの結果を反映しているのかの報告（ビルドレポートあるいはリリースレポート）を自動化してくれる
これまで「開発」という文脈で自動化というと、テストやコード生成の自動化が語られることが多いと思います。RTC＋RMCでは作業の流れやそれに関わる条件判定をツール側に任せることによって、「何か齟齬があったときに開発者に教えてくれる」受動化アプローチをとれるようにしているのです。
