はじめて使う Jazz: 第 5 回 プロセス・エンアクトメント

さて、今回は少しテーマを変えて、Jazzの新しいコンセプトである「プロセスをツールに組み込むことで、ツールが開発者にそのプロセスに自然に従うようにする」、というお話をしましょう。

畑 秀明, ソフトウェア事業ラショナルテクニカルセールス&サービス, IBM

畑 秀明 日本アイ・ビー・エム株式会社 ソフトウェア事業ラショナルテクニカルセールス&サービス。ソフトウェア開発は楽しいのだけど、いつ頃からか「きつい仕事」というイメージがつきつつあると危惧しています。開発者の明るい未来を目指してよりよいやり方、道具、そういったものを一人でも多く人に知ってもらう、あるいは実践してもらうために日々活動しています。



2009年 4月 17日

開発プロセスに実効力を持たせる「プロセス・エンアクトメント」

アジャイル開発では厳格なルール(無駄が多いという意味で)を嫌う傾向がありますが、ルールがまったくないというのも考えものです。例えば、分散環境であったり経験やスキルのまばらなメンバーの集まったチームでは、何のルールもなくプロジェクト運用は人任せというのは危険です。自律したチームほど守らなくてはいけない必要なルールが何であるかを知っているものです。

チーム・メンバーにとって、スムーズに仕事がはかどるためには必要最低限のルールが必要です。しかし開発者全員にルールを徹底するのは大変です。

では、ツールがルールを守るように開発者に仕向けてくれるとしたらどうでしょう?例えば、原則としてソースを変更してチームのストリームに提出するのに、変更の元となる作業指示(ワークアイテム)を申告しないと提出できないといったルールがあるとします。そして、その申告を忘れた時、ツールが「あなたはワークアイテムの申告を忘れてますよ。今あなたが担当しているいくつかのワークアイテムのうち、今回はこれらのうちどのワークアイテムに関するソースの変更なの?」って聞いてきてくれたら苦労せずルールに従うことができそうです。

このように今までソフトウエア開発の現場では、そのプロジェクトで規定した例えば次のような項目と、実際の開発作業というのはかけ離れることが多いと言えるのではないでしょうか。

  • 実在の開発者と役割の定義
  • 役割によって果たすべき責務(および、やってはいけない作業)
  • ワークアイテムと成果物
  • ワークアイテムの状態遷移をさせてよい条件
  • チームの環境に変更を与える操作を行う際の条件 など

ソフトウエア開発のプロジェクトにおいて「誰が、何をして、何を作成する」といった定義は開発プロセスと呼んでいます。通常プロジェクトを運用するためにさらにこれらに付随する「うまくいくための経験則」や、やってはいけない「べからず集」も含まれていることが多いものです。

こうしたプロセスを、それを定義しただけの単なる読み物ではなく実質的な効力を持たせるようにすることをJazzでは、「プロセス・エンアクトメント(Process Enactment)」と呼びます。つまり、Jazzが狙っているのはツールがプロセス・エンアクトメントを実現し、開発者が自然とプロセスに従うようにするというものです。

エンアクトメントはあまり聞き慣れない言葉だと思います。辞書では法律などの効力を発効する、という意味と書いてありますが、日本語ではぴったりくる表現とは思えないので、そのままエンアクトメントと呼ぶことにしています。

 

プロセス・エンアクトメントの例

ここで、より理解を深めるために、Rational Team Concert(以下、RTC)のプロセス・エンアクトメントの動きの例をみてみることにしましょう。

「はじめて使うJazzシリーズ」の第3回で見たようにRTCでソース管理を行うことができますが、ソースを修正してチームのストリームに提出する際に、コメントを入れることとワークアイテムとの紐付けをしないと提出を許さない、というルールをツールに設定したとします。

それにもかかわらず、ある開発者がソースを修正してそのまま提出しようとしたとします。

 

すると、RTCはチーム・アドバイザー画面を表示して、ルールに違反していることを教えてくれます。

 

それでは、この違反を解消するにはどうしたらよいのでしょうか。

