開発プロセスに実効力を持たせる「プロセス・エンアクトメント」
さて、今回は少しテーマを変えて、Jazzの新しいコンセプトである「プロセスをツールに組み込むことで、ツールが開発者にそのプロセスに自然に従うようにする」、というお話をしましょう。
アジャイル開発では厳格なルール（無駄が多いという意味で）を嫌う傾向がありますが、ルールがまったくないというのも考えものです。例えば、分散環境であったり経験やスキルのまばらなメンバーの集まったチームでは、何のルールもなくプロジェクト運用は人任せというのは危険です。自律したチームほど守らなくてはいけない必要なルールが何であるかを知っているものです。
チーム・メンバーにとって、スムーズに仕事がはかどるためには必要最低限のルールが必要です。しかし開発者全員にルールを徹底するのは大変です。
では、ツールがルールを守るように開発者に仕向けてくれるとしたらどうでしょう？ 例えば、原則としてソースを変更してチームのストリームに提出するのに、変更の元となる作業指示（ワークアイテム）を申告しないと提出できないといったルールがあるとします。そして、その申告を忘れた時、ツールが「あなたはワークアイテムの申告を忘れてますよ。今あなたが担当しているいくつかのワークアイテムのうち、今回はこれらのうちどのワークアイテムに関するソースの変更なの？」って聞いてきてくれたら苦労せずルールに従うことができそうです。
このように今までソフトウエア開発の現場では、そのプロジェクトで規定した例えば次のような項目と、実際の開発作業というのはかけ離れることが多いと言えるのではないでしょうか。
- 実在の開発者と役割の定義
- 役割によって果たすべき責務（および、やってはいけない作業）
- ワークアイテムと成果物
- ワークアイテムの状態遷移をさせてよい条件
- チームの環境に変更を与える操作を行う際の条件 など
ソフトウエア開発のプロジェクトにおいて「誰が、何をして、何を作成する」といった定義は開発プロセスと呼んでいます。通常プロジェクトを運用するためにさらにこれらに付随する「うまくいくための経験則」や、やってはいけない「べからず集」も含まれていることが多いものです。
こうしたプロセスを、それを定義しただけの単なる読み物ではなく実質的な効力を持たせるようにすることをJazzでは、「プロセス・エンアクトメント（Process Enactment）」と呼びます。つまり、Jazzが狙っているのはツールがプロセス・エンアクトメントを実現し、開発者が自然とプロセスに従うようにするというものです。
エンアクトメントはあまり聞き慣れない言葉だと思います。辞書では法律などの効力を発効する、という意味と書いてありますが、日本語ではぴったりくる表現とは思えないので、そのままエンアクトメントと呼ぶことにしています。
