作業の分割/分業/工程

前回のエントリにも何人かの方からコメントを頂きました。

頂いたコメントを読んでみて、私の中でも工程というものの
定義自体があいまいだったと思いました。
コメントを下さった方の意見は、工程に対する異なる定義に
基づいていて、そこがどうも議論のかみあわなさにつながって
いるような気がします。

私は、ソフトウェア開発における
・作業の分割
・分業
・工程の分割
の3つを区別して考えたいと思います。

3つのうち、もっとも基本的なものは作業の分割
です。これは単に、開発作業全体を管理可能な部分に分割することです。
これは単に分割するということ以上の何者も意味していません。
この分割は、スコープ管理、進捗管理など、プロジェクト管理の基礎と
なるため、ほぼ どのプロジェクトでも必要と思われます。
前回のエントリに対するhiro345さんの意見は、工程というものを
この最も基本的な意味での作業の分割という意味に捉えていると
想定され、その限りにおいて私はhiro345さんの意見に同意します。

分業は分割した作業を異なる担当者にアサインすることです。

さて、問題の工程です。過去のエントリを
読みなおしてみると、私は工程をほとんど作業の分割
と同じように語ってしまっていましたが、実は私の中では勝手に
もっと純粋にウォーターフォール的な意味での工程をイメージしていました。

私のイメージする「工程」を語るためには、まず「作業の分割」にも
次の2つのやり方があることを示さねばなりません。

1.直列に分割する
2.並列に分割する

1.の直列に分割することは、ある機能を実現する作業を

要件定義->基本設計->詳細設計->プログラム設計->
実装->単体試験->結合試験

といったように上流から下流に向かい、前の作業が終わらなければ次の作業に
移れないように分割することです。

2.の並列に分割することは、
システム全体を実現する作業を並行して行えるように、多くの場合は
機能毎に分割することです。

工程とは、作業を直列に分割し、かつ分割した作業に対し
分業が可能なようにInputとOutputとなる成果物を定義し、生成することです。

tatakahaさんの指摘は、作業を並列に分割し、それを異なる担当者で分業
するというものでした。それによって、コストをかけることで
納期が短縮できる。まったくそのとおりだと思います。
私自身、この後のエントリで作業を分割するなら工程と言う形で直列に
分割するのではなく、並列に分割した方が良いという話を書こうと思っていた
所です。

並列に分割した場合は、ここで定義した意味での工程に分割した場合に
発生する問題は発生しませんが、その代わりに並行して開発した部分を
統合するコストが発生します。
しかし、JUnitの様なテストのためのフレームワークや、Mavenのような
ビルドツールの進歩のおかげで、この統合のコストはあまり問題に
ならなくなっています。だから、作成するソフトウェアの規模が大きく、
かつ納期が限られているため、追加の要員を投入して
分業を行うことが必要なケースでは作業を直列に分割する
より並列に分割することを優先した方がうまく行くと思っています。

言葉の定義を後付けするのはあまりよろしくないとは思いますが、
blogでは最初から体系的に書くことは難しいので、
大目に見て頂ければと思います。

今ちょっと酔ってるので何か言ってること
おかしかったらご指摘ください。

次は、どうしても工程を分けざるを得ない場合に、
その分け方の善し悪しをどう判断したらいいか、という話題を取り上げたいと
思っています。