チーム・アドバイザーは違反があったことを教えてくれるだけでなく、画面の右側に解決策の欄があり、この場合どうすればよいか、3つの候補を教えてくれています。例えば今回の対応としては「既存のワークアイテムの関連付け」をして対応することとし、候補の中からそのリンクを選択してみます。

すると、ログインしているユーザーが担当しているワークアイテムが選択できる画面が表示されてきます。

 

適切なワークアイテムを選択して[OK]を押したうえで、再度「保留中の変更」ビューに戻り、チーム・アドバイザーの指示の通りにコメントをいれます。

 

再度、提出をします。すると、今度はエラーなく終了しました。

ここでのルール「ソースを修正してチームのストリームに提出する際に、コメントを入れることとワークアイテムと紐付けをしないと提出を許さない」は人手の運用に任せると徹底させるのが大変だったりうっかり忘れてしまったりということがありえます。しかしこのようにRTCが誘導してくれることで開発者にとってそれほど負担を感じることなくルールに従えるようになるわけです。

プロセスに効力を持たせる、プロセス・エンアクトメントの実現は他にもありますが、このようにツールが振る舞いを変えて開発者を適切なプロセスに誘導する動きはまさにプロセス・エンアクトメントの代表的なものです。

さぁ、プロセス・エンアクトメントがどういったものかということが理解できたと思いますので、RTCのプロセス・エンアクトメントについての動作と設定について詳しく見ていくことにしましょう。


プロセスの設定とプロセス・テンプレートの関係

注釈

第1回では、RTCのバージョン1.0.1.1M1を用いていましたが、現在は製品版のバージョン1.0.1.1がリリースされていますので今回の記事ではそれを用いています。そのため、第1回の記事の画面とは多少変更があります。特に日本語翻訳部分でいくつかの改善がされています。

自分のプロジェクトで設定したいプロセスについては、RTC上でプロジェクトを作成したときに選択したプロセス・テンプレートによってそのデフォルトのプロセスが決まります。

プロジェクトを作成する手順については、「はじめて使うJazzシリーズ」の第1回の「プロジェクトの作成」を参照するとよいでしょう。

RTCに含まれているデフォルトのプロセス・テンプレートは以下の5種類があります。

  • EclipseWayプロセス
  • OpenUPプロセス
  • シンプル・チーム・プロセス
  • アジャイル・プロセス
  • スクラム
 

これらのいずれかを選択することで、プロセスとして定義すべき役割や必要となるワークアイテム、ルールなどが決定されます。

その例として、選択したプロセス・テンプレートに応じて、プロジェクトで指定できる役割の種類が異なることをお見せしましょう。

このシリーズの第1回でプロジェクトを作成した際には、スクラムを選択してプロジェクトを作成しました。その際にメンバーを定義する中で併せて役割も指定しました。

 
 

スクラムでは4つの役割が定義されていましたが、他のプロセス・テンプレートを採用したときにはどのように変わるかを見てみましょう。

次の図はプロセス・テンプレートとしてEclipseWayプロセスを選択したときの役割の指定の画面です。EclipseWayプロセスでは2種類の役割が定義されています。

EclipseWayプロセスを選択した際の役割の種類

次の図はOpenUPプロセスをプロセス・テンプレートとして選択したときの役割の指定画面です。OpenUPプロセスでは、6種類の役割が定義されていることが分かります。

OpenUPプロセスを選択した際の役割の種類

プロセス・テンプレートによって役割の違いがあることを理解してもらいましたが、これと同様にワークアイテムの種類、自動生成されるワークアイテム、ワークフロー、開発者がアクションを起こしたときのルール、ワークアイテムの状態遷移などをプロセス・テンプレートごとに設定しておくことができます。

このようにプロセスの設定はプロジェクト作成の際に選択したプロセス・テンプレートによって大筋決定されるということが分かりました。

