第3回　アジャイルな開発プロセスの展開

“アジャイル”の次へ：IBMの開発プロセス戦略の今（3）

2012/05/08 14:00

ポスト

プロジェクト実行を支援する環境

プロジェクト管理との連携

　Rational Team Concert（以後、RTC）は、プロジェクトの計画に基づいて作業管理、ソースのバージョン管理などを行うALMの中心的な役割を担う統合管理ソリューションで、作業情報や成果物などを集中リポジトリーによって関連付けて管理できます。プロセスで定義されているWBSのタスクをRTCのワークアイテムとして登録して、作業状況を管理します。

　RTCのワークアイテムは、繰り返し実行する複数の作業パターンをテンプレート化して作業を一括登録することができます。Rational Method Composer（以後、RMC）からエクスポートしたプロセスのケーパビリティー・パターンに含まれるWBSをRTCのワークアイテム・テンプレートとすることができます。前ページのMicrosoft Projectへのエクスポート例と同様に、登録されたタスクにはあらかじめ作業内容が明記されており、さらに詳細を説明するプロセス定義へのリンクも含まれるので、すべきことを確認しながら作業を行うことができます（図6）。

図6. ワークアイテム・テンプレートから登録したタスクの例

　また、そのプロセス定義ドキュメントの参照先は、RTC自体がJava EEアプリケーションであるため同一のWebサーバーにRMCからHTML形式で出力したものを合わせてホストすることも可能です。

プロセス改善もアジャイルに

　RTCは、管理単位としてプロジェクト・エリアおよびそれに含まれるチーム・エリアがあり、それぞれ毎に「プロセス記述」を登録／参照できます（図7）。このプロセス記述には、RMCから出力したプラクティスをインポートできます（図8）。前述のプロセス定義ドキュメントの共有では、そのスコープはプロジェクト横断になりますが、実際にはプロジェクトもしくはチームをスコープとしたプラクティスのカスタマイズが必要になります。そういったケースに対応するためにRTCには個別のプラクティスをホストするためのスペースが備わっています。また、他のプロジェクトから独立しているので、一定期間ごとのふりかえり（反省会）で提案された改善を気軽にドキュメントに反映することができます。

図7. RTCのプロジェクト・エリアに登録したプラクティス

図8. RTCのプロセス記述の相関イメージ

　こういった改善の成功の積み重ねを上位層の標準プロセスに順次フィードバックして、常に時代やニーズに合ったプロセスを組織全体で共有することができます。

　これまでの開発プロセス標準の決め方では、定義する側と開発現場の課題意識の乖離も有ってなかなか浸透しないということが多々ありましたが、現場を信頼して、ある程度の権限を与えて柔和なガバナンスによる開発プロセスにより、本来の目的である組織レベルでの生産性向上を実現しやすくなります。

　「アジャイルをプロセス化する」ということ自体に反発を覚える技術者にお会いすることがよくあります。そもそものアジャイルやリーンの発想が、無意味な形骸化したプロセスへのアンチテーゼであったわけですから、反発を覚えるのも無理はありません。しかし、その一方で、"自律"を重視するアジャイルではあっても、その律し方があらゆる人で同じということも期待できないでしょう。開発に関わる人が多くなってくれば、ある程度の節目や、進め方の大枠が共有されていないと、無法地帯になってしまいます。

　次回は、"自律""ガバナンス"について話を進めていきたいと思います。