作業成果物の目的

開発プロセスの構築支援で「作業成果物の目的を明確にしたほうがよいか」という質問をいただいた。これには注意が必要だ。

開発プロセスに関係する要素には、作業定義、作業成果物、ロール、ガイダンスがある。作業定義を特化させたものがActivity,Task,Iteration,Phase,LifeCycleなどの定義となる。作業には開始条件／終了条件（ゴール）、目的、実施事項（作業ステップ）などが定義される。作業の実施（作業ステップの実行）を支援するためにガイダンスがある。そこには技法などのノウハウが記述されている。こういった構成であるはずだ。

開発プロセスを定義する場合、体系化しやすいように、つまりプロセス改善に柔軟に対応できるように、各作業で適用する手法・技法や利用するツールについての記述を分離しておく必要がある。プロセス定義の中にいわゆるノウハウを含めないようにし、それらはガイダンスとして分離してまとめる訳である。

プロセス定義では、目的とその手段を明確に分離して構成すべきなのである。手法・技法の適用、ツール利用は手段である。実作業ではいろいろな手段の中から任意のものを選択して、目的を遂行すればよい。

ここで問題となるのは作業成果物である。作業成果物は手段である。選択必須の手段である。作業の目的を達成していれば、Excelの表であろうが、UMLで表現したモデルであろうが構わない。たとえば「利害関係者の特定」というタスクの作業成果物は、表形式でまとめてもいいし、UMLのアクターで汎化を使いながら表現してもいい。

作業成果物は、作業定義と同じようにプロセス要素であり、ガイダンスを伴う。テンプレート、サンプル、作成要領などがある。ただ作業定義と違ってゴールはない。明示すべき目的はない。なぜなら作業成果物は作業定義の手段であるからだ。

作業成果物に目的を記述しようとすることはナンセンスである。作業成果物はその関連付く作業定義によって目的は変わるからだ。クラス図やシーケンス図はいろいろな局面、つまりいろいろな作業の作業成果物となり得る。個々のクラス図やシーケンス図に目的を設定しようとしても無理である。目的は作業定義（ActivityやTask）の方に在るのである。作業成果物に無理に目的を設定すると、結局は作業定義で明示される目的と同じになる。いろんな局面で利用される作業成果物では、矛盾が生じてくるかもしれない。