この先は、テンプレートに定義されているデフォルトの設定を、プロジェクトのレベルで変更して自分たちのプロジェクトに合ったプロセスを定義することについて説明していきたいと思います。なお、この先の説明では、ここまでの連載と同様にスクラムのプロセス・テンプレートを使用したプロジェクトで操作していくことにします。


今回確認するプロセス・エンアクトメントのシナリオ

RTCでプロジェクトのプロセスに関連する設定項目は非常に多く用意されています。

これらは、プロジェクト・エリアを開いた画面の「プロセス構成」タブで設定することができます。

 

注釈

プロセス構成を変更するには、RTCのStandard Editionが必要です。Express Editionを使用している場合は、セキュリティ制御可能な箇所が限定されています。以下のシナリオについてもStandard Editionであることが前提となります。

Express Editionを使用した場合、誰もがほぼ全部可能になるという緩いセキュリティになりますので注意してください。また、Express Editionでも以下の設定が画面上は行えるのですが、ツールの振る舞いはそれらを無視する形になるので、注意が必要です。

今回はページの都合上すべての設定を細かくご説明するわけにはいきませんので、以下の代表的なシナリオを用意しました。これらに沿ってRTCの動きとその設定方法について見ていくことにしましょう。

  • シナリオ1)
    ソース管理において提出時にワークアイテムの関連付けを必須とする。
  • シナリオ2)
    役割ごとにできる操作を変える。
  • シナリオ3)
    シナリオ1)において時期によってルールを変える。

シナリオ1)ソース管理において提出時にワークアイテムの関連付けを必須とする

これはこの記事の冒頭でプロセス・エンアクトメントの例として説明した動作です。

この動作の設定を行うのは、プロセス構成タブの中の「構成」セクション内の[チーム構成]-[操作の振る舞い]を選択します。

細かい操作ごとと役割ごとのマトリクスが表示され、該当する操作と役割の組み合わせにおける設定が画面右下部に表示されます。

 

クリックして大きなイメージを見る

デフォルトのプロセスでは図のように、以下の組み合わせが指定されています。

  • 操作=ソース管理(クライアント)
  • 役割=利用者(デフォルト)
  • 前提条件=変更セットの説明

この時の制約として、以下が設定されています。

  • 変更セットに対してコメントと関連付けたワークアイテムの両方が必要であること。
  • ワークアイテムの所有者が指定されていること。ただし、操作をしている開発者である必要はない。
  • そのワークアイテムの計画対象に何かしらの計画が指定されていること。ただし、その計画が現在操作している該当の計画でなくてもよい。

今回、これを「スクラム・マスター以外は提出できない。提出時はワークアイテムの関連付けだけでコメントはオプションとする」というルールに変えるとしましょう。

まず、利用者(デフォルト)の動作指定を解除します。そのためには画面中段の「この操作に前提条件およびフォローアップ・アクションが構成されます」のチェックをはずします。

 

次に、操作の中の[ソース管理]-[提出(クライアント)]行のスクラム・マスターの欄をクリックして、[この操作に前提条件およびフォローアップ・アクションが構成されます]のチェックを入れます。

引き続き、前提条件セクションの[追加]ボタンを押します。前提条件として指定できる候補の一覧が表示されますので、[ワークアイテムおよびコメントは必須]を選択して[OK]を押します。

 

制約セクションの提出時に変更セットに必要なものが「関連付けられたワークアイテム」にチェックがはいっていることを確認してください。

最後に画面右上の[保存]ボタンで保存しましょう。下図が設定が終了した状態の画面です。

 

クリックして大きなイメージを見る

これで「スクラム・マスター以外は提出できない。提出時はワークアイテムの関連付けだけでコメントはオプションとする」というルールを設定することができました。

この設定は[保存]ボタンを押したタイミングでリアルタイムに反映されます。ソース管理の機能で試してみるとこのルールに沿った動きをすることが分かると思います。


シナリオ2)役割ごとにできる操作を変える

次にプロジェクトに指定した役割ごとに、操作の許可・不許可を設定する場面を見てみましょう。

