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

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

2012/05/08 14:00

ポスト

　いくつものアジャイル・プラクティスがツールの利用を前提にしているように、IBM Rationalのプロセス戦略においてもツールは重要な要素です。本稿では、プロセスのオーサリングをするためのRational Method Composer、プロセスの実行エンジンとしてRational Team Concertを取り上げ、アジャイルのプロセス化とツールによって解決できる問題が何かを論じたいと思います。

ポスト

プロセスの展開に必要なこと

自律的な展開と改善サイクル

　標準プロセスの定義ドキュメントを公開して幾度かの説明会を開催し、あとは自然と普及するのを待つ。一年後に調べたらまったく使われていない...という黄金パターンを経て、認知を広げるだけでは不十分であることはご承知のとおりです。ならばと、ISOなどの規格に準拠するために行ったようにガバナンスの大義名分の下、組織上層部から適用を働き掛ける対策が思ったよりも効果が出ない...という、もう一つの黄金パターンもご経験済みではないでしょうか。

　プロセスの展開は、実行側である開発チームに自発的に適用できる力を付けさせて、さらに実行で得られたチームの知見を反映して改善を自律的に続けていくことです。教育と環境をセットで提供することが望ましく、そのためにガイドやトレーニングを用意し、予算が許せば実践を支援するツールなどの環境も提供することになります。また、ビジネス環境やプロジェクト状況の変化へ動的に対応するためにも、プロセスのカスタマイズを前提にしておかなければなりません。

　また、アジャイル開発の世界では、プラクティスのラインナップは固定されることはありません。日々、現場からの知見を得て、これからも様々なプラクティスが提案されていくでしょう。これらの新しい"知見"も必要に応じて適宜追加していきたいものです。

　開発組織のゴール達成に向けて変化を許容することでプロセスの浸透は早まり、組織全体での生産性の底上げに繋がります。

カスタマイズを下支えするプロセス定義の『型』

　あえてカスタマイズと表現しましたが、CMMIでも明記されているように、プロセスはテーラリング（Tailoring）して現実に見合ったものにすることが必要です。テーラリングは直訳すると「洋服の仕立屋」という意味です。つまり、オーダースーツやドレスのように、対象業種やプロジェクトの特性（規模、期間、新技術の利用など）にプロセスをフィットさせるわけです。ただし、すべてのプロジェクトをフルオーダースーツにすることは、現場のオーバーヘッドになり現実的ではないので、例えば、プロセスの記述内容を修正するフルオーダーのテーラリングは部署単位、プロジェクトやロール・チームにおいてはイージーオーダーでプラクティスの取捨選択だけするといったようなテーラリングの程度に配慮が必要です。

　IBM Rationalでは、これを行いやすくするためにRational Method Composer（以後、RMC）でオーサリングの仕組みをフレームワーク化しています。その大本となるプロセスの定義を収める『型』をメソッド・プラグインと呼び、連載第1回で登場したRUP由来でOMGに承認されたSPEM2（Software Process Engineering Meta-Model 2.0）に準拠しています。これによって深く意識せずともプロセスの構成要素はある程度の統一化を図ることができ、部署や人に依存せずにプロセスの定義を誰でも理解しやすい環境を整えることができます。

　メソッド・プラグインは、一つのメソッド・コンテンツと一つのプロセスという枠で構成され、メソッド・コンテンツにはロールやワーク・プロダクト（成果物）やタスクなどを記述して、プロセスには主にWBSなど順序を定義します。新しいプラクティスを取り込もうとする場合には、メソッド・プラグインを追加することで、すでに定義されているプラグインと同様に扱うことができます。

図1. 左: Rational Method Composerのメソッドの構成要素、右: 階層構造

　このメソッド・プラグインの集まりがメソッド・ライブラリーとなります。RMCのデフォルトのメソッド・ライブラリーは、IBMプラクティス・ライブラリーであり、これをスーパーセットとしてメソッド・プラグインをピックアップして組み合わせたものがStandard RUPやディシプリンド・アジャイル・デリバリー（以後、DAD）といったプロセスとして構成されています。

　次に具体的にRMCでのテーラリングの方法を紹介します。