第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でのテーラリングの方法を紹介します。

次ページ：プロセスのテーラリング

プロセスのテーラリング

ピックアップ型のプロセスの構成

　Rational Method Composer（以後、RMC）によるプロセスの構成は、ツール上はメソッド構成というもので定義します。まず、メソッド・ライブラリーからプロセスに含める要素をメソッド・コンテンツのコンテンツ・パッケージ、プロセスのケーパビリティー・パターンおよびデリバリー・プロセスを単位としてピックアップします。この方式にすることでメソッド・コンテンツとプロセスの再利用性が高い上に、プロジェクトに適用する開発プロセスの定義を柔軟に行えます（図2）。

図2. DADのメソッド構成の画面

　また、定義済みのメソッドがプロジェクトに適さない場合には、ベースとなるメソッド・プラグインから派生させてオリジナルのメソッド・プラグインを拡充させることができます。当然、メソッドをスクラッチで記述するのに比べて作業量は圧倒的に少なく済みます。例えば、あるタスクのカスタマイズを行う場合では、定義項目が明確になっているので、関係者間で変更内容の合意形成が取りやすくなっています（図3）。

図3. タスク記述の画面

　ただし、いくら容易とはいえ、メソッドの記述を変更するレベルのテーラリングが頻発すると開発現場の負担が高くなり、プロジェクトの立ち上がりの期間を長くしてしまうので、ISOやプライバシーマークなどの認定に対応する全社統一のプロセス以外は、対象業種や部署ごとに開発プロセス標準をテンプレートとして規定して、プロジェクトやその中のロール・チームはピックアップ型でテーラリングするのが現実的です。

定義したプロセスの公開

　RMCでのメソッド構成（プロセス定義）が完了したら続いて公開用のドキュメントをHTML、Adobe PDF、Microsoft Wordのいずれかの形式で出力します。HTMLは、シンプルなWebサーバーで公開するための静的なコンテンツとして、またはJavaアプリケーション・サーバーのアプリケーション（WARまたはEAR）としての出力を選択できます（図4）。プロジェクトに適用したプロセス定義をプロジェクトのポータル・サイトなど、規定した場所に公開することで参照しやすくすることができます。

図4. Tomcatでアプリケーションとして出力したDADのドキュメント

　さらにRMCには、メソッド・プラグインのケーアビリティー・パターンに含まれるWBSをプロジェクト管理ツール用のデータとしてエクスポートすることができます。これらのタスクには、すべき作業の説明が記述されているだけでなく、プロセス定義へのハイパー・リンクも含まれており、担当者がタスクの意味と求められる成果物を理解するのを手助けします（図5）。

図5. Microsoft Projectに取り込んだWBSとプロセス定義

次ページ：プロジェクト実行を支援する環境

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

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

　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のプロセス記述の相関イメージ

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

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

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

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