シナリオ1)で行ったようなプロセス設定の変更をプロジェクト・メンバーの誰もができてしまっては困りものです。ここではルールとして「スクラム・マスター以外はプロセス構成を変更できない」というルールを作ってツールに設定しましょう。

この役割ごとの操作の許可設定もプロジェクト・エリアのプロセス構成タブで設定します。

構成セクションから[プロジェクト構成]-[アクセス権]を選択します。

右画面に役割ごとに許可されたアクションが表示されます。チェックボックスのスタイルになっているので、許可する場合はチェックを入れます。逆に操作を許可しない場合はチェックをはずします。

 

クリックして大きなイメージを見る

また、上部の[すべてのアクションおよび役割を表示]にチェックを入れると、アクションと役割のマトリクス形式でチェックする画面に切り替わります。これは同じ設定の見方を変えているだけですので、いずれか好きな方で設定を行うとよいでしょう。

 

クリックして大きなイメージを見る

今回、スクラム・マスター役割のプロセス仕様の変更にはチェックを入れ、それ以外の役割にはこのチェックをはずせば、今回のルール「スクラム・マスター以外はプロセス構成を変更できない」を実現することができます。

試しにスクラム・マスターではなく、チーム・メンバーである開発者:次郎がプロセス構成を変更しようとした時のエラー画面をお見せします。この場合、次郎に解決策はないので、チーム・アドバイザーは単にその操作が権限に違反していることだけを通知しているだけになります。

 

シナリオ3)シナリオ1)において時期によってルールを変える

中規模・大規模でアジャイル開発を行おうとした場合、試行錯誤するようなプロジェクト初期にはルールを緩めて創造性を損なわないようにし、プロジェクト後期の量産期にはメンバーが多くなったり分散チームで行ったりするため、ある程度の縛りをいれる、という運用が求められることがあります。

ここではシナリオ1)のソース管理においてワークアイテムとの関連付けを必須とする、というルールを拡張して、以下のルールをRTCに設定しようと思います。

「スプリント1では誰でも提出できる。ただしワークアイテムの関連付けあるいはコメントのいずれかを指定することとする。スプリント3ではスクラム・マスターとチーム・メンバーだけが提出できる。ただし、ワークアイテムの関連付けとコメントの入力が必須とする」

まず、プロジェクト・エリアのプロセス構成タブで構成セクションの[チーム構成]を開きます。開発ラインの下を開いていくと、プロジェクトで定義した反復構造が同じように見えてきます。

 

これをよく見ると、シナリオ1)で設定したものと同じ「操作の振る舞い」という設定項目が複数出てきていることに気が付きます。

スプリント1の中にも「操作の振る舞い」の設定がありますし、スプリント3の中にも「操作の振る舞い」の設定があります。

つまり、これらに異なる設定をすることで、スプリント1とスプリント3のルールを変えることができる、というわけです。

また、スプリント1から上をたどると、「リリース1.0」「メイン開発」「チーム構成」の各レベルに「操作の振る舞い」がありますが、これは階層構造として上位で設定したものが下位に伝搬する動作をします。

スプリント1のレベルで許可をはずしたとしても、その上位のどこかで許可がされていたら、それは許可されているとみなしますので注意が必要です。

先のルールを実現するためには、まずシナリオ1)で設定したチーム構成レベルの振る舞いをはずします。設定をはずすには、構成セクションで[チーム構成]-[操作の振る舞い]の構成でスクラム・マスターに対する[ソース管理]-[提出(クライアント)]の欄を選択したうえで、[この操作に前提条件およびフォローアップ・アクションが構成されます]のチェックをはずします。

 

クリックして大きなイメージを見る

次にスプリント1の操作の振る舞いをルールに従うようにするため、利用者(デフォルト)役割に対して、前提条件として「ワークアイテムおよびコメントは必須」を追加して、制約セクションで提出時に変更セットに必要なものとして「いずれか」を選択します。

 

クリックして大きなイメージを見る

こうすることでRTCは、スプリント1では利用者誰もが提出が可能であり、提出時にはワークアイテムの関連付けか、コメントの入力により提出が可能、という振る舞いをします。

次にスプリント3はスクラム・マスターとチーム・メンバーだけに許可を与えるためには、次の画面のような設定をします。

役割としてスクラム・マスターとチーム・メンバーだけに構成を行い、制約は提出時に変更セットに必要なものとして「両方」を選択しましょう。

 

クリックして大きなイメージを見る

これで今がスプリント1なのか、スプリント3なのかによって、RTCの振る舞いが変わることになります。このようにスプリントごとに設定を変えることで、時期に応じたルールの強弱を付けることができ、プロジェクトの状況に応じた柔軟なルール運用が可能となります。


組み込まれたプロセス定義文書を参照する

プロセス・エンアクトメントの実現、つまり開発プロセスを作業環境から離れたところに置いたままにするのではなく作業をしながら開発者がすぐに使える状況にするという観点で、RTCは別の機能として開発プロセス文書をRTCの中に組み込むということができます。

プロジェクトを作成した際に選択した製品のデフォルトのプロセス・テンプレートには、その種類に応じたプロセス文書、すなわちそのプロセスで定義された文書(誰が、何をして、何を作成する、それにかかわる技術文書と共に)が含まれています。

プロジェクト・エリアの「プロセスの記述」セクションからそれを表示することができます。プロセスの記述セクションに、選択したプロセス・テンプレート名がリンクとしてあるので、それをクリックするとそのプロセスのプロセス定義文書がHTMLの形式で表示されます。

 

クリックして大きなイメージを見る

スクラムのリンクをクリックすると、このスクラムのプロセス・テンプレートに関する説明文書が表示されます。

 

このように、開発プロセスの文書がRTCの中に組み込まれることで、開発者が容易に参照したり、調べたりすることができるようになります。より一層プロセスが現場の開発者に使われる状態になるでしょう。


設定をカスタマイズしたプロセスをプロセス・テンプレート化する

注釈

プロセス・テンプレートの要素に日本語を用いると、作成されたプロセス・テンプレートでは日本語の部分は別のエリアに保管される形になります。これについては、jazz.netの記事『Translate Process Template』を参照してください。

ここまで説明した設定以外に、プロジェクトのプロセス設定は次のような項目を設定することができます。

  • ワークアイテムの種類(タスク、障害、変更依頼、など)
  • ワークアイテムの状態
  • 自動生成されるワークアイテム
  • ワークフローおよび状態遷移のルール
  • ワークアイテムの照会の種類
  • 利用可能なデフォルトのダッシュボードおよびレポートの種類

これらの設定を皆さんの組織や会社のルールに合わせて設定した後に、これを組織標準や全社標準としてRTCのプロセス・テンプレート化することができます。

手順は簡単です。

一通り設定が終わったプロジェクトをチーム成果物ビューで選択して、右クリックのメニューから[プロセス・テンプレートの作成]を選択します。

 

プロセス・テンプレート名および必要な情報を指定して[終了]を押すことでテンプレートを作成することができます。

 

これで次回からプロジェクトを作成する際に、選択する使用可能なプロセス・テンプレートの中に今作成したテンプレートが選べるようになります。

 

クリックして大きなイメージを見る

このようにしてプロセス・テンプレートを用いることで、皆さんの組織・会社のプロセスをエンアクトメントする環境を実現することができるようになるでしょう。

補足ですが、プロセス・テンプレートはそれ自体をエクスポートして他のサーバーへ移したりすることも可能です。

一度プロセス・テンプレートから作成したプロジェクトが存在する場合、そのプロセス・テンプレートは削除できなくなりますので、気をつけてください。


まとめ

今回の記事では、プロセス・エンアクトメントについてのご紹介とRTCにおける具体的な設定と振る舞いについて紹介してきました。

今後の記事では、ダッシュボードについて詳しく紹介していきたいと思います。どうぞお楽しみに!

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational
ArticleID=380819
ArticleTitle=はじめて使う Jazz: 第 5 回 プロセス・エンアクトメント
publish-date=